Способы хранения, классы и ярусы

Страница объясняет, как S3R решает, в каком виде и на каких дисках хранить содержимое объекта: чем различаются способы хранения, как класс хранения S3 связан с ярусом дисков и как клиент выбирает ярус. Она нужна тому, кто планирует ярусы до установки или разбирает, почему объект оказался не там, где ожидалось.

Коротко

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

Что происходит с объектом внутри яруса, описано на странице Группы размещения.

Два независимых решения

Размещение объекта определяется двумя независимыми решениями.

Ось	Что определяет	Чем задаётся
Внутри площадки	способ хранения: inline, erasure-coded в ярусе с k > 1 или replicated в ярусе с k = 1	параметром inline_max и схемой избыточности яруса в s3r_storage.erasure
Между площадками	на скольких площадках хранится копия объекта	составом доменов отказа: компонентом dc в failure_domain

Объект с копией на одной площадке

Столбец placements строки объекта перечисляет, где хранится его содержимое. Пока в нём есть только одна запись live, безвозвратная потеря этой площадки делает содержимое объекта недоступным, даже если строка объекта сохранилась. Перед плановым выводом площадки дождитесь пустой очереди s3r_t<N>_siterepl каждого тенанта и проверьте наличие записей live на других площадках.

Кодирование не выходит за границу площадки. Внутри площадки объект кодируется по k+m дискам, а между площадками реплицируется целиком: каждая площадка хранит собственную, независимо закодированную копию. Репликация между площадками дополняет кодирование, а не заменяет его:

• при одной площадке применяется кодирование;
• при нескольких площадках — кодирование внутри каждой площадки и репликация между ними.

Причина ограничения — пропускная способность канала между площадками. При кодировании через границу площадки:

• каждое чтение с потерей фрагментов передавало бы по каналу k фрагментов;
• каждое восстановление передавало бы объём в k раз больше утраченного;
• каждая запись ожидала бы самое медленное из k+m соединений.

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

Размещение голосующих реплик Picodata и сохранение кворума Raft настраиваются отдельно от размещения содержимого объектов.

Способы хранения внутри площадки

Способ хранения объекта записан в столбце encoding его строки.

Размер объекта	Способ хранения	Размещение
до inline_max включительно	inline	строка метаданных; избыточность обеспечивает Picodata
больше inline_max	erasure-coded	ярус со схемой k > 1: k фрагментов данных и m фрагментов чётности на полосу
больше inline_max	replicated	ярус со схемой k = 1: m + 1 полных копий на дисках различных доменов отказа

Размер объекта определяет только одно: хранится ли содержимое в строке метаданных или в хранилище фрагментов — на дисках узлов. Содержимое объекта размером до inline_max хранится в строке, и его избыточность обеспечивает Picodata. Всё, что попадает в хранилище фрагментов, хранится по схеме избыточности своего яруса.

Запасного варианта нет

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

Малые объекты в ярусе с кодированием

Внутри хранилища фрагментов второй границы по размеру объекта, между репликацией и кодированием, нет. В ярусе с k > 1 кодируется и объект, который помещается в один малый блок: он хранится малыми блоками группы, и чтение собирает его из k фрагментов. Кроме того, каждая запись в хранилище фрагментов выравнивается до 4 КиБ, что существенно для малых объектов.

Сравнение схемы k=8, m=4 с тремя копиями:

Объект	Кодирование 8+4	3 копии	Меньший объём
5 КиБ	48 КиБ	24 КиБ	копии
8 КиБ	48 КиБ	36 КиБ	копии
16 КиБ	48 КиБ	60 КиБ	кодирование
64 КиБ	144 КиБ	204 КиБ	кодирование
1 МиБ	1584 КиБ	3084 КиБ	кодирование

Для объектов размером примерно от 4 до 10 КиБ, то есть немного больше inline_max, репликация занимает меньше места, а чтение закодированного объекта требует k обращений к дискам против одного. Если таких объектов много, есть два решения:

• увеличить inline_max до записи схемы избыточности яруса;
• направить их в отдельный ярус со схемой k = 1 через карту классов хранения (см. следующий раздел).

Классы хранения S3 и ярусы

Класс хранения S3 (x-amz-storage-class) выбирает клиент, а ярус (tier= на диске) назначает администратор. Соответствие между ними, карту классов хранения, задаёт параметр s3r_storage.tiers: каждому ярусу соответствует один класс, а каждому классу один ярус. Список упорядочен от наиболее частого к наиболее редкому доступу.

