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

От одного NFS-сервера к резервному NFS-хранилищу

В настоящее время у нас установлено 6 физических хост-компьютеров с Proxmox VE. На этих хостах запущено несколько виртуальных машин. В основном Windows Server 2008 R2. Хосты представляют собой блейд-серверы Intel с центральным хранилищем RAID5 и имеют доступ к Intel Shared LUN. Центральное хранилище физически связано с одним из блейд-серверов и содержит все образы дисков виртуальных машин. Образы дисков этих виртуальных машин доступны для виртуальных машин через центральное хранилище NFS. Поскольку этот NFS-хост - это всего лишь одна машина, мы непреднамеренно создали единую точку отказа. Например, если NFS-хост не может запуститься по какой-либо причине, все виртуальные машины не смогут получить доступ к своим дискам и не будут работать.

Главный вопрос заключается в том, как и с помощью какого программного обеспечения преобразовать это местоположение NFS-хранилища в избыточное, возможно, синхронизирующееся с другим устройством хранения, не нанося никакого вреда существующим образам дисков ВМ. Это может быть отказоустойчивая система, когда один NFS-хост отключен, а другой NFS-хост берет на себя управление. Какое решение было бы оптимальным для устранения этого SPoF?

Резервный NFS (по сути, любой избыточное хранилище) нетривиально.
Планируйте потратить на это много времени (и капитала), если вы действительно хотите, чтобы все работало хорошо.

Обычно вам доступны два варианта:

Вариант 1. Купить резервные устройства хранения

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

Два основных преимущества этого маршрута заключаются в том, что он быстрый (вы получаете готовое решение, которое можно просто развернуть, следуя руководству), и он поддерживается (если у вас есть проблема, вы звоните поставщику и кричите, пока он не исправит ее).


Вариант 2. Собери сам

На этом сайте есть хорошая схема создания избыточного кластера iSCSI / NFS с использованием Debian Linux.. Это с 2009 года, но принципы верны.
Конкретные пошаговые инструкции по созданию такой среды выходят за рамки Server Fault, но я могу дать вам приблизительный обзор того, что вам понадобится:

  • Общее (или реплицированное) хранилище
    Чтобы обеспечить избыточность на уровне хранилища, вам необходимо, чтобы одни и те же данные были доступны из разных мест - либо путем их репликации в реальном времени, либо путем подключения всего к общему пулу дисков.
    SAN - это обычный способ удовлетворить требования к общему хранилищу. Это все еще единственная точка отказа, но когда вы кладете все яйца в одну из этих корзин, вы убедитесь, что это ОЧЕНЬ хорошая корзина.
    Репликация DRBD или ZFS может удовлетворить требования к реплицированному хранилищу, если вы выберете этот путь - это, вероятно, дешевле, чем SAN, и обе технологии разработаны до очень надежного состояния.
  • Множественные "интерфейсные" системы
    Теперь, когда у вас проработано хранилище, вам необходимо сделать его доступным через избыточные «интерфейсные» системы - это машины, на которых запущен сервер NFS (или все, что вы используете для обслуживания диска для клиентов).
    Вам нужно как минимум два, работающих с программным обеспечением высокой доступности / аварийного переключения, поэтому, если / когда вы потеряете один, другой может взять на себя управление. Переключение IP при отказе является здесь «простым» вариантом (если одно поле выходит из строя, другое принимает «живой» IP-адрес).
  • Несколько физических путей к хранилищу
    Всякая избыточность хранилища в мире вам не поможет, если все идет по одному проводу.
    Вам необходимо убедиться, что клиентские машины имеют несколько физических путей для возврата к внешним интерфейсам хранилища, иначе отказавший коммутатор оставит вас в той же ситуации единой точки отказа, из которой вы пытаетесь выйти.

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


Что вам нужно в любом случае

Тебе понадобится план тестирования * перед запуском в производство.
В идеале он должен быть у вас еще до того, как вы начнете сборку (знание того, от каких сбоев вы защищаетесь, поможет вам спроектировать свою систему).

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