Данный инструмент сравнивает текущие настройки операционной системы и системы резервного копирования и восстановления данных с рекомендованными.
Типичная картина до закручивания настроек безопасности может выглядеть так:

Подробное описание всех проверок, включая ключи реестра, можно прочитать в статье Security & Compliance Analyzer.

Для игнорирования проверки жмёте “Suppress”, а вот если хотите исправить, то идёте в статью базы знаний “Script to Automate Implementation of Security & Compliance Analyzer Recommendations” где размещен powershell-скрипт исправляющий часть настроек. Сначала заново валидируете конфигурацию, а потом выбираете исправления, которые вас устраивают:

Я люблю гибкость, которую дает мне виртуализация VMware vSphere. Временами это может причинять неудобства. При записи подкаста с Greg Stuart мы пришли к выводу, что практически нет одинаковых виртуальных окружений.

Таким образом мы пришли к вопросу: как виртуальные среды могут так различаться? Что было сделано правильно, а что – нет? Я предлагаю вам свой список настроек, которыми нельзя пренебрегать.

1) Используйте DNS с умом

У меня есть популярная запись в блоге – настройка Hyper-V после установки. Совет №1 – правильно настройте DNS. Применительно к vSphere это означает не используйте host-файлы. Это может работать, но vSphere 5.1 использует запросы к DNS-серверу для получения статуса.

2) Не соединяйте все сети вместе

Это совет к использованию большего (чем один) количества виртуальных коммутаторов. Вы можете совмещать виртуальные сети различного назначения в тестовых целях, но на продуктивных серверах я рекомендую разносить виртуальные сети и адаптеры vmkernel по различным виртуальным коммутаторам (и различным физическим адаптерам сервера). Это может быть как разделение с помощью VLAN, так и использование отдельных интерфейсов vmkernel для различных нужд гипервизора.

Ниже пример, как делать не стоит

Заодно еще совет – не используйте виртуальный коммутатор с единственным аплинком.

3) Не забывайте про обновление хостов, версии виртуального железа и VMware Tools

vSphere предоставляет вам отличный инструмент для обновления всех трех компонентов – VMware Update Manager. С его помощью вы можете без проблем обновить вашу инфраструктуру с версии 4.1 до 5.1. Есть “старые” виртуальные машины с 4й версией виртуального железа? Вы легко обновите их с выключением и обновлением VMware Tools.

4) Не усложняйте конфигурацию DRS

Если вы один раз сделали это, больше вряд ли станете. Бесполезные настройки планировщика DRS могут снизить производительность, особенно, если вы станете развлекаться со значениями относительных приоритетов (shares) виртуальных машин и пулов ресурсов. Не делайте этого.

5) Не забывайте удалять старые настройки для СХД в vmkernel

Пример старых настроек на скриншоте

А что на ваш взгляд не стоит делать в виртуальной среде VMware vSphere?

• Achieving a Million I/O Operations per Second from a Single VMware vSphere 5.0 Host
• VMware vCenter Update Manager 5.0 Performance and Best Practices
• Performance Implications of Storage I/O Control–Enabled NFS Datastores in VMware vSphere 5.0
• Understanding Memory Management in VMware vSphere 5
• Host Power Management in VMware vSphere 5
• Microsoft Exchange Server 2010 Performance on vSphere 5
• Zimbra Collaboration Server Performance on VMware vSphere 5
• vMotion Architecture, Performance, and Best Practices in VMware vSphere 5
• Command-Line Installation and Upgrade of vCenter Server 5.0
• Legacy Host Licensing with vCenter Server 5.0
• Performance Best Practices for VMware vSphere 5.0

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

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

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

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

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

Для серверов 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 был возможен.

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

В этом примере каждый 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, автор Волнянский Виталий

Собственно, прошивка вышла, а также появились свежие практики по работе с этой СХД.

Основные рекомендации с прошлой прошивки не изменились, разве что отводится большее внимание отслеживанию свободного места на диск-группе.

Также очень порадовал раздел “Best practice folklore, urban legends, myths, and old best practices”

UPD: также появился документ о Thin Provisioning.

Написано монументально, к прочтению рекомендуется.

За ссылку спасибо romx, прямой линк на файл.

Кстати, рекомендую ознакомиться с блогом romx’а, достаточно интересные вещи про СХД пишет.

1. Aidan Finn выложил презентацию “Что нового в Hyper-V R2 и VMM R2”. В ней встречайте – исправленные максимумы, а также несколько слайдов про улучшенные механизмы работы;
2. Chaffie McKenna выдает пятерку лучших советов по планированию/настройке Hyper-V R2. Среди них подбор количества физических сетевых адаптеров хоста.
3. В комментариях к статье Hyper-V – наш выбор? Mr Nobody ссылается на класснейшую сборку ссылок по производительности Hyper-V R2.
4. Тут пишут про бесплатную утилиту для мониторинга за Hyper-V.

VMware проанализировало множество внедренных серверов SQL и выяснило следующие закономерности:
– SQL сервер обычно запущен на двух физических ядрах;
– Средняя загрузка процессора меньше 6%, 85% SQL серверов используют менее 10% процессора, 95% используют менее 30%;
– В среднем, на сервер установлено 3,1 гигабайта оперативной памяти, используется 60%;
– Среднее количество операций ввода/вывода – 20 IOPS, у 95%процентов серверов – меньше 100 IOPS;
– Средний сетевой трафик составляет3.2Мбит/сек.

Так что виртуализовать SQL очень даже имеет смысл!

Также в документе очень интересная таблица по поводу восстановления работоспособности сервиса после сбоя.

Failover clustering – не меньше 30 секунд;

Database Mirroring – меньше 3 секунд;

Log Shipping – время не указывается.

Replication – время не указывается.

Достаточно хорошим выбором является Database Mirroring. Быстрее восстановление, чем у кластера, стоит меньше (отсутствует необходимость в общем сторадже). Естественно, что балансировки нагрузки ни при кластеризации, ни при зеркалировании баз данных не происходит. Для балансировки Log Shipping и Replication выглядят лучше, но у них гораздо большее время при восстановлении и возможна потеря данных.

Есть над чем подумать…