Страница 1 из 1
Кластер отказоустойчивый для ESX серверов.
Добавлено: 30 май 2011, 16:46
Venberg
Из-за проблем с системами охлаждения помещения потеряли часть оборудования. Слава богу данные спасти удалось.
На данный момент доделываются две площадки на расстояние менее 100 метров. Между площадками оптика одномод. На каждой будет стоять по HP DL380 G5. В них хотелось бы запихать в ESX 4.1 все критичные сервера для бизнеса. Еще есть основной сервер с Windows Server 2008 Ent x64 (не R2) с терминалом и 1С7.7, 1С 8.2. Его наверное то же перенесем в ESX 4.1 что бы при аварии можно было поднять на любом оставшемся сервере.
Необходимо выбрать СХД. Склоняемся к вашей TrinityNAS, в перспективе две. Коммутационное оборудование для связывания двух площадок. И ПО для организации отказоустойчивого кластера. На данный момент у нас большая часть серверов загнана на один DL360 G5 под ESXi.
Re: Кластер отказоустойчивый для ESX серверов.
Добавлено: 30 май 2011, 17:59
setar
По хранению так:
Нужно две TrinityNAS в базовой конфигурации + Simple HA Cluster + AutoCDP + VMDC (работа с гипервизорами) лицензии
Опционально если нужно FCTarget для этих NAS
По сетке и лицензиям виртуализации сейчас коллеги подскажут.
в почту ушла документация по кластеризации.
Re: Кластер отказоустойчивый для ESX серверов.
Добавлено: 30 май 2011, 18:31
Kirill Tkachev
Venberg писал(а):На данный момент доделываются две площадки на расстояние менее 100 метров. Между площадками оптика одномод.
Оптика уже положена? Если нет, то лучше проложить многомод.
На такое расстояние использование SM не требуется, а стоимость оборудования значительно вырастает.
Уточните какой тип трафика вы планируете передавать между площадками по оптике (IP, FC). Нужно ли резервирование. Скорость канала.
Есть ли отличные от Windows сервера, которые необходимо виртуализовать?
Re: Кластер отказоустойчивый для ESX серверов.
Добавлено: 30 май 2011, 19:18
Venberg
Kirill Tkachev писал(а):
Оптика уже положена? Если нет, то лучше проложить многомод.
На такое расстояние использование SM не требуется, а стоимость оборудования значительно вырастает.
Уточните какой тип трафика вы планируете передавать между площадками по оптике (IP, FC). Нужно ли резервирование. Скорость канала.
Есть ли отличные от Windows сервера, которые необходимо виртуализовать?
Оптика уже лежит одномод.
Трафик пока IP.
Есть пока еще, отличный от других один Windows сервер. Который то же придется виртуализовать. Но с этим у ESX вроде бы проблем не должно быть.
Re: Кластер отказоустойчивый для ESX серверов.
Добавлено: 31 май 2011, 11:06
Venberg
Вопрос стоимости на оборудование и софт остается открытым. В добавок непонятно пока по активному оборудованию. Сколько и каких коммутаторов лучше брать? Или может в СХД и сервера повтыкать оптических 10Gb адаптеров и коммутаторы вообще не использовать? Два серера и две СХД разнесем по разным зданиям.
Re: Кластер отказоустойчивый для ESX серверов.
Добавлено: 31 май 2011, 12:22
Kirill Tkachev
Venberg писал(а):Оптика уже лежит одномод.
Прискобно, вам существенно дороже обойдется оборудование.
Venberg писал(а):Есть пока еще, отличный от других один Windows сервер. Который то же придется виртуализовать. Но с этим у ESX вроде бы проблем не должно быть.
Т.е. у вас вся инфраструктура с Microsoft серверами? Если да, то VMware не лучший выбор с точки зрения экономии - вам нужны будут дополнительные лицензии, если захотите полноценный кластер сделать.
Мне для вашего варианта видится две системы хранения зеркалирующихся по FC. Если волокон достаточно, то свитчи не обязательно.
Сколько волокон кабель лежит?
Два сервера на разных площадках.
Пара свитчей соединенных оптикой.
В случае аварии виртуальные машины в ручную восстанавливаются на резервной площадке (тут с VMware попроще, чем с Hyper-V - не надо конфигурации пересоздавать).
Re: Кластер отказоустойчивый для ESX серверов.
Добавлено: 31 май 2011, 18:40
Venberg
У меня единственный сервер на Windows 2008 x64 Ent (не R2). К счастью. И трогать похоже его не будем. Т.к. там 1С 7.7 dbf в терминале. Там два 5560 с 4 ядрами. А ESX в не дорогих редакциях держит только 4 виртуальных CPU для одной виртуальной машины.