Storage DRS и частично подключённые массивы

В ситуации с частично подключенными массивами столько всего интересного!

Начнём с определений понятий. Для этого рассмотрим следующую ситуацию: у вас развернут кластер из определённого количества хостов с ESXi и какой-либо внешний дисковый массив.

Некоторые из LUN массива подключены ко всем хостам в кластере, а некоторые нет. Полностью подключёнными массивами/LUNами в терминологии VMware называются именно те, которые подключены ко всем серверам в кластере, а частично подключённые, соответственно, не ко всем. Эта же терминология касается и кластеров хранилищ.

Почему VMware не рекомендует использовать конфигурации с частично подключёнными датасторами?

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

Основное назначение DRS и Storage DRS это обеспечение максимального количества доступных ресурсов, а требованием для этого является мобильность нагрузки между серверами. Именно исходя из этого при создании виртуальной машины DRS и SDRS генерирует рекомендации для изначального расположения ВМ.

Кроме того, если Storage DRS обнаруживает в кластере частично подключенные датасторы вперемешку с полностью подключёнными, то SDRS выключает балансировщик нагрузки (IO load balancing). А балансировщик свободного места, в свою очередь, просто игнорирует такие датасторы при расчётах.

Оригинал: Frank Denneman

Top 25 VMware blogs

Портал vSphere Land открыл очередной раунд голосования, чтобы определить 25 лучших блогов о виртуализации VMware.

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

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

И немного информации о самом голосовании:

• Вы можете выбрать 10 ваших любимых блогов и сделать свою собственную горячую десятку. Блог #1 получит 10 очков, блог #10 - 1 очко. В конце будут подсчитаны общие результаты и блоги получат соответствующие места в итоговом списке Top25.
• Если Вы не знаете блоггеров, то можете руководствоваться vLaunchpad для ознакомления с блогами и оценки.

Ну и, конечно, голосуйте за меня :)) В списке представлен как "Virtual Admin Notes (Anton Zhbankov)"

Обработка отказа СХД в vSphere 5

К сожалению, бывают случаи, когда vSphere теряет доступ к системе хранения данных по той или иной причине. В vSphere 4 отказ доступа к СХД мог привести к непредсказуемому результату: от немедленного BSoD у высоконагруженных ВМ до нормальной работы у простаивающих серверов за счёт работы с локальным кэшем. В vSphere 5 обработка отказов СХД была существенно переработана и улучшена.
vSphere 5 теперь различает два состояния отказа LUN: отказ всех путей (APD – All Paths Down) и перманентный отказ устройства (PDL – Permanent Device Lost). Разница между APD и PDL видна в названии – в первом случае система временно не имеет доступа к LUN (например, вышел из строя свитч к СХД), тогда как во втором случае LUN был удалён из СХД.

С технической стороны разница состоит в SCSI кодах, получаемых vmkernel при попытке обращения к LUN. Детальное описание всех кодов и сообщений в логах доступно в этой статье VMware KB.

Данные о APD/PDL никак не передаются виртуальной машине, и обрабатываются на уровне гипервизора, так что если в случае APD/PDL не записанные из-за истечения тайм-аута данные будут сброшены, виртуальная машина попытается снова записать их на диск.
Гипервизор же в случае отказа всех путей к LUN будет хранить данные в кэше vmkernel вплоть до восстановления доступа к устройству, тогда как в случае с перманентным отказом устройства данные даже не будут кэшироваться, чтобы избежать ситуаций с переполнением буфера процесса hostd, что приводило к неотзывчивости системы в vSphere 4.

Нюанс обработки удаления LUN в некоторых СХД

Некоторые низкоуровневые СХД не поддерживают технологию multi LUN, и используют схему 1 LUN – 1 таргет. Если такой LUN удалить из СХД, то при обращении в ответ не будут высланы соответствующие SCSI коды и vSphere не сможет понять, что LUN удалён навсегда (PDL), а будет считать, что это временный отказ путей к хранилищу (APD).