199: Intel v4 işlemciler ve sanallaştırma üzerine

Intel’in, Mart 2016 itibari ile resmi olarak duyurduğu ve veri merkezlerinde ağırlığı çeken E5-2600 serisi işlemciler artık tamamen gündeme oturmuş durumda. Ben de bu yeni jenerasyon işlemciler ve özellikle sanallaştırma platformlarına etkileri doğrultusunda bir kaç bilgi vereyim istedim.

Önemli Not: Eğer E5-2600v4 işlemcilerden kullanmaya başladı iseniz, her şeyden önce VMware’ın bu işlemciler ile ilgili makalesine göz atmanızı tavsiye ederim. Durduk yere PSOD yemeyin.

Broadwell kod adlı, Intel Xeon v4 işlemciler, Intel’in 2007 yılından bugüne uyguladığı tick-tock modelinde en son tick’e denk gelmektedir, yani bir önceki jenerasyon olan ve 22nm çip prosesine sahip Haswell mikro-mimarisinin 14nm mertebesine sıkıştırılmış hali olarak düşünebiliriz, ve tabi bir takım yenilikler ile birlikte. Ancak mikro-mimari genel itibari ile aynıdır. Tock’a denk gelen jenerasyon değişimlerinde ise transistör boyutu sabit kalır ancak mikro-mimari değiştirilir.

Not: Bu arada daha güncel bir bilgiyi de atlamış olmayayım; Intel, 2016 Mart ayında tick-tock modelini, process-architecture-optimization modeli ile değiştireceğini duyurdu. 

Intelv4-1

Intel v3 Haswell işlemciler 18 çekirdeğe kadar çıkabiliyorken, Broadwell işlemciler 22 çekirdeğe çıkabiliyor. Bunun ile birlikte L3 (LLC, last level cache) cache alanı da 55 MB’a çıkarılmış durumda. Böylelikle, hem çekirdek sayısının hem de L3 cache alanının büyümesi, ortalamada çekirdek başına kullanılabilecek L3 cache değerini değiştirmemiş görünüyor. Bunun yanında tüm çekirdekler, 32KB L1 data cache ve 32KB L1 instruction cache alanlarının yanı sıra, 256KB L2 cache’e sahiptir. QPI link hızları jenerasyonlar arasında değişim göstermemiş durumda iken, maksimum bellek hızları 2400MHz’i desteklemektedir.

Yeniliklerden bahsederken, mikro-mimari seviyesinde de bir takım değişiklikler gerçekleşti, örnek olarak AES şifreleme performansını artıran yeni instruction’ları veya sanal adresleri fiziksel adreslere çevirmede yüksek performans sağlayan TLB (Translation Lookaside Buffer) cache alanının kapasitesinin %50 oranında artmasını (1500 page table entry) sayabiliriz. Ancak direk sanal sistemleri adresleyen iki adet önemli değişiklik de söz konusu.

Bunlardan birincisi ve daha önemli olanı, posted interrupts. Normal bir senaryoda, donanımsal bir talebi karşılamak için bir interrupt oluştuğunda, çalışan sanal sunucu geçici olarak durdurulur (VM-Exit) ve interrupt önce hipervizör tarafından karşılanır. Sonrasında VMM tarafından sanal sunucunun bu talebi karşılaması sağlanır. Hipervizör tarafından bu VM-Exit operasyonu değerli CPU cycle’larını harcayan bir süreçtir. Posted interrupts ile, hipervizör, gelen interrupt’ların CPU tarafından direk ilgili VM’e yönlendirmesini sağlayacak şekilde programlanabilir ve VM’ler gereksiz yere durdurulmaz. Sonuç olarak VM’ler daha önemli işlerini öncelikli halledip interrup’ları yönetme şansı yakalarken, hipervizör ise sürekli VM’ler arasında switch yapmak zorunda kalmaz, sonuç olarak daha düşük CPU latency değerleri elde edilir. Bunun en büyük etkisi NFV alanında olacaktır. Sanal network bileşenlerine gelecek olan yoğun network verisini ve bunun yaratacağı interrupt trafiğini düşünün. Yapılan bir benchmark 256 bytes paketler ile %41’lik throughput artışı sağlamış, 1KB paket boyutunda ise %19.

İkinci madde ise, vMotion gibi canlı taşıma veya swapping operasyonlarını adresliyor, Page-Modification Logging. vMotion adımlarını hatırlarsak, pre-copy sonrası hipervizörün kirlenen sayfaları tespit etmesi ve bu sayfaları yeniden taşıması gerekli idi. Bunun tespiti aşamasında VMM, Intel EPT (Extended Page-Table) mekanizmasını kullanır, bu alanı gerektiğinde tarar ve değişen sayfaları takip eder ancak bu maliyetli bir işlemdir. PML ise EPT üzerine geliştirilmiştir, EPT’ye giren her kayıt için aynı zamanda in-memory log oluşturulur ve bu logda değişen bloğun fiziksel adresi yer alır. VMM ise bu alanı tarayarak daha verimli bir şekilde değişen sayfalara ulaşır. Sonuç daha verimli vMotion performansı. Yine NFV sistemler için bir hayli faydalı olacaktır.

Tüm bu detaylardan sonra, Broadwell E5-269X işlemcilerin Haswell versiyonları ile karşılaştırıldıklarında, genel ortalamada %27, VMMark sonuçları doğrultusunda da %25 oranında daha iyi performans gösterdiğini söyleyebiliriz. %27’lik performans artışını ve CPU’ların toplam thread sayılarını da baz alırsak, single-thread performansının da yaklaşık olarak %5 oranında arttığını hesaplayabiliriz.

