Запуск первого Azure Stack в России (First Azure Stack in Russia launch) - день 2-й и 3-й

Примечание: я использую условные обозначения вида "2-й день" или "3-й день", чтобы выделить некоторые реперные точки запуска. Между этими точками могут быть перерывы в 1 - 3 дня, в зависимости от возникающих событий, к примеру: длительность установки обновлений, возникающие инциденты и т.д.

Привет, всем. 

Итак, день 2-ой.

Опишу вкраце, т.к. никаких сверхъестественных вещей не происходило.
После установки стойки начался относительно долгий процесс обновления firmware, драйверов и прочего ПО серверов, HLH узла и т.д. Это заняло пару дней, т.к. в процессе установки обновлений возникла проблема с одним из узлов виртуализации.

Примечание: проблема решилась перезаливкой конфигурационного профиля сервера и перепрошивкой устройства.

Процесс нудный, но нужный - без него нам не видать стабильной работы S2D и других подсистем.

День 3-й.

Самый важный день - запуск непосредственно инсталляции Azure Stack. Мы решили обосноваться со Святославом (Delivery consultant, HPE) в московском офисе HP для упрощения коммуникации в рамках запуска.

Поскольку CDW (Excel файл, из которого формируется конфигурационный файл ответов для установки AzS) был заранее сформирован на фабрике, как и предполагает процесс развёртывания AzS, нам оставалось выполнить некоторые предварительные проверки, скачать необходимые обновления AzS и подложить сертификаты в соотвествующие папки для инсталляции.

Примечание: процесс установки Azure Stack включает в себя несколько активностей, которые происходят ещё до того, как сама стойка приедет к Вам на площадку. Примерно за 2 недели до начала работ по установке (в случае с HPE), delivery consultant приглашает Вас на встречу, где вы подтверждаете правильность информации, указанной в CDW, отвечаете на ключевые вопросы по предварительной подготовке площадки (к примеру: обеспечена ли связанность с Интернет, проверяются диапазоны IPv4 адресов (внутренних и внешних), BGP ASN и маршрутизация, названия регионов, свойства и наличие сертификатов и т.д.). 

Внимание: конфигурационный файл ответов CDW формируется на фабрике. Имейте в виду, что при некорректном его заполнении, консультанту необходимо будет выслать исправленный файл на завод для ре-генерации (это может повлечь за собой изменение и других настроек, к примеру: сетевых ACL через формирование новых конфигурационных файлов для активного оборудования). Иногда этот процесс может затянуться до 2-х недель (насколько я понял, это некий reply SLA). 

Примечание: хочу отметить, что изменение файла руками может привести к проблемам с установкой лекарство от которой - полный re-deployment. Также, учитывайте, что ToR коммутаторы и ПО AzS имеет много настроенных сетевых ACL и правил сетевых экранов (включая компоненты SDN) - изменение руками сетевых настроек задача крайне нетривиальная и требующая погружения в дебри. В случае Вашей ошибки,  вы можете снизить надёжность и безопасность решения, а также повысить возможность взлома извне.

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

• все файлы ответов находятся на своих местах;
• все аппаратные компоненты не содержат ошибок;
• все системы обновлены до крайней стабильной версии;
• файл-образ ОС Azure stack лежит в правильной папке;
• сертификаты созданы правильно и проходят проверку с помощью специальной утилиты;
• сертификаты размещены в соответствующих папках для каждого сервиса;
• всё учётные данные, включая учётные записи Windows Azure корректны;

От себя дам несколько советов:

• Внимательно прочтите инструкции к CDW "HPE ProLiant for MS Azure Stack CDW - Read First", "Azure Stack Deployment Companion Guide-customer", "HPE Azure Stack CDW and Planning Guide" - это сохранит Вам нервы и средства;
• Перед AzS рекомендуется устанавливать Firewall для защиты элементов управления (порталов, точек публикации и т.д.) - это требует дополнительных денег; Нужно это потому, что все трафики идут в одной трубе; также, установка межсетевого экрана позволит избежать ситуации, когда в случае ошибки конфигурации, допущенной кем-либо (производитель, инженер поддержки вендора) - вы окажетесь с решением, торчащим дырой в интернет;
• Предварительная проверка сертификатов проводится на любом ПК Windows 10/Windows Server 2016 вне Azure Stack - Вам необходимо заиметь такой ПК и настроить соответствующим образом (инструкции даст консультант);
• Обязательно проверьте, что не вышло новых критических обновлений, когда вы подошли к моменту запуска скрипта установки - это может спасти от многих дальнейших проблем;
• Некоторые обновления могут быть доступны только через внутренние  ресурсы производителя аппаратного обеспечения или Microsoft - скачайте их дополнительно и скопируйте их на хост HLH для последующей установки (к примеру: с помощью USB девайса; шаг выполняется инженером производителя аппаратного обеспечения);
• Если Вы хотите упростить работы - скачайте все обновления на USB, установите USB накопитель в HLH хост до конца установки;
• При установке обновлений прошивок серверов и драйверов лучше иметь в наличии Remote Hands при удалённой работе, либо обеспечьте себе место в ЦОД;
• Возможность использовать для копирования RDP сессию может отсутствовать из-за технических ограничений безопасности, как вариант - используйте Device Mount в iLO для доставки съемных носителей на HLH;
• документы по установке AzS неcтатичны - они могут очень быстро меняться, нужно всегда иметь актуальную версию (к примеру: к моменту выхода на установку Microsoft и HPE отменили использование DVM (deployment VM)) при запуске скрипта установки - теперь с HLH;
• ДВАЖДЫ ПРОВЕРЬТЕ корректность наименования региона и другие параметры (если вы укажете некорректное имя региона - deployment надо начинать сначала полностью, насколько я понял, из-за того, что где-то на уровне ПО железа идёт хардкод, а также имя региона включается в сертификаты);
• Утилита проверки сертификатов НЕ ПРОВЕРЯЕТ КОРРЕКТНОСТЬ НАИМЕНОВАНИЯ РЕГИОНА;

Перед запуском скрипта установки необходимо выполнить подготовку 

Ну и волнительный момент :)

Относительно недавно столкнулись с проблемой, когда узел Network Controller оказался в состоянии "Database corruption". База сервис фабрики перестала реплицироваться с партнерами и сервиса NC не запускались. Стоит отметить, что 2 два других узла работали штатно.

1. попытка запуска нового экземпляра базы

 2. присоединяемся к базе

3. Собственно проблема

и далее следовала остановка экземпляра.

Пока мы решали кейс, Network Controller, спустя некоторое время - 1,5 месяца (не всё зависит от Microsoft), решил, что: "ну его в баню, пересоздам ка я базу". Собственно после событий на скриншотах ниже узел Network Controller вернулся к жизни.

После создания нового экземпляра базы, как в предыдущем примере, узел NC перевёл её в "обслуживание".

и далее проблема ушла.

Также, есть возможность форсировать этот момент с помощью команды:

Remove-ServiceFabricReplica -ReplicaOrInstanceId 131535831061893748 -PartitionId 886a4647-7202-49e0-8084-a39e1e149b57 -NodeName MSK***

Замените значения, выполненные курсивом на присутствующие в Вашей инфраструктуре.

Примечание: ситуация ненормальная, но после самоустранения проблемы решено было не копать БД NC (экономия часов MPS). Хорошо, что механизм саморазрешения таких проблем есть. 

Запуск первого Azure Stack в России (First Azure Stack in Russia launch) - день 1-й

Привет, в данном блоге я буду делиться информацией о процессе запуска первого Azure Stack на территории России, в ЦОД облачного провайдера #CloudMTC. В нашем случае разговор идёт об Azure Stack на базе HPE.

Приехал к нам этот чудо-зверь в полностью собранном виде, как на фото ниже (AzS 12 nodes, Single region). 

Весом это чудо почти в тонну (~800 кг), имейте в виду, что понадобится 2 - 3 человека, чтобы было комфортно работать при перемещении этой истории.

В комплекте предусмотрены даже специальные салазки для своза стойки с евро-палеты с забавной инструкцией на коробке.

Внутренняя начинка стойки хорошо скомпонована, в целом, не вызывает вопросов.

Для тех, кто будет приземлять подобное решение у себя в ЦОД: обратите внимание на кол-во груш питания - их 4-ре штуки (в данной конфигурации присутствуют 4 PDU, в которые собраны блоки розеток). 

Примечание: каждое PDU позволяет получить до 32 А максимум, судя по цифрам потребления электричества, указанным на блоках питания серверов/коммутаторов - решение имеет явный перезаклад по PDU (почему? пока не ясно).

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

Ниже пара фотографий о том, как стойку скатывали с евро-палеты.

Предварительно стойку необходимо было открутить от поддона (она закреплена намертво с 4-х сторон).

Сама стойка имеет шасси для перемещения внутри ЦОД.

Затем, монтировались вот такие вот салазки, с помощью которых мы сняли стойку с евро-палеты.

И да, венец решения в век космических технологий :) Бруски в виде рёбер жесткости :)

Примечание: несмотря на наличие салазок, скатывать стойку надо аккуратно, т.к. салазки имеют толщину около 5 - 7 мм в конце ската, при свозе можно тряхнуть стойку. Придерживайте её, чтобы избежать удара.

 И наконец, эпичный момент:

Диск в статусе Detached в Storage Spaces Direct

Существует несколько случаев, когда мы наблюдали диск в статусе "Detached" в Storage Spaces Direct.

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

...

один из CSV дисков отказывался монтироваться и постоянно улетал в "Failed".

Что было предпринято:

1.       Были запущены выключенные узлы кластера.

2.       Я дождался пока пройдут все Repair Jobs.

3.       Я менял координатор для диска HDD.

4.       Я отключал и снова включал пул.

5.       Я вывел в паузу 5 нод и ребутнул их. Шестую ноду не дожидаясь тоже отправил в перезагрузку.

Это всё не помогло. После перезагрузки всех серверов и окончания Repair Jobs ситуация не поменялась.

Диск был попеременно то в состоянии "Degraded" (когда он пытался монтироваться) то в состоянии "Detached".

В кластерных логах относящихся к этому диску наблюдались следующие ошибки:

На ноде координаторе данного диска были следующие ошибки ReFS:

Что сделано:

PowerShell:

Remove-ClusterSharedVolume -name "Cluster Virtual Disk (S2D-HDD-06)"

Get-ClusterResource -Name "Cluster Virtual Disk (S2D-HDD-06)" | Set-ClusterParameter -Name DiskRunChkDsk -Value 7

Start-ClusterResource -Name "Cluster Virtual Disk (S2D-HDD-06)"

Диск сразу перешёл в состояние InService:

Для него пошла Repair Job:

Диск виделся в кластере как Available Storage:

PowerShell:

Get-ClusterResource -Name "Cluster Virtual Disk (S2D-HDD-06)" | Set-ClusterParameter -Name DiskRunChkDsk -Value 0

Add-ClusterSharedVolume -Name "Cluster Virtual Disk (S2D-HDD-06)"

Get-VirtualDisk

Диск отобразился как “Cluster Shared Volume”

 

Продолжали идти Repair Jobs:

Виртуальные машины запустились:

Статья которая мне помогла:

http://jtpedersen.com/index.php/2016/11/23/troubleshooting-failed-virtualdisk-on-a-storage-spaces-direct-cluster/

Сборка нового шаблона ВМ для Debian 9.3 и CentOS 7.4 или сказ о том, как слоны и карри могут украсть два выходных

Немного забавная история про то, как мой коллега Дмитрий С. обновлял шаблоны *nix ВМ в облаке.

В попытках создать шаблон с Debian 9.3 я провёл умотаться сколько времени.

Ни одна дока с просторов не привела меня к успеху.

VMM агент «успешно» устанавливался внутрь виртуальной машины. Но VMM считал иначе:

Что-то не так…

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

Что мы видим? Этот идиот пытается стучаться по несуществующему пути:

/etc/dhcp3/ – вот эта лишняя «3» портит нам всю жизнь.

 

Разбираем .tar

Правим конфигу руками.

Собираем .tar обратно.

Ставим агента VMM из исправленного пакета.

«Detected»!

Отлично… первая проблема решена.

Теперь решаем проблему с тем, что при кастомизации развёртывания из шаблона, она доходит только до 99%

Здесь мне помогла вот эта статья:

https://blogs.msdn.microsoft.com/virtual_pc_guy/2015/02/11/copying-the-vhd-of-a-generation-2-linux-vmand-not-booting-afterwards/

А если точнее, то первый комментарий под ней.

Удалось добиться завершения кастомизации виртуальной машины.

DPM 2016 Stories :) #2: Резервное копирование SCCM 2016, с помощью, SCDPM 2016 заканчивается ошибкой

Disclaimer: я благодарен за эту информацию, своему коллеге-другу Сергею Т., который взял на себя бремя обеспечения инфраструктуры РК на базе DPM 2016. Оригинал текста слегка модифицирую, чтобы сделать более читабельным.

Сценарий

Пытаемся сделать резервную копию сервера ConfigMgr Stand-alone Primary Site  Config_Mgr_Name (базы данных установлены отдельно), как виртуальную машину с кластера.

Завершалось все ошибкой:

Affected area:  RCT\Config_Mgr_Name

Occurred since:                1/24/2018 8:40:11 AM

Description:       The replica of Microsoft Hyper-V RCT\Config_Mgr_Name on SCVMM Config_Mgr_Name Resources. Cluster_Name is inconsistent with the protected data source. All protection activities for data source will fail until the replica is synchronized with consistency check. You can recover data from existing recovery points, but new recovery points cannot be created until the replica is consistent.

For SharePoint farm, recovery points will continue getting created with the databases that are consistent. To backup inconsistent databases, run a consistency check on the farm. (ID 3106)

                An unexpected error occurred while the job was running. (ID 104 Details: Unknown error (0x80041069) (0x80041069))

Date inactivated:             1/24/2018 9:03:00 AM

Recommended action: No action is required because this alert is inactive.

Короче DPM говорит, что не может и отвалите от него.

В VMM - тишина.

На хосте, где размещается ВМ, нашел ошибки:

Раз:

'Config_Mgr_Name' failed to perform the operation. The virtual machine is not in a valid state to perform the operation. (Virtual machine ID 872B50C5-AE1F-4486-A37A-B3A719F4DB52)

Два:

The Hyper-V Virtual Machine Management service encountered an unexpected error: Catastrophic failure (0x8000FFFF).

Три:

The description for Event ID 3280 from source Microsoft-Windows-Hyper-V-Worker cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

Config_Mgr_Name

872B50C5-AE1F-4486-A37A-B3A719F4DB52

%%2147943860

0x800705B4

The locale specific resource for the desired message is not present

Четыре:

Checkpoint operation for 'Config_Mgr_Name' failed. (Virtual machine ID 872B50C5-AE1F-4486-A37A-B3A719F4DB52)

Явная отсылка к чекпойнтам в последнем сообщении. 

Поэтому решил проверить создание снепшота вручную из консоли VMM. И опять печаль:

Error (12700)
VMM cannot complete the host operation on the 'host_name' server because of the error:
Unknown error (0x8004)

Recommended Action
Resolve the host issue and then try the operation again.

Катаем виртуалку между хостами – не помогает.

Выключаем ВМ. 

Создание снапшота на выключенной виртуальной машине завершается успешно.

Бэкапить только выключенную виртуалку – моветон. Копаем глубже.

Создание Standard Checkpoint вместо стандартного режима по умолчанию ProductionChekpoint (Ответственность за каламбур лежит на MS) завершается успешно.

Переключаемся на него и стартуем задание DPM. 

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

Осознаем, что что-то не так в гостевой ОС Config_Mgr_Name и это надо решать.

Лезем смотреть ошибки на Config_Mgr_Name

VSS providers и writers в порядке.

Находим ошибку в Event Viewer:

Cryptographic Services failed while processing the OnIdentity() call in the System Writer Object.

Details:

AddLegacyDriverFiles: Unable to back up image of binary Microsoft Link-Layer Discovery Protocol.

System Error:

Access is denied.

.

И предупреждение:

A provider, SMSDPProvider, has been registered in the Windows Management Instrumentation namespace root\SCCMDP to use the LocalSystem account. This account is privileged and the provider may cause a security violation if it does not correctly impersonate user requests.

Исправляем ошибку вот такой страшной командой в CMD из-под администратора:

sc sdset MSLLDP D:(D;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BG)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO)(A;;LCRPWP;;;S-1-5-80-3141615172-2057878085-1754447212-2405740020-3916490453)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

Пробуем – не работает по-прежнему, но ошибка пропала. Грустим.

Лезем в консоль Configuration Manager и проверяем компоненты (ну есть же предупреждение про SMSDPProvider)

Находим, что компонент SMS_HIERARCHY_MANAGER превысил свои лимиты на ошибки и ушел в Critical.

Лезем в сообщения об ошибках и находим:

Hierarchy Monitoring detected that the Database File Disk (P:\) is running out of space.

Осознаем, что на SCCM нет диска P:, перечитываем сообщения и лезем на кластер SQL серверов.

Находим, что диск P: - это как раз диск базы данных SCCM, и на нем свободно чуть меньше 2 GB, то есть около 20%. Но мы же не первый раз с MS дружим.

Увеличиваем диск до 20GB. 

Сбрасываем счетчики в ConfigMgr, перезагружаем Config_Mgr_Name в очередной раз и запускаем резервное копирование.

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

Первые сравнительные данные производительности VM, после установки обновления от уязвимостей Spectre и Meltdown в облаке 3H Cloud

Мы получили первые сравнительные данные по производительности доступных Заказчикам конфигураций ВМ нашего облака, после того, как мы установили патчи от DELL и Microsoft в нашей инфраструктуре.

Патчи призваны исправить проблемы, описанные в бюллетенях безопасности CVE-2017-5753, CVE-2017-5715, CVE-2017-575.

Как видно из таблицы ниже, падение составило от 12 - 3100 MIPs на VM, в зависимости от её класса (кол-ва vCPU и ОЗУ).
Однако, при тестировании с помощью 7-Zip benchmark погрешность может составлять +\-  1000 (в некоторых тестах, приходилось переделывать). 

Условия тестирования

Значения тестов являются примерными. Для тестов использовалась виртуальная машина с операционной системой Windows Server 2016 Datacenter x64 GUI ENG., помещённая на свободный Hyper-V узел с двумя процессорами Intel Xeon E5-2698 v4 2.2 GHz с 20 физическими ядрами каждый, и тест 7-zip benchmark, версии 17.01 beta (x64). Результаты тестов могут иметь погрешность «Total Rating» +/- 1000 MIPS; размер словаря 32 Mb.

Сравнительные результаты тестирования производительности vCPU до и после обновлений

Имя класса	Total Rating		Total Rating/Usage
	До обновления	После обновления	До обновления	После обновления
A0	3159 MIPS	3147 MIPS	3207 MIPS	3224 MIPS
A0v1	3260 MIPS	3217 MIPS	3255 MIPS	3222 MIPS
A1	6539 MIPS	6367 MIPS	3546 MIPS	3525 MIPS
A2	3297 MIPS	3247 MIPS	3297 MIPS	3247 MIPS
A3	6507 MIPS	6465 MIPS	3548 MIPS	3538 MIPS
A4	12810 MIPS	12363 MIPS	3554 MIPS	3441 MIPS
A5	12810 MIPS	12348 MIPS	3483 MIPS	3397 MIPS
A6	12810 MIPS	12545 MIPS	3483 MIPS	3470 MIPS
B0	6507 MIPS	6458 MIPS	3548 MIPS	3530 MIPS
B1	12810 MIPS	12581 MIPS	3554 MIPS	3471 MIPS
B2	12810 MIPS	12600 MIPS	3483 MIPS	3453 MIPS
B3	12810 MIPS	12528 MIPS	3483 MIPS	3468 MIPS
B4	12810 MIPS	12527 MIPS	3483 MIPS	3459 MIPS
C0	12810 MIPS	12600 MIPS	3508 MIPS	3504 MIPS
C1	23668 MIPS	24511 MIPS	3388 MIPS	3356 MIPS
C2	36365 MIPS	34706 MIPS	3301 MIPS	3240 MIPS
C3	46929 MIPS	45792 MIPS	3236 MIPS	3182 MIPS
C4	45610 MIPS	44793 MIPS	3223 MIPS	3115 MIPS
С5	53389 MIPS	52172 MIPS	2776 MIPS	2729 MIPS
C6	63376 MIPS	61629 MIPS	2344 MIPS	2320 MIPS
D0	24981 MIPS	24327 MIPS	3408 MIPS	3333 MIPS
D0v1	24218 MIPS	24388 MIPS	3267 MIPS	3371 MIPS
D0v2	18652 MIPS	18681 MIPS	3269 MIPS	3415 MIPS
D1	36274 MIPS	35435 MIPS	3313 MIPS	3258 MIPS
D2	46469 MIPS	45658 MIPS	3168 MIPS	3148 MIPS
D3	52405 MIPS	52777 MIPS	2829 MIPS	2743 MIPS
D4	52232 MIPS	51621 MIPS	2810 MIPS	2707 MIPS
D5	62103 MIPS	61356 MIPS	2367 MIPS	2306 MIPS
H0	24250 MIPS	24454 MIPS	3279 MIPS	3340 MIPS
H1	24347 MIPS	24293 MIPS	3404 MIPS	3324 MIPS
H2	35490 MIPS	34758 MIPS	3325 MIPS	3232 MIPS
H3	46763 MIPS	44773 MIPS	3224 MIPS	3142 MIPS
H4	54402 MIPS	52378 MIPS	2799 MIPS	2727 MIPS
H5	64113 MIPS	61027 MIPS	2354 MIPS	2272 MIPS

Имейте в виду, что тест 7-zip зависит от соотношения кол-ва vCPU и RAM на борту ВМ.

Выводы
Критического снижения производительности не произошло для гостевых ОС. 
Storage Spaces Direct, также, не потеряли в производительности.
SDN (NC,SLB/MUX,RSGW) продолжают работать нормально. Дальше мы будет устанавливать на них январское обновление.

В дальнейшем мы планируем провести тестирование одного узла виртуализации с 20,30,40 и 50 ВМ на узел, для проверки выводов тестирования при увеличенной нагрузке.

Ниже приведена конфигурация ВМ, доступных в облаке.

Имя класса	vCPU	RAM (GB)
A0	1	1
A0v1	1	2
A1	2	2
A2	1	4
A3	2	4
A4	4	4
A5	4	8
A6	4	10
B0	2	4
B1	4	4
B2	4	8
B3	4	8
B4	4	10
C0	4	12
C1	8	16
C2	12	16
C3	16	24
C4	16	32
С5	24	32
C6	32	32
D0	8	32
D0v1	8	40
D0v2	6	40
D1	12	32
D2	16	32
D3	24	48
D4	24	64
D5	32	64
H0	8	16