Типичное инфраструктурное решение для SMB сейчас это несколько хостов с установленными гипервизорами и некий вариант Shared Storage для возможности кластеризации. И чаще всего эта схема выглядит как пара, тройка хостов подключенных к NAS по iSCSI. Hyper-v сейчас работает по SMB 3.0, и что то там можно накрутить с Clustered Shared Storage в среде Microsoft, что должно по идее дать много плюшек вместе с Storage Spaces. Но сейчас не об этом, я пока не игрался :). Традиционно люди закупают NAS'ы для этих целей или полки с подключением по SAS.
В очередном проекте возникла задача построения кластеров на имеющемся оборудовании, и при этом никаких СХД не было в наличии. Первым решением было поднять на одном из серверов хранилище и завязаться на него. Поскольку сервера были HP, в ходе обновлений прошивок наткнулся на интересное решение - HP StoreOnce VSA.
Уже потом выяснил что для пользователей VMWare даже есть родные решения такого же плана vSAN и еще что то. И что на рынке сейчас много подобных решений StarWind, Nutanix. Технологии имеют маркетинговый шильдик "Гиперконвергентность". Касательно HP StoreOnce все работает - проверено. Оно до 1ТБ еще и бесплатное теперь, при этом работает не только на серверах HP! А в SMB шансов уместить в 1-1,5 ТБ важные виртуальные машины как раз много.
Суть в том что сервера сами себе СХД, причем распределенное, отказоустойчивое СХД. Берем дисковое пространство, отдаем его в некий общий пул, а потом подключаемся к этому же общему пулу и получаем из него нужное нам пространство.
Решение HP VSA StoreVirtual предоставляемое компанией HP совместно с Intel сроком на 3 года, ограниченное 3мя нодами хранилища и 1 террабайтом дискового пространства на каждой из нод. В результате внедрения получаем общее дисковое пространство до 1,5 Tb (доступное для использования), подключаемое по iSCSI к хостам гипервизоров, используемое для целей создания отказоустойчивого кластера Hyper-V.
На аппаратном хосте создается дисковый аппаратный RAID уровня 10. На нем располагается диск VHDX, который предоставляется виртуальной машине HP VSA. Несколько таких виртуальных машин в свою очередь формируют виртуальную SAN. Сформированные в виртуальной SAN диски предоставляются тем же аппаратным хостам (или любым другим) по iSCSI. На подключенных таким образом дисках гипервизоры могут создавать отказоустойчивые решения (кластеры), как в рамках целей виртуализации, так и в рамках кластерных решений БД, приложений и пр. Чуть позднее вычитал где то что лучше отдавать не готовый VHDX, а выделенный логический диск сформированный Raid контроллером (ну или LUN). Мы же мигрировать виртуальную машину с хранилищем не будем.
Синим выделены виртуальные машины HP VSA; черным – аппаратные хосты гипервизор; оранжевым – виртуальные машины.
Решение не требует дополнительных расходов на лицензирование и задействует имеющееся аппаратное обеспечение. Масштабируется путем лицензирования дополнительных опций, дискового пространства. Либо путем добавления аналогичных решений (копирования решения). Возможно использование аналогичного решения в географически распределенных системах (MultiSite), обеспечивающих работоспособность сервисов при выходе из строя одной из серверных комнат. Но тут не пробовал, при бесплатных 3х нодах как построить такое - не знаю.
Можно построить на двух, но тогда нужен некий третий сервер, который будет определять - кто из серверов VSA живой, а кто нет в случае конфликта. Третий требует минимальных ресурсов, почти ничего.
Возможно масштабирование увеличением количества нод, но это уже лицензии нужны.
Много вопросов возникло при планировании решения, при тестировании. Как что лучше настроить, подключить. В качестве примера - схема подключения.
В самой СХД участвуют только первые три сервера, четвертый в данном случае не содержит общего пространства. Но подключен к iscsi vlan и может использовать общее хранилище. Суть в том что для подсистемы хранения (виртуальных машин StoreOnce VSA) выделяем отдельные сетевые интерфейсы. Два, поскольку хотим иметь агрегацию и отказоустойчивость. Подключаем к двум коммутаторам. А коммутаторы связываем между собой агрегацией. Можно все в один коммутатор, тогда коммутаторы практически не нужно настраивать. Вся настройка будет заключаться в выделении для СХД подсети отдельного Vlan. Пакеты дальше этих коммутаторов лучше не гонять, ибо латентность.
Дьявол в деталях, так что на самом деле эта схема ошибочна.
Тиминги интерфейсов VSA делать не умеет!!! Так что тиминг нужно делать силами гипервизора (vSwitch)
На серверах в данном случае всего 4 интерфейса сетевых, а нужно 6! Потому что лучше отдать VSA пару интерфейсов для своих нужд (и сделать тиминг на уровне Hyper-v), дать самим Hyper-v пару интерфейсов для подключения к хранилищу по iSCSI (уже без тиминга, т.к. здесь уместнее MPIO), и для виртуальных машин тоже нужно что то выделить. С трудом можно совместить траффик VSA и iSCSI на одних и тех же интерфейсах, но в этом случае либо не будет Teaming для VSA, и VSA будет использовать только 1 интерфейс, либо MPIO не использовать. В общем - лучше 6.
Гиперконвергентные решения в SMB скорее всего будут обходить по соотношению цена/производительность и цена/емкость и всем кому грозит апгрейд СХД или просто планируется покупка - стоит посмотреть в эту сторону. Конкуренция на этом рынке сейчас есть, есть из чего выбрать.
No comments:
Post a Comment