Intel’in v4 işlemci listesinde buradan ulaşabilirsiniz. Bu liste içerisinde bir çok model yer alıyorken, E5-2600v4 serisinde, çekirdek sayıları bazında anlam ifade edeceğini düşündüğüm modelleri aşağıdaki gibi sıralayabilirim. Özellikle üzerinde çalışacak sanal uygulamaların lisanslama modelleri doğrultusunda, Frequency Optimized veya Segment Optimized işlemciler, daha sık tercih edilmesi muhtemel işlemciler gibi görünüyor. Bir sonraki yazımda lisanslama konusunu daha detaylı ele almayı planlıyorum.

Intelv4-3

 

Kategoriler:VMware Etiketler:

198: ESXi 6.0, WSFC ve vMotion çözümü

Haziran ayı içerisinde, ESXi 6.0 sunucular üzerinde konumlandırdığım bir Windows 2012 R2 + SQL Server kümesinde vMotion yaparken SQL servislerinin fail olması ile ilgili bir yazı yazmış ve problemin bir PR (persistent reservation) sorunu olduğundan bahsetmiştim, buradan erişebilirsiniz. Ağustos ayı başında çıkan “ESXi 6.0 Patch 3” ile bu problemin adreslendiğini görmek ise beni fazlasıyla mutlu etti. Patch 3 içerisinde gelen kritik bugfix detaylarına buradan ulaşabilirsiniz. Ancak beni ilgilendiren madde aşağıdaki madde oldu;

When the Path Selection Policy is set to Round Robin, performing vMotion of active node results in the SQL database to become inaccessible. Attempts of writes to the database will fail. The cluster resources will appear failed. Also, the NTFS error 140 and the cluster event ID 1069 are registered.

Elbette ilk iş sunucuları güncelledim ve vMotion sonrasında ne SQL hatası, ne NTFS 140 hatası ne de vmkernel logları içerisinde problem teşkil edebilecek SCSI Sense Code gördüm. SCSI kodlarından geçen yazıda kısaca bahsetmiştim, konu da hazır vMotion noktasına gelmişken, vMotion operasyonlarınızın sağlık durumunu ve loglamasının nasıl yapıldığına yer verip, bu yazıyı bağlamak niyetindeyim.

Uçtan uca bir vMotion operasyonunu ele aldığımızda, aslında sanal sunucunun sağlığı ile yakından alakalı, göz önünde bulundurmamız gereken iki adet kritik değer var, vMotion trafiğinin bandwidth’i ve sanal sunucunun stun süresi, yani cevap veremediği süre. Kullanılabilir bandwidth ne kadar yüksek olursa, stun süresi o kadar düşük olacaktır. 10G interface kullanmak, jumbo frame veya multi-nic vmotion yapılanmaları bize bunu sağlayacaktır. Stun süresini etkileyen bir diğer parametre de, precopy (ilk bellek bloklarının kopyalanması) sonrası ne kadar kirli bellek kaldığının miktarıdır. Bilindiği gibi, vmkernel precopy sonrası bir hesaplama yapar, eğer gözlemlediği bandwidth ile, kalan kirli bellek bloklarını 500ms ‘nin altında bir sürede taşıyabileceğini hesaplar ise, sanal sunucuyu dondurur (stun) ve vMotion işlemini gerçekleştirir. Eğer isterseniz 500ms değerini Migrate.PreCopySwitchoverTimeGoal parametresi ile değiştirebilirsiniz. Ancak yanlış anlaşılmasın, burada her vMotion operasyonunun 500ms altında tamamlanacağı garanti edilmez, bu sadece precopy esnasında yapılmış bir hesaplamadır. Sunucu dondurulup kopyalama başladığında, değişen network koşulları operasyonun daha uzun sürmesine ve hatta sanal sunucunun saniye mertebesinde stun konumunda kalmasına sebebiyet verebilir.

Bahsettiğim iki parametrenin sayısal takibinin en kolay yolu vRealize Log Insight ürünü ile takip etmektir. Hazır gelen dashboard’lar içerisinde vMotion’a özel bir dashboard bulunmaktadır ve vMotion operasyonlarının detaylarına kolay bir şekilde ulaşabilirsiniz (süreler ms cinsindedir).

vmotion-1

Eğer bir şekilde ortamınızda vRealize Log Insight yok ise, ESXi sunucularının log dosyalarında biraz efor ile benzer bilgilere ulaşabilirsiniz. ESXi 6.0 üzerinde vMotion detaylarına ulaşabileceğiniz log dosyaları; vmware.log, vmkernel.log ve vpxa.log dosyalarıdır.

Öncelikle yapılan vmotion operasyonunun id’si işinize yarayacaktır çünkü tüm loglar bu id ile loglanır. Böylelikle farklı log dosyalarında bu id aracılığı ile aynı vmotion operasyonunu izlediğinizden emin olursunuz. Bu id’yi sanal sunucunun vmware.log dosyaları içerisinden alabilirsiniz.

[root@esx02:/vmfs/volumes/…./VM01] cat vmware-272.log | grep “migration id”
Migrate_Open: Restoring from <192.168.0.15> with migration id 1471495441309585

Bu noktadan sonra, geri kalan log dosyaları içerisinde operasyon ile ilgili detaylı bilgilere ulaşabilirsiniz.

Kaynak ESXi Sunucusu:

