понедельник, 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.

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

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




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