Как сделать Linux FC-target из компа, кучи SATA-дисков и FC-карты QLogic?

Что это нам дает:

1. Возможность дешево получить дисковое место, подключаемое по Fibre Channel (вы возможно слышали о тормозах из-за latency при работе по iscsi?)
2. Полное управление возможностями без дополнительных лицензий (опять же, возможно, слышали о Flashcache?)
3. Полный контроль над ошибками и сбоями (а знали ли что mdadm умеет сам проверять состояние рейда и присылать письма в электронку если какой-то диск поломался?)
4. Возможность подкрутить параметры и получить быстрый ребилд и лишние проценты производительности (Write-intent bitmap или stripe_cache_size?)

Что нам потребуется:

1. Компьютер с PCIe 4,8 или 16х, желательно более 4ГБ ОЗУ и процессор новее, чем 2007 года выпуска (все же Gentoo будет компилировать свои кусочки).
2. Карточка FC фирмы QLogic: 2400/2500/2600/8100/8300 (якобы с другими не работает, но я запускал на 2432. Список совместимых – http://linux-iscsi.org/wiki/Fibre_Channel#Hardware_support).
3. Кроме дисков в RAID, нужен будет ещё диск под систему, все попытки запускать backstore на файлах заканчивались у меня зависаниями.

Первым делом необходимо установить ОС (в моем случае Gentoo, но технически можно любую – пропадет удобство сборки и обновления – из RPM/YUM не работает). Тут все банально, следует лишь учесть что ядро стоит брать самое новое (например, ловил глюки в TCM на версии 3.8.х которых не стало при переходе на 3.9-rc), а само ПО управления из GIT.

После установки нужно сконфигурировать ядро для поддержки Generic Target Core Mod (TCM). Я брал sys-kernel/Gentoo-sources версии 3.9.4 и настраивал следующим образом(Device Drivers / Generic Target Core Mod (TCM) and ConfigFS Infrastructure):
Если у вас меньше строчек в этой меню – вы что-то забыли активировать.

Наиболее вероятно, что нет строки TCM_FC и не активирован драйвер HBA QLogic – (что приводит к невозможности работы с FC и ошибкам при настройке) искать это тут (Device Drivers / SCSI device support / SCSI low-level drivers):

Собственно на этом с ядром все, собираем и перезагружаемся в него (genkernel all&&reboot).

После этого в файле /etc/modprobe.d/qla2xxx.conf необходимо указать что адаптер не должен инициализироваться в режиме инициатора:

options qla2xxx qlini_mode="disabled"

далее устанавливаем саму программу управления:

emerge -av sys-block/targetcli

RAID-массив у меня уже есть, нужно только к нему приделать bitmap:

# cat /proc/mdstat
md127 : active raid5 sde2[2] sdb2[0] sdc2[1] sdd2[3]
5860222464 blocks level 5, 256k chunk, algorithm 2 [4/4] [UUUU]
mdadm -G /dev/md127 -b /md127_intent

и видим что все получилось:

# cat /proc/mdstat
md127 : active raid5 sde2[2] sdb2[0] sdc2[1] sdd2[3]
5860222464 blocks level 5, 256k chunk, algorithm 2 [4/4] [UUUU]
bitmap: 466/466 pages [1864KB], 2048KB chunk, file: /md127_intent

добавим в автозапуск настройки (файл /etc/local.d/settings.start):

/sbin/mdadm --monitor --mail=ven@с***y.ru --daemonise /dev/md127
/usr/bin/setterm -powersave off -blank 0
sysctl -w dev.raid.speed_limit_min=500000
echo "2000000" > /sys/block/md127/md/sync_speed_max
blockdev --setra 16384 /dev/md127
echo 16384 > /sys/block/md127/md/stripe_cache_size

готово, теперь у нас отличный набор безумно дешевых SATA-дисков доступен, как RAID5, но пока только изнутри системы.

запускаем ПО:

# targetcli

видим что инициализация прошла успешно (выделил болдом самое важное место):

Warning: Could not load preferences file /root/.targetcli/prefs.bin.
targetcli GIT_VERSION (rtslib GIT_VERSION)
Copyright (c) 2011 by RisingTide Systems LLC.
All rights reserved.
Loaded tcm_fc kernel module.
Created '/sys/kernel/config/target/fc'.
<strong>Loaded tcm_qla2xxx kernel module. </strong>Created '/sys/kernel/config/target/qla2xxx'.
Loaded tcm_loop kernel module.
Created '/sys/kernel/config/target/loopback'.
Loaded iscsi_target_mod kernel module.
Created '/sys/kernel/config/target/iscsi'.

Отлично, давайте настроим карту:

qla2xxx/ info
Fabric module name: qla2xxx
ConfigFS path: /sys/kernel/config/target/qla2xxx
Allowed WWNs list (free type): <strong>21:00:00:e0:8b:94:2b:98 </strong>Fabric module specfile: /var/target/fabric/qla2xxx.spec
Fabric module features: acls
Corresponding kernel module: tcm_qla2xxx

С другим WWN карта создать вам не даст, это не Ethernet:

qla2xxx/ create 21:00:00:e0:8b:94:2b:98
Created target 21:00:00:e0:8b:94:2b:98.

Создаем хранилище:

backstores/iblock create sata-r5 /dev/md127
Generating a wwn serial.
Created iblock storage object sata-r5 using /dev/md127

Создаем LUN0:

/qla2xxx/21:00:00:e0:8b:94:2b:98/luns create /backstores/iblock/sata-r5
Selected LUN 0.
Successfully created LUN 0.

Добавляем доступ с инициаторов (не забудьте прописать зоны в FC-свитчах!):

/qla2xxx/21:00:00:e0:8b:94:2b:98/acls create 21:00:00:1b:32:1f:76:a0
Successfully created Node ACL for 21:00:00:1b:32:1f:76:a0
Created mapped LUN 0.

Смотрим, что получилось:

ls
o- / ......................................................................................................................... [...]
o- backstores .............................................................................................................. [...]
| o- fileio ................................................................................................... [0 Storage Object]
| o- iblock ................................................................................................... [1 Storage Object]
| | o- sata-r5 ............................................................................................ [/dev/md127 activated]
| o- pscsi .................................................................................................... [0 Storage Object]
| o- rd_dr .................................................................................................... [0 Storage Object]
| o- rd_mcp ................................................................................................... [0 Storage Object]
o- iscsi ............................................................................................................. [0 Targets]
o- loopback .......................................................................................................... [0 Targets]
o- qla2xxx ............................................................................................................ [1 Target]
| o- 21:00:00:e0:8b:94:2b:98 ........................................................................................... [enabled]
| o- acls ............................................................................................................. [3 ACLs]
| | o- 10:00:00:05:1e:fb:28:cc .................................................................................. [1 Mapped LUN]
| | | o- mapped_lun0 ............................................................................................... [lun0 (rw)]
| | o- 21:00:00:1b:32:1f:76:a0 .................................................................................. [1 Mapped LUN]
| | | o- mapped_lun0 ............................................................................................... [lun0 (rw)]
| | o- 21:00:00:1b:32:88:d8:eb .................................................................................. [1 Mapped LUN]
| | |  o- mapped_lun0 ............................................................................................... [lun0 (rw)]
| o- luns .............................................................................................................. [1 LUN]
| o- lun0 ...................................................................................... [iblock/sata-r5 (/dev/md127)]
o- tcm_fc ............................................................................................................ [0 Targets]

сохраняем настройки:

/> saveconfig
WARNING: Saving localhost current configuration to disk will overwrite your boot settings.
The current target configuration will become the default boot config.
Are you sure? Type 'yes': yes
Making backup of loopback/ConfigFS with timestamp: 2013-05-31_03:05:44.355635
Successfully updated default config /etc/target/loopback_start.sh
Making backup of qla2xxx/ConfigFS with timestamp: 2013-05-31_03:05:44.355635
Successfully updated default config /etc/target/qla2xxx_start.sh
Making backup of fc/ConfigFS with timestamp: 2013-05-31_03:05:44.355635
Successfully updated default config /etc/target/fc_start.sh
Making backup of LIO-Target/ConfigFS with timestamp: 2013-05-31_03:05:44.355635
Generated LIO-Target config: /etc/target/backup/lio_backup-2013-05-31_03:05:44.355635.sh
Making backup of Target_Core_Mod/ConfigFS with timestamp: 2013-05-31_03:05:44.355635
Generated Target_Core_Mod config: /etc/target/backup/tcm_backup-2013-05-31_03:05:44.355635.sh
Successfully updated default config /etc/target/lio_start.sh
Successfully updated default config /etc/target/tcm_start.sh

Собственно все, у вас в свойствах FC адаптера должен появится таргет с похожим именем:

LIO-ORG Fibre Channel Disk (naa.6001405d566ba0125e644df8007603ce)

Не забудьте проверить:

1. На свитче настроены zone, это самая частая ошибка.
2. Target прописан в автостарте и вообще запускается.
3. Установлен пакет с firmware (sys-block/qla-fc-firmware)
4. FC-адаптер на таргете виден в lspci, очень часто PCIe выпадывают из слота. (выполнить lspci | grep ibre ): 02:00.0 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 02).
5. FC адаптер на esxi установился, некоторые требуют установки extension.

Далее можно использовать устройство в VMware, но для оптимального результата стоит отключить ускорение (конечно если у вас нет других СХД, поддерживающих эту фичу – посмотреть можно в storage, колонка «hardware acceleration») иначе ESXi будет при каждой операции его пытаться использовать и тормозить.

