Обзор гипервизора Harvester 1.3.0
В процессе поиска подходящей платформы для того, чтобы инсталлировать Kubernetes у себя дома, я эксперементировал с разными вариантами. В этой статье — делюсь опытом работы с этой системой.
Что такое Harvester? Официально — A Cloud Native Open Source Hyper-converged Infrastructure. Если попробовать сказать простыми словами — то эта операционная система, которая предназначена для запуска и управления Kubernetes, виртуальных машин и система хранения данных (СХД). Вот такая иллюстрация на сайте Harvester:
Harvester
Node — это сервер. Практически — это одна из нод Кубернетеса. Для высокой доступности требуется три ноды. А так можно запуститься и на одной.
Linux — это и есть Harvester, ОС сделанная на основе OpenSUSE. Версия ядра — 5.14, не самая свежая. Особенность ОС в том, что она — минимальная. То есть при инсталяции ставится абсолютный минимум системных программ, добавлять в ОС — нельзя, если что-то запускать — то только в контейнерах или виртуальных машинах. Сделано это для минимизации необходимости обновлений ОС.
Kubervirt — технология, которая позволяет запускать виртуальные машины в Куберенетес кластере.
Longhorn — технология, которая отвечает за работу с дисками. При наличии ресурсов Longhorn обеспечивает высокую доступность (high availability) и надёжность (redundancy).
Ещё есть сетевая подсистема: Flannel Canal, KubeVirt, плюс собственные модули Harvester.
Harvester — гиперконвергентная система. Это означает, что ОС соединяет в себе управление всеми частями инфраструктуры: вычислительными ресурсами (процессор, память), дисками, сетью. Если сравнить например с VMware ESX — то ESX управляет только виртуальными машинами, а СХД — это уже нужно ставить и управлять отдельно. Если к ESX добавить их vSAN для СХД, и NSX-T для управления сетью, то получится некоторый аналог Harvester.
Требования по железу
Полностью — вот здесь.
У каждой ноды должно быть не меньше двух сетевых подключений: одно — management, второе — для запущенных програм и виртуальных машин. Можно попробовать систему и с одной карточкой, но некоторые вещи работать не будут, например live migration for VM.
Скорость сети — 10Gbps. Хотя запустится и с 1Gbps
Процессоры на нодах лучше иметь одинаковые. Иначе live migration может не работать, или надо будет прописывать настройки, какие фишки процессора не должны быть активированы. Процессоры должны поддерживать виртуализацию.
Система отжирает прилично процессора и памяти, поэтому рекомендуется минимум 16 ядер на ноду.
Не нужен RAID. Про это ниже:
Longhorn — система хранения данных
Наверное все знакомы с технологией RAID: данные пишутся на несколько дисков, и даже если один или несколько (в зависимости от уровня) дисков выйдут из строя — то дисковая система продолжит работать без остановки и потери данных.
Какие есть ограничения у RAID?
Если сервер на котором работает RAID остановится (сломается, или надо будет ставить обновления) — то данные становятся недоступны на это время.
Если диск вышел из строя — то до тех пор, пока не будет установлен новый — система становится менее надёжной. А при установке нового диска — нужно будет синхронизировать ВСЕ данные на нём. Некоторые системы, такие как ZFS — чуть более «умные», и синхронизирует только ту часть, где реально есть данные, но всё равно — нужно синхроннизировать ВСЕ данные на диске.
RAID ограничен в том, какие конфигурации поддерживаются. Например если у вас есть зеркальный RAID 1 из двух дисков по 4TБ, то вы не можете добавить ещё один диск на 10TБ: если заменить один — то расмер массива останется 4TБ, если добавить третьим, то придётся конвертировать в RAID 5/6 и всё равно использоваться будет только часть диска.
Что предлагает Longhorn:
Longhorn
Longhorn — это программа, которая работает в Кубернетесе, на каждой ноде.
Данные хранятся в томах (volumes). Это могут быть PVC Кубернетеса. Это могут быть диски виртуальных машин. Для любого тома можно сконфигурировать количество копий (replica) и класс (например SSD, HDD, NVMe…) и Longhorn будет реплицировать данные на несколько серверов (нод). Поэтому даже потеря целого сервера — не критична, потому что есть копии на других серверах.
При потере диска, тоже как в RAID нужно будет копировать все данные с утерянного диска, но копироваться они будут с разных дисков и серверов, и на разные диски. Ждать установки нового диска не нужно, данные начнут копироваться сразу, как только диск будет или сервер будет утерян. Если есть подозрение, что диск скоро выйдет из строя (например по SMART), то можно превентивно запустить процесс, которые уберёт (evict) все данные с этого диска.
Диски могут быть добавляемы, убираемы в любых конфигурациях, размерах. Если Longhorn сможет найти диск подходящего класса на сервере — он будет его использовать.
Доступ к томам может быть ReadWriteOnce (читается и пишется только с одного сервера, доступ к данным с помощью iSCSI), или ReadWriteMany (читается и пишется с нескольких серверов — в этом случае доступ к данным — через NFS). iSCSI и NFS полностью настраиваются Longhorn — для пользователся это абсолютно прозрачно.
По сравнению с RAID, недостатком может быть то, что данные для копий приходится пересылать по сети, а это может вносить задержки. Поэтому и рекомендуется быстрая сеть — 10Gbps.
Вот тут есть официальный замер скорости доступа к дискам. При использовании 3х копий, при доступе к данным через Longhorn теряется больше половины IOPS от скорости дисков. Bandwidth не теряется. Задержка увеличивается со 0.1 мс до 0.4 мс. Сейчас идёт работа над второй версией, и в ней IOPS должны значительно вырасти за счёт нагрузки на процессор.
С какими трудностями пришлось столкнуться при работе с СХД?
В Harvester можно назначить только одно место, куда будет делаться бэкап для всех томов. NFS или S3. Для каждого тома можно назначить расписание для бэкапов, снэпшотов.
Не очень удобный UI, чтобы делать бэкапы.
Бывает, что при восстановлении надо будет разбираться какой том к какому поду относится. Непросто сделать новую копию из бэкапа, непросто иметь файловый доступ к тому — придётся его сначала монтировать.
Volume in Longhorn
это возможно не относится только к Longhorn, а может быть больше к Кубернетесу, но некоторые вещи делаются непривычно, и могут привести к потере данных. Например вы создали манифест с томом (PVC) 2 ГБ данных, что-то туда сохранили, делали снепшоты, решили откатиться на прошлый спэпшот. Я решил просто удалить манифест и потом выбрать нужный мне снэпшот. Оказалось, что когда я удалил манифест, то все снэпшоты тоже удаляются. Бэкапы остаются.
Есть отдельный кейсы, который не продуманы. Например Longhorn следит за копиями только, когда том в активном состоянии (attached). Если же том не используется, и в этом время диск или сервер теряются, то станет на одну копию меньше, но Longhorn ничего делать не будет. Обещают пофиксить это в версии 1.8.0: https://github.com/longhorn/longhorn/issues/3619
Шифрование дисков обещают в версии 1.7.0: https://github.com/longhorn/longhorn/issues/7051
Harvester
Верися Кубернетеса жёстко привязана к версии. Поэтому пока Harvester не выйдет с нужной версией — будет такая, какая есть.
Сейчас последняя версия Harvester — 1.3.0.
С этой версией поставляется Кубернетес 1.27.10 (RKE2).
У Harvester есть фишка, что на основной кластер можно поставить несколько вложенных кластеров Rancher, которые управляются независимо. Мне это было неинтересно, но может быть полезно, если кто-то захочет дать каждому разработчику по личному кластеру.
В базовом кластере Harvester есть только один пользователь — admin. Других создавать нет возможности. Если нужны пользователи, разграничения прав — это нужно ставить Rancher сверху на Kubernetes. Для этого есть плагин.
Для виртуальных машин можно прокидывать vGPU для тех карточек, которые это поддерживают, PCI.
Пока не поддерживается прокидывание USB устройств в виртуальную машину. Обещают это в 1.4.0.
С какими трудностями я столкнулся:
https://github.com/harvester/harvester/issues/5831 [BUG] Upon migration, the VM becomes unreachable
Когда виртуальная машина работает на одной ноде — сетевое подключение есть. Когда переношу машина на другую ноду — сетевые подключения снаружи не работают. Хотя внутри виртуалки сеть есть, интернет доступен.
https://github.com/harvester/harvester/issues/5830 [BUG] When node is lost, it’s pods can’t recover
Когда отключается одна из нод, то контэйнеры которые были на ней — должны перезапуститься на другой ноде. Вместо этого, они подвисают в состоянии Terminating, потому что том для контейнера оказывается заблокирован в Longhorn.
https://github.com/harvester/harvester/issues/5727 [ENHANCEMENT] How can I configure logs from additional pods or deployments?
У Harvester есть возможность отправлять логи. Я настроил, чтобы логи шли в Эластик. Логи шли с большой задержкой, и только часть контейнеров. Причём непонятно, какая часть. Обещають исправить в следующей версии 1.4.0.
https://github.com/harvester/harvester/issues/5687 [BUG] hard drive unmounted every few hours
Я хотел подключить к ноде мой 16Тб диск, с уже существующими данными. И это делается легко. Но каждые несколько часов запускается какой-то процесс, и все диски, которые не являются частью Longhorn от системы отмонтировываются. Обещают исправить в 1.4.0
P.S.
После моих экспериментов, я пришёл к выводу, что Кубернетес — чересчур сложная система. Возможно — это оправданная сложность, потому что задачи, которые решает Кубернетес — сложные, но как-то вот потратил очень много времени настраивая всё это, нарвался я на слишком много багов, и решил, что наверное лучше я поставлю Proxmox + Ceph, и свои контейнеры там буду запускать. Может даже в Кубернетесе, но немного упрощённом.
Habrahabr.ru прочитано 3221 раз