[root@esx03:/var/log] cat vmkernel.log | grep 1471495441309585
Migrate: vm 822434: 3385: Setting VMOTION info: Source ts = 1471495441309585, src ip = <192.168.0.15> dest ip = <192.168.0.13> Dest wid = 840083 using SHARED swap
MigrateNet: 1468: 1471495441309585 S: Successfully bound connection to vmknic ‘192.168.0.15’
MigrateNet: 1468: 1471495441309585 S: Successfully bound connection to vmknic ‘192.168.0.15’
VMotionUtil: 3995: 1471495441309585 S: Stream connection 1 added.
MigrateNet: 1468: 1471495441309585 S: Successfully bound connection to vmknic ‘192.168.1.15’
VMotionUtil: 3995: 1471495441309585 S: Stream connection 2 added.
VMotion: 4693: 1471495441309585 S: Stopping pre-copy: only 45003 pages left to send, which can be sent within the switchover time goal of 0.500 seconds (network bandwidth ~1719.506 MB/s, 163513% t2d)
VMotionSend: 4161: 1471495441309585 S: Sent all modified pages to destination (network bandwidth ~1846.259 MB/s)
VMotionUtil: 6170: 1471495441309585 S: Socket 0x430798b66780 rcvMigFree pending: 90576/90648 snd 0 rcv

Hedef ESXi Sunucusu:

[root@esx02:/vmfs/volumes/…./VM01] cat /var/log/vmkernel.log | grep 1471495441309585
Migrate: vm 840083: 3385: Setting VMOTION info: Dest ts = 1471495441309585, src ip = <192.168.0.15> dest ip = <192.168.0.13> Dest wid = 0 using SHARED swap
MigrateNet: 1468: 1471495441309585 D: Successfully bound connection to vmknic ‘192.168.0.13’
VMotionUtil: 3995: 1471495441309585 D: Stream connection 1 added.
VMotionUtil: 3995: 1471495441309585 D: Stream connection 2 added.
VMotionRecv: 659: 1471495441309585 D: Estimated network bandwidth 1719.492 MB/s during pre-copy
VMotionRecv: 2493: 1471495441309585 D: DONE paging in
VMotionRecv: 2501: 1471495441309585 D: Estimated network bandwidth 1844.010 MB/s during page-in
VMotion: 6039: 1471495441309585 D: Received all changed pages.

[root@esx02:/vmfs/volumes/…./VM01] cat /var/log/vpxa.log | grep 1471495441309585
[MIGRATE] (1471495441309585) PrepareDestinationEx start
[MIGRATE] (1471495441309585) srcIp 192.168.0.15
[MIGRATE] (1471495441309585) dstIp 192.168.0.13
[MIGRATE] (1471495441309585) srcLoggingIp
[MIGRATE] (1471495441309585) dstLoggingIp
[MIGRATE] (1471495441309585) PrepareDestinationEx finish
[MIGRATE] (1471495441309585) InitiateDestination start
[MIGRATE] (1471495441309585) dstConfigPath ds:///vmfs/volumes/…./VM01/VM01.vmx
[MIGRATE] (1471495441309585) localConfigPath /vmfs/volumes/…./VM01/VM01.vmx
[MIGRATE] (1471495441309585) immigrating VM at path /vmfs/volumes/…./VM01/VM01.vmx has vmid 12
[MIGRATE] (1471495441309585) dstId 840083
[MIGRATE] (1471495441309585) InitiateDestination finish
[MIGRATE] (1471495441309585) tracking progress at destination…
[MIGRATE] (1471495441309585) finished tracking
[MIGRATE] (1471495441309585) getting/awaiting vmid
[MIGRATE] (1471495441309585) vmIdAcquireTimeout:: 60
[MIGRATE] (1471495441309585) vmid 12
[MIGRATE] (1471495441309585) vmotion result has downtime value 459754
[MIGRATE] (1471495441309585) CompleteDestination start
[MIGRATE] (1471495441309585) VM present

Son olarak benzer şekilde hostd.log dosyası içerisinde de benzer sorguyu yapabilirsiniz, burada operasyonun detaylı içeriği değil, task ile ilgili yüzeysel bir takım bilgilere ulaşabilirsiniz (hangi kullanıcı başlattı, hangi parametreler ile başlattı, başarılı tamamlandı mı gibi).

Kategoriler:VMware Etiketler:

197: PhotonOS v1.0

Photon-1Geçen sene, özellikle VMworld 2015 sonrası, beni en çok etkileyen konular container ve CNA (cloud native apps) alanındaki gelişmeler olmuştu ve bu vizyonu kısaca kaleme almaya çalışmıştım (buradan erişebilirsiniz). Yakın zaman içerisinde de, VMware’ın 2015 Nisan ayında duyurusunu yaptığı, bu alandaki en önemli bileşenlerinden biri olan Photon OS’un GA sürümü yayınlandı. Photon OS, vSphere platformu için optimize edilmiş, açık kaynak, minimal bir ayak izine sahip olan ve üzerinde Docker, Rocket (rkt), Garden formatlarında container yapılarını çalıştırılabilen, Linux tabanlı bir sistemdir.

Photon’u vSphere platformunuzda çok basit bir şekilde ayağa kaldırabilirsiniz. Bunun için tek ihtiyacınız olan, GitHub üzerinden ister ISO formatında, ister OVA formatında gerekli bileşenleri indirip kurulumu gerçekleştirmek. Ben biraz daha açıklayıcı olabilmesi adına ISO formatını tercih edeceğim çünkü OVA ile hazır appliance kurulumu yapıldığından aradaki az sayıda olan adımı da göremeyeceğiz.

