Требуется помощь в планировании High Availability на Microsoft

Издрасьте. Дошли руки/ноги/голова до планирования высокой доступности в отдельно взятом офисе (нет, работу я еще не сменил :)).

Итак, дано:

1. Желание исключить критические точки отказа и повысить доступность для следующих служб:
1.1. Файловый сервер
1.2. Exchange
1.3. CRM+ERP-сервер
2. Необходимость замены некоторого серверного оборудования.
3. Наличие жареного петуха, который уже клюнул чересчур экономное командование компании (обошлось часовым простоем, но, кажется, осознание необходимости существует).
4. Возможность построения второй отдельной серверной комнаты в здании, что позволит устранить потенциальный риск глобальной катастрофы в единственной серверной: пожар / потоп / метеорит и т.п.

Исхожу из построения Failover Cluster c Hyper-V, планируя при этом виртуализировать:
* файловый сервер
* exchange с разнесением ролей (сейчас физически сервер exchange существует в единственном экземпляре)
* SQL-сервер (он же — erp).

Доступ в интернет, очевидно, придется дублировать при помощи массива Forefront TMG, но это — не в первую очередь.

В данный момент задача — осметить всё это хозяйство.

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

1. Microsoft рекомендует при развертывании Failover cluster использовать высокодоступное хранилище данных, предлагая в качестве сценария развертывания хранилища реализацию отдельного кластера. По сути, получается, что требуется реализация двух независимых кластеров: (a) файлового сервера и (b) hyper-v, использующего ресурсы (a). Получается, что требуется как минимум четыре физических узла, по два на каждый кластер. С учетом возможности размещения узлов в разных серверных помещениях, подход верен с точки зрения отказоустойчивости (а с учетом политики лицензирования Enterprise-версии windows — еще, вроде, и возможность нести 16 виртуальных машин — поправьте, если неправ)
2. Наличие отдельного кластера под файловый сервер предполагает наличие отказоустойчивого хранилища. С учетом различных серверных, полагаю, целесообразно развертывать правильные NAS. Вопрос: как правильно организовать отказоустойчивые NAS? На какое оборудование смотреть, исходя из желания оптимизировать бюджет мероприятия?
3. Достаточно ли для нормального функционирования двух указанных выше кластеров существующего сетевого оборудования? Сейчас для коммутации серверов эксплуатирую стек из гигабитных AT-AR9424, производительность устраивает. Требуется ли организация более производительной сети (оптика?) или для адекватной производительности достаточно имеющегося?
4. Как можно оптимизировать систему с точки зрения бюджета? Какое оборудование стоит применять в описанном сценарии? Кто реализовал подобное — поделитесь опытом, пожалуйста.
  • Вопрос задан
  • 4129 просмотров
Пригласить эксперта
Ответы на вопрос 2
omnimod
@omnimod
Большинство из тех сервисов, о которых вы написали, можно кластеризовать на уровне самих сервисов, например несколько контроллеров домена, DNS, DHCP, файловых серверов (DFS), Exchange серверов (DAG), SQL (например, Database Mirroring). В большинстве случаев это обеспечит больший уровень доступности сервисов (поскольку защитит не только от отказа железа), хотя и может потребовать большее количество лицензий на ПО (Exchange, SQL), а также позволит устранить единую точку отказа в виде общего хранилища; эффективнее утилизировать ресурсы серверов (нежели просто резервировать их под Failover Cluster); использовать DAS (sas/scsi хранилище или внутренние диски сервера) в качестве хранилища виртуальных машин и данных приложений, вместо общего хранилища.

exchange с разнесением ролей

Вы уверены, что это необходимо делать? Конечно, зависит от нагрузки и количества пользователей, но если <300 человек — не стоит слишком заморачиваться, кроме, пожалуй, установки выделенного front-end'а (например Exchange Edge или другой mail relay) для антиспам или антивирусной проверки входящих сообщений.

По сути, получается, что требуется реализация двух независимых кластеров: (a) файлового сервера

NAS (CIFS или NFS) официально не поддерживается в качестве хранилища вирутальных машин Hyper-V, тем более с DFS. Если вы планируете как-то иначе кластеризовать файловое хранилище (например с тем же Failover Cluster) вам все-равно понадобится общее блочное хранилище данных (DAS, SAN). Смысл тогда огород городить?

(а с учетом политики лицензирования Enterprise-версии windows — еще, вроде, и возможность нести 16 виртуальных машин — поправьте, если неправ)

Не совсем, при использовании Enterprise лицензий вы сможете запустить до 4-х экземпляров ОС на том же сервере, к которому данная лицензия привязана, если у вас будет всего 2 Hyper-V сервера, то значит, что вы сможете поднять 4-ре ВМ на одном и 4-ре на другом.

Вопрос: как правильно организовать отказоустойчивые NAS?

Что касается правильного NAS — как уже писал выше — не поддерживается. Если хочется отказоустойчивое хранилище (сравнительно дешевое), посмотрите в сторону Starwind или самосборном Linux + ietd + drbd + heartbeat (но, естественно, такое решение поддерживаться не будет).

Достаточно ли для нормального функционирования двух указанных выше кластеров существующего сетевого оборудования?

50/50 либо хватит, либо не хватит.
Ответ написан
Комментировать
liveder
@liveder
В своей компании планирую делать следующее:
10 серверов, на которых стоит citrix xenserver.
СХД, к которому подключены эти самые 10 серверов по фибрам.
Все сервисы(sql, terminal, почта) виртуализированы.
Соответственно, отказоустойчивость и распределение нагрузки берет на себя цитрикс.

СХД сделать отказоучтойчивым очень бюджетно. Сам СХД у нас выходит в районе 500 тысяч, так что делать резервный СХД будет явно накладно.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы