Информация:
Имеются две штуки stand alone хостов виртуализации (Hyper-V) на базе вот таких платформ: SYS-6017R-TDF. Также имеется вроде бы отказоустойчивая файлопомойка (RAID10 на железе, файловый кластер Windows Server из двух узлов поверх железа в виртуальных машинах) на базе вот такой платформы: SYS-5017C-MTF. Коммутатор серверной стойки вот такой: Cisco SG300-10.
На всех трех хостах по 2 гигабитных сетевых адаптера, объединенных в NIC Teaming средствами WS2012R2, настроен weight-based QoS. Под каждый тип трафика (репликация, управление, доступ в сеть для виртуалок) отведены отдельные виртуальные адаптеры с соответствующими весами QoS.
Внутри хостов виртуализации крутятся: AD DC -- 2 шт., хосты сессий RDS -- 2 шт., хосты сессий RemoteApp -- 2 шт., на каждый хост виртуализации по одной каждого типа. Весь этот зоопарк загружает сеть примерно на 100мбит/с в пике, средняя нагрузка около 30мбит/с. В случае репликации виртуальной машины сеть, естественно, утилизируется "в ноль", но такое в рабочее время случается нечасто.
Сейчас возникла необходимость в поднятии отказоустойчивого SQL, в связи с чем файлопомойка спешно комплектуется парой SSD, iSCSI-target'ом и нарекается "системой хранения данных". Так как после установки SSD файлопомойка стала обладать достаточным функционалом (отказоустойчивый ФС с iSCSI) и производительностью (1000+ IOPS), возникла идея наконец-то сделать нормальный Hyper-V кластер вместо stand alone хостов без адекватной дисковой системы.
В силу ограниченности финансовых и аппаратных ресурсов 10Gb сети не предвидится, как и RDMA-capable сетевых адаптеров. Сделать надо на имеющемся железе или не сделать вообще. В резерве имеются два Intel® PRO/1000 CT сетевых адаптера. Сложились несколько схем организации сети хранения:
- В уже сложившейся конвергированной сети нарезаем еще одну сеть для iSCSI, выставляем минимальный вес пропускной способности на 50% (это около гигабита должно получиться) и запускаем.
- То же, что и в предыдущем пункте, только в хосты виртуализации доставляем те "резервные" сетевые адаптеры, т.е. получаем NIC Team из трех, а не двух гигабитных сетевых адаптеров на стороне хостов виртуализации. В файлопомойке все еще два адаптера, ну да и черт с ними.
- (вот тут я сам не понимаю, зачем я это придумал) Доставляем в хосты виртуализации "резервные" сетевые адаптеры, не включаем их в NIC Team. Получаем конвергированную сеть со стороны файлопомойки и отдельный гигабит со стороны хостов виртуализации.
- Правдами-неправдами выбиваем из начальства "двухголовую" сетевую карточку, втыкаем ее в файлопомойку, в хосты виртуализации втыкаем "резервные" сетевые адаптеры, соединяем все кроссовером. Так уж точно гигабит будет.
Вопросы:Во-первых, стоит ли игра свеч. Вместо старых беспокойств (отсутствие отказоустойчивости на уровне дисковой системы -- там нет рейда, отсутствие отказоустойчивости на уровне хостов виртуализации -- нет кластера) получаем новые, касающиеся производительности: возрастут ли задержки, хватит ли скоростей чтения/записи. В данный момент один из хостов виртуализации обменивается с диском 10мб/с, среднесуточные и пиковые метрики будут только утром.
Во-вторых, если все же стоит, какой способ организации сети хранения выбрать? И необходимо ли будет настраивать QoS еще и на коммутаторе?
С SAN и iSCSI в частности ранее дел не имел, нет ни опыта, ни толковых знаний, поэтому надеюсь на ваши советы.
Простой
Средний
