Обновление!. В комментах один из читателей предложил попробовать Linstor (возможно, он сам над ним работает), так что я добавил раздел об этом решении. Еще я написал пост о том, как его установить, потому что процесс сильно отличается от остальных.
Если честно, я сдался и отказался от Kubernetes (во всяком случае, пока). Буду использовать Heroku. Почему? Из-за хранения! Кто бы мог подумать, что я буду больше возиться с хранилищами, чем с самим Kubernetes. Я использую Hetzner Cloud, потому что это недорого и производительность хорошая, и с самого начала я развертывал кластеры с помощью Rancher. Я не пробовал управляемые сервисы Kubernetes от Google/Amazon/Microsoft/DigitalOcean и проч., проч., потому что всему хотел научиться сам. А еще я экономный.
Так что — да, я потратил уйму времени, пытаясь решить, какое хранилище выбрать, когда прикидывал возможный стек на Kubernetes. Я предпочитаю решения с открытым исходным кодом, и не только из-за цены, но я изучил пару-тройку платных вариантов из любопытства, потому что у них есть бесплатные версии с ограничениями. Я записал несколько цифр из последних тестов, когда сравнивал разные варианты, и они могут заинтересовать тех, кто изучает хранение в Kubernetes. Хотя лично я пока с Kubernetes распрощался. Еще хочу упомянуть драйвер CSI, в котором можно напрямую подготавливать тома Hetzner Cloud, но я его пока не пробовал. Я изучал облачные программно-определяемые хранилища, потому что мне нужна была репликация и возможность быстро подключать постоянные тома на любой ноде, особенно в случае сбоя нод и других подобных ситуаций. Некоторые решения предлагают снапшоты на момент времени и off site бэкапы, а это удобно.
Я протестировал 6–7 решений для хранения:
OpenEBS (https://openebs.io/)
Как я уже говорил в предыдущем посте, протестировав большинство вариантов из списка, я поначалу остановился на OpenEBS. OpenEBS очень просто устанавливать и использовать, но, если честно, после тестов с реальными данными под нагрузкой его производительность меня разочаровала. Это опенсорс, и разработчики на своем канале Slack всегда очень помогали, когда мне нужна была помощь. К сожалению, у него очень низкая производительность по сравнению с другими вариантами, поэтому пришлось провести тесты заново. Сейчас у OpenEBS 3 движка хранилища, но я публикую результаты бенчмарка для cStor. Пока у меня нет цифр для Jiva и LocalPV.
В двух словах, Jiva чуть быстрее, а LocalPV вообще быстрый, не хуже, чем бенчмарк диска напрямую. Проблема с LocalPV в том, что доступ к тому можно получить только на той ноде, где он был подготовлен, а репликации совсем нет. У меня были некоторые проблемы с восстановлением бэкапа через Velero на новом кластере, потому что имена нод отличались. Если говорить о бэкапах, у cStor есть плагин для Velero, с которым можно делать off site бэкапы снапшотов на момент времени, что удобнее, чем бэкапы на уровне файлов с Velero-Restic. Я написал несколько скриптов, чтобы было проще управлять бэкапами и восстановлениями с этим плагином. В целом, мне очень нравится OpenEBS, но вот его производительность...
Rook (https://rook.io/)
У Rook тоже открытый исходный код, и от остальных вариантов в списке он отличается тем, что это оркестратор хранилища, который выполняет сложные задачи по управлению хранилищем с разными бэкендами, например Ceph, EdgeFS и другие, что значительно упрощает работу. У меня были проблемы с EfgeFS, когда я пробовал его несколько месяцев назад, так что тестировал я, в основном, с Ceph. Ceph предлагает не только хранилище блоков, но и хранилище объектов, совместимое с S3/Swift и распределенной файловой системой. Что мне нравится в Ceph, так это возможность распространить данные тома по нескольким дискам, чтобы том мог использовать больше дискового пространства, чем умещается на одном диске. Это удобно. Еще одна классная функция — когда добавляешь в кластер диски, он автоматически перераспределяет данные по всем дискам.
В Ceph есть снапшоты, но, насколько я знаю, их нельзя напрямую использовать в Rook/Kubernetes. Правда, я в это не углублялся. А вот off site бэкапов нет, так что придется использовать что-нибудь с Velero/Restic, но там только бэкапы на уровне файлов, а не снапшоты на момент времени. Зато в Rook мне очень понравилась простая работа с Ceph — он скрывает почти все сложные штуки и предлагает инструменты, чтобы общаться с Ceph напрямую для устранения неисправностей. К сожалению, на стресс-тесте томов Ceph у меня все время возникала эта проблема, из-за которой Ceph становится нестабильным. Пока непонятно, баг это в самом Ceph или проблема в том, как Rook управляет Ceph. Я поколдовал с настройками памяти, и стало получше, но до конца проблема не решилась. У Ceph неплохая производительность, как видно в бенчмарках внизу. А еще у него хорошая панель мониторинга.
Rancher Longhorn (https://github.com/longhorn/longhorn)
Мне очень нравится Longhorn. По-моему, это перспективное решение. Правда, сами разработчики (Rancher Labs) признают, что для рабочей среды он пока не годится, и это видно. У него открытый исходный код и неплохая производительность (хотя ее оптимизацией они еще не занимались), но тома очень долго подключаются к поду, и в худших случаях это занимает 15–16 минут, особенно после восстановления большого бэкапа или апгрейда рабочей нагрузки. У него есть снапшоты и off site бэкапы этих снапшотов, но они распространяются только на тома, поэтому вам все равно нужно будет что-то типа Velero для бэкапа остальных ресурсов. Бэкапы и восстановления очень надежные, но неприлично медленные. Серьезно, просто запредельно медленные. Использование процессорных ресурсов и загрузка системы часто подскакивают при работе со средним объемом данных в Longhorn. Есть удобная панель мониторинга, чтобы управлять Longhorn. Я уже говорил, что мне нравится Longhorn, но над ним надо как следует поработать.
StorageOS (https://storageos.com/)
StorageOS — это первый платный продукт в списке. У него есть версия для разработчиков с ограниченным размером управляемого хранилища в 500 ГБ, но количество узлов, по-моему, не ограничено. В отделе продаж мне сказали, что стоимость начинается от $125 в месяц за 1 ТБ, если я правильно запомнил. Там есть базовая панель мониторинга и удобный CLI, но с производительностью творится что-то странное: в некоторых бенчмарках она вполне приличная, но в стресс-тесте томов скорость мне совсем не понравилась. В общем, не знаю, что и сказать. Поэтому я особенно не разбирался. Здесь нет off site бэкапов и придется тоже использовать Velero с Restic для бэкапа томов. Странно, ведь продукт-то платный. А еще разработчики не горели желанием общаться в Slack.
Robin (https://robin.io/)
О Robin я узнал на Reddit от их техдиректора. Раньше я о нем и не слышал. Может, потому что искал бесплатные решения, а Robin платное. У них довольно щедрая бесплатная версия с хранилищем на 10 ТБ и тремя нодами. В целом, продукт вполне достойный и с приятными функциями. Там отличный CLI, но самое крутое — это то, что можно делать снапшот и бэкап всего приложения (в селекторе ресурсов это называется релизами Helm или «flex apps»), включая тома и другие ресурсы, так что можно обойтись без Velero. И все было бы чудесно, если бы не одна маленькая деталь: если восстанавливать (или «импортировать», как это называется в Robin) приложение на новом кластере — например, в случае восстановления после аварии — восстановление, конечно, работает, но продолжить бэкап приложения нельзя. В этом релизе это просто невозможно, и разработчики подтвердили. Это, мягко говоря, странно, особенно если учесть остальные преимущества (например, невероятно быстрые бэкапы и восстановления). Разработчики обещают все исправить к следующему релизу. Производительность, в целом, хорошая, но я заметил странность: если запустить бенчмарк напрямую на томе, подключенном к хосту, скорость чтения гораздо выше, чем в том же томе, но изнутри пода. Все остальные результаты идентичны, но в теории разницы быть не должно. Хоть они над этим и работают, я расстроился из-за проблемы с восстановлением и бэкапом — мне показалось, что я наконец нашел подходящее решение, и я даже готов был платить за него, когда мне понадобится больше пространства или больше серверов.
Portworx (https://portworx.com/)
Тут мне особо нечего сказать. Это платный продукт, одинаково классный и дорогой. Производительность просто чудо. Пока это лучший показатель. В Slack мне сказали, что цена начинается от $205 в месяц за ноду, как указано в гугловском GKE Marketplace. Не знаю, будет ли дешевле, если покупать напрямую. В любом случае, я не могу себе такое позволить, так что я был очень и очень разочарован, что лицензия разработчика (до 1 ТБ и 3 ноды) практически бесполезна с Kubernetes, если только вы не довольствуетесь статической подготовкой. Я надеялся, что корпоративная лицензия автоматически понизится до уровня разработчика в конце пробного периода, но не случилось. Лицензию разработчика можно использовать только напрямую с Docker, а настройка в Kubernetes очень громоздкая и ограниченная. Я, конечно, предпочитаю опенсорс, но будь у меня деньги, я бы точно выбрал Portworx. Пока что его производительность просто не сравнится с другими вариантами.
Linstor (https://www.linbit.com/en/linstor/)
Я добавил этот раздел уже после публикации поста, когда один читатель предложил попробовать Linstor. Я попробовал, и мне понравилось! Но надо еще покопаться. Сейчас могу сказать, что производительность неплохая (результаты бенчмарка добавил ниже). По сути, я получил ту же производительность, что и для диска напрямую, совсем без издержек. (Не спрашивайте, почему у Portworx цифры лучше, чем бенчмарк диска напрямую. Понятия не имею. Магия, наверное.) Так что Linstor пока кажется очень эффективным. Устанавливать его не то что бы сложно, но не так легко, как остальные варианты. Сначала мне пришлось установить Linstor (модуль ядра и инструменты/сервисы) и настроить LVM для thin provisioning и поддержки снапшотов за пределами Kubernetes, напрямую на хосте, а потом создать ресурсы, необходимые для использования хранилища из Kubernetes. Мне не понравилось, что он не заработал на CentOS и пришлось использовать Ubuntu. Не страшно, конечно, но немного раздражает, потому что в документации (она, кстати, отличная) упоминается несколько пакетов, которые невозможно найти в указанных репозиториях Epel. В Linstor есть снапшоты, но не off site бэкапы, так что здесь снова пришлось использовать Velero с Restic для бэкапа томов. Я бы предпочел снапшоты вместо бэкапов на уровне файлов, но это можно стерпеть, если решение будет производительным и надежным. У Linstor открытый исходный код, но есть платная поддержка. Если я правильно понимаю, его можно использовать без ограничений, даже если у вас нет договора на поддержку, но это надо уточнить. Я не знаю, насколько Linstor проверен для Kubernetes, но сам уровень хранения находится за пределами Kubernetes и, судя по всему, решение появилось не вчера, так что, наверное, уже проверено в реальных условиях. Есть ли тут решение, которое заставит меня передумать и вернуться к Kubernetes? Не знаю, не знаю. Нужно еще поковыряться, изучить репликацию. Посмотрим. Но первое впечатление хорошее. Я совершенно точно предпочел бы использовать свои собственные кластеры Kubernetes вместо Heroku, чтобы получить больше свободы и научиться новому. Раз Linstor устанавливается не так просто, как другие, скоро я напишу об этом пост.
Бенчмарки
К сожалению, я сохранил мало записей о сравнении, потому что не подумал, что буду об этом писать. У меня есть только результаты базовых бенчмарков 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Сначала я создал том с соответствующим классом хранилища, а потом запустил задание с fio за кадром. Я взял 1 ГБ, чтобы прикинуть производительность и не ждать слишком долго. Вот результаты:
Я выделил лучшее значение для каждого показателя зеленым, а худшее — красным.
Заключение
Как видите, в большинстве случаев Portworx показал себя лучше других. Но для меня он дорогой. Я не знаю, сколько стоит Robin, но там отличная бесплатная версия, так что, если вам нужен платный продукт, можете попробовать (надеюсь, они скоро исправят проблему с восстановлением и бэкапами). Из трех бесплатных у меня меньше всего проблем возникло с OpenEBS, но производительность у него ни к черту. Жаль, я не сохранил больше результатов, но, надеюсь, вам помогут приведенные цифры и мои комментарии.
Автор: nAbdullin
