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

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

Варианта обычно три: продлевать жизнь текущей СХД через сторонний сервис, купить классический массив другого производителя или перейти на программно-определяемое хранилище (SDS) на стандартных серверах. Решение принимают после пилотного теста на собственной нагрузке, а не после сравнения буклетов.

Какие есть варианты замены

• Сторонняя поддержка текущей СХД. Даёт время на планирование миграции. Минусы: нет обновлений прошивок, запчасти приходится искать на вторичном рынке, сроки ремонта непредсказуемы.
• Классический массив другого вендора. Привычная модель: двухконтроллерная система, единая консоль управления, поддержка производителя. Подходит, если команда небольшая и не готова сопровождать распределённые системы.
• SDS на стандартных серверах. Хранилище собирается из обычных серверов с дисками, отказоустойчивостью и распределением данных управляет софт. Масштабируется добавлением узлов, но требует сильной экспертизы в сетях и Linux.
• Гибрид. Классический массив для баз данных и виртуализации, SDS или объектное хранилище для архива, бэкапов и видео.

Чем открытая архитектура отличается от «чёрного ящика»

В классических СХД аппаратная часть часто проприетарная: контроллер или полку можно заменить только оригинальным блоком совместимой ревизии. Если вендор ушёл с рынка, это главный риск.

Платформы на стандартных компонентах устроены иначе. Шасси, платы, блоки питания и HBA унифицированы, часть решений проектируется с учётом спецификаций Open Compute Project, а основная ценность — в управляющем софте. Пример такого подхода — отечественная система хранения на собственной аппаратной платформе. Такие решения стоит сравнивать с другими российскими СХД и SDS из реестра отечественного ПО и Минпромторга: по поддерживаемым протоколам, функциям (снапшоты, репликация, дедупликация), срокам поставки ЗИП и условиям поддержки.

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

Почему большие диски усложняют отказоустойчивость

Объём HDD вырос до 20 ТБ и больше, а скорость чтения увеличилась намного меньше. Поэтому перестроение массива после отказа диска может идти от нескольких часов до суток и дольше — это зависит от нагрузки, типа RAID и приоритета восстановления.

Пока идёт перестроение, оставшиеся диски сильно нагружены чтением. RAID 5 выдерживает отказ только одного диска, поэтому на больших HDD он считается рискованным. RAID 6 переносит два отказа, но перестроение тоже длинное.

Что используют вместо этого:

• Распределённый RAID. Резерв распределён по всем дискам группы, поэтому восстановление идёт параллельно и заметно быстрее.
• Erasure coding. Данные делятся на фрагменты с контрольными блоками и распределяются по дискам или узлам. В зависимости от схемы кластер переживает отказ нескольких дисков или целого сервера.
• Тиринг. Горячие данные лежат на NVMe/SSD, холодные — на ёмких HDD.

Erasure coding экономнее зеркалирования по ёмкости, но при записи мелкими блоками даёт большие задержки. Для баз данных его применяют осторожно.

Как определить реальный профиль нагрузки

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

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

Эти данные дают и статистика текущей СХД, и гипервизоры, и мониторинг серверов. Без них вы сравниваете чужие цифры.

Как протестировать СХД перед внедрением

1. Воспроизведите свою нагрузку. Настройте генератор (FIO, vdbench, HCIBench для vSphere) по профилю, который собрали ранее: размер блока, соотношение чтения и записи, глубина очереди. Смотрите на задержки, а не только на IOPS.
2. Проверьте отказ под нагрузкой. Отключите диск, затем второй, затем контроллер или узел. Замерьте, насколько проседает производительность и сколько длится восстановление. Для пилота лучше брать диски того объёма, который пойдёт в работу.
3. Проверьте снапшоты и репликацию. Создайте много снапшотов, удалите часть, посмотрите на задержки. Если нужна репликация на резервную площадку, протестируйте её на реальном канале.
4. Проверьте интеграцию. Работа с вашим гипервизором, системой бэкапа, мониторингом, обновление прошивки без остановки сервиса.
5. Проверьте документацию и поддержку. Заведите тестовую заявку и посмотрите, как быстро и по существу отвечают.

Что проверить в договоре и условиях поддержки

• сроки реакции и восстановления по уровням критичности;
• наличие склада ЗИП в России и сроки замены дисков, блоков питания, вентиляторов, HBA;
• можно ли ставить диски сторонних производителей или только сертифицированные;
• частота выпуска обновлений и порядок их установки;
• наличие в реестрах, если это важно для госзаказчиков и КИИ;
• стоимость поддержки на третий-пятый год, а не только при покупке.

Типичные ошибки при миграции

• Выбирать СХД по максимальным IOPS из спецификации, а не по задержке на своём профиле.
• Ставить RAID 5 на ёмкие HDD ради экономии дисков.
• Переходить на SDS без людей, которые умеют сопровождать распределённые системы и сеть.
• Не тестировать отказы до запуска в работу.
• Переносить все данные за один раз без плана отката.

Кому новые решения не подходят

Если текущая СХД стабильна, сервисный контракт с третьей стороной закрывает риски, а данные почти не растут, спешить с заменой незачем. Можно спокойно спланировать миграцию на конец жизненного цикла.

SDS плохо подходит небольшим компаниям с одним администратором и малым объёмом: сложность сопровождения не окупается. Отечественным решениям может не хватать специфичных функций, например сертифицированной интеграции с конкретной СУБД или прикладным ПО. Это нужно проверять по спискам совместимости.

С чего начать

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