Дешевый сторадж для малого кластера виртуализации?
Приветствую уважаемый %username%! У меня задача поднять кластер виртуализации из двух серверов, чтобы виртуальные машины в случае падения или для административных нужд можно было с минимальной задержкой запустить на другом. Это значит сервера должны либо работать с одним общим стораджем, либо их раздельные стораджи должны синхронизироваться какой-либо репликацией. Я ранее уже поднимал конфигурацию с локальными винтами в каждом с ервере и DRBD синхронизацией. Подскажите имеет ли смысл отказываться от этого подхода и брать общий сторадж (shared storage, san) в условиях малого бюджета? Может у кого есть опыт использования распределённой файловой системы вместо блочной репликации?
В бюджете денег на нормальный SAN нету, да и нужно нам всего 8 винтов. Из общего железа возможен вариант полки с двумя подключениями SCSI (по одному на сервер, общий доступ требует использования кластерной файловой системы), либо какого-то самого бюджетного SAN. Как вариант — «самодельный» iSCSI/NFS сторадж на базе обычного сервера.
Подскажите пожалуйста ещё варианты дешевого общего стораджа или другие варианты кроме блочной репликации.
Кстати, поскольку в требованиях нет живой миграции, возможно, есть ещё более простые концепты?
UPD. Не очень принципиален выход из строя система на 10-15 минут, но единая точка отказа с риском долгосрочного выпадения (например единая полка дисков или единый сторадж сервер) критичны
В вашем варианте есть одна существенная точка отказа — сам сторадж.
Либо вы платите деньги за его большую надежность (два контроллера, две карточки iscsi или sas)
Либо вы платите за два стораджа умеющих active-active.
И то и другое — много денег.
В случае если вы поднимаете failover cluster (а по описанию — вы имено его и делаете) то вам в любом случае нужен внешний (по отношению к серверам) сторадж. Если денег нет — берёте машину, ставите харды, поднимаете iscsi target, заботитесь о бэкапе стораджа на внешнее хранилище, например ещё одна машина с iscsi target ;)
>> вам в любом случае нужен внешний (по отношению к серверам) сторадж
В чём преимущество внешнего стораджа? Только multipathing? Локальный сторадж реплицируемый между машинами (просто винты либо direct attached storage) работает вполне достойно. У нас нет требований по отказоустойчивости, только по быстрому фейловеру
Ну как бы есть вопросы в надежности такого решения. Если вы уверены что это надежно — что ж, можете делать, но лично я такое решение никогда бы не сделал и не брал бы на обслуживание.
Если вас устраивает производительность iscsi, то да, можно просто поднять две машины забитых дисками и организовать active-active программно.
По поводу внешнего и быстрого:
если у вас есть две машины виртуализации, то гонять виртуалки только на одной, в ожидании пока какая-либо виртуалка или сам сервер не сдохнет — просто глупо и расточительно. При двух хост машинах половина VM живет на Host1, половина на Host2; при сдыхании любого из Host — половина машин этого не замечает (т.к. живет на другом), половина поднимается на оставшейся ноде.
Бонус — возможность выделения гораздо больших ресурсов CPU и RAM пока всё нормально.
На одном серваке винты в зеркале. Если сервер сгорит винты перекинуть в соседий сервак.
Нет живой миграции, думаю и время преключения на резерв не регламентируется, тогда зачем кластер?
Если сложнее, то нужен стораж с контроллерами, прямое подключение к серверам, multipath. Для здач с 2-мя серверами SAN не нужен.
Вот о таком простом решении я совсем не подумал — просто кейдж с винтами переставить во вторую машину!
Кластер нужен только для минимизации времени восстановления при крахе виртуализации. Переставить корзину всё такие минут 20-60 занимает пока техник подойдёт, в фейловер кластере (работал с XenServer) 1-2 минуты и более менее автоматически
У вас, собственно, и есть самый дешевый вариант. Я не увидел, чем она вам не устраивает.
Единственный его недостаток — отсутствие бекапа на уровне ОС, потому как DRBD поблочно переносит все, в том числе и убитую ОС.
На двух серверах могу предложить такой вариант: отказ от DRBD, виртуалки работают на одном сервере, холодная репликация их на другой (раз в сутки, например). Программа репликации работает в виртуалке на резервном сервере. В случае выхода из строя основного сервера все, что потребуется — запустить реплики на резервном. Только это будет не кластер, задержка запуска будет минимальной, некоторая потеря актуальности данных.
Простой
Средний
