В чём ключевое различие между схемами active-active и active-passive при отказе одного экземпляра?
В схеме active-active трафик одновременно обслуживают несколько экземпляров, поэтому при отказе одного из них запросы можно направить на уже работающие экземпляры. В схеме active-passive резервный экземпляр не обслуживает основной трафик до переключения, поэтому отказ требует обнаружения, активации резерва и перенаправления запросов. Обычно active-active обеспечивает меньшее время восстановления и лучше использует ресурсы, но сложнее с точки зрения согласованности состояния и балансировки нагрузки.
Подходы появились как способы уменьшить последствия отказа отдельных компонентов без ожидания их ручного восстановления. Резервирование позволяло сохранить работоспособность сервиса, но не решало автоматически вопрос времени переключения, доступности резервных ресурсов и актуальности данных.
Схема active-passive проще для систем, где одновременно безопасно работать может только один экземпляр, например при наличии локального состояния или ограничений на запись. Active-active стала особенно полезна там, где важны высокая доступность, равномерное использование вычислительных ресурсов и быстрое продолжение обслуживания при отказе узла.
Если весь трафик направлен на один активный экземпляр, его отказ прекращает обслуживание до завершения переключения. На результат влияют время обнаружения отказа, запуск или расконсервация резерва, обновление маршрутизации и готовность зависимостей.
Если несколько экземпляров активны одновременно, отказ одного из них обычно не прерывает обслуживание полностью. Однако система должна корректно распределять запросы, исключать неисправные экземпляры и решать проблему общего состояния; иначе активная работа нескольких копий может привести к конфликтам или потере данных.
В active-active балансировщик или маршрутизатор направляет запросы на несколько здоровых экземпляров. При отказе одного экземпляра проверки состояния убирают его из набора доступных, а оставшиеся принимают его нагрузку. Это уменьшает зависимость от отдельной процедуры переключения, но требует, чтобы оставшиеся экземпляры имели достаточный запас производительности.
В active-passive только активный экземпляр принимает основной трафик, а пассивный ожидает. После обнаружения отказа система назначает резерв активным и изменяет маршрут. Такая схема проще для состояния и записи, но её RTO обычно включает время обнаружения, переключения и прогрева резерва; кроме того, неиспользуемый резерв может скрывать проблемы до момента отказа.
Главный компромисс — простота против скорости и эффективности. Active-passive легче контролировать для stateful-компонентов, но требует расходов на резервную мощность и проверки готовности. Active-active лучше использует ресурсы и может пережить отказ без заметного переключения, однако требует идемпотентности операций, корректной синхронизации данных, защиты от split-brain и тщательного контроля перегрузки после отказа.
Нельзя считать экземпляр готовым только потому, что его процесс запущен. Для обеих схем важно проверять способность реально обслуживать запросы, а при active-active дополнительно учитывать, что после отказа оставшиеся экземпляры могут получить существенно большую нагрузку и сами начать деградировать.
Платформа обработки заказов работала в двух экземплярах. Вариант active-passive давал понятную модель записи: один экземпляр владел рабочим состоянием, а резерв включался после отказа. Его минусами были заметное время переключения и необходимость регулярно тестировать, действительно ли резерв способен быстро принять нагрузку.
Вариант active-active позволял распределять заказы между экземплярами и переживать отказ одного узла почти без паузы. Но потребовались идемпотентные операции, общий источник состояния и защита от ситуации, при которой оба экземпляра считают себя владельцами одной операции.
Выбрали active-active для обработки запросов чтения и независимых операций, а последовательные изменения состояния направили через механизм, гарантирующий единственного владельца операции. Это сохранило быстрый отвод трафика от отказавшего узла, не распространяя сложную модель совместной записи на все операции.
Нет. Если каждый экземпляр работает почти на предельной мощности, отказ одного может перегрузить оставшийся, и формальная схема active-active не обеспечит фактическую доступность. Нужно заранее проверять сценарий отказа при пиковом трафике и оставлять запас мощности либо применять контролируемое ограничение нагрузки.
Кроме того, балансировщик должен исключать неисправный экземпляр достаточно быстро, но не настолько агрессивно, чтобы кратковременные сбои вызывали постоянное выведение и возвращение узлов. Параметры проверок состояния являются компромиссом между скоростью реакции и риском ложного переключения.
Если операция имеет побочный эффект, повторная доставка или одновременная обработка на разных экземплярах может выполнить её дважды. Например, после сетевого тайм-аута клиент не знает, была ли операция принята, и отправляет её повторно; без идемпотентного ключа обе попытки могут изменить состояние.
Защита обычно включает идемпотентность, уникальные идентификаторы операций, атомарную фиксацию результата и явную модель повторов. Простое наличие нескольких экземпляров не гарантирует согласованность: её нужно обеспечивать на уровне хранилища и протокола обработки.
Если старый активный экземпляр временно потерял связь с системой управления, но продолжает принимать запросы, резерв может быть активирован параллельно. Оба экземпляра тогда считают себя владельцами роли — это состояние называют split-brain.
Для снижения риска применяют fencing или другой механизм принудительного лишения старого владельца права изменять состояние, а также используют арбитраж при спорном выборе лидера. Одного тайм-аута недостаточно: он помогает обнаружить подозрение на отказ, но сам по себе не доказывает, что старый экземпляр действительно прекратил работу.