piraeus-operator установит вам linstor-хранилище только на воркерах кубер-кластера. Т.е. к виртуалкам с воркерами должны быть подключены отдельные диски для линстора. И сам линстор-кластер будет внутри кубера.
В статье описан способ организовать линстор-кластер вне кубера. Из плюсов этого способа:
линстор-хранилище можно подключить к нескольким кубер-кластерам одновременно;
больше гибкость для сопровождения: можно добавлять/убавлять/обновлять/перезагружать ноды не трогая кубер-кластер;
при большой инфраструктуре и наличии штата, администрирование кубера можно отдать одной структуре ИТ Департамента, а дисковые хранилища другой. Так сотрудники не будут мешать друг другу и валить друг на друга проблемы.
К сожалению не скажу. Опыт использования longhorn не очень большой. Был только один кубер-кластер k3s с longhorn установленным прямо на воркерах кластера. Через пару-тройку месяцев отказались от него в пользу linstor, т.к. он показался более перспективным.
Не совсем верно. На ноде кубера не нужен свободный диск под PersistentStorage и в нашем примере его как раз нет. На нодах кубера linstor работает в Diskless-режиме, т.е. он все данные синхронизирует по сети.
Нода kuber работает в Diskless-режиме
Смысл создания отдельных вм под линстор, который пока приходит в голову:
линстор-хранилище можно подключить к нескольким кубер-кластерам одновременно;
больше гибкость для сопровождения: можно добавлять/убавлять/обновлять/перезагружать ноды не трогая кубер-кластер;
при большой инфраструктуре и наличии штата, администрирование кубера можно отдать одной структуре ИТ Департамента, а дисковые хранилища другой. Так сотрудники не будут мешать друг другу и валить друг на друга проблемы.
выключаем s2 - запись в pod'e alpine в /data идёт нормально
выключаем s3 - запись в pod'e alpine в /data идёт нормально
включаем обратно s2 и s3 - запись в pod'e alpine в /data идёт нормально
Смотрим на linstor-controller: все ноды linstor-кластера online, все drbd-разделы UpToDate
выключаем s1 (там где контроллер) - запись в pod'e alpine в /data идёт нормально
выключаем s3 - запись в pod'e alpine в /data идёт нормально
включаем обратно s1 и s3 - запись в pod'e alpine в /data идёт нормально.
Смотрим на linstor-controller: все ноды linstor-кластера online, все drbd-разделы UpToDate
выключаем s1, s2, s3 - в pod'e директория /data становится недоступна (т.е. команда ls -la /data подвисает). Сам pod и процессы в нём работают.
включаем s1,s2,s3 - в pod'e директория /data становится доступной, каждые 10 секунд появляется новый файл. Файлов, которые должны были появиться в то время когда s1,s2,s3 были выключены, нет.
Смотрим на linstor-controller: все ноды linstor-кластера online, все drbd-разделы UpToDate
В рамках данной статьи был рассмотрен способ настройки линстор-кластера и подключение его к куберу.
Тесты на скорость и стабильность работы ожидайте в последующих статьях)
piraeus-operator установит вам linstor-хранилище только на воркерах кубер-кластера. Т.е. к виртуалкам с воркерами должны быть подключены отдельные диски для линстора. И сам линстор-кластер будет внутри кубера.
В статье описан способ организовать линстор-кластер вне кубера. Из плюсов этого способа:
линстор-хранилище можно подключить к нескольким кубер-кластерам одновременно;
больше гибкость для сопровождения: можно добавлять/убавлять/обновлять/перезагружать ноды не трогая кубер-кластер;
при большой инфраструктуре и наличии штата, администрирование кубера можно отдать одной структуре ИТ Департамента, а дисковые хранилища другой. Так сотрудники не будут мешать друг другу и валить друг на друга проблемы.
К сожалению не скажу. Опыт использования longhorn не очень большой. Был только один кубер-кластер k3s с longhorn установленным прямо на воркерах кластера. Через пару-тройку месяцев отказались от него в пользу linstor, т.к. он показался более перспективным.
Не совсем верно. На ноде кубера не нужен свободный диск под PersistentStorage и в нашем примере его как раз нет. На нодах кубера linstor работает в Diskless-режиме, т.е. он все данные синхронизирует по сети.
Смысл создания отдельных вм под линстор, который пока приходит в голову:
линстор-хранилище можно подключить к нескольким кубер-кластерам одновременно;
больше гибкость для сопровождения: можно добавлять/убавлять/обновлять/перезагружать ноды не трогая кубер-кластер;
при большой инфраструктуре и наличии штата, администрирование кубера можно отдать одной структуре ИТ Департамента, а дисковые хранилища другой. Так сотрудники не будут мешать друг другу и валить друг на друга проблемы.
Здесь подключаем к кластеру PersistentStorage
https://habr.com/ru/articles/847568/comments/
Почему бы и нет)
выключаем s2 - запись в pod'e alpine в /data идёт нормально
выключаем s3 - запись в pod'e alpine в /data идёт нормально
включаем обратно s2 и s3 - запись в pod'e alpine в /data идёт нормально
Смотрим на linstor-controller: все ноды linstor-кластера online, все drbd-разделы UpToDate
выключаем s1 (там где контроллер) - запись в pod'e alpine в /data идёт нормально
выключаем s3 - запись в pod'e alpine в /data идёт нормально
включаем обратно s1 и s3 - запись в pod'e alpine в /data идёт нормально.
Смотрим на linstor-controller: все ноды linstor-кластера online, все drbd-разделы UpToDate
выключаем s1, s2, s3 - в pod'e директория /data становится недоступна (т.е. команда ls -la /data подвисает). Сам pod и процессы в нём работают.
включаем s1,s2,s3 - в pod'e директория /data становится доступной, каждые 10 секунд появляется новый файл. Файлов, которые должны были появиться в то время когда s1,s2,s3 были выключены, нет.
Смотрим на linstor-controller: все ноды linstor-кластера online, все drbd-разделы UpToDate