После перевода серверов виртуализации на Windows Server 2012 возникло желание использовать новый функционал Hyper-V – Shared Nothing Live Migration для хостов не являющихся членами кластеров. Здесь я опишу практический пример действий, которые были выполнены для того, чтобы отделить трафик миграции от основного трафика управления хостом виртуализации. В рассматриваемом примере имеется два сервера виртуализации HP ProLiant DL380 G5 с дополнительно установленным двух-портовым гигабитным сетевым адаптером HP NC360T. Таким образом каждый сервер имеет по четыре гигабитных сетевых интерфейса, которые мы будем использовать в следующем порядке:

• Port 1 NC373I (On-Board NIC1) – Под трафик резервного копирования DPM
• Port 2 NC373I (On-Board NIC2) – Под трафик Live Migration (LM)
• Port 3 NC360T (PCI-E NIC Port1) – Под трафик управления хостом
• Port 4 NC360T (PCI-E NIC Port2) – Под трафик виртуальных машин

Настраиваем отдельный сетевой интерфейс для Live Migration

Соответственно первое что мы должны сделать, это выделить отдельную IP подсеть и назначить каждому серверу IP адрес из этой подсети. В нашем примере под задачи миграции выделена подсеть 10.160.35.0/24 и адрес из этой подсети указан на интерфейсе Port 2 на каждом из серверов. Указываем только IP адрес и маску подсети. Шлюз по умолчанию оставляем пустым (он указан только на интерфейсе управления хостом – Port 3).

По кнопке Advanced открываем расширенные настройки IPv4 и отключаем регистрацию в DNS

На закладке Networking оставляем включенным только минимально необходимое количество модулей:

• Client for Microsoft Networks
• QoS Packet Scheduler
• File and Printer Sharing for Microsoft Network
• Internet Protocol Version 4 (TCP/IPv4)

Также не забываем выставить приоритет использования сетевых интерфейсов таким образом, чтобы интерфейс управления (в нашем случае Port 3) был самым первым.
Control Panel\Network and Internet\Network Connections > Меню Advanced

После того как на обоих наших серверах виртуализации настроены сетевые интерфейсы для миграции, проверим их взаимную доступность выполнив Ping IP адресов сегмента 10.160.35.0/24 с одного сервера на другой. В нашем примере оба сервера виртуализации подключены к одному физическому сегменту сети и поэтому проблем с их взаимной доступностью не возникает.

Включаем и настраиваем опции Live Migration

Далее на каждом из серверов откроем оснастку Hyper-V Manager и в меню Action > Hyper-V Settings на вкладке Live Migration включим нужный нам функционал, если он не был включён ранее, например на этапе установки роли Hyper-V.

В качестве протокола аутентификации выберем Kerberos, так как этот вариант позволит нам использовать для запуска миграции средства удалённого управления, такие как консоль SCVMM или удалённо запущенную оснастку Hyper-V Manager. Также укажем IP подсеть, которая должна будет использоваться для LM. Можно указать например всю подсеть типа 10.160.35.0/24 или же отдельный адрес локального интерфейса в виде 10.160.35.60/32

На всех интерфейсах относящихся к перечисленным подсетям будет создан TCP прослушиватель порта 6600 для входящих подключений LM. Если по какой-то причине после сохранения настроек указанный порт не начал прослушиваться, то можно попробовать перезапустить службу Hyper-V Virtual Machine Management (vmms).

Через PowerShell локально на сервере виртуализации можно получить информацию об активных прослушивателях LM с помощью команды:

gwmi-nroot\virtualization\v2Msvm_VirtualSystemMigrationService | selectMigrationServiceListenerIPAddressList

или для удалённого компьютера:

gwmi-computer <RemoteServer> -nroot\virtualization\v2Msvm_VirtualSystemMigrationService

Настраиваем делегирование в Active Directory

Чтобы выбранный нами тип взаимной аутентификации между хостами виртуализации в процессе миграции успешно работал, нам необходимо выполнить делегирование служб cisf и Microsoft Virtual System Migration Service в свойствах учетных записей обоих серверов виртуализации на соответствующей закладке

Если хостов виртуализации для которых нужно настроить делегирование более 2-3, то добавление каждого нового хоста может стать трудоёмким процессом. Вот пример простенького скрипта который позволит ускорить процесс добавления нового хоста виртуализации в делегирование всем существующим:

Import-ModuleActiveDirectory

$HostName=“KOM-AD01-VM01”

$HostFQDN=“KOM-AD01-VM01.holding.com”

$Services= @(“cifs”,“Microsoft Virtual System Migration Service”)

$OU= “OU=HOSTS,DC=holding,DC=com”

$Filter=“(&(objectClass=computer)(cn=KOM-AD01-VM*)(!description=*cluster*)(!userAccountControl:1.2.840.113556.1.4.803:=2))”

Get-ADComputer-SearchBase$OU-ResultSetSize$null-LDAPFilter$Filter-PropertiesDistinguishedName | ForEach-Object {

Write-Host“Изменяемучетнуюзапись:”$_.DistinguishedName

ForEach ($Servicein$Services)

{

Set-ADObject$_.DistinguishedName -Add @{“msDS-AllowedToDelegateTo”=“$Service/$HostFQDN”,“$Service/$HostName”}

}

}

Определяемся с разрешением имён

Далее нам необходимо решить вопрос с разрешением имён, то есть чтобы хосты виртуализации “видели” друг друга по IP адресам относящимся к выделенной нами подсети 10.160.35.0/24. Сделать это можно двумя путями – через DNS или через редактирование локальных файлов hosts (C:\Windows\System32\drivers\etc) на хостах виртуализации.

Вариант использования DNS предполагает создание для каждого сервера дополнительной A-записи с IP адресом из подсети LM. С точки зрения трудозатрат это самый простой вариант, однако он имеет существенный недостаток – при разрешении имени сервера виртуализации может возвращаться как IP адрес из подсети миграции так и IP адрес из подсети управления, а это сводит на нет саму идею разграничения трафика. Дополнительно это может вызвать проблемы с доступностью хостов из инфраструктурных систем типа SCVMM или SCOM.

Нам нужно выполнить такую настройку, при которой только сервера виртуализации между собой будут общаться исключительно через выделенную подсеть 10.160.35.0/24, а для всех остальных внешних систем эти самые сервера по прежнему будут доступны через IP адрес интерфейса управления (в нашем случае Port 3). Сделать это можно как раз с помощью редактирования файл hosts на всех серверах виртуализации которые у нас должны участвовать в процессе миграции. Итак, добавляем на каждом хосте записи о других хостах, указав IP адреса из подсети LM:

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

Если же всё таки вы решите остановиться на варианте с DNS, то как я уже сказал, вам придётся создать дополнительную A-запись (PTR не нужна) с указанием IP адреса из подсети LM

После создания записи, DNS сервер начнёт возвращать разные адреса для одного и того же имени и если IP Forwarding не настроен на интерфейсе сети Live Migration, то могут возникнуть проблемы с доступностью сервера из разных систем. Это можно легко проверить выполнив ping интерфейса LM из другой подсети. По умолчанию в Windows Server 2012 IP Forwarding выключен на всех сетевых интерфейсах. Убедиться в этом можно через PowerShell:

Get-NetIPInterface “Port 2 On-Board (Live Migration)” | fl

Если вы хотите включить на интерфейсе Forwarding , выполните команду:

Get-NetIPInterface “Port 2 On-Board (Live Migration)” | Set-NetIPInterface -Forwarding Enabled

В своём конкретном примере я остановился на варианте с файлом hosts, при котором сервера доступны друг другу в подсети 10.160.35.0/24 и включать форвардинг нет никакой необходимости.

Производительность сетевого интерфейса Live Migration

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

1) Отключить на хосте виртуализации аппаратные функции энергосбережения и заставить работать сервер в режиме High Performance. В частности отключить в BIOS для процессоров использование С-State. В некоторых источниках в интернете можно встретить громогласные заявления о том что отключение С-State приводит чуть ли не к 30% увеличению производительности сетевых адаптеров. Често говоря я такого эффекта на платформе HP ProLiant DL 380 G5 не заметил, хотя всё равно оставил включённым режим повышенной производительности.

2) Включить использование Jumbo Packet на сетевых интерфейсах используемых для LM. В моём случае на встроенном котроллере HP NC373i это означало выбор максимально возможного значения Jumbo Packet – 9014

После того как на хостах настроено использование больших пакетов нам необходимо удостовериться в том что такие пакеты действительно могут ходить между серверами в сегменте сети LM. Сделать это можно например с помощью команды Ping выставив флаг запрета фрагментации пакетов и задать заведомо большую величину пакета:

PING 10.160.35.60 -f -l 8000

Если Ping не пойдёт и мы получим сообщение о том что требуется фрагментация пакета, значит на нашем сетевом оборудовании к которому подключены хосты установлено ограничение по размеру пакета и на этом оборудовании также необходимо включать поддержку Jumbo Packet.

В моём примере оба хоста виртуализации подключены к коммутатору Cisco Catalyst C3560G-24TS. Для того чтобы посмотреть настройки MTU на уровне коммутатора в консоли управления коммутатором выполним:

show system mtu

Чтобы посмотреть MTU на уровне порта:

show interfaces GigabitEthernet0/1

Чтобы сконфигурировать размер MTU для использования Jumbo:

configure terminal
system mtu jumbo ?
system mtu jumbo 9000
exit
write
reload

