четверг, 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.