Варианты локального хранения для Kubernetes homelab [закрыто]

Я думаю, у меня проблема XY, если вы можете определить её как таковую, пожалуйста, ответьте соответствующим образом!

Предыстория

Моя главная цель — изучение Kubernetes, а второстепенная цель — домашние лабораторные эксперименты — хостинг различных небольших сервисов для кого-то, кто должен больше времени проводить на улице. У меня есть кластер coolberetes homelab, работающий на K3S, несколько рабочих узлов, управляющий узел, работающий на «картофельном» кластер-менеджере, и QNAP NAS для хранения.

На QNAP установлено 8 дисков объемом 12 ТБ с 7200 об/мин в конфигурации RAID-6. Он отлично подходит для поддерживаемых передач, но случайный ввод-вывод приводит его в ступор. Это ожидаемо из-за режима работы и аппаратного обеспечения. QNAP подключён к 10-гигабитному коммутатору, с портами 2.5/1 гигабит к рабочим узлам, так что пропускной способности не так много, но я думаю, что этого будет достаточно для моих нужд. У каждого узла есть локальный NVMe диск на 1 ТБ, что, как я думаю, будет важно позже.

Проблема

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

Большинство контейнеров разделены на два “класса” томов: data, config. Тома data — это большие объемные файлы с последовательным доступом. Их я обрабатываю через NFS/SMB тома, и это работает нормально. Тома config включают такие вещи, как несколько YAML-файлов, один-два JSON-файла, некоторые папки журналов, база данных SQLite и т. д. Эти тома работают гораздо хуже при монтировании через NFS, а базы данных SQLite полностью выходят из строя из-за проблем с блокировкой.

Обходные решения и причины их отклонения

• “Поместите тома config на NFS” — SQLite вызывает сбои из-за ошибок блокировки. Это v3 и v4.
• “Прекратите использовать SQLite” — Софт в образах жестко запрограммирован на его использование. Переписывание кода невозможно.
• “Просто поместите эти тома config на локальный диск” — как чисто локальные тома позволяют мне мигрировать или масштабировать любые сервисы?
• “Поместите кеши на NAS” — QNAP не позволяет добавлять кеши записи по глупым причинам.
• “Используйте rsync для синхронизации тома” — да, это было сделано, сработало “неплохо”, но я сомневаюсь, что это официальное решение.

Ожидаемое решение

Здесь, как мне кажется, находится моя проблема XY, или, по крайней мере, полное отсутствие знаний. Я ожидаю, что существует способ воспользоваться 1ТБ NVMe дисками на каждом рабочем узле, с блочным хранилищем, экспортируемым через NAS, в виде распределенной или кластерной файловой системы. Я бы ожидал, что могу смонтировать эту распределенную/кластерную файловую систему локально, чтобы контейнеры работали с ней, и в фоновом режиме она будет синхронизироваться среди работающих узлов и обратно на QNAP для резервного копирования. Для моих целей файловая система на 1 TiB подойдет для моих нужд в config томах.

Если такое решение существует, как оно называется и где я могу узнать больше?
Если это неправильное решение, то какое “правильное”?

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

Отказ от ответственности: Я еще не настроил это, но я провел все исследования и готов осуществить это, как только у меня будет несколько часов свободного времени. Насколько я понимаю, Longhorn будет управлять репликацией и синхронизацией физических данных в точности так, как вы описали, и поддерживает NFS/SMB как целевой бэкап.

Единственное, что меня беспокоит в этой настройке, — производительность: Как я уже сказал, я еще не настроил это, поэтому я не знаю, как это получится на практике, но я знаю, что Longhorn выполняет синхронную репликацию (всё должно быть записано на репликах до того, как операция записи будет считаться “завершенной”), поэтому это определенно будет медленнее, чем чисто локальный NVMe. Насколько медленнее, пока предстоит узнать, но я думаю, что это не будет проблемой для вас, особенно при 10-гигабитной сетевой связи, поскольку вас не беспокоили, например, производительность SQLite через NFS, только проблемы с согласованностью.

