СХД для бизнес-приложений: как выбрать архитектуру с учётом роста и сбоев

База заказов, учётная система и виртуальные машины могут занимать сравнительно мало места, но остановить работу компании при потере доступа к дискам.

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

Какие требования предъявляют приложения

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

Паспорт нагрузки должен включать:

• Данные: занятый объём, темп роста, журналы транзакций, временные файлы и сроки хранения.
• Обращения к дискам: случайный или последовательный доступ, размеры блоков, соотношение чтения и записи, одновременные запросы.
• Задержки: время ответа хранилища и длительность операций внутри приложения.
• Фоновые задачи: резервное копирование, обслуживание БД, обновления и одновременный запуск VM.
• Доступность: допустимую потерю последних изменений, то есть RPO, и целевое время восстановления, то есть RTO.

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

Время ответа измеряют на нескольких уровнях. В руководстве Microsoft Troubleshoot slow SQL Server performance caused by I/O issues диагностика связывает ожидания СУБД, статистику файлов и показатели ОС. Это помогает отделить проблему хранения от блокировок запросов или недостатка памяти. Сам факт медленного отчёта ещё не доказывает, что требуется новая СХД.

Для тестов полезно задавать критерий на уровне бизнеса: например, отчёт должен укладываться в согласованное время при работающем резервном копировании. Помимо среднего значения, проверяют p95 – границу, в которую укладываются 95% измерений. Редкие длинные задержки могут быть незаметны в среднем, но регулярно мешать отдельным пользователям.

Когда нужны локальные диски, а когда внешняя СХД

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

Общий блочный массив отделяет хранение от вычислений. Несколько серверов получают доступ к предусмотренным для них томам, а кластерное ПО управляет запуском VM или приложений. Пример такого класса – СХД HPE MSA. Конкретную модель хранилища выбирают вместе со схемой подключения, версиями ПО и требованиями к отказоустойчивости.

В QuickSpecs для HPE MSA 2060 (версия 24) описаны исполнения с FC, iSCSI или SAS. Поэтому до заказа определяют интерфейс конкретной конфигурации и совместимые адаптеры, кабели либо трансиверы. Характеристики одного поколения нельзя автоматически переносить на другое. Для проверяемой связки используют документацию выбранной модели, HPE SPOCK и матрицы совместимости ОС или гипервизора.

Таблица сравнивает архитектуры, а не гарантирует превосходство одной из них. Например, локальные диски также могут участвовать в отказоустойчивой системе через репликацию средствами СУБД. Тогда проверяют возможности конкретной базы, порядок переключения и резерв ресурсов на принимающем сервере.

Блочное хранилище не является готовой общей папкой. Для файлового доступа нужен соответствующий серверный сервис; совместная работа нескольких хостов с одним LUN требует файловой системы или ПО, поддерживающих согласованный совместный доступ. Простое подключение одного тома к двум независимым ОС не обеспечивает согласованной записи. Пример организации общего доступа описан в документации Microsoft Cluster Shared Volumes для Windows Server, но конкретный способ зависит от программной платформы.

Как разделить отказоустойчивость и резервное копирование

Отказоустойчивость позволяет продолжить работу после предусмотренной неисправности. Резервная копия даёт возможность вернуть данные к сохранённому состоянию. Эти механизмы дополняют друг друга: исправный массив способен без ошибок записать случайное удаление таблицы или зашифрованные файлы.

Разбирать защиту удобнее по событиям:

• Отказ накопителя. RAID сохраняет доступ в пределах выбранного уровня защиты. Во время восстановления массива проверяют задержки и нагрузку на оставшиеся диски.
• Потеря пути доступа. Нужны независимые соединения и корректно настроенный multipath. Два кабеля через один коммутатор сохраняют общую точку отказа.
• Отказ контроллера. Второй контроллер должен принять нагрузку, а хосты – перейти на доступные пути. Доступность данных ещё не означает сохранения прежней скорости.
• Отказ сервера. Требуются другой вычислительный узел, механизм переключения и достаточный резерв CPU и RAM. Одна внешняя СХД этого не обеспечивает.
• Потеря массива или площадки. Данные и средства восстановления должны существовать за пределами отказавшей системы.

Особенно показателен отказ контроллера. В руководстве HPE MSA 1060 и HPE MSA 2060/2062 Storage best practices в 3-ей редакции описано влияние настроек защиты кэша на работу при недоступности второго контроллера. При переходе на write-through запись подтверждается после сохранения на накопителях, поэтому её задержка может увеличиться. Проверять нужно не только наличие томов, но и выполнение рабочих операций в таком режиме.

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

Практический минимум – независимое хранилище копий, отдельные полномочия доступа и защищённая от изменения либо отключаемая копия. В руководстве CISA #StopRansomware Guide отдельно выделены автономные копии и регулярная проверка восстановления. Результатом проверки должен быть запущенный сервис с корректными данными, а не только успешное завершение задания backup.

Как запланировать миграцию и расширение

Запас ёмкости рассчитывают до выбора числа накопителей. Номинальная сумма объёмов дисков отличается от пространства, доступного приложениям: часть занимают избыточность, служебные данные и резерв восстановления. Кроме того, приходится хранить снимки и оставлять свободное место для эксплуатации.

Расчётный пример ≠ не результат тестирования. Допустим, рабочие данные занимают 10 TiB, растут на 25% ежегодно, а горизонт планирования составляет три года. Дедупликацию и сжатие в расчёт не включаем. Под локальные снимки условно выделяем ещё 4 TiB, а свободный резерв принимаем равным 20% полезной ёмкости пула.

Расчёт выполняется в три шага:

1. Рабочие данные через три года: 10 × 1,25³ ≈ 19,53 TiB.
2. Вместе с заданным бюджетом снимков: 19,53 + 4 = 23,53 TiB.
3. С сохранением 20% свободного пространства: 23,53 ÷ 0,8 ≈ 29,41 TiB полезной ёмкости.

Это ориентир после учёта избыточности и служебных расходов, а не сумма маркировок накопителей. Резервные копии здесь не учтены. Размер снимков зависит от объёма изменяемых блоков и срока хранения; 4 TiB и 20% – допущения примера, не норматив производителя. Для закупки расчёт повторяют по фактической динамике данных и правилам выбранного массива. TiB также нельзя без пересчёта подставлять вместо десятичных TB из спецификации диска.

Thin provisioning позволяет выделить приложениям логические тома без немедленного резервирования всего заявленного объёма. Физическое место при этом не появляется: отслеживают реальную занятость пула, скорость её изменения и время, необходимое для расширения. Порог предупреждения должен оставлять время на поставку и внедрение, а не просто сообщать, что место заканчивается.

Перенос проводят по проверяемому плану:

1. Сверяют совместимость, версии прошивок, драйверов и multipath; проверяют лицензии необходимых функций.
2. Создают копию и восстанавливают её в изолированной среде. Проверяют приложения, права и зависимости.
3. Выполняют пробную миграцию, измеряют продолжительность и нагрузку на действующую систему.
4. В согласованное окно завершают перенос поддерживаемым для приложения способом, при необходимости приостанавливая запись, затем переключают сервисы и проверяют операции пользователей. Заранее определяют условия отката и обработку новых записей после переключения.
5. В тестовом контуре по процедурам производителя испытывают предусмотренные отказы и восстановление. Фиксируют паузу, состояние данных и производительность при сокращённом числе компонентов.

Локальное хранение оправдано, когда его восстановление укладывается в требования бизнеса. Общая СХД полезна для разделения вычислений и хранения при продуманной защите путей, узлов и данных. Распределённая архитектура подходит при готовности обслуживать кластер и оплачивать его избыточность. Выбор считается обоснованным, когда конфигурация выдерживает рабочую нагрузку, предусмотренный рост и согласованные сценарии отказа.