В моём примере включение Jumbo на уровне коммутатора требует его перезагрузки (reload), то есть планировать такое мероприятие разумеется лучше на нерабочее время.

Проверяем результат

После того как все настройки завершены и мы убедились в том что пакеты большого размера успешно ходят между хостами можно выполнить запуск процедуры Shared Nothing Live Migration. В процессе переноса виртуальной машины обращаем внимание на сетевую активность на выделенных сетевых интерфейсах:

На отправляющей стороне, то есть на хосте виртуализации с которого выполняется перенос VM:

И на принимающем сервере…

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

В процессе миграции выполнялся ping переносимой виртуальной машины и осуществлялся доступ по RDP. 2 потерянных пакета не повлияли на качество терминальной сессии. И это не может не радовать.

Дополнительные источники информации:

TechNet Library – Hyper-V: Live Migration Network Configuration Guide

Windows IT Pro – Shared-Nothing VM Live Migration with Windows Server 2012 Hyper-V

Ask Premier Field Engineering (PFE) Platforms – Windows Server 2012 Hyper-V Best Practices (In Easy Checklist Form)

Если у вас появилась необходимость в использовании нормальных сертификатов не только для web-серверов, но и для Vmware View 5.1-5.2, то очень рекомендую использовать StartCom SSL Certificates (это нормальные сертификаты за весьма разумные деньги – 59 USD за 2-х летние сертификаты Class 2).

Преамбула или Tips & Tricks

Для получения сертификатов – нужно пройти регистрацию на сайте — StartSSL (все достаточно стандартно и предсказуемо). Единственный момент заключается в том, что авторизация на сайте для операций с сертификатами производится при помощи сертификата, который размещается в хранилище компьютера (браузера), т.е. никаких паролей и имен пользователей. Этот сертификат и инструкцию по работе с ним выдают по окончанию регистрации. Сертификат — не восстанавливается, поэтому его лучше сохранить в надежном месте.
После ее прохождения вы получите возможность генерировать сертификаты Class 1 сроком действия – 1год. Они бесплатные и подходят для тестирования сайтов или обучения работе с сертификатами.
Здесь — StartSSL Comparison Chart можно посмотреть сравнительную таблицу сертификатов и их стоимости.
Но, если вам нужен нормальный сертификат ( который будут воспринимать все браузеры), то есть ряд очень важных моментов, связанных с присвоением вам статуса доверенного лица и подготовкой данных для сертификатов»:

1. При регистрации нужно вводить только реальные данные и не использовать VPN или чего-то еще искажающего ваш ip-адрес. Это одна из проверок,

2. Обязательно указывайте номер телефона не через +7, а через 007, т.к. вам будут звонить на него из США, а там не все операторы телефонии понимают символ «+» и если вам не дозвонятся, то откажут в регистрации,

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

4. Если вы прошли все проверки, вам позвонили и убедились, что вы реальное лицо и вас зарегистрировали как доверенное лицо, которое может подписывать сертификаты, а также с карточного счета сняли 59 USD, то это только начало,

5. Важно, что бы в вашем домене был адрес postmaster@domain, т.к. все письма с кодами валидации будут приходить только на этот адрес,

6. Не используйте функцию wildcard, т.е.сертификат для всего домена целиком, а формируйте сертификаты под конкретные имена, иначе для поддоменов и серверов новые сертификаты создавать будет нельзя. Мне этот опыт стоил 25 USD за revocation и настоятельно был рекомендован сотрудником StartCom.

Особенности создания сертификатов для Vmware View 5.1-5.2

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

1. Сертификат генерится через форму сайта, обязательно с паролем,

2. В меню Tool Box выбирается Create PKCS#12 (PFX) File и далее используется только он,

3. После того, как полученный файл .p12 скопирован на сервер, где установлен View Connection Server,

4. Нужно запустить оснастку Certificates/ Local Computer/ Personal

5. После этого требуется вызвать импорт правой кнопкой мыши All Tasks/Import и пройдя нехитрый мастер получить картинку, указанную на скриншоте.

6. Всего должно быть установлено 3 сертификата: сертификат самого сервера и 2 сертификата CA, причем именно в этой ветке.

7. Не забудьте указать vdm в свойствах сертификата Friendly Name,

8. Далее нужно перезапустить все сервисы Vmware Connection Server.

Данный, не очень сложный метод, был подобран методом проб и ошибок, т.к. наличие, просто, сертификата без сертификатов CA, приводило к тому, что ничего не работало, а в логах шла ругань на сертификат.
Для продуктов Vmware недавно появился инструмент — vCenter Certificate Automation Tool 1.0.
И более продвинутый инструментарий от VSSLabs — vCert Manager , уже находится на стадии бета-тестирования.

Итак, поехали.

Для обновления данного массива можно вдохновляться HP EVA4000/6000/8000 and EVA4100/6100/8100 Updating Product Software Guide (либо другим, соответствующим вашей модели СХД).
В данном руководстве достаточно хорошо описаны аспекты обновления массива, я же подробнее остановлюсь на обновлении прошивок дисков.

Обновление дисков можно производить через графический интерфейс HP Command View EVA или через скриптовый интерфейс HP SSSU.

Можно обновить прошивку сразу всех дисков, входящих в ваше СХД. Для этого вы скачиваете архив с прошивками, например, HDDBundled_FC_Image_2013_03_18.zip. Кроме прошивок дисков внутри архива лежит информация о версии сборки, в текущем случае это v1.025.

В столбце “Eligible?” указывается, будет ли обновляться этот жесткий диск. После нажатия кнопки Code Load и двухкратного подтверждения запустится последовательное обновление прошивок всех дисков.

Есть нюанс при обновлении EVA второго поколения (x000/x100) – если вы обновляете подряд прошивки 15-20 дисков, вы можете свалить оптическую петлю, на которой они сидят. Думаю, то же актуально и для третьего/четвертого поколений HP EVA – x400. В руководстве после обновления 15 дисков рекомендуют в окне браузера переместиться в другой пункт меню Command View и заново запустить обновление прошивок дисков через несколько минут. Несколько дебильная схема на мой взгляд.

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

Данный вариант плох тем, что каждый диск прошивается в отдельном окне. Соответственно, вы очень долго будете прошивать все диски.

Но у нас же есть SSSU – чем он может нам помочь?

Я ранее писал про то, что SSSU может помочь получить модели дисков нашей EVA. Более удобный способ – сделать это через отчеты Command View EVA.

Для этого зайдем в System Options и выберем там пункт Export Reports.

При скачивании вы получите архив, в котором находятся CSV-файлы с вашими отчетами.

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

После этого формируем скрипт для HP SSSU:

select manager localhost username=admin password=password
select system EVANAME
CODELOAD DISK "c:\FW34.lod" DISK="Disk 001"
CODELOAD DISK "c:\FW34.lod" DISK="Disk 002"
...
CODELOAD DISK "c:\FW34.lod" DISK="Disk 010"

И выполняем его с сервера, на котором установлен HP SSSU

"C:\Program Files\Hewlett-Packard\Sanworks\Element Manager for StorageWorks HSV\sssu.exe" "file C:\tmp\script.sssu"

Таким нехитрым образом мы можем обновлять прошивку сразу нескольких дисков EVA, при этом не рискуя положить оптическую петлю.

Работая с серверами HP ProLiant столкнулся с ситуацией когда в BIOS отсутствует информация о серийном номере сервера а значение UUID забито нулями. Как выяснилось, данная проблема может всплыть например после выхода из строя и замене батареи “таблетки” на материнской плате сервера. В некоторых случаях это может стать источником мелких неприятностей, например невозможностью получить соответствующую информацию из систем инвентаризации и/или мониторинга.

По началу я бросился искать на сайте вендора какой-нибудь инструмент для регенерации UUID, но потом вспомнил что если зайти в BIOS сервера, то в разделе управления расширенными настройками Advanced Options можно забить фактическую информацию в поля Serial Number и Product ID с шильдика который расположен на лицевой стороне сервера.

После этого при следующей перезагрузке сервера UUID будет автоматически сгенерирован на основе введённых данных

Ранее описывалась Установка HP Systems Insight Manager (SIM) на примере версии 6.2 на базе Windows Server 2008 R2 и SQL Server 2008 R2. Развернутый описанным образом SIM просуществовал у меня периодически обновляясь методом in place upgrade до версии 7.0.0. Теперь рассмотрим процедуру простейшей миграции существующего сервера на новую версию SIM 7.2 на базе Windows Server 2012 и SQL Server 2012.

Ознакомится с предварительными требованиями для новой версии SIM можно в документе HP Systems Insight Manager 7.2 Installation and Configuration Guide for Microsoft Windowsиз которого мы и узнаём о том, что теперь для сервера SIM можно использовать Windows Server 2012 и SQL Server 2012.

В целом процедура миграции будет представлять из себя следующую последовательность действий:

1. Экспортируем данные SIM с помощью утилиты MXEXPORT
2. Переустанавливаем ОС и выполняем подготовительные процедуры
3. Устанавливаем и обновляем SQL Server
4. Устанавливаем новую версию HP SIM
5. Импортируем данные с помощью утилиты MXIMPORT
6.Проверка и дополнительные манипуляции.

1. Экспортируем данные SIM с помощью утилиты MXEXPORT

Изначально я планировал несколько иной сценарий обновления, когда сначала на действующей системе SIM обновляется до версии 7.2 а потом уже выполняется экспорт/переустановка/импорт. Но в результате такой последовательности я получил необъяснимую для меня ошибку (какое-то дикое исключение Java) в процессе импорта на переустановленной системе и пришлось откатывать виртуальную машину назад.

