Başlangıç > VMware > 196: ESXi 6.0, WSFC ve vMotion sorunu

196: ESXi 6.0, WSFC ve vMotion sorunu

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:
  1. 15.06.2016, 08:11

    1-2 hafta önce Microsoft Cluster ile ilgili bir araştırma yaparken bir community’de yüksek latency’den dolayı tamda belirtmiş olduğunuz gibi sorun yaşayan bir post ile karşılaşmıştım. Ancak orada sorun PSP_RR yapılarak giderilebildiği belirtilmişti. Senin yaşadığın bu problemi PDL’e bir işaret diyebilirmiyiz?

    • 15.06.2016, 15:55

      PDL ile ilgili vmkernel loglarda bir iz göremedim, aksi taktirde SCSI kodları içerisinde PDL durumunu adresleyen mesajları görürdüm. SCSI kodları PR sorununu adresliyor görünüyor ki bana da mantıklı geldi.

  1. 18.08.2016, 08:41

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

w

Connecting to %s

%d blogcu bunu beğendi: