Two-Node Server 2012 R2 Hyper-V Cluster: возможно ли использование локальных физических дисков в кластере?
Посмотрите на следующую статью TechNet о кластерных общих пространствах, и похоже, что это применимо только к хостам, совместно использующим корпус JBOD через внешнюю объединительную панель SAS.
Однако каждый хост в кластере с двумя узлами имеет одинаковое количество дисков SAS 15K (4), которые в настоящее время настроены как массив RAID 10.
Мне интересно, есть ли Hyper-V, эквивалентный технологии Virtual SAN VMWare, тогда как локальные диски могут быть представлены как кластерные узлы общего хранилища.
По сути, мы просто хотим использовать диски на хосте, а диспетчер отказоустойчивости кластеров, похоже, не хочет играть в мяч с локальными дисками в качестве цели для перемещения виртуальной машины. Было бы неплохо для обслуживания SAN иметь возможность перетасовывать виртуальные машины на локальные диски по мере необходимости.
4 ответа
Отказоустойчивые кластеры требуют общего хранилища. Без этого, если машина умирает, данные на них недоступны, и без этих данных невозможно перейти на другой ресурс.
Я не верю, что существует какой-либо встроенный отказоустойчивый метод использования локальных дисков. Для кластерных виртуальных машин вам необходимо общее хранилище, а внутренние диски не подходят.
Что вы можете сделать, особенно если это временно, пока вы выполняете обслуживание или обновление SAN, - это потерю отказоустойчивости. Если вы используете SCVMM, снимите флажок "Сделать эту виртуальную машину доступной". Если вы используете диспетчер отказоустойчивого кластера, удалите виртуальную машину из диспетчера кластера (она все еще будет существовать на физическом хосте). Затем используйте диспетчер Hyper-V, чтобы переместить его в локальное хранилище.
Когда вы делаете это, вы теряете отказоустойчивость - если физический хост умирает, любые виртуальные машины на этом хосте идут вместе с ним. Вы по-прежнему сможете использовать некластерную версию динамической миграции для перемещения их между хостами во время нормальной работы, но это также будет означать перемещение файлов на диске, поэтому это займет больше времени.
Когда вы закончите, переместите их диски обратно в общее хранилище и снова сделайте их высокодоступными.
Добавлять особо нечего, так как StarWind и HP VSA уже упоминались! Оба продукта обеспечивают большую ценность и делают именно то, что вы пытаетесь достичь.
Помните, что вы не сможете перенаправить виртуальные машины обратно в локальное хранилище, если оно уже выделено в качестве пула хранения для HP VSA или StarWind. Тем не менее, хранилище StarWind всегда доступно в режиме обратной связи, поэтому у вас есть доступ к виртуальным машинам даже во время обслуживания. Не уверен насчет HP VSA, для кластера необходим третий объект голосования, поэтому процесс обслуживания может стать более сложным.
Если у вас есть резерв места для перестановки виртуальных машин, вы можете использовать функцию Storage Live Migration с любым из доступных на рынке решений для хранения данных.
StarWind Virtual SAN - это почти все, что вам нужно. В отличие от самодельного решения под управлением ВМ, GregL упомянул, что именно это решение на 100% встроено в Hyper-V, так как это приложение для Windows: простое в установке и без проблем с исправлениями в ВМ. + производительность. Если у вас все в порядке с виртуальными машинами, взгляните на HP StoreVirtual VSA. Их бесплатная версия будет ограничена емкостью 1 ТБ и попросит третий автономный узел установить FOM (эквивалент свидетеля кластера Windows).
Я думаю, что ваш единственный способ сделать это - настроить собственную версию vSAN для домашнего использования с локально расположенными "контроллерами".
Что-то вроде этого или набор кластеризованных экземпляров FreeNAS / OpenFiler, работающих под управлением DRBD, должны справиться с этой задачей.
Я бы не стал полагаться на это для целей первичного хранения, но в крайнем случае он мог бы нормально работать, когда вам необходимо выполнить разрушительное обслуживание SAN и поддерживать несколько виртуальных машин в рабочем состоянии.