Как да изградите ракетен ускорител за PowerCLI скриптове 

Рано или късно всеки системен администратор на VMware започва да автоматизира рутинни задачи. Всичко започва с командния ред, след това идва PowerShell или VMware PowerCLI.

Да приемем, че сте усвоили PowerShell малко повече от стартирането на ISE и използването на стандартни кратки команди от модули, които работят поради „някаква магия“. Когато започнете да броите виртуални машини в стотици, ще откриете, че скриптовете, които помагат в малък мащаб, работят значително по-бавно в голям мащаб. 

В тази ситуация ще ви помогнат 2 инструмента:

• PowerShell Runspaces – подход, който ви позволява да паралелизирате изпълнението на процеси в отделни нишки; 
• Get-View – базова PowerCLI функция, аналог на Get-WMIObject в Windows. Тази кратка команда не изтегля обекти, придружаващи обекти, но получава информация под формата на прост обект с прости типове данни. В много случаи излиза по-бързо.

След това ще говоря накратко за всеки инструмент и ще покажа примери за употреба. Нека анализираме конкретни скриптове и да видим кога единият работи по-добре от другия. Отивам!

Първи етап: Runspace

И така, Runspace е предназначен за паралелна обработка на задачи извън основния модул. Разбира се, можете да стартирате друг процес, който ще изяде малко памет, процесор и т.н. Ако вашият скрипт се изпълнява за няколко минути и консумира гигабайт памет, най-вероятно няма да имате нужда от Runspace. Но за скриптове за десетки хиляди обекти е необходимо.

Можете да започнете да учите тук: 
Начало на използването на PowerShell Runspaces: Част 1

Какво дава използването на Runspace:

• скорост чрез ограничаване на списъка с изпълнени команди,
• паралелно изпълнение на задачи,
• сигурност.

Ето пример от Интернет, когато Runspace помага:

„Състезанието за съхранение е един от най-трудните показатели за проследяване във vSphere. Във vCenter не можете просто да отидете и да видите коя VM консумира повече ресурси за съхранение. За щастие можете да съберете тези данни за минути благодарение на PowerShell.
Ще споделя скрипт, който ще позволи на системните администратори на VMware бързо да търсят във vCenter и да получат списък с виртуални машини с данни за тяхното средно потребление.  
Скриптът използва пространства за изпълнение на PowerShell, за да позволи на всеки ESXi хост да събира информация за потреблението от собствените си виртуални машини в отделно пространство за изпълнение и незабавно да докладва завършването. Това позволява на PowerShell да затваря незабавно задания, вместо да преминава през хостове и да чака всеки да изпълни заявката си.

Източник: Как да покажете I/O на виртуална машина на табло за управление на ESXi

В случая по-долу Runspace вече не е полезен:

„Опитвам се да напиша скрипт, който събира много данни от VM и записва нови данни, когато е необходимо. Проблемът е, че има доста VM и на една машина се изразходват 5-8 секунди. 

Източник: Многонишков PowerCLI с RunspacePool

Тук ще ви трябва Get-View, нека да преминем към него. 

Втори етап: Get-View

За да разберете защо Get-View е полезен, струва си да си припомните как работят командлетите като цяло. 

Кратки команди са необходими за удобно получаване на информация, без да е необходимо да изучавате справочници за API и да преоткривате следващото колело. Това, което в старите дни отнемаше сто или два реда код, PowerShell ви позволява да правите с една команда. Ние плащаме за това удобство с бързина. В самите командлети няма магия: същият скрипт, но на по-ниско ниво, написан от умелите ръце на майстор от слънчева Индия.

Сега, за сравнение с Get-View, нека вземем cmdlet Get-VM: той осъществява достъп до виртуалната машина и връща съставен обект, тоест прикачва други свързани обекти към него: VMHost, Datastore и т.н.  

Get-View на негово място не добавя нищо ненужно към върнатия обект. Освен това ни позволява стриктно да посочим каква информация ни е необходима, което ще улесни изходния обект. В Windows Server като цяло и в Hyper-V в частност cmdlet Get-WMIObject е директен аналог - идеята е абсолютно същата.

Get-View е неудобен за рутинни операции върху точкови обекти. Но когато става въпрос за хиляди и десетки хиляди предмети, това няма цена.

Можете да прочетете повече в блога на VMware: Въведение в Get-View

Сега ще ви покажа всичко с помощта на истински случай. 

Писане на скрипт за разтоварване на VM

Един ден мой колега ме помоли да оптимизирам неговия скрипт. Задачата е обичайна рутина: намерете всички виртуални машини с дублиран параметър cloud.uuid (да, това е възможно при клониране на виртуална машина във vCloud Director). 

Очевидното решение, което идва на ум е:

1. Вземете списък с всички виртуални машини.
2. Анализирайте списъка по някакъв начин.

Оригиналната версия беше този прост скрипт:

function Get-CloudUUID1 {
   # Получаем список всех ВМ
   $vms = Get-VM
   $report = @()

   # Обрабатываем каждый объект, получая из него только 2 свойства: Имя ВМ и Cloud UUID.
   # Заносим данные в новый PS-объект с полями VM и UUID
   foreach ($vm in $vms)
   {
       $table = "" | select VM,UUID

       $table.VM = $vm.name
       $table.UUID = ($vm | Get-AdvancedSetting -Name cloud.uuid).Value
          
       $report += $table
   }
# Возвращаем все объекты
   $report
}
# Далее РУКАМИ парсим полученный результат

Всичко е изключително просто и ясно. Може да се напише за няколко минути с кафе пауза. Завийте филтрацията и готово.

Но нека измерим времето:

2 минути 47 секунди при обработка на почти 10k VM. Бонус е липсата на филтри и необходимостта от ръчно сортиране на резултатите. Очевидно скриптът изисква оптимизация.

Runspaces са първите, които идват на помощ, когато трябва едновременно да получите метрики на хост от vCenter или трябва да обработите десетки хиляди обекти. Нека да видим какво носи този подход.

Включете първата скорост: PowerShell Runspaces

Първото нещо, което идва на ум за този скрипт, е да изпълни цикъла не последователно, а в паралелни нишки, да събере всички данни в един обект и да го филтрира. 

Но има проблем: PowerCLI няма да ни позволи да отворим много независими сесии към vCenter и ще изведе забавна грешка:

You have modified the global:DefaultVIServer and global:DefaultVIServers system variables. This is not allowed. Please reset them to $null and reconnect to the vSphere server.

За да разрешите това, първо трябва да подадете информация за сесията вътре в потока. Нека си припомним, че PowerShell работи с обекти, които могат да бъдат предадени като параметър към функция или към ScriptBlock. Нека предадем сесията под формата на такъв обект, заобикаляйки $global:DefaultVIServers (Connect-VIServer с ключ -NotDefault):

$ConnectionString = @()
foreach ($vCenter in $vCenters)
   {
       try {
           $ConnectionString += Connect-VIServer -Server $vCenter -Credential $Credential -NotDefault -AllLinked -Force -ErrorAction stop -WarningAction SilentlyContinue -ErrorVariable er
       }
       catch {
           if ($er.Message -like "*not part of a linked mode*")
           {
               try {
                   $ConnectionString += Connect-VIServer -Server $vCenter -Credential $Credential -NotDefault -Force -ErrorAction stop -WarningAction SilentlyContinue -ErrorVariable er
               }
               catch {
                   throw $_
               }
              
           }
           else {
               throw $_
           }
       }
   }

Сега нека внедрим многопоточност чрез Runspace Pools.  

Алгоритъмът е следният:

1. Получаваме списък с всички виртуални машини.
2. В паралелни потоци получаваме cloud.uuid.
3. Събираме данни от потоци в един обект.
4. Ние филтрираме обекта, като го групираме по стойността на полето CloudUUID: тези, където броят на уникалните стойности е по-голям от 1, са виртуалните машини, които търсим.

В резултат на това получаваме скрипта:

function Get-VMCloudUUID {
   param (
       [string[]]
       [ValidateNotNullOrEmpty()]
       $vCenters = @(),
       [int]$MaxThreads,
       [System.Management.Automation.PSCredential]
       [System.Management.Automation.Credential()]
       $Credential
   )

   $ConnectionString = @()

   # Создаем объект с сессионным ключом
   foreach ($vCenter in $vCenters)
   {
       try {
           $ConnectionString += Connect-VIServer -Server $vCenter -Credential $Credential -NotDefault -AllLinked -Force -ErrorAction stop -WarningAction SilentlyContinue -ErrorVariable er
       }
       catch {
           if ($er.Message -like "*not part of a linked mode*")
           {
               try {
                   $ConnectionString += Connect-VIServer -Server $vCenter -Credential $Credential -NotDefault -Force -ErrorAction stop -WarningAction SilentlyContinue -ErrorVariable er
               }
               catch {
                   throw $_
               }
              
           }
           else {
               throw $_
           }
       }
   }

   # Получаем список всех ВМ
   $Global:AllVMs = Get-VM -Server $ConnectionString

   # Поехали!
   $ISS = [system.management.automation.runspaces.initialsessionstate]::CreateDefault()
   $RunspacePool = [runspacefactory]::CreateRunspacePool(1, $MaxThreads, $ISS, $Host)
   $RunspacePool.ApartmentState = "MTA"
   $RunspacePool.Open()
   $Jobs = @()

# ScriptBlock с магией!)))
# Именно он будет выполняться в потоке
   $scriptblock = {
       Param (
       $ConnectionString,
       $VM
       )

       $Data = $VM | Get-AdvancedSetting -Name Cloud.uuid -Server $ConnectionString | Select-Object @{N="VMName";E={$_.Entity.Name}},@{N="CloudUUID";E={$_.Value}},@{N="PowerState";E={$_.Entity.PowerState}}

       return $Data
   }
# Генерируем потоки

   foreach($VM in $AllVMs)
   {
       $PowershellThread = [PowerShell]::Create()
# Добавляем скрипт
       $null = $PowershellThread.AddScript($scriptblock)
# И объекты, которые передадим в качестве параметров скрипту
       $null = $PowershellThread.AddArgument($ConnectionString)
       $null = $PowershellThread.AddArgument($VM)
       $PowershellThread.RunspacePool = $RunspacePool
       $Handle = $PowershellThread.BeginInvoke()
       $Job = "" | Select-Object Handle, Thread, object
       $Job.Handle = $Handle
       $Job.Thread = $PowershellThread
       $Job.Object = $VM.ToString()
       $Jobs += $Job
   }

# Ставим градусник, чтобы наглядно отслеживать выполнение заданий
# И здесь же прибиваем отработавшие задания
   While (@($Jobs | Where-Object {$_.Handle -ne $Null}).count -gt 0)
   {
       $Remaining = "$($($Jobs | Where-Object {$_.Handle.IsCompleted -eq $False}).object)"

       If ($Remaining.Length -gt 60) {
           $Remaining = $Remaining.Substring(0,60) + "..."
       }

       Write-Progress -Activity "Waiting for Jobs - $($MaxThreads - $($RunspacePool.GetAvailableRunspaces())) of $MaxThreads threads running" -PercentComplete (($Jobs.count - $($($Jobs | Where-Object {$_.Handle.IsCompleted -eq $False}).count)) / $Jobs.Count * 100) -Status "$(@($($Jobs | Where-Object {$_.Handle.IsCompleted -eq $False})).count) remaining - $remaining"

       ForEach ($Job in $($Jobs | Where-Object {$_.Handle.IsCompleted -eq $True})){
           $Job.Thread.EndInvoke($Job.Handle)     
           $Job.Thread.Dispose()
           $Job.Thread = $Null
           $Job.Handle = $Null
       }
   }

   $RunspacePool.Close() | Out-Null
   $RunspacePool.Dispose() | Out-Null
}


function Get-CloudUUID2
{
   [CmdletBinding()]
   param(
   [string[]]
   [ValidateNotNullOrEmpty()]
   $vCenters = @(),
   [int]$MaxThreads = 50,
   [System.Management.Automation.PSCredential]
   [System.Management.Automation.Credential()]
   $Credential)

   if(!$Credential)
   {
       $Credential = Get-Credential -Message "Please enter vCenter credentials."
   }

   # Вызов функции Get-VMCloudUUID, где мы распараллеливаем операцию
   $AllCloudVMs = Get-VMCloudUUID -vCenters $vCenters -MaxThreads $MaxThreads -Credential $Credential
   $Result = $AllCloudVMs | Sort-Object Value | Group-Object -Property CloudUUID | Where-Object -FilterScript {$_.Count -gt 1} | Select-Object -ExpandProperty Group
   $Result
}

Красотата на този скрипт е, че може да се използва в други подобни случаи, като просто замените ScriptBlock и параметрите, които ще бъдат предадени на потока. Експлоатирайте го!

Ние измерваме времето:

55 секунди. По-добре е, но все още може да бъде по-бързо. 

Да преминем към втората скорост: GetView

Нека разберем какво не е наред.
Първо и най-важно, Get-VM cmdlet отнема много време за изпълнение.
Второ, завършването на кратката команда Get-AdvancedOptions отнема още повече време.
Нека първо се справим с второто. 

Get-AdvancedOptions е удобен за отделни VM обекти, но е много тромав при работа с много обекти. Можем да получим същата информация от самия обект на виртуална машина (Get-VM). Той просто е заровен добре в обекта ExtensionData. Въоръжени с филтриране, ние ускоряваме процеса на получаване на необходимите данни.

С леко движение на ръката това е:

VM | Get-AdvancedSetting -Name Cloud.uuid -Server $ConnectionString | Select-Object @{N="VMName";E={$_.Entity.Name}},@{N="CloudUUID";E={$_.Value}},@{N="PowerState";E={$_.Entity.PowerState}}

Превръща се в това:

$VM | Where-Object {($_.ExtensionData.Config.ExtraConfig | Where-Object {$_.key -eq "cloud.uuid"}).Value -ne $null} | Select-Object @{N="VMName";E={$_.Name}},@{N="CloudUUID";E={($_.ExtensionData.Config.ExtraConfig | Where-Object {$_.key -eq "cloud.uuid"}).Value}},@{N="PowerState";E={$_.summary.runtime.powerstate}}

Резултатът е същият като Get-AdvancedOptions, но работи многократно по-бързо. 

Сега към Get-VM. Не е бърз, защото се занимава със сложни обекти. Възниква логичен въпрос: защо се нуждаем от допълнителна информация и чудовищен PSObject в този случай, когато имаме нужда само от името на виртуалната машина, нейното състояние и стойността на един хитър атрибут?  

В допълнение, препятствието под формата на Get-AdvancedOptions е премахнато от скрипта. Използването на Runspace Pools сега изглежда като излишно, тъй като вече няма нужда да паралелизирате бавна задача в нишки на клек, когато предавате сесия. Инструментът е добър, но не е за този случай. 

Нека да разгледаме изхода на ExtensionData: това не е нищо повече от Get-View обект. 

Нека използваме древната техника на майсторите на PowerShell: един ред с помощта на филтри, сортиране и групиране. Целият предишен ужас е елегантно свит в един ред и изпълнен в една сесия:

$AllVMs = Get-View -viewtype VirtualMachine -Property Name,Config.ExtraConfig,summary.runtime.powerstate | Where-Object {($_.Config.ExtraConfig | Where-Object {$_.key -eq "cloud.uuid"}).Value -ne $null} | Select-Object @{N="VMName";E={$_.Name}},@{N="CloudUUID";E={($_.Config.ExtraConfig | Where-Object {$_.key -eq "cloud.uuid"}).Value}},@{N="PowerState";E={$_.summary.runtime.powerstate}} | Sort-Object CloudUUID | Group-Object -Property CloudUUID | Where-Object -FilterScript {$_.Count -gt 1} | Select-Object -ExpandProperty Group

Ние измерваме времето:

9 секунди за почти 10k обекта с филтриране по желаното състояние. Страхотен!

Вместо заключение

Приемливият резултат директно зависи от избора на инструмент. Често е трудно да се каже със сигурност какво точно трябва да се избере, за да се постигне това. Всеки от изброените методи за ускоряване на скриптове е добър в рамките на своята приложимост. Надявам се, че тази статия ще ви помогне в трудната задача да разберете основите на автоматизацията на процесите и оптимизацията във вашата инфраструктура.

PS: Авторът благодари на всички членове на общността за тяхната помощ и подкрепа при подготовката на статията. Дори тези с лапи. И дори тези, които нямат крака, като боа констриктор.

Източник: www.habr.com