Почитать о процедуре миграции можно в разделе Data migration (стр.61) указанного выше документа. Конкретно по работе утилиты MXEXPORT более подробной можно найти в соответствующем разделе онлайн справки.

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

MXEXPORT -p Passw0rd

По умолчанию экспорт данных будет произведён в файл Products.zip расположенный в каталоге
C:\Program Files\HP\Systems Insight Manager\data\configdata-export\

В случае возникновения каких либо ошибок в процессе экспорта (как и в последующем процессе импорта) для отладки можно дополнительно включить режим расширенного логирования в файле migration.propsкаталога [HPSIM]\config\debugsettings поменяв значение параметра GlobalEnable на true,20,,

После этого в процессе экспорта/импорта данные расширенного логирования будут попадать в файл [HPSIM]\logs\migration_log4j.log

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

2. Переустанавливаем ОС на Windows Server 2012

Предварительно скопировав в надёжное место полученные предыдущем этапе данные экспорта SIM, переустанавливаем ОС на нашем сервере на Windows Server 2012 Standard. В процессе установки оставляем нетронутым логический диск D: потому что в нашем примере на нём хранится каталог VCRepository в который ранее были развернуты все обновления распространяемые через Version Control Repository Manager (VCRM). Содержимое этого каталога нам понадобятся в дальнейшем для быстрого  восстановления работоспособности VCRM

После завершения процесса установки в консоли Computer Management переводим в боевое состояние наш том на котором сохранён репозитарий VCRM и присваиваем ему используемую ранее букву диска

Далее, в процессе настройки системы присваиваем компьютеру те же имя и IP адрес, что были ранее.

Устанавливаем все доступные обновления с WSUS

Включаем в группу локальных Администраторов доменные сервисные учетные записи, от имени которых будут работать службы SQL Server и HP SIM. В нашем случае это s-KOM-AD01-HPSIM-DB и s-KOM-AD01-HPSIM-Svc соответственно

В дальнейшем для установки SQL Server 2012 на наш сервер нам потребуется наличие компонент .NET Framework 3.5 а для работы HP SIM потребуется служба SNMP Service

Включаем нужные компоненты с помощью PowerShell:

Import-ModuleServerManager

Add-WindowsFeature NET-Framework-Core -Restart-Source:\\FILESERVER\OSInstallers\WinSrv2012RTM\sources\sxs

Add-WindowsFeature SNMP-Service

В документации можно найти упоминания о том, что в некоторых случаях требуется отключение механизма User Account Control (UAC). Через локальные политики безопасности мы можем отключить использование UAC для администраторов системы.

Откроем оснастку Local Group Policy Editor (gpedit.msc), перейдём к разделу Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Local Polices > Security optionsи отключим параметр

User Account Control: Run all administrators in Admin Approval Mode

Чтобы эта настройка вступила в действие необходимо перезагрузить систему. Можно также отключить глобально UAC в панели управления. Фактически я пробовал проводить процедуру установки и с включенным UAC и поверхностно всё вроде бы было нормально. Однако в определённый момент всё равно приходилось отключать UAC чтобы как-то уменьшить странности в поведении SIM, например на отрез неработающий автологон (SSO) при входе в веб-консоль SIM. К слову об автологоне – на обновлённой инсталляции смог заставить работать этот механизм лишь через браузер Mozilla Firefox.

3. Устанавливаем SQL Server 2012

Согласно раздела System requirements (стр.5) выше обозначенного документа для БД SIM мы можем использовать Microsoft SQL Server 2012 Express SP1

В процессе установки SQL Server выбираем компоненты. Необходимый минимум:

• Database Engine Services
• Management Tools – BasicПри желании выносим каталог данных экземпляра SQL Server на раздел, отличный от системного.

  Указываем созданную ранее доменную учетную запись от имени которой будет работать служба SQL Server Database Engine, а для службы  SQL Server Browser тип запуска не забываем выставить в Automatic

  

  Выбираем порядок сортировки БД тот же с которым у нас успешно функционировала БД SIM прошлой версии – Latin1_General_CI_AS

  

  Найти явных требований к режиму аутентификации мне не удалось, хотя в некоторых документах, например How to Move an HP Systems Insight Manager SQL 2008 Database from a Local to a Remote Server White Paper проскакивает информация о необходимости использования Mixed Mode, хотя это довольно странно, так как не понятно зачем именно нужен этот режим, когда в документе речь идёт лишь о Windows аутентификации. Как и ранее я останавливаюсь на использовании Windows authentication mode

  Не забываем также включить локальную группу администраторов сервера BUILTIN\Administrators в администраторы экземпляра SQL Server.

  После завершения основной установки выполняем установку Service Pack 1 for SQL Server 2012 а затем Cumulative update package 2 for SQL Server 2012 Service Pack 1 (KB2790947)

  

  Затем открываем консоль SQL Server Configuration Manager.
  Проверяем параметры службы SQL Server Browser на предмет автоматического запуска. В свойствах серверных протоколов включаем протоколы Named Pipes и TCP/IP

  В свойствах протокола TCP/IP необходимо отключить использование динамических портов, указав статический порт по умолчанию – 1433

  

  После всех внесённых изменений перезагружаем сервер и убеждаемся, что службы SQL Server стартовали без проблем и в системе работают соответствующие TCP/IP прослушиватели.

  Настраиваем правило в Windows Firewall для входящих подключений на порт SQL по умолчанию 1433:

  netsh advfirewall firewall add rule name = “SQL Server Default Port Rule” dir = “IN” protocol = “TCP” action = “Allow” localport = “1433”

  4. Устанавливаем новую версию HP SIM

  Загружаем HP SIM по ссылке http://www.hp.com/go/hpsim

  Для загрузки нам потребуется зарегистрироваться на сайте HP с указанием существующего почтового ящика email (на него буду приходить уведомления о транзакциях операций загрузки ПО HP). После регистрации мы сможем скачать дистрибутив HP SIM последней версии. Текущая версия HP SIM 7.2 загружается в виде архива размером 1,44 ГБ.

  

  Распаковываем скачанный архивный файл, переходим в каталог hpsim\win и запускаем setup.exe. Инсталлятор выполнит проверку наличия экземпляра SQL Server и найдёт установленный нами ранее экземпляр именованный как SQLEXPRESS. В качестве учетной записи для доступа к базе данных используем созданную соответствующую доменную учетную запись.

  

  Возможно мы получим предупреждение об использовании неподдерживаемого типа БД. Полагаю можно его проигнорировать, так как в документации (стр.7) встречается упоминание о подобном поведении инсталлятора и на Windows 2008.

  

  Далее указываем тип установки. Выбираем тип Typicalдля полной установки всех компонент.

  

  В качестве учетной записи служб HP SIM укажем туже самую созданную ранее в домене сервисную учетную запись.

  

  После этого подтверждаем выбор устанавливаемых компонент и запускаем непосредственную процедуру установки. После окончания процедуры установки мы получим уведомление о регистрации. Для регистрации перейдём на сайт HP на страницу HP Systems Insight Manager Registration(со временем URL для регистрации может измениться, актуальную его версию можно найти в свежем руководстве по установке HP SIM). Процедура регистрации также потребует учетной записи на сайте HP (HP Passport sign-in) хотя и не представляет собой ничего сложного.

  Если мы выполняем повторную установку HP SIM то можно воспользоваться кодом регистрации полученным ранее. Например у меня для регистрации подошёл код полученный ещё для версии 6.2

  

  После того как ключ введён и успешно принят, программа установки попросит выполнить перезагрузку компьютера.

  Для возможности удалённого доступа к компонентам HP SIM добавим ещё ряд разрешающих правил для Windows Firewall:

  netsh advfirewall firewall add rule name = “SNMP Trap Listener” dir= “IN” protocol = “UDP” action = “Allow” localport = “162”

  netsh advfirewall firewall add rule name = “HP Systems Insight Manager Web Server” dir= “IN” protocol = “TCP” action = “Allow” localport = “280”

  netsh advfirewall firewall add rule name = “HP Systems Insight Manager Secure Web Server” dir= “IN” protocol = “TCP” action = “Allow” localport = “50000”

  netsh advfirewall firewall add rule name = “HP System Management Homepage Web Server” dir= “IN” protocol = “TCP” action = “Allow” localport = “2301”

  netsh advfirewall firewall add rule name = “HP System Management Homepage Secure Web Server” dir = “IN” protocol = “TCP” action = “Allow” localport = “2381”

  Информацию обо всех портах используемых SIM (в зависимости от набора используемых компонент) можно найти в таблицах:

  стр.35 Table 11 Firewall protection exceptions
  стр.39 Table 12 Exceptions to firewall protection

  После этого мы должны удостовериться что веб-консоль HP SIM успешно открывается. Используем адрес по умолчанию:

  https://KOM-AD01-HPSIM.holding.com:50000

  При первом входе запустится First Time Wizard, который мы закрываем без заполнения.

  5. Импортируем данные с помощью утилиты MXIMPORT

  Копируем созданный ранее файл с экспортированными данными Products.zip  в каталог [HPSIM]\data\configdata-import\, открываем из под Администратора командную строку и вызываем утилиту импорта MXIMPORT и последовательно:

   

