пятница, 15 июня 2018 г.

Запуск первого 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 надо начинать сначала полностью, насколько я понял, из-за того, что где-то на уровне ПО железа идёт хардкод, а также имя региона включается в сертификаты);
  • Утилита проверки сертификатов НЕ ПРОВЕРЯЕТ КОРРЕКТНОСТЬ НАИМЕНОВАНИЯ РЕГИОНА;

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




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













вторник, 29 мая 2018 г.

Относительно недавно столкнулись с проблемой, когда узел 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 мм в конце ската, при свозе можно тряхнуть стойку. Придерживайте её, чтобы избежать удара.


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








вторник, 6 марта 2018 г.

Диск в статусе 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:

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

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

вторник, 27 февраля 2018 г.

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

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

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

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



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



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





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


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


Разбираем .tar


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


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


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


«Detected»!






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

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

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


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

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



среда, 7 февраля 2018 г.

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 в очередной раз и запускаем резервное копирование.

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

четверг, 1 февраля 2018 г.

Первые сравнительные данные производительности 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