Вопрос или проблема
Я еще никогда не использовал GlusterFS, как и многие другие техники, которые планирую освоить, поэтому прошу отнестись с пониманием! Я благодарен за конструктивные советы. До недавнего времени у меня были две Linux-машины, дублирующие свои диски с помощью DRBD. Pacemaker/Heartbeat отвечал за запуск LVM и LXC-контейнеров на любой из них и их переключение. Контейнеры всегда работают на одном хосте, поэтому конкурентного доступа к данным нет. Недостаток в том, что каждой машине требуется достаточно емкости для хранения данных обеих машин. Внезапное наводнение уничтожило серверную комнату, и пришло время обновить характеристики, так как объем данных начал превышать доступный размер диска. Это ни в коем случае не огромный сайт, всего менее 20 ТБ. Я мог бы приобрести SAN и два новых сервера с большим объемом оперативной памяти, которые соединяются через fiber channel. В принципе, это все, что нужно, чтобы все запустить и функционировать, но я хочу достичь следующего:
переключение LXC-контейнеров с одной машины на другую.
актуальные версии данных на SAN, хранящиеся на локальных дисках.
Начиная с 2, каждая машина имеет разумное количество хранилища, а SAN имеет достаточно для обеих. Итак, моя идея – настроить репликацию GlusterFS на каждой машине для синхронизации дисков с соответствующими LUN на SAN. Насколько я понимаю, GlusterFS обычно не настраивается через fiber channel, так как это похоже на локальное хранилище, и в принципе это не имеет смысла для репликации. Однако я читал где-то, что это можно принудительно осуществить. Может кто-то подтвердить? Если это так, то кластер переживет потерю любой машины, будь то сервер или SAN, что и является моей основной целью. Что касается 1, я представляю, что контейнеры с машины A мигрируют на машину B и получают доступ к своим файлам через GlusterFS с SAN, пока машина A недоступна. Как только A снова становится активной, контейнеры можно вернуть на A, и GlusterFS должен будет заново синхронизировать локальные диски с SAN. Это кажется довольно очевидным, но я был бы благодарен, если кто-то сможет это подтвердить. Кроме того, есть 3: В другой части здания у меня есть две старые машины с HBA для fiber channel, которые я хочу использовать для восстановления после аварии. Я могу увеличить их хранилище с помощью более больших, но медленных дисков, чтобы достичь нужной емкости. Они должны пробуждаться каждую ночь и выполнять георепликацию (“резервное копирование”) данных кластера. Опять же, мой вопрос: возможно ли подключить хост георепликации через fiber channel. Я также рассматривал возможность традиционного резервного копирования, что может иметь больше смысла. Любые предложения? Не стесняйтесь комментировать, если видите лучшие варианты. GlusterFS просто был единственным, что пришло мне в голову при поиске репликации через fiber channel. Я хорошо знаком с DRBD, и он не работает через fiber channel.
Ну, оба варианта, которые вы упомянули, действительно не самые лучшие… Позвольте мне объяснить, почему!
GlusterFS
Он переживает свои последние дни, так как IBM/Red Hat прекратили его поддержку, и он теперь официально прекращен. Вы можете проверить статус на веб-странице проекта. https://access.redhat.com/support/policy/updates/rhs GitHub тоже не выглядит обнадеживающе… https://github.com/gluster/glusterfs/issues/4298 Может показаться, что GlusterFS еще жив, но это, по сути, зомби, ходячий мертвец на данный момент. Команда была расформирована и перемещена на другие проекты IBM/Red Hat, и количество коммитов быстро сокращается. Очень скоро он начнет показывать свой возраст, оставляя вас с нерешенными проблемами, нерассмотренными pull-запросами и отсутствием поддержки. Мы уже видели этот шаблон с RHEV/oVirt. Вывод: плохо вкладывать свои усилия в этот вариант, так как вам придется искать замену раньше или позже.
DRBD
DRBD известен проблемами со стабильностью. Хотя версия 9 значительно лучше версий 7 и 8, все равно она страдает от потери кворума, разделенного мозга и сопутствующей порчи данных. В целом, она слишком нестабильна для использования в производственных условиях. Есть множество руководств в интернете по “решению” этой неприятной ситуации. https://xahteiwi.eu/resources/hints-and-kinks/solve-drbd-split-brain-4-steps/ https://www.suse.com/support/kb/doc/?id=000019009 https://www.recitalsoftware.com/blogs/29-howto-resolve-drbd-split-brain-recovery-manually https://support.sciencelogic.com/s/article/1259 https://www.ipserverone.info/knowledge-base/how-to-fix-drbd-recovery-from-split-brain/ К сожалению, ничто из этого не поможет, если вы неверно прочтете метки времени и назначите неправильный мастер… В этом случае ваши новые данные будут стерты, а старые перезапишут их, если вы сможете избежать полной порчи данных, что еще более распространено. Кроме того, LinBit, компания за DRBD, имеет долгую историю изменения лицензионных условий с открытым исходным кодом, что является серьезным сигналом тревоги в сообществе. На практике это может означать, что вы останетесь с устаревшим, неподдерживаемым ПО, потому что обновление требует либо оплаты, либо соблюдения новых ограничений. https://forum.proxmox.com/threads/drbdmanage-license-change.30404 Это проблема, которая уже стала причиной упадка нескольких ранее популярных проектов с открытым исходным кодом. Вы можете найти интересным историю CDRECORD. https://lwn.net/Articles/346540/ В итоге: хотя DRBD может быть полезен для лабораторных условий и прототипирования, надежность его в производственной среде крайне сомнительна. Итак.. Что вы можете действительно сделать? Вот несколько альтернатив, которые хорошо работают.
ZFS
Да, вы можете использовать репликацию ZFS. Делайте снимки ZFS и настраивайте send/recv на другой хост. Хотя это не синхронная репликация, и вы можете потерять некоторые данные при сбое, снимки являются консистентными при аварии. Кроме того, если вы скриптируете ваши контейнерные приложения для намеренного завершения работы, вы можете полностью избежать потери данных. Вот как это настроить. https://docs.oracle.com/cd/E18752_01/html/819-5461/gbchx.html Многие сейчас используют ZFS! Заключение: если ваши требования RTO/RPO не слишком жесткие, и вы готовы написать несколько скриптов для управления вашей средой LXC, этот подход является высоконадежным и широко используемым.
Ceph
Ceph – другой вариант, и хотя он также связан с IBM, он активно поддерживается и улучшается. IBM делает ставку на Ceph как на свое программное обеспечение для хранения, интегрируя современные транспортные протоколы, такие как NVMe/TCP, чтобы заменить более старые протоколы, такие как iSCSI, и проводя недавнюю сертификацию VMware. Ceph требует как минимум трех узлов, но вы можете запустить два узла с OSD и MON службами, оставив третий узел как MON-только свидетель для кворума. Вот несколько ссылок для начала работы с Ceph в контейнеризованных средах. https://docs.openshift.com/container-platform/3.11/install_config/persistent_storage/persistent_storage_ceph_rbd.html https://forum.proxmox.com/threads/best-practices-for-setting-up-ceph-in-a-proxmox-environment.148790/ https://forum.proxmox.com/threads/using-ceph-to-host-lxc-containers.58386/ Вывод: Ceph является сильным претендентом на звание отраслевого стандарта высокодоступного решения для хранения данных для контейнеров Linux. IBM сосредотачивается на его использовании в корпоративных сценариях, в то время как Proxmox делает его доступным для малого бизнеса и любителей. Надеюсь, это прояснит проблему, с которой вы сталкиваетесь!
Чтобы подытожить требования: 20 ТБ на 1 хосте, желается отказоустойчивость одного хоста. Пару более старых хостов доступно для плана обеспечения непрерывности бизнеса. Нет приверженности к использованию общей системы хранения. Идеально бы резервное копирование фиксировало неизменяемые точки во времени в другой системе хранения защиты, отличной от операционной системы. Как последняя линия защиты данных, недопустимо, чтобы ошибка или баг на основном кластере хранения уничтожили резервные копии. Возможно, программное обеспечение для резервного копирования, которое отправляет блобы в объектное хранилище, на некоторых из этих дисков, а возможно с архивированием в облачное и оффлайн хранилище. Необходимо, по крайней мере, отделить систему хранения защиты на независимые физические и логические объемы. Сначала нулевая гипотеза для использования технологий репликации хранилища: упростить, не используя их. Один хост, один массив дисков. Иметь наготове другие компоненты как холодные резервные копии. Востанавливать данные из резервных копий. Хотя это просто для реализации, в нескольких сценариях это может привести к часам простоя. Теперь перейдем к более сложным проектам хранения. Слишком мало узлов для распределенного хранилища, как gluster или ceph. Они начинались как большие, распределяя данные по целым стойкам хостов, с сопутствующей сложностью раздельного управления и передачи данных. Теоретически, их можно уменьшить до 3 или 4 узлов, но вы рискуете потерять обещания по доступности с небольшим кластером. И вам понадобятся несколько дополнительных узлов для кластера резервного копирования, чтобы он мог быть независимым. Что касается распределенного хранения. Очевидная сфера его применения – это массовое оборудование, где у вас есть множество небольших серверов с несколькими локальными дисками каждый. Избыточность достигается полосным распределением данных на многих хостах с помощью IP-приложения; данные всегда имеются, даже если хост выходит из строя. Хотя можно использовать SAN с FC LUN, в этом нет необходимости, когда уровень хранения уже является многосерверным. Gluster по IP, файловая система brick, LVM, FC SAN LUN, SAN массив, это довольно много уровней и две сети. В категории репликации дисков как блочных устройств, DRBD – выбор с открытым исходным кодом. Возможно, у вас есть с ним некоторый опыт. Он не масштабируется для очень большого количества хостов, но это не проблема при таком размере. На своем типичном месте, как часть HA-кластера, поддержание целостности данных – деликатная операция, так как необходимо обеспечить репликацию блоков, даже в условиях отказа, без знания уровня файловой системы выше. Блочная репликация подобной нет хорошим резервным копированием, также необходимо хранить неизменяемые временные точки. Репликация на значительное расстояние также может вызвать проблемную задержку. Для полноты, похоже, LINBIT предлагает нечто под названием LINSTOR как управляющую плоскость для DRBD, LVM, ZFS и нескольких других технологий хранения. Это может быть кандидатом, если вы хотите автоматизировать множество томов, например, с интеграцией Kubernetes. Довольно много сложности, однако. Общая система хранения не была в вашем плане, но вы можете с ней построить кластер. Из массива хранения представьте несколько LUN через FC может быть на 3 хоста. Кластерное программное обеспечение отвечает за перемещение дисков при отказе вычислительного хоста. Несколько недостатков. Одна копия данных, необходимо дополнительное реплицирование в другом месте, если это требуется сверх внутренней избыточности массива. Плюс отдельные резервные копии. Ресурсы файловой системы, созданные вручную, могут быть не идеальны для многихиртуальных машин и контейнеров, которые вы имеете в виду. Существует уровень репликации файловой системы, который может перемещать специфические тома между неразделяемым хранилищем. В частности, репликация ZFS. Proxmox оборачивает zfs send и zfs recv для обеспечения репликации на гостевом уровне по расписанию. Как метод резервного копирования, zfs send очень хорош. Независимый резервный пул. Специфические точки во времени. Проверки целостности данных ZFS. Это не в реальном времени, поэтому если вам нужна репликация с точностью до секунды, возможно, стоит что-то другое выбрать.
Ответ или решение
Понимание и управление репликацией и обеспечением высокой доступности данных — это ключевой аспект любой ИТ-инфраструктуры, особенно когда речь идет о критически важных приложениях, работающих в виртуализированной среде. Ваша задача по модернизации системы после стихийного бедствия и переходу к более масштабируемым и надежным решениям заслуживает детального рассмотрения подходов, доступных на сегодняшний день.
Теория
Первоочередной вопрос заключается в выборе подходящей технологии для репликации и обеспечения отказоустойчивости. Ранее вы использовали DRBD совместно с Pacemaker/Heartbeat для управления контейнерами LXC на двух Linux-серверах, что позволяло обеспечить одноранговую репликацию данных между серверами. Однако известные недостатки DRBD, такие как проблематичная работа с потерей кворума и возможная коррумпированность данных в ситуации split-brain, делают это решение не лучшим выбором для продакшн-систем. Тема использования GlusterFS также вызывает обеспокоенность из-за прекращения его поддержки со стороны IBM/Red Hat. Таким образом, становится актуальным поиск альтернативных решений, которые предоставляют надежность и поддерживаются сообществом.
Пример
В качестве альтернативы рассмотрим ZFS и Ceph — два популярных и активно поддерживаемых решения, предлагающих разные подходы к управлению данными.
ZFS — это файловая система и менеджер томов, известный своими возможностями хранения и репликации данных. Он поддерживает создание снимков (snapshots) и их репликацию с использованием команд zfs send и zfs recv, что позволяет реализовать плановые резервные копии или асинхронную репликацию для защиты от потери данных. Хотя ZFS не предоставляет синхронной репликации, его снимки являются согласованными по состоянию системы на момент их создания, что делает его вспомогательным инструментом для резервного копирования и восстановления данных.
Ceph — это распределенная система хранения, обеспечивающая высокую доступность и масштабируемость данных. Ceph использует объектное хранение и может работать в кластерной конфигурации, обеспечивая репликацию и устойчивость к отказам. Он хорошо интегрируется с контейнерами и виртуализированными средами, такими как OpenShift или Proxmox. Требования к кластеру в виде трех нод (две ноды для хранения и мониторинга, одна нода для мониторинга) обеспечивают кворум и надежность.
Применение
Таким образом, рекомендую рассмотреть сценарии внедрения каждой из технологий в вашу архитектуру:
-
ZFS:
- Организуйте репликацию ZFS между вашими новыми серверами и резервным сервером для обеспечения резервного копирования. Настройте ежесуточное создание снимков и их репликацию на резервный сервер, что позволит избежать потери данных при сбоях.
- Напишите скрипты для управления LXC-контейнерами, чтобы обеспечить их мягкое завершение до создания снимков, минимизируя риск потери данных в случае сбоя.
-
Ceph:
- Разверните кластер Ceph на двух новых серверах и одной из существующих машин для обеспечения мониторинга. Это решит вашу задачу о переносе контейнеров между серверами, так как данные будут доступны на обоих серверах одновременно.
- Используйте Ceph для управления данными LXC-контейнеров, что также упростит их миграцию между серверами.
Кроме того, для реализации задачи 3 (георепликация и резервное копирование), можно рассмотреть традиционные методы резервного копирования. Используйте ПО для бэкапа, которое создает "снимки" данных и хранит их в облаке или на удаленных серверах, что минимизирует риск одновременной потери данных и резервных копий.
В заключение, стоит отметить, что хотя GlusterFS и DRBD могут показаться очевидными выборами, их недостатки и ограниченная поддержка делают их менее привлекательными в вашей ситуации. ZFS и Ceph представляются более современными и гибкими решениями, которые смогут обеспечить надежность и отказоустойчивость в долгосрочной перспективе.