Вопрос или проблема
У меня есть многорегиональный кластер Kubernetes на голом металле, который использует Tailscale и flannel для межузловой сети. Для хранения я использую драйвер OpenEBS LocalPV ZFS CSI на двух конкретных рабочих узлах, каждый из которых настроен с 100 ГБ ZFS zpool. PersistentVolumeClaims (PVCs) и их объекты VolumeSnapshots, нативные для Kubernetes, создаются на одном из этих двух узлов, в зависимости от того, где запланирована работа (Pods).
Настройка выглядит следующим образом:
Workernode1: 100GB zpool, размещающий PVCs и снимки
Workernode2: 100GB zpool, также размещающий PVCs и снимки
Я убедился, что правильная маркировка узлов выполнена, чтобы PVCs привязывались к нужным узлам. Теперь я рассматриваю стратегию репликации. В случае сбоя одного узла или его недоступности я хотел бы, чтобы на другом узле была актуальная копия данных PVC и всех связанных снимков. Это позволило бы мне быстро восстановить рабочие нагрузки, указав на реплицированные данные на оставшемся узле.
В настоящее время я рассматриваю использование zrepl для выполнения инкрементных, периодических снимков и репликации на уровне ZFS, эффективно поддерживая наборы данных zpool1/replicated/… на каждом узле. Это будет происходить вне Kubernetes; zrepl будет работать на уровне хоста и обрабатывать создание снимков, репликацию и их хранение в соответствии с расписанием.
Мой вопрос: Является ли использование zrepl (или аналогичного инструмента репликации, родного для ZFS) вне Kubernetes рекомендуемым подходом для этого сценария? Существуют ли известные наилучшие практики, шаблоны или альтернативные решения, которые более глубоко интегрированы с Kubernetes, или используют снимки CSI напрямую для автоматизированной межузловой репликации?
Я не нашел встроенной функции репликации в драйвере OpenEBS LocalPV ZFS, и мне не известен оператор или контроллер, родной для Kubernetes, который бесшовно обрабатывает репликацию ZFS-объемов между узлами. Любая информация о том, как другие подошли к этой проблеме, или предложения по более интегрированному решению будут очень признательны.
Решение о том, чтобы полагаться на localpv, связано с задержкой. Я не могу полагаться на синхронную репликацию из-за этого.
Ответ или решение
Репликация PVC на основе ZFS, созданных с помощью OpenEBS LocalPV CSI: Стратегия аварийного восстановления
В вашем сценарии с многоуровневым, многорегиональным кластером Kubernetes на базе Bare Metal с использованием Tailscale и Flannel для кросс-узловой сетевой связи, задачей является создание надежного механизма репликации для PVC, чтобы обеспечить быстрое восстановление после возможного сбоя узла. Учитывая, что вы используете OpenEBS LocalPV с ZFS CSI драйвером и создаете PVC на двух специфических рабочий узлах, ваша задача заключается в обеспечении актуальности данных и их доступности на одном из узлов в случае сбоя другого.
Подход с использованием zrepl
Использование zrepl для периодического инкрементного снятия снимков и репликации ZFS — это разумное решение для ваших требований. Этот инструмент позволяет автоматически управлять процессом репликации на уровне файловой системы ZFS, что дает вам возможность:
- Создание мгновенных снимков:
zreplможет выполнять инкрементные снимки и репликацию данных, что позволит вам уменьшить объем хранимых данных и ускорить процесс. - Гибкость в настройки: Планирование задач репликации и управление ими можно настроить под ваши специфические требования по времени и частоте.
Масштабирование и еффективность
Ваше решение о выборе LocalPV объясняется необходимостью минимизации задержек, что делает синхронную репликацию нежелательной. Репликация на уровне ZFS в этом случае вполне оправдана, так как она не требует синхронности, а также позволяет избежать сетевых задержек, связанных с передачей данных между узлами.
Потенциальные риски
Тем не менее, важно учитывать потенциальные риски, связанные с использованием zrepl:
- Доступность данных: При использовании периодической репликации возможно несоответствие данных в случае сбоя. Следует учитывать, что данные между моментами репликации могут не соответствовать.
- Сложности в управлении: Несмотря на простоту интерфейса
zrepl, добавление еще одного инструмента может увеличить общую сложность управления системой.
Альтернативные стратегии и лучшие практики
Хотя использование zrepl является вполне приемлемым решением, вы упомянули, что не нашли встроенные функции репликации в OpenEBS LocalPV. Рассмотрите возможность интеграции следующих подходов:
-
Использование Kubernetes CronJobs: Вы можете создать CronJob в Kubernetes для запуска команд
zfs snapshotиzfs send/receiveдля создания снимков и их последующей репликации. -
Интеграция с другими решениями: Изучите возможность использования Kasten K10 или Rook, которые могут обеспечить более интегрированные подходы к резервному копированию и восстановлению с поддержкой ZFS.
Заключение
Ваш план по использованию zrepl для создания репликации PVC ZFS является основательным и оправданным с учетом специфики вашего окружения. Однако также стоит исследовать интеграцию с Kubernetes через CronJobs или использование специализированных операторов для резервного копирования, которые могут улучшить уровень автоматизации и управление данными. Перед принятием окончательного решения проведите тщательное тестирование выбранной стратегии, чтобы убедиться в ее эффективности и надежности в вашей инфраструктуре.