Arşiv

Posts Tagged ‘PowerCLI’

236: iovDisableIR parametresi hakkında

07.02.2017 1 yorum

Interrupt Remapping, Intel VT-d ve AMD IOMMU tarafından implemente edilen ve I/O cihazlarından gelen interrupt taleplerinin daha verimli bir şekilde sanal sunuculara yönlendirilmesini sağlayan bir özelliktir. ESXi 4.1 ve sonrası sürümlerde, VMware tarafından da varsayılan olarak desteklenmektedir. Buraya kadar her şey güzel iken, sıkıntılı taraf her donanım bu kodu desteklememektedir ve uyumlu olmayan bir konfigürasyon sanal sunucularda problemlere sebebiyet verebilir. VMware’ın makalesi bu konuyu detaylı olarak ifade etmektedir ve bu tip durumlarda önerilen, bir adet kernel parametresi ile bu özelliğin kapatılması yönündedir.

esxcli system settings kernel set –setting=iovDisableIR -v TRUE

Not: Konu ile ilgili güzel ve gayet detaylı bir makale de Adem Yetim’in zamanında yazmış olduğu bir makaledir, buradan erişebilirsiniz.

Ancak tam tersi senaryonun problem yarattığı durumlar da vardır. Örnek olarak, HPE DL/ML/BL Gen8/9 sunucularda bu özelliğin pasif bırakılmaması yönünde yazılmış tavsiye niteliğinde makaleler de bulunmaktadır. Hatta bu özellik kapatıldığında, yüksek oranda LINT1/NMI hatası ve sonucunda PSoD almamız muhtemeldir.

iovdisableir

Burada bahsetmek istediğim kritik nokta, uzun süredir varsayılan olarak FALSE olarak tanımlı olan ve sonuç olarak Interrupt Remapping özelliğini aktif tutan iovDisableIR kernel parametresinin, “ESXi 6.0 Patch 4” sonrasında TRUE olarak değiştirilmiş ve HPE sistemlerde PSoD’ye sebebiyet verebilecek olmasıdır (Güncelleme: ESXi 5.5 için de benzer durum söz konusu görünüyor).

Bu yüzden, tüm sistemler üzerinde bu parametrenin değerinin ne olduğu ve donanım üreticisinin tavsiyeleri doğrultusunda tanımlanmış olup olmadığı bir hayli önem kazanıyor. Aşağıdaki powershell fonksiyonu ile tanımlamaları hızlı bir şekilde görebiliriz.


function Get-iovDisableIR {
$VMHosts = Get-VMHost | Sort-Object Name
foreach ($VMHost in $VMHosts) {
$esxcli = Get-EsxCli -VMHost $VMHost
$item = $esxcli.system.settings.kernel.list($false,"iovDisableIR")
Write-Host ("{0} ({1}) -> Def:{2}-Con:{3}-Run:{4}" -f $VMHost.Name,$VMHost.Build,$item.Default,$item.Configured,$item.Runtime)
}
}

Bu fonksiyon ile vCenter sunucusuna bağlı tüm ESXi sunucuların isim ve build numarası ile birlikte, iovDisableIR parametresinin Default, Configured ve Runtime değerlerini görebilirsiniz.

Aşağıdaki örnekte, son yama geçilmemiş iki adet ESXi 6.0 sunucu ile diğer sunucular arasındaki farkı net olarak görebiliriz, versiyon numarası daha düşük ve varsayılan değer FALSE olarak. Güncellenmiş sunucularda ise bu değer TRUE görünmektedir.

iovdisableir2

Sözün özü, eğer HPE DL/ML/BL Gen8/9 sunucunuz varsa, PSoD almamak adına önerilen workaround, bu parametrenin yama sonrasında yeniden FALSE olarak değiştirilmesi ve sunucunun restart edilmesi. Ancak VMware ve HPE bu konuda beraber çalışıyorlar, ilerleyen dönemlerde belki bir BIOS güncellemesi olarak belki de farklı bir yama ile durumun daha kalıcı olarak çözülmesini bekleyebiliriz. Bu zamana kadar

ESXi üzerinden Interrupt Remapping özelliğinin yeniden açılması için:

esxcli system settings kernel set –setting=iovDisableIR -v FALSE

Powercli ile toplu bir şekilde yeniden açılması için:


function Disable-iovDisableIR {
$VMHosts = Get-VMHost | Sort-Object Name
foreach ($VMHost in $VMHosts) {
$esxcli = Get-EsxCli -VMHost $VMHost
$item = $esxcli.system.settings.kernel.set("iovDisableIR","FALSE")
Write-Host ("{0}: iovDisableIR is disabled, Please reboot the server" -f $VMHost.Name)
}
}

