Оцените, почему увеличение числа реплик не повышает устойчивость данных, если все реплики размещены в одном домене отказа.
Число реплик повышает устойчивость только к независимым отказам. Если все реплики находятся в одном домене отказа — например, на одном физическом узле, в одной зоне доступности или в одном электропитании, — единый отказ может уничтожить или одновременно сделать недоступными все копии.
Реплики нужно распределять между доменами отказа, а выбранную схему размещения согласовывать с моделью отказов и требованиями к задержке, стоимости и доступности.
Репликация появилась как способ переживать отказ отдельных компонентов без потери данных и длительного простоя. Однако ранние или наивные схемы часто копировали данные только между логическими узлами, не учитывая их физическую общность.
Практика эксплуатации показала, что отказ обычно затрагивает не случайный один узел, а целую группу: сервер, стойку, зону доступности, регион, систему питания или сетевой сегмент. Поэтому надёжность стали оценивать не только по числу копий, но и по их независимости.
Пусть данные хранятся на пяти репликах, но все они находятся на серверах одной стойки. Отказ стойки из-за питания, перегрева или сетевого оборудования одновременно выводит из строя все пять копий.
В такой ситуации коэффициент репликации равен пяти, но эффективное количество независимых копий с точки зрения отказа стойки — одному. Если система подтверждает запись после сохранения внутри этого домена, подтверждение не защищает от его полной потери.
Неверное размещение создаёт ложное ощущение надёжности: метрики показывают много реплик, а фактическая вероятность потери данных почти не уменьшается для коррелированного отказа.
Сначала определяют домен отказа — набор компонентов, которые могут выйти из строя по одной причине. Затем реплики размещают так, чтобы критичный отказ не затрагивал все подтверждённые копии. Например, для защиты от отказа сервера реплики разносят по серверам, для защиты от отказа стойки — по стойкам, для защиты от отказа зоны — по зонам доступности.
Важно различать репликацию и размещение реплик. Репликация создаёт копии, а политика размещения определяет, насколько независимы эти копии. Увеличение числа реплик в одном домене может улучшить пропускную способность чтения, но почти не улучшить сохранность при отказе самого домена.
Подтверждение записи также должно учитывать домены отказа. Если запись считается принятой после подтверждения двух реплик, расположенных в одной зоне, это не гарантирует сохранность при потере зоны. Для нужной гарантии подтверждения должны приходить от требуемого числа независимых доменов.
У распределения есть компромиссы. Размещение по зонам или регионам увеличивает сетевую задержку, стоимость передачи и сложность восстановления, а синхронное ожидание удалённой реплики может снизить доступность при проблемах связи. Поэтому часто используют минимально достаточное число копий в разных доменах и отдельно определяют, какие отказы система обязана переживать.
Нужно учитывать и скрытые общие зависимости: общий кластер хранения, один сетевой коммутатор, единый источник питания, общую систему управления или одинаковую ошибочную конфигурацию. Формальное размещение на разных серверах не делает копии независимыми, если они используют общий критичный компонент.
Сервис хранит пользовательские данные на трёх репликах. Сначала все реплики размещают в одной зоне доступности: это даёт низкую задержку и небольшую стоимость, но отказ зоны делает данные недоступными одновременно.
Вариант с пятью репликами в той же зоне повышает запас при отказе отдельных серверов и может ускорить чтение, но почти не защищает от отказа зоны. Вариант с тремя репликами в трёх зонах лучше защищает данные, однако увеличивает задержку записи и стоимость межзонного трафика.
Выбирают третий вариант: запись подтверждается после сохранения в минимальном числе независимых зон, достаточном для заявленной гарантии, а дополнительные копии используются для восстановления и чтения. В результате отказ одного сервера или зоны не приводит к потере всех подтверждённых копий, хотя система принимает более высокую стоимость и задержку записи.
1. Дополнительный вопрос: достаточно ли разместить реплики в разных серверах одной зоны?
Нет, если требуется переживать отказ зоны. Такое размещение защищает от отказа отдельного сервера, но не от общей инфраструктуры зоны: питания, сетевого оборудования, системы охлаждения или крупной ошибки управления. Гарантия определяется самым крупным отказом, который реплики ещё имеют общий.
2. Дополнительный вопрос: делает ли межзонное размещение запись безопасной автоматически?
Нет. Реплики могут находиться в разных зонах, но запись может подтверждаться только локальной репликой или ещё не успеть дойти до удалённых копий. Для гарантии нужно определить, какие копии считаются достаточными для подтверждения, и связать это правило с требуемым сценарием отказа.
Кроме того, при асинхронной репликации потеря зоны может привести к потере последних неподтверждённых или ещё не переданных изменений. Межзонное размещение уменьшает риск, но не заменяет правильно выбранную семантику подтверждения.
3. Дополнительный вопрос: почему три реплики в трёх зонах не всегда лучше пяти реплик в двух зонах?
Потому что число реплик и число независимых доменов решают разные задачи. Пять копий могут давать больше запасных экземпляров и лучшую способность обслуживать чтения, но при отказе одной из двух зон оставшиеся копии могут оказаться в одной зоне или потерять необходимый кворум.
Три реплики в трёх зонах обеспечивают более равномерное распределение по этим доменам, но оставляют меньший запас при последовательных отказах или длительном восстановлении. Выбор зависит от модели отказов, требований к кворуму, допустимой потери данных, задержки и стоимости; универсального оптимального числа реплик нет.