August 2013 – vMind.ru

EMC VNX2

Наш блог уделяет внимание не только виртуализации, но и её фундаменту – аппаратной инфраструктуре.

Сегодня мне в руки попала презентация линейки второго поколения систем хранения среднего уровня EMC VNX: VNX5400, VNX5600, VNX5800, VNX7600, VNX8000.

Что нового в EMC VNX второго поколения:

Процессор Intel Sandy Bridge.
Шина передаче данных PCIe Gen 3 позволяет обеспечивать ввод-вывод через интерфейсы 40GbE и 16Gb FC.
Многоядреная оптимизация (MCx) используется в реализации функций RAID, Cache и FAST Cache.
Больше ядер, памяти, дисков и ёмкость FAST Cache.
1 миллион IOPS при операция чтениях размером 8k.
Поддержка недорогих eMLC Flash дисков на 100, 200, 400 ГБ.
Блочная дедупликация LUNs в базовой поставке.
Адаптивное управление кэшем(Cache) с общим пулом на запись и чтение.
Увеличена производительность FAST Cache и уменьшено время “разогрева”.
Active/Active доступ к LUN.
FAST VP использует сегмент размером 256МБ, что в 4 раза меньше первого поколения.
Автоматическое назначение дисков горячей замены(даже если вы их не назначали) и возможность переноса дисков.
VNX Monitoring and Reporting включен в базовую поставку.
Автоматическая онлайн миграция файловых систем с Celerra и VNX.
Диски и полки расширения от VNX можно использовать, а вот данные при этом сохранить нет.

Скачать презентацию, ссылка доступна на момент публикации ;).

Обзорная статья от Jason Nash “Introducing the Next Generation VNX Arrays from EMC“, ссылка доступна на момент публикации 😉 .

Поубавить восторгов. Русская версия статьи в блоге Романа Хмелевского.

P.S. Анонс новой системы в сентябре 2013. Часть программного функционала будет доступна в течении нескольких фаз (этапов), аппаратные возможности также будут некоторое время дополняться. Анонс систем хранения начального уровня EMC VNXe второго поколения будет в первом квартале 2014 года.

Перенос Custom Attributes между VMware vCenter

У меня возникла задача переехать в новый vCenter. При планировании работ обратил внимание на потребность переноса полей виртуальных машин Custom Attributes, созданных мной.

В моей инфраструктуре используется два дополнительных поля – Administrator, где указываются основной и дублирующий администратор, поле – Nagios, где указывается имя, под которым сервер занесен в систему мониторинга. Данное поле позволяет осуществлять контроль все ли продуктивные виртуальные машины занесены в Nagios.

В отличии от Notes, созданный вручную Custom Attribute хранится в vCenter и при переходе на чистую базу данных не сохраняется.

Поиск быстро выдал пример скрипта на PowerShell для экспорта-импорта данных полей.

Приведу кусочек кода, немного исправленный и используемый мной.

Экспорт (обратите внимание на указание кодировки для атрибутов на кириллице):

$vmlist = get-vm 
$Report =@()
 foreach ($vm in $vmlist) {
 $row = "" | Select Name, Notes, Key, Value, Key1, Value1
 $row.name = $vm.Name
 $row.Notes = $vm | select -ExpandProperty Notes
 $customattribs = $vm | select -ExpandProperty CustomFields
 $row.Key = $customattribs[0].Key
 $row.Value = $customattribs[0].value
 $row.Key1 = $customattribs[1].Key
 $row.Value1 = $customattribs[1].value
 $Report += $row
 }

$report | Export-Csv "c:\temp\vms-with-notes-and-attributes.csv" -NoTypeInformation -encoding unicode

$vmlist = get-vm

$Report =@()

foreach ($vm in $vmlist) {

$row = "" | Select Name, Notes, Key, Value, Key1, Value1

$row.name = $vm.Name

$row.Notes = $vm | select -ExpandProperty Notes

$customattribs = $vm | select -ExpandProperty CustomFields

$row.Key = $customattribs[0].Key

$row.Value = $customattribs[0].value

$row.Key1 = $customattribs[1].Key

$row.Value1 = $customattribs[1].value

$Report += $row

}

$report | Export-Csv "c:\temp\vms-with-notes-and-attributes.csv" -NoTypeInformation -encoding unicode

Импорт:

 $NewAttribs = Import-Csv "C:\temp\vms-with-notes-and-attributes.csv"

 foreach ($line in $NewAttribs) {
 set-vm -vm $line.Name -Description $line.Notes -Confirm:$false
 Set-CustomField -Entity (get-vm $line.Name) -Name $line.Key -Value $line.Value -confirm:$false
 Set-CustomField -Entity (get-vm $line.Name) -Name $line.Key1 -Value $line.Value1 -confirm:$false
 }

$NewAttribs = Import-Csv "C:\temp\vms-with-notes-and-attributes.csv"

foreach ($line in $NewAttribs) {

set-vm -vm $line.Name -Description $line.Notes -Confirm:$false

Set-CustomField -Entity (get-vm $line.Name) -Name $line.Key -Value $line.Value -confirm:$false

Set-CustomField -Entity (get-vm $line.Name) -Name $line.Key1 -Value $line.Value1 -confirm:$false

}

Active Directory vs vSphere 5.1

В процессе использования vSphere 5.1 столкнулся с несколькими нюансами работы платформы с Active Directory.

vSphere 5.1 SSO и домены с доверительными отношениями.

Эпически глючная вещь в vSphere 5.1 – это сильно распиаренный Single Sign-On. На нашем предприятии развернут лес с двумя поддоменами, где “живут” учётные записи пользователей, которым требуется доступ к виртуальной инфраструктуре. Очень интересно ведёт себя SSO при недоступности доменных контроллеров доверенных доменов – он просто не даёт авторизовать в других. У меня проблемы две – временная недоступность из-за сетевой недоступности и некорректная настройка DNS.

При восстановлении сетевой доступности SSO не слишком торопится достучаться до контроллеров домена, обычно, приходится авторизоваться под учётной записью admin@system-domain и делать шаманские пляски с перепроверкой identity source.

Вторая проблема возникает при попытке заменить адреса доменных контроллеров на имя домена, то есть вместо dc-01.perm.contoso.com писать perm.contoso.com, так как фактически DNS на запрос perm.contoso.com возвращает NS-серверы, а не доменные контроллеры. В моём случае, запрос по имени доверенного домена возвращает по одному из 4 адресов не контроллер домена. Ну, это местечковые грабли. Для решения проблемы прописал “наиболее доступные” контроллеры домена.

vCenter и объекты безопасности Active Directory.

Второе “волшебное” поведение платформы – это группы и пользователи AD с назначенными разрешениями к объектам vCenter. Вы назначаете группе или учётной записи доступ к виртуальной машине, а спустя некоторое время решает привести названия групп к новому стандарту наименования. Результат впечатляет – все переименованные группы и учётные записи бесследно исчезают из разрешений. Но, как говорится, это by design.

Примечание. При создании локальной доменной группы (domain local) безопасности, добавлении в неё учётной записи из доверенного домена и назначении прав в vCenter получил негативный результат – доступ не был предоставлен. Возможно, где-то я скосячил, а может и не я.