Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 12
сколько не читал обзоров, форумов, статей:
Все сводилось к тому что гластер легко ломается и сложно в итоге делается.
Надежнее ceph, но сильно дороже, но и развалить сложнее
А в энтерпрайз на днях пришел vsan с интеграцией с kubernetes и vmware.
Сколько gluster ни собирал, ломаться там особо не чему, потому что он просто файлики из локальной папочки по сети отдает, кроме distributed транслятора конечно. А вот производительность всегда была и остается говном, хоть какой простой сетап не запиливай.
Ceph пробовал последний раз в далеком 2013-м, тогда он делал kernel panic и убивал машину. Думаю с тех пор все сильно лучше стало.
Ceph пробовал последний раз в далеком 2013-м, тогда он делал kernel panic и убивал машину. Думаю с тех пор все сильно лучше стало.
Я конечно не настоящий сварщик(с), в том смысле что не работаю с кубернетсом, но глядя на все эти костыли с велосипедами сразу задаюсь вопросами.
1) В данном примере сразу есть shared storage, почему просто не использовать кластерную fs gfs/lustre? Нет поддержки?
2) Зачем абстрагироваться на 2 этажа ниже — не проще и лучше для устойчивости и производительности синхронизировать данные на более высоком уровне?
1) В данном примере сразу есть shared storage, почему просто не использовать кластерную fs gfs/lustre? Нет поддержки?
2) Зачем абстрагироваться на 2 этажа ниже — не проще и лучше для устойчивости и производительности синхронизировать данные на более высоком уровне?
Разумеется, возможно использовать репликацию данных и другими способами, сверху обвесив тем же NFS и keepalived и получить по сути аналогичную систему. Но сейчас очень пользуется популярностью GlusterFS и предлагает легкое развертывание в режиме мультимастеров и простую поддержку, поэтому надо было испробовать данное решение на совместимость, а то, с чем мы столкнулись описано выше. Конечная схема с велосипедами — не идеальное решение, но большая часть людей остановится на варианте работы с гластером через их протокол и в данных велосипедах не будут нуждаться, ну, а если нет, то любые средства хороши, главное получить желаемый результат.
Выбирали ли вы DFS и из каких систем? Делали ли тесты по производительности и надежности? Сравнивали ли возможности?
Около 4 лет назад мы выбирали систему для работы в облаке. Сравнивали Ceph, Gluster и другие FS. В нашем сравнении победила малоизвестная FS SeaWeedFS.
Может кому-то это будет полезно.
Около 4 лет назад мы выбирали систему для работы в облаке. Сравнивали Ceph, Gluster и другие FS. В нашем сравнении победила малоизвестная FS SeaWeedFS.
SeaweedFS is a simple and highly scalable distributed file system, to store and serve billions of files fast! SeaweedFS implements an object store with O(1) disk seek, transparent cloud integration, and an optional Filer supporting POSIX, S3 API, AES256 encryption, Rack-Aware Erasure Coding for warm storage, FUSE mount, Hadoop compatible, WebDAV.
Может кому-то это будет полезно.
Много систем отпадало по причине недостаточной документации или избыточности, как Ceph.
Сравнение делалось только с Ceph, который разумеется, производительнее, но и значительно сложнее.
Такую FS даже не встречал. Жаль, что не написали пост о ней, было бы интересно ознакомиться. Но к малоизвестным системам тяги нет, в случае нештатных ситуаций легко можно оказаться без помощи или ждать исправления проблемы долгое время, а в случае FS еще и потерять данные.
Сравнение делалось только с Ceph, который разумеется, производительнее, но и значительно сложнее.
Такую FS даже не встречал. Жаль, что не написали пост о ней, было бы интересно ознакомиться. Но к малоизвестным системам тяги нет, в случае нештатных ситуаций легко можно оказаться без помощи или ждать исправления проблемы долгое время, а в случае FS еще и потерять данные.
Вы с Heketi не разобрались совсем и написали полную ерунду.
1. Давайте начнем с простого. Что же это такое? Обратимся к официальной документации. Я сразу попробую перевести на русский язык:
Kubernetes работает с Heketi только в тот момент, когда создает/изменяет/удаляет PersistentVolumeClaim. Для взаимодействия контейнеров с GlusterFS он не нужен, так как вся информация, которая необходима для монтирования волума, содержится в PersistentVolume. Соответственно, и кластеризовать Heketi нет никакого смысла. Нужно только делать бэкапы базы.
2.
Из-за этого у вас появились какие-то вопросы с Endpoints, потом появился NFS, да еще keepalived. Хотя достаточно было:
1. Установить GlusterFS.
2. Настроить Heketi (не важно, в kubernetes или нет), дать ему собрать кластер GlusterFS
3. Создать StorageClass
Всё! Провайдер для Heketi есть в Kubernetes очень давно, ничего городить не нужно. Создаете PVC и получаете свой волум.
3.
На этом просто необходимо было остановиться и подумать, а хорошее ли данное решение? Выглядит как-то не очень.
4. Ну и напоследок:
Как считаете, вы достигли этой цели? ;)
1. Давайте начнем с простого. Что же это такое? Обратимся к официальной документации. Я сразу попробую перевести на русский язык:
Heketi предоставляет RESTful API, который можно использовать для управления жизненным циклом томов GlusterFS. Благодаря Heketi Kubernetes может динамически предоставлять тома GlusterFS.
Kubernetes работает с Heketi только в тот момент, когда создает/изменяет/удаляет PersistentVolumeClaim. Для взаимодействия контейнеров с GlusterFS он не нужен, так как вся информация, которая необходима для монтирования волума, содержится в PersistentVolume. Соответственно, и кластеризовать Heketi нет никакого смысла. Нужно только делать бэкапы базы.
2.
Запуск в kubernetes данного сервиса также не подходитRedHat и IBM не в курсе. Вы хоть попробовали разобраться, перед тем как это написать на хабре?
Из-за этого у вас появились какие-то вопросы с Endpoints, потом появился NFS, да еще keepalived. Хотя достаточно было:
1. Установить GlusterFS.
2. Настроить Heketi (не важно, в kubernetes или нет), дать ему собрать кластер GlusterFS
3. Создать StorageClass
Всё! Провайдер для Heketi есть в Kubernetes очень давно, ничего городить не нужно. Создаете PVC и получаете свой волум.
3.
в случае падения основной ноды, будет простой около минуты
На этом просто необходимо было остановиться и подумать, а хорошее ли данное решение? Выглядит как-то не очень.
4. Ну и напоследок:
Хранилище должно быть совместимо с Kubernetes
Как считаете, вы достигли этой цели? ;)
1. Да, пожалуй на отказоустойчивость heketi можно забить, т.к. если PVC был создан, то при последующем запуске пода heketi не нужен. Но, если вы внимательно читали пост, а не мимо строк дабы высказать свое мнение, то вы наверняка заметили, что основной проблемой является mount через gluster, которого у нас нет, как и нет возможности его нормально поставить. Вариант в Endpoint наиболее удобный, если нет нужды динамического создания Volume, и я могу сказать, что довольно часто это не нужно. Таким образом человек, который будет это использовать, избавится от кучи лишних прослоек и будет сам управлять своим стораджем. Я не говорю что heketi — то хорошо или плохо, но я считаю что вполне можно обойтись и без него.
2. Разумеется пробовал. И смысл того, что данный вариант не подходит в том, что база heketi должна быть на диске, а значит либо городить еще одно хранилище, или держать его на одной ноде (возможно в рамках одного ДЦ) и это не дает нужной отказоустойчивости. Плюс, хочу заметить, что я не писал что это не возможно, мысль скорее в том, что смысла тащить в кубер его нет.
3. Так отрабатывает таймаут у маунта. Минутный простой в случае падения одной из нод — это не критично. Как я уже говорил, это далеко не эталонное решение, но кто столкнется с проблемой, может использовать и его.
4. Не так как ожидалось, но цель достигнута.
Еще раз повторюсь, я не утверждаю что это правильно и надо так делать, кому нужно будет, может использовать, кому нет, тот может основываясь на статье принять решение о том, стоит ли им этим заниматься.
2. Разумеется пробовал. И смысл того, что данный вариант не подходит в том, что база heketi должна быть на диске, а значит либо городить еще одно хранилище, или держать его на одной ноде (возможно в рамках одного ДЦ) и это не дает нужной отказоустойчивости. Плюс, хочу заметить, что я не писал что это не возможно, мысль скорее в том, что смысла тащить в кубер его нет.
3. Так отрабатывает таймаут у маунта. Минутный простой в случае падения одной из нод — это не критично. Как я уже говорил, это далеко не эталонное решение, но кто столкнется с проблемой, может использовать и его.
4. Не так как ожидалось, но цель достигнута.
Еще раз повторюсь, я не утверждаю что это правильно и надо так делать, кому нужно будет, может использовать, кому нет, тот может основываясь на статье принять решение о том, стоит ли им этим заниматься.
- Я понял, у вас используется CoreOS, который EOL через месяц, соответственно, в продакшен среде ему не место. Его необходимо обновить до Fedora CoreOS, там такой проблемы нет.
- Вы даже не посмотрели примеры, ссылки на которые я вам дал и снова что-то додумали и на основе этого сделали выводы.
- Тем не менее схд, у которой простой при отработке отказа составляет одну минуту — решение изначально очень плохое. Его не следует использовать в продакшене нигде и никому :). Устаревшая CoreOS — не аргумент.
Интересная, а главное, вполне подробная практическая статья.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
GlusterFS как внешнее хранилище для Kubernetes