s3r_storage:
  tiers:
    - { name: standard, class: STANDARD  }
    - { name: cold, class: STANDARD_IA  }
  erasure:
    - { k: 4, m: 2, stripe_size: 2MiB  }
    - { k: 8, m: 2, stripe_size: 4MiB, tier: cold  }

Привязка класса к ярусу постоянна

Строки объектов хранят класс, размещения ссылаются на группы одного яруса, и изменение конфигурации данные не переносит. Команда ALTER PLUGIN, которая связывает уже известный класс с другим ярусом или ярус с другим классом, отклоняется и ничего не сохраняет.

Как клиент выбирает класс

Объект создаётся в ярусе, который соответствует его классу.

• Операции PutObject, CopyObject и CreateMultipartUpload принимают заголовок x-amz-storage-class.
• Без заголовка назначается класс STANDARD. CopyObject не наследует класс источника.
• Части составной загрузки наследуют класс загрузки.
• Класс возвращается в ответах HeadObject, GetObject, GetObjectAttributes и операций перечисления.

Какие классы принимаются:

• Класс, которого нет в карте, отклоняется с ответом 400 InvalidStorageClass.
• Кластер с единственным ярусом принимает любое имя класса AWS и хранит его как метку.
• Если в карте нет ни яруса standard, ни класса STANDARD, ярус standard с классом STANDARD подразумевается.
• Объекты размером до inline_max хранятся в строке метаданных при любом классе, и класс для них служит только меткой.

Если на площадке нет группы нужного яруса

Запись объекта этого класса отклоняется с ответом 503, в котором названы класс, ярус и площадка. На дисках яруса с более частым доступом объект не размещается. Такие отказы считает метрика s3r_class_refused_total{storage_class}.

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

Изменение карты классов

Действующая карта хранится в таблице s3r_tier. Команда ALTER PLUGIN, противоречащая ей, отклоняется (см. предупреждение в начале раздела). Ошибка s3r_storage.tiers is not applied and the recorded class map stays in force: ... записывается в журнал в двух случаях:

• Противоречащая карта была сохранена раньше. Сервис при запуске записывает ошибку и продолжает использовать прежнюю карту.
• Две команды ALTER PLUGIN ... SET меняют карту одна за другой, и вторая карта противоречит первой. Вторую карту сверяют с записанной картой до того, как первая попадёт в таблицу s3r_tier, и отклоняют при записи.

Принятая карта начинает действовать не сразу. В таблицу s3r_tier её записывает служебный процесс сервиса s3r_storage, который следит за составом кластера: после запуска сервиса и после каждого изменения параметра, если записанная карта отличается от принятой. Ни команда ALTER PLUGIN ... ENABLE, ни команда ALTER PLUGIN ... SET этой записи не ждут. Поэтому запросы S3 с классом нового яруса направляются в этот ярус после того, как строка яруса появится в таблице s3r_tier. До этого:

• кластер с единственным ярусом принимает такой класс как метку;
• кластер с несколькими ярусами отклоняет запрос.

Поле compress записи яруса в постоянную привязку не входит. Необязательное значение compress: true включает сжатие объектов, которые записываются в этот ярус операцией PutObject (см. Сжатие). Его можно изменить в любой момент, и изменение действует на последующие записи.

Правила построения кластера с ярусами

1. У каждого яруса своя схема и свои диски. Каждый ярус с дисками объявляет свою схему, а его диски на каждой площадке должны позволять разместить группу этой схемы по правилам раздела Группы размещения. Диски другого яруса не заимствуются.
2. Запись идёт через инстансы с дисками яруса. Ярусы могут находиться на разных инстансах. Запись объекта выполняет инстанс, который принял запрос, в свою группу яруса. Поэтому клиент записывает объекты бакета через инстансы, у которых есть диски яруса этого бакета. Инстанс без группы нужного яруса отвечает на запись 503 с сообщением this instance owns no placement group in tier <ярус>: пересылки записи другому инстансу нет.
3. Ярус на меньшинстве узлов нагружает их сеть. Если ярус представлен на меньшинстве узлов, весь его трафик и восстановление проходят через сетевые интерфейсы этих узлов. Подробности приведены в разделе Администрирование.