Я постараюсь не забыть опубликовать обновление здесь, как только это будет настроено (планирую сделать это на этой неделе). Я постараюсь провести некоторые базовые тесты производительности на локальном диске и с Longhorn.

К вашему сведению, Longhorn — не единственный вариант, который у вас есть. Другие названия, которые всплыли в ходе моих исследований, включают Piraeus и Linstor, но я не проводил много исследований по ним, поэтому не знаю, как они сравниваются.

Редактировать: Результаты тестов

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

Я провел 3 теста (ну, 6, потому что я тестировал чтение и запись отдельно) для каждой конфигурации, которую я тестировал. Тесты были следующими:

• Максимальная пропускная способность: 4MiB чтений/записей из одного процесса с глубиной очереди 16
• Максимальное число операций ввод-вывод в секунду (IOPS): 4к случайных чтений/записей из 16 параллельных процессов, каждый из которых выполняется с глубиной очереди 16 (то есть 256 операций одновременно)
• Попытка эмулировать более “реальную” рабочую нагрузку для обсуждаемой ситуации: 4к случайных чтений/записей из одного процесса с глубиной очереди 2. Моя цель в этом — подражать, например, слабо загруженному веб-приложению на основе SQLite (который по умолчанию использует страницы размером 4к, если я правильно помню.)

Я провел эти тесты в следующих ситуациях:

• Напрямую против локального диска, без виртуализации
• Против того же диска, но смонтированного в поде с hostPath
• Против того же диска через Longhorn с 1 репликой
  • Из локального пода (работающего на той же ноде, что и реплика)
  • Из удаленного пода (работающего на другой ноде, чем реплика)
• Против того же диска через Longhorn с 2 репликами (у меня в кластере в данный момент всего 2 ноды, так что тестировать 3 реплики было бы не очень значимо.)

Сервера работали на процессорах Epyc 7262 (8c16t), 64 ГБ ОЗУ и были подключены через 10GbE. Тестируемые диски были SK Hynix Platinum P41 (с оценкой 7000 MiB/s на чтение, 6500 MiB/s на запись, и ~1.5M IOPS)

Таблицы немного запутанные, поэтому для ясности, строки представляют собой конфигурации хранения (например, тестирование непосредственно против диска по сравнению с тестированием через Longhorn или что-то еще), а столбцы представляют рабочие нагрузки. Колонка “BW – R” относится к нагрузке чтения для максимальной пропускной способности, колонка “IOPS – W” относится к нагрузке записи для максимального числа операций ввод-вывод в секунду, и так далее.

Результаты – Пропускная способность (MiB/s)

IOPS

Задержка

Примечание о задержке: Я использую среднее значение lat, которое производит fio, и которое, насколько я знаю, относится ко времени с момента, когда операция отправлена, до момента, когда чтение/запись завершается. Поэтому оно так высоко в сценариях максимальной пропускной способности: они 1000х больше, чем операции на 4к, так что они наверняка займут немного больше времени.

Выводы:

Как ни крути, вы жертвуете много производительности по сравнению с тем, что вы получаете, работая с локальным диском без виртуализации.

Но я не уверен, что это имеет значение! Особенно если мы посмотрим на IOPS и показатели задержки для «легкой» рабочей нагрузки, мы можем увидеть, что мы все еще получаем >1k IOPS, и эти операции завершаются в <1 мс. На мой взгляд, этого достаточно для повседневного использования. Если базе данных вашего веб-приложения нужно будет несколько раз обратиться к диску для обработки запроса, вы все равно не заметите разницы, потому что все, что занимает меньше 1 мс, абсолютно заслоняется сетевой задержкой.

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

Longhorn работает над V2 своего механизма хранения, который, как они утверждают, “значительно уменьшает задержку ввода-вывода, одновременно увеличивая IOPS и пропускную способность,” но он все еще находится на стадии активной разработки и пока не поддерживает важные функции, такие как моментальные снимки и резервное копирование. Может быть, когда он будет выпущен, я обновлюсь и пересниму эти тесты.

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