როგორ ავაშენოთ რაკეტის გამაძლიერებელი PowerCLI სკრიპტებისთვის 

ადრე თუ გვიან, ნებისმიერი VMware სისტემის ადმინისტრატორი მოდის რუტინული ამოცანების ავტომატიზაციისთვის. ეს ყველაფერი იწყება ბრძანების ხაზით, შემდეგ მოდის PowerShell ან VMware PowerCLI.

ვთქვათ, თქვენ დაეუფლეთ PowerShell-ს ცოტა უფრო შორს, ვიდრე ISE-ის გაშვება და სტანდარტული cmdlet-ების გამოყენება მოდულებიდან, რომლებიც მუშაობენ „რაღაც მაგიის“ გამო. როდესაც ვირტუალური მანქანების ასობით დათვლას დაიწყებთ, აღმოაჩენთ, რომ სკრიპტები, რომლებიც ხელს უწყობენ მცირე მასშტაბებს, შესამჩნევად ნელა მუშაობს დიდი მასშტაბით. 

ამ სიტუაციაში 2 ინსტრუმენტი დაგეხმარებათ:

• PowerShell Runspaces – მიდგომა, რომელიც საშუალებას გაძლევთ პარალელურად მოახდინოთ პროცესების შესრულება ცალკეულ ძაფებში; 
• Get-View – ძირითადი PowerCLI ფუნქცია, Get-WMIObject-ის ანალოგი Windows-ში. ეს cmdlet არ იზიდავს თანმხლებ ობიექტებს, მაგრამ იღებს ინფორმაციას მარტივი ობიექტის სახით მონაცემთა მარტივი ტიპებით. ხშირ შემთხვევაში უფრო სწრაფად გამოდის.

შემდეგ, მოკლედ ვისაუბრებ თითოეულ ხელსაწყოზე და ვაჩვენებ გამოყენების მაგალითებს. მოდით გავაანალიზოთ კონკრეტული სკრიპტები და ვნახოთ, როდის მუშაობს ერთი მეორეზე უკეთესი. წადი!

პირველი ეტაპი: Runspace

ასე რომ, Runspace განკუთვნილია ძირითადი მოდულის გარეთ ამოცანების პარალელური დამუშავებისთვის. რა თქმა უნდა, შეგიძლიათ დაიწყოთ სხვა პროცესი, რომელიც შეჭამს გარკვეულ მეხსიერებას, პროცესორს და ა.შ. თუ თქვენი სკრიპტი რამდენიმე წუთში იმუშავებს და მოიხმარს მეხსიერების ერთ გიგაბაიტს, სავარაუდოდ Runspace არ დაგჭირდებათ. მაგრამ ათიათასობით ობიექტის სკრიპტებისთვის ეს საჭიროა.

შეგიძლიათ დაიწყოთ სწავლა აქ: 
PowerShell Runspaces-ის გამოყენების დასაწყისი: ნაწილი 1

რას იძლევა Runspace-ის გამოყენება:

• სიჩქარე შესრულებული ბრძანებების სიის შეზღუდვით,
• დავალებების პარალელურად შესრულება,
• უსაფრთხოება.

აქ არის მაგალითი ინტერნეტიდან, როდესაც Runspace ეხმარება:

”საცავის წინააღმდეგობა არის vSphere-ში თვალყურის დევნება ერთ-ერთი ყველაზე რთული მეტრიკა. vCenter-ის შიგნით, თქვენ არ შეგიძლიათ უბრალოდ შეხვიდეთ და ნახოთ რომელი VM მოიხმარს მეტ შენახვის რესურსს. საბედნიეროდ, თქვენ შეგიძლიათ შეაგროვოთ ეს მონაცემები წუთებში PowerShell-ის წყალობით.
მე გავაზიარებ სკრიპტს, რომელიც VMware სისტემის ადმინისტრატორებს საშუალებას მისცემს სწრაფად მოძებნონ vCenter-ში და მიიღონ VM-ების სია მათი საშუალო მოხმარების მონაცემებით.  
სკრიპტი იყენებს PowerShell-ის პერსპექტივებს, რათა თითოეულ ESXi ჰოსტს შეაგროვოს მოხმარების ინფორმაცია საკუთარი VM-ებიდან ცალკე Runspace-ში და დაუყოვნებლივ შეატყობინოს დასრულების შესახებ. ეს საშუალებას აძლევს PowerShell-ს დაუყონებლივ დახუროს სამუშაოები, ნაცვლად იმისა, რომ გაიმეოროს ჰოსტების მეშვეობით და დაელოდოს თითოეული მათგანის მოთხოვნას.”

წყარო: როგორ ვაჩვენოთ ვირტუალური მანქანა I/O ESXi Dashboard-ზე

ქვემოთ მოცემულ შემთხვევაში, Runspace აღარ არის სასარგებლო:

„ვცდილობ დავწერო სკრიპტი, რომელიც აგროვებს უამრავ მონაცემს VM-დან და საჭიროების შემთხვევაში ახალ მონაცემებს წერს. პრობლემა ის არის, რომ VM-ები საკმაოდ ბევრია და 5-8 წამი იხარჯება ერთ მანქანაზე“. 

წყარო: Multithreading PowerCLI RunspacePool-ით

აქ დაგჭირდებათ Get-View, მოდით გადავიდეთ მასზე. 

მეორე ეტაპი: Get-View

იმის გასაგებად, თუ რატომ არის Get-View სასარგებლო, უნდა გვახსოვდეს, თუ როგორ მუშაობს cmdlets ზოგადად. 

Cmdlet-ები საჭიროა ინფორმაციის მოსახერხებლად მოსაპოვებლად API საცნობარო წიგნების შესწავლისა და შემდეგი ბორბლის ხელახლა გამოგონების გარეშე. რაც ძველ დროში სჭირდებოდა კოდის ას ან ორ სტრიქონს, PowerShell საშუალებას გაძლევთ გააკეთოთ ერთი ბრძანება. ჩვენ ვიხდით ამ კომფორტს სიჩქარით. თავად სმდლეტების შიგნით არ არის მაგია: იგივე სკრიპტი, მაგრამ უფრო დაბალ დონეზე, დაწერილი მზიანი ინდოეთის ოსტატის გამოცდილი ხელებით.

ახლა, Get-View-თან შესადარებლად, ავიღოთ Get-VM cmdlet: ის წვდება ვირტუალურ მანქანას და აბრუნებს კომპოზიტურ ობიექტს, ანუ ანიჭებს მას სხვა დაკავშირებულ ობიექტებს: VMHost, Datastore და ა.შ.  

Get-View თავის ადგილზე არ ამატებს რაიმე ზედმეტს დაბრუნებულ ობიექტს. უფრო მეტიც, ის საშუალებას გვაძლევს მკაცრად განვსაზღვროთ რა ინფორმაცია გვჭირდება, რაც გაადვილებს გამომავალ ობიექტს. ზოგადად Windows Server-ში და კერძოდ Hyper-V-ში Get-WMIObject cmdlet პირდაპირი ანალოგია - იდეა ზუსტად იგივეა.

Get-View მოუხერხებელია წერტილოვან ობიექტებზე რუტინული ოპერაციებისთვის. მაგრამ როდესაც საქმე ეხება ათასობით და ათი ათასობით ობიექტს, მას ფასი არ აქვს.

მეტი შეგიძლიათ წაიკითხოთ VMware ბლოგზე: Get-View-ის შესავალი

ახლა მე გაჩვენებთ ყველაფერს რეალური ქეისის გამოყენებით. 

სკრიპტის დაწერა VM-ის განტვირთვისთვის

ერთ დღეს ჩემმა კოლეგამ მთხოვა მისი სცენარის ოპტიმიზაცია. დავალება ჩვეულებრივი რუტინაა: იპოვეთ ყველა VM დუბლიკატი cloud.uuid პარამეტრით (დიახ, ეს შესაძლებელია VM-ის კლონირებისას vCloud Director-ში). 

აშკარა გამოსავალი, რომელიც მახსენდება არის:

1. მიიღეთ ყველა VM-ის სია.
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 $_
           }
       }
   }

ახლა მოდით განვახორციელოთ Multithreading Runspace Pools-ის მეშვეობით.  

ალგორითმი შემდეგია:

1. ჩვენ ვიღებთ ყველა VM-ის ჩამონათვალს.
2. პარალელურ ნაკადებში ვიღებთ ღრუბელს.uuid.
3. ჩვენ ვაგროვებთ მონაცემებს ნაკადებიდან ერთ ობიექტში.
4. ჩვენ ვფილტრავთ ობიექტს CloudUUID ველის მნიშვნელობის მიხედვით დაჯგუფებით: ის, სადაც უნიკალური მნიშვნელობების რაოდენობა 1-ზე მეტია, არის VM-ები, რომლებსაც ჩვენ ვეძებთ.

შედეგად, ჩვენ ვიღებთ სკრიპტს:

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 cmdlet-ის დასრულებას კიდევ უფრო მეტი დრო სჭირდება.
ჯერ მეორეს მივხედოთ. 

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, მაგრამ ის ბევრჯერ უფრო სწრაფად მუშაობს. 

ახლა მიიღეთ-VM. ის არ არის სწრაფი, რადგან საქმე აქვს რთულ ობიექტებს. ჩნდება ლოგიკური კითხვა: რატომ გვჭირდება ამ შემთხვევაში დამატებითი ინფორმაცია და ამაზრზენი PSOობიექტი, როცა უბრალოდ გვჭირდება VM-ის სახელი, მისი მდგომარეობა და სახიფათო ატრიბუტის მნიშვნელობა?  

გარდა ამისა, სკრიპტიდან ამოღებულია დაბრკოლება Get-AdvancedOptions-ის სახით. Runspace Pools-ის გამოყენება ახლა ზედმეტად გამოიყურება, რადგან სესიის გადაცემისას აღარ არის საჭირო ნელი ამოცანის პარალელიზება squat ძაფებში. ინსტრუმენტი კარგია, მაგრამ არა ამ შემთხვევისთვის. 

მოდით შევხედოთ 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 ათასი ობიექტისთვის სასურველი პირობით გაფილტვრით. დიდი!

იმის ნაცვლად, რომ დასკვნა

მისაღები შედეგი პირდაპირ დამოკიდებულია ხელსაწყოს არჩევანზე. ხშირად ძნელია ზუსტად იმის თქმა, თუ რა უნდა აირჩიოს მის მისაღწევად. სკრიპტების დაჩქარების თითოეული ჩამოთვლილი მეთოდი კარგია მისი გამოყენების საზღვრებში. ვიმედოვნებ, რომ ეს სტატია დაგეხმარება რთულ ამოცანაში თქვენი ინფრასტრუქტურის პროცესის ავტომატიზაციისა და ოპტიმიზაციის საფუძვლების გაგებაში.

PS: ავტორი მადლობას უხდის საზოგადოების ყველა წევრს სტატიის მომზადებაში გაწეული დახმარებისა და მხარდაჭერისთვის. თუნდაც თათებით. და მათაც კი, ვისაც ფეხები არ აქვს, როგორც ბოა კონსტრიქტორი.

წყარო: www.habr.com