В университете из Уругвая, где я работаю, у нас есть 2 IBM BladeCenter S с 4 блейд-серверами каждый. На каждом блейд-сервере установлен и работает XenServer 6.2.
Наша идея состоит в том, чтобы каждый BladeCenter находился в разных (подключенных) сборках, чтобы иметь возможность переключения при отказе.
В каждое шасси BladeCenter встроено хранилище оптоволоконных каналов, и я заранее не знаю, как совместно использовать это хранилище с другим шасси BladeCenter.
Кроме того, я знаю, что способ общего хранилища не самый лучший, потому что он реализует единую точку отказа ...
Итак, мне нужно найти способ обеспечить высокую доступность с помощью XenServer 6.2 без общего хранилища. я нашел http://www.halizard.com/, но я хочу знать другие альтернативы высокой доступности без общего хранилища.
Еще одна вещь, о которой я могу думать, - это если бы я мог зеркалировать хранилища по сети (с iSCSI) и использовать несколько путей для целей iSCSI как 1, или иметь многопутевые iSCSI и Fibre Channel (но я не знаю, существует ли это). Если это возможно, реализация XenServer HA будет работать.
Надеюсь, мы сможем мне помочь!
Привет, вы можете попробовать Xen DRBD для достижения высокой доступности без общего хранилища ...
http://www.drbd.org/users-guide/ch-xen.html
https://github.com/locatrix/xs-pacemaker
-Как это
Если вы подключите достаточно локального хранилища, вы можете создать собственное решение iSCSI HA.
Рецепт: - drbd> 8.2.x - tgtd
Настройте две локальные виртуальные машины, которые реплицируют два LV друг на друга в двойном первичном режиме drbd. Используйте каждую локальную цель iscsi. На XEN-сервере обязательно используйте eacch target в активном / пассивном режиме (без rr!).
При выборе решения высокой доступности вам необходимо решить, какой уровень простоя (если таковой имеется) является приемлемым. Это повлияет на сложность вашей настройки.
Думаю, у вас есть два варианта без покупки дополнительного оборудования (с дальнейшими перестановками):
Для настройки максимальной доступности без общего хранилища вам придется использовать DRBD в роли «первичный-первичный». Это потребует, чтобы устройство STONITH отключило не отвечающий узел. Устройства резервного питания от батарей на базе IP обычно могут эффективно справляться с этой функцией. Pacemaker и corosync могут обрабатывать запуск виртуальных машин и управлять ресурсами.
Плюсы в том, что вы можете выполнять динамическую миграцию и теоретически исключить простои.
Минусы этой настройки в том, что если произойдет разделение мозга (а это произойдет), его может быть сложно исправить, поскольку данные могут существовать на обоих узлах.
В качестве альтернативы, если вас устраивает несколько минут простоя, мы запускаем вот что:
По сути, у нас есть два пула хранения LVM поверх двух массивов MDADM Raid 1. Они экспортируются в DRBD для репликации на уровне блоков. Затем вы добавляете LVM поверх DRBD, чтобы сделать снимки виртуальных машин и прямой доступ файловой системы к виртуальным машинам. Почему два?
Первоначальная идея заключалась в том, чтобы создать ресурс DRBD для каждой виртуальной машины, чтобы машины можно было перемещать между хостами в зависимости от нагрузки и не допускать простоя одного хоста. Администрирование было затруднительным, поэтому два ресурса DRBD по 200 ГБ каждый были хорошим компромиссом. Таким образом, r0 может быть основным на node1, а r1 может быть основным на node2. Если node1 выходит из строя, мы запускаем наш сценарий «make master» на node2, и он обрабатывает сопоставления LVM, устанавливая DRBD как первичный для этих ресурсов и сообщая virsh о запуске всех узлов. На SSD-массиве я могу отключить дюжину виртуальных машин и подключить их к node2 примерно за 2-3 минуты.