Ozon / Озон (системный дизайн) - 2

Актуальность: 2 кв 2025

У компании есть распределенное «облако», состоящее из множества физических серверов, сгруппированных в N (N > 3) разных дата-центров (ЦОД). На этих серверах развертываются кластеры баз данных (Scylla/Cassandra) по следующим правилам:

• Трехзональная репликация: Каждый кластер должен жить ровно в трех ЦОД (то есть для кластера создаются три копии/реплики, по одной в каждом из трех дата-центров). sql/replication-scaling
• Одинаковые ресурсы узлов: Все узлы (ноды) баз данных имеют одинаковые характеристики потребления ресурсов (CPU/RAM/Disk); architecture/system-design
• Изоляция узлов: Ноды одной и той же БД не могут находиться на одном физическом сервере; sql/general
• Выделенные сервера: Некоторые кластеры (или узлы) должны разворачиваться только на выделенных серверах с определенными метками (тегами); architecture/system-design
• Размещение: Нужно учитывать это требование и не размещать такие узлы на обычных серверах. architecture/system-design

На базе этих требований вам необходимо спроектировать две связанные подсистемы: Шедулер (resource manager) и Дешедулер (descheduler).

Шедулер (Resource Manager)

Задача: При получении запроса на создание нового кластера должен: architecture/system-design

• определить, в каких трех ЦОД будут жить реплики (учитывая текущую доступность/загруженность);
• выбрать конкретные физические серверы под узлы, соблюдая правило «одна нода - один физический сервер» и наличие нужных ресурсов;
• если кластер требует «выделенных серверов», шедулер обязан искать только среди помеченных таким образом машин.

Требования к шедулеру

• Учитывать актуальную топологию (расположение ЦОД, доступные сервера, их загруженность и метки); architecture/system-design
• Учитывать заявки на ресурсы (CPU, RAM, Disk); architecture/system-design
• Давать возможность «зарезервировать» ресурсы под заявку, чтобы не было гонки при параллельных запросах; go/concurrency
• Хранить историю размещений и уметь оперативно реагировать, если один из серверов или ЦОД стал недоступен (например, нужно пересоздать часть узлов где-то еще). architecture/system-design

Дешедулер (Descheduler)

Задача: Отслеживать утилизацию ресурсов в дата-центрах и выравнивать нагрузку за счет перезапуска/миграции узлов между ЦОД. Например, если в одном ЦОД много свободных ресурсов, а в другом - перегрузка, дешедулер должен инициировать «перeeзд» части узлов. sql/orm-drivers

Важные моменты

• При «перeeзде» нужно сохранить исходные принципы размещения (3 ЦОД, разные физические сервера и т. д.); architecture/system-design
• Следить, чтобы не нарушить SLA/доступность: например, недопустимо одновременно мигрировать все реплики одного кластера так, чтобы база данных оставалась вообще без работающих узлов; sql/replication-scaling
• Учитывать сложность миграции данных (объемы, сетевые ограничения). architecture/system-design