вторник, 21 мая 2019 г.

Проблема с режимом обслуживания Azure Stack c обновления 1901

В обновлении 1901, при выводе узла из режима обслуживания, портал администратора сообщает о том, что узел готов к работе.

Однако, в этот момент, вероятно прохождение заданий по восстановлению целостности хранилища.

Microsoft принципиально изменил работу режима обслуживания, запущеного из портала администратора: добавили полную блокировку хранилища узла при помещении его в режим обслуживания. Что раньше, выглядело по другому.

Также, отмечено, что в более ранних версиях, если узел не был перезагружен StorageJob не генерировались в таком объеме.

Как итог: портал может ввести в заблуждение оператора, сообщив о том, что узел готов к работе и в случае перевода другого узла в режим обслуживания может возникнуть ситуация перехода отдельных томов S2D в режим read-only из-за отсутствия достаточного кол-ва копий данных для отдельных ресурсов (если остается 1, то в режим чтения).

Важно! В официальной документации Microsoft по Azure Stack этот момент не обнаружен.

Вывод
Необходимо каждый раз наблюдать за StorageJob и контролировать их завершение, перед выполнением других действий.

Контроль может осуществляться с помощью способов, описанных ниже

• Одиночные команды, выполняемая на PEP без разбития стекла (может понадобиться выполнить несколько раз).
Для проверки выполнения заданий хранилища использовать Get-VirtualDisk -cimsession s-cluster | Get-StorageJob
Затем для проверки восстановления виртуальных дисков использовать Get-VirtualDisk -cimsession s-cluster 

• Второй способ - это запуск скрипта, приведённого ниже, выводящего статус заданий хранилища по временному интервалу.

Важно! Увеличение кол-ва запросов к WMI, обслуживающему вызовы PowerShell к S2D, путём уменьшения тайм-аута, может привести к проблемам с S2D.

Заметка: требуется разбить стекло для работы со скриптом



while(1)
{
cls
$a = $b
Write-Host "OLD DATA" -ForegroundColor Gray
Write-Host $datetime -ForegroundColor Gray
Write-host "--------------------" -ForegroundColor Gray
$a | Out-String
$b = Get-VirtualDisk -CimSession s-cluster | Get-StorageJob
$datetime = Get-Date
Write-Host "New DATA" -ForegroundColor Yellow
Write-Host "--------------------" -ForegroundColor Yellow
Write-Host $datetime -ForegroundColor White
Write-Host "-------------------------" -ForegroundColor Yellow
$b | Out-String
start-sleep -seconds 300 
}


Далее, после окончания заданий надо выполнить Get-VirtualDisk -cimsession s-cluster 

Возможно индикация готовности узла к работе и S2D на  портале будет исправлена позже.

воскресенье, 17 марта 2019 г.

Replacing motherboard on Azure Stack Compute Node

Привет, столкнулся очень с интересной историей:
не всегда field engineer производителя аппаратного обеспечения имеет понимание о том, что находится внутри Azure Stack (какое ПО и как оно работает). Необходимо чётко контролировать выполнение им рекомендация Microsoft, т.к. Action Plan, которой такой инженер пытается выполнить может содержать ошибки.

Это я к тому, что после замены материнской платы  в вычислительном узле необходимо выполнить Repair этого узла и никак иначе (более того это написано в документации Microsoft, в. отличии от AP инженера).

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

Достаточно было выполнить repair узла, это нивелировало  ошибки NcHostAgent, SLBHostAgent, также, это добавило информацию об узле в вывод Get-AzureStackStampInformation.

Узел добавляется в кластер в процессе Repair.

Единственное, что вызывало вопрос: ошибка ниже, вызванная контроллером.





   Severity: Critical
 

Reason         : Communication has been lost to the AzS-Node04, Enclosure #: PDNNF0ARHA70L1, HP, P840.

Recommendation : Start or replace the storage enclosure.

Location       : AzS-Node04, Enclosure #: PDNNF0ARHA70L1, HP, P840

Description    : Enclosure #: PDNNF0ARHA70L1, HP, P840



При этом S2D чувствовали себя нормально, все виртуальные диски были здоровы.
Проблема возникла из-за "зависшей" информации в службе здоровья кластера S2D.

После перезапуска - проблема решилась.






четверг, 21 февраля 2019 г.

Ошибка развёртывания через ARM template "AddressSpace of the virtual network /subscriptions/<>/resourceGroups/mydemo-rg/providers/Microsoft.Network/virtualNetworks/<> does not have any address prefixes in addressPrefixes array.

Столкнулся с ошибкой ниже...(нажми, чтобы увидеть :)) 




Если коротко, то
"message": "AddressSpace of the virtual network /subscriptions/ae87f7d8-d62f-47ac-a00c-aae6edb3acda/resourceGroups/mydemo-rg/providers/Microsoft.Network/virtualNetworks/core-rg-network does not have any address prefixes in addressPrefixes array.


НО в шаблоне было указано всё правильно.
Перечитал и передумал всё, что можно и нельзя, а потом в NotePad++ проверил скобки.
Данная ошибка появляется, если в шаблоне, в разделе ниже  (см. картинку) нет  скобок [].
 

 



Проспал...внимательнее читаем код...



понедельник, 18 февраля 2019 г.

Как дать права только на чтение co-administrator в тенанте Заказчика Azure Stack

Ответ - никак.


Администраторы (Операторы) Azure Stack  со стороны провайдера не могут это сделать.


Выполняется данная операция Заказчиком самостоятельно.
Для этого необходимо выполнить серию простых шагов в тенанте Заказчика в Microsoft Azure и затем в IAM (Identity Access Management) Azure Stack.




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


Затем выполняем вход в наш тенант на Azure Stack с правами "Owner" на существующую подписку.
Переходим "Subscriptions" - "SubscrptionID" - "IAM" и делаем действия, показанные на картинке ниже. 




далее, выполняем тестовый вход в тенант Azure Stack  с желаемой учетной записью, с правами  Read-Only и проверяем желаемое.




На этом все.

Нюансы обновлений Azure Stack

В одной из предыдущих записей я упоминал ECE (Enterprise Cloud Engine).

 
Данный сервис, на текущий момент, крутиться на ERSC виртуальных машинах, которые имеют относительно небольшой объём ОЗУ (~8Gb) и vCPU.

 
Для тех кто не знает - поясняю:
ERSC решают несколько задач:
  • это и Privilege Endpoint (PEP); 
  • и обработка ECE,  который передаёт информацию на портал и с него в недра Azure Stack и т.д.;

 
В чём, собственно, соль.

 
Каждая открытая сессия портала и запросы с него или сессия на PEP обрабатываются ERSC. Все эти активности выедают и без того небольшой объём памяти и процессорной мощности, выделенных на ВМ.

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

 
Проблема в том, что при таком раскладе, работа ECE может нарушаться, что приводит к проблемам при обновлении.


Вывод и рекомендация от производителя: при проведении процесса обновлений необходимо выполнять выход из всех открытых сессий к интерфейсам администратора.


Ниже вы найдёте рекомендации для OpsMgr по перенастройки мониторов.
Кстати, наличие OpsMgr тоже может приводить к проблемам с обновлениями, т.к. он будет постоянно дёргать доступные ему интерфейсы с высокой  частотой.


Настройте следующие мониторы на момент обновления, как описано ниже:


Microsoft Azure Stack Update Run 

  • Availability 
    • Microsoft Azure Stack Update Run State Monitor 
  • Microsoft Azure Stack Update 
    • Availability 
      • Microsoft Azure Stack Update State Monitor 
    • Discovered Type: Microsoft Azure Stack Update Run 
      • Microsoft Azure Stack Update Run Discovery 


     Interval override value to 3600. 


     
    Продуктовая команда, по слухам, собирается доработать код ECE, чтобы снизить кол-во таких проблем в будущем.

    суббота, 2 февраля 2019 г.

    Узел Azure Stack пропадает из консоли при переводе/выводе из режима обслуживания.

    Помещая узел Azs-node04 в режим обслуживания я вдруг обнаружил его исчезновение в консоли, чем был крайне озадачен. Решил воспользоваться открытой сессией на PEP, чтобы понять, что происходит - сбой или нет.


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















    Через 5 - 10 минут ожидания узле отобразился в консоли в статусе "в обслуживании".


    Я подозреваю, что проблема заключается в так называемом Enterprise Cloud Engine (ECE). Это компонент, который работает (в текущей реализации) на ERSC виртуальных машинах, и отвечает за связь внутренней сервисной фабрики и консоли администратора Azure Stack. Судя по всему, процесс - не моментальный сам по себе, но при наличии нагрузки на ERSC может тормозить.










    Azure Stack all nodes stuck in adding state

    Столкнулся со странной проблемой:

    После того, как я вернул узел в кластер из режима обслуживания - все остальные узлы Azure Stack  ушли в статус "adding". Сказать, что я остался спокойным, не ударился в панику и не удивился - нельзя.




    Тем не менее, stamp  продолжал работать. Test-AzureStack показывал "PASS" для всех пунктов, но инцидент в поддержке я всё же открыл.

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

    Короче говоря, после перезапуска Service Fabric нехитрым скриптом и смены Primary узла - всё вернулось на круги своя.

    Stamp Version: 1.1809.90




    Короткое дополнение: за некоторое время до этого OpsMgr,  также, отображал 3 узла в статусе "Adding" и я думал, что проблема на его стороне, однако после перезапуска XRP и смены владельца Primary роли - все сообщения закрылись. Нюанс, OpsMgr  упорно информировал о таком статусе на 3-х узлах, а не на всех....







    пятница, 1 февраля 2019 г.

    Draft TypeHandlerVersion issue

    Как-то столкнулся с проблемой при создании Virtual Machine Scale Set через PowerShell на Azure Stack   (v.1808), содержащего CustomScriptExtension.
    После формировании переменной, содержащей целевую конфигурацию, не получалась запустить  процесс командой:


     Update-AzureRmVmss -ResourceGroupName $vmssrg -VirtualMachineScaleSet $targetvmss -VMScaleSetName $targetvmss.name -verbose

    , выпадала ошибка:


    VERBOSE: Performing the operation "Update" on target "myvmss02".


    Update-AzureRmVmss : The value of parameter typeHandlerVersion is invalid.


    ErrorCode: InvalidParameter

    ErrorMessage: The value of parameter typeHandlerVersion is invalid.

    StatusCode: 400

    ReasonPhrase: Bad Request

    OperationID : 57e66af6-a75e-4093-846e-b6f95fc52aab

    At line:1 char:2

    + Update-AzureRmVmss -ResourceGroupName $vmssrg -VirtualMachineScaleSe ...

    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo : NotSpecified: (:) [Update-AzureRmVmss], ComputeCloudException

    + FullyQualifiedErrorId : Microsoft.Azure.Commands.Compute.Common.ComputeCloudException,Microsoft.Azure.Commands.Compute.Automation.UpdateAzureRmVmss 


    Проблема заключалась в понимании того, что должно содержаться в поле "TypeHandlerVersion". Дело в том, что при получении данных об образе CustomScriptExtension поле TypeHandlerVersion содержит 3 цифры (1.9.1), но сам параметр принимает только основную версию "1.9", а минорную версию указывать отдельно (как показано в примере ниже)


    $targetvmss = Add-AzureRmVmssExtension -VirtualMachineScaleSet $targetvmss -Name "CustomScriptExtension" -Publisher "Microsoft.Compute" -Setting $customConfig -Type "CustomScriptExtension" -TypeHandlerVersion "1.9" -AutoUpgradeMinorVersion $True


    $targetvmss.VirtualMachineProfile.ExtensionProfile.Extensions[0].ForceUpdateTag="1"

    В этом случае, проблема не возникает.


    OpsMgr 2016 Azure Stack bugs or features #1 :)

    Сегодня поймал дежавю с сообщениями в OpsMgr.

    Если честно, сначала не понял почему ибо: все апдейты были успешно установлены и почему, в том числе для старых версий.

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

    Вероятно для объектов Runtime (длинный ID ниже), срабатывает триггер обнаружения сбойной попытки обновления.
    Думаю, неплохо бы добавить в пакет управления проверку на наличие успешной попытки и поднять уведомление об ошибке, только если такой попытки не существует для каждого отдельно взятого обновления.



    Пока исправления для МР я делать не стал (может сообщество допилит и времени нет), проще решить проблему переопределениями для конкретных объектов Runtime.