Kategoriler:VMware Etiketler:,

225: Snapshot’dan VM üretmek

Gerek vSphere Client olsun gerekse Web Client, VMware bazı özellikleri GUI üzerine koymamayı tercih ediyor, fakat API üzerinden bu özellikler kullanılabiliyor. Bunlardan bir tanesi de, snapshot’ını aldığımız bir sanal sunucudan, geçmişe yönelik klon üretmek.

Not: 6.5 ile birlikte de GUI üzerinde göremedim ancak bir yerlerde gizlenmiş olma ihtimalini açık bırakıyorum.

GUI üzerinden snapshot modunda olan bir sanal sunucunun klonunu almak istersek, sistemin yapacağı, arada geçen tüm snapshot’ları, yeni oluşturulacak VM ile birlikte konsolide etmek olacaktır. Bu durumda arada yer alan bir durumun klonunu oluşturamayacağız. Örnek olarak aşağıdaki sunucuyu düşünebiliriz.

snapclone

Yaptığım testte kolaylık olması açısından, sunucunun sadece vHW (sanal donanım seviyesi) değerini birer artırarak snapshot aldım. Bu arada, vHW seviyesini birer birer, istediğiniz seviyede artırmak da GUI üzerinden yapabileceğimiz bir aksiyon değil. ESXi sunucusu hangi seviyede ise, direk bizi o seviyeye çıkarır. Kontrollü gidebilmek için PowerCLI üzerinde aşağıdaki komutu kullandım.


$VM = Get-VM -Name PHOTON02
$VM.ExtensionData.UpgradeVM("vmx-10")
$VM.ExtensionData.UpgradeVM("vmx-11")

Gelelim işin klon kısmına. Bu işi gerçekleştiren, vSphere 6.0 API referans dokümanından da ulaşabileceğimiz, CloneVM_Task metodudur. Bu metod üç adet parametre kabul eder;

  • Folder: ManagedObjectReference tipinde
  • Name: Oluşacak klonun adı, string tipinde
  • Spec: VirtualMachineCloneSpec tipinde. Klonlama operasyonu ile ilgili tüm parametreleri girdiğimiz obje budur.

Spec objesi çok detaylı bir objedir. İçeriğini ve alt kırılımlarını incelediğimizde karşımıza diskMoveType isimli bir özellik çıkar ki bütün farkı yaratan bu özelliktir. Alabileceği beş adet değer bulunur:

  • createNewChildDiskBacking: Eğer linked klon üretmek istiyorsak, kullanabileceğimiz değer budur. Bu yöntem en hızlı klon alma yöntemidir ve bir anda onlarca klonu alıp, sunucuları hayata geçirebilirsiniz. Script içerisinde LinkedClone opsiyonu ile bu değeri kullandım.
  • moveAllDiskBackingsAndAllowSharing: Tüm delta dosyaların da kopyalanması ile birlikte full klon oluşturmayı tetikler ancak snapshot konfigürasyon dosyasını barındırmaz. Dolayısı ile klon alınmış sunucu, snapshot bilgilerini göremez.
  • moveAllDiskBackingsAndConsolidate: Tüm disklerin taşınıp, konsolide edildiği durum.
  • moveAllDiskBackingsAndDisallowSharing: vSphere Client üzerinden klon gerçekleştirdiğimizde kullanılan değer budur. Tüm delta disklerin konsolide edilmesini sağlar. Klon metodu içerisinde kullanıldığında, yukarıdaki opsiyon ile aynı görevi görür. Script içerisinde, LinkedClone talep edilmediği durumda bu değeri kullandım.
  • moveChildMostDiskBacking: Yine linked klon yapmamızı ancak tüm disklerin değil, en son deltanın kopyalanmasını tetikler.

Şimdi gelelim hem full klon hem de linked klon oluşturabileceğimiz fonksiyonumuza;


