Rook или не Rook — вот в чём вопрос

[de1m]

Спасибо за статью, я к нему уже давно пристматриваюсь. Мне вот интересно если весь кластер сломается. Его (rook) можно будет потом востановить. В смысле данные то останутся, но на сколько это проблемно их опять в кластер получить?
У меня раз кластер ломался, я как представлю, что при этом ещё и данные надо как-то востанавливать.

[monester]

Сам rook не сломается, а вот сломанный ceph востановить будет сложно — rook генерирует конфиги через init контейнеры и это сильно усложняет процесс.

[amarao]

Мой опыт с k8s в районе persistent volumes показал, что оно не плохо, а катастрофически плохо (т.е. плохо во время катастроф). Без адекватного STONITH оно жить не сможет, а STONITH в k8s не завезли.

А как сделать "плохо"? Ну, например, во время установки stp-соединения не закрыть канал. Раз 8 или 16.

Вы думаете, что у вас в инсталляции нет STP? А если найду? STP находится где-то между SAS HBA и SAS Enclosure, а цифра 8 или 16 соответствует wide port в SAS.

Что происходит после того, как все 16 каналов заняты? Теоретически, контроллер должен послать bus/host reset, но тут интрига: не проходит.

С практической стороны это выглядит как TASK_UNINTERRUPTIBLE (D+) и делай что хочешь. В силу устройства контейнеров, пока все процессы не прибъёшь — pod живёт. А если процесс игнорирует ваши просьбы-9? Продолжает жить. Если pod продолжает жить, deploy не видит смысла спанить ещё один.

[gecube]

Это из серии — как заюзать хайповую технологию, обрадоваться как круто и здорово, а потом потерять все данные заказчика-клиента одним махом. Магия хороша, пока она работает. Но если она ломается… Ну, вы поняли )))