Вопросы дизайна СХД для vSphere 5 при использовании Storage DRS

В vSphere 5 представлено огромное количество новых функций, множество из которых еще, увы, не освещено. Хотелось бы рассказать о новых функциях, так, или иначе, касающихся вопросов дизайна СХД – Storage DRS и кластера хранилищ.

Storage DRS – механизм, о котором в своё время ходило много слухов. Является развитием технологии Distributed Resource Scheduling, и позволяет мигрировать файлы виртуальных машин между хранилищами, входящими в один кластер для балансировки нагрузки на СХД. Несмотря на то, что Storage DRS позволяет отслеживать производительность ВМ, не нужно путать эту функцию с Storage IO Control (SIOC). Также интегрируется с VASA (VMware vSphere Aware Storage API), о котором ниже.


Profile Driven Storage – позволяет указывать в параметрах хранилища его характеристики или свойства, создавать на их основе профили, и размещать ВМ соответственно их требованиям к профилям. Что самое приятное у каждого диска, снепшота или даже .vmx файла может быть свой профиль. Кроме того, эта функция способна интегрироваться с VASA – новым API, которое позволяет СХД сообщать гипервизору о своих свойствах (тип RAID, репликация и т.д.).

Главное преимущество этих технологий в том, что они позволяют развернуть ВМ и быть уверенным, что все файлы виртуальной машины размещены на LUN согласно вашим требованиям и дизайну, при этом не настраивая каждую ВМ отдельно.
У меня вышло три схемы, которые бы позволили достичь этой цели.

Схема #1

В этой схеме у нас есть 3 кластера хранилищ, каждому соответствует один профиль. Каждый кластер имеет свой уровень (Tier). Иерархическое управление СХД (HSM) используется для разделения СХД по каким-либо свойствам – чаще всего физическим и, соответственно, производительности. То есть Tier1 – это SSD кэш и SAS диски, тогда как Tier2 уже может быть просто SAS массив, и так далее. При этом Вы можете использовать собственные параметры для создания уровней иерархии.

Главное преимущество этой схемы в том, что каждому кластеру соответствует один профиль, а все хранилища одного типа добавлены в свой кластер. Это очень упрощает размещение виртуальных машин, так как если Storage DRS изменит расположение vmdk внутри кластера, то вы сможете быть уверенными, что файлы ВМ хранятся на соответствующем иерархическом уровне СХД.

Также в такой схеме можно без проблем использовать механизм балансировки нагрузки (I/O load balancing), так как в данном случае подразумевается, что каждый vmdk это отдельное приложение со своими собственными требованиями к производительности, значит, что сообщения о несбалансированности и высоком времени ответа будут вызваны именно загруженностью этого хранилища, а не работой других, более высоконагруженных ВМ.

Некоторые пользователи считают, что использование механизма балансировки нагрузки вызовет рост количества Storage vMotion. И хотя это отчасти правда, механизм балансировки нагрузки будет очень полезен в тех случаях, когда объём свободного пространства в кластере примерно одинаков, так как при миграции также учитывается балансировка и свободного места на дисках, что в данном случае позволит свести к минимуму влияние данного параметра на количество миграций ВМ.
С другой стороны, отчасти под влиянием опасений о влиянии Storage vMotion на дисковую систему, сам механизм Storage vMotion полностью переработан.

Схема #2

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

Когда Storage DRS перемещает виртуальные машины, он берёт в расчёт весь кластер в целом. Проще говоря, если диски с данными ВМ у вас отделены от дисков с ОС и размещены на разных по производительности хранилищах, то SDRS не сможет самостоятельно размещать файлы соответственно вашим требованиям. Вы можете создать набор правил близости (affinity rules), чтобы хранить vmdk файлы на разных хранилищах, но можете столкнуться со сложностями при управлении такой схемой. Также необходимо отметить, что если хранилище выделено для хранения своп файлов ВМ, то оно не учитывается при расчётах SDRS.

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

В итоге такая схема не предоставляет должного уровня гибкости, особенно для больших инфраструктур, в которых возможно использование Storage DRS или отдельных LUN для репликации или резервного копирования.

Схема #3

Эта схема является гибридом первых двух. В одном кластере тут используются высокоуровневые массивы для критичных данных, тогда как во втором кластере дешёвые массивы для некритичных данных – например, своп файлов виртуальных машин или логов.
Так как для первого кластера будет использоваться SDRS, то Вы можете столкнуться с ситуацией, когда ВМ вследствие миграции оказывается не на том уровне СХД или профиль хранилища не будет отвечать профилю ВМ, поэтому я бы рекомендовал задуматься о включении автоматического перемещения между хранилищами в такой схеме. Как вариант решения проблемы – использовать правила близости, но такую схему опять же будет сложно поддерживать при росте количества ВМ. Для второго кластера я бы рекомендовал полностью отключить Storage DRS, чтобы он даже не принимал участие в расчётах балансировки.

Как создать профили?

Создайте Storage Profile и присвойте ему определённые свойства. Важно отметить, что эти свойства должны быть уникальными для каждого профиля, иначе если вы назначите одинаковые свойства двум хранилищам с разными свойства, то вы столкнётесь с коллизией и нарушением ваших правил.

Созданное правило нужно применить к каждому хранилищу в кластере. Учтите, что у каждого хранилища может быть один системный и один пользовательский профиль. К кластеру хранилищ нельзя прикрепить какое-либо свойство, однако если оно свойственно всем хранилищам кластера, оно автоматически станет свойством кластера.

В этом примере только NFS кластер отвечает всем требованиям виртуальной машины.
Проверить соответствие расположение виртуальной машины можно в любой во вкладке Summary виртуальной машины.

 

Оригинал: Greg Mulholland (blog.krystaltek.com)