Windows Server 2012 Отказоустойчивый кластер Hyper-V + Активное/Активное решение для устройства хранения данных HA
mkswap /dev/cciss/c0d0p6
echo '/dev/cciss/c0d0p6 none swap sw 0 0' >> /etc/fstab
swapon -a
но я не знаю, как этого добиться без дорогостоящего стороннего программного обеспечения.
Что ж, допустим, что «дорого» - это 299 долларов США за узел IISC ( http://www.kernsafe.com/ HA ISCSI target, 2 узла, репликация) или бесплатно (с использованием некоторых из HA-материал доступен для Linux)
Кроме того - нет возможности для полной высокой доступности. Извините.
Вы можете легко построить недорогой кластер Hyper-V с использованием технологии VMware VSAN / Linux DRBD / FreeBSD HAST (стек виртуализации хранилища работает изначально на гипервизоре, а не внутри гостевой виртуальной машины, поскольку это медленно и шелушащийся). У StarWind Software есть эта версия, и начальный уровень даже бесплатен. См .:
http://www.starwindsoftware.com/native-san-for-hyper-v-free-edition
StarWind может даже построить SoFS без какого-либо физического внутреннего блочного хранилища (без SAS , без FC, без iSCSI, только недорогие диски SATA и Ethernet). См .:
http://www.starwindsoftware.com/sw-configuring-ha-shared-storage-on-scale-out-file-servers
Но опять же, это имеет смысл, только если вы хотите поиграть с SoFS и SMB 3.
Один на базе Windows, на который вы ссылаетесь, будет стоить 600 долларов + лицензии Windows (еще 1000 долларов). И для Windows, и для Linux вам придется добавить пару физических серверов для их запуска и пару сетевых коммутаторов. Весь проект обойдется в 4-5 тысяч долларов (одна Windows, Linux, конечно, дешевле). Это цена VNXe начального уровня или SAS JBOD от DataOn. Оба предоставят хорошую поддержку, а с решением для Windows, о котором вы упомянули, в основном нет поддержки («Сделано в Китае», компания, управляемая одним человеком), а Linux идет только с поддержкой сообщества. Не уверен, что "HA" и эти упомянутые проблемы хорошо сочетаются :)
Вы можете создать кластер SOFS для достижения этой цели. Серверная часть хранилища должна быть массивом JBOD SAS, например, решениями DataOn Storage . Это гарантирует, что хранилище будет запущено и работает даже при отказавшем узле в кластере SOFS, и когда оба узла будут работать, они будут представлять хранилище в активном / активном режиме.
Затем вы должны представить кластер SOFS хостам Hyper-V, используя протокол SMB3, в идеале на сетевых адаптерах 10 Гбит / с.
Я не стал точить цифры, но, по слухам, такого рода решения часто примерно вдвое дешевле. цена стандартного SAN и становится все более популярной.
В блогах есть много сообщений с подробным описанием различных вариантов, у Эйдана Финна много хороших .
SoFS имеет смысл, если вам нужен дешевый шлюз на базе Ethernet вместо дорогого для расширения хранилища SAS или FC. Допустим, у вас есть SAS JBOD или FC SAN. Имея всего пару хостов Hyper-V, вы можете легко поделиться этим хранилищем. Но если у вас больше узлов (3+), вам необходимо развернуть коммутаторы SAS и лицензировать еще 8+ портов FC. Так что с финансовой точки зрения имеет смысл оставить SAS и FC подключенными к паре окон Windows, конвертирующих DAS -> SMB 3.0 с концепцией SoFS.
См. Презентации MS - они всегда показывают ОГРОМНЫЕ фермы SoFS. Не зря: конфигурация SoFS с двумя узлами дорогая и медленная (DAS и FC напрямую быстрее, чем Ethernet). Так что ДА, вы можете делать SoFS. Но НЕТ, вам действительно не нужно делать это, прежде чем вам нужно будет передать общее хранилище как минимум в 4-узловой кластер Hyper-V: )
SoFS на самом деле не активен / активен, так как вам нужно несколько клиентов, поскольку рабочая нагрузка сервера распределяется на основе DNS: нет MPIO, как это происходит с FC или iSCSI.
Вы определенно можете построить кластер SoFS для этого. Хранилище бэкэнд должен быть массивом JBOD SAS, например DataOn Storage решения. Это гарантирует, что хранилище будет работать даже с вышедший из строя узел в кластере SOFS, и когда оба узла подняты, они будут текущее хранилище в активном / активном режиме.