Pull to refresh

Comments 19

Добрый день.

не совсем понятен момент:

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


в моей терминологии «сырой» объем — это объем, получаемый путем сложения всех объемов всех дисков, а тут, видимо, это утверждение не совсем верно?
В данном случае возникает два уровня RAID:
1. Аппаратный, собираемый на RAID-контроллерах серверов (узлов) до загрузки ОС. Полученный объем и лицензиурется.
2. Софтовый, собираемый в Network RAID на базе тех томов, которые мы создали на первом уровне. Для конечного пользователя (администратора\менеджера виртуального кластера) именно этот объем будет «полезным», т.е. пригодным для использования.
А собирать аппаратный RAID — это обязательное условие? Или можно презентовать JBOD, и данный продукт сам соберёт из них отказоустойчивую конфигурацию?

Просто ScaleIO, например, принимает пачку дисков, и совсем не обязательно собирать из них RAID на железе. Это даёт бОльшую гибкость в манипуляциях с дисками — их можно выкидывать и менять на диски бОльшего объёма, например, без остановки узла и пересборки аппаратного массива. Если же у вас аппаратный RAID, то это сделать будет малость затруднительно, как минимум потребуется поддержка такой операции RAID-контроллером (online capacity extension, OCE), а такое умеют не все контроллеры.
Для VSA нет обязательного условия иметь аппаратный RAID, т.к. ему через гипервизор презентуется дисковая емкость — в виде сырых дисков или раздела на vmfs datastore (виртуальный диск). Пользователь сам решает, что ему важнее – надежность или гибкость. Надо понимать, что при выходе из строя даже одного диска, без наличия аппаратного RAID, весь узел кластера (целая VSA) остановится. А если есть RAID, то узел продолжит работать.
при выходе из строя даже одного диска, без наличия аппаратного RAID, весь узел кластера (целая VSA) остановится


Именно это и означает, что аппаратный RAID всё же обязателен :-)

В настоящее время все больше вендоров пробуют выпускать свои вариации на тему SDS. Естественно в каждом решении есть свои нюансы и интересные подходы и технологии.
Интересно бы увидеть более подробные TTX данного решения и рекомендации.
1) Максимальное число узлов в кластере?
2) Максимальный размер блочного тома, отдаваемого гипервизору? И общий максимальный поддерживаемый объем в рамках кластера (полезный или raw)?
3) Какие протоколы используются для того что бы подмапить блочный том гипервизору? Что-то кроме iSCSI поддерживается?
4) Как пробрасывается физический том с RAID контроллера в виртуальную ноду кластера?
5) Есть или нет условно бесплатная версия для тестов без покупки сервера HP?
6) Какая пропускная способность сети требуется\рекомендуется для кластера? Для Multi-site SAN?
7) Как работает тиринг? Вернее даже каким образом определяются блочные тома в конкретные тиры?
8) При помощи чего реализуется "Создание консистентных снэпшотов на уровне приложений"? И какие приложения поддерживаются?
9) Как кластер реагирует на временное исчезновение Quorum Witness виртуалки или шары?
10) Каким образом проводится обновление данного решения? Узлы обновляются поочередно? С перезагрузкой? При перезагрузке ноды на начинается перестроения Network RAID?

1) Рекомендуется до 16 узлов на кластер в StoreVirtual VSA, до 32 узлов на кластер в аппаратных StoreVirtual 3200/4000. Для 1TB/4TB лицензий есть лимит в 3 узла на кластер. Лимит снимается после миграции на лицензию с объемом в 10TB и более.
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 на аппаратную платформу. Коллеги обещали привезти его мне в демо до конца года. Как только получу на руки, то сразу напишу аналогичный обзор.
Пока уступает в цене MSA 1040 на аналогичных конфигурациях.
Очень мало даных по производительности.

По 2-му 128TiB это размер чего? Или это ответ сразу на оба вопроса из второго пункта?


По 9-тому так и не понял как обеспецивается консистентность? В гипервизор ставится програмный агент? Если нет, то не вижу каким способом СХД сообщает OS или гипервизору на сервере о том что сейчас будет сделан снэпшот и нужно синхронизировать все буферы и кэши на диски.

128TiB — это для одного LUN, лимитов для кластера не нахожу.

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.
128TiB — это для одного LUN, лимитов для кластера не нахожу.

Не совсем согласен с вашим ответом.
Как таковых ограничений на размер тома нет. Есть лиценизонное ограние 50Тб на узел, в кластер собирается до 16 узлов, что на входе дает 800 Тб полезной емкости (до объединения в Network RAID).
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 КБ, общее кол-во таких блоков определяется динамически исходя из степени загрузки системы.
«Именно алгоритм резервирования Network RAID 10+1 лежит в основе технологии SplitSite, позволяя создавать кластер на 3х географически разнесенных площадках...» А как себя поведет вся эта красота при падении каналов между датацентрами? Не знаю как в «у вас», а вот у нас падение каналов (или флаппинг, или резко пропавший в «неизвестном» направлении ipsec) происходит значительно чаще чем падение серверов или хранилищ.
Сценарий будет идентичным как и при падении узла. Система перейдет в статус Degrade, начнут сыпаться алерты, но кластер продолжит работу на базе доступного для приложения датацентра.
А если само приложение точно так же кластеризировано и разнесено по ЦОД. Мы ведь получим в результате ситуацию когда везде ничего не будет работать во избежании split-brain'а?
В случае с разнесенным по ЦОДам приложением у нас всегда поулчается схема active-standby. Правильная настройка «Quorum Witness + активный узел кластера приложений» позволит избежать split-brain. Разница с другими аналогичными архитектурами в том, что в отличии от схемы active-standby, у нас не будет переключения на уровне системы хранения.
Sign up to leave a comment.

Articles