Планирование ёмкости хранилища

Планирование ёмкости хранилища — это определение требуемого количества физических дисков для хранения заданного объёма данных с учётом репликации и накладных расходов, а также обратная задача: оценка полезного объёма данных для заданного количества оборудования.

Модель распределённого хранилища

На уровне оборудования кластер YDB включает в себя некоторое количество физических дисков (HDD / SSD / NVMe). Остальные компоненты (CPU, RAM, сеть) в данной статье не рассматриваются.

Кластеры YDB являются мультитенантными, и один физический диск может совместно использоваться несколькими потребителями — изолированными базами данных. Поверх каждого физического диска запущено по одному компоненту для работы с ним — PDisk. Ресурсы одного PDisk (IOPS, полоса на чтение и на запись, ёмкость) делятся на равные доли, именуемые слотами. Слоты резервируются для создания логических (виртуальных) дисков VDisk. За каждым VDisk закреплён один слот.

Для управления ресурсами пользователю доступна сущность группы хранения. Группа хранения представляет собой совокупность из нескольких VDisk на разных серверах, обеспечивающих отказоустойчивость наподобие RAID. Количество VDisk в группе хранения определяется режимом работы кластера:

* Значения 8 для block-4-2 и mirror-3of4, а также 3 для mirror-3-dc — это минимально необходимое количество стоек для обеспечения работоспособности кластера. При такой конфигурации кластер запускается и работает, но не имеет запаса для самовосстановления: при отказе стойки её VDisk'и некуда переселить в рамках модели отказа, и любой дополнительный сбой может привести к недоступности данных. Дополнительные стойки нужны механизму SelfHeal, чтобы перенести VDisk'и с отказавшей стойки на оставшееся оборудование с сохранением гарантий отказоустойчивости. Поэтому для практической эксплуатации рекомендуется использовать не менее 10 стоек для block-4-2 и mirror-3of4, и не менее 4 стоек для mirror-3-dc. Подробнее о режимах хранения и гарантиях отказоустойчивости см. Топология кластера YDB.

** Для режима mirror-3-dc в штатном режиме RF = 3 (3 копии данных). При недоступности одного дата-центра запись идёт в 4 копии (по 2 в оставшихся дата-центрах), и нагрузка на оставшиеся ДЦ удваивается. Если ДЦ может быть недоступен длительно (или дата-центры выводятся в обслуживание по очереди), необходимо закладывать RF = 6. Если допустимы только краткосрочные отказы (восстановление быстрее, чем система успевает перезаписать существенную долю данных), достаточно RF = 3. Подробнее о режимах хранения и гарантиях отказоустойчивости см. Топология кластера YDB.

С точки зрения пользователя группу хранения можно воспринимать как фиксированный набор ресурсов: IOPS, полоса на чтение и на запись, ёмкость. Каждой базе данных принадлежит одна или более групп хранения. Каждая группа хранения принадлежит одной определённой базе данных.

Пользовательские таблицы состоят из таблеток. Каждая таблетка управляет фрагментом пользовательских или системных данных. Таблетки хранят данные в группах, каждая таблетка может записывать данные в несколько групп хранения, в каждую группу хранения пишут множество таблеток.

Используемые величины

Tablet Storage — это суммарный объём данных, хранимый таблетками базы.

Database Storage — это суммарный размер, аллоцированный VDisk'ами базы. Этот размер включает в себя:

• собственно данные, записанные таблетками;
• избыточность при репликации или кодировании с исправлением ошибок;
• служебные метаданные и журналы;
• аллоцированное, но реально не используемое место.

Для существующих баз значения Tablet Storage и Database Storage можно посмотреть в YDB UI на странице базы на вкладке Info → Storage.

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

Другие накладные расходы могут существенно варьироваться в зависимости от характера хранимых данных и нагрузки. Для грубой оценки можно считать Overhead = 2 — это медианное значение, полученное эмпирически на выборке продуктивных баз в режиме mirror-3-dc. В зависимости от режима, структуры данных и характера нагрузки накладные расходы могут существенно отличаться. Для более точной оценки рекомендуется проведение пилотного эксперимента.

Связать эти величины можно приблизительно через соотношение:

Database Storage = Tablet Storage × RF × Overhead

Оценка требуемого оборудования

Задача сводится к тому, чтобы подобрать конфигурацию кластера так, чтобы данные гарантированно поместились в группы хранения и в кластере остался рабочий запас пустых слотов для обеспечения отказоустойчивости.

Входные параметры:

• Tablet Storage — полезный объём данных, которые необходимо разместить.
• DriveSize — ёмкость используемых дисков.

Искомые параметры (конфигурация кластера):

• NumRacks — количество стоек / серверов (доменов отказа)
• DisksPerRack — количество дисков в каждом домене отказа.

Референсные значения:

• RF — фактор избыточности, определяется режимом работы кластера (см. таблицу выше).
• Overhead — накладные расходы хранилища (см. раздел выше); для грубой оценки принять 2.
• ExpectedSlotCount — количество слотов на PDisk; определяется характеристиками диска — IOPS и полосой на чтение и на запись. Типовые значения: 8 для HDD, 16 для SSD/NVMe.
• VDisksInGroup — количество VDisk в группе хранения, определяется режимом работы кластера (см. таблицу выше).

Для оценки требуемого оборудования выполните следующие шаги.

1. Оцените требуемый объём Database Storage:

   Database Storage = Tablet Storage × RF × Overhead
   

2. Определите размер слота:

   SlotSize = (DriveSize - 27.65 GB) / ExpectedSlotCount
   

   Около 27.65 ГБ ёмкости PDisk зарезервировано для системных нужд, остальное место поровну распределяется между слотами.

   Данная формула применима для дисков объёмом от 800 ГБ. Использование дисков меньшего размера не рекомендуется, если необходимо достижение оптимальной производительности. Подробнее о требованиях к дисковой подсистеме читайте в разделе Системные требования и рекомендации для YDB.

3. Оцените количество групп хранения:

   TotalGroups = ceil( Database Storage / (SlotSize × VDisksInGroup × 0.85) )
   

   Коэффициент 0.85 отражает рекомендуемый процент заполнения VDisk (VDisk Raw Usage = 85%).

   При мониторинге рекомендуется ориентироваться на значения VDisk Slot Usage и Capacity Alert. Для существующих групп значения VDisk Raw Usage, VDisk Slot Usage и Capacity Alert можно посмотреть в YDB UI на вкладке Info → Storage страницы базы.

   Порог, при котором группа считается переполненной, соответствует значениям VDisk Slot Usage = 100%, Capacity Alert = LightYellow, VDisk Raw Usage ≈ 90% — тогда как формула выше оставляет запас до этого порога.

4. Оцените количество занятых слотов:

   UsedSlots = TotalGroups × VDisksInGroup
   

5. Получите нижнюю оценку требуемого числа физических дисков (без учёта запаса на отказоустойчивость):

   TotalPDisks ≥ ceil( UsedSlots / ExpectedSlotCount )
   

6. Выберите конфигурацию кластера — параметры NumRacks, DisksPerRack, и определите минимально необходимый общий запас пустых слотов в кластере:

   TotalSlots    = NumRacks × DisksPerRack × ExpectedSlotCount
   MinEmptySlots = ceil( MaxSlotsInRack + 0.027 × TotalSlots )
   

   Запас пустых слотов необходим для нормальной работы механизма SelfHeal, выполняющего автоматическую реконфигурацию групп хранения для замены вышедших из строя или длительное время недоступных дисков.

   Первое слагаемое MaxSlotsInRack — максимальное количество слотов в одном домене отказа. Для однородного кластера MaxSlotsInRack = DisksPerRack × ExpectedSlotCount, для неоднородного — MaxSlotsInRack = max_i(DisksPerRack_i × ExpectedSlotCount). Этот запас необходим, чтобы при отказе наиболее ёмкого домена его VDisk'и могли уместиться на оставшемся оборудовании.

   Второе слагаемое 0.027 × TotalSlots — эмпирически подобранный операционный запас (~1 диск на 37), покрывающий внеплановую замену отдельных дисков.

7. Оцените соответствие конфигурации минимальным требованиям:

   EmptySlots = TotalSlots - UsedSlots
   

   Должно выполняться условие EmptySlots ≥ MinEmptySlots. Если условие не выполняется, увеличьте NumRacks или DisksPerRack и вернитесь к шагу 6. См. Пример расчёта.

Оценка полезной ёмкости хранилища

Обратная задача — оценить, какой полезный объём данных можно разместить на заданном количестве оборудования.

Пусть имеется TotalPDisks физических дисков ёмкостью DriveSize каждый. Тогда:

1. Общее количество слотов:

   TotalSlots = TotalPDisks × ExpectedSlotCount
   

2. Часть слотов остаются пустыми для запаса на SelfHeal, остальные доступны для групп хранения:

   MinEmptySlots = ceil( MaxSlotsInRack + 0.027 × TotalSlots )
   UsableSlots = TotalSlots - MinEmptySlots
   

   Здесь MaxSlotsInRack — максимальное количество слотов в одном домене отказа (стойке или сервере): для однородного кластера DisksPerRack × ExpectedSlotCount, для неоднородного — max_i(DisksPerRack_i × ExpectedSlotCount).

3. Количество групп хранения:

   TotalGroups = floor( UsableSlots / VDisksInGroup )
   

4. Полезная ёмкость распределённого хранилища с учётом порога заполнения 85%:

   Database Storage = TotalGroups × VDisksInGroup × SlotSize × 0.85
   

5. Оценка полезного объёма данных:

   Tablet Storage = Database Storage / (RF × Overhead)
   

Пример расчёта

Допустим, необходимо разместить 100 ТБ данных (Tablet Storage) в кластере с режимом отказоустойчивости block-4-2, используя SSD-диски ёмкостью 3.2 ТБ.

Исходные параметры:

Расчёт:

1. Database Storage = 100 000 × 1.5 × 2 = 300 000 ГБ

2. SlotSize = (3 200 − 27.65) / 16 ≈ 198.27 ГБ

3. TotalGroups = ⌈300 000 / (198.27 × 8 × 0.85)⌉ = 223 группы хранения

4. UsedSlots = 223 × 8 = 1 784 слота

5. TotalPDisks (без запаса) = ⌈1 784 / 16⌉ = 112 дисков

6. Далее выберем конкретную конфигурацию кластера, предусмотрев запас пустых слотов для обеспечения отказоустойчивости. Для этого рассмотрим различные варианты оборудования и оценим соответствие минимальным требованиям, учитывая что для режима block-4-2 требуется минимум 8 доменов отказа (серверов или стоек), а для устойчивой практической эксплуатации рекомендуется 10 и более:

   • Возьмем 10 стоек по 12 дисков. В одной стойке 12 × 16 = 192 слота, TotalSlots = 1 920. MinEmptySlots = ⌈192 + 0.027 × 1 920⌉ = 244. EmptySlots = 1 920 − 1 784 = 136. 136 < 244 — минимальные требования не соблюдены. Несложно убедиться, что 10 стоек по 14 дисков оказывается достаточно: TotalSlots = 2 240, MinEmptySlots = ⌈224 + 0.027 × 2 240⌉ = 285, EmptySlots = 2 240 − 1 784 = 456 > 285.

   • В качестве домена отказа можно выбрать сервер и рассмотреть 30 серверов по 4 диска. В одном домене отказа 4 × 16 = 64 слота, TotalSlots = 1 920. MinEmptySlots = ⌈64 + 0.027 × 1 920⌉ = 116. EmptySlots = 1 920 − 1 784 = 136 > 116 — минимальные требования соблюдены.

Таким образом, для хранения 100 ТБ данных в режиме block-4-2 на SSD-дисках ёмкостью 3.2 ТБ потребуется 10 стоек по 14 дисков (140 дисков) либо 30 серверов по 4 диска (120 дисков).

Обратный расчёт:

Далее возьмём конфигурацию из предыдущего примера — 30 серверов по 4 SSD-диска ёмкостью 3.2 ТБ, и оценим, какой полезный объём данных поместится в таком кластере.

1. TotalSlots = 120 × 16 = 1 920 слотов
2. MinEmptySlots = ⌈MaxSlotsInRack + 0.027 × TotalSlots⌉ = ⌈4 × 16 + 0.027 × 1 920⌉ = ⌈115.84⌉ = 116 слотов
3. UsableSlots = 1 920 − 116 = 1 804 слота
4. TotalGroups = ⌊1 804 / 8⌋ = 225 групп хранения
5. SlotSize = (3 200 − 27.65) / 16 ≈ 198.27 ГБ
6. Database Storage = 225 × 8 × 198.27 × 0.85 ≈ 303 353 ГБ
7. Tablet Storage = 303 353 / (1.5 × 2) ≈ 101 118 ГБ

Таким образом, кластер из 30 серверов и 120 SSD-дисков по 3.2 ТБ в режиме block-4-2 позволяет разместить около 101.1 ТБ данных (Tablet Storage).

Дополнительная информация

• Топология кластера YDB
• Системные требования и рекомендации для YDB
• Работа с SelfHeal