Pull to refresh

Comments 7

А как проблему со splitbrain решаете?
В статье нет ничего про случай, если оба ДЦ работают, но потеряли связь друг с другом.

Хороший вопрос! В случае потери связи между дата центрами обе реплики SQL-базы данных станут мастерами, и сообщение об этом высылается админам. Чтобы не разъехались данные, админы настраивают балансер HAProxy или DNS Round Robin так, чтобы весь трафик пошел в выбранный ими дата центр. Реплика SQL-базы данных выбранного дата центра становится мастером после восстановления связи между дата центрами.

Ну сам по себе старый мастер слейвом же не станет?

У ДЦ выключается сеть, происходит splitbrain, ДЦ без сети (точнее, база) продолжает считать себя мастером (и переключить её невозможно, т.к. сети нет), haproxy в этом ДЦ продолжает проксировать трафик туда.

Или есть стопкран/арбитр/etc?

Можно в облаке поставить небольшой VPS, установить в него скрипт, отслеживающий ситуацию, когда оба стали мастерами, и гасить один из дата центров. При этом внешний балансер HAProxy автоматически сделает keep-alive чек и направит трафик в выживший дата центр.

Благодарю за статью!
Etcd позиционирует себя как "высокоскоростное" хранилище key-value, и возникает вопрос - а не сравнивали ли случайно производительность API kubernetes с etcd и c kine+pg? Или может kine берет на себя какие-то кеширующие задачи а "исторические" данные закидывает в pg? Сам с kine не работал - очень интересно стало.

Спасибо за фидбек. К сожалению производительность API Kubernetes с etcd и SQL-базой данных не сравнивали. Просто не совсем понятна методика тестирования. Если есть возможность, подскажите методику мы с удовольствием протестируем и отпишемся о результатах. Про кэширование в Kine информации не встречали. Тут только смотреть код

На самом деле предполагал даже не сколько сам ETCD, сколько его в связке с API Kubernetes на условные чтение-запись, просаживается ли и сильно ли.
В целом еще раз спасибо за статью, возможно с коллегами тоже пощупаем данный подход и проверим.

Sign up to leave a comment.