function CreateVMFromSnap {
[CmdletBinding()]
Param ( [parameter(Mandatory=$true)][ValidateNotNullOrEmpty()][String]$SourceVMName,
[parameter(Mandatory=$true)][ValidateNotNullOrEmpty()][String]$CloneName,
[parameter(Mandatory=$true)][ValidateNotNullOrEmpty()][String]$SnapshotName,
[parameter(Mandatory=$true)][ValidateNotNullOrEmpty()][String]$ClusterName,
[parameter(Mandatory=$true)][ValidateNotNullOrEmpty()][String]$DatastoreName,
[parameter(Mandatory=$true)][ValidateNotNullOrEmpty()][String]$FolderName,
[parameter(Mandatory=$false)][Switch]$LinkedClone
)

$SourceVM = Get-VM -Name $SourceVMName -ErrorAction:SilentlyContinue
if ($SourceVM) {
$Snapshots = Get-Snapshot -VM $SourceVM
$ResourcePoolMoRef = (Get-Cluster -Name $ClusterName | Get-ResourcePool -Name "Resources").ExtensionData.MoRef
$DatastoreMoRef = (Get-Datastore -Name $DatastoreName).ExtensionData.MoRef
$FolderMoRef = (Get-Folder -Name $FolderName -Type VM).ExtensionData.MoRef
if ($LinkedClone) { $CloneType = "createNewChildDiskBacking" }
else { $CloneType = "moveAllDiskBackingsAndDisallowSharing" }

$CloneSpec = New-Object Vmware.Vim.VirtualMachineCloneSpec
$CloneSpec.Snapshot = ($Snapshots | Where-Object {$_.Name -eq $SnapshotName}).ExtensionData.Snapshot
$CloneSpec.Location = New-Object Vmware.Vim.VirtualMachineRelocateSpec
$CloneSpec.Location.Pool = $ResourcePoolMoRef
$CloneSpec.Location.Datastore = $DatastoreMoRef
$CloneSpec.Location.DiskMoveType = [Vmware.Vim.VirtualMachineRelocateDiskMoveOptions]::$CloneType
$VITask = $SourceVM.ExtensionData.CloneVM_Task($FolderMoRef, $CloneName, $CloneSpec)

} else {
Write-Host ("{0} sanal sunucusu bulunamadi" -f $SourceVMName) -ForeGroundColor Red
}
}

Aşağıda LinkedClone oluşturabileceğimiz örnek bir komutu görebiliriz. Seçtiğimiz snapshot bellek bilgilerini de barındırıyor ise, arka planda her VM için bellek verisinin kopyalanması gerekecektir, bu da biraz daha zaman alacaktır. Diğer türlü, çok daha hızlı şekilde sunucuları açabiliriz (tabi açarken IP çakışması olabileceğini de atlamamamız gerekiyor).


for ($num=3; $num -le 10; $num++) {
CreateVMFromSnap -SourceVMName PHOTON02 -CloneName ("PHOTON{0}" -f $num) -SnapshotName VMX10_Acik_Belleksiz -ClusterName DC2.DemoCluster -DatastoreName Datastore02 -FolderName VMFolder -LinkedClone
#Start-VM -VM ("PHOTON{0}" -f $num)
}

Sonuç:

snapclone2

Kategoriler:VMware Etiketler:

220: VMware PowerCLI 6.5 ilk izlenimler

powercli0“Geç olsun, güç olmasın” dediğimiz ve sabırla beklediğimiz PowerCLI’ın yeni sürümü 6.5 Release1, dün itibari ile yayınlandı. İlk dikkatimizi çeken nokta, daha önceki ürün yelpazesi vSphere PowerCLI olarak isimlendirilirken, 6.5 versiyonu VMware PowerCLI olarak çıktı. Bu bir pazarlama hamlesinin ötesinde, PowerCLI vizyonunu aslında adresleyen bir değişim ve artık sadece vSphere değil, bir çok farklı ürünün desteklendiğinin ve destekleneceğinin habercisi. Ürünün sürüm notlarına buradan ulaşabilirsiniz.

Ürün desteği:

VMware PowerCLI ile ilgili gözümüze çarpan ile nokta, VMware ürün ailesi içerisindeki desteğini genişletmiş olması, örnek olarak Horizon View. View için daha önceden modül eklentisi mevcut idi ancak buradaki problem sadece Connection Server üzerinde çalıştırılabiliyordu, uzaktan bağlantıyı desteklemiyordu. Artık API erişimini, uzaktan, Connect-HVServer komutu ile her ortamdan yapabilir durumdayız.

SDS kapsamında da yeni bir modül eklendi (VMware.VimAutomation.Storage). Bu modül, hem vSAN [v’si küçük :)], hem VVOL, hem de normal sanal diskler için operasyonlarımızı kolaylaştıracak toplamda 56 adet cmdlet barındırıyor. Özellikle vSAN alanında çok kullanım alanı bulacaktır.

vSphere tarafında da, GUI üzerinden yapamadığımız, belli operasyonlar için artık cmdlet opsiyonları mevcut. Bunlardan örnek olarak, farklı SSO etki alanları arasında cross-vCenter vMotion özelliğini verebiliriz, Move-VM komutu bunu destekler nitelikte. Benzer bir örnek, New-VM komutunda vSoket bazında vCore sayısını belirtemiyorduk, artık bunu da belirtebiliyoruz.

Halen bulamadığım bir özellik var, o da VM-fork (nam-ı diğer Instant Clone). API referansı içerisinde incelemem devam ediyor, bulduğumda bunu ayrı bir yazı olarak paylaşacağım. Çok daha fazlası için aşağıdaki linkleri kullanabilirsiniz.

Eklenti ve modüller:

VMware PowerCLI 6.5’in en göze çarpan yapısal farklılığı, modül ve eklenti bazında kendini gösteriyor. Daha önceki sürümlerde, PSSnap-in eklentisi aracılığı ile çalışıyordu. Normalde PowerCLI’ı çalıştırdığınızda, arka planda Initialize-PowerCLIEnvironment.ps1 isimli bir script çalışır ve eklentileri eklerdi. Bu, özellikle powershell temelli otomasyonlarda bizlere ekstra bir yük teşkil eder, atomik scriptleri yavaşlatırdı.

Yeni sürüm ile birlikte, tüm eklentiler kaldırıldı, Bunun yerine modüler bir yapı getirildi. Yine öncesinde bir powershell scripti çalışıyor ancak bu script çok daha hafif bir script ve ilgili modülleri eklemek dışında çok büyük bir görevi bulunmuyor. Aşağıdaki örnekte, powershell eklentisi haricinde bir eklenti bulunmadığını görebilirsiniz.

powercli2

Eğer standard bir powershell içerisinden de kullanmak isterseniz, tek bir komut ile tüm modülleri ekleyebilir ve tüm özelliklere erişebilirsiniz.

Get-Module -Name VMware* -ListAvailable | Import-Module

PowerCLI 6.5’in eski versiyonlara uyumluluk durumu, vSphere 5.5 seviyesine kadar bulunuyor. vCenter 5.5 ve sonrası tüm sürümler için kullanılabilir. vSAN uyumluluğu, VMware vSAN 6.0 ve sonrası şeklinde, Horizon View uyumluluğu ise 7.0.2 itibari ile olacaktır.

Bildiğiniz gibi, PowerCLI’ın bir de docker üzerinde çalışan core versiyonu bulunuyor. GitHub sayfasını kontrol ettiğinde ekstra modüllerin henüz desteklenmediğini görüyorum ancak core modülü içerisinde yeni komutlar destekleniyor (Ör: Open-VMConsoleWindow)

Düzeltme: VM konsol komutu linux kernel dolayısı ile desteklenmiyor ancak en azından var olduğunu görebiliyoruz. Amacım core versiyonunun güncellenmiş olduğunu göstermek.

powercli3

Sonuç itibari ile, VMware PowerCLI 6.5 Release1, 15 modül, 0 PS-snapin, 587 cmdlet ve 62 alias ile hayatımızı daha da kolaylaştırmak için hazır bekliyor. Gerisi bizlere kalmış…

 

 

Kategoriler:VMware Etiketler:,

214: ESXi hostlar üzerinde PowerCLI ile zaman kontrolü

Bu sene geleneksel DST şenlikleri kapsamında, kış zamanına geçmeyecek olmamız, hepimizin fazlasıyla bilgi sahibi olduğu ve üzerinde çalıştığı bir konu. VMware’ın konu ile ilgili, kritik gördüğüm iki adet makalesi var, aşağıdaki linklerden erişebilirsiniz.

  • KB2135594: Daylight Savings Time (DST) end date in Turkey on November 8, 2015 and VMware products
  • KB2147470: Turkish time zone issue in VMware Identity Manager, Identity Manager Connector and Access Point

Konunun özünde, core servisler UTC kullandığı için bir etki beklemiyoruz. Ancak yine de, NTP tanımlarımızın doğru yapılmış olduğu ve ESXi sunucularımızda zaman kayması yaşamıyor olduğumuzun kontrolü genel anlamda önemli bir durum çünkü ESXi sunucular ile VM sunucular arasında zaman senkronizasyonu söz konusu olduğunda sıkıntı yaşamak istemeyiz.

Zaman kayması kontrolünü, bir PowerCLI scripti aracılığı ile hızlı bir şekilde yapabiliriz. Bu script gün itibari ile aceleye geldi, biraz daha geliştirdiğimde yeniden paylaşmayı planlıyorum, örnek olarak NTP servis durumu ve konfigürasyonlarının listelenmesi gibi.


Connect-VIServer -Server vCenterSunucunuz
$acceptedDifference = 2
$VMHosts = Get-VMHost | Where-Object {$_.ConnectionState -eq "Connected"} | Sort-Object Name

foreach ($VMHost in $VMHosts) {
$Color = "Green"
$DTS = Get-View $VMHost.ExtensionData.ConfigManager.DateTimeSystem
$Time = $DTS.QueryDateTime()
$Diff = ($Time - [DateTime]::UtcNow).TotalSeconds
If ([math]::abs($Diff) -gt $acceptedDifference) {$Color = "Red"}

If ($Diff -gt 0) {
Write-Host ("{0} sunucusu {1} saniye ileri" -f $VMHost.Name, [math]::abs($Diff)) -ForeGroundColor $Color
} Else {
Write-Host ("{0} sunucusu {1} saniye geri " -f $VMHost.Name, [math]::abs($Diff)) -ForeGroundColor $Color
}
}

Scriptin tek bir değişkeni var, saniye cinsinden kabul edilen maksimum zaman kayması. Buna göre çıktı yeşil renk veya kırmızı renkte olacaktır.

Basit olarak yaptığımız, UTC olarak zamanı ESXi sunucusundan almak, client olarak çalıştırdığımız işletim sisteminin zamanını da UTC olarak alıp karşılaştırmak. Eğer değer sıfırdan büyük ise, ESXi sunucusunun zamanı ileri, tersi durumda ise geri demektir. Tabi karşılaştırmayı scripti çalıştırdığımız PC veya sunucu ile yaptığımızdan dolayı, bu sistemin zamanının ortamımız ile senkron olduğundan emin olmamız gerekmektedir.

Örnek bir çıktı ise aşağıdaki şekilde görünmeli.

datetime

Umarım faydalı olur.

Kategoriler:VMware Etiketler:,

210: VMware {Code} Hackathon 2016 hakkında

21.10.2016 2 yorum

hackathonVMworld 2016 esnasında, belki de en fazla keyif aldığım etkinliklerden biri hackathon gecesi oldu. Pazartesi akşamı saat 18:00’dan gece yarısına kadar süren bu etkinlik için dünyanın farklı yerlerinden birçok insan bir araya geldi. Peki, kısaca nedir bu hackathon?

VMware {Code} Hackathon, API/SDK/CLI Product Line Manager Alan Renouf, VMware {Code} ekibi ve William Lam tarafından organize edilen bir etkinlik. Asıl amaç, birbirini hiç tanımayan insanları bir araya getirip takımlar oluşturmak ve bir problemi adresleyecek şekilde kod yazmalarını sağlamak ve bunu yaparken de bol bol eğlenmek. Her hangi bir katılım şartı yok, isteyen herkesin katılabileceği bir etkinlik.

Kodlamaları gerçekleştirdiğimiz hackathon platformu, William Lam tarafından özenle hazırlanmış 7 adet Intel NUC üzerinde çalışıyordu. Bu 7 adet NUC üzerinde ESXi 6.0U2 kurulmuş ve VSAN yapılandırılmış durumdaydı ve her ekibin kendine ait bir ESXi sunucusu bulunuyordu. Her ESXi sunucusu içerisinde de bir adet VCSA kurulmuş halde bekliyordu. Bunun haricinde ise elimizde olan tek şey, Content Catalog içerisinde nested ESXi şablonu idi. Bunun dışında ihtiyacınız olan herşeyi dışarıdan getirme şansımız vardı, örnek vRO kullanacak ekip, bunu internetten indirme veya yanında getirip import etme konusunda serbestti. Yani hiçbir sınır yok.

nucs-300x225

Toplamda 7 adet ekip vardı ve her ekip kendi belirledikleri bir konu üzerinde çalışma gerçekleştirdi. Ben Luc Dekens’ın ekibinde yer aldım ve amacımız Microsoft’un DSC (Desired State Configuration) Powershell modülü ile vSphere’ı birleştirmek. Luc uzun zamandır bu konu üzerinde çalışıyor ve GitHub üzerinde bir kısım kodu bulunuyor, dolayısı ile sıfırdan başlamadık, GitHub üzerinde yer alan kodu klonlayıp, hackathon için yeni bir branch oluşturduk ve işe koyulduk. Amacımız alarm’ların yönetimini DSC ile yapmak için gerekli modülleri yazmak idi.

Bu esnada ekipten kodlamaya biraz daha uzak olan bir arkadaş ise, nested ESXi ortamını ayağa kaldırmak için gerekli çalışmayı gerçekleştirdi ve default root şifrelerini değiştirdi. Gerekçe ise, Vegas’da gerçekleştirilen hackathon esnasında edinilen tecrübeler doğrultusunda, diğer ekiplerin sizin ortamınızı “hack” edebilecek olması, aşağıda görüldüğü gibi :)

hackathon2

Ekipten bir kişi VMware’ın API referansı üzerinden doğru objelerin doğru metod ve özellikleri ile konumlandırılması konusunda Luc’a destek verdi. Luc ise zaten takımın beyni olarak genel anlamda kodlamayı gerçekleştirdi. Benim görevim ise fonksiyonları hackathon ortamında çalıştırmak, hataları debug etmek ve gerekli düzeltmeleri ortam üzerinde yapmak oldu (Burada SDLC süreçlerinin hiçbir yeri yok :))

Sonuç? Tabiki yetiştiremedik :) Zaten jürinin beklentisi de, 3 saat içerisinde tamamlanmış bir proje değil ve hiçbir ekip de bu noktaya ulaşamadı. Hatta çalışan bir kısım kod ortaya koyabilen ekip sayısı bile sınırlı idi. Alarm objelerimizi konfigüre ettiremediysek de, yazdığımız kod diğer vSphere objelerini otomatik olarak oluşturmak ve konfigüre etmek konusunda başarılı oldu (datacenter objesi, folder objesi, cluster objesi ve nested esxi hostların eklenmesi gibi). Eğer aşağıdaki fonksiyonu da doğru bir şekilde çalıştırabilseydik, belki daha fazla puanımız olacaktı. Üzerinde biraz daha oynamaya ihtiyacı var ama bitiş zili çaldığında sona çok yakın olduğumuzu hissediyordum :)


enum VmwAlarmState {
Green
Yellow
Red
Gray
}

function New-VmwAlarm
{
[CmdletBinding()]
param(
[VMware.Vim.ManagedEntity]$Parent,
[String]$Name,
[string]$Description,
[PSCredential]$Credential,
[VmwAlarmState]$StateStart,
[VmwAlarmState]$StateFinal,
[boolean]$Repeats,
[boolean]$Enabled,
[string]$EventTypeId,
[Vmware.Vim.ManagedObjectReference]$entity
)

$si = Get-View ServiceInstance
$alarmMgr = Get-View -Id $si.Content.AlarmManager

$spec = New-Object VMware.Vim.AlarmSpec
$spec.Name = $Name
$spec.Description = $Description
$spec.Action = New-Object VMware.Vim.AlarmTriggeringAction
$spec.Action.Action = New-Object VMware.Vim.SendEmailAction
$spec.Action.Action.body = "Test email body"
$spec.Action.Action.subject = "Test email subject"
$spec.Action.Action.toList += "test@email.com"
$spec.Action.TransitionSpecs += New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec
$spec.Action.TransitionSpecs[0].StartState = $StateStart
$spec.Action.TransitionSpecs[0].FinalState = $StateFinal
$spec.Action.TransitionSpecs[0].Repeats = $Repeats
$spec.Enabled = $Enabled
$spec.Expression = New-Object VMware.Vim.EventAlarmExpression
$spec.Expression.EventTypeId = $EventTypeId
$spec.Expression.EventType = $null
$spec.Setting = New-Object [VMware.Vim.AlarmSetting]
# $spec.Setting.ReportingFrequency = $Re
# $spec.Setting.ToleranceRange =

$alarmMgr.CreateAlarm($entity,$spec)
}

Not: Kod tam halini aldığında bunu da burada güncelleyeceğim.

Tüm bu çabalarımız doğrultusunda 3. sırayı aldık. Bu arada birincilik ödülü, tüm ekip üyelerine, platformda kullanılanlardan bir adet NUC idi. İkinci ve üçüncü sırayı alan ekiplerden ise çekiliş ile bir kişiye NUC verildi. Ödül alan projeler;

  1. HTML5 Front end to vRO: Çalışmanın sonunda HTML5 tabanlı şık bir arayüz hazırdı ve vRO ile REST API üzerinden haberleşip tüm workflow’ları listeleyebiliyordu. Ancak “Run Workflow” düğmesinin arkası hazır değildi. Bence birinciliği hak ettiler çünkü gerçekten iyi bir fikir ve görsele sahipti.
  2. Availability Report: Burada amaç, ESXi hostları shutdown ederken girilen gerekçelerin raporlanabilmesi. Şu anda bunu yapabilen bir ürün yok ve fikir de buradan çıkmış, basit gibi görünüyor iken, içine girdiğinizde bu veriyi çekmenin ne kadar kompleks olduğu ortaya çıkıyor.

Sonuç itibari ile gerçekten unutulmaz bir gece geçirdik;

  • Yeni insanlar tanıdık ki bunların arasında Alan Renouf, Duncan Epping, Cormac Hogan, Luc Dekens, Mike Foley gibi gurular da bulunuyor. Hatta bir ara VMware CTO/CDO’su Ray O’Farrel bile etkinliğe uğradı.
  • Konfor alanımızın dışında kodlamaya çalıştık. DSC benim için tamamen yeni bir alan, dolayısı ile çok fazla şey öğrendim.
  • Ancak herşeyden önemlisi çok eğlendik, özellikle projelerin sunumları esnasında zira jürinin kriter listesinde bu da artı bir puan, eğlence unsuru ve yaratıcılık :) Hatta hackathon sonunda masalardaki boş bira şişe sayısının bile sonradan artı puan olduğunu öğrendik. Bunu önceden biliyor olsaydık, bir kişiye sırf bira içme görevi bile verebilirdik :)

Umarım seneye yine burada olur ve bu etkinliğe katılabilirim ve eğer siz de az biraz kodlamaya yakın iseniz, kesinlikle kaçırmayın derim.

hackathon2

 

Kategoriler:VMware Etiketler:, ,

209: PowerCLI ve çoklu platform desteği

powerclicoreVMworld 2016 sonrası yazılacak çok fazla konu var ancak neden bilmiyorum SDK takımının gerçekleştirdiklerinin bende hep ayrı bir yeri var. Keynote lansmanları esnasında, amiral gemisi olarak nitelendirebileceğimiz ürünlerin yanında yer bulmaya başlamaları da bir diğer gelişme. Bu yüzden bir önceki yazıda, kısaca kaldığımız yerden devam edeceğim. Asıl konuları da, yakın zamanda daha detaylı bir şekilde kaleme alacağım.

Yakın zamanda, Photon OS üzerinden bir docker container olarak powershell kullanabilir olduğumuzu görmüştük. Şimdi ise SDK takımı konuyu bir kademe ileriye taşıdı ve PowerCLI’ın core bileşenlerini de, hem Linux/MacOS üzerinde, hem de docker container olarak çalışabilir hale getirdi. Container olarak da, daha öncekilerinden farklı olarak, Ubuntu yerine Photon OS imajı kullanıldı.

Photon OS üzerinde aşağıdaki iki komutu kullanarak, hızlı bir şekilde, PowerCLI ortamını canlandırabilirsiniz.

docker pull vmware/powerclicore

docker run –rm -it –entrypoint=’/usr/bin/powershell’ vmware/powerclicore

Powershell ve beraberinde PowerCLI artık gerçek anlamla çoklu platform desteği sağlamış görünüyor ve aynı zamanda container ile taşınabilirlik özelliklerini. Windows, Linux, Mac OS, Docker, Photon OS…. Peki geriye ne kaldı? Belki mainframe :)

powerclicore2

Özelikle docker tarafını önemli buluyorum. Neden mi? Sadece farklı platformlarda bir scripti çalıştırmanın, evet, çok büyük bir esprisi yok. Ancak, normalde bir sunucu üzerinde silo halinde tutup çalıştırdığımız PowerCLI scriptlerin veya fonksiyonların, artık bir codebase içerisinde, bir event ile tetiklenip, beraberinde bir container oluşturup, çalışıp, sonuç üretip, işi bittikten sonra da container ile birlikte yok olan ve bu şekilde hem verimlilik hem de yönetilebilirlik avantajları getirecek bir nesile evrimleşmesi mümkün görünüyor. Elbette bunun için önümüzde daha zaman var ancak IT dünyasında zamanın nasıl hızlı geçebildiğini hepimiz iyi biliyoruz.

PowerCLICore lansmanı yapıldığında aklıma gelen bir diğer konu ise, bunu bir noktada VCSA veya vMA üzerinde görüp göremeyeceğimiz oldu ve bu konuyu vCenter Product Management ekibinden birisine sorma şansını yakaladım. Zannedersem biraz fazla gizli bilgi içerecek bir konu olduğundan net bir cevap alamadım ancak edindiğim izlenim olumluya yakın bir “neden olmasın” idi :)

Son olarak, paketlere fling sayfasından da erişebilirsiniz.

PowerCLI Core Fling

Kategoriler:Docker, VMware Etiketler:, ,

168: DRS Anti-Affinity Kuralları ve otomasyonu

Varsayalım ki, bir gün bir sunucunuz NMI hatası vermeye karar verdi ve ESXi sunucunuzda PSoD (Purple Screen of Death) oluştu. Bu durumda HA devreye girdi ve sanal sunucularınızı başka bir ESXi üzerinde ayağa kaldırdı. Ancak sonradan farkettiniz ki, yedekli çalışan iki sanal sunucu, problem anında aynı ESXi sunucusu üzerinde çalışmakta iken problemden etkilenmiş ve hizmet kesintisine sebebiyet vermiş.

Bu tip problemler her zaman engellenemeyebilir ancak hizmet kesintisini engellemek ya da en azından olasılığını düşürmek elimizde. DRS anti-affinity kuralları bize bu konuda yardımcı olabilir. Normalde DRS ile yazabileceğimiz üç çeşit kural vardır, bunlar;

  • Keep Virtual Machines Together: Şu sanal sunucular aynı host üzerinde çalışsın.
  • Separate Virtual Machines: Şu sanal sunucular aynı host üzerinde çalışmasın
  • Virtual Machines to Hosts: Şu sanal sunucular sadece şu host’lar üzerinde çalışsın

Aşağıdaki örnekte bunu daha net görebilirsiniz. “Separate Virtual Machines” kuralı ise (anti-affinity) bize bir problem anında aynı görevi gören yedekli sunucuların farklı ESXi sunucuları üzerinde çalışmasını sağlar. Eğer bugüne kadar DRS kuralı oluşturmadıysanız, bugün oluşturmanızı tavsiye ederim.

CreateDRSRule

Şimdi gelelim işin heyecanlı kısmına. Eğer kümenizde yüzlerce sunucu varsa, bu iş çok can sıkıcı bir hal alabilir. Bu yüzden, bir PowerCLI kodu ile bu işi otomatik yapmaya karar verdim. Bu kodun sağlıklı çalışması için öncelikli koşul düzgün bir sanal sunucu isimlendirme standardınızın olması. Aşağıdaki algoritmada bunu, sunucu adının son iki hanesine göre ayırt ediyorum (yani webserver01 ve webserver02’nin yedekli ve ayrı ESXi sunucularında çalışması gerektiğini varsayıyorum). İkinci önkoşul ise, kümede tanımlı bir DRS kuralının olmaması, aksi taktirde dublike kurallar oluşabilir.


function Create-DRSRules {
param ([Parameter(Mandatory=$true)][string]$Cluster)

$VMCluster = Get-Cluster -Name $Cluster
$VMHosts = $VMCluster | Get-VMHost
$VMs = $VMCluster | Get-VM | Sort-Object Name

foreach ($VM in $VMs) {

Write-Host ("{0}: " -f $VM.Name) -NoNewline
$strShortName = $VM.Name.Substring(0,$VM.Name.Length - 2)
$SimilarVMs = $VMs | Where-Object {$_.Name -match $strShortName}

if (!$SimilarVMs.Count) { Write-Host ("Benzer VM bulunamadi"); Continue }
if ($SimilarVMs.Count -gt $VMHosts.Count) { Write-Host ("Benzer VM sayisi ESXi sayisindan fazla"); Continue }

$DRSRuleName = ("{0}_Sep" -f $strShortName)
$DRSRule = $null
$DRSRule = Get-DrsRule -Name $DRSRuleName -Cluster $VMCluster -ErrorAction SilentlyContinue
if ($DRSRule) {
Write-Host ("DRS Rule yazilmis; {0}" -f $DRSRule.Name); Continue }

try {
Write-Host ("Creating DRS Rule {0}" -f $DRSRuleName) -ForegroundColor Yellow
$spec = New-Object VMware.Vim.ClusterConfigSpecEx
$spec.rulesSpec = New-Object VMware.Vim.ClusterRuleSpec[] (2)
$spec.rulesSpec[0] = New-Object VMware.Vim.ClusterRuleSpec
$spec.rulesSpec[0].operation = "add"
$spec.rulesSpec[0].info = New-Object VMware.Vim.ClusterAntiAffinityRuleSpec
$spec.rulesSpec[0].info.enabled = $true
$spec.rulesSpec[0].info.name = $DRSRuleName
$spec.rulesSpec[0].info.userCreated = $true
$spec.rulesSpec[0].info.vm = ($SimilarVMs | Get-View) | %{$_.moref}
$Task = (Get-View -Id $VMCluster.id).ReconfigureComputeResource_Task($spec, $true)
Start-Sleep -Seconds 2
} catch {
$ErrorMessage = $_.Exception.Message
Write-Host $ErrorMessage -ForegroundColor Red
}
}
}

Not: PowerCLI 5.5 versiyonu ile scripti çalıştırdığımda “A specified parameter was not correct” hatası ile karşılaştım. Ancak PowerCLI 5.1 versiyonunda herhangi bir problem ile karşılaşmadım. vCenter sunucusu ise 5.5 idi.

Fonksiyonu PowerCLI ekranınıza yapıştırıp, aşağıdaki şekilde çağırdığınızda, ilgili kümede onlarca (belki yüzlerce) anti-affinity DRS kuralının oluştuğunu görebilirsiniz. Kurallar oluşurken de, DRS, oluşmuş kurallar doğrultusunda sanal sunucuları taşımaya başlayacaktır. Ne kadar çok sunucunun vMotion ile taşındığını görürseniz, o kadar doğru bir iş yapmış olduğunuzu farkedeceksiniz.

Ekran görüntüsündeki maskeleme için kusura bakmayın, gizlilik her zaman iyidir.

CreateDRSRule2

Not: Fonksiyonu çağırmadan önce Connect-VIServer komutu ile vCenter sunucusuna bağlanmış olmanız gerekmektedir.

Kategoriler:VMware Etiketler:,
%d blogcu bunu beğendi: