Три узла и три копии данных выглядят как готовая отказоустойчивая схема. Но методика проектирования MIND uStor допускает такой кластер только для разработки и тестов. Для рабочей системы она требует минимум шесть узлов.
Одной репликации мало. До закупки нужно посчитать полезную ёмкость, ресурсы программного хранилища и сеть. Иначе проект переживёт отказ диска на схеме, но упрётся в память, процессор или межузловой обмен после запуска СУБД.
Ниже — расчёт шестузлового MIND uStor для транзакционной базы 1С. Требования этой платформы нельзя переносить на Ceph, Storage Spaces Direct и другие SDS: у них иные правила размещения данных и отказоустойчивости.
Сначала решите, готовы ли вы обслуживать SDS
SDS отделяет управление данными от конкретных дисковых полок и контроллеров. Программный слой объединяет накопители стандартных серверов, распределяет блоки между узлами и восстанавливает копии после отказа.
Такое хранилище растёт добавлением узлов. Вместе с ёмкостью вы покупаете процессоры, память, сетевые порты и ещё одну систему, которую придётся обновлять и диагностировать.
В традиционной СХД один производитель отвечает за контроллеры, прошивки, диски и управляющее ПО. У SDS оборудование и программный слой могут обслуживать разные поставщики. Команда заказчика разбирает пограничные сбои сама: например, отделяет проблему адаптера от ошибки сети или хранилища.
Эти различия описывает сравнительный материал Cyber Protect о СХД и SDS. Он же отмечает более низкие стартовые расходы SDS на стандартном оборудовании, но предупреждает о расходах на квалифицированных специалистов.
| Условие проекта | Что выбирать | Причина |
|---|---|---|
| Команда умеет обслуживать Linux, сеть и распределённое хранилище | SDS | Специалисты смогут локализовать сбой между программой, сервером и сетью |
| Ёмкость нужно наращивать узлами без замены всей системы | SDS | Scale-out добавляет серверы вместе с дисками и вычислительными ресурсами |
| Нужен один ответственный за весь стек | СХД | Производитель контролирует оборудование, прошивки и управляющее ПО |
| Администраторы обслуживают только 1С и СУБД | СХД либо внешняя поддержка SDS | Иначе сбой хранилища потребует компетенций, которых внутри компании нет |
| Закупка должна закрыть фиксированный объём на несколько лет | Оба варианта | Решение зависит от стоимости расширения, поддержки и миграции |
| Нет отдельного контура для испытания обновлений | СХД | Ошибка обновления SDS затронет сразу программный и аппаратный слои |
Вывод: низкая цена отдельных серверов не окупит простой, если команда не умеет восстанавливать кластер.
Для рабочей СУБД SDS стоит выбирать после проверки компетенций и модели поддержки. Если эти вопросы пока не закрыты, сравнивать цены дисков рано.
Три копии оставляют треть сырой ёмкости
MIND uStor рекомендует RF 3 для горячих данных с требованиями к задержке, включая СУБД. RF 3 означает, что хранилище держит три копии каждого блока на разных узлах.
Возьмём расчётный кластер из шести узлов. В каждом установлено восемь одинаковых SATA/SAS SSD условной ёмкостью 3,84 ТБ.
Сначала считаем количество накопителей:
6 узлов × 8 SSD = 48 SSD
Сырая ёмкость кластера:
48 × 3,84 ТБ = 184,32 ТБ
При RF 3 каждый полезный блок занимает место трижды:
184,32 ТБ ÷ 3 = 61,44 ТБ
Это расчётная полезная ёмкость до резерва на восстановление, служебных данных и будущий рост. Закладывать в проект ровно 61,44 ТБ рабочих данных нельзя.
Размер резерва зависит от темпа роста и политики заполнения MIND uStor. Перед закупкой возьмите фактический объём базы, журналов и прочих томов. Затем добавьте прогноз роста на срок между расширениями.
Правило пересчёта простое: требуемую полезную ёмкость умножьте на три, потом добавьте резерв. Получившийся объём разделите на ёмкость одного накопителя и число дисков в узле.
Например, расчётные 40 ТБ рабочих данных требуют 120 ТБ под три копии. Резерв нужно прибавить отдельно — назначать его без статистики заполнения нельзя.
Для архивов и резервных копий методика MIND предлагает Erasure Coding 6+2. Такая схема делит данные на шесть частей и добавляет две части избыточности. Ей нужно минимум восемь узлов.
Переносить EC 6+2 на транзакционную базу только ради ёмкости не следует. Сначала проверьте требования СУБД к задержке и поведение платформы под вашей нагрузкой. В переданном исследовании таких замеров для 1С нет.
Репликация также не заменяет резервную копию. После ошибочного удаления SDS удалит блок на всех репликах. Для PostgreSQL нужен отдельный контур с базовой копией, WAL-архивом и проверкой восстановления на выбранный момент. Порядок описан в материале про резервное копирование PostgreSQL для 1С.
Число дисков задаёт процессор и память узла
Процессор узла обслуживает не только виртуальные машины и СУБД. Часть физических ядер забирает программный слой хранилища.
Методика MIND uStor закладывает около 0,5 физического ядра на один SATA/SAS SSD. Для восьми накопителей получаем:
8 SSD × 0,5 ядра = 4 физических ядра
Эти четыре ядра нужно оставить SDS сверх ресурсов виртуальных машин. Если на том же узле работает СУБД, её расчёт складывается с потребностью хранилища.
Память MIND предлагает считать по сырой ёмкости: около 2 ГБ RAM на 1 ТБ. Минимум платформы — 32 ГБ на узел.
Сырая ёмкость нашего узла:
8 × 3,84 ТБ = 30,72 ТБ
Расчёт памяти:
30,72 ТБ × 2 ГБ = 61,44 ГБ RAM
Расчёт превысил платформенный минимум. Значит, под SDS нужно заложить не 32, а не менее 61,44 ГБ на узел. На практике выбирают доступный объём модулей выше расчётной границы, а память СУБД и виртуальных машин считают отдельно.
| Компонент узла | Формула или требование MIND | Результат примера | Как пересчитать |
|---|---|---|---|
| Диски данных | 8–12 дисков на узел — рекомендуемый диапазон | 8 SSD по 3,84 ТБ | Выберите число дисков после расчёта сырой ёмкости |
| Сырая ёмкость | Число дисков × ёмкость диска | 30,72 ТБ | Умножьте фактические значения одного узла |
| Физические ядра SDS | 0,5 ядра × SATA/SAS SSD | 4 ядра | Прибавьте результат к CPU виртуальных машин и СУБД |
| Оперативная память SDS | 2 ГБ × 1 ТБ сырой ёмкости | 61,44 ГБ | Сравните результат с минимумом 32 ГБ и возьмите большее значение |
| Системный том | Два отдельных SSD в RAID1 | 2 SSD | Не включайте их в пул данных |
| Подключение данных | HBA либо контроллер в режиме HBA/JBOD | Отдельный доступ к каждому SSD | Проверьте режим контроллера и отключение аппаратного RAID |
Вывод: CPU и RAM для SDS считают после дисков, а не по числу пользователей 1С.
Системные и рабочие накопители нужно разделить. MIND uStor требует два отдельных SSD в RAID1 под систему. Диски данных подключаются через HBA или контроллер в режиме HBA/JBOD.
Аппаратный RAID для пула данных платформа не поддерживает. Контроллер не должен скрывать накопители за общим виртуальным диском: распределением копий управляет сама SDS.
Перед заказом сервера проверьте не только наличие нужного числа отсеков. Нужны линии PCIe под контроллеры и сетевые адаптеры, подходящий HBA, резерв по питанию и место под два системных SSD.
Сеть входит в спецификацию хранилища
У SDS межузловой обмен проходит при каждой записи и восстановлении реплик. Поэтому сеть нужно считать вместе с дисками, а не после выбора серверов.
Архитектура MIND uStor разделяет три потока: управление, клиентский доступ и обмен внутри кластера. Для них нужны три изолированных сетевых сегмента.
Для узла с восемью SATA/SAS SSD методика требует два канала по 25 Гбит/с. В расчёт закупки войдут два порта на узел, адаптеры, коммутаторы, кабели и резервирование путей.
| Накопители на одном узле | Сеть по методике MIND | Что меняется в проекте |
|---|---|---|
| До 16 SATA/SAS SSD | 2 × 25 Гбит/с | Нужны два 25-гигабитных порта и два отказоустойчивых пути |
| От 17 до 24 SATA/SAS SSD | 2 × 40 Гбит/с | Меняются адаптеры, коммутаторы и кабельная схема |
| До 8 NVMe SSD | 2 × 40 Гбит/с | Сеть считают уже под обмен быстрых накопителей |
| От 9 до 12 NVMe SSD | 2 × 100 Гбит/с | Потребуется 100-гигабитная сетевая инфраструктура |
| До 24 HDD | 2 × 10 Гбит/с | Более медленные диски снижают требование к каналу |
Вывод: дополнительный диск меняет не только ёмкость — на границе диапазона он меняет всю сетевую часть проекта.
RDMA по RoCEv2 методика MIND связывает только с NVMe и сетью без потерь. Для неё нужны настроенные PFC и ECN. Покупка адаптеров с RDMA без такой настройки не закрывает требование.
Номинальная скорость порта не доказывает, что СУБД выдержит рабочую нагрузку. До эксплуатации проверьте задержку, пропускную способность и восстановление реплик на стенде с вашим профилем запросов. Универсального числа IOPS для базы 1С здесь нет.
Отказоустойчивость SDS не резервирует всю систему 1С
SDS сохраняет доступ к тому при отказе диска или узла хранения. Она не резервирует сервер приложений 1С, экземпляр СУБД, коммутаторы и клиентский маршрут.
Каждый слой требует своей схемы. Для 1С нужны несколько рабочих серверов и настроенное резервирование процессов. Для СУБД — реплика или кластерный механизм, который соответствует выбранному продукту.
Схема этих слоёв приведена в инструкции по настройке отказоустойчивого кластера 1С. Хранилище стоит проверять вместе с ней: доступный том бесполезен, если после отказа единственного ragent пользователи не войдут в базу.
До ввода системы в эксплуатацию отключите один узел по согласованному сценарию. Проверьте доступность тома, запуск восстановления реплик и состояние СУБД.
Затем верните узел и дождитесь завершения восстановления. В этот момент наблюдайте за задержкой и сетевыми каналами. Именно восстановление создаёт дополнительную нагрузку, которой нет при спокойной работе кластера.
Отдельно разверните резервную копию базы в другом контуре. Проверка реплик и проверка бэкапа отвечают на разные вопросы: первая подтверждает доступность хранилища, вторая — возможность вернуть данные после удаления или повреждения.
Спецификация шестузлового кластера
Для принятого примера получается такая основа:
| Параметр | Конфигурация |
|---|---|
| Узлы MIND uStor | 6 серверов |
| Диски данных | По 8 SATA/SAS SSD на узел |
| Условная ёмкость SSD | 3,84 ТБ |
| Сырая ёмкость | 184,32 ТБ |
| Схема защиты | RF 3 |
| Расчётная полезная ёмкость | 61,44 ТБ до резерва |
| CPU под SDS | Минимум 4 физических ядра на каждом узле |
| RAM под SDS | 61,44 ГБ на каждом узле по базовой формуле |
| Системные диски | 2 SSD в RAID1 на каждом узле |
| Контроллер данных | HBA либо HBA/JBOD |
| Сеть хранения | 2 × 25 Гбит/с на каждый узел |
| Сетевые сегменты | Управление, клиентский доступ, межузловой обмен |
Вывод: это расчёт ресурсов MIND uStor, а не обещание производительности СУБД 1С.
При другой ёмкости сначала пересчитайте диски и RF. Затем пересчитайте CPU, RAM и сетевой диапазон. Обратный порядок оставит в спецификации ресурсы, которые не соответствуют пулу данных.
Перед закупкой проверьте пять условий:
- отказ одного узла не останавливает доступ к тому;
- сырой ёмкости хватает на три копии, восстановление и рост;
- сеть соответствует типу и числу дисков;
- системные SSD отделены от пула данных;
- резервная копия разворачивается отдельно, а 1С и СУБД тоже резервированы.
Если эти пункты закрыты, спецификацию можно защищать перед руководителем. Когда расчёт упирается в размещение СУБД, виртуальных машин и SDS на одних узлах, потребуется подбор конфигурации под вашу базу: без профиля нагрузки нельзя честно назначить процессор и память для всего сервера.