Назад | Перейти на главную страницу

Варианты общего хранилища для кластера ESXi HA

Я ищу рекомендации по вариантам общего хранилища для поддержки кластера ESXi HA (обратите внимание, что я НЕ просить рекомендации по продукту / бренду / модели - я знаю, что здесь это противоречит правилам). я спрашивая для технология рекомендация.

Компания, в которой я работаю, - это небольшой бизнес. На данный момент у нас есть один HP DL380 G9 с DAS, с ESXi 6.0, на котором запущено наше специально разработанное приложение. Сейчас мы смотрим, как достичь HA / FT, используя наиболее экономичный вариант. Нам нужен HA / FT, потому что я - ИТ-команда из одного человека, и я часто бываю в разъездах, поэтому ручное переключение / восстановление не вариант.

Я понимаю, что нам нужно минимум 2 хоста ESXi (физический сервер) и общее хранилище для достижения HA / FT. Здесь, я думаю, становится интересно: даже самый дешевый массив хранения начального уровня, вероятно, окажется для нас излишним. Наши требования к емкости хранилища, вероятно, составляют около 200 ГБ, и мы не наблюдаем этого удвоения как минимум 5 лет. Тем не менее, нам нужно общее хранилище для HA / FT.

Поэтому был бы очень признателен за любые рекомендации по моим вариантам. Спасибо.

Общие примечания (поток сознания):

  • Считать действительно серьезно о том, что вы пытаетесь защитить.
  • Никто не использует VMware Fault-Tolerance. Ладно может быть кто то есть, но здесь слишком много ограничений, а вариант использования особенно узок.
  • Серверы более надежны, чем вы ожидаете, особенно при работе с такими качественными системами, как HP ProLiant. Другое дело Supermicro ...
  • Оцените реалистичные режимы отказа. Сервер HP ProLiant Gen9 не просто потерпеть поражение.
  • Вы можете столкнуться со сбоями отдельных компонентов, но внутренних резервов достаточно, чтобы изящно решить большинство проблем.
    • Серьезно, резервные источники питания, резервные вентиляторы, RAIDing внутренних дисков, встроенные сетевые адаптеры и адаптеры FLR редко выходят из строя.
    • Добавьте мониторинг МОТ, комплексные проверки работоспособности оборудования, и диапазон элементов, влияющих на время безотказной работы, сведен к отказам DIMM и проблемам системной платы.

Итак, теперь мы подошли к общему хранилищу. Общее хранилище становится точкой отказа, в зависимости от того, как оно устроено.

  • Что-то вроде MSA SAS-подключенный массив это вариант и может работать с VMware и двумя хостами. Вы можете купить их голыми и добавить необходимую емкость.
  • Установка без совместного использования была бы полезна в некоторых отношениях, но добавляет определенные сложности.
  • Существуют варианты гиперконвергенции, такие как VMware vSAN, то HPE StoreVirtual VSA или Виртуальная сеть хранения данных Starwind предложение.
  • В HPE VSA может быть бесплатным для хранения до 1 ТБ для вашей установки.
  • SAN начального уровня не так хороша, учитывая ваши требования к пространству. невероятно низкий.
  • Можно использовать одностороннее хранилище ... возможно, даже обычный сервер HP с ОС хранилища по вашему выбору (Linux, экспортирующий NFS, Windows Storage Server и т. Д.)
  • Я задокументировал и обрисовал Решение ZFS для Linux которые могут обеспечить двухголовое аварийное переключение и кластеризацию для хранения: См. https://github.com/ewwhite/zfs-ha
  • Другое решение, которое может ничего не делать с парой серверов, - это Zetavault.
  • Добавьте к этому репликацию Veeam на уровне виртуальных машин или что-то еще на основе массивов, и вы покроете 99% потенциальных проблем с хранилищем.

Но опять же, это зависит от вашего риска. Люди могут легко спуститься в кроличью нору высокой доступности ...

Хосты с двумя гипервизорами ... хорошо. Тогда вам нужны двойные коммутационные фабрики? Сложенные коммутаторы? Агрегация каналов с несколькими шасси (MLAG / MC-LAG)? Одна SAN с двумя контроллерами? Две SAN? Репликация SAN? Репликация ВМ? Репликация ВМ в разные хранилища?

У вас есть силовое разнообразие? Несколько PDU? Несколько ИБП? Поддерживается ли генератор сайтов?

Итак, что у вас осталось?

Я думаю, что лучше иметь несколько вариантов. Возможно, вам понадобится дополнительная помощь для покрытия. Задокументируйте решение достаточно хорошо, чтобы у клиента было несколько вариантов. Создайте модуль / сценарий аварийного восстановления или отключения системы.

Если ваша компания не может выдержать простоев пользователей, тогда вам подойдет VMware FT. Для реализации этой функции вам определенно потребуется какое-то общее хранилище. В этом случае я бы рекомендовал обратить внимание на решения программно-определяемого хранилища (SDS), которые все чаще используются для создания виртуализированных инфраструктур. При таком подходе вы можете виртуализировать локальные ресурсы физического хранилища ваших хостов ESXi и превратить их в полноценную виртуальную SAN. На ум сразу приходит VMware VSAN, но я хотел бы указать на несколько очень интересных альтернатив, которые должны быть намного дешевле для реализации в среде ESXi. Первый кандидат HPE VSA: хороший уровень функциональности и раздражающее требование третьего узла голосования для кворума. Да, я знаю, вы все еще можете использовать 2 узла, но если вас не устраивают простои, кворум просто необходим. Второй кандидат, напротив, имеет минималистичную аппаратную площадь всего с двумя физическими хостами вместе с набором функций, таких как кэширование, сжатие данных и т. Д. StarWind vSAN. Оба решения имеют бесплатные версии, просто проверьте и посмотрите, какую пользу они вам принесут.

Лучше всего вам подойдет технология «программно определяемое хранилище». Виртуальная машина, которая делает локально подключенные диски доступными для всех виртуальных машин, в идеале обеспечивая избыточность, позволяя использовать локальные диски на нескольких узлах одновременно (что позволяет вам потерять узел без потери всех ваших виртуальных машин). Поскольку мы не говорим о рекомендациях по продуктам, я оставлю все как есть. Это все еще зарождающийся рынок, но есть несколько устоявшихся вариантов, которые отвечают всем требованиям.