Öncelikle manuel bir sanal sunucu oluşturarak işe başlayabiliriz. Sanal sunucuyu oluştururken aşağıdaki değerleri kullandım. Bu arada CPU ve RAM kaynaklarının aslında üzerinde koşturulması planlanan container uygulamaları doğrultusunda şekillendirilmesi uygun olacaktır.

  • Disk alanı: 8GB ancak kuracağımız Photon tipine göre değişebilir
  • Compatibility: Hardware Level 11 (ESXi 6.0)
  • Guest OS Version: Other 3.x or later Linux (64-bit)
  • vCPU: 1
  • vRAM: 384 MB

Sonrasında ISO’yu sunucuya mount edip, kuruluma başlayabiliriz. Welcome page, license agreement ve disk formatlama ile ilgili kısımları geçersek, bize soracağı en önemli soru aşağıdaki olacaktır.

Photon-2

  • Photon Minimal: Üzerinde container çalıştırabilmek adına, Photon’un en düşük ayak izine sahip versiyonu (yaklaşık 60 MB). Bu sayede uygulamanız için hem en iyi performans sağlayanacak hem de en hızlı şekilde çoğaltabileceksiniz.
  • Photon Full: Container host runtime özellikleri haricinde, yeni uygulamalarınızı da paketlemenizi ve container olarak çalıştırabilmenizi sağlayan bileşenleri de içerir. Eğer amacınız test etmek veya yeni container uygulamaları oluşturmak ise uygun olacaktır. Yaklaşık 128 MB’lık bir ayak izine sahiptir.
  • Photon OSTree Host: OSTree, işletim sisteminin dosya yapısını, read-only bir şekilde ve versiyonlanabilir, merkezi bir yapı üzerinden dağıtımını ve sync edilmesini sağlayan bir mekanizmadır. Ne tam olarak bir paket dağıtım mekanizması ne de disk imajlarını yönetim şeklidir. İkisi arasında bir yerdedir. Burada da Photon’un OSTree mekanizmasını destekleyen client versiyonunun kurulumu hedeflenmektedir.
  • Photon OSTree Server: Oluşturulmuş Photon OSTree Host’lar için repository görevi görmek amacı ile oluşturulabilecek profildir.

Bu noktada Photon Full ile devam ediyorum. Sunucu adı ve root şifresi bilgilerini girdikten sonra kurulum başlayabilir. Full versiyonunun kurulumu tam olarak 172 saniye sürdü. Minimal versiyon ise çok çok daha hızlı olacaktır.

Photon-3

Varsayılan olarak, sunucu DHCP’den IP alması üzerine tasarlanmıştır, olması gereken de bu şekildedir. Ancak biz bu ilk örneğimizde statik IP ile devam ediyoruz. Bunun için tanımlamaları yapacağımız ayrı bir .network dosyası yaratabileceğimiz gibi, varolan /etc/systemd/network/10-dhcp-en.network dosyası güncelleyerek de ilerleyebiliriz. Kolay olması açısından, dosyayı aşağıdaki şekilde güncelliyorum.


[Match]
Name=eth0

[Network]
Address=192.168.0.2/24
Gateway=192.168.0.1
DNS=192.168.0.10
NTP=192.168.0.10

Sonrasında systemctl restart systemd-networkd komutu ile bu tanımın aktif olmasını sağlamalıyız. Servis yeniden başladığında .network uzantılı dosyaları alfabetik olarak tarayacak ve dosyalar içerisinde yazılmış “match” kuralları doğrultusunda ilgili interface’in tanımlamalarını yapacaktır. Bu dosyalar içerisinde yapabileceğiniz çok detaylı tanımlamalar için buradan bilgi alabilirsiniz.

Photon-4

Sistem üzerinde daha rahat çalışabilmek için root kullanıcısına SSH yetkisi vermek de anlamlı olacaktır. Bunun için, /etc/ssh/sshd_config dosyası içerisinde PermitRootLogin değerini yes olarak güncellemek ve SSH servisini yeniden başlatmak yeterli olacaktır.

Photon-5

Photon OS ile ilgili en temel gereksinimlerimizi karşıladığımıza göre, bu sunucu üzerinde hangi komutlar ile neler yapabiliriz, onlara kısaca bakalım ve şimdilik burada bırakalım.

Örnek docker komutları:

  • systemctl start docker: Docker servisini başlatır
  • systemctl enable docker: Docker servisinin sunucu ile başlamasını sağlar
  • docker images: Lokalde bulunan docker imajlarını listeler
  • docker run -d -p 80:80 vmwarecna/nginx: Arka planda yeni bir docker container başlatır
  • docker info: Container host sunucusunun bilgilerini listeler.
  • docker ps: Docker proseslerini listeler
  • docker stop <id>: Docker prosesini durdurur
Kategoriler:VMware Etiketler:, ,

196: ESXi 6.0, WSFC ve vMotion sorunu

15.06.2016 3 yorum

Mart ayı içerisinde, vSphere 6.0 platformu üzerinde Windows 2012 R2 Failover Cluster yapılanması ile ilgili bir yazı yazmış ve dikkatimi çeken konulara değinmiştim (buradan erişebilirsiniz). Tüm bu yapılanma içerisinde beni en çok heyecanlandıran konu ise, vSphere 6.0 ile birlikte WSFC (Windows Server Failover Cluster) vMotion desteğinin gelmiş olmasıydı. Biz de VMware’ın dokümanları doğrultusunda test ortamımızı hazırladık, testimizi gerçekleştirdik ve CAB (Cluster Across Box) yapısında tanımladığımız sanal sunucunun başarılı bir şekilde vMotion yapılabildiğini gördük. Herşey gayet güzel idi, SQL admininin “Bir sorun var” demesine kadar !!!

Kontrol ettiğimizde SQL veritabanları gerçekten dağılmış görünüyordu. Örnek olarak master veritabanı ile ilgili aşağıdaki mesajlar konunun ciddiyetini gösterir nitelikte.

2016-04-21 12:25:00.66 spid6s Starting up database ‘master’.
2016-04-21 12:25:00.70 spid6s SQLServerLogMgr::FixupLogTail (failure): alignBuf 0x000000000901B000, writeSize 0x1c00, filePos 0x2602400
2016-04-21 12:25:00.70 spid6s blankSize 0x3c0000, blkOffset 0x412, fileSeqNo 2513, totBytesWritten 0x0
2016-04-21 12:25:00.70 spid6s fcb status 0x100042, handle 0x00000000000004C4, size 7208 pages
2016-04-21 12:25:00.70 spid6s Error: 17053, Severity: 16, State: 1.
2016-04-21 12:25:00.70 spid6s FixupTail: Operating system error 170(failed to retrieve text for this error. Reason: 15100) encountered.
2016-04-21 12:25:01.71 spid6s Error: 17053, Severity: 16, State: 1.
2016-04-21 12:25:01.71 spid6s FCB::ZeroFile(), GetOverLappedResult(): Operating system error 170(failed to retrieve text for this error. Reason: 15105) encountered.
2016-04-21 12:25:01.71 spid6s Cannot recover the master database. SQL Server is unable to run. Restore master from a full backup, repair it, or rebuild it

İşletim sistemi seviyesinde kontrol ettiğimizde ise NTFS 140 hatalarının sıklıkla tekrarlandığını gördük. Bu hata filesystem üzerinde diske flush edilemeyen bir veri olduğunu bize gösteriyor. Böyle bir durum SQL veritabanının bulunduğu diskler üzerinde gerçekleştiğinde de veritabanı açılamıyor.

WSFC2

Gelelim vSphere katmanına. ESXi sunucusu olarak testte 6.0 Update 2 Build 3380124 versiyonunu kullandık. Problem esnasında karşılaşmış olduğumuz aşağıdaki VMkernel logları, bize problem ile ilgili biraz daha net veriler sunmaya başladı.

2016-04-21T09:13:12.334Z esx01 vmkernel: cpu35:33550)ScsiDeviceIO: 2613: Cmd(0x43a6015c4180) 0x84, CmdSN 0x1b0ea9 from world 0 to dev “naa.60000970000296700072533030313837” failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x6 0x2a 0x5.
2016-04-21T09:07:01.030Z esx02 vmkernel: cpu5:33549)ScsiDeviceIO: 2613: Cmd(0x439e1679c000) 0x28, CmdSN 0xffffe0015529d600 from world 642979 to dev “naa.60000970000296700072533030313030” failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x6 0x2a 0x5.
2016-04-21T09:07:01.028Z esx02 vmkernel: cpu5:33549)NMP: nmp_ThrottleLogForDevice:3286: Cmd 0x28 (0x439e16a26540, 642979) to dev “naa.60000970000296700072533030313030” on path “vmhba2:C0:T1:L39” Failed: H:0x0 D:0x2 P:0x0 Valid sense data: 0x6 0x2a 0x5. Act:NONE
2016-04-21T08:25:16.740Z esx02 vmkernel: cpu0:33547)NMP: nmp_ThrottleLogForDevice:3270: Cmd 0x5f/0x6 (0x439e1900bd00, 642979) to dev “naa.60000970000296700072533030313837” on path “vmhba2:C0:T1:L6” Failed: H:0x0 D:0x0 P:0x4 Possible sense data: 0x6 0x2a 0x4. Act:NONE

Bu esnada farklı varyasyonlarda testlerimizi gerçekleştirdik ve aşağıdaki bulgulara ulaştık;

  • VMware NMP ile birlikte PSP olarak RoundRobin kullanırsak problem yaşadık.
  • VMware NMP ile birlikte PSP olarak Fixed kullanırsak problem yaşamadık
  • Powerpath ile birlikte symmetrix optimized policy kullanırsak problem yaşamadık.

SCSI Sense Code’ları incelediğimizde genel olarak karşımıza iki tip mesaj çıkıyor; 0x6 0x2a 0x4 (RESERVATIONS RELEASED) ve 0x6 0x2a 0x5 (REGISTRATIONS PREEMPTED). Tüm bu bulgular, SCSI-3 rezervasyonlarının yönetimi konusunda sıkıntı yaşandığını gösteriyor.

SCSI rezervasyonları, bir SCSI diskine erişimleri düzenleyen ve birim zamanda tek bir initiator tarafından güncellenmesini sağlayan bir mekanizmadır (file locking gibi düşünülebilir). Günümüzde tüm sistemler SPC-3 uyumludur ve SCSI-3 Persistent Reservation komut setlerini desteklerler. SCSI-3 Persistent Reservation çalışma mekanizması registration ve reservation sistemi üzerine kuruludur. Diske erişen sistemler kendilerini, özel bir key ile, LUN’a register ettirirler. Sadece register olmuş sistemler, disk üzerinde rezervasyon koyma yetkisine sahip olurlar. Bu şekilde bir diske erişimi engellemek, bu initiator’ın kayıt bilgisini silmek kadar kolay bir hale gelir ve bunu da sadece daha önceden kayıt olmuş initiator’lar gerçekleştirebilir. NetApp’ın bir makalesinden aldığım aşağıdaki görsel de durumu biraz daha açıklıyor.

WSFC3

Bizim senaryomuzda ise durum biraz daha karışık. SCSI-3 rezervasyonlarını koyan ve yöneten Windows Sunucusu. Zaten ESXi sunucular üzerinde WSFC çalıştırabilmek için physical RDM kullanmamızın gerekliliği buradan gelir, diske direk erişip SCSI-3 rezervasyonlarını yönetebilmek. Ancak MPIO yönetimi de Windows’da değil, bunu da sağlayan VMware NMP’si. Dolayısı ile hipervizörün, VM’den gelen persistent reserve in ve persistent reserve out komutlarını doğru şekilde disk ünitesine yönlendirmesi gerekmektedir. Görünüşe göre vMotion esnasında, anlık da olsa, göndermesi gereken registeration ve reservation komutlarını doğru gönderemiyor ve sonucu SQL servislerinin fail olmasına kadar varan I/O problemleri yaşanıyor.

Sonuç olarak, tüm bu bilgiler ışığında, bu durumun bir “known issue” olduğu ve ESXi 6.0 Patch 3 ile giderilmesinin beklendiği bilgisine ulaştık. Bunun üzerine çok fazla detay alamadım ve dolayısı ile bu problemin ne kadar yaygın olduğunu bilemiyorum veya ne kadar bize özel olduğunu. Eğer sizin elinizde de bir takım geri bildirimler varsa, bunları duymak isterim. Ancak görünen o ki, Patch 3 çıktığında durumu yeniden detaylı incelemek gerekecektir.

Kategoriler:VMware Etiketler:

195: VAMI sertifika güncellemesi

vSphere 6.0 ilk çıktığı zamanlarda beni en çok heyecanlandıran özelliklerinden biri VMCA (VMware Certification Authority) olmuştu ve bunun ile ilgili bir yazı yazmıştım, buradan erişebilirsiniz. Bunun sebebi hangi uygulamayı kullanırsanız kullanın, kullanılan sertifikaların güvenlik gereği kurumsal bir CA tarafından imzalanmış olan bir sertifika ile değişmesi gerekliliğine olan inancım ve vSphere 6.0 öncesinde maalesef bunun tam bir zulüm olması. PSC (Platform Services Controller) bünyesinde yer alan VMCA servisini eğer kurumsal CA yapınızda orta kademe CA olarak tanımlayabilir iseniz, hem sertifika üretimini otomatize etme şansını yakalayabilir hem de üretilen sertifikanın domain’inizde trusted olmasını sağlayabilirsiniz. Sonuç olarak aşağıdaki gibi bir sertifika zinciri oluşacaktır.

VMCA4

Bu yapının oluşturulmasını detaylandırmayacağım. VMware’ın bu konuda güzel yazılmış bir makalesi bulunuyor (KB2112016). Buraya kadar herşey çok güzel görünüyor. Ancak yakın zamanda, 6.0 Update2 ile tanımlamaları yaptığımda, VMware’ın bir noktayı atladığını farkettim. Bu noktayı açıklayabilmek için, mekanizmadan kısaca bahsetmemde fayda var.

vSphere 5.5’de sertifikalar ile uğraşmış olanlar hatırlar, tüm servisler için ayrı sertifika oluştururduk; vpxd, inventory service, log browser, auto deploy ve update manager.  vSphere 6.0 ile birlikte bir adet reverse HTTP proxy servisi geliştirildi (rhttpproxy) ve erişimlerde diğer servisler bu servisin arkasına alındı. Dolayısı ile sadece reverse proxy servisinin sertifikasının güncellenmesi, güvenli erişiminizi sağlayacaktır. Yine bu yüzdendir ki, artık webclient erişimi için 9443 portuna ihtiyacımız kalmadı, rhttpproxy servisine 443 ile bağlanıp, webclient’a erişebiliyoruz.

VMCA6

Şimdi eksik kalan noktaya gelelim. vSphere 6.0 ilk çıktığında, 5480 portu üzerinden hizmet veren VAMI (vCenter Server Appliance Management Interface) kaldırıldı. Sonra gelen geribildirimler doğrultusunda Update1 sürümü ile yeniden eklendi. Ancak diğer servisler gibi reverse proxy arkasına değil, eskiden alıştığımız şekilde 5480 portu üzerinden hizmet vermeye devam etti. Dolayısı ile bu servisin de manuel olarak sertifikasının güncellenmesi ihtiyacı doğdu.

Dikkat: Bu yazının yazıldığı gün itibari ile, konu ile ilgili yazılmış herhangi bir makale veya blog bulamadım, dolayısı ile yapılan aşağıdaki konfigürasyon VMware tarafında %100 desteklenir olmayabilir.

  • Reverse Proxy için oluşturmuş olduğunuz sertifikadan, VAMI hizmetini veren vami-lighttpd için de bir sertifika oluşturulur.

ORIG_CERT=”/etc/applmgmt/appliance/server.pem”
RHTTPPROXY_CERT=”/etc/vmware-rhttpproxy/ssl/rui.crt”
RHTTPPROXY_KEY=”/etc/vmware-rhttpproxy/ssl/rui.key”
cat $RHTTPPROXY_CERT $RHTTPPROXY_KEY > $ORIG_CERT

  • lighttpd konfigürasyon dosyasına aşağıdaki satır eklenir.

Dosya adı: /opt/vmware/etc/lighttpd/lighttpd.conf
Tanım: ssl.ca-file = “/etc/applmgmt/appliance/vmca.crt”

  • Elinizdeki vmca sertifikası yukarıdaki path’e kopyalanır, vmca.crt olarak.
  • VAMI servisi yeniden başlatılır.

service vami-lighttpd restart

Bu adımlardan sonra 5480 portu üzerinden gerçekleştirdiğiniz erişimleri de düzgün bir şekilde şifrelemiş olacaksınız.

vmca7

Kategoriler:VMware Etiketler:, ,

194: VM üzerinde “disabled” metodlar

Yakın zamanda yeniden karşılaştığım, eğer snapshot temelli yedekleme yazılımları kullanıyorsanız muhtemelen sizin de karşılaşabileceğiniz bir senaryodan kısaca bahsetmek istiyorum, biraz da arkasındaki mantıktan. Öncelikle semptomumuz şu şekilde; elimizde bir VM var, svMotion yapmak istiyorsunuz ancak aşağıdaki hata ile karşılaşıyorsunuz;

DisabledMethod1

Method olarak burada bahsedilen nedir ve Avamar bunu neden disable etmiştir, bunu açıklamaya çalışalım. Bir sanal sunucu üzerinde onlarca gerçekleştirebileceğimiz işlem vardır, bunları her gün vSphere Client veya Web Client üzerinden gerçekleştiriyoruz. Her bir işlem arka tarafta API Method‘larına tekabül eder (vSphere6 için tanımlı metodlara buradan erişebilirsiniz). Ancak her metodu her zaman çağıramazsınız, örnek olarak svMotion yaptığınız bir VM’de sağ tıkladığınızda bir çok aksiyonu aşağıdaki gibi kapalı görürsünüz. Çünkü bu API metodları vCenter tarafında geçici olarak disable edilmiştir.

DisabledMethod2

vCenter hangi VM’de hangi işlemin yapılamayacağı bilgisini VPX_DISABLED_METHODS isimli bir tabloda tutar ve işlem tamamlanınca burayı yeniden günceller. Herhangi bir VM’in, o an için hangi metodlarının disable olduğunu powerCLI ile de görebilirsiniz.

DisabledMethod3

Snapshot temelli yedekleme yazılımları da yedek alırken veya restore yaparken bu mekanizmayı kullanarak belli işlemlerin yapılmasını engeller, sunucunun svMotion ile taşınması gibi. Bir şekilde bu komutu gönderebilseniz bile size hata verecektir. İşlem tamamlanınca da, yedekleme yazılımı vCenter’a disable ettirdiği metodun (RelocateVM_Task) yeniden enable edilmesini sağlar. Ancak zaman zaman bu iletişimde problem oluşur ve svMotion metodu yeniden aktif hale gelmez. Böyle bir durumda deneyebileceğiniz bir kaç aksiyon var. Bunlar;

  • VM’i unregister/register yapmak. Bu durum hem offline bir işlemdir hem de istatistik bilgilerine, custom field verilerine ve history verilerine veda etmeniz gerekir.
  • vCenter veritabanında vpx_disabled_methods tablosundan kayıt silmek. Bu durum vCenter veritabanınızın kapalı olmasını gerektirecektir, üretim ortamı için çok uygulanabilir bir yöntem değil. Ancak yine de yapmak isterseniz, veritabanı yedeğinizi aldıktan sonra, aşağıdaki komutlar yardımıyla yapabilirsiniz. İlk komut VM-ID’yi elde etmenizi sağlar, ikinci komut ise silme işlemini gerçekleştirir.
    • select * from VPX_VM WHERE FILE_NAME LIKE ‘%VMName%’;
    • delete from VPX_DISABLED_METHODS WHERE ENTITY_MO_ID_VAL = ‘vm-ID’;
  • İlgili yedekleme yazılımından yeniden yedek başlatmak. Az sayıda VM bu durumdan muzdarip ise en mantıklı senaryo bu olabilir. Yedekleme sürecinin sonunda ilgili yedekleme yazılımı, disable edilmesini sağladığı metodların yeniden enable edilmesini de tetikleyecektir.
Kategoriler:VMware Etiketler:,

193: HTML5 destekli yeni WebClient

29.03.2016 1 yorum

Eğer gelişmeleri yakından takip ediyorsanız büyük olasılıkla VMware’ın dün yayınlanan son fling’ini duymuşsunuzdur; vSphere HTML5 Web Client. Bildiğiniz gibi kullanılan Web Client versiyonları Flash ve uzantılarını kullanmaktadır. Flash’in yerini yavaş yavaş HTML5’e bıraktığı bugünlerde, VMware de Web Client arayüzünde bu değişimin ilk sinyallerini vermeye başladı ve henüz üretim ortamları için hazır olmayan ancak kurup deneyebileceğiniz ürünü piyasaya sürdü (buradan erişebilirsiniz).

Bu yeni Web Client aslında vCenter kurulumları ile birlikte kurduğunuz Web Client uygulamasını bypass ediyor ve direk SSO ile konuşup, sizi diğer kaynaklara eriştiriyor. Normalde vCenter mimarisinin bileşenlerini ve yeni HTML5 Web Client’ın nereye oturduğunu aşağıda daha net görebilirsiniz. Bu yeni Web Client servisi bir OVF template olarak gelmektedir. Kurulumu ve konfigürasyonunu tamamladığınızda, güncel tarayıcınız ile normalde kullandığınız Web Client’a değil, kurulumunu yaptığımız bu yeni servise 9443 portundan erişmeniz gerekecektir. Bu topolojinin güzel tarafı, vCenter tarafında çok basit bir değişiklik haricinde önemli bir konfigürasyon yapmaya gerek duymamanız. Bu arada hatırlatmakta fayda var, sadece vCenter 6.0 desteği söz konusu.

HTML5WebClient

Kurulum aşaması, normal bir OVF kurulumundan farklı değil. Bu esnada size ekstradan sadece IP adresini soruyor. Yaklaşık 1 dakika içerisinde de power verilebilir duruma geliyor. Ancak ilk power denemenizde muhtemelen aşağıdaki gibi bir hata ile karşılaşacaksınız.

HTML5WebClient2

Bunun sebebi, elbette bir sunucuyu ayağa kaldırmak için IP adresinden fazlasına ihtiyaç duyacak olmanız, hatırlarsanız bize ne Gateway, ne Subnet Mask ne de DNS sormuştu. Bu noktada beklentisi, sunucuyu tanımlamış olduğunuz portgroup’un bir IP Pool ile eşleştirilmiş olması ve geri kalan TCP/IP parametrelerini bu IP Pool’dan alması. Dolayısı ile vSphere ortamınızda, datacenter objenizi seçer, bir IP Pool oluşturur ve bu portgroup’a bağlarsanız, sunucunuz açılacaktır.

Sunucu açıldıktan sonra, 5480 portu üzerinden erişilebilir bir yönetim arayüzü sağlayacaktır ancak diğer appliance ürünlerinde olduğu gibi çok kapsamlı bir arayüz beklemeyin, sadece görmüş olmak için bağlanıp inceleyebilirsiniz. Varsayılan kullanıcı adı root ve şifresi de demova ‘dır.

Şimdi gelelim ihtiyacımız olan bir iki küçük konfigürasyonu yapmaya. Öncelikli olarak yeni kurduğumuz Web Client appliance’a SSH yapmamız gerekecektir. Appliance NTP tanımları yapılmamış olarak gelecektir, SSO entegrasyonunda zaman senkronizasyonu önemli olacağından dolayı ilk olarak NTP sunucusu tanımlamanızda fayda var. Aşağıdaki komut ile bunu yapabilirsiniz. Bu komut sonrası /etc/ntp.conf dosyasını kontrol ederseniz, aşağıdaki IP adreslerinin NTP sunucusu olarak tanımlandığını görebilirsiniz.

/etc/init.d/vsphere-client ntp_servers 10.20.30.1,10.20.30.2

İkinci aşamada Web Client appliance’ın hangi vSphere platformu ile entegre olacağını tanımlamanız gerekmektedir. Bunu aşağıdaki şekilde tanımlayabilirsiniz. Yaklaşık 2-3 dakikalık bir süreç sonrasında komut başarılı bir şekilde tamamlanacaktır. Bu arada yine hatırlatayım, bu yazdıklarım vCenter Server Appliance (VCSA) için geçerli. Hala Windows kullanıyorsanız adımlarda ufak farklılıklar olacaktır, fling sayfasından detaylara ulaşabilirsiniz.

/etc/init.d/vsphere-client configure –start yes –user root –vc <vCenter_IP_adres>

Yukarıdaki komut, eğer VCSA sunucunuzda root kullanıcısının varsayılan shell’i bash değil, appliancesh ise komut başarılı tamamlanamayacaktır. Bilindiği üzere, VCSA’nın vSphere 6.0 sürümünden sonrasında özel ve kısıtlı bir shell konumlandırıldı (appliancesh) ve root ile bağlandığınızda otomatik olarak buraya düşmeniz sağlandı. Normal bash’e geçmek için öncelikle bash’i etkinleştirmeniz gerekmektedir. Sonrasında da root’un varsayılan shell’ini bash olarak değiştirmelisiniz. Aslında vCenter tarafında yapılması gereken tek tanımlama budur.

shell.set –enable True

shell

/usr/bin/chsh -s “/bin/bash” root

Bu tanımlamayı yapıp, vCenter ile Web Client HTML5 appliance sunucusunu eşleştirdiğinizde artık hazırsınız demektir. Sunucunun 9443 portundan bağlantı sağlayabilirsiniz (https://SunucuIP:9443/ui). Login sonrası sizi aşağıdaki gibi bir arayüz karşılayacaktır.

HTML5WebClient3

Öncelikle bunun çok kısıtlı bir platform olduğunu söylemeliyim. Fling sayfasında nelerin desteklendiğini bulabilirsiniz. Ancak kullanım esnasında dikkatimi çeken konu, normal Web Client’a göre çok daha hızlı olduğunu söyleyebilirim. Bunu elbette bir veri ile destekleyemiyorum, psikolojik de olabilir ancak bende yarattığı izlenim bu şekilde :)

ESXi Embedded Host Client fling’inde olduğu gibi, bunun da en popüler fling’ler arasına gireceği şimdiden kesin görünüyor. Kim bilir, belki bu sayede çok daha hızlı bir geliştirme sürecine girer ve üretim ortamlarında kullanıma hazır hale getirilir. Biz de Flash yerine HTML5 gibi güncel bir teknolojinin avantajlarından faydalanabiliriz.

Kategoriler:VMware Etiketler:,
Takip Et

Her yeni yazı için posta kutunuza gönderim alın.

%d blogcu bunu beğendi: