Comments 19
не совсем понятен момент:
Лицензируется данный продукт по объему, который мы презентуем гипервизору в качестве datastore. Важно понимать, что это будет «сырой» объем с точки зрения конечного пользователя. В первую очередь локальные диски ваших серверов будут объединены в RAID-группы на уровне RAID-контроллера узла. Получившийся полезный объем и будет лицензироваться.
в моей терминологии «сырой» объем — это объем, получаемый путем сложения всех объемов всех дисков, а тут, видимо, это утверждение не совсем верно?
1. Аппаратный, собираемый на RAID-контроллерах серверов (узлов) до загрузки ОС. Полученный объем и лицензиурется.
2. Софтовый, собираемый в Network RAID на базе тех томов, которые мы создали на первом уровне. Для конечного пользователя (администратора\менеджера виртуального кластера) именно этот объем будет «полезным», т.е. пригодным для использования.
Просто ScaleIO, например, принимает пачку дисков, и совсем не обязательно собирать из них RAID на железе. Это даёт бОльшую гибкость в манипуляциях с дисками — их можно выкидывать и менять на диски бОльшего объёма, например, без остановки узла и пересборки аппаратного массива. Если же у вас аппаратный RAID, то это сделать будет малость затруднительно, как минимум потребуется поддержка такой операции RAID-контроллером (online capacity extension, OCE), а такое умеют не все контроллеры.
В настоящее время все больше вендоров пробуют выпускать свои вариации на тему SDS. Естественно в каждом решении есть свои нюансы и интересные подходы и технологии.
Интересно бы увидеть более подробные TTX данного решения и рекомендации.
1) Максимальное число узлов в кластере?
2) Максимальный размер блочного тома, отдаваемого гипервизору? И общий максимальный поддерживаемый объем в рамках кластера (полезный или raw)?
3) Какие протоколы используются для того что бы подмапить блочный том гипервизору? Что-то кроме iSCSI поддерживается?
4) Как пробрасывается физический том с RAID контроллера в виртуальную ноду кластера?
5) Есть или нет условно бесплатная версия для тестов без покупки сервера HP?
6) Какая пропускная способность сети требуется\рекомендуется для кластера? Для Multi-site SAN?
7) Как работает тиринг? Вернее даже каким образом определяются блочные тома в конкретные тиры?
8) При помощи чего реализуется "Создание консистентных снэпшотов на уровне приложений"? И какие приложения поддерживаются?
9) Как кластер реагирует на временное исчезновение Quorum Witness виртуалки или шары?
10) Каким образом проводится обновление данного решения? Узлы обновляются поочередно? С перезагрузкой? При перезагрузке ноды на начинается перестроения Network RAID?
2) 128TiB.
3) В StoreVirtual VSA поддерживается только iSCSI, в StoreVirtual 3200/4000 еще есть поддержка FC 8Gb/16Gb. Добавить поддержку CIFS (SMB3.1), NFS, HTTP & FTP возможно с помощью HPE StoreEasy 3830 Gateway Storage.
4) Через VMFS или RDM для VMware vSphere, также поддерживается разворачивание в средах Microsoft Hyper-V и KVM.
5) Есть тестовая лицензия без технических ограничений на 60 дней — http://h20392.www2.hpe.com/portal/swdepot/displayProductInfo.do?productNumber=StoreVirtualSW (нужна регистрация). Нужны следующие файлы:
— HPE StoreVirtual Centralized Management Console for Windows/Linux
— HPE StoreVirtual VSA 2014 for vSphere
— HPE StoreVirtual Multipathing Extension Module for Vmware
— HPE StoreVirtual VSA Installation and Configuration Guide
— HPE StoreVirtual Storage User Guide
— HPE StoreVirtual Multipathing User Guide
6) Для кластера/Multi-site требуется 1Gb/s, рекомендуется 10Gb/s.
7) Работает в реальном времени блоками 256 KB
8) Консистетнтные для VMware and Hyper-V VMs и Microsoft VSS
9) Давно проверяли с заказчиком на P4500 G2 Multi-Site — без происшествий.
10) С практики обновляется гладко. Узлы обновляются поочередно с перезагрузкой сервисов, без перестройки массива данных.
Хочу добавить относительно StoreVirtual 3200 — продукт тоже крайне интерессный в плане переноса архитектуры SDS на аппаратную платформу. Коллеги обещали привезти его мне в демо до конца года. Как только получу на руки, то сразу напишу аналогичный обзор.
По 2-му 128TiB это размер чего? Или это ответ сразу на оба вопроса из второго пункта?
По 9-тому так и не понял как обеспецивается консистентность? В гипервизор ставится програмный агент? Если нет, то не вижу каким способом СХД сообщает OS или гипервизору на сервере о том что сейчас будет сделан снэпшот и нужно синхронизировать все буферы и кэши на диски.
ximik13, все всерно, для сбрасывания «грязного» кэша используется агент под названием Application Aware Snapshot Manager:
— To use the Application Aware Snapshot Manager in VMware environments, the vSphere servers must be managed by VMware vCenter. The Application Aware Snapshot Manager must be installed on the vCenter server that manages all other vSphere servers connected to the StoreVirtual OS volumes.
— The Application Aware Snapshot Manager uses the VSS Provider to create an application-quiesced snapshot on the HP StoreVirtual SAN. The VSS Provider is the StoreVirtual plug-in for the Microsoft VSS (Volume Shadow Copy Service) framework.
8) Консистетнтные для VMware and Hyper-V VMs и Microsoft VSS
Подробнее: в общем виде используется ПО Application Aware Snapshot Manager, которое ставится на внешний хост и управляет процессом создания консистентных снэпшотов (вернее его координирует, т.к. создание снэпшотов доступно и из консоли самой VSA). Поддерживаются ОС Windows Server 2012, Windows Server 2012 R2, Windows Server 2012 R2 Core, Windows Server 2008, 32-bit и 64-bit versions, vSphere (5.0, 5.1, 5.5 и 6.0). Перед созданием аппаратного снэпшота производятся необходимые действия по остановке (заморозке, снэпшоту) приложения (файловой системы).
7) (Тиринг) Работает в реальном времени блоками 256 KB
Чуть более подробно: можно определить два тира – 0 и 1. При подключении дискового пространства (датастора) в виртуальной машине VSA можно определить тип тира. По умолчанию все логические тома создаваемые внутри кластера используют оба тира. Все новые блоки всегда пишуться на тир 0 (пока там есть место), потом, по мере его заполнения, блоки начинают пистаться на тир 1. Все это время ведется т.н. heat map (карта горячих и холодных блоков на основе частоты обращений к них). Как только какие-то блоки становятся кандидатоми на миграцию, начинается миграция таких блоков. Для этого определяется равное кол-во холодных и горячих блоков и они перемещаются. Минимальный блок для миграции 256 КБ, общее кол-во таких блоков определяется динамически исходя из степени загрузки системы.
Назад к истокам или шаг вперед? HPE StoreVirtual VSA