Рекомендации по настройке СХД Hitachi серии AMS 2000

Эта заметка будет посвящена ключевым рекомендациям по настройке и подключению СХД серии AMS 2000 от компании Hitachi Data Systems, в которую входят AMS2100, AMS 2300 и AMS2500. Многие из этих рекомендаций общие для всех СХД, многие уже известны, а некоторые относятся только к AMS.

Конфигурация СХД

На картинке ниже нарисована схема СХД, применительно к которой и будут описаны рекомендации.

А далее я опишу ключевые моменты обеспечения

 

Избыточность:

Избыточность в инфраструктуре хранения требуется для поддержания высокой доступности, масштабируемости и производительности. Причем масштабируемость требуется на каждом уровне сети хранения данных.

Для серверов ESX(i) – это избыточные HBA. Это позволит использовать встроенную поддержку multipathing, а так же предоставит защиту от аппаратных сбоев в HBA или проблем на Fibre Channel линках.

Избыточность Fabric тоже важна, так как сбой на единственном Fibre Channel коммутаторе вызовет ошибки на всех виртуальных машинах, подключенных к хранилищу через этот Fabric коммутатор.

Без избыточности в каждом компоненте, все виртуальные машины могут стать “жертвой” одной точки отказа.

В AMS 2000 series на СХД избыточность достигается двумя контроллерами доступа к LU с количеством FC портов от 2 до 8 на каждом контроллере. Для использования преимуществ такой конфигурации, каждый контроллер нужно подключать в двум или более FC коммутаторам. такой подход защитит от сбоев в FC линках, коммутаторах и контроллерах AMS.

Рекомендация: Подключайте не менее 2 Fibre Channel портов на каждом контроллере в разные FC коммутаторы, по 1 порту с каждой платы расширения Fibre Channel на контроллере

Если AMS 2000 подключены таким образом к ESX(i) хостам, то рекомендуется включить Round Robin алгоритм выбора пути на ESX(i) серверах, чтобы использовать все преимущества Symmetric Logical Unit Access контроллеров на СХД.

Зонирование

Это общая тема для всех СХД, я освещу только самые ключевые моменты.

Зонирование позволяет разделить FC фабрику на несколько логических частей для повышения безопасности и изоляции данных. Неправильное зонирование может вызвать ошибки презентования LU для хостов ESX, нестабильные пути и другие проблемы. Существует два типа зонирования и у каждого свои недостатки и преимущества:

По портам – использует указанные физические порты на FC коммутаторе. Зонирование по портам предоставляет большую защищенность и простоту при поиске неисправностей. Это может быть преимуществом в небольших статических инфраструктурах. Недостаток такого подхода в том, что HBA с ESX хоста всегда должны быть подключены к указанным портам, а переключение линка вызовет потерю соединения и потребует перезонирования.

По WWN – использует сервера имен на коммутаторах для привязки WWN HBA адаптера к WWN целевого порта. Преимущества такого подхода в том, что переключение физических линков от ESX HBA на коммутаторах не потребует перезонирования и, в динамических инфраструктурах, такой подход предоставляет большую гибкость. Недостатком подходя является меньшая защищенность и повышенная сложность при поиске неисправностей.

Зоны могут быть созданы любым из двух путей:

Multiple initiator (множественные инициаторы) – Несколько инициаторов (HBA) расположены в одной зоне с одной или несколькими целями. Такую конфигурацию легче создавать и она облегчает административную нагрузку, но может вызвать некоторую интерференцию потоков данных.

Single initiator (один инициатор) – Один инициатор (HBA) и одна или несколько целей расположены в одной зоне. Это исключает интерференцию, но требует создания зон для каждого инициатора (HBA).

При зонировании необходимо учесть все пути, доступные целям, чтобы multipathing был возможен.

Пример зонирования:

 

Хост	Номер HBA на хосте	Название зоны	Порт на СХД
ESX 1	HBA 1 Port 1	ESX1_HBA1_1_AMS2K_0A_1A	OA 1A
ESX 1	HBA 2 Port 1	ESX1_HВA2_1_AMS2K_0E_1E	OE 1E

В этом примере каждый ESX хост имеет 2 однопортовых HBA. Каждый HBA зонирован к 1 порту на каждом контроллере, с 1 инициатором и двумя целями в зоне. В результате каждый HBA порт имеет два пути и 1 зону. Имея 2 HBA каждый хост получает 4 пути и 2 зоны.

