Автоматическое развертывание Windows Failover кластеров в Azure и еще один пример неработающего публичного кода и поддержки от Microsoft


Смотри на действование Microsoft: ибо кто может выпрямить то, что Он сделал кривым? (Екк. 7:13)

Верить в наше время нельзя никому, порой даже самому себе. Мне — можно. (Старина Мюллер)

Северный пушной зверек подкрался незаметно, откуда его никто не ждал… (Работа)

Начало этой истории (которая по странному стечению обстоятельств практически совпала с другой историй про Microsoft support, о которой я писал ранее и с еще более печальной историей про бан моего курса по экзамену AZ-900 со стороны Microsoft) было драматичным… Заказчик присылает на развертывание дизайн ресурсной группы в Azure, в котором кроме всего прочего – еще и 6 Windows Failover Clusters по 2 сервака в каждом и с обычными сроками «на завтра». В принципе, все есть – ARM templates много раз деланы-переделаны, отдельные ARM template/DSC для кластеров официально опубликованы Microsoft на GitHub – https://github.com/Azure/azure-quickstart-templates/tree/master/301-storage-spaces-direct . Звоню заказчику, торгуюсь по срокам, договариваемся «на послезавтра, иншааллах». В моем отделе не принято «сетапить ручками» или сдавать заказчику непроверенные пакет ARM/DSC/PowerShell скриптов – потому день будет на тестирование «на всякий случай», хотя скрипты уже множество раз протестированы и отлажены на предыдущих деплойментах, в том числе и для этого заказчика буквально месяц назад – в общем, на 100% уверены и тестовое развертывание – это «чистая формальность»…

Ага! «Формальность»! Как же! До того момента, как следом за Microsoft с его комплектом ARM/DSC/PowerShell для развертывания кластера на GitHub не подкрался тот самый северный пушной зверек. Народ сразу взялся за дело и … смотрит на меня слегка офигевшими от прихода зверька глазами. Microsoft’овский скрипт для развертывания кластера выдает при тестовом прогоне ошибку:

“DSC Configuration \u0027ConfigS2D\u0027 completed with error(s). Following are the first few: PowerShell DSC resource MicrosoftAzure_xCluster failed to execute Set-TargetResource functionality with error message: The running command stopped because the preference variable “ErrorActionPreference” or common parameter is set to Stop: The network path was not found.\r\n The SendConfigurationApply function did not succeed. LCM failed to start desired state configuration manually.”

и деплоймент всего ARM шаблона обваливается 😦 Понятно, что «на послезавтра» сделать кластеры можно, но «ручками», а это не наш стиль – все инфраструктуры клиентов у нас хранятся в ARM/DSC/PowerShell и даже если нет полной копии сайта в Azure Site Recovery, а только бекапы – восстановление/развертывание копии инфраструктуры заказчика с наличием таких скриптов занимает от минут до нескольких часов.

И вот тут до меня начинает доходить весь круг тех проблем, которые очертил своими лапками пушной зверек, вызванный нежеланием Microsoft сопровождать и тестировать свои скрипты после очередных апдейтов (типа, мы вам их «кинули» 3 года назад и чего это вы еще недовольны?). А проблема в том, что примерно в 1/3 от всех развернутых клиентских инфраструктур у нас присутствуют кластеры и это означает, что случись сейчас что или клиенты захотят «дубликаты» – то у нас нет рабочих скриптов «быстро все повторить». В общем, «зверек» разгулялся по полной…

Быстрое изучение вопроса и поиск решения показало только то, что проблема не только у нас, но есть еще люди на просторах Интернета и даже успели опубликовать проблему в репозитории – https://github.com/Azure/azure-quickstart-templates/issues/6932 – но самое главное в данной ситуации, что никому в Microsoft проблема со скриптом на GitHub для развертывания кластера в Azure не интересна – запрос висит уже месяц и только дополнился еще одним пострадавшим… Ну не работает у людей инфраструктура в Azure – проблемы индейцев пользователей шерифа Microsoft не волнуют, Azure не требует поддержки для пользователей по мнению самого Microsoft. Кстати, и запрос к техническому специалисту в Microsoft, который привязан к конкретному заказчику «пошуршать по продуктовой команде и найти тех, кто выправит то, что сделалось кривым» – так и ушел «вникуда»… Периодически пингую «специалиста» последнюю неделю без какого-либо успеха… А что, Рождество же, Azure и проблемы могут и подождать, «ручками развернете и сконфигурите кластеры»…

Заранее предполагая такую проблему с тем, что в Microsoft об восстановлении скрипта никто и «не почешится», решил сделать запасной вариант развертывания кластеров в Azure, интегрированный в ARM template и использующий «чистый» PowerShell – разбираться, что пошло не так со сценарием DSC в «оригинальном» решении Microsoft, времени и желания не было.

Потому, пока Microsoft не пофиксит (может быть) «главный скрипт», вот вам основная идея, как автоматически развертывать кластеры в Azure через ARM с zero-touch. Да, получилось не так универсально, как в оригинале, но оно простое и понятное для всех, легко модифицируется и, главное, работает 😉

Итак, основные технические нюансы и сам код:

Первое – в Azure можно поднять только Windows Failover Cluster в режиме Storage Spaces Direct на 3 узла максимум. Кроме того, не все нагрузки поддерживаются в таком режиме в Azure, и, самое главное – цена вопроса, поскольку требуются производительные премиумные SSD диски для работы дисковой системы в режиме репликации Storage Spaces Direct в таком кластере.

Второе – чтобы развернуть кластер, необходимо, чтобы виртуальные машины, в нем участвующие, как узлы, имели частные статические IP в виртуальной сети Azure и были добавлены в единый Availability Set. ОС внутри этих ВМ должны быть добавлены в домен (кстати, если нужно только добавить ВМ в домен, то это можно сделать и непосредственно в ARM через расширение JsonADDomainExtension), на них установлены необходимые роли и службы. Это не проблема, такую работу выполняет простой PowerShell скрипт:

[CmdletBinding()]

param (

    [Parameter()]

    [string]

$domainname,

    [string]

$biosname,

    [string]

$adminname,

    [string]

$adminpwd

)

#Online the cluster’s disks

Get-Disk |  Where-Object IsOffline -eq $true | Set-Disk -IsOffline $false

#install failover clustering services and tools

Install-WindowsFeature Failover-Clustering -IncludeAllSubFeature -IncludeManagementTools

Start-Sleep -Seconds 5

Install-WindowsFeature FS-FileServer

Start-Sleep -Seconds 5

# generate domain admin’s credentials for domain join

$adminusername = “$biosname\$adminname”

$password = ConvertTo-SecureString -String $adminpwd -AsPlainText -Force

$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $adminusername, $password

Add-Computer -DomainName $domainname -Credential $cred -Restart -Force

Скрипт помещается в виде файла в какой-то Azure BLOB Storage (не забудьте разрешить анонимный доступ к объектам внутри контейнеров, хотя можно и заморочиться с атрибутам ресурса и указанием ключа доступа к этому BLOB) и запускается такой скрипт внутри VM из ARM template, как ресурс для создаваемой виртуальной машины с использованием extentions типа CustomScriptExtention, с указанием правильного пути к скрипту, который вы только что скопировали в BLOB (атрибут fileUris) и генерацией правильной командной строки (атрибут commandToExecute). Вот пример фрагмента кода именно ресурса (должен быть пристыкован к BМ) для ARM template:

“resources”: [

            {

“type”: “extensions”,

“name”: “CustomScriptExtension”,

“apiVersion”: “2017-03-30”,

“location”: “[parameters(‘location’)]”,

“dependsOn”: [

“[concat(‘Microsoft.Compute/virtualMachines/’, parameters(‘vmname1av1’))]”,

“[concat(‘Microsoft.Compute/virtualMachines/’, parameters(‘vmname2av1’))]”

              ],

“properties”: {

“publisher”: “Microsoft.Compute”,

“type”: “CustomScriptExtension”,

“typeHandlerVersion”: “1.8”,

“autoUpgradeMinorVersion”: true,

“settings”: {

“fileUris”: [

https://mystorage.blob.core.windows.net/CL/pre-setupVM.ps1”

                  ],

“commandToExecute”: “[concat(‘powershell -ExecutionPolicy Unrestricted -File pre-setupVM.ps1 -domainname ‘, parameters(‘domainname’), ‘ -biosname ‘, parameters(‘netbiosname’), ‘ -adminname ‘, parameters(‘adminUsername’), ‘ -adminpwd ‘, parameters(‘adminPassword’))]”

}

}

}

]

Еще хочу обратить внимание на формирование строки для выполнения пользовательского скрипта – начинается она с вызова powershell с правильными параметрами -ExecutionPolicy Unrestricted и указанием имени файла вашего скрипта в параметре -File.

Данный скрип будет запущен после развертывания самой виртуальной машины ARM шаблоном и сконфигурирует диски, установит нужные роли и службы в виртуальную машину, добавит ее в домен и перезагрузит.

Третье – и вот тут, после выполнения скрипта и перезагрузки каждой машины начинаются проблемы. ARM считает свою работу по запуску скриптов выполненной и, самое главное, в описание каждой из виртуальной машины в ARM template вы можете добавить только один ресурс типа extensions/CustomScriptExtension. А после перезагрузки нам нужно запустить на одном из узлов будущего кластера еще один скрипт, который сформирует кластер. Сделать это в ARM template нельзя – второй скрипт не указывается, и объяснить ARM, что после перезагрузки на машине стартует еще один скрипт и окончания его работы тоже нужно дождаться – тоже не получится… Потому – занимаемся «лайфхакингом». Если нельзя сделать внутри ARM template, это можно сделать в скрипте PowerShell, который запускает развертывание ARM template. Схематически такой скрипт выглядит следующим образом:

  1. Запускаем команду PowerShell на развертывание ARM – New-AzResourceGroupDeployment с указанием файла «большого» ARM, который развернет всю требуемую инфраструктуру и запустит на требуемых виртуалках скрипт конфигурации машины (выше);
  2. А теперь «хак» – для каждой из виртуальных машин, где уже был выполнен скрипт, запускаем команду по удалению расширения, что позволит выполнить еще одно развертывание ARM со вторым скриптом, который и сконфигурирует кластер – Remove-AzAMCustomScriptExtention . Единственное НО тут – это то, что данная команда для каждой из ВМ выполняется достаточно долго – 3-5 минут.
  3. Снова запускаем New-AzResourceGroupDeployment – на этот раз для развертывания второго шаблона ARM, в котором для каждой второй виртуальной машины (одной из пары узлов кластера) выполняется другой скрипт, как extensions/CustomScriptExtension.

Четвертое – для работы кластера требуется кворум, который для нашего варианта в Azure реализуется с использованием Cloud Witness. Для этого требуется создать Azure BLOB Storage, получить Access Key этого хранилища и использовать ключ для конфигурирования кворума кластера в режиме Cloud Witness. Потому в логике скрипта выше появляется еще один пункт 2а, где после создания инфраструктуры и сервисов (в том числе и хранилища для Cloud Witness) и удаления первых расширений, мы получаем ключи доступа для созданных хранилищ и на следующем шаге передаем их как параметр в новый ARM template – и дальше уже внутри ARM они будут переданы в вызываемый через extensions/CustomScriptExtension скрипт PowerShell для создания непосредственно кластера.

Итого, общий код PowerShell скрипта, который будет выполнять развертывание двух ARM template, с переключением extensions/CustomScriptExtension и получением ключей хранилища:

# deploy basic infrastructure from main ARM template (defined in $templateFilePath)

New-AzResourceGroupDeployment -ResourceGroupName $resourceGroupName -Mode Incremental -TemplateFile $templateFilePath -TemplateParameterObject $Params | Out-Null

# delete CustomScriptExtension from deployed VMs (names should be defined in $deployedVMs array)

foreach($vmname in $deployedvms){

Remove-AZVMCustomScriptExtension -ResourceGroupName $ResourceGroupName -VMName $vmname -Name “CustomScriptExtension” -Force | Out-Null

}

# get storage account’s key for Cluster quorum Cloud Witness and set values in $Params object for next ARM deployment

$keys = Get-AzStorageAccountKey -ResourceGroupName $ResourceGroupName -Name $Params[‘storagename1’]

$Params[‘key1’] = $keys[0].Value

# deploy second CustomScriptExtension (build the cluster) from second ARM template (defined in $templateFilePath2)

New-AzResourceGroupDeployment -ResourceGroupName $resourceGroupName -Mode Incremental -TemplateFile $templateFilePath2 -TemplateParameterObject $Params | Out-Null

Теперь дело за малым – за созданием кластера.

Сам код вызова extensions/CustomScriptExtension во втором ARM template выглядит аналогично первой части (второй скрипт тоже не забудьте поместить в правильный контейнер, как и в первом случае), единственно – в параметрах скрипта передается 2 имени узлов будущего кластера и другие его параметры:

“resources”: [

        {

“type”: “Microsoft.Compute/virtualMachines/extensions”,

“name”: “[concat(parameters(‘vmName2av1′),’/customscript’)]”,

“apiVersion”: “2015-06-15”,

“location”: “[parameters(‘location’)]”,

“properties”: {

“publisher”: “Microsoft.Compute”,

“type”: “CustomScriptExtension”,

“typeHandlerVersion”: “1.4”,

“settings”: {

“fileUris”: [

https://mystorage.blob.core.windows.net/CL/setupCluster.ps1”

                    ],

“commandToExecute”: “[concat(‘powershell -ExecutionPolicy Unrestricted -File setupCluster.ps1 -domainname ‘, parameters(‘domainname’), ‘ -biosname ‘, parameters(‘netbiosname’), ‘ -adminname ‘, parameters(‘adminUsername’), ‘ -adminpwd ‘, parameters(‘adminPassword’), ‘ -vmnames \”‘, parameters(‘vmname1av1′),’,’,parameters(‘vmname2av1’),’\” -clustername ‘, parameters(‘availabilitysetname1’), ‘ -clusterip ‘, variables(‘cluster1’), ‘ -storageaccount ‘, parameters(‘storagename1’), ‘ -storageacckey ‘, parameters(‘key1’))]”

                }

            }

        }

]

Пятое – чтобы развернуть кластер, скрипт должен выполняться с правами администратора домена, а вот CustomScriptExtension исполняет скрипт с правами ОС внутри виртуальной машины. Но скрипт PowerShell нельзя имперсонализировать в самом скрипте, но, как вариант, можно выполнить команду с правами администратора на удаленном компьютере через Invoke-Command. Т.е. запускаем скрипт через ARM template, передаем логин/пароль админа в скрипт, который создает идентити админа и вызывает команду через Invoke-Command с правами администратора.

Шестое – Windows Failover Cluster НЕЛЬЗЯ развернуть удаленно через Invoke-Command даже с правами администратора. НО, можно сконфигурировать удаленное исполнение команд Invoke-Command через аутентификацию CredSSP, которую предварительно надо настроить на обоих узлах с использованием пары перекрестных команд Enable-WSManCredSSP:

  • Для каждого из узлов включаем режим сервера Enable-WSManCredSSP Server -Force
  • Для каждого из узлов включаем доверие Enable-WSManCredSSP Client -DelegateComputer <имя второго узла> -Force

После конфигурации CredSSP для каждого узла появляется возможность использования Invoke-Command для создания кластера.

Таким образом второй скрипт PowerShell, который создает кластер, будет выглядеть следующим образом:

[CmdletBinding()]

param (

    [Parameter()]

    [string]

$domainname,

    [string]

$biosname,

    [string]

$adminname,

    [string]

$adminpwd,

    [string]

$vmnames,

    [string]

$clustername,

    [string]

$clusterip,

    [string]

$storageaccount,

    [string]

$storageacckey

)

# create domain admin credential’s object

$adminusername = “$biosname\$adminname”

$password = ConvertTo-SecureString -String $adminpwd -AsPlainText -Force

$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $adminusername, $password

#get nodes name from parameter string like “node1,node2”

$nodesArr = $vmnames -split “,”

$n1 = $nodesArr[0]

$n2 = $nodesArr[1]

#enable CredSSP authentication for admin impersonation by remote calls

#set both nodes as CredSSP’s servers

Invoke-Command $nodesArr -Credential $cred {Enable-WSManCredSSP Server -Force}

#set current node CredSSP’s client that trusts other node

Enable-WSManCredSSP Client -DelegateComputer $n1 -Force

#set other node CredSSP’s client that trusts current node

Invoke-Command $n1 -Credential $cred {Enable-WSManCredSSP Client -DelegateComputer $Using:n2 -Force}

Start-Sleep -Seconds 5

# create cluster as domain admin with one node by remote call over CredSSP

Invoke-Command $n1 -Credential $cred {New-Cluster -Name $Using:clustername -Node $Using:n1 -NoStorage -AdministrativeAccessPoint ActiveDirectoryAndDns -StaticAddress $Using:clusterip -Force} -Authentication Credssp

Start-Sleep -Seconds 30

Invoke-Command $n1 -Credential $cred {Get-Cluster $Using:clustername} -Authentication Credssp

Start-Sleep -Seconds 5

# add second node to the cluster as domain admin by remote call over CredSSP

Invoke-Command $n1 -Credential $cred {Get-Cluster -Name $Using:clustername | Add-ClusterNode -Name $Using:n2 -NoStorage} -Authentication Credssp

Start-Sleep -Seconds 30

Invoke-Command $n1 -Credential $cred {Get-Cluster $Using:clustername} -Authentication Credssp

Start-Sleep -Seconds 5

# configure cluster’s Storage Spaces Direct as domain admin by remote call over CredSSP

Invoke-Command $n1 -Credential $cred {Enable-ClusterStorageSpacesDirect -Confirm:$false} -Authentication Credssp

Start-Sleep -Seconds 30

# configure cluster’s cloud witness as domain admin by remote call over CredSSP

Invoke-Command $n1 -Credential $cred {Get-Cluster -Name $Using:clustername | Set-ClusterQuorum -CloudWitness -AccountName $Using:storageaccount -AccessKey $Using:storageacckey} -Authentication Credssp

Start-Sleep -Seconds 5

# configure cluster’s cloud witness as domain admin by remote call over CredSSP

Invoke-Command $n1 -Credential $cred {Get-StoragePool S2D* | New-Volume -FriendlyName Data -FileSystem CSVFS_ReFS -UseMaximumSize} -Authentication Credssp

Вот и все готово… Получилось, как я уже писал выше – куда более лаконично, нежели нагромождение кода DSC у Microsoft (который и обвалился в результате), более понятно и читаемо (хотя да, есть некоторые «странности», но это опять таки – вопросы к МС с его Invoke-Command и ограничениями для extensions/CustomScriptExtension) и, главное – оно работает, в отличие от «элитарного» кода Microsoft.

Сейчас держим про запас 2 набора файлов IaC для наших заказчиков с кластерами в Azure – один с «классическим» и нерабочим сейчас кодом Microsoft для создания кластеров через ARM/DSC – в надежде, что Microsoft таки читает запросы на разрешение проблем и хоть как-то сопровождает свой код, и второй – вот данный момент рабочий и приведенный выше.

Я уже писал про компетенцию и поддержку своих продуктов со стороны Microsoft – этот случай из той же оперы, причем тут Microsoft явно забил на свой публично опубликованный код (типа, а вот сопровождать не обещали). Так что, как сказано в предисловии к посту – верить никому нельзя и мы таки попытались выправить то, что Microsoft сделал кривым.

И да, если Microsoft не в состоянии поддерживать документацию, код и вообще – оказывать качественный саппорт – может, им стоит прислушаться к тому совету, который мне написали в комментариях к предыдущему моему посту (хотя Microsoft пошел простым путем – находит тех, кто делает это бесплатно за непонятные и совершенно эфимерные плюшки статуса MVP, который еще и довольно таки “подозрителен”, как я уже писал ранее):

Игорь, привет. По поводу твоего свежего поста – совет: предложить им сделать аналог Bug Bounty/Marketplace: за чужой хороший код и документацию платить премии.

Друге посты и видео по теме Azure и ИТ-карьеры:

SysAdmin vs DevOps–что разного и что общего–будущее системных администраторов на примере автоматизации развертывания и конфигурирования VM в Azure–Infrastructure as Code и инструменты DevOps, которыми сисадмин должен будет владеть в ближайшем будущем


DevOps – одно из модных сейчас «поветрий» (наряду с «data scientist» и прочими «IoT» и «AI»), адепты которого активно продвигают мысль, что «все ИТ будет devops» – в прогрессивной ИТ-среде не останется системных (и прочих) администраторов, их таки заменят DevOps. НО, самое интересное, что даже внутри крупных ИТ корпораций, которым тренд «DevOps» приносит большие прибыли, нет единого мнения о судьбе в современных ИТ-инфраструктурах тех позиций, которые в общем называли «ИТ-профессионалы» («ТЫЖПРОГРАММИСТ!» – «нет, я администратор сети и безопасности») и которые в реальности к «Dev» вообще не прикасаются, а управляемые ими инфраструктуры настолько статичны, что их «Ops» не меняются годами и выполняются рутинно (я это называю «ребята нашли свой карман безделья»).

NoDevOpsПотому, в данной презентации со Стального Бубна 2018 во Львове, посвященной концепции Infrastructure as Code (IaC) для системных администраторов и архитекторов ИТ-инфраструктуры, я попытался (как оказалось, даже 1,5 часа очень и очень мало, чтобы рассказать и показать самые базовые концепции) сравнить те задачи, которые решают DevOps и SysAdmin, что у них отличного и, главное, что есть общего в работе и DevOps, и SysAdmin – какие современные тенденции на рынке управления ИТ-инфраструктурами позволяют использовать общий инструментарий и общие подходы в работе SysAdmin и DevOps. И все это, конечно же, на примере облачных технологий, связанных с Microsoft Azure.

Начнем, пожалуй, с того момента, что важность и потребность в позиции «DevOps» достаточно сильно «культивирована» теми компаниями, которые, собственно, продают инструменты для работы DevOps или компаниями-аутсорсерами, где DevOps – производственная необходимость в рабочем процессе с постоянным «выкатыванием» новых сборок ввиду забажености кода, производимого гребцами галер. Да и, собственно, сейчас какие только позиции и обязанности не называют красивым именем «DevOps». В реальности ситуация с DevOps примерно такая же, как с той картинкой про айсберг – DevOps сейчас – одна из самых «видимых» позиция в ИТ-индустрии, не считая девелоперов (потому что их раньше не было, точнее – не придумали еще такое слово, и технологии были «пожиже», а теперь они срочно нужны каждому уважающему себя аутсорсеру), а основное управление ИТ-инфраструктурой «обычных» компаний по прежнему лежит на плечах обычных таких системных администраторов, которые работают себе с этой самой инфраструктурой «по старинке». Я лично, и моя компания как раз оказывает услуги таким вот «обычным» компаниям и сейчас в тренде – это миграция части ИТ инфраструктуры в облака с последующим обновлением (читай – rebuild до архитектуры, близкой к требованиям PaaS) некоторых LoB решений компании или же – использование облачных сервисов типа Azure Backup или Azure Site Recovery для реализации более эффективного резервного копирования или защиты от сбоев. И у меня накопилась достаточно большая и релевантная статистика отношения руководителей (CIO, CEO) к концепции DevOps для работы с их ИТ-инфраструктурой.

Но перед тем, как продолжить тему Infrastructure as Codeрекомендую познакомиться с моим докладом на предыдущем Стальном Бубне, который подробно рассказывает, что бывает, когда DevOps используют (или они берутся сами за работу) не по прямому назначению – как архитекторы и администраторы ИТ-инфраструктуры обычной компании с ее обычными сервисами + немного облаков.


Steel Drum/Стальной Бубен – доклад по реализации проектов Azure Site Recovery или DevOps vs SysAdmin

Также смотрите и читайте другие материалы для ИТ-профессионалов у меня на канале iWalker2000 и блоге:

 

Итак, вернемся к отзывам обычных компаний про место DevOps и соответствующих процессов в их ИТ-инфраструктуре (комментарии собирательные, но некоторой – очень близко к тексту):

  • У нас нет разработки, у нас стабильная инфраструктура, которая нуждается в базовых рутинных операциях.
  • Мы планируем перенос инфраструктуры в облако, верно, но это будут реплики наших виртуальных машин или базовые сервисы.
  • Скрипты? Извините, но мои люди получают заплату за то, чтобы работали сервисы.
  • У нас рутинные операции, если надо – есть RDP/TeamViewer и прочие инструменты админа.
  • DevOps – это какие-то аутсорсеры, которых мы наняли для написания приложений, они работают в своей песочнице и инфраструктуры это не касается.

Как мы видим, с точки зрения руководителей ИТ в компаниях, которые «просто эксплуатируют ИТ, как часть производственного процесса» – места для DevOps в таких компаниях нет, а позиции системных администраторов прочны, как никогда. И таких компаний, для которых ПК или мобильные устройства всего лишь средство обработки производственной информации – большинство. Так что, стоит ли сисадминам почивать на лаврах?

Текущие тенденции в экономике и бизнесе – говорят, что нет… Хотя бы потому, что все идет, как обычно – нужно дешевле, быстрее и на вчера. В том числе – и в управлении ИТ-инфраструктурой. Быстрее развертывать новые сервисы, восстанавливать старые, подключать быстрее и больше пользователей и выдавать им данные на их запрос как можно оперативнее, а лучше всего – дать пользователю кнопку «сделать весь отчет/презентацию/работу за меня» 😉 И да! – Еще и параноидальная безопасность во всем + новое красивое слово GDPR (под которое можно подвести любые требования).

И, самое главное – компаниям упорно продают облака… Мировые гиганты в ИТ вкладывают в этот сегмент громадные деньги, в том числе и на маркетинг, что приводит к тому, что любой CIO задумывается над вопросом «а зачем мне облака?» и даже если не задумывается – ему обязательно напомнит его CEO вопросом типа «а что у нас там с облаками? Мне тут рассказали, что это на 30% эффективнее нашей текущей системы». Нет, я ничего против облаков не имею, и даже сам придумаю 10-15-20 причин, почему облака лучше локальной инфраструктуры – я просто озвучиваю тенденции и текущий момент раздумий CIO.

В результате сейчас сложилась ситуация, которая довольно патовая и для руководства ИТ-инфраструктур, и для сисадминов, и даже для тех самых корпораций, которые «пропихивают» массы в облака. Почему? Да потому что сейчас как бы существует 2 мира ИТ-инфраструктур, в одном из которых есть серверы с их консолями, традиционные системы и процедуры управления (от тех самых компаний, которые и «за облака»), а во втором – есть облака с совершенно другой концепцией управления, вроде как изначально заточенной под девелоперов и DevOps (что не принимается CIO/сисадминами – смотри выше) и в которые надо поместить путем «взяли и переставили» существующие серверы с нестыкующейся моделью управления внутри. И основные проблемы тут:

  • Традиционные модели управления устаревают ввиду новых облачных технологий и требований,
  • Очень много ручной работы и модификаций + еще один уровень абстракции в виде облака,
  • Ручное тестирование современной инфраструктуры требует больших затрат в целом и слушком затратно по времени,
  • Административные привилегии предоставляются без детализации задачи, ограничений по времени,
  • Операционные команды не накапливают опыт в виде готовой документации и повторяемых конфигураций – метод next-next-next этого не позволяет 😉

Потому общую тенденцию в изменении требований к управлению «обычной» ИТ-инфраструктуры «обычными» системными администраторами можно озвучить, как:

НОВЫЕ ПОДХОДЫ К УПРАВЛЕНИЮ ИТ ИНФРАСТРУКТУРОЙ ТРЕБУЕТ БОЛЕЕ ТОЧНЫХ, АВТОМАТИЗИРОВАНЫХ ПРОЦЕССОВ С ОБШИРНЫМИ ВОЗМОЖНОСТЯМИ ПО ДЕКЛАРАТИВНОМ ОПИСАНИЮ, ПОВТОРЕНИЮ И МАСШТАБИРОВАНИЮ, НЕЖЕЛИ СЕЙЧАС.

Как будут выглядеть ИТ-инфраструктуры будущего даже в «обычных» компаниях, которые соответствуют указанным требованиям и какой будет работа системного администратора, управляющего такой ИТ-инфраструктурой? – Правильно, как уже знакомое для DevOps понятие Infrastructure as Code со всеми вытекающими отсюда свойствами и возможностями:

  • Инфраструктура определяется как набор декларативных описаний объектов…
  • Которые сохраняются в конфигурационных файлах…
  • Точно описывающих установку отдельного сервера или всего окружения…
  • С «идемпотентностью» (вот же слово придумали) …
  • С автоматизацией конфигурирования и рутинных операций…
  • С сохранением ИТ администраторских навыков и инструментов…
  • + внедрения процедур, применяемых в разработке ПО – Source/Build/Test/Release

Что изменится в результате распространения концепции Infrastructure as Code для системных администраторов не только в облачных ИТ-инфраструктурах, но и в их локальных сетях и любимых продуктах, а также в самих процедурах работы с ИТ-инфраструктурой в средних и крупных компаниях?

  • Распространение концепции декларативной Infrastructure as Code на локальные инфраструктуры (например, с распространением Azure Stack),
  • Перенос большинства сервисов управления и мониторинга в облака (уже сейчас активно развиваются облачные Microsoft Intune и Operations Management Suite) с применением к ним возможностей управления через конфигурацию,
  • Автоматизация работы облачных, гибридных и локальных с использованием облачных сервисов типа Azure Automation и гибридных runbook,
  • Постепенный дрифт AD в сторону Azure AD + Desire State Configuration (DSC), который придет на замену привычных групповых политик (учим DSC уже сейчас),
  • Повышение требований Business Continuity / Disaster Recovery и, как результат, более активное использование в компаниях таких средств, как Azure Backup и Azure Site Recovery – готовой песочницы для того, чтобы при крупной катастрофе локальной инфраструктуры компания «рывком» оказалась в облаках (и вы даже не представляете, какая будет паника у ИТ после этого!),
  • Иметь 2-3 параллельные идентичные инфраструктуры будет нормой – что позволит быстро вводить в эксплуатацию новые решения или реагировать на катастрофы,
  • И да, концепт на то, что в нынешних условиях дешевле все с нуля пересобрать, развернуть или переключить несколько слотов развертывания с использованием декларативных шаблонов, описанных выше – чтобы быстро обеспечить бизнесу работу служб – а после искать ошибки, которые привели к сбоям или остановке предыдущей,
  • Изменяются процедуры и сам стиль работы ИТ отделов – «админ» поправил файл конфигурации, собрал, затестил, зарелизил в автоматизированной системе (даже, возможно, с тестовым развертыванием в свободный слот) – и шеф нажал кнопку деплоймента в продакшен. Все это – с версионностью, трекингом изменений конфигураций, мониторингом событий и возможностью повторить операцию бесконечное количество раз даже на уже работающей инфраструктуре без потери ее работоспособности (та самая «идемпотентность»).

Итак, перспективы развития облачных, гибридных и даже локальных ИТ-инфраструктур и подходов управления ими в ближайшие годы понятны. Что делать системному администратору, который осознал, что его умение создать, настроить виртуальную машину и установить внутрь нее ОС с настройкой ролей этой ОС и даже детальных отдельных сервисов, типа вебсайта – скоро окажется невостребованным по причине замены этих навыков новыми инструментами? Есть много ответов на этот вопрос, например – «уйти из ИТ», или «переквалифицироваться в DevOps», или «в бьюти-/тревел-блогеры» (ага, это троллинг самого себя, у автора достаточно большое количество видео, посвященных путешествиям – «Путевые Заметки Игоря Шаститко» – http://bit.ly/iwalker2000_travels1 ), или «просто развиваться и постараться взглянуть на способы администрирования ИТ-инфраструктур под другим углом». И изучать новые технологии и инструменты управления, которые уже есть на рынке, и которые используют те же DevOps (так что, если хотите в DevOps – учиться придется еще больше и тому же). А именно:

  • Шаблоны описания конфигураций – Azure Resource Manager templates (ARM, доступен и в локальных облаках Azure Stack),
  • Средства развертывания инфраструктур из шаблонов и просто скриптами – портал Azure, Azure PowerShell, Azure CLI, VS, GitHub,
  • Средства контроля конфигураций – Desire State Configuration (DSC) – и не только в базовых сценариях, но и в сочетании с теми же шаблонами ARM,
  • Облачные средства автоматизации и мониторинга – такие, как Azure Automation, Hybrid Runbook Workers, Operations Management Suite и прочие реакции на события и т.п.,
  • Средства управления исходным кодом шаблонов, скриптов развертывания, runbook, DSC, с интеграцией Azure с GitHub и прочими решениями,
  • Средства управления процессом разработки ИТ-инфраструктуры с подходом Infrastructure as Code – Source/Build/Test/Release – с применением тех же облачных сервисов Visual Studio Team Services и т.п.

И, после такой вводной части – рекомендую все же посмотреть полную запись моего выступления на конференции «Стальной Бубен» во Львове в мае 2018 – «Автоматизация развертывания и конфигурирования VM в IaaS Azure – взгляд со стороны админа, а не DevOps» – кроме, собственно, слайдов системные администраторы найдут в этом видео примеры использования всех перечисленных технологий и инструментов. Да, как я уже писал, я немного просчитался со временем, к сожалению, опыт показал, что для подобной презентации с демо потребуется минимум в 3 раза больше времени, потому я планирую включить все эти демо в запланированную на своем канале серию, посвященную работе системного администратора с Microsoft Azure, а уже опубликованные серии, где рассматривается применение Azure со стороны системных администраторов, найдете здесь – https://youtu.be/MEjC_GityKc


Steel Drum/Стальной Бубен – Infrastructure as Code – автоматизация развертывания VM в Azure 

Выводы? Для системных администраторов – они не утешительные – «учиться, учиться и еще раз учиться» – вас ждет «большая ломка» – методов, инструментов, и собственно, того, чем вы будете управлять. Потому – всех действительно заинтересованных ожидает очень интересная дорога вперед, перед которой вы должны понять несколько простых истин из будущего (которые я вкратце постарался осветить в данном видео):

  • Все «артефакты» Infrastructure as Сode, описывающие даже самые сложные инфраструктуры компаний – простые текстовые файлы, как и исходный код у девелоперов!
  • «Админы инфраструктуры» медленно переползают в «разработчиков инфраструктуры» (писателей ARM шаблонов и скриптов runbook на PowerShell)…
  • «Админы рабочих мест/серверов» в «разработчиков конфигураций» (писателей DSC и, снова же – скриптов PowerShell)…
  • Инфраструктурный и конфигурационный код может быть сохранен, версионизирован, протестирован и распространен, как и программный код – у вашей инфраструктуры вскоре появятся свои сборки, свои релизы, и свои тестовые и разрабатываемые копии в отдельных «слотах».
  • И да поможет вам <тут фрагмент политкорректности> в вашем постижении новой мудрости и желании перерасти свой консерватизм с RDP и кликами next-next-next!!!

Это не единственный семинар, который я читал в Украине, в ближайшее время еще одно интересное мероприятие для сисадминов пройдет в Харькове, 13 июня 2018 всех интересующихся приглашаю сюда – SysAdmin Day.Kharkiv 2018 – https://www.facebook.com/SysAdminDayUA/ (предварительная регистрация обязательна). И, конечно же, следите за выпусками технических видео на канале – http://bit.ly/WindowsServer_overview .

 

Первые серии нового курса по использованию Azure IaaS и обо всем том, где будет рассмотрено подробно все то, о чем я говорил в данной презентации:

 

Видео об ИТ-карьере – как стать ИТ-специалистом и заработать много денег:

Немного ссылок на другие материалы для тех, кто хочет стать просто ИТ-специалистом – смотрите первые шаги по созданию тестового рабочего места:

И смотрите другие видео для ИТ-специалистов у меня на канале:

Видео про новые возможности дисков и дисковых массивов:

 

Подписывайтесь на мой Youtube канал iWalker2000 – для подписки просто кликните сюда

 

Также, по просьбам посетителей – меня найти можно (добавляйтесь в друзья и подписчики):

 

Эмиграция для ИТ-профессионалов в Европу! Оформление ВНЖ в Словакии, возможность работы со всеми странами ЕС, открытие фирм, ЧП с соответствующими видами деятельности, оформление документов для членов семьи. Быстро, качественно, дешево и абсолютно легально ВНЖ в Словакии. www.slovakiago.com
Не упустите свой шанс жить и работать в Евросоюзе!