Размышления о высокой доступности UC решений от MS

Сколько минимум серверов нужно для построения UC решения от решения Microsoft с обеспечением высокой доступности?

Правильный ответ – два мощных сервера, два голосовых шлюза и хранилище с высокой доступностью. А теперь подробнее размышления на тему. Статья ни на что не претендует и выражает только мои личные мысли.

Обеспечение высокой доступности UC от Microsoft c минимальными затратами но сохранением поддержки🙂

Немного критики

Начну с критики в адрес Microsoft. Это гигантская компания и разные подразделения зачастую не могут не то что, влиять на разрабатываемые в других подразделениях решения, но даже договориться J.

Нет, ну честно, несколько вопросов касающихся взаимодействия продуктовых групп внутри MS, решение которых позволило бы, как минимум, снизить стоимость внедрения Unified Communications от MS:

1. Конфликт network load balancing (NLB) и Failover Cluster. В результате невозможно поднять Exchange 2010 с высокой доступностью, используя только серверные лицензии Windows Server / Exchange 2010 и не имея балансировщиков нагрузки сторонних производителей. Требуется, как минимум, два сервера Exchange с ролью Mailbox Server (MB), объединенных в Database Availability Group (DAG )и два сервера с ролями Client Access Server (CAS)и Hub Transport Server (HUB) где роли CAS балансируются посредством службы Windows NLB.

clip_image002

2. Отсутствие в network load balancing возможности определения сессии по cookie для веб трафика и контроля за балансируемыми службами. Технологии network load balancing уже много лет, а с Windows Server 2003 изменения косметические. Про конфликт с Failover Cluster я уже написал. Второй момент, который вполне можно было бы реализовать – настройка различных способов определения сессии, как делается в нормальных балансировщиках сетевой нагрузки (affinity, как называют это в MS, или persistence, как это называют в остальном мире). Ну а третий, возможность мониторинга служб, балансировка которых выполняется. Хотя бы банальным telnet. В результате, решение от MS (Microsoft Lync Server / Microsoft OCS) не поддерживает собственный механизм балансировки нагрузки.

clip_image004

3. Отсутствие поддержки механизма SQL Database Mirroring в Microsoft Lync Server 2010 для обеспечения высокой доступности баз данных. Мало кто готов тратиться на СХД с синхронной репликацией, а без SQL Database Mirroring это единственный способ хотя-бы приблизить высокую доступность Microsoft SQL к пресловутым пяти девяткам.

clip_image006

Казалось бы

clip_image008

Не очень приглядная картина во всех смыслах. Перерисовывать красивее мне, если честно, лень, а вот оптимизировать содержимое схемы можно попробовать.

Попробуем оптимизировать

Что ж, значит, если мы хотим сэкономить, нужно искать маленькие хитрости. Хитрости как обычно рождаются на стыке стандартных возможностей, так что о них и поговорим. Но сначала небольшое предупреждение. Как я уже писал ранее, в данной статье рассматриваются только поддерживаемые производителем решения.

1. Виртуализация. Зачем покупать 4 физических сервера под Exchange (2 MB и 2 CAS+HUB), когда можно купить два и поднять на каждом узле по одному виртуальному серверу с MB и одному с CAS+HUB. Затраты уже меньше а высокая доступность не страдает. Все компоненты Exchange Server и все компоненты Lync Server полностью поддерживаются в виртуальной среде. Поддержка серверов Exchange с ролью Unified Messaging, кстати, была объявлена на днях.

clip_image010

2. Строим единое решение🙂. Если у вас уже используются балансировщики нагрузки (например, для lync Server), вы можете развернуть все роли Exchange Server 2010 (кроме Edge конечно), на двух серверах с сохранением высокой доступности. Правда стоят они обычно в России дороже чем хорошие серверы, но и тут есть нюанс. И еще моя маленькая гордость🙂

Небольшое отступление. Балансировщики нагрузки в виде виртуальным машин (software load balancers или load balancers as virtual appliance) для Exchange Server поддерживаются давно. Поддержки же их для OCS / Lync еще год назад не было. Но несколько месяцев назад мне повезло оказаться на тренинге, проводимым продуктовой группой Lync, по бете продукта. На мои вопросы касательно поддержки Database Mirroring и NLB положительный ответ от выступающего представителя продуктовой группы, занимающейся обеспечением высокой доступности, не последовал. 🙂 На вопрос, почему поддерживаются только аппаратные балансировщики нагрузки, ответ был – потому что у программных версий недостаточный функционал. После выступления я поймал выступающего и 15 минут объяснял ему разницу (а вернее её отсутствие) между поддерживающимися тогда аппаратными балансировщиками Citrix Netscaler и их виртуальными копиями Citrix Netscaler VPX. Через 3 недели Citrix Netscaler VPX появились в списке поддерживаемых балансировщиков для OCS 2007 R2.

Пока, суммарно, если не брать в расчет телефонию и доступ из Интернет, у нас вырисовывается следующее решение: два физических сервера с четырьмя виртуальными машинами на каждом. И конечно, дисковые хранилища, с синхронной репликацией, подключенные к серверам.

На каждом сервере запущены следующие виртуальные машины: Exchange Server (MB+CAS+HUB), Lync Server Front End, SQL Server, балансировщик нагрузки в виде Virtual Appliance, балансирующий трафик для Lync и для Exchange в части CAS.

Если требуется телефония, самый дешевый вариант – обойтись без дополнительных виртуальных машин и голосовых шлюзов, совместить роли Lync Server Front End с Lync Server Mediation и организовать до оператора SIP trunk. Но тут очень много маленьких нюансов, ограничений и подводных камней. Так что это уже на свой страх, риск и геморрой.

3. Послабление требований. Допустим, из всего функционала Lync для вас критичным является только телефония. И Вы готовы ради существенной экономии на время восстановления какого-либо компонента решения отказаться от IM и различных конференций. В этом случае Вам уже не требуются жутко дорогие дисковые хранилища с синхронной репликацией. Ведь в случае выхода из строя кластера SQL, телефония Lync всё рано будет работать. А если вы готовы на 5-10 минут остаться без телефонии в случае непредвиденной ситуации, вы можете отказаться и от SQL серверов вообще и перейти на использование двух серверов Lync Server Standard вместо кластера Lync Server Front End. Об этом я уже писал в одной из статей.

4. Хостинг. Тут, как говорится, без комментариев. И без затей. Зачастую, самый дешёвый способ обеспечения высокой доступности решения это обеспечение высокой доступности канала в Интернет и использование хостинга. Даешь облака! 🙂 Кстати, Lync Server в облаке пока еще не доступен широкой публике хостеров и есть только у MS, да и в России пока Office 365 отсутвует. Минусы и плюсы, думаю, каждый для себя найдет сам.

Итого

Вывод простой и короткий. Идеального решения, как всегда, пока нет и наверно не будет. Оптимальное — подбирается исходя из имеющихся возможностей и требований.🙂

комментариев 11 to “Размышления о высокой доступности UC решений от MS”

  1. Argon Says:

    Во многом согласен, но хочу дополнить своими мыслями.

    1. Про виртулазацию.

    Думаю, что если не совсем заморачиваться на девятках после запятой, можно и без синронно реплицирующихся хранилищ обойтись. Одного CХД для работы 2х узлового кластера Hyper-V вполне хватит. На кластер положить все сервера в режиме высокой доступности ВМ, одновременно с этим оставив кластеризацию на уровне приложений (DAG, NLB). Таким образом, и нагрузку по узлам распределим, и доступность машин повысим, и кластеризацию на уровне приложений сохраним.

    При желании, можно сэкономить на лицензиях SQL Server (не собирать SQL кластер).

    2. Failover Cluster и NLB действительно не совместимы архитектурно в рамках одной машины. Однако, разве Exchnage DAG используют Failover Cluster в традиционном понимании? ИМХО, использует он лишь некторые API, либо вообще для галочки, чтобы Enterprise версии Windows Server покупали.

  2. Александр Донин Says:

    1. не спорю. Обычно так и делается.
    2. На самом деле, еще как использует. Запустите на Mailbox в DAG консоль кластера и убедитесь.
    Хотя на сколько мне известно, команда Exchange общалась с командой Windows на эту тему. Как видно, ничего не вышло. А то для ОС серверов в DAG требовались бы лицензии типа Standard, как и на сам Exchange 2010.

  3. Vitaly Says:

    Александр, а сколько стоит Citrix Netscaler VPX? Не дешевле все таки купить еще два Exchange? Просто судя по сайту Citrix стоимость там просто заоблачная.

  4. Александр Донин Says:

    Есть триальная лицензия на год. Ограничение 5 Мбит пропускной способности.
    Лицензия на 10 Мбит, если не ошибаюсь, стоит 2000$. На 200 Мбит уже 5000$.
    Для Lync в варианте с высокой доступностью балансировщик потребуется так или иначе. Ставя еще два Exchange вы тратите неньги не только на железо но и на серверные лицензии. Тем не менее всё индивидуально. В каждой ситуации нужно взвешивать все за и против.

  5. Vitaly Says:

    Вопрос: при 400-500 пользователях Exchange пропускной способности триальной версии достаточно по Вашему мнению?

  6. Александр Донин Says:

    http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/25b84026-a106-472b-8932-ea22abc3cbb1/
    По ссылке — пример приблизительного расчета.
    Всё зависит от объема писем, частоты их отправки и кол-ва получателей🙂
    В среднем — должно хватить. Но лучше пересчитать для вашего случая. При расчете не забывайте, что нагрузка обычно неравномерна. всегда есть часы пик.

  7. Vitaly Says:

    Спасибо за помощь!
    Последний вопрос — все таки для отказоустойчивости нужно использовать два балансировщика нагрузки в виде Virtual Appliance?

  8. Александр Донин Says:

    Аха. На разных физических серверах. В идеале на разных СХД. Кстати, с помошью балансировщиков нагрузки можно контролировать трафик в территориально распреленной инфраструктуре. При наличии кластера с узалми в сайтах А и Б пользователи из сайта А всегда будут обращаться к серверам сайта А а пользователи сайта Б к серверам сайта Б. Но это тема отдельной статьи.

  9. Vitaly Says:

    Александр, спасибо!
    Еще пара вопросов (уточнений)🙂
    1. «В идеале на разных СХД» — поясните?
    2. В случае следующей архитектруы: два физических сервера, на них в виртуальной среде на каждом Exchange (CAS+HUB+MB), балансировщик нагрузки, Lync FE Std (Primary или Backup Registar Pool):
    а) Отказоустойчивость Lync будет только для телефонии? И если как раз телефония не используется, то такой сценарий не особо имеет смысл?
    б) Имеет ли смысл базу Exchange разбить на две и, соответственно разнести активные базы по разным серверам с точки зрения производительности?
    3. Имели ли в практике внедрения на базе HP E5000?

    • Александр Донин Says:

      1. Обычно серверы виртуализации объеденяют в кластер, подключая к СХД. СХД в этом случае — точка отказа. Но — см. первый коментарий к статье.
      2. а. да
      б. воспользуйтесь http://gallery.technet.microsoft.com/v144-of-the-Exchange-2010-1912958d и примите для себя решение
      3. Это решение, вроде как, призвано уменьшить риски от некоректной инсталяции. А я работаю в системном интеграторе. Привлечение интегратора выполняет ту же функцию.🙂. Так что, нет.

  10. Vitaly Says:

    Спасибо!

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s


%d такие блоггеры, как: