Для улучшения работы сайта мы используем файлы cookies. Оставаясь на сайте, вы соглашаетесь с политикой обработки персональных данных.

Требования к дисковой подсистеме

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

Требования распространяются на режимы Single instance и High Availability (HA). Значения, которые различаются для этих режимов, указаны отдельно.

В режиме High Availability (HA) к дисковой подсистеме предъявляются более строгие требования, чем в режиме Single instance. Это связано с механизмами обеспечения отказоустойчивости, в том числе с контролем аренды Patroni в Kubernetes.

1. Длительность единичного провала диска

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

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

Тип узла Рекомендуется Допустимо Не допускается

Control Plane (Master), High Availability

≤ 1 с

≤ 5 с

> 8 с

Узел Single instance

≤ 1 с

≤ 30 с

> 45 с

Worker и тома данных

≤ 1 с

≤ 5 с

> 5 с

LB

≤ 1 с

≤ 5 с

Порог не обнаружен до 30 с

При превышении пороговых значений возможны следующие последствия:

Длительность провала High Availability Single instance

9–12 с

База данных платформы переходит в режим только для чтения на 10–12 с

Без последствий

12 с на Worker

Таймауты ClickHouse, обрывы RabbitMQ, деградация томов

Аналогичные последствия

20 с

8–9 томов переходят в состояние faulted, выполняется перезапуск слоя данных

Без последствий

30 с

Отказ ClickHouse, RabbitMQ и PostgreSQL

Отказ слоя данных

120 с

—

Отказ всех компонентов, включая точку входа портала

2. Задержка подтверждённой записи

Для оценки задержки подтверждённой записи используется следующий профиль измерения:

  • размер блока — 2300 Б;

  • fdatasync выполняется для каждой операции;

  • глубина очереди — 1.

Такой профиль соответствует характеру операций etcd.

Показатель Рекомендуется Допустимо Не допускается

p50

≤ 1 мс

≤ 3 мс

> 5 мс

p99

≤ 5 мс

≤ 25 мс

> 50 мс

p99.9

≤ 20 мс

≤ 70 мс

> 150 мс

Максимальное значение за 30 минут

≤ 200 мс

≤ 1 с

> 2 с

Для etcd значение p99 fsync должно составлять менее 10 мс, а p99 фиксации хранилища — менее 25 мс. При превышении этих значений etcd сигнализирует о медленной работе диска.

Значения в колонке Рекомендуется соответствуют требованиям etcd с дополнительным запасом. Значения в колонке Допустимо соответствуют уровню, при котором Cloudlink продолжает работать, однако etcd уже может сигнализировать о медленной работе дисковой подсистемы.

Высокая пропускная способность диска не гарантирует низкую задержку подтверждённой записи. Например, устройство, выполняющее 17 000 операций записи в секунду с задержкой 40 мкс, может выполнять только 270 операций fdatasync в секунду с задержкой 3 мс.

3. Количество операций ввода-вывода

Рекомендуемые значения IOPS приведены с запасом на выполнение регламентных операций системы хранения данных.

Тип узла Минимальное значение, IOPS Рекомендуемое значение, IOPS

Master: etcd и API Server

1 000

3 000

Worker: реплики хранилища и containerd

5 000

15 000

LB

100

300

Единственный узел Single instance

3 000

10 000

Для Master количество IOPS является второстепенным показателем. Определяющими являются длительность единичного провала диска и задержка подтверждённой записи.

Например, узел со 100 IOPS может продолжать работать с низкой производительностью, тогда как узел с 5 000 IOPS и единичным провалом длительностью 12 с требованиям не соответствует.

4. Требования к носителям и организации хранения

Параметр Требование

Тип носителя

Enterprise SSD с защитой от потери питания. При использовании СХД — all-flash с зеркалированным NVRAM-кэшем записи

QoS

Тома Cloudlink должны быть изолированы от посторонней нагрузки

Свободное место на узле

Не менее 20 %

Swap

Отключён

Для данных Control Plane и томов хранилища не допускается использовать:

  • HDD и гибридный тиринг;

  • SSD без защиты от потери питания;

  • thin provisioning с выделением пространства при первой записи;

  • inline-дедупликацию без гарантированных значений p99.

Пороговые значения свободного места определяются конфигурацией платформы:

  • менее 30 % — kubelet удаляет образы;

  • менее 15 % — хранилище перестаёт размещать новые реплики на узле;

  • менее 5 % — вытесняются поды класса BestEffort.

Мониторинг заполнения дисков необходимо выполнять средствами внешнего мониторинга.

5. Требования к сети

Требования раздела применяются к режиму High Availability. В режиме Single instance трафик между узлами отсутствует, поэтому требования к сети сводятся к доступности точки входа платформы.

Определяющим требованием является длительность полного разрыва соединения, а не задержка, потери пакетов или пропускная способность по отдельности.

Параметр Рекомендуется Допустимо Не допускается

Полный разрыв между Master

≤ 2 с

≤ 5 с

> 6 с

Полный разрыв Worker → Control Plane

≤ 5 с

≤ 8 с

> 10 с

Изоляция одного Master

—

До 180 с без последствий

—

Потери пакетов между Master

0 %

≤ 5 %

> 10 %

RTT Master <→ Master

≤ 1 мс

≤ 50 мс

> 50 мс

RTT Worker <→ Master, Worker <→ Worker

≤ 2 мс

≤ 50 мс

> 50 мс

Пропускная способность, Master и LB

10 Гбит/с

1 Гбит/с

—

Пропускная способность, Worker

10 Гбит/с

4 Гбит/с

1 Гбит/с недостаточно

Допустимое значение RTT 50 мс соответствует контрольному порогу etcd по времени репликации между участниками кластера. Во время измерений отказов при более высоких значениях не наблюдалось, однако при RTT более 50 мс etcd перестаёт соответствовать собственным нормативным значениям.

При полном разрыве соединения отказ происходит не сразу, а через 15–24 с. Это время необходимо Patroni для обнаружения потери аренды.

Насыщение пропускной способности рабочей нагрузкой непосредственно не приводит к отказу. Требование к пропускной способности определяется временем восстановления реплик хранилища.

6. Проверка дисковой подсистемы

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

6.1. Проверка задержки подтверждённой записи

Выполните команду:

fio --name=fsync --directory=/mnt/test --rw=write --ioengine=sync --fdatasync=1 --bs=2300 --size=64m --runtime=1800 --time_based --numjobs=1 --iodepth=1

В секции fsync/fdatasync должны выполняться следующие условия:

  • 99.00th — не более 25 мс;

  • 99.90th — не более 70 мс;

  • max — не более 1 с за весь 30-минутный тест.

6.2. Проверка единичных провалов

Выполните команду:

fio --name=stall --directory=/mnt/test --rw=randwrite --ioengine=libaio --direct=1 --bs=4k --size=4g --runtime=3600 --time_based --numjobs=1 --iodepth=1 --write_lat_log=stall --log_avg_msec=1000

По журналу не должно быть операций длительностью более 1 с.

Операция длительностью более 8 с означает, что дисковая подсистема не прошла приёмочную проверку.

6.3. Проверка количества операций

Выполните команду:

fio --name=randwrite --directory=/mnt/test --rw=randwrite --ioengine=libaio --direct=1 --bs=4k --size=4g --runtime=60 --time_based --numjobs=4 --iodepth=8 --group_reporting

Полученные значения должны соответствовать требованиям по Количеству операций ввода-вывода.

6.4. Проверка сети

Выполните команды:

ping -c 1000 -i 0.01 -q <узел>
iperf3 -c <узел> -t 30 -P 4

Полученные значения должны соответствовать Требованиям к сети.

При оценке дисковой подсистемы необходимо учитывать не только IOPS и пропускную способность, а также длительность единичного провала диска и задержку подтверждённой записи.