Настройка HOST GROUP

Настройка Host Groups, а далее групп хостов, на Hitachi AMS 2000 позволяет указать какие HBA или группы HBA могут подключаться к LU через определённые порты на контроллерах.

Одна группа хостов на каждые сервер ESX, настройка изолированных хостов

Если хосты ESX работают в изолированном режиме, то есть вне кластера, то WWN каждого хоста может располагаться в собственной хост группе. Это рекомендованная настройка для инфраструктур с реализованной SAN Boot, так как сервера ESX не имеют доступа в загрузочным LU других серверов. Но такой подход может представлять собой административную головную боль, так как при большом количестве серверов LU c VMFS придется добавлять в каждую группу хостов, что может привести к ошибке из-за человеческого фактора.

Одна группа хостов на кластер, настройка хостов в кластере

Так как многие из возможностей vSphere требуют общее хранилище, такие как vMotion, DRS, HA, FT и Storage vMotion, то LU с виртуальным хранилищем должен быть презентован на все сервера ESX, участвующие в данных операциях.

Рекомендация: WWN всех серверов ESX нужно размещать в одной группе хостов на AMS

Опции групп хостов – Host Group Options

Группы хостов на семействе AMS 2000 создаются через Hitachi Storage Navigator Modular 2 (HSNM2). В модуле Available Ports, необходимо выбрать порты для которых применится конфигурация. Из списка Platform необходимо выбрать VMware, а из списка Common Setting, выбрать Standard Mode. В модуле Additional Settings нужно снять галки во всех позиций. Эти настройки автоматически применят правильную конфигурацию для серверов ESX.

 

Hitachi Dynamic Provisioning Software

Что такое Dynamic Provisioning (DP) можно почитать в маркетинговых материалах. А в этой главе я укажу ключевые моменты использования Dynamic Provisioning для платформы VMware. Итак, начнем!

Эффективное использование дискового пространства с Dynamic Provisioning и типы виртуальных дисков

Я буду использовать формулировку thin-дружелюбность и её производные в этой части статьи. В оригинале эта формулировка выглядит “thin-friendly”. Thin-дружелюбность подразумевает под собой, что виртуальные диски отнимают чанки из пула Dynamic Provisioning только по мере необходимости. Два формата виртуальных диском vmware являются thin-дружелюбными: Thin и thick (он же zeroedthick). Диски формата Eagerzeroedthick занимают в DP пуле 100% своего пространства и не позволят сэкономить дисковое пространство, но они тем не менее могут быть полезны, так как позволят использовать wide-stripe и “размазать” виртуальную машину по всем дискам в DP пуле сразу.

Основные практики использования DP-томов для overprovisioning (ВМ занимает все выделенное ей место сразу):

Создавайте шаблоны ВМ в zeroedthick формате, если ваша vSphere не поддерживает VAAI. Для vSphere с поддержкой VAAI создавайте шаблоны в формате eagerzeroedthick. При создании ВМ из шаблона выбирайте: Использовать формат как у источника (Same format as source)

• Используйте eagerzeroedthick для сред с VAAI
• Используйте zeroedthick для сред без VAAI
• Storage vMotion операция по перемещению ВМ с Dynamic Provisioning LU – это thin-дружелюбная операция.

Примечание: Перемещение ВМ с одного хранилища на другое не освобождает место на DP пуле.* Для этого нужно запустить процесс оптимизации пула на СХД вручную.

*Примечание 2: В vSphere5 новая VAAI команда UNMAP позволяет освобождать место в DP пуле при Storage vMotion. Но firmware СХД должна поддерживать эту команду.

Виртуальные диски и производительность Dynamic Provisioning

Для достижения максимальной производительности СХД в vSphere4 следуйте следующим рекомендациям:

Используйте eagerzeroedthick для избавления от задержки для обнуления блоков при первой записи. Для загрузочных томов ВМ можно использовать zeroedthick, так как там не требуется максимальная производительность.

Используйте не менее 4 RAID групп в Dynamic Provisioning пуле для достижения максимальной эффективности wide-страйпинга.

Если нет возможности создавать большие DP пулы, то стоит разделять случайные и последовательные нагрузки на разные DP пулы

Для приложений, использующих log recovery, нужно отделить логи от базы данных и расположить их на разных DP пулах. Это разделяет последовательные и рандомные нагрузки и позволяет повысить защищенность данных от возможных аппаратных сбоев.

Виртуальные диски на стандартных LU

Диски форматов zeroedthick и eagerzeroedthick имеют одинаковую производительность на стандартных LU после предварительной разметки. Но zeroedthick диски показывают чуть большую задержку во времени доступа и меньшую скорость так как разметка блока происходит в момент первого доступа к нему.При выборе zeroedthick или eagerzeroedthick дисков руководствуйтесь следующими пунктами:

Для использования vSphere Fault Tolerance нужно использовать eagerzeroedthick диски.

Если нужно сократить время создания виртуальных дисков, то используйте zeroedthick диски.

Если необходима максимальная изначальная производительность записи, то используйте eagerzeroedthick диски.

 

Распределение I/O нагрузки

Hitachi Dynamic Provisioning Software может балансировать I/O нагрузку между пулами  рейд-групп. Для vSphere 4 это можно считать зачатком Storage DRS, так как он не перемещает диски между пулами хранилищ, а только распределяет нагрузку по всем рейд-группам в пуле.

Вот так выглядит типичная картина DP-томов:

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

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

При использовании же Hitachi Dynamic Provisioning нет нужды отслеживать производительность индивидуальных RAID групп, так как этим занимается сама СХД и равномерно распределяет нагрузку по всем дискам в пуле. И тогда картинка будет выглядеть вот так:

Рекомендация: Максимальной эффективности от балансировки нагрузки виртуальных машин можно добиться при одновременном использовании Hitachi Dynamic Provisioning, round robin multipathing и VMware DRS.

vStorage API for Array Integration (VAAI)

В этой главе я опишу рекомендации по использованию VAAI с СХД AMS2000 и чего это позволит добиться. Про преимущества использования VAAI с AMS 2000 в vSphere 4.1 можете почитать в этом документе. А здесь я опишу что такое VAAI и рекомендации по его применению.

Аппаратное ускорение типовых операций vSphere с виртуальными хранилищами

В vSphere 4.1 было всего 3 команды VAAI:

Full Copy / Clone Blocks / XCOPY – функция, позволяющая передать на сторону массива возможности копирования объектов виртуальной инфраструктуры без задействования операций четния-записи со стороны сервера VMware ESX 4.1. Эту функцию также называют Hardware Offloaded Copy и SAN Data Copy Offloading.

Write Same / Zero Blocks – возможность обнуления больших массивов блоков на дисковых устройствах для быстрого создания дисков vmdk типа eager zero thick.

Atomic Test and Set (ATS) –возможность защиты метаданных тома VMFS как кластерной файловой системы в ситуациях, когда большое количество хостов ESX имеют разделяемый доступ к одному хранилищу. Также эта функция называется Hardware Assisted Locking.

Описание этих команд я взял из блога vmgu.ru, так как не вижу смысла переводить их самостоятельно. ЧТо они дают вы так же можете почитать в этой статье.

В vSphere 5 количество команд VAAI было расширено, но так как у меня нет vSphere 5, то я не могу провести какое-либо тестирование, а  Hitachi еще не опубликовало никаких подробных документов на эту тему. Так что я опишу здесь рекомендации для vSphere 4.1.

Итак, чтобы воспользоваться всеми преимуществами VAAI то придерживайтесь следующих рекомендаций:

• Целевое и исходное виртуальные хранилища должны иметь одинаковый размер блока.
• При клонировании RDM диска целевой диск тоже должен быть RDM.
• При клонировании убедитесь, что диски не sparse и не hosted типов.
• При клонировании ВМ у неё не должно быть снапшотов.
• Исходный и целевой тома VMFS должны находиться на одной СХД

Аппаратное ускорение Thin Provisioning

При использовании Hitachi Dynamic Provisioning с VAAI позволяет превратить eagerzeroedthick в thin диски на уровне СХД. В табличке ниже вы увидите результаты Provisioning операций для дисков разного типа.

Тип виртуального диска	Стандартные RAID группы	Dynamic Provisioning том без VAAI	Dynamic Provisioning том с VAAI
Thin	Thin Provisioned	Thin Provisioned	Thin Provisioned
Zeroedthick	Thick Provisioned	Thin Provisioned	Thin Provisioned
Eagerzeroedthick	Thick Provisioned	Thick Provisioned	Thin Provisioned

Как видите еagerzeroedthick диски на DP томах с VAAI и без получаются разного типа. А создание дисков любого типа на DP томе с VAAI создает thin диск на СХД. При этом еagerzeroedthick не требуется обнуление блока при первом доступе точно так же, как и на стандартных RAID группах и он сразу же предоставляет максимальную производительность записи.

Примечание: При конвертации Thin или Zeroedthick в формат Eagerzeroedthick в итоге получается Thick Provisioned диск. Для того чтобы снова сделать его thin на СХД нужно запустить zero page reclaim.

Включение VAAI на AMS2000

Чтобы использовать VAAI в вашей среде нужно, чтобы она удовлетворяла следующим условиям:

• Версия ESX не ниже 4.1
• СХД Hitachi AMS 2000 должна использовать firmware не ниже версии 0890/B
• Hitachi Storage Navigator Modular должен быть не ниже версии 9.03

Так же в дополнение к стандартным настройкам HOST GROUPS необходимо дополнительно включить следующие параметры:

1. Enable Unique Extended COPY Mode
2. Enable Unique Write Same Mode

Примечание: hardware assisted locking не требует дополнительного включения в настройках, он активен всегда, если ваша среда позволяет его применять.

Масштабируемость

Тут не существует единого правила, так что я лишь укажу общие моменты которые стоит учесть при планировании инфраструктуры:

• Размер LU
• Количество ВМ на 1 LU
• Приемлемый уровень производительности
• Размер виртуальных дисков
• Количество виртуальных дисков на 1 ВМ
• Тип нагрузки (последовательная, случайная запись/чтение)
• Тип физических дисков
• Размер физических дисков
• Тип RAID групп
• Конфигурация RAID групп

При проектировании вашей среды vSphere можете воспользоваться следующими рекомендациями:

• Ориентируйтесь сначала на производительность, только потом на объем. Количество дисков для достижения необходимой производительности может быть больше, чем для ёмкости. При использовании Hitachi Dynamic Provisioning добавление RAID групп в пул позволит увеличить и емкость и производительность одновременно. Добавление в DP пул происходит без прерывания работы.
• Учитывайте I/O требования приложений и старайтесь не превысить возможности RAID группы. Или используйте Hitachi Dynamic Provisioning для того чтобы минимизировать административную нагрузку.
• Распределяйте разные типы I/O нагрузки между разными RAID группами, а так же распределяйте I/O нагрузки между RAID группами равномерно

Выравнивание дисков и размер RAID Stripe

Для достижения оптимальной производительности СХД необходимо правильно выровнять систему и диски, чтобы избежать дополнительных операций I/O. По-умолчанию AMS 2000 использует размер страйпа 256Кб, а VMFS3 использует размер блока 128К. Их необходимо выравнивать по границе в 128Кб.

Убедитесь, что VMFS том правильно выровнен набрав команду:

fdisk -lu

Выделенное красным поле и значение 128 означает, что VMFS выровнен правильно. Если это не так, то почитайте эту инструкцию.

Так же необходимо правильно выравнивать диски виртуальных машин. Для выравнивания дисков в Windows смотрите этот гайд. Windows 2008 все новые диски по-умолчанию создаются правильно выровненными.

Настройки хостов ESX

Эта часть моей статьи будет самой короткой. Я не стану вдаваться в подробности и описание настроек, а лишь укажу те, который следует проверить или изменить:

• Multipathing: используйте round robin.
• Queue Depth: 32 для SAS дисков и 16 для SATA.
• Disk.SchedNumReqOutstanding: используйте значение 32 даже для SATA дисков.
• VMkernel Advanced Disk Parameters: используйте параметры по-умолчанию.

Заключение

На этом завершается моя статья. Прошу учесть, что большинство практик из этого документа применимы к vSphere 4.1. Я обновлю эту статью с учётом vSphere 5, как только она будет доступна конечным пользователям и у меня будет время провести тестирование всех пунктов заново.

---

Запись первоначально опубликована в блоге volnyanskiy.ru, автор Волнянский Виталий