Как стать автором
Обновить

Состояние и производительность решений для постоянного хранения данных в Kubernetes

Время на прочтение 11 мин
Количество просмотров 11K
Всего голосов 38: ↑37 и ↓1 +36
Комментарии 5

Комментарии 5

За все не скажу, но вот longhorn мне не понравился — постоянно отваливаются реплики, вечное выпадание в I/O error после непонятно чего (фиксится только перезапуском пода), томы кушают место просто потому что (какие-то старые реплики, которые никем не используются, но и не удаляются).


OpenEBS, в котором движок jiva использует наработки longhorn, работает куда стабильнее и по моим тестам быстрее самого longhorn, уж не знаю как, настройки плюс-минус одинаковые — три реплики на том на трёх разных серверах.

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

Например, в Longhorn нет возможности освободить диск. Создали volume — заполнили, удалили все, а реальное использование диска на хосте не поменялось.

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

P.S. Из-за этого вообще не представляю реальные кейсы его использования.
Хм, а где же Rook из инкубатора?
Я после перебора всех вариантов остановился на нем по нескольким причинам:
1. Под капотом Ceph. Он конечно страшный, но развивается черт знает сколько лет и производительность у него неплохая.
2. Легко ставится, в целом нормально работает.
3. Следствие ceph-а — отказоустойчивость нормальная, если не экономить на репликах. Есть erasure, что в некоторых кейсах полезно.
4. Прицепом получаешь еще и object storage, что тоже полезно.
Минусы конечно тоже есть, но лично для меня плюсы перевесили. Сравнивал с EBS+Jiva и Longhorn. В моей конфигурации они были сильно медленнее. Очень сильно медленнее.

P.S. Позабавило весьма высказывание про OpenEBS и DynamicLocal PV. Веселая часть в том, что это фактически не является «системой постоянного хранения данных в кластере», потому что это «альтернатива локальному диску с более удобным в некоторых кейсах провиженом». Сравнивать же производительность локального и сетевого диска (если это конечно не NVMe-oF какой-нибудь) — затея несколько странная. Не говоря уже о том, что никакой речи о миграции подобных дисков между машинами не идет и по сути полнофункциональный аналог облачных дисков вроде EBS не дает.

P.P.S. Я понимаю что это перевод, но уровень проведения теста по сути не позволяет ответить нормально ни на вопрос проивзодительности в реальных кейсах, ни про надежность. В целом, «я что-то мерил и у меня что-то получилось». Объем записи в разы меньше объема оперативной памяти, тесты проводятся прямо на storage-ноде, что не дает понимания как оно себя будет вести, если обе реплики будут находиться на другой машине и так далее, вплоть до вывода «победила схема с асинхронной репликацией и отложенной записью», что конечно вполне ожидаемо, вот только отказоустойчивость такой схемы более чем сомнительна.
С распределенным block-storage на bare-metal вообще в целом все печально, кубернетис тут разве что чуть своих проблем подкидывает. Странно, что в сравнении нет glusterfs и ceph. Оба вполне себе интегрируются в кубер и будут более зрелыми, чем все перечисленные вместе взятые наверное. А так, в итоге все равно непонятно, чему из этого всего можно довериться. Даже glusterfs казалось бы, а проблем от него огребли выше крыши и забыли как страшный сон.

Это конечно красиво и удобно, когда можно поднять общий block-storage на куче машин и скейлить его бесконечно, но по всем признакам оно работает довольно условно и требует кучи усилий для этого. Либо для этого требуется покупать что-то дорогое и закрытое. Как-то светлое будущее распределенных открытых файловых хранилищ все никак не наступит.

В итоге мне видится более удачным подходом выносить проблемы и сложности надежности хранения на уровень приложений, где это более менее давно решено. Требуется поднять PostgreSQL? Ставим stolon, маунтим на local volume прямо на хостах. Отвалится хост или его диск — подхватит реплика с другого хоста. Надо Cassandra? Тоже самое, все средства надежности встроены. Надо что-то свое хранить? Тут можно попробовать натянуть на объектные хранилища. На картинке выше в списке решений вон minio есть — пока очень хорошо справляется. Чрезвычайно быстрый и простой (практически линейно скейлится с числом дисков по тестам). Максимально все на него перетащили, что совместимо, и пока устраивает.

Кстати, тем, кто заинтересовался Piraeus/Linstor — на днях у них будет вебинар на платформе CNCF: «Update on and Demo of Piraeus Datastore (LINSTOR)» — May 27th; 10:00-11:00 AM PT (UTC-7).
Зарегистрируйтесь на Хабре , чтобы оставить комментарий