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