16+
В проектах виртуализации основная неопределенность возникает на стыке вычислительного и дискового контуров: тип доступа к данным, поддержка гипервизоров, поведение при отказах и обновлениях. Поэтому в техническом задании все чаще фиксируют программно-аппаратный комплекс виртуализации как единый проверенный блок, где аппаратная платформа и программный слой заранее согласованы по совместимости — это упрощает ввод в эксплуатацию и последующее сопровождение.
Даже при корректном подборе серверов и сети проблемы часто проявляются позже — при росте нагрузки, плановых работах или аварийном восстановлении. На практике критичны следующие моменты:
согласованность SAN/NAS/S3-доступа с архитектурой кластера и приложениями;
предсказуемость отказоустойчивости (в том числе в двухконтроллерных схемах и режимах с ALUA);
масштабирование хранилища без пересборки стека;
наличие встроенных механизмов защиты данных (WORM, снапшоты, репликация, компрессия, дедупликация — где поддерживается);
совместимость с выбранными платформами виртуализации и ОС инициаторов.
Набор критериев лучше формулировать через сценарий использования, а не через абстрактные мощности:
сценарий виртуализации: кластер для корпоративных сервисов, VDI, тестовые/DEV-стенды;
тип доступа к хранилищу: SAN или NAS, при необходимости — объектный S3;
протоколы: FC/iSCSI (в т.ч. iSER — если требуется), SMB/NFS и дополнительные протоколы в зависимости от задач;
отказоустойчивость: двухконтроллерность, режимы работы и поддержка ALUA;
масштабирование: как наращиваются диски и полки или модули, насколько прозрачно расширение;
совместимость с платформами: перечень поддерживаемых гипервизоров и их особенностей интеграции;
опции работы с данными: WORM, снапшоты, репликация, компрессия, дедупликация (если предусмотрена);
эксплуатация и обновления: возможность выполнять регламентные операции без остановки сервисов там, где это заявлено;
реестровость: наличие в реестре Минпромторга России как практический фактор для части закупок (без юридических интерпретаций).
Короткий чек-лист, который помогает связать потребности кластера с характеристиками ПАК:
какие хранилища нужны для VM: блочные тома (SAN) или датасторы, шары (NAS);
какие протоколы обязательны (FC, iSCSI, SMB/NFS, при необходимости S3);
какие платформы виртуализации должны поддерживаться (включая версии, где они указаны);
требуется ли Active-Active ALUA и как будет организована работа при отказе контроллера;
какие функции обязательны для данных: WORM, снапшоты, репликация, компрессия, дедупликация (при наличии);
как планируется рост емкости и каким способом добавляются дисковые модули или полки;
какие ОС выступают инициаторами и должны корректно работать с доступом к данным;
какие ограничения по окнам обслуживания допустимы для обновлений и регламентных работ.
Описывают «хранилище для виртуализации», но не фиксируют, где нужен SAN, а где достаточно NAS.
Включают в ТЗ «совместимость с гипервизорами», не перечисляя конкретные платформы и контуры доступа.
Забывают про требования к защите данных (WORM, снимки, репликация), оставляя их «на потом».
Не увязывают масштабирование с жизненным циклом кластера, что приводит к пересборке архитектуры при росте.
Формулируют отказоустойчивость общими словами, без акцента на двухконтроллерность и режимы с ALUA.
В каталоге раздела ПАК представлены три устройства. Общая аппаратная база для всех: размещение в стойку 19", высота 4U, 4 × 2nd Gen Intel Xeon Scalable, дисковая подсистема 24 SSD/HDD 2,5”/3,5” HotSwap, а также признак присутствия в реестре Минпромторга России. Отличия задаются программным слоем и поддерживаемыми сценариями доступа.
ПО BAUM Storage AI поддерживает платформы виртуализации VMWare ESXi, решения на базе Linux KVM, Microsoft Hyper-V, XenServer, Proxmox VE, RHEV. По доступу приведены примеры файловых протоколов SMB v2/v3, NFS v3/v4, FTP и блочных — iSCSI 10/25 ГБ, Fibre Channel 8/16 ГБ. Среди опций: WORM, компрессия, снапшоты и репликация. В эксплуатационном контуре отдельно отмечается возможность обновления микрокода без простоя сервисов (нейтрально — как признак удобства сопровождения).
ПО RAIDIX 5.X описывается как российская программно-определяемая СХД для задач высокой производительности. По виртуализации указаны ESXi Server 7.0, zVirt 4.0, ROSA Virtualization 3.0. Примеры протоколов: SMB v2/v3, NFS v3/v4, AFP, FTP, а также блочные FC 8/16/32 ГБ, iSCSI/iSER 10/25/40/100 ГБ, InfiniBand SRP (в т.ч. 100 ГБ), SAS 12 ГБ. Из опций упомянуты WORM и защита от скрытого повреждения данных. При работе с flash-накопителями отмечается ERA Engine (параллелизация, lockless-архитектура).
ПО ARGO предназначено для гибридных и all-flash СХД с SAN и NAS доступом. По виртуализации перечислены VMware (VAAI), KVM, Microsoft Hyper-V Server, Proxmox VE. Протоколы: SMB v2, NFS v3/v4, FC 8/16/32 ГБ, iSCSI 10/25/40/100 ГБ, а также S3 для объектных сценариев. Опции: WORM, тонкие тома, клоны, снапшоты, компрессия, дедупликация. Дополнительный механизм — поддержка RAID B3 (тройной контроль честности).
Кластер виртуализации для корпоративных сервисов
Если в контуре одновременно нужны SAN-тома для VM и файловые ресурсы, важны протоколы (FC/iSCSI и SMB/NFS) и перечень поддерживаемых платформ. В таких условиях чаще рассматривают ПХ424И24БМ-БА (широкий список платформ виртуализации и набор протоколов) либо ПХ424И24БМ-АР, если требуется дополнительно встроить S3 и сохранить SAN+NAS в одном решении.
VDI / виртуальные рабочие места
Для VDI значимы управляемость данных и предсказуемые механизмы защиты: WORM, снимки, компрессия, дедупликация — по политике. Здесь уместен ПХ424И24БМ-БА за счет опций снапшотов или репликации и заявленного подхода к обновлениям без остановки сервисов, альтернативой может быть ПХ424И24БМ-АР, когда важно сочетание SAN/NAS и функции тонких томов и дедупликации.
Тестовые или пилотные стенды и DEV/QA
В таких средах ценится быстрый возврат к состояниям и тиражирование окружений. Если акцент на снапшоты и репликацию — логика ведет к ПХ424И24БМ-БА, если требуется клонирование или /снимки и гибкое управление томами, можно рассматривать ПХ424И24БМ-АР с его опциями клонов, снапшотов и тонких томов — при условии, что протоколы доступа подходят архитектуре стенда.
Backup/архив для виртуальных сред
Для резервного контура в первую очередь проверяют WORM и возможности работы со снимками или репликацией. В этой логике чаще подходит ПХ424И24БМ-БА (WORM плюс снапшоты и репликация). ПХ424И24БМ-АР также применим при ориентации на WORM и клоны или снапшоты, а выбор уточняется тем, нужен ли объектный доступ или приоритет — SAN/NAS.
Объектные сценарии S3 для хранилищ и сервисов
Если требуется S3 для репозиториев, сервисов или объектных архивов, профильным вариантом становится ПХ424И24БМ-АР, поскольку S3 указан как поддерживаемый тип доступа. Далее сопоставляют, какие протоколы (SAN/NAS) нужны параллельно и какие опции данных (компрессия, дедупликация, WORM) обязательны.
ПАК в виртуальной инфраструктуре стоит подбирать не по названию, а по связке требований: сценарий (кластер, VDI, DEV/QA, backup), тип доступа (SAN/NAS/S3), протоколы, совместимость платформ и набор эксплуатационных опций. Такой подход позволяет заранее зафиксировать архитектуру хранения для VM и снизить риски несовместимости и непредсказуемого сопровождения.