• Вводим пароль с которым производился экспорт данных;
• Соглашаемся с предупреждением о том, что существующие данные из БД свеже-установленного SIM в процессе импорта будут удалены и заменены импортируемыми данными;
• Отказываемся от того, что наша база данных является удалённой;
• Соглашаемся с тем что службы IM будут остановлены в процессе импортаДожидаемся успешного окончания процесса импорта, после чего снова запускаем веб-консоль SIM и проверяем что же мы получили в результате импорта.6. Проверка и дополнительные манипуляции.

  
  Убеждаемся в том, что восстановлена информация о всех устройствах и коллекциях устройств которые мы создавали ранее, а также сохранена вся информация о событиях для этих устройств:

  

  Убеждаемся в том, что настройках безопасности сохранены все сделанные ранее нами настройки по распределению прав доступа к SIM – Users/Toolboxes/Authorizations в меню Options > Security > Users and Authorizations

  

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

  1. Останавливаем службу HP Systems Insight Manager

  2. В каталоге C:\Program Files\HP\Systems Insight Manager переименовываем существующие файлы (делаем их резервную копию):
  – файл \bin\server_cert.pem переименовываем в server_cert_BACKUP.pem
  – файл \bin\ssoserver_cert.pem переименовываем в ssoserver_cert_BACKUP.pem
  – папку \config\certstorпереименовываем в certstor_BACKUP

  3. Копируем файлы server_cert.pem , ssoserver_cert.pem  и весь каталог \config\certstorиз резервной копии каталога C:\Program Files\HP\Systems Insight Manager, которую мы сделали до переустановки ОС. При этом необходимо выполнить аналогичные настройки на разрешения на уровне NTFS выставленные на указанные файлы.

  4. Запускаем службу HP Systems Insight Manager и проверяем результат.

  Ещё раз повторюсь что использовать такой способ – на ваш страх и риск, и его реальные последствия мне не известны… И честно говоря после некоторых мытарств я всё таки решил что правильней будет не делать этого, а создать новый сертификат сервера и для механизмов SSO SMH/iLO использовать сгенерированный в ходе установки сертификат.

  Для того чтобы восстановить функциональность VCRM, открываем его веб-консоль и заново выполняем настройки, указав в частности используемый ранее каталог для хранения обновлений:

  

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

Итак, поехали.

1) Обновление vCenter до версии 5.1b.

vCenter у меня уже версии 5.1.

Вставляем диск с vCenter и по порядку выполняем обновление всех компонент.

Проблем никаких не увидел.

2) Обновляем хосты ESX 4.1 U3 до ESXi 5.1.

Обновление хостов я производил через Update Manager.

– Добавил дистрибутив с ESXi 5.1.

– Создал Baseline для апгрейда хостов

– Затем назначил этот Baseline на кластер и начал применять (Remediate) его на хосты.

Первый подвох был внезапен

VMkernel and Service Console interfaces are sharing the same subnet…

Пришлось удалять VMKernel-интерфейс из подсети управления хостами.

Также при обновлении хоста пришлось временно отключать Admission Control и давать разрешение на удаление стороннего ПО с хоста.

На выходе мы имеем несколько хостов ESXi 5.1 с оценочной лицензией. Теперь можно установить на них дополнительные патчи для ESXi 5.1 и продолжать настройку.

3) Так как я сижу на распределенном коммутаторе, мигрируем обратно на стандартный.

– Составляем список портгрупп распределенного коммутатора, используемых на обновленных хостах.

– Создаем стандартный коммутатор vSwitch0 на каждом хосте кластера и создаем портгруппы с корректными номерами VLAN

Get-Cluster -Name Cluster | Get-VMHost | %{
$vswitch=New-VirtualSwitch -Name vSwitch0 -vmhost $_
New-VirtualPortGroup -Name VLAN10 -VLanId 10 -VirtualSwitch $vswitch
New-VirtualPortGroup -Name VLAN20 -VLanId 20 -VirtualSwitch $vswitch
New-VirtualPortGroup -Name VLAN30 -VLanId 30 -VirtualSwitch $vswitch
}

– руками добавляем адаптер vmnic1 в стандартный коммутатор на каждом хосте

– заходим в сетевые настройки хоста и проверяем, что на распределенном коммутаторе остался один сетевой адаптер. Нажимаем ссылку “Manage Virtual Adapters…”

– в полученном окне выбираем интерфейс управления и нажимаем кнопку “Migrate” для его переноса на стандартный коммутатор

– укажем название стандартного коммутатора и корректный номер VLAN для управляющего интерфейса VMKernel

– после этого можно переносить виртуальные машины на стандартный коммутатор. Проще всего это делать из вкладки Home->Inventory->Networking (скриншот приведен выше), где представлены все порт-группы. Выбираете порт-группу на распределенном коммутаторе, там выделяете все ВМ с вашего хоста и перетаскиваете их на соответствующую порт-группу стандартного коммутатора (drag’n’drop). Осторожно, никаких подтверждений не требуется, вы легко можете перенести ВМ в другую порт-группу и создать инцидент. Данный перенос можно производить в рабочее время – доступ к ВМ не прекращается.

– теперь в сетевых настройках хоста нажмем ссылку “Manage Physical Adapters…” и удалим из распределенного коммутатора адаптер vmnic0

– для добавления этого адаптера к стандартному коммутатору переключимся на представление стандартного коммутатора и зайдем в его свойства

– переключимся на вкладку “Network Adapters” и добавим адаптер vmnic0

– теперь остается удалить хосты из распределенного коммутатора и указать для них лицензии vSphere 5.

P.S. Вся эта суматоха затеяна из-за компании VMware, которой влом поддерживать Windows 2012/Windows 8 на vSphere 4.1.

Продолжая тему развёртывания Service Pack 1 (SP1) для линейки продуктов Microsoft System Center (SC) 2012, в этой заметке опишу опыт обновления Configuration Manager (SCCM).

Обновление инфраструктуры SCCM до уровня SP1 будем выполнять в следующей последовательности:

1. Обновляем сервер центрального сайта – Central Administration Site (CAS)
2. Обновляем сервера первичных сайтов Primary Site
3. Обновляем сервера вторичных сайтов Secondary Site
4. Обновляем клиентов SCCM

В данный момент все сервера инфраструктуры SCCM у нас работают на базе Windows Server 2008 R2 и SQL Server 2008 R2. Рассмотрим сценарий In-Place Upgrade обновления SCCM

О всех основных изменениях и нововведениях в SP1 можно почитать в документе TechNet Library –  What’s New in Configuration Manager SP1

Общие процедуры установки пакета обновлений описаны в документе TechNet Library –  Upgrade Configuration Manager to a New Service Pack

Для того чтобы правильно спланировать обновление желательно прочитать документы:
TechNet Library – Planning to Upgrade System Center 2012 Configuration Manager
KB2801416 – How to upgrade System Center 2012 Configuration Manager to SP1

Для корректной процедуры обновления нам потребуется дистрибутив SCCM SP1 доступный на Microsoft после 25.01.2013. В обновленный дистрибутив интегрировано обновление KB2801987 – Installation error 0x800b0101: System Center 2012 Configuration Manager Service Pack 1 client. Загрузить правильный образ ISO с дистрибутивом можно либо с сайта MVLSC – имя файла: SW_DVD5_Sys_Ctr_2012w_SP1_Config_Mgr_EndPt_Protection_MultiLang_-2_X18-84756.ISO
либо с сайта Technet Subscriptions – имя файла:
mu_system_center_2012_configuration_manager_and_endpoint_protection_with_sp1_x86_x64_dvd_1565907.iso

И в том и в другом случае контрольная сумма файла
SHA1: AB930F8FC127D00C510A5FD73038CF16DCFD2290

Подготовительные мероприятия

Перед непосредственной процедурой обновления нам нужно выполнить резервное копирование данных сайта на серверах CAS и Primary. Порядок резервного копирования и восстановления подробно описан в документе  TechNet Library – Backup and Recovery in Configuration Manager

После обновления SCCM доя уровня SP1 нам станет доступно резервное копирование сайта с помощью DPM, а пока у нас нет такой возможности и мы можем настроить для этой цели стандартную задачу обслуживания сайта (Maintenance Task)

В консоли SCCM переходим Administration\Overview\Site Configuration\Sites и для сайта выбираем Site Maintenance. В открывшемся перечне задач обслуживания сайта включаем задачу резервного копирования – Backup Site Server. Указываем путь к каталогу для сохранения резервной копии данных сайта и устанавливаем ближайшее время.

После того как наступает указанный период времени нам необходимо убедиться в том, что резервное копирование успешно выполнено. Для этого в разделе консоли Monitoring\Overview\System Status\Component Status находим компонент SMS_SITE_BACKUP и проверяем события зарегистрированные этим компонентом (Show Messages > All). Наличие события с кодом ID 5035 будет свидетельствовать об успешном завершении бэкапа.

Возможные ошибки и предупреждения в развернутом виде можно найти в лог-файле:
<Каталог установки SCCM>\Logs\Smsbkup.log

Файлы резервной копии сайта сохраняем в надёжное место и делаем ещё одну резервную копию, для того чтобы извлечь из неё файлы базы данных (БД) SQL Server и выполнить над ними процедуру проверки готовности БД к обновлению до уровня SCCM SP1.

В каталоге
<Каталог резервного копирования>\Files\<SiteCode>Backup\SiteDBServer\
находим файлы:
CM_<SiteCode>.mdf
CM_<SiteCode>_log.LDF

и копируем их на отдельный тестовый сервер с развернутым экземпляром SQL Server той же версии что используется на нашем сервере сайта SCCM. Ни в коем разе не стоит использовать для этой процедуры экземпляр SQL Server на продуктивной системе.
Для дополнительной страховки при подключении файлов БД к тестовому экземпляру SQL Server переименуем файлы БД и изменим её имя.

Подключаем БД в SQL Server Management Studio следующим запросом:

USE [master]

GO

CREATE DATABASE [CM_CAS_TEST] ON

( FILENAME = N’F:\SiteDBServer\CM_CAS_TEST.mdf’ ),

( FILENAME = N’F:\SiteDBServer\CM_CAS_TEST_log.LDF’ )

FOR ATTACH

GO

Распаковываем на тестовом сервере дистрибутив SCCM SP1 и запускаем процедуру тестирования подключенной БД специальной командой:

SMSSETUP\BIN\X64\Setup.exe /TESTDBUPGRADE SQLTEST\CM_CAS_TEST

Где SQLTEST\CM_CAS_TEST имя экземпляра SQL Server и подключенной копии БД.

Все ключи здесь: Использование параметров командной строки в программе установки

После запуска программы проверки нажимаем кнопку Begin TestDBUpgrade

Если размер БД большой то можем получить уведомление о том что процедура обновления может занять значительно время.

В моём случае я нарвался на ошибку обновления БД

В логе C:\ConfigMgrSetup.log фигурировала ошибка.

ERROR: SQL Server error: [42000][468][Microsoft][SQL Server Native Client 11.0][SQL Server]Cannot resolve the collation conflict between “Cyrillic_General_CI_AS” and “SQL_Latin1_General_CP1_CI_AS” in the not equal to operation.

Стало очевидно, что процесс обновления не может выполнить необходимые ему действия из-за того, что порядок сортировки (Collation) экземпляра SQL на тестовом сервере отличается от порядка сортировки копии БД SCCM. Поэтому дополнительно мне пришлось развернуть на тестовом сервере ещё один инстанс SQL Server с таким же порядком сортировки, что используется в копии БД SCCM.

После разрешения всех подобных недоразумений запускаем процедуру обновления копии БД снова и дожидаемся окончания процесса по записям лога C:\ConfigMgrSetup.log

Если процедура обновления на тестовой копии БД в конечном итоге прошла успешно, можно приступать к следующему подготовительному шагу.

***

В консоли SCCM переходим Administration\Overview\Site Configuration\Sites и для сайта выбираем Site Maintenance. В открывшемся перечне задач обслуживания сайта отключаем задачу – Delete Aged Client Operations. Это нужно выполнить для всех первичных сайтов в иерархии. Вновь включить задачу можно будет после окончания процесса обновления первичных серверов.

***

Если на обновляемом сайте (CAS/Primary/Secondary) используется роль Software Update Point (SUP) в связке с WSUS 3.0 SP2, то необходимо установить обновления KB2720211 и KB2734608.

***

Выполняем удаление Windows Automated Installation Kit (WAIK) через оснастку установки и удаления программ

Это потребуется сделать для того, чтобы в дальнейшем можно было установить необходимый для SCCM SP1 пакет Windows Assessment and Deployment Kit (ADK), так как WAIK и ADK не уживаются на одной системе. В моём случае это пришлось сделать на CAS и Primary

Сразу после этого устанавливаем Windows ADK. В составе устанавливаемых компоненты выбираем необходимый минимум:

• Deployment Tools
• Windows Preinstallation Environment (Windows PE)
• User State Migration Tool (USMT)

***

Согласно вышеупомянутого документа KB2801416 – How to upgrade System Center 2012 Configuration Manager to SP1 перед установкой SP1 на все сервера SCCM необходимо установить Windows Management Framework 3.0, в состав которого входит Windows PowerShell 3.0в том случае если на серверах используется ОС отличная от Windows Server 2012. Честно говоря, требование этой статьи кажется довольно сомнительным, так как нигде в явном виде не удалось найти информации о том, что серверным компонентам SCCM SP1 действительно нужен WMF 3.0.

Попытался для себя прояснить ситуацию здесь SCCM 2012 SP1 – Вопрос по минимальным требованиям к ПО для вторичного сайта, но честно говоря ясности от этого не добавилось.

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

1) Установка WMF 3.0 на CAS снесла башню WMI (пространство имён Root\SMS попросту пропало), после чего, понятное дело SCCM перестал адекватно себя вести. Спасла ситуацию последовательность действий:
– Остановил службу WMI
– Переименовал каталог C:\Windows\System32\wbem\Repository в Repository.BACK
– Запустил службу WMI
– Выполнил установку SCCM SP1 после чего пространство имён SCCM было восстановлено, но осадок в душе остался неприятный.
По ходу пьесы нашёл полезную заметку о решении проблем с WMI у SCCM IT Evangelist – Unable to connect to the SCCM Console – How to fix issues related with connectivity to the SCCM Console

2) Установка WMF 3.0 на следующий обновляемый сервер первичного сайта прошла вполне себе без последствий.

3) Установку WMF 3.0 на следующие несколько подчинённых серверов вторичных сайтов не делал вообще (сервера обновлялись с консоли, подключённой к серверу первичного сайта с уже установленным SP1). При этом процедура обновления устанавливая пререквизиты на вторичные сайты про WMF 3.0 даже не заикнулась.

Если у кого-то есть какие-то соображения по поводу реальной необходимости установки WMF 3.0 перед развертыванием SP1 – интересно было бы выслушать.

Итак, вернёмся к процессу подготовки к установке SP1

***

Необходимо убедиться в том, что у нас используется совместимая версия SQL Server по уровню установленных Service Pack / Cumulative Update. Список поддерживаемых версий здесь: Supported Configurations for Configuration Manager

Другие, не менее важные, но неприменимые в моём случае требования:

• Если для роли SUP используется NLB кластер, его необходимо отключить, оставив только один сервер с ролью SUP;
• При использовании репликации БД для работы с Management Point, необходимо остановить репликацию;
• Если ранее были модифицированы встроенные коллекции, такие как например All Systems – необходимо сохранить эти модификации, если в них ещё есть необходимость, так как в процессе установки SP1 будут восстановлены значения по умолчанию для таких коллекций.***Запускаем процедуру предварительной загрузки обновлений для SP1 указав отдельно созданный для этих обновлений каталог.

В моём случае в этот каталог было загружено 622 MB

***

Из каталога дистрибутива \SMSSETUP\BIN\X64 запускаем утилиту Prerequisite Checker – prereqchk.exeчтобы выполнить проверку соответствия системы всем предварительным требованиям для установки SP1

В своём случае я словил ошибку:

There is an active source hierarchy configured for migration. Please stop data gathering for each source site in the source hierarchy.

Для её разрешения в консоли SCCM Administration\Overview\Migration\Source Hierarchy пришлось остановить все активные источники миграции – Stop Gatering Data

После того, как все требования чекера удовлетворены, – можно приступать к установке…

Обновляем первый сервер в иерархии (CAS/Primary)

Запускаем программу установки Service Pack 1 и выбираем вариант обновления сайта – Upgrade this Configuration Manager site

Вводим ключ продукта (тот же что использовали при первоначальной установке SCCM)

Принимаем все предложенные лицензионные соглашения

Указываем каталог с предварительно загруженными обновлениями – Use previously downloaded files

Выбираем язык серверных компонент. Для того чтобы отчеты SCCM опубликованные на SSRSбыли доступны через веб-браузер на родном Русском языке – включаем  его.

Выбираем языки доступные клиенткой части SCCM.

Снова доходим до шага предварительных проверок убеждаемся в отсутствии проблем, препятствующих установке SP1 и запускаем сам процесс обновления – Begin Install

Дожидаемся успешного окончания процесса установки…

После завершения дополнительно можем просмотреть журнал установки ConfigMgrSetup.log на наличие ошибок и предупреждений

После того, как первый сервер в иерархии обновлён, – самое время обновить отдельно установленные консоли Configuration Managerна рабочих станциях администраторов. Фактически процесс обновления консоли представляет собой удаление консоли версии RTM и установку консоли версии SP1.

Обновляем сервера первичных сайтов

В целом процесс подготовки и установки Service Pack 1 на сервера первичных сайтов, подчинённых CAS, ничем не отличается от вышеизложенного. Вас может смутить сообщение при попытке подключиться консолью SCCM к обновлённому первичному сайту, говорящее о том что консоль будет работать в режиме “только чтение”

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

Обновляем сервера вторичных сайтов

Вторичные сервера, подчинённые уже обновлённым первичным серверам, могут быть легко обновлены прямо с консоли SCCM. Собственно говоря, насколько я понял, никакой другой вариант обновления вторичных сайтов и не поддерживается.

В консоли SCCM переходим в Administration\Overview\Site Configuration\Sites выбираем вторичный сайт и запускаем Upgrade

После утвердительного ответа на вопрос о наших намерениях, мы сможем увидеть, что статус сайта поменялся…

…а через кнопку Show Install Statusмы сможем отследить все этапы обновления…

Если на какой-то из обновлённых серверов вторичных сайтов с включенной ролью SUP вы забыли предварительно установить ранее обозначенные обновления KB2720211 и KB2734608, для такого сервера синхронизация метаданных об обновлениях с сервера верхнего уровня работать перестанет. Но это на самом деле поправимо и эти обновления можно до-установить позже.

Обновляем клиентов

Процедура обновления клиентов представляет собой удаление клиента старой версии и установку клиента версии SP1 (5.00.7804.1000). В процессе установки клиента автоматически устанавливается Microsoft Silverlight версии 5.1.10411.0. Указанная версия Silverlight необходима для доступа к обновлённой веб-консоли Каталога приложений SCCM (Application Catalog). Так же параллельно с обновлением клиента SCCM обновится клиент System Center 2012 Endpoint Protection (SCEP) до версии 4.1.522.0.

Перед тем как в иерархии включать автоматическое развёртывание клиента новой версии клиентского ПО, не помешает создать отдельный пакет и развернуть его на тестовую группу клиентов. Обновлённый дистрибутив клиентского ПО можно найти на сервере в каталоге \\SCCMServer\SMS_<SiteCode>\Client

Информацию о том, как создать пакет для установки/обновления клиента SCCM, а также о всех возможных способах распространения клиента можно найти в документе How to Install Clients on Windows-Based Computers in Configuration Manager

После того как произведено тестовое развёртывание клиентов, в новой версии SCCM можно включить функцию автоматического обновления клиентов в иерархии сайта. В консоли SCCM переходим к узлу Administration\Overview\Site Configuration\Sites и нажимаем на ленте кнопку Hierarchy Settings. На закладке Automatic Client Upgrade включаем опцию Upgrade client automatically when new client updates are availableи настраиваем количество дней в течение которых должно производиться обновление.

Спустя некоторое убеждаемся в том, что на клиентских компьютерах появилось обновлённое клиентское ПО…

За общим статусом обновления всех клиентов принадлежащих сайту можно воспользоваться отчётом Count of Configuration Manager clients by client versions  в группе отчетов Site – Client Information

Под занавес…

После завершения процесса обновления не забываем обратно включить задачу обслуживания Delete Aged Client Operationsна всех первичных сайтах, где она выключалась перед процессом обновления.

***

Также возможно потребуется обновить правила членства в коллекциях, которые имеют ссылку на версию ОС.

***

И ещё один момент. Сразу после обновления обнаружили что перестало работать развертывание ОС при использовании PXE. В качестве первой попытки решения вопроса была выключена и снова включена поддержка PXE (без переустановки) в свойствах роли точки распространения (Distribution Point) – не помогло. И тут вспомнилось предупреждение лога установки ConfigMgrSetup.log о том что требуется вручную обновить загрузочные образы WinPE используемые для среды PXE. После того как образы WinPE были обновлены до новой версии (6.2.9200.16384) и в их свойствах была включена поддержка PXE – всё встало на свои места.

***

При необходимости можно установить обновлённую версию набора утилит System Center 2012 Configuration Manager Service Pack 1 Component Add-ons and Extensions

***

После обновления консоли покрутил имеющиеся на сегодняшний день варианты расширений к консоли и пришёл к выводу что более или менее вменяемым является ConfigMgr Console Extensions последней версии 1.7.2 (21.10.2012)

Дополнительные источники информации:

Techdays – Эволюция в управлении клиентами и серверами с System Center 2012 SP1 Configuration Manager

Anoop – ConfigMgr SCCM 2012 SP1 Upgrade Known Issues

ITBand.ru – Обновляем ConfigMgr 2012 до ConfigMgr 2012 SP1

Russ Rimmerman – ConfigMgr Guy   >  Configuration Manager 2012 RTM to SP1 Upgrade Overview

KB2801420 – List of public KB articles and major fixes that are included in System Center 2012 Configuration Manager SP1

SCCM Team Blog – List of System Center 2012 Configuration Manager Service Pack 1 KBs

Продолжая тему развёртывания Service Pack 1 (SP1) для линейки продуктов Microsoft System Center (SC) 2012, в этой заметке опишу опыт обновления Virtual Machine Manager (VMM).

Выполним обновление сервера VMM до уровня SP1, при этом также обновим операционную систему сервера до Windows Server 2012 Standard а БД перенесём на SQL Server 2012 Standard.

Сразу отмечу, что в моём примере не используются хосты виртуализации VMware и не используются механизмы Performance and Resource Optimization (PRO). В случае использование этих вещей перед обновлением стоит ознакомится с дополнительными подготовительными процедурами согласно Planning Considerations for Upgrading to VMM in System Center 2012 SP1

С системными требованиями для развёртывания VMM можно ознакомится в документе System Requirements for System Center 2012 – Virtual Machine Manager. При этом мы можем обнаружить, что среди поддерживаемых ОС для серверной части VMM есть только Windows Server 2012 (Full/Server Core installation) в редакциях Standard/Datacenter, поэтому, в силу того, что у нас на момент обновления используется Windows Server 2008 R2, мы фактически будем вынуждены выполнить переустановку ОС на поддерживаемую версию – Windows Server 2012.

После установки ОС для экземпляра БД VMM мы развернём SQL Server 2012  Standard Service Pack 1.

В нашем случае на одном сервере будут развернуты компоненты VMM:
– VMM Management Server
– VMM Console
– VMM Database
– VMM Library Server

Ранее мы использовали функционал Self-Service Portal, но начиная с версии SP1 этот функционал из VMM убрали. Грустно конечно, но не смертельно, так как при необходимости в качестве альтернативного решения предлагается использовать сервер App Controller. Но этот продукт в этой заметке мы затрагивать не будем.

Весь процесс будет состоять последовательности действий:

1. Удаляем VMM с сохранением БД VirtualManagerDB
2. Переустанавливаем ОС на Windows Server 2012
3. Устанавливаем SQL Server 2012
4. Восстанавливаем БД VirtualManagerDB в SQL Server
5. Устанавливаем VMM 2012 SP1 в режиме восстановления БД
6.Обновляем агентов VMM

1. Удаляем VMM с сохранением БД VirtualManagerDB

Для начала, на текущем сервере VMM мы должны убедиться в том, что отсутствуют выполняющиеся задачи в рабочей области Задания, после чего надо выполнить резервную копию базы данных VMM. Сделать это можно разными способами, но предпочтительный – с помощью консоли VMM (Параметры > Резервное копирование). Укажем каталог в который будет сохранена резервная копия и запустим процедуру.

Отследить состояние задачи резервного копирования можно в рабочей области Задания. Копируем получившийся файл резервной копии вида VirtualManagerDB-02042013-103204.bak в надёжное месторасположение, например в сетевую папку на другом сервере.

Закрываем консоль и через оснастку установки и удаления программ вызываем процедуру удаления VMM. В мастере установки выбираем режим удаления – Remove features

Затем выбираем компоненты VMM которые мы хотим удалить – отмечаем все.

На следующем шаге выбираем режим сохранения БД – Retain database.

Дожидаемся окончания процесса удаления.

На самом деле, в нашем случае не имеет значения режим удаления VMM, так как мы уже сделали предварительно копию БД, а это по сути и есть всё, что нам нужно для возможности восстановления VMM после переустановки ОС.

2. Переустанавливаем ОС на Windows Server 2012

Переустанавливаем ОС на нашем сервере на Windows Server 2012 Standard, при этом для установленной системы присваиваем тоже имя сервера что было ранее.

Устанавливаем все доступные обновления с WSUS

Включаем в группу локальных Администраторов доменные сервисные учетные записи, от имени которых будут работать службы SQL Server и VMM. В нашем случае это s-SCVMMDB и s-SCVMMSvc

В дальнейшем для установки SQL Server 2012 на наш сервер нам потребуется наличие компонент .NET Framework 3.5. Включаем их с помощью PowerShell:

Import-ModuleServerManager

Add-WindowsFeature NET-Framework-Core -Restart -Source:\\FILESERVER\OSInstallers\WinSrv2012RTM\sources\sxs

3. Устанавливаем SQL Server 2012

О системных требованиях, предъявляемых к БД SC 2012 SP1 VMM, читаем в документе System Requirements: VMM Database

В процессе установки SQL Server выбираем компоненты. Необходимый минимум:

• Database Engine Services
• Management Tools – Complete

Имя экземпляра SQL Server можно оставить по умолчанию – MSSQLSERVER

Для запуска служб SQL Server Database Engine и SQL Server Agent используем ранее созданную доменную учетную запись (которую мы включили в группу локальных Администраторов) – s-SCVMMDB. Режим запуска службы SQL Server Agent – Automatic

Порядок сортировки Collation устанавливаемого экземпляра SQL Server должен быть регистро-независимым (case-insensitive). В нашим примере выбран SQL_Latin1_General_CP1_CI_AS

Режим аутентификации – Windows authentication mode. В группу администраторов SQL Server добавляем локальную группу Администраторовсервера

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

Дожидаемся успешного окончания процесса установки выбранных компонент SQL Server

Устанавливаем обновления доступные на WSUS, в том числе Service Pack 1 для SQL Server

Отдельно устанавливаем доступное на данный момент кумулятивное обновления KB2790947 – Cumulative update package 2 for SQL Server 2012 Service Pack 1

В Windows Firewall создаем правила разрешающие входящие подключения к ресурсам SQL Server:

netsh advfirewall firewall add rule name = “SQL Server Default Port” dir = in protocol = tcp action = allow localport = 1433

4. Восстанавливаем БД VirtualManagerDB в SQL Server

Восстанавливаем в установленный SQL Server 2012 из резервной копии БД VirtualManagerDB. В нашем случае файлы БД должны быть расположены следующим образом:
D:\SQLData\VirtualManagerDB.mdf
D:\SQLData\VirtualManagerDB_log.ldf
Соответственно команда восстановления будет следующей:

Sqlcmd -Q “RESTORE DATABASE [VirtualManagerDB] FROM DISK = N’D:\VMM2012_RTM_DB_BACKUP\VirtualManagerDB-02042013-103204.bak’ WITH FILE = 1, MOVE N’VirtualManagerDB’ TO N’D:\SQLData\VirtualManagerDB.mdf’, MOVE N’VirtualManagerDB_log’ TO N’D:\SQLData\VirtualManagerDB_log.ldf’, NOUNLOAD”

Опционально при желании можно переопределить значения Initial Size для файлов служебной БД tempdb:

Sqlcmd -Q “ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N’tempdev’, SIZE = 102400KB ); ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N’templog’, SIZE = 51200KB )”

В силу того что в нашем примере SQL Server и VMM выполняются на одном сервере, для того чтобы экземпляр SQL Server не отобрал под себя все ресурсы, -настроим ему ограничение по использованию оперативной памяти.

Sqlcmd -Q “EXEC sys.sp_configure N’show advanced options’, N’1′ RECONFIGURE WITH OVERRIDE; EXEC sys.sp_configure N’min server memory (MB)’, N’2048′; EXEC sys.sp_configure N’max server memory (MB)’, N’8192′; RECONFIGURE WITH OVERRIDE; EXEC sys.sp_configure N’show advanced options’, N’0′ RECONFIGURE WITH OVERRIDE”

Или же можно изменить ограничение с помощью графического интерфейса в SQL Server Management Studioоткрыв свойства экземпляра SQL Server

5. Устанавливаем VMM 2012 SP1 в режиме восстановления БД

Перед установкой VMM выполним требования к предварительной установке ПО:

• Windows PowerShell 3.0(уже включено в Windows Server 2012)
• WinRM(уже включено в Windows Server 2012 и по умолчанию служба Windows Remote Management (WS-Management) настроена в режиме автоматического запуска).
• Microsoft .NET Framework 4 или 4.5(уже включено в Windows Server 2012)
• Windows Assessment and Deployment Kit (ADK) for Windows 8 (потребуется отдельная установка)

Загружаем Windows ADK и запускаем исполняемый файл adksetup.exe. Нам потребуется загрузить в отдельный каталог полный дистрибутив ADK

В моём случае по окончании процесса загрузки размер этого каталога составил примерно 2,55 GB.

По завершении загрузки снова запускаем adksetup.exeи переходим к установке, где на этапе выбора компонент отмечаем необходимый минимум:

• Deployment Tools
• Windows Preinstallation Environment (Windows PE)
  

После того как ADK установлен, стоит ещё раз вспомнить о дополнительных требованиях, предъявляемых к серверу VMM:

• Компьютер должен быть членом домена Active Directory
• Имя компьютера не должно содержать последовательность символов “–SCVMM-” и/или быть более 15 символов
• Если VMM разворачивается на виртуальной машине Hyper-V с включенным механизмом Dynamic Memory, значение startup RAM должно быть не менее 2048 Mb

Запускаем процесс установки VMM и выбираем компоненты VMM management server и VMM console

Вводим название организации, Product key, принимаем условия лицензирования и на шаге конфигурации базы данных указываем имя нашего сервера, экземпляр SQL Server и выбираем опцию использования существующей БД (Existing database) – VirtualManagerDB

Мастер установки определит что мы подсовываем ему старую версию БД и предложит выполнить её обновление в процессе установки, с чем мы должны согласиться.

На следующем этапе укажем доменную учетную запись (которую мы ранее включили в группу локальных Администраторов) от имени которой будут запущены службы сервера VMM – s-SCVMMSvc

Включение опции сохранения ключей шифрования VMM в AD в нашем случае неактуально, так как мы не используем отказоустойчивую конфигурацию – кластер VMM

Далее предлагаемые номера портов для коммуникации между компонентами VMM оставляем в значении по умолчанию, если для их изменения нет реальных причин.

Стоит отметить, что на нашем сервере запущена служба Windows Firewall, для которой в процессе установки автоматически будут настроены все необходимые разрешающие правила.

На следующем шаге информацию о создаваемом сетевом каталоге библиотеки VMM (library share) также оставляем без изменений

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

Ещё раз проверяем все выбранные настройки и запустив процесс установки дожидаемся его успешного завершения…

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

%SYSTEMDRIVE%\ProgramData\VMMLogs

Далее запрашиваем с WSUS последние обновления для компонент VMM – в нашем случае это Update Rollup 1

После установки этих обновлений перезагружаем сервер.

6. Обновляем агентов VMM

При первом запуске консоли VMM указываем FQDN имя сервера и порт, который был определён в процессе установки..

Из личных ощущений могу отметить тот факт что скорость открытия консоли и отклик консоли на действия администратора в обновлённой версии стали на порядок лучше. Отдельно порадовало то, что теперь нет проблемы замерзания консоли из-за попытки получить статус отображаемых групп/пользователей из Lync.

Переходим в рабочую область консоли Fabric (Структура) и запускаем процедуру обновления агентов VMM – Update Agent

Первая попытка обновления будет завершена с ошибкой если на целевых хостах виртуализации не установлен пакет Microsoft Visual C++ 2010  x64 Redistributable – версии 10.0.40219. То есть фактически при первой попытке будет произведена автоматическая установка этого пакета на хост, о чём свидетельствуют события в журнале Application

Log Name:    Application
Source:       MsiInstaller
Date:          04.02.2013 22:55:51
Event ID:     1038
Task Category: None
Level:         Information
Keywords:   Classic
User:          SYSTEM
Computer:    KOM-AD01-VM04.holding.com
Description:
Windows Installer requires a system restart. Product Name: Microsoft Visual C++ 2010  x64 Redistributable – 10.0.40219. Product Version: 10.0.40219. Product Language: 0. Manufacturer: Microsoft Corporation. Type of System Restart: 2. Reason for Restart: 1.

После установки этого пакета нужно перезагрузить хосты виртуализации, и уже после перезагрузки развертывание новой версии агента VMM должно пройти успешно.

О том как автоматизировать процесс обновления отдельно установленных консолей VMM с помощью SCCM 2012 описано в заметке В.Якоба – Развёртывание консоли управления System Center 2012 Virtual Machine Manager SP1 при помощи SC 2012 CM

Дополнительные источники информации:

TechNet Library – Tasks to Perform Before Beginning the Upgrade to VMM in System Center 2012 SP1
TechNet Library – Upgrading to VMM in System Center 2012 SP1
TechNet Library – Installing VMM from a Command Prompt

HP Array Configuration Utility (ACU) из состава ProLiant Support Pack это браузер-ориентированная утилита позволяющая управлять дисковой подсистемой серверов HP, например дисковыми массивами подключёнными к контроллерам HP Smart Array. Этот инструмент вполне интуитивно понятен и не создаёт никаких проблем при использовании на полной версии Windows Server c GUI и IE на борту. По умолчанию ACU запускается и выполняется на такой системе в режиме локального приложения (Local Application Mode), но есть у этой утилиты ещё и режим службы для возможности удалённых подключений -Remote Service Mode. При переключении ACU в этот режим в ОС регистрируется системная служба, принимающая запросы на подключение к возможностям ACU от удаленных клиентов. Режим Remote Service Mode может оказаться полезен при работе с серверами на базе OC Windows Server 2008/2008 R2 в режиме Core или Hyper-V Server 2008/2008 R2, то есть там, где нет возможности использовать браузер для запуска ACU в режиме Local Application Mode.

Рассмотрим пример настройки и использования ACU в режиме Remote Service Mode на сервере c OC Hyper-V Server 2008 R2.

Для начала, для возможности работы режима удалённой службы в целевой системе необходимо разрешить входящие подключения на порты TCP 2301 и 2381. Сделать это можно командами:

netsh advfirewall firewall add rule name=’HP System Management Homepage (Secure Port)’ protocol=TCP dir=in localport=2381 action=allow

netsh advfirewall firewall add rule name=’HP System Management Homepage (Insecure Port)’ protocol=TCP dir=in localport=2301 action=allow

После того как порты открыты из командной строки вызываем программу настройки режима запуска ACU:

“Program Files (x86)\Compaq\Cpqacuxe\Bin\setup.exe”

В открывшейся диалоговой форме выбираем соответствующий режим:

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

sc query “Array Configuration Utility”

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

Обратите внимание на то, что текущая реализация ACU подразумевает то, что совместить режимы Remote Service Mode и Local Application Mode невозможно.

В целях повышения общего уровня безопасности системы могу порекомендовать включать использование режима Remote Service Mode только в случаях необходимости и только на время конфигурации дисковой подсистемы сервера.

На практике я столкнулся с интересной ситуацией – если запускать ACU в режиме Remote Service Mode на полной версии Windows Server 2008 R2 (с GIU), то удалённое подключение к ACU через System Management Homepageработает без проблем…

… а вот если использовать этот режим в Hyper-V Server 2008 R2 то ссылка на ACU в System Management Homepage перенаправляет нас на страницу с предупреждением о том, что на целевом сервере не доступен режим удалённого использования:

Если посмотреть код ссылки то можно увидеть что посылается запрос на получение страницы типа

https://kom-ad01-vm03:2381/ACU-XE/ACU-XE.htm

… Но такая ссылка не работает

При этом даже полное отключение брандмауэра не решает этой проблемы…

Самое интересное в этой ситуации то, что если несколько изменить ссылку до вида

https://kom-ad01-vm03:2381/ACU-XE/ACU.htm

то мы получим таки доступ к ASU…

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