Persistent Storage для Kubernetes на базе Linstor

[D1abloRUS]

А теперь запустите запись и пороняйте ноды с хранилкой по питанию/сети(не grace), а потом уроните их все и включите обратно

[zamal]

Почему бы и нет)

1. выключаем s2 - запись в pod'e alpine в /data идёт нормально

2. выключаем s3 - запись в pod'e alpine в /data идёт нормально

3. включаем обратно s2 и s3 - запись в pod'e alpine в /data идёт нормально

4. Смотрим на linstor-controller: все ноды linstor-кластера online, все drbd-разделы UpToDate

1. выключаем s1 (там где контроллер) - запись в pod'e alpine в /data идёт нормально

2. выключаем s3 - запись в pod'e alpine в /data идёт нормально

3. включаем обратно s1 и s3 - запись в pod'e alpine в /data идёт нормально.

4. Смотрим на linstor-controller: все ноды linstor-кластера online, все drbd-разделы UpToDate

1. выключаем s1, s2, s3 - в pod'e директория /data становится недоступна (т.е. команда ls -la /data подвисает). Сам pod и процессы в нём работают.

2. включаем s1,s2,s3 - в pod'e директория /data становится доступной, каждые 10 секунд появляется новый файл. Файлов, которые должны были появиться в то время когда s1,s2,s3 были выключены, нет.

3. Смотрим на linstor-controller: все ноды linstor-кластера online, все drbd-разделы UpToDate

[datsen]

Странная получается схема...
- на одной из нод кластера куба, надо иметь свободный диск, в данном примере 10ГБ.
- получается нет смысла создавать отдельные вм под linstor/drbd, проще эти ноды докинуть в кубер.

[zamal]

Не совсем верно. На ноде кубера не нужен свободный диск под PersistentStorage и в нашем примере его как раз нет. На нодах кубера linstor работает в Diskless-режиме, т.е. он все данные синхронизирует по сети.

Нода kuber работает в Diskless-режиме

Смысл создания отдельных вм под линстор, который пока приходит в голову:

• линстор-хранилище можно подключить к нескольким кубер-кластерам одновременно;

• больше гибкость для сопровождения: можно добавлять/убавлять/обновлять/перезагружать ноды не трогая кубер-кластер;

• при большой инфраструктуре и наличии штата, администрирование кубера можно отдать одной структуре ИТ Департамента, а дисковые хранилища другой. Так сотрудники не будут мешать друг другу и валить друг на друга проблемы.

[ashkraba]

Рабочая схема. Использую нечто подобное в проде уже два года - проблем не было от слова совсем. Собрано на нодах proxmoxa, стораджи подкинуты и в сам proxmox и в кубернетес кластера - полет нормальный. Так что рекомендую.)

Но схд в fiberchannel всё-таки надёжнее)

[Mike_Mihalych]

А много у вас узлов в кластере?

[vuidji]

А longhorn обладает какими-то недостатками по сравнению с предложенным решением?

[zamal]

К сожалению не скажу. Опыт использования longhorn не очень большой. Был только один кубер-кластер k3s с longhorn установленным прямо на воркерах кластера. Через пару-тройку месяцев отказались от него в пользу linstor, т.к. он показался более перспективным.

[ashkraba]

Он в разы медленнее

[zabit]

Не понимаю автора статьи, зачем все это делать руками когда есть piraeus-operator

[zamal]

piraeus-operator установит вам linstor-хранилище только на воркерах кубер-кластера. Т.е. к виртуалкам с воркерами должны быть подключены отдельные диски для линстора. И сам линстор-кластер будет внутри кубера.

В статье описан способ организовать линстор-кластер вне кубера. Из плюсов этого способа:

• линстор-хранилище можно подключить к нескольким кубер-кластерам одновременно;

• больше гибкость для сопровождения: можно добавлять/убавлять/обновлять/перезагружать ноды не трогая кубер-кластер;

• при большой инфраструктуре и наличии штата, администрирование кубера можно отдать одной структуре ИТ Департамента, а дисковые хранилища другой. Так сотрудники не будут мешать друг другу и валить друг на друга проблемы.

[azzii]

Спасибо, интересно. Жаль автор не рассказал про фактическую емкость и репликацию. И что выбор не ограничивается zfs и причинах его выбора. И тестов бы производительности в сравнении просто с выданным диском, в том числе при отказах. Распределенные системы дороги за счёт количества реплик и большого пенальти на операции, все прекрасно, пока дело не доходит до iops.

[zamal]

В рамках данной статьи был рассмотрен способ настройки линстор-кластера и подключение его к куберу.

Тесты на скорость и стабильность работы ожидайте в последующих статьях)

[azzii]

Было бы интересно еще сравнение с longhorn и ceph в тех же сценариях. Идеи для будущих статей=)