Huawei OceanStor Dorado для виртуализации: параметры КП и приемка

Какая проблема с КП на all-flash СХД для виртуализации

Главная беда коммерческих предложений по all-flash СХД для виртуализации в том, что они часто сравниваются как прайс-листы: модель, емкость, «до X IOPS» и цена. Для виртуализации это почти всегда приводит к сюрпризам после покупки. Не потому что кто-то «плохой», а потому что в КП редко зафиксированы условия, при которых цифры вообще достижимы.

IOPS и latency в брошюре без контекста мало что значат. У одного вендора «1 млн IOPS» получен на блоках 4K, чтение 100%, очередь 128, с компрессией, на коротком тесте в лаборатории. У другого - на смешанном профиле 70/30 и реальных задержках, но IOPS ниже. На выходе вы сравниваете не системы, а маркетинг. Для Huawei OceanStor Dorado для виртуализации это особенно важно: платформа сильная, но правильность сравнения зависит от того, какие именно параметры и допущения вы зафиксировали.

Еще одна типичная проблема: в КП не попадают «соседние» части решения, которые потом определяют результат сильнее, чем сама СХД. Например, вы ждете 1-2 мс, а в реальности получаете 8-12 мс, потому что узкое место оказалось в сети или на хостах.

Чаще всего в КП не хватает таких вещей:

• Условия тестовых цифр: размер блока, профиль чтение/запись, очередь, длительность, включены ли дедупликация и компрессия.
• Конкретная конфигурация: сколько контроллеров, какие диски/классы, RAID/erasure coding, объем кэша, лицензии на ускорение.
• Порты и скорость «в штуках»: сколько 16/32G FC или 25/100GbE реально будет установлено, а не «поддерживается».
• Требования к окружению: какие HBA/NIC на хостах, какие настройки MPIO/ALUA, какая схема фабрики или коммутаторов.
• Ограничения по функционалу: что будет с производительностью при снапшотах, репликации, шифровании, QoS.

Небольшой пример из практики виртуализации: компания планирует кластер на 6 хостов и 400 VDI. В КП сравнили только емкость и «пиковые IOPS». После внедрения выясняется, что для нормальной работы нужны дополнительные FC-порты на массиве и на каждом хосте, а также лицензия на нужный тип репликации. Сама СХД справляется, но проект дорожает и сроки растут.

Чтобы сравнение было честным, несколько решений стоит принять заранее и закрепить в запросе: какой гипервизор и версия, какие протоколы вы точно готовы использовать (FC/iSCSI/NVMe over Fabrics), какой профиль нагрузки вы считаете «своим» (VDI, базы, файловые сервисы), и какие метрики важнее - стабильная latency на 95/99 перцентиле или максимум IOPS на пике. Если это сделать до получения КП, дальше будет проще обсуждать цифры предметно и готовить приемочные испытания.

Что нужно описать до запроса КП, чтобы сравнение было корректным

Чтобы сравнить all-flash СХД честно, важно сначала описать свою виртуальную среду. Иначе поставщики пришлют красивые, но несопоставимые цифры: один посчитает под «легкий» профиль, другой - под «тяжелый», и формально оба будут правы.

Начните с инвентаризации нагрузок. Сколько виртуальных машин будет на старте и какие именно это типы: VDI, базы данных, файловые сервисы, терминальные сервера, прикладные системы. Укажите, какие ВМ критичны по времени отклика, а какие терпят задержки. Для Huawei OceanStor Dorado для виртуализации это особенно важно: поведение СХД сильно зависит от того, что именно вы на ней запускаете.

Дальше нужен профиль I/O, хотя бы приближенный. Опишите долю чтения и записи (например, 70/30), типичный размер блоков (4K, 8K, 64K) и пики: когда и насколько возрастает нагрузка (утро, конец месяца, ночные бэкапы, пересчет отчетов). Если точных метрик нет, можно взять данные из мониторинга гипервизора или сделать короткий замер в рабочий день.

