СХД среднего класса для виртуализации: MSA, ME, ETERNUS

О чем спорят, когда выбирают СХД под виртуализацию

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

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

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

Чаще всего спор идет о том, что станет первым узким местом: производительность (IOPS и задержка), рост по полкам и емкости, поведение кэша и контроллеров под пиком.

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

Поэтому в выборе между HPE MSA, Dell PowerVault ME и Fujitsu ETERNUS чаще спорят не о бренде, а о прогнозе: какая нагрузка будет через год и где вы хотите запас - по задержке, по расширению или по кэшу.

Метрики, без которых сравнение не имеет смысла

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

IOPS, MB/s и latency отвечают на разные вопросы:

• IOPS важны для множества мелких операций (типично для виртуальных машин и баз данных).
• MB/s показывают скорость потока данных, например для бэкапов или больших файлов.
• Latency (задержка) часто важнее всего: даже при приличных IOPS пользователи будут жаловаться, если отклик скачет и растет в пике.

Отдельная ловушка - очереди. Результаты сильно зависят от глубины очереди (queue depth): чем она выше, тем проще «разогнать» IOPS, но это не всегда похоже на поведение VMware или Hyper-V в вашей конфигурации. Для виртуализации честнее ориентироваться на низкую и стабильную задержку при умеренной очереди, чем на рекорды при завышенной.

RAID и тип дисков меняют картину радикально. SSD против HDD - очевидно, но важнее помнить про «штраф на запись» у RAID 5/6: запись становится дороже, а значит растет latency. Кэш контроллеров может сгладить пики, но не отменяет математику RAID и ограничения по дискам.

И наконец, узкое место часто не в дисках, а в «обвязке»: контроллеры, порты, хост-интерфейсы и настройка multipath.

Перед сравнением MSA, ME и ETERNUS стоит зафиксировать одинаковые условия: профиль нагрузки (процент чтение/запись и размер блока), допустимую задержку именно на пике, глубину очереди и число потоков, RAID и тип дисков, наличие кэша на запись, а также скорость и количество портов на стороне СХД и хостов.

Когда эти параметры совпадают, цифры становятся сопоставимыми, а выбор - заметно проще.

Границы по IOPS: как понять, что вам хватит

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

Начните с того, как именно получена цифра в тесте. Один и тот же массив может показать «красивые» IOPS на 4K чтении и заметно просесть на 8K-16K, при смешанном чтении/записи или при меньшем числе потоков. Для виртуализации показательны сценарии «случайный доступ + 60/40 или 70/30 чтение/запись» и измерение задержки на уровне, который вы готовы терпеть в гостевых ОС.

Что стоит уточнить у вендора или в отчете пилота:

• размер блока и долю чтения/записи;
• число потоков и глубину очереди;
• тип RAID и сколько дисков участвовало в тесте;
• какая задержка была при заявленных IOPS, а не только «максимум»;
• что происходит при деградации: rebuild, отказ диска, заполнение пула.

Смешивание NVMe, SSD и HDD в одной системе тоже дает сюрпризы. «Быстрые» диски могут не раскрыться, если горячие данные постоянно «проваливаются» на медленный уровень, если алгоритмы тиринга не подходят под вашу нагрузку или если контроллер упирается в запись и защиту данных.

Практичный ориентир простой: снимите текущие IOPS и задержку на хостах (или на старой СХД), добавьте прогноз по росту числа ВМ и сервисов и заложите запас. Часто разумный запас по IOPS - 30-50% на рост и пики, плюс отдельный резерв на «плохие дни» вроде rebuild и обновлений, когда профиль внезапно становится более «записывающим».

Границы по полкам и емкости: как планировать рост

При выборе СХД среднего класса для виртуализации спор обычно начинается с IOPS, но покупку чаще всего «ломает» рост по емкости. У любой линейки (HPE MSA, Dell PowerVault ME, Fujitsu ETERNUS) есть максимум по количеству дисковых полок, но в реальности масштабирование ограничивают не только цифры из спецификации.

«Сырые» терабайты почти никогда не равны полезной емкости. RAID забирает место под защиту, часто нужен hot spare, плюс остаются резервы под снапшоты, репликацию и «воздух» для нормальной работы пула. Если планируете занять 95% пула, ждите проблем: скорость падает, задержка растет, а обслуживание (rebuild, перераспределение данных) начинает заметно мешать виртуальным машинам.

При расширении пула обычно происходит одно из двух. Либо массив какое-то время активно перераскладывает данные (и это поднимает задержку), либо вы создаете новый пул и переносите нагрузки вручную. Второй вариант чаще проще контролировать. Добавление полок иногда дает не только емкость, но и производительность (больше дисков или больше SSD). Но если вы уже уперлись в контроллеры, кэш или порты, новые диски не спасут.

Практический способ прикинуть рост

Держите план простым:

• считайте полезную емкость: RAID + hot spare + минимум 20-30% свободного места;
• заранее решите, чем будете расти: тем же типом дисков или отдельным пулом;
• проверьте, выдержит ли обслуживание: rebuild на больших дисках может идти долго;
• заложите запас по стойке: RU, вес полок, место под кабели;
• уточните по инженерке: питание (A/B), PDU, охлаждение и шум.

Иногда именно стойка и электрика становятся «потолком» раньше, чем лимит по полкам. Поэтому емкость стоит планировать вместе с площадкой, а не только по прайсу и спецификации.

Кэш и контроллеры: когда это реально важно

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

Главный режим, который влияет на отклик, - write-back. В нем запись подтверждается сразу после попадания в кэш, а на диски уходит чуть позже. Это снижает задержку и повышает IOPS на мелких записях, но требует защиты от потери питания. Поэтому важны батарея или суперконденсатор (иногда вместе с энергонезависимой памятью), чтобы кэш не «пропал» при отключении электричества.

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

Кэш почти не помогает, когда диски и так быстрее нагрузки или когда рабочий набор слишком большой и «не помещается» в кэш. Это часто видно в таких сценариях: длинное чтение больших массивов без повторов, упор в сеть или хосты (а не в СХД), все на SSD и задержка определяется очередями и CPU контроллеров, а также включены функции, которые заметно меняют профиль I/O.

В описании модели полезнее всего проверять конкретику: объем кэша на контроллер и сколько из него реально доступно; есть ли write-back по умолчанию и какие условия его отключают; чем защищен кэш при потере питания; есть ли зеркалирование кэша; как ведут себя контроллеры при отказе и насколько быстро происходит переключение.

Интерфейсы и подключение: где теряются IOPS

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

FC, iSCSI, SAS: что проще и что дает по задержке

FC обычно дает предсказуемую задержку и меньше сюрпризов от общего трафика, но требует FC-коммутаторов и дисциплины в зонировании. iSCSI проще по входу, потому что работает поверх Ethernet, но требует аккуратной сети (скорость, буферы, jumbo frames, отсутствие лишней маршрутизации). SAS-подключение выглядит «простым и коротким», зато оно менее гибкое по масштабированию и часто ограничивает топологию.

На практике разница ощущается быстро: если в iSCSI смешать хранение и обычную сеть, рост задержки может «съесть» выгоду от SSD. А в FC можно получить отличные цифры, но потерять их из-за неверного зонирования или перегруженного ISL между коммутаторами.

Сколько портов нужно и почему MPIO обязателен

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

Практическая базовая схема: два сегмента (A и B) или два независимых коммутатора; минимум по 2 порта на хост под storage и по 2 порта на контроллер; MPIO на хостах с понятной политикой балансировки; разнесение путей по разным NIC/HBA, коммутаторам и VLAN/VSAN.

MPIO нужен не только для отказоустойчивости. Он помогает равномерно грузить порты, чтобы один путь не превращался в «пробку», из-за которой падают IOPS и растет задержка.

Типовые ошибки: iSCSI через перегруженные коммутаторы без QoS, «один большой VLAN на все», разный MTU на участках, неправильный LACP. В FC часто встречаются крайности: все хосты в одной зоне или слишком сложная схема без понятной диагностики.

Пошагово: как выбрать между MSA, ME и ETERNUS

Выбор между HPE MSA, Dell PowerVault ME и Fujitsu ETERNUS обычно упирается не в бренд, а в то, насколько конкретная конфигурация выдержит вашу реальную нагрузку. Для СХД среднего класса для виртуализации важно сравнивать решения в одинаковых условиях: одинаковые диски, одинаковая схема RAID, одинаковое число полок и одинаковая ширина подключений.

Сначала договоритесь с командой виртуализации о вводных: сколько ВМ будет жить на массиве, какие сервисы критичны (базы, VDI, файловые), как быстро растет объем и сколько «пиков» в день.

Дальше помогает простой алгоритм:

• снимите факты с текущей среды: средние и пиковые IOPS, read/write, размер блока, latency по датасторам, заполнение и скорость прироста;
• задайте целевую задержку для ключевых сервисов (отдельно для баз данных и для «обычных» ВМ);
• соберите 2-3 конфигурации-кандидаты под одинаковую полезную емкость и одинаковый уровень защиты;
• проверьте ограничения масштабирования: максимум полок, дисков, кэша, портов, и что будет с производительностью при росте;
• сравните по одному сценарию теста: те же ВМ, те же профили, те же окна пиков.

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

Чтобы выбор не превратился в спор, заранее зафиксируйте критерии приемки на внедрении: предельную latency на пике для критичных сервисов, запас на рост (например, 30-40%), достижимую полезную емкость с учетом RAID и hot spare, понятный сценарий расширения, а также как именно вы будете мониторить и подтверждать результат после запуска.

Типовые нагрузки виртуализации и как они упираются в СХД

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

Самые частые профили в кластере:

• базы данных: много мелких случайных операций, важнее стабильная задержка, чем пиковые IOPS;
• VDI: резкие всплески (утренний логон, обновления), сильно зависит от кэша и политики записи;
• файловые сервисы: умеренная нагрузка, но много метаданных и мелких операций, которые «режут» диски;
• резервное копирование: длинные последовательные потоки, легко забивают каналы и мешают «боевым» ВМ.

Проблема «средней температуры» в том, что 80% времени все спокойно, а 20% времени система упирается в СХД и пользователи видят тормоза. Средняя задержка за день может выглядеть нормально, но краткие пики в 20-50 мс уже превращают VDI и базы данных в мучение. Поэтому смотрите не только среднее, но и 95-й или 99-й процентиль задержки.

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

Снапшоты и репликация тоже забирают ресурсы. Проверьте заранее, где хранится snapshot и как он растет при активной записи, как часто планируются снимки и как долго они живут, в какие окна идет репликация и бэкап, и что важнее для вас: RPO/RTO или стабильная производительность днем.

На практике помогает простое правило: тяжелые базы, VDI и бэкап лучше разводить по времени или по пулам. Иначе «невидимая» служебная нагрузка легко съедает запас по задержке.

Пример из практики: кластер виртуализации в организации

Типичный кейс для СХД среднего класса выглядит так: в компании есть 2-3 кластера (прод, тест, отдельный контур для критичных сервисов), всего 40-80 виртуальных машин. Два сервиса «держат бизнес» (например, база 1С и почта), а параллельно идет пилот VDI на 20-30 рабочих мест.

Перед расчетом СХД полезно собрать входные данные. Самая частая причина промаха - считать «по емкости», не увидев пики и фоновые операции.

Вопросы, которые реально меняют итоговую конфигурацию:

• когда бывают пики по IOPS и задержке (утро, конец месяца, регламентные закрытия)?
• есть ли «шумные соседи» - ВМ, которые периодически съедают диск (антивирус, индексация, отчеты)?
• какое окно бэкапа и как он устроен (снапшоты, репликация, ночные полные копии)?
• какой рост планируется на 12-24 месяца по ВМ и по данным?
• нужна ли отдельная зона под VDI, чтобы он не влиял на критичные сервисы?

Дальше нагрузки удобно разложить по пулам хранения. В этом примере логика простая: быстрый пул для критичных сервисов и VDI, универсальный для основной массы ВМ, архивный для файлов, логов и редко используемых образов. Так проще выбирать диски и не переплачивать за «скорость везде».

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

Частые ошибки при выборе и закупке

Самая частая ошибка - сравнивать IOPS как «цифру в вакууме». У одного вендора тест на 100% чтение, у другого - 70/30, у третьего завышена очередь. Для виртуализации важнее связка: задержка под смешанной нагрузкой и ее стабильность при росте очереди.

Вторая боль - емкость «впритык». В RAID вы теряете часть дисков под паритет или зеркало, плюс нужен запас под rebuild, снапшоты, метаданные и будущие ВМ. Если взять ровно столько, сколько занято сейчас, через пару месяцев начинаются ограничения: нельзя расшириться без боли, нельзя держать запас под аварии.

Часто в одном пуле смешивают продуктив и бэкап, и это убивает предсказуемость. Ночной бэкап с большим числом потоков легко «съедает» очередь, и ВМ получают скачки задержки. Лучше разделять пулы или хотя бы вводить явные лимиты для задач копирования.

Еще одна ловушка - экономия на сети. Упираются не в СХД, а в один коммутатор, пару 10GbE портов, неправильный MTU, отсутствие multipath или ошибки в настройке iSCSI/FC на хостах. В итоге массив выглядит слабым, хотя проблема вообще не в нем.

Перед закупкой проверьте пять вещей:

• условия теста: блок, профиль, очередь, доля чтения/записи и целевая задержка;
• расчет емкости с учетом RAID, hot spare, снапшотов и запаса роста;
• разделение продуктивных томов и бэкап-целей (или понятные лимиты);
• пропускную способность и отказоустойчивость сети (порты, пути, настройки);
• совместимость: прошивки, MPIO/DSM, драйверы и поддержка вашей версии VMware или Hyper-V.

Чеклист перед финальным выбором и следующий шаг

Перед покупкой полезно на один лист собрать то, что нельзя «додумать» по ходу проекта. Так быстрее видно, где MSA, ME или ETERNUS упираются в пределы именно в вашей схеме.

Сначала зафиксируйте требования со стороны приложений и бизнеса - измеримо:

• целевая задержка (latency) в рабочие часы и на пике, отдельно для критичных ВМ;
• рост емкости на 12-24 месяца и допустимые окна простоя на расширение;
• самые чувствительные сервисы (VDI, базы, файловые, резервное копирование) и их профиль чтение/запись;
• требования по RPO/RTO и что именно считается «восстановлено»;
• ограничения площадки: питание, стойки, доступные порты SAN/LAN.

Дальше проверьте, что выбранная конфигурация не «закончится» раньше, чем вы планируете. Тут важны не только диски:

• сколько полок реально добавить без замены контроллеров и какой запас по портам останется;
• ограничения пулов, RAID-групп, thin, snapshot, репликации (если нужно);
• резерв по производительности: что будет при деградации (1 контроллер, rebuild, отказ диска);
• два независимых пути от хоста до СХД (мультипасинг) и понятный мониторинг;
• процедура обслуживания: кто и как меняет диски, контроллеры, батареи или модули кэша.

План внедрения тоже лучше описать заранее: сначала подключить новую СХД к тестовому хосту, прогнать нагрузку, похожую на ваш «понедельник 10:00», и только потом мигрировать прод. Критерии приемки простые: достигли целевой latency, выдержали пиковые IOPS, аварийные сценарии проходят по инструкции.

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