В поисках идеальной кластерной ФС: опыт использования LINSTOR / Андрей Квапил (kvaps)

• Андрей Кваел представляет компанию Ведос, крупнейший чешский хостинг.  

• Ведос имеет два действующих дата-центра и строит третий.  

• Компания обслуживает клиентов в Чехии и Восточной Европе, но не популярна в России.  

• Ведос активно использует Kubernetes, OpenStack и Proxmox.  

• В новом дата-центре используется активное масляное охлаждение.  

• Инфраструктура состоит из HP-муншотов с 45 серверами и 64 ГБ оперативной памяти.  

• Все серверы работают в масле, что обеспечивает высокую производительность.  

• Ведос искал хранилище с высокой производительностью, надежностью и отказоустойчивостью.  

• Важно было, чтобы хранилище легко интегрировалось с Kubernetes и OpenStack.  

• Необходимо было бесшовно мигрировать и обновлять виртуальные машины.  

• Хранилища делятся на три типа: POSIX-совместимые файловые системы, блочные устройства и IP-интерфейсы.  

• Ведос рассматривал только первые два типа хранилищ из-за большого количества легаси.  

• Ведос рассматривал Ceph, Gluster и LizardFS.  

• Ceph потреблял много ресурсов и не подходил из-за высокой нагрузки на CPU.  

• Gluster был медленнее, но подходил для небольших файлов.  

• LizardFS показал стабильную производительность, но был медленным.  

• BigFS была выбрана из-за высокой производительности и низкой ресурсоемкости.  

• BigFS обеспечивала отказоустойчивость через реплику данных между серверами.  

• Однако, BigFS имела специфические проблемы с восстановлением данных.  

• BigFS столкнулась с проблемами, такими как неожиданные изменения в файлах.  

• Ведос начал искать альтернативные решения, включая Shibby и RoseFS.  

• Shibby не прошел краш-тесты и не восстанавливал поврежденные блоки.  

• RoseFS показала неплохую производительность, но не имела комьюнити.  

• LusterFS требовала много времени на интеграцию и не подходила из-за специфики.  

• OrangeFS была выбрана из-за интеграции в ядро Linux,  

• Сенсорные файловые системы не поддерживают блокировки, отказоустойчивость и не имеют комьюнити.  

• Решение: использование Deduplication для создания отказоустойчивого NFS-сервера.  

• В каждом шасси было по два сервера с блочным устройством LVM и контейнером.  

• Контейнер с NFS-сервером подключался к остальным нодам.  

• Система работала стабильно и быстро, особенно после замены NFS-сервера на iSCSI Target.  

• Виртуальные машины могли работать с одних и тех же таргетов на разных нодах.  

• Linstor - новый оркестратор для блочных устройств, заменяющий Deduplication Management.  

• Позволяет нарезать устройства на нодах и отдавать их виртуальным машинам.  

• Каждое устройство можно снапшотить и работать с ним независимо.  

• Linstor создает LVM пулы и нарезает устройства с репликацией.  

• Виртуальные машины могут запускаться на любой ноде, даже если данных нет.  

• Linstor состоит из контроллера и сателлитов, которые настраивают LVM и Deduplication.  

• Linstor поддерживает планирование размещения ресурсов и различные бэкенды.  

• Автоматическое добавление дополнительных реплик для поддержания кворума.  

• Шифрование и снапшот-шипинг для резервного копирования.  

• Использование стандартных драйверов для Proxmox и OpenStack.  

• Написание собственных реализаций для Kubernetes и OpenShift.  

• Демонстрация работы Linstor на примере кластера из 800 нод.  

• Ноды используются для сторожа и виртуальных машин.  

• Каждая нода имеет лейбл, который определяет её роль.  

• Можно выбирать ноды по лейблу, например, ноды с лейблом "пятнадцать".  

• Ресурсы определяют конфигурацию размещения ресурсов.  

• Ресурсы могут быть репликами, размещаемыми в разных шасси для отказоустойчивости.  

• Ресурсы определяются через ресурс-дефинишнс, которые описывают блочные устройства.  

• LInstor содержит баги, которые исправляются в новых версиях.  

• Обновление LInstor требует согнать все виртуальные машины и перекомпилировать ядро.  

• Рекомендуется использовать последние версии для устранения багов.  

• LInstor имеет проблемы, такие как эваку, которая пересоздает ресурсы при недоступности ноды.  

• Поддержка RDMA доступна только в Enterprise версии.  

• Для больших кластеров требуется много ручных действий, что делает LInstor менее удобным.  

• Основной вендор предложил коробочное решение, что привело к отказу от LInstor.  

• LInstor остается перспективной технологией для дешевых сторожей.  

• Использование NFS Server Provisioner для автоматизации provisioning томов.  

• Используется собственное решение для резервного копирования на основе Resic.  

• Комьюнити в Telegram для обсуждения кластерных файлов и систем.  

• Вопросы по LInstor и Kubernetes можно задать в соответствующих чатах.  

• LInstor Control Plane должен быть установлен на всех нодах кластера.  

• Обновление LInstor требует остановки и перезапуска всех демонов.  

• В компании вся инфраструктура построена на Kubernetes, включая LInstor.  

• В Kubernetes есть встроенные решения для квот, не зависящие от LInstor.  

• LInstor имеет ограничения на создание томов больше размера физической ноды.  

• Масштабирование кластера требует осторожности и может быть болезненным.  

• Процесс репликации данных в Linstor не автоматизирован.  

• Необходимо вручную копировать данные с ноды на ноду.  

• Скорость репликации зависит от скорости дисков.  

• Дисковые ноды отличаются от вычислительных конфигурацией.  

• На дисковых нодах можно использовать LVM ZFS пулы.  

• На вычислительных нодах можно просто добавить ноду в кластер.  

• Linstor позволяет использовать различные слои для репликации данных.  

• Возможность использования Sherwood для репликации данных.  

• Linstor можно использовать как API-интерфейс для других систем.  

• Linstor имеет преимущества в сравнении с другими системами.  

• OpenEBS имеет потенциал, но пока не готов к использованию.  

• Linstor обеспечивает отказоустойчивость и быстрое восстановление данных.  

• Тестирование файловых систем заняло много времени.  

• Linstor был выбран из-за его надежности и скорости.  

• Linbit имеет решение для репликации данных между дата-центрами.  

• Обсуждение продолжится в цифровых кулуарах.  

• Вячеслав получит книгу за лучший вопрос.  

• Участники перемещаются в цифровые кулуары для продолжения дискуссии.