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

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

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

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

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

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

Първи етап: Runspace

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

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

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

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

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

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

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

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

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

Източник: Многонишково изпълнение на PowerCLI с RunspacePool

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

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

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

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

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

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

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

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

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

Писане на скрипт за разтоварване на виртуална машина

Един ден, един мой колега ме помоли да оптимизирам неговия скрипт. Задачата беше рутинна: ​​да намеря всички виртуални машини с дублиран параметър 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 секунди при обработка на почти 10 000 виртуални машини. Бонус е липсата на филтри и необходимостта от ръчно сортиране на резултатите. Очевидно е, че скриптът се нуждае от оптимизация.

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

Включване на First Speed: 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 отнема много време.
Второ, командата 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 секунди За почти 10 000 обекта с филтриране по желано условие. Отлично!

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

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

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

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