Масштабируемость хранилища ломается не на объёме, а на границах отказа и перекосах нагрузки

Масштабируемость хранилища ломается не на объёме, а на границах отказа и перекосах нагрузки

Распределённое хранилище можно расширять почти бесконечно только на бумаге. На практике узкие места появляются в трёх местах: метаданные, ребалансировка и сетевой слой. Если каталог объектов живёт на одном узле, а данные разложены по десяткам дисков, система упрётся не в ёмкость, а в операции поиска, размещения и восстановления.

Анализ показал, что для проверки масштаба важнее смотреть не на среднюю загрузку, а на поведение под неравномерным доступом:
— растёт ли latency при отказе одного узла;
— сколько времени занимает перераспределение фрагментов;
— не создаёт ли репликация «горячие» сегменты;
— сохраняется ли предсказуемость при росте числа клиентов и shard’ов.

Рассмотрим архитектурный срез по данному узлу. Если при расширении кластера меняется только объём, но не модель размещения, система начинает деградировать ступенчато: сначала растёт очередь на запись, затем замедляется восстановление, потом увеличивается окно уязвимости при сбое. Особенно часто это видно там, где нет явного ограничения на размер shard’а и отсутствует контроль баланса по дискам, а не только по серверам.

Рекомендуется обращать внимание на три вещи: детерминированное размещение, ограничение домена отказа и дешёвую перестройку данных. Если эти механизмы не описаны заранее, масштабирование превращается в постоянную операцию ручного выравнивания, а не в свойство системы.