Хабрахабр

[Перевод] Хранилища в Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

В комментах один из читателей предложил попробовать Linstor (возможно, он сам над ним работает), так что я добавил раздел об этом решении. Обновление!. Еще я написал пост о том, как его установить, потому что процесс сильно отличается от остальных.

Буду использовать Heroku. Если честно, я сдался и отказался от Kubernetes (во всяком случае, пока). Из-за хранения! Почему? Я использую Hetzner Cloud, потому что это недорого и производительность хорошая, и с самого начала я развертывал кластеры с помощью Rancher. Кто бы мог подумать, что я буду больше возиться с хранилищами, чем с самим Kubernetes. А еще я экономный. Я не пробовал управляемые сервисы Kubernetes от Google/Amazon/Microsoft/DigitalOcean и проч., проч., потому что всему хотел научиться сам.

Я предпочитаю решения с открытым исходным кодом, и не только из-за цены, но я изучил пару-тройку платных вариантов из любопытства, потому что у них есть бесплатные версии с ограничениями. Так что — да, я потратил уйму времени, пытаясь решить, какое хранилище выбрать, когда прикидывал возможный стек на Kubernetes. Хотя лично я пока с Kubernetes распрощался. Я записал несколько цифр из последних тестов, когда сравнивал разные варианты, и они могут заинтересовать тех, кто изучает хранение в Kubernetes. Я изучал облачные программно-определяемые хранилища, потому что мне нужна была репликация и возможность быстро подключать постоянные тома на любой ноде, особенно в случае сбоя нод и других подобных ситуаций. Еще хочу упомянуть драйвер CSI, в котором можно напрямую подготавливать тома Hetzner Cloud, но я его пока не пробовал. Некоторые решения предлагают снапшоты на момент времени и off site бэкапы, а это удобно.

Я протестировал 6–7 решений для хранения:

OpenEBS

OpenEBS очень просто устанавливать и использовать, но, если честно, после тестов с реальными данными под нагрузкой его производительность меня разочаровала. Как я уже говорил в предыдущем посте, протестировав большинство вариантов из списка, я поначалу остановился на OpenEBS. К сожалению, у него очень низкая производительность по сравнению с другими вариантами, поэтому пришлось провести тесты заново. Это опенсорс, и разработчики на своем канале Slack всегда очень помогали, когда мне нужна была помощь. Пока у меня нет цифр для Jiva и LocalPV. Сейчас у OpenEBS 3 движка хранилища, но я публикую результаты бенчмарка для cStor.

Проблема с LocalPV в том, что доступ к тому можно получить только на той ноде, где он был подготовлен, а репликации совсем нет. В двух словах, Jiva чуть быстрее, а LocalPV вообще быстрый, не хуже, чем бенчмарк диска напрямую. Если говорить о бэкапах, у cStor есть плагин для Velero, с которым можно делать off site бэкапы снапшотов на момент времени, что удобнее, чем бэкапы на уровне файлов с Velero-Restic. У меня были некоторые проблемы с восстановлением бэкапа через Velero на новом кластере, потому что имена нод отличались. В целом, мне очень нравится OpenEBS, но вот его производительность... Я написал несколько скриптов, чтобы было проще управлять бэкапами и восстановлениями с этим плагином.

Rook

У меня были проблемы с EfgeFS, когда я пробовал его несколько месяцев назад, так что тестировал я, в основном, с Ceph. У Rook тоже открытый исходный код, и от остальных вариантов в списке он отличается тем, что это оркестратор хранилища, который выполняет сложные задачи по управлению хранилищем с разными бэкендами, например Ceph, EdgeFS и другие, что значительно упрощает работу. Что мне нравится в Ceph, так это возможность распространить данные тома по нескольким дискам, чтобы том мог использовать больше дискового пространства, чем умещается на одном диске. Ceph предлагает не только хранилище блоков, но и хранилище объектов, совместимое с S3/Swift и распределенной файловой системой. Еще одна классная функция — когда добавляешь в кластер диски, он автоматически перераспределяет данные по всем дискам. Это удобно.

Правда, я в это не углублялся. В Ceph есть снапшоты, но, насколько я знаю, их нельзя напрямую использовать в Rook/Kubernetes. Зато в Rook мне очень понравилась простая работа с Ceph — он скрывает почти все сложные штуки и предлагает инструменты, чтобы общаться с Ceph напрямую для устранения неисправностей. А вот off site бэкапов нет, так что придется использовать что-нибудь с Velero/Restic, но там только бэкапы на уровне файлов, а не снапшоты на момент времени. Пока непонятно, баг это в самом Ceph или проблема в том, как Rook управляет Ceph. К сожалению, на стресс-тесте томов Ceph у меня все время возникала эта проблема, из-за которой Ceph становится нестабильным. У Ceph неплохая производительность, как видно в бенчмарках внизу. Я поколдовал с настройками памяти, и стало получше, но до конца проблема не решилась. А еще у него хорошая панель мониторинга.

Rancher Longhorn

По-моему, это перспективное решение. Мне очень нравится Longhorn. У него открытый исходный код и неплохая производительность (хотя ее оптимизацией они еще не занимались), но тома очень долго подключаются к поду, и в худших случаях это занимает 15–16 минут, особенно после восстановления большого бэкапа или апгрейда рабочей нагрузки. Правда, сами разработчики (Rancher Labs) признают, что для рабочей среды он пока не годится, и это видно. Бэкапы и восстановления очень надежные, но неприлично медленные. У него есть снапшоты и off site бэкапы этих снапшотов, но они распространяются только на тома, поэтому вам все равно нужно будет что-то типа Velero для бэкапа остальных ресурсов. Использование процессорных ресурсов и загрузка системы часто подскакивают при работе со средним объемом данных в Longhorn. Серьезно, просто запредельно медленные. Я уже говорил, что мне нравится Longhorn, но над ним надо как следует поработать. Есть удобная панель мониторинга, чтобы управлять Longhorn.

StorageOS

У него есть версия для разработчиков с ограниченным размером управляемого хранилища в 500 ГБ, но количество узлов, по-моему, не ограничено. StorageOS — это первый платный продукт в списке. Там есть базовая панель мониторинга и удобный CLI, но с производительностью творится что-то странное: в некоторых бенчмарках она вполне приличная, но в стресс-тесте томов скорость мне совсем не понравилась. В отделе продаж мне сказали, что стоимость начинается от $125 в месяц за 1 ТБ, если я правильно запомнил. Поэтому я особенно не разбирался. В общем, не знаю, что и сказать. Странно, ведь продукт-то платный. Здесь нет off site бэкапов и придется тоже использовать Velero с Restic для бэкапа томов. А еще разработчики не горели желанием общаться в Slack.

Robin

Раньше я о нем и не слышал. О Robin я узнал на Reddit от их техдиректора. У них довольно щедрая бесплатная версия с хранилищем на 10 ТБ и тремя нодами. Может, потому что искал бесплатные решения, а Robin платное. Там отличный CLI, но самое крутое — это то, что можно делать снапшот и бэкап всего приложения (в селекторе ресурсов это называется релизами Helm или «flex apps»), включая тома и другие ресурсы, так что можно обойтись без Velero. В целом, продукт вполне достойный и с приятными функциями. В этом релизе это просто невозможно, и разработчики подтвердили. И все было бы чудесно, если бы не одна маленькая деталь: если восстанавливать (или «импортировать», как это называется в Robin) приложение на новом кластере — например, в случае восстановления после аварии — восстановление, конечно, работает, но продолжить бэкап приложения нельзя. Разработчики обещают все исправить к следующему релизу. Это, мягко говоря, странно, особенно если учесть остальные преимущества (например, невероятно быстрые бэкапы и восстановления). Все остальные результаты идентичны, но в теории разницы быть не должно. Производительность, в целом, хорошая, но я заметил странность: если запустить бенчмарк напрямую на томе, подключенном к хосту, скорость чтения гораздо выше, чем в том же томе, но изнутри пода. Хоть они над этим и работают, я расстроился из-за проблемы с восстановлением и бэкапом — мне показалось, что я наконец нашел подходящее решение, и я даже готов был платить за него, когда мне понадобится больше пространства или больше серверов.

Portworx

Это платный продукт, одинаково классный и дорогой. Тут мне особо нечего сказать. Пока это лучший показатель. Производительность просто чудо. Не знаю, будет ли дешевле, если покупать напрямую. В Slack мне сказали, что цена начинается от $205 в месяц за ноду, как указано в гугловском GKE Marketplace. Я надеялся, что корпоративная лицензия автоматически понизится до уровня разработчика в конце пробного периода, но не случилось. В любом случае, я не могу себе такое позволить, так что я был очень и очень разочарован, что лицензия разработчика (до 1 ТБ и 3 ноды) практически бесполезна с Kubernetes, если только вы не довольствуетесь статической подготовкой. Я, конечно, предпочитаю опенсорс, но будь у меня деньги, я бы точно выбрал Portworx. Лицензию разработчика можно использовать только напрямую с Docker, а настройка в Kubernetes очень громоздкая и ограниченная. Пока что его производительность просто не сравнится с другими вариантами.

Linstor

Я попробовал, и мне понравилось! Я добавил этот раздел уже после публикации поста, когда один читатель предложил попробовать Linstor. Сейчас могу сказать, что производительность неплохая (результаты бенчмарка добавил ниже). Но надо еще покопаться. (Не спрашивайте, почему у Portworx цифры лучше, чем бенчмарк диска напрямую. По сути, я получил ту же производительность, что и для диска напрямую, совсем без издержек. Магия, наверное.) Так что Linstor пока кажется очень эффективным. Понятия не имею. Сначала мне пришлось установить Linstor (модуль ядра и инструменты/сервисы) и настроить LVM для thin provisioning и поддержки снапшотов за пределами Kubernetes, напрямую на хосте, а потом создать ресурсы, необходимые для использования хранилища из Kubernetes. Устанавливать его не то что бы сложно, но не так легко, как остальные варианты. Не страшно, конечно, но немного раздражает, потому что в документации (она, кстати, отличная) упоминается несколько пакетов, которые невозможно найти в указанных репозиториях Epel. Мне не понравилось, что он не заработал на CentOS и пришлось использовать Ubuntu. Я бы предпочел снапшоты вместо бэкапов на уровне файлов, но это можно стерпеть, если решение будет производительным и надежным. В Linstor есть снапшоты, но не off site бэкапы, так что здесь снова пришлось использовать Velero с Restic для бэкапа томов. Если я правильно понимаю, его можно использовать без ограничений, даже если у вас нет договора на поддержку, но это надо уточнить. У Linstor открытый исходный код, но есть платная поддержка. Есть ли тут решение, которое заставит меня передумать и вернуться к Kubernetes? Я не знаю, насколько Linstor проверен для Kubernetes, но сам уровень хранения находится за пределами Kubernetes и, судя по всему, решение появилось не вчера, так что, наверное, уже проверено в реальных условиях. Нужно еще поковыряться, изучить репликацию. Не знаю, не знаю. Но первое впечатление хорошее. Посмотрим. Раз Linstor устанавливается не так просто, как другие, скоро я напишу об этом пост. Я совершенно точно предпочел бы использовать свои собственные кластеры Kubernetes вместо Heroku, чтобы получить больше свободы и научиться новому.

Бенчмарки

У меня есть только результаты базовых бенчмарков fio и только для кластеров с одним узлом, так что для реплицированных конфигураций у меня пока нет цифр. К сожалению, я сохранил мало записей о сравнении, потому что не подумал, что буду об этом писать. Я прогнал бенчмарки трижды для каждого решения и вычислил средний результат, плюс сбрасывал настройки сервера для каждого продукта. Но по этим результатам можно получить примерное представление о том, чего ждать от каждого варианта, потому что я сравнивал их на одинаковых облачных серверах, 4 ядра, 16 ГБ оперативки, с дополнительным диском на 100 ГБ для тестируемых томов. В других тестах я копировал 38 ГБ фото и видео с тома и на том, чтобы потестить чтение и запись, но цифры, увы, не сохранил. Все это совершенно не научно, просто чтобы вы поняли в общих чертах. Если вкратце: Portworkx был гораздо быстрее.

Для бенчмарка томов я использовал этот манифест:

kind: PersistentVolumeClaim
apiVersion: v1
metadata: name: dbench
spec: storageClassName: ... accessModes: - ReadWriteOnce resources: requests: storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata: name: dbench
spec: template: spec: containers: - name: dbench image: sotoaster/dbench:latest imagePullPolicy: IfNotPresent env: - name: DBENCH_MOUNTPOINT value: /data - name: FIO_SIZE value: 1G volumeMounts: - name: dbench-pv mountPath: /data restartPolicy: Never volumes: - name: dbench-pv persistentVolumeClaim: claimName: dbench backoffLimit: 4

Я взял 1 ГБ, чтобы прикинуть производительность и не ждать слишком долго. Сначала я создал том с соответствующим классом хранилища, а потом запустил задание с fio за кадром. Вот результаты:

Я выделил лучшее значение для каждого показателя зеленым, а худшее — красным.

Заключение

Но для меня он дорогой. Как видите, в большинстве случаев Portworx показал себя лучше других. Из трех бесплатных у меня меньше всего проблем возникло с OpenEBS, но производительность у него ни к черту. Я не знаю, сколько стоит Robin, но там отличная бесплатная версия, так что, если вам нужен платный продукт, можете попробовать (надеюсь, они скоро исправят проблему с восстановлением и бэкапами). Жаль, я не сохранил больше результатов, но, надеюсь, вам помогут приведенные цифры и мои комментарии.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть