Exchange 2010 Beta: Database Availability Groups против CCR - смотрим первыми

Microsoft на этой неделе выпустила публичную бету Exchange Server 2010, и мы поставили её на тестовую виртуалку. Руки чешутся написать раньше, чем дотронулись до продакшена, - но именно такой момент и бывает интересен: смотришь без груза обязательств и можешь честно сказать, что видишь.

Главная история в этом релизе - это Database Availability Groups, DAG. Вкратце: Microsoft выбрасывает в мусор Cluster Continuous Replication и Local Continuous Replication и делает на их месте один механизм, который умеет то же самое, но по-человечески.

Почему CCR был болью

Тем, кто не вникал в Exchange 2007, поясним коротко. Когда три года назад мы планировали первые переезды на Exchange 2007, высокая доступность базы почты выглядела так:

• CCR (Cluster Continuous Replication) - активно-пассивный кластер из двух нод, репликация транзакционных логов на пассивную ноду, автоматический фейловер. Звучит красиво. На деле - Windows Server Failover Clustering, который надо настроить отдельно, общее имя кластера, отдельный шаг квалификации каждого сервера, и если хочешь третью ноду для ситуации на другой площадке - уже LCR поверх этого, что отдельная история.
• LCR (Local Continuous Replication) - копия базы на том же физическом сервере. Спасает от сбоя базы, не спасает от сбоя железа. Для чего именно это - сложно сказать.
• SCR (Standby Continuous Replication) - появилось в SP1 и немного облегчило жизнь с геораспределёнными сценариями, но конфигурировать всё это вместе - удовольствие сомнительное.

Короче говоря, высокая доступность в Exchange 2007 - это когда ты потратил два дня на то, чтобы у тебя работало то, что в теории должно было быть одной галочкой в мастере.

Что такое DAG

В Exchange 2010 это всё заменяется одной сущностью. DAG - это группа серверов Mailbox (до 16 штук), между которыми базы реплицируются автоматически. Не надо отдельно поднимать WSFC, не надо разделять роли таким образом, что CCR-нода не может быть Hub Transport, не надо думать о том, куда пойти за пассивной копией в случае аварии.

На бете мы собрали пару из двух виртуалок, добавили обе в DAG, создали базу почты - и она появилась на обоих серверах как активная копия на одном и пассивная на другом. Фейловер потестировали выключением первой ноды: почта переключилась на вторую примерно за минуту, без какого-либо вмешательства.

Несколько наблюдений по бете:

• WSFC под капотом остался, но DAG его поднимает и конфигурирует сам при добавлении серверов в группу. Это принципиальный момент: ты работаешь с DAG, не с кластером напрямую.
• Witness-сервер нужен для кворума при чётном числе нод - Exchange сам предлагает использовать Hub Transport сервер для этого, и это разумно: не надо держать отдельную машину.
• Репликация по сети, не через shared storage. Для большинства наших клиентов это хорошая новость: дорогой SAN для HA почты больше не обязателен, хватит нормального гигабитного соединения между серверами.
• Бета есть бета. Несколько раз консоль управления зависала при смене активной копии базы. В продакшен такое не пойдёт, но для первого взгляда картина в целом внятная.

Мы пока не гоняли нагрузочные тесты - это для беты излишне. Задача была понять концепцию и убедиться, что она работает именно так, как описана в документации.

Кому это важно прямо сейчас

На нескольких клиентах в рамках сопровождения у нас Exchange 2003. Это клиенты, которые в своё время не перешли на 2007 по очевидным причинам: 64-бит как жёсткое требование, смена архитектуры ролей, необходимость нового железа. Проще было подождать.

Вот сейчас мы им и говорим: ждали правильно. Exchange 2010 - это тот релиз, куда стоит идти прямо с 2003, минуя 2007. Аргументы простые:

• Миграция с 2003 на 2007 и затем с 2007 на 2010 - это две полных миграции, два окна, два риска, два раза переобучать пользователей Outlook.
• Exchange 2007 сейчас в конце активного жизненного цикла с точки зрения выхода новых версий, и идти на него за месяцы до выхода следующей версии выглядит странно.
• DAG делает высокую доступность почты доступной для клиентов, которым CCR был не по силам ни по стоимости, ни по сложности настройки.

Дата релиза Exchange 2010 пока не объявлена - это бета. Но горизонт планирования здесь правильный: начинать разговор с клиентом о переезде сейчас, чтобы к моменту RTM иметь готовый план, протестированный стенд и понимание объёма работ.

Для клиентов на Exchange 2003 с небольшой инфраструктурой следующий шаг - инвентаризация текущего состояния и оценка, что нужно докупить по железу. Требования к 64-бит никуда не делись, это условие сохраняется. Но хотя бы дорогой кластер под HA больше не обязателен - и это меняет экономику переезда.

Продолжаем смотреть на бету. Если RTM выйдет в этом году - готовимся заранее.