Comments 11
В случае падения ведущего дата центра, в ведомом дата центре следует выполнить следующие действия
На этом слово Highly можно удалять.
Все действия по переключению в выживший дата центр автоматизированы в скриптах и происходят довольно быстро. Какое же слово нам использовать вместо Highly? )
Пришлось пойти на небольшой downtime в пользу снижения затрат на инфраструктуру, чтобы построить решение на два дата центра вместо трех. Если мы не ошибаемся, Highly Available это все-таки минимизация времени незапланированных простоев.
Время на реакцию и действия умножить на 2 потенциальных инцидента в год (а их легко может быть больше) и вот уже в 4 девятки вписаться вряд ли получится. Даже если скрипты отрабатывают за секунду, наличие необходимости реагировать сотруднику очень быстро понижает доступность.
>...модули плоскости управления Kubernetes.
Подскажите, что такое плоскость управления?
Компоненты Kubernetes | Kubernetes модули в пунктирном прямоугольнике Kubernetes Control Plane
Это не самый удачный перевод control plane, который был когда-то давно принесён в русскоязычную версию документации Kubernetes, но мы от него отказались (в пользу «управляющего слоя»). Хотя вижу, что осталось ещё [как минимум] одно упоминание по приведённой ссылке — пройдусь ещё раз grep'ом, чтобы избавиться от этого.
Спасибо, что поправили! Теперь будем использовать термин "управляющий слой" вместо "плоскость управления". Похоже еще одно упоминание в документации осталось вот тут Компоненты Kubernetes | Kubernetes
PV над NFS... Ну допустим, хотя применимость весьма ограничена, не знаю что там ваши компоненты делают. Отказоустойчивость NFS через DRBD? Тут уже стоит хорошенько задуматься. DRBD между ДЦ - а вы проверяли как хорошо это работает? Обычно это ужасная идея.
2 зоны для отказоустойчивой системы? Окей, раз переключение вручную. Но если переключение вручную, то может это уже disaster recovery и стоит рассмотреть более простые и надёжные инструменты с чуть худшим RPO? Насколько это критично для CI/CD?
Почему не запустить три копии системы в разных ДЦ, и не реализовать масштабируемость и отказоустойчивость на прикладном уровне, а не на уровне платформы?
Про требования DRBD к пропускной способности сети, пожалуй, стоило упомянуть в статье. Мы тестировали скорость записи на DRBD-разделы для двух нод, разнесенные в разные дата центры. iperf между дата центрами показал 150Kbps, а ping 38ms. В синхронном режиме репликации "C" скорость записи на DRBD-раздел составила 12MB/s, в асинхронном режиме "B" - 26MB/s и в асинхронном режиме "A" - 95MB/s. Далее можно экстраполировать и прикинуть, какая пропускная способность сети потребуется, чтобы достичь скорости записи HDD или SSD.
disaster recovery - это точное название тому, что мы спроектировали. Набор инструментов был заранее задан.
3 копии в разных ДЦ - это верное решение, но у нас изначально задумка была, сделать проще и дешевле. На уровне приложений пока не удается реализовать отказоустойчивость - Gitea/Forgejo лочит файл и не дает запустить вторую реплику в соседнем дата центре.
CI/CD Kubernetes платформа Gitorion. Highly Available исполнение