Требования по доступности стоит формулировать как сценарии отказов, а не общие слова «должно быть надежно». Например: выдержать отказ одного контроллера, одного коммутатора SAN, одного пути от хоста до массива, обновление без простоя. Это сразу влияет на схему подключения, число портов и итоговую конфигурацию.

Не забудьте про ограничения площадки: сколько юнитов в стойке доступно, какая мощность и охлаждение, есть ли ограничения по уровню шума, как далеко расположены серверы и коммутаторы, что уже есть в сети (скорости, свободные порты, оптика или медь). Часто именно эти детали ломают «идеальную» конфигурацию из КП на этапе внедрения.

Чтобы КП можно было сравнить, отправьте поставщикам один и тот же набор вводных:

• Список типов нагрузок и число ВМ на старте
• Профиль I/O: чтение/запись, блоки, пики
• Сценарии отказов и допустимый простой
• Ограничения по стойке, питанию, охлаждению и текущей сети
• План роста на 1-3 года: емкость, производительность, порты

Простой пример: 250 ВМ, из них 120 VDI, 20 ВМ с базой, остальное - файловые и прикладные сервисы. Днем много мелких операций 4K, вечером - резервное копирование и рост записи. Если это не описать, в КП могут «оптимизировать» конфигурацию под дневной профиль и получить неприятный сюрприз ночью.

Чем точнее входные данные, тем меньше магии в КП и тем проще потом согласовать приемку по понятным, заранее зафиксированным условиям.

Порты и интерфейсы: что реально сравнивать в первую очередь

В КП по all-flash СХД легче всего «победить» цифрами, если не зафиксировать, чем именно вы будете подключаться. Для виртуализации это критично: даже самая быстрая система упрется в сеть, HBA/NIC хостов или коммутаторы, и вы получите высокий latency не из-за дисков, а из-за узкого горлышка на фронтенде.

Сначала определитесь с типом фронтенд-подключения. Для SAN чаще сравнивают FC (16/32Gb) и iSCSI/NVMe over RoCE по Ethernet (10/25/40/100GbE). Конвергентные варианты тоже возможны, но важно, чтобы ваш текущий стек (коммутаторы, карты в серверах, лицензии гипервизора, политика безопасности) реально это поддерживал. Если вы рассматриваете Huawei OceanStor Dorado для виртуализации, уточняйте не «есть ли порты FC/Ethernet», а какие именно модули, сколько портов в каждом и как они раскладываются по контроллерам.

Совместимость по скорости часто выглядит простой, но на практике ломает планы. Например, СХД с 100GbE не даст пользы, если у хостов 2x25GbE и коммутаторы не тянут нужное количество аплинков. С FC похожая история: 32Gb FC на СХД не поможет, если часть HBA в кластере 16Gb и вы вынуждены выравнивать скорость вниз. Отдельно фиксируйте среду (оптика или медь), типы трансиверов и длины линий, чтобы не выяснять это на монтаже.

Резервирование описывайте как схему, а не как фразу «2 контроллера». Для нормальной отказоустойчивости обычно нужны два независимых коммутатора (fabric A/B), и порты СХД должны быть распределены по контроллерам и по этим двум фабрикам. Иначе при падении одного контроллера или одного коммутатора вы теряете половину путей и получаете скачок задержек.

Где чаще всего возникает предел по производительности

На практике «упираются» не только порты СХД. Частые виновники: перегруженные коммутаторы, недостаток портов на хостах, неправильная настройка multipath, или банально мало активных путей (часть подключений простаивает).

Небольшой пример: кластер из 6 хостов с 2x25GbE каждый. Если вы подключили СХД всего двумя 25GbE портами на контроллер, то при пиковых бэкапах и миграциях ВМ упретесь в фронтенд, даже если у СХД «миллионы IOPS» на бумаге.

Как фиксировать это в КП

Попросите перечислить конкретику, которую можно проверить на приемке:

• Точные модели фронтенд-модулей, количество модулей и количество портов каждого типа.
• Скорости портов и режимы работы (например, 25/100GbE, 16/32Gb FC), тип среды (оптика/медь) и требования к трансиверам.
• Схему подключения с разнесением по двум контроллерам и двум коммутаторам, с указанием, сколько активных путей будет у каждого хоста.
• Ограничения и допущения: сколько портов доступно без «апгрейда лицензий/модулей», какие порты заняты под репликацию или сервисные сети.
• Рекомендованное количество NIC/HBA на хост и минимальные требования к коммутаторам, чтобы заявленные latency и IOPS были достижимы.

Если эти пункты в КП прописаны точно, сравнение становится честным: вы сравниваете не маркетинговые цифры, а реальные фронтенд-возможности вашей будущей конфигурации.

Протоколы и интеграция с гипервизором: без сюрпризов на внедрении

Даже лучшая all-flash СХД может дать разный результат в виртуализации из-за протокола и того, как он «дружит» с вашим гипервизором. Поэтому в КП важно фиксировать не только «поддерживает iSCSI/FC», а конкретную схему подключения, версии и ограничения.

Выбор протокола: что уточнить в КП

Сначала зафиксируйте, что именно вы планируете: iSCSI, Fibre Channel или (если рассматриваете) NVMe over Fabrics. Дальше просите описать параметры в формате «как будет у нас».

Например, для iSCSI важно: 10/25/40/100GbE, сколько физических портов на контроллер, как будет разделяться трафик (отдельные VLAN под storage), какой MTU планируется, и есть ли требования к коммутаторам (DCB, PFC - если заявляют, что это нужно). Для FC - скорость 16/32G, сколько FC-портов, как строятся фабрики A/B и нужны ли отдельные лицензии на FC-порты или «активацию» протокола.

Интеграция с гипервизором: версии и «обязательные мелочи»

В КП должна быть строка вида: «Поддерживаем VMware vSphere X.Y / Hyper-V (Windows Server YYYY) / KVM (дистрибутив и версия)», а не просто «VMware supported». Маленькая разница по версии часто означает большие отличия по драйверам, плагинам и поведению multipath.

Попросите описать, как будет настроен multipath: какой механизм (например, для VMware это NMP/PSP или vendor-плагин), какие политики балансировки (Round Robin и параметры), и как работает ALUA (active/optimized пути). Это те вещи, из-за которых потом появляются странные задержки и «прыгающая» производительность при отказах.

Фиксируйте в КП ожидаемую схему: сколько путей на LUN/том, сколько инициаторов на хост, и как будет выглядеть отказ одного контроллера, порта или коммутатора. Простой прием: попросите описать поведение «в норме» и «при отказе», в двух абзацах.

Функции виртуализации: что реально дает эффект

Для VMware отдельно уточните поддержку и условия включения VAAI (offload-клонирование, ускорение zeroing, hardware assisted locking). Эти функции уменьшают нагрузку на хосты и сеть во время клонирования ВМ, Storage vMotion и развертывания из шаблонов.

Если вы используете vVols, попросите в КП указать: поддерживается ли vVols именно для вашей версии vSphere, нужен ли отдельный VASA Provider, как он разворачивается и кто отвечает за его отказоустойчивость. Также полезно спросить про лимиты: максимальное число vVol, снапшотов и объектов на массив.

Как отловить лицензии и ограничения заранее

Самый частый сюрприз - когда «поддержка» есть, но половина нужного работает только при покупке отдельных опций. Чтобы это не всплыло на внедрении, просите в КП таблицу «функция - входит/лицензируется отдельно - требования к версии».

Что стоит включить в эту проверку:

• Протоколы (iSCSI/FC/NVMe-oF): включены ли порты и нужна ли активация.
• Интеграционные плагины/MPIO: что ставится на хост, кто обновляет, есть ли ограничения по ОС/ESXi.
• VAAI/vVols/VASA: входит ли в базу, есть ли лимиты по объектам.
• Репликация/снапшоты/клоны: лицензируются ли отдельно и как влияют на поддержку.

Если вы закупаете решение через интегратора, удобно заранее потребовать в КП «ответственность за совместимость»: кто подтверждает совместимость гипервизор-версии, HBA/NIC, драйверов и прошивок, и кто исправляет проблему, если она проявится на приемке.

Кеш и внутренняя архитектура: что спрашивать, чтобы понять поведение СХД

Когда в КП пишут просто «кеш 128 ГБ», это почти ничего не говорит о реальном поведении all-flash массива. Для виртуализации важнее понять, какие типы памяти используются, что именно в них хранится и что будет с задержками при записи в пиковые моменты.

Что именно называют кешем

Под словом «кеш» могут скрываться разные слои:

• DRAM для «горячих» данных и метаданных
• энергонезависимая память (NVRAM/SCM) для подтверждения записи
• SLC-буфер на SSD (если он есть) как временная зона для ускорения записи
• отдельные области под метаданные (таблицы дедупликации, карты блоков, снапшоты)

Попросите в КП разложить кеш по типам и назначению, а не одной цифрой. Для Huawei OceanStor Dorado для виртуализации это напрямую влияет на стабильность latency при смешанной нагрузке VDI, баз данных и файловых сервисов.

Отдельный вопрос - как подтверждается запись. Если массив отвечает «write acknowledged» до того, как данные защищены (в энергонезависимой зоне и с зеркалированием), то при сбое питания возможны неприятные сюрпризы. Если же запись подтверждается после сохранения в защищенной области, latency может быть выше, но поведение предсказуемее. В КП должно быть написано, какой именно сценарий используется и какие механизмы защиты применяются.

Компрессия, дедупликация, RAID и «скрытые» расходы

Снижение данных может давать красивую цену за ТБ, но меняет задержки. Важно уточнить, где выполняется дедупликация и компрессия (на лету или после записи), можно ли отключать их для отдельных LUN/datastore и какие типы данных почти не сжимаются (например, уже сжатые бэкапы, видео, шифрованные тома). Также попросите указать, в каких условиях вендор гарантирует заявленные IOPS и latency: с включенной оптимизацией или без.

RAID/erasure coding и ширина группы дисков влияют на запись и на rebuild. Чем шире группа, тем больше «штраф» на запись и тем дольше восстановление после выхода диска. Это особенно заметно в часы пик, когда параллельно идут снапшоты и бэкапы.

Чтобы сравнение КП было честным, задайте один набор вопросов всем участникам:

• Из чего состоит кеш (DRAM/NVRAM/SCM/SSD-буфер) и что хранится в каждом слое?
• Как подтверждается запись и как обеспечивается сохранность при потере питания?
• Дедупликация/компрессия: режим (inline/post), гранулярность, возможность выборочного отключения, ожидаемый рост latency?
• Схема защиты данных (RAID/EC), ширина групп, расчетное время rebuild и влияние на производительность?
• Снапшоты и клоны: сколько их планируется, какой overhead по месту и по производительности, что происходит при массовых удалениях?

Чем точнее эти ответы в КП, тем меньше риск, что на внедрении массив «вдруг» начинает держать нагрузку хуже именно в те моменты, которые для виртуализации самые важные.

Latency, IOPS и пропускная способность: как читать цифры без самообмана

В КП по all-flash СХД для виртуализации цифры легко выглядят красиво, но часто описывают тест, который не похож на вашу жизнь. Чтобы сравнение было честным, просите не только IOPS и GB/s, но и подробные условия, при которых эти цифры получены. И самое важное: оценивайте не среднюю задержку, а «хвосты».

Какие метрики просить и почему «средняя» обманывает

Для виртуализации критично, чтобы задержка была предсказуемой. Средняя latency может быть 0,5 мс, но если 1% операций улетает в 10-20 мс, пользователи это почувствуют как «подвисания».

Запрашивайте в КП:

• latency: средняя, 95-й и 99-й перцентиль, плюс максимальная
• IOPS и пропускная способность вместе с указанием latency, при которой они достигнуты
• распределение по чтению/записи (например, 70/30), а не «пиковый IOPS на чтении»

Короткий пример. В VDI утром много мелких чтений и логинов, днем добавляются фоновые обновления, а вечером могут идти бэкапы. В таком миксе важнее 99-й перцентиль, чем рекордные IOPS в идеальных условиях.

Условия измерения: без них цифры не сравнить

Одни и те же массивы могут показать «космос» или «средне» в зависимости от методики. Поэтому просите зафиксировать, как именно измеряли:

• размер блока (часто для VM это 4K-32K, но зависит от профиля)
• read/write соотношение и тип нагрузки (случайная или последовательная)
• queue depth и количество потоков (если их завысить, IOPS растут, но latency тоже)
• длительность теста и наличие прогрева (warm-up)
• включены ли дедупликация/сжатие, и какие данные использовали (случайные данные не сжимаются)

Если в КП написано «1 000 000 IOPS», но нет блока, R/W, QD и latency, это не показатель производительности в виртуализации, а рекламная цифра.

Steady state: измеряйте после заполнения и прогрева

Для all-flash систем важно, что происходит не в первые 5 минут, а через неделю под реальной нагрузкой. Просите результаты в steady state: после заполнения пула (часто ориентируются на 60-80%) и после прогрева кешей/метаданных.

Почему это важно: на «пустом» массиве и с холодными данными задержка может быть ниже, чем в рабочем режиме. А еще часть сценариев внезапно упирается не в SSD, а в контроллеры, кеш, внутренние очереди и работу сервисов данных.

Смешанная нагрузка и привязка к SLA

Один синтетический тест почти никогда не отражает картину виртуализации. В нормальном сравнении нужен хотя бы смешанный профиль: небольшие блоки + микс чтения/записи + параллельные фоновые операции (снапшоты, репликация, антивирус в гостевых ОС, бэкап).

Сведите цифры к понятному SLA для приложений:

• для VDI и файловых сервисов обычно важна стабильная низкая latency на мелких блоках
• для баз данных важны «хвосты» (99p), потому что редкие пики задержки дают медленные транзакции
• для бэкапов и больших копирований важнее пропускная способность, но не ценой того, что «убиваются» продовые VM

Если заранее записать целевые значения (например: «99p latency не выше X мс при Y IOPS на профиле 70/30, блок 8K»), вы получаете основу и для честного сравнения КП, и для будущих приемочных испытаний.

Какие пункты требовать в КП, чтобы сравнение было прозрачным

Чтобы сравнить Huawei OceanStor Dorado для виртуализации с другими all-flash СХД честно, в КП нужны не красивые «до X миллионов IOPS», а одинаковые исходные условия и полный состав поставки. Иначе вы сравниваете маркетинг, а не решение.

Попросите сделать КП в виде одной таблицы, где каждый параметр можно проверить. Важно, чтобы рядом с цифрами были пояснения: что именно входит, в какой конфигурации и с какими ограничениями.

Вот минимальный набор пунктов, который стоит требовать в каждом КП:

• Конфигурация и емкость: raw и usable (с указанием RAID/erasure coding), количество контроллеров, полок, дисков, блоков питания и вентиляторов, а также схема отказоустойчивости.
• Порты и подключение: число и тип портов по факту в поставке (FC/iSCSI/NVMe), скорость, сколько портов доступно под хосты, сколько занято под межконтроллерные связи.
• Производительность с условиями: размер блока, профиль read/write, указание p95/p99 latency, глубина очереди, заполнение массива (например 70-80%), включенные функции (сжатие, дедупликация, шифрование, снапшоты).
• Что включено в цену: лицензии на снапшоты, репликацию, QoS, мультипасинг/плагины, а также поддержка (срок, окна, время реакции), внедрение и обучение.
• Масштабирование: максимальное число полок и дисков, пределы по портам, варианты апгрейда контроллеров и возможность расширения без простоя (и что для этого реально нужно сделать).

Отдельным блоком попросите «требования к инфраструктуре». Там должны быть перечислены конкретные модели или минимум характеристики коммутаторов, трансиверов и кабелей, требования к HBA/NIC, а также версии гипервизора и сопутствующего ПО. Частая ловушка: цифры в КП даны под один тип сети, а в вашей серверной стоит другой.

Наконец, включите в КП пакет документов для приемки: методику испытаний, критерии прохождения (например p95 latency не выше заданного значения при вашем профиле), формат отчета (графики, логи), и кто со стороны поставщика имеет право подписывать протокол. Если вы работаете через системного интегратора (например, такого как GSE.kz), заранее договоритесь, кто готовит стенд и кто отвечает за воспроизводимость теста.

Приемочные испытания: пошаговый план, который можно согласовать заранее

Приемка all-flash СХД для виртуализации нужна не для рекордов в синтетике, а чтобы подтвердить предсказуемую задержку и стабильность под вашей реальной нагрузкой. Для Huawei OceanStor Dorado это особенно важно: цифры в КП почти всегда даны для «идеального» стенда, а в проекте решают версии, настройки и фоновые операции.

1) Что фиксируем заранее

Сначала зафиксируйте стенд так, чтобы его можно было повторить. Запишите модели серверов, HBA и коммутаторов, скорость FC или Ethernet, схему подключений, версию гипервизора, драйверов, multipath и настройки очередей (queue depth). Если есть SAN, отдельно фиксируйте зонирование и политику балансировки путей.

Дальше согласуйте сценарии нагрузок. Важно прописать профиль (случайное/последовательное, чтение/запись, блок 4К/8К/64К), длительность прогрева и самого теста, а также заполнение пула (например, 70-80%) и фоновые задачи: снапшоты, клонирование, миграции ВМ, backup, возможная репликация.

Не забудьте про конфигурацию хранения: как создаются пулы и тома/LUN, какие политики включены (thin/thick, дедупликация/сжатие, QoS, шифрование), размер stripe/segment, сколько дисков реально участвует. Если какая-то функция включается «по умолчанию», ее тоже нужно явно указать в плане, иначе результаты будут несравнимыми.

2) Как провести испытания

Удобно оформить план как короткую последовательность шагов с критериями выхода:

• Зафиксировать стенд и версии: гипервизор, драйверы, multipath, сеть или FC, схема подключения и скорости портов.
• Подготовить СХД: пулы, LUN/тома, политики, включенные функции, целевое заполнение пула и набор тестовых датасторов.
• Запустить согласованные нагрузки: синтетика (например, 4К random read/write) плюс «живые» шаблоны ВМ (VDI, SQL, файловые сервисы), с прогревом и одинаковой длительностью.
• Записать метрики: latency (средняя и 95/99 перцентиль), IOPS, пропускная способность, глубина очередей, загрузка контроллеров, промахи кеша, паузы при снапшотах и миграциях.
• Оценить стабильность и пики: держится ли задержка в пределах порога, нет ли «пилы» по latency, как система ведет себя при отказе пути или контроллера (failover) и после восстановления.

Критерии лучше формулировать не «IOPS не меньше X», а «99p latency не выше Y мс при Z IOPS на таком-то профиле и при включенных фоновых задачах». Это защищает от ситуации, когда средние цифры красивые, но пользователи видят короткие, регулярные «замирания».

Финал приемки - протокол. В него включают данные стенда, настройки, результаты по каждому сценарию, логи/скриншоты метрик и явный список отклонений с решением: принять, донастроить, повторить тест. Такой документ потом помогает и при поддержке, и при расширении системы.

Частые ошибки при выборе и приемке all-flash СХД

Самая частая причина провала сравнения и приемки - тестируют не ту систему, которая потом будет работать в проде. All-flash СХД может показывать отличные цифры на стенде, но в реальной стойке упереться в сеть, HBA/NIC, драйверы или настройки multipath. В итоге спорят не про массив, а про то, что условия были разными.

Одна из типовых ошибок - «тест в вакууме». Например, OceanStor Dorado подключили напрямую к двум хостам, а в проекте планируются коммутаторы, другие SFP, другая длина оптики и другая схема отказоустойчивости. Виртуализация чувствительна к мелочам: неправильный баланс путей, разные таймауты, отключенный ALUA/UA, не те очереди на HBA - и latency скачет, хотя «по паспорту» все должно быть хорошо.

Еще одна ловушка - сравнение несравнимого. Сегодня тест на 4K random read, завтра - 8K mixed, а потом внезапно 64K sequential. Плюс разные уровни заполненности: пустая СХД часто быстрее, чем заполненная на 70-80%, особенно если включены снапшоты и идет фоновая активность. Если вы сравниваете Huawei OceanStor Dorado для виртуализации с альтернативами, фиксируйте условия как договор: блок, профиль, глубина очереди, число ВМ, заполненность пула и включенные функции.

Третья ошибка - погоня за пиковыми IOPS вместо стабильной задержки. Для пользователей важнее ровная работа: не «миллионы IOPS на графике», а то, что 95-й и 99-й перцентили latency не улетают вверх при нагрузке соседних ВМ.

Есть и коварный момент с экономией места. Компрессию и дедупликацию часто включают «для красоты КП», но не проверяют, как это влияет на CPU контроллеров и задержку на реальных данных. На синтетике все может быть гладко, а на базе данных или VDI внезапно появляются пики.

При приемке часто забывают проверить деградации. В реальной жизни ломается не «массив целиком», а мелочи: порт, линк, коммутатор, контроллер, диск, путь. Проверьте хотя бы это:

• отказ одного порта/линка и восстановление без паузы ВМ
• отказ коммутатора или одного fabric (для FC) и корректный multipath
• деградацию при rebuild/ресинке и фоновых задачах
• поведение при заполнении пула и активных снапшотах
• стабильность перцентилей latency под смешанной нагрузкой

И наконец, организационная ошибка: нет единого документа, где заранее согласованы критерии успеха. Тогда любой результат можно трактовать как угодно. Согласуйте до теста: какие метрики снимаем (включая перцентили), какие сценарии считаются «пройдено/не пройдено», и кто отвечает за конфигурацию хостов и сети.

Короткий чеклист и следующие шаги перед покупкой

Перед тем как подписывать договор на Huawei OceanStor Dorado для виртуализации, полезно на одной странице зафиксировать, что именно вы сравниваете и как будете принимать результат. Это снижает риск, что “похожая” конфигурация в реальности окажется другой по портам, отказоустойчивости или задержкам.

Вот короткий чеклист, который удобно приложить к запросу КП и к плану приемки:

• Зафиксируйте точную конфигурацию: контроллеры, лицензии, набор портов по типам и скорости, модули, диски, полки, а также условия, при которых измерялись метрики (объем данных, степень заполнения, включенная дедупликация/сжатие, профиль нагрузки).
• Опишите протоколы и схему резервирования: две фабрики FC или две независимые IP-сети, отдельные VLAN, multipath на гипервизорах, правила зонирования/доступа и кто за что отвечает при настройке.
• Согласуйте KPI приемки заранее: не только “среднюю” задержку, а 95 и 99 перцентили latency, целевые значения пропускной способности и IOPS, плюс поведение на пиках (очереди, “хвосты” задержек, деградация при росте числа ВМ).
• Добавьте сценарии отказов: отключение одного контроллера, одного пути, одного коммутатора/фабрики, перезагрузка узла, деградация диска. Для каждого сценария укажите, что считается успехом (время переключения, отсутствие остановки ВМ, допустимый рост задержек).
• Подготовьте шаблон протокола испытаний и список артефактов: экспорт настроек СХД, параметры multipath, версии прошивок, схемы подключения, логи, скриншоты ключевых экранов, сырые результаты тестов и краткое резюме “прошло/не прошло”.

Следующие шаги обычно самые эффективные: короткий PoC на вашем типовом наборе ВМ (или близком по профилю) и приемка по заранее согласованному протоколу. Если у вас нет ресурса вести это внутри, подключайте интегратора, который может взять проект под ключ и при этом оставаться вендор-нейтральным: например, GSE.kz как системный интегратор может помочь собрать корректные требования, согласовать KPI, организовать PoC и довести внедрение до понятного результата с документами приемки.