Пулы хранения
Проблема и зачем
В гиперконвергентном кластере внешней системы хранения нет. Диски стоят в тех же серверах, которые считают виртуальные машины, а программно-определяемый слой хранения (SDS) собирает эти диски в пулы. Пул отвечает за избыточность, компрессию и дедупликацию и хранит все данные кластера.
Отсюда вытекает практический вопрос администратора: пул — это не «диск с процентом заполнения», а объект с двумя разными ёмкостями, четырьмя признаками состояния и дисками на всех узлах кластера. Пока эта модель не разложена, числа в интерфейсе читаются неверно: сырая ёмкость принимается за доступную, а сумма размеров дисков виртуальных машин — за занятое место.
Эта страница объясняет модель. Как смотреть пулы — в инструкции «Как посмотреть пулы кластера»; как работать со свойствами датасета — в инструкции «Как посмотреть и изменить свойства датасета».
Модель и сущности
Слой хранения кластера состоит из трёх уровней.
Диски. Физические носители в серверах. В платформе они только SSD и NVMe: разделения на «кэш» и «ёмкость», как в гибридных решениях, здесь нет, ярусов хранения тоже нет. Планировать пул из жёстких дисков нельзя — вся ёмкость all-flash.
Пул. Группа дисков, объединённая ZFS. Пул собран из дисков всех узлов кластера, а не одного узла: дисков в пуле столько, сколько в кластере узлов, а минимальное число пулов в кластере равно числу узлов. Отсюда и избыточность: в кластере из двух узлов — зеркало (RAID-1), в остальных конфигурациях — RAID-Z, где все диски равнозначны. Избыточность пула тождественна избыточности кластера — кластер из семи узлов с избыточностью 2 держит пул в работе, пока в пуле осталось не меньше пяти дисков. Поэтому потеря диска — событие уровня пула, а не отдельной виртуальной машины.
У пула есть имя (name), постоянный идентификатор (guid) и номер текущего
обслуживающего узла (node_id) — узла, через который кластер сейчас работает с
пулом. В интерфейсе это колонка Current node. Диски пула этому узлу не
принадлежат: они разложены по всем узлам, и у каждого диска пула свой номер узла.
Датасет. Единица внутри пула, на которую ложится диск виртуальной машины.
Адресуется полным именем вида pool-a/vm-100-disk-0 и собственным GUID. Свойства
датасета — компрессия, дедупликация, размер тома, контрольные суммы — живут
отдельно от свойств пула и меняются отдельными методами.
| Сущность | Чем адресуется | Кто ей владеет |
|---|---|---|
| Пул | guid, либо пара nodeId (обслуживающий узел) + name | кластер |
| Датасет | guid диска | пул |
Как работает
У слоя хранения vStack Center два независимых пути к данным, и разница между ними объясняет большую часть неожиданных ответов.
Первый путь — карта пулов из базы vStack Center. Диспетчер кластера держит снятое состояние всех пулов у себя и отвечает на запрос сразу, синхронно. Карта доступна даже тогда, когда узел не отвечает, но показывает последнее снятое состояние, а не текущее.
Второй путь — живой опрос узла. Запрос ретранслируется на Storage-агент нужного
узла. Сначала приходит промежуточный ответ {"message": "relayed"}, затем финальный
— обратным вызовом от агента. Живые методы дают полный набор свойств ZFS, но
молчащий узел означает ошибку вместо данных.
| Что нужно | Метод | Режим | Откуда данные |
|---|---|---|---|
| Все пулы, сгруппированные по узлам | pool-map | синхронный | база vStack Center |
| Все пулы с ёмкостью и состоянием | pool-map-by-guid | синхронный | база vStack Center |
| Пулы, обслуживаемые узлом | pools-list | асинхронный | Storage-агент узла |
| Полные свойства одного пула | pools-get | асинхронный | Storage-агент узла |
| Свойства датасета | filesystems-get | асинхронный | Storage-агент узла |
| Правка свойств датасета | filesystems-set | асинхронный | Storage-агент узла |
Две ёмкости пула
Ёмкость пула описывают семь полей, и путать их дорого: разница между сырой и полезной ёмкостью равна доле, отданной избыточности.
| Поле | Что показывает |
|---|---|
size_raw | сырая ёмкость — сумма дисков пула |
size | полезная ёмкость — size_raw за вычетом доли избыточности |
used | занято данными |
free | остаток полезной ёмкости: size минус used |
capacity_pct | заполнение пула в процентах |
provisioned | сумма заявленных размеров всех датасетов пула |
provisioned_pct | отношение provisioned к полезной ёмкости, в процентах |
Датасеты выделяют место тонко: заявленный размер тома резервируется не сразу.
Поэтому provisioned считается по заявкам, а used — по факту, и первое число
свободно превышает второе. Значение provisioned_pct выше 100 означает
переподписку: датасеты пула заявили больше, чем в пуле полезной ёмкости. Само по
себе это не авария, но с этого момента наполнение пула нужно вести по
capacity_pct, а не по остатку квот.
Четыре признака состояния
| Поле | Значение |
|---|---|
health | состояние пула; у здорового — ONLINE |
consuming | пул принят кластером как рабочий носитель данных (1 / 0) |
scrubbing | идёт проверка целостности данных (1 / 0) |
resilvering | идёт восстановление избыточности после замены диска (1 / 0) |
Рядом с ними карта отдаёт lif — сетевой адрес, по которому доступен пул.
Признак consuming управляет записью в пул. Пул со значением 0 кластер данными
не наполняет, и операции, которым нужна запись, на нём отклоняются: создание и
удаление снимков виртуальных машин, откат на снимок, отправка резервной копии,
создание машины на явно выбранном пуле, клонирование машины по пулу источника,
удаление диска машины, операции с датасетами резервных копий. Если такая операция
падает, а виртуальная машина при этом жива, проверьте consuming её пула прежде,
чем искать причину в самой машине. Добавление диска и расширение диска этот признак
не проверяют.
Кто что видит
Область видимости у двух уровней разная, и это не настройка, а свойство методов.
Пул — объект уровня кластера. Живые методы пула (pools-list, pools-get) отдаёт
только глобальная роль Cluster master. Карту пулов (pool-map) читают две
глобальные роли: Cluster master и Resource Viewer. Администратору ВЦОД
(Виртуальный Центр Обработки Данных) пул не виден: у пула нет владельца-ВЦОД, на
одном пуле живут датасеты разных ВЦОД. Исключение — pool-map-by-guid: канон API
доступ к этому методу не оговаривает.
Датасет — объект уровня ВЦОД. Чтение свойств (filesystems-get) и правка
(filesystems-set) открыты роли администратора ВЦОД и выше, и только внутри своего
ВЦОД. Принадлежность датасета проверяется до обращения к узлу, причём чужой датасет
отклоняется тем же кодом ошибки, что и несуществующий: факт существования датасета
другого ВЦОД не раскрывается. Глобальная роль работает с датасетами любого ВЦОД.
Ограничения
На уровне пула API кластера только читает. Методов создания, удаления и
расширения пула в группе хранения нет — есть карта, список, свойства. Обойти это
запросом нельзя: единственная запись в слое хранения на этом уровне — свойства
датасета через filesystems-set.
Живые методы пула идут через один узел. У пула в каждый момент один обслуживающий узел, и запрос ретранслируется на него, поэтому недоступный узел даёт ошибку ретрансляции вместо свойств пула. Обход: смотрите таблицу пулов в интерфейсе — она отвечает из базы vStack Center и переживает недоступность узла, но покажет последнее снятое состояние.
Свойства датасета закрыты фича-флагом. Пока в кластере не включена фича
filesystem_options, форма свойств датасета в интерфейсе не открывается, а метод
filesystems-set отвечает ошибкой.
Ярусов хранения нет. Схема «кэш на SSD плюс ёмкость на жёстких дисках» в платформе не поддерживается. Обход в виде отдельного «медленного» пула тоже не работает: пул наследует характеристики своих дисков, а вся ёмкость кластера рассчитана на SSD и NVMe.
Что читать дальше
- Как посмотреть пулы кластера — таблица пулов, страница пула, разбор пула по дискам.
- Как посмотреть и изменить свойства датасета — чтение свойств ZFS и правка компрессии.
- Поля и коды ошибок методов хранения — состав ответов и разбор кодов ошибок.
- Восстановление пула после отказа диска — в разделе «Сценарии».