Başlangıç > VMware > 182: VM Component Protection (VMCP)

182: VM Component Protection (VMCP)

vSphere6 ile birlikte gelen, belki de en çok beklenen özelliklerden biri, vSphere HA’in bir alt bileşeni olan VM Component Protection (VMCP) özelliğidir. Tek bir cümlede ifade etmek gerekirse VMCP, All Paths Down (APD) ve Permanent Device Lost (PDL) durumlarında sanal sunucuları korumaya yönelik yapabileceğimiz ekstra tanımlamalardır. Konfigürasyon öğelerine geçmeden önce, kısaca bu tanımların üzerinden geçmekte fayda var.

PDL: Normalde ESXi sunucuları ile disk üniteleri, SCSI Sense Code diye isimlendirilen özel hexadecimal mesajlar ile birbirleri ile iletişim halindedirler. SCSI Sense Code ile ilgili VMware’ın makalesinden daha detaylı bilgilere erişebilirsiniz (KB289902). PDL durumu, disk ünitesinden, ilgili SCSI diskin erişilemediği ile ilgili bir kod dönmesi durumunda gerçekleşir. Bunun en sık karşılaşılan örneği, SAN admininin disk yada diskleri VMware admininden habersiz silmesi yada unmap etmesidir. Bu durumda, disk ünitesi aşağıdaki kodlardan birini gönderecek ve ESXi sunucusu da durumdan haberdar olup, disklere I/O talebinde bulunmayacak.

SCSI sense code Description
H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0 LOGICAL UNIT NOT SUPPORTED
H:0x0 D:0x2 P:0x0 Valid sense data: 0x4 0x4c 0x0 LOGICAL UNIT FAILED SELF-CONFIGURATION
H:0x0 D:0x2 P:0x0 Valid sense data: 0x4 0x3e 0x3 LOGICAL UNIT FAILED SELF-TEST
H:0x0 D:0x2 P:0x0 Valid sense data: 0x4 0x3e 0x1 LOGICAL UNIT FAILURE

APD: Eğer ESXi sunucusu disk ünitesine erişimi tamamen kaybetmiş ise ve ilgili SCSI diskler hakkında hiç bir SCSI kodu alamıyorsa, APD durumu oluşur. Bu durumda ESXi sunucusunun diskin durumu ile ilgili bir fikri olmayacağından dolayı, disklere komut göndermeye devam eder.

Peki bu durum neden bu kadar önemli? vSphere4 zamanlarına dönersek, bir VMware admininin belkide başına en sık gelen ve en çok can yakan konularından biriydi, VMware admininden habersiz diskin çekilmesi. Çünkü vSphere4 zamanında PDL özelliği henüz eklenmemişti. Diske erişim gittiğinde, ESXi sunucusu durumdan haberdar olmadığından sürekli diske komut gönderip, sonrasında VMkernel üzerindeki bir bug’dan dolayı da, inconsistent duruma düşüyordu. VMkernel’ın bu duruma düşmesi de, ESXi üzerinde yer alan tüm VM’lerde network sıkıntılarına sebebiyet veriyordu ve çoğu durumda vMotion bile yapamıyordunuz. Bu yüzden, uzun süre VMware’a açılan SR’larda en çok referans gösterilen makale, datastore olarak kullanılan bir diskin nasıl sağlıklı bir şekilde çekilebileceğini anlatan makale idi. Bu makalenin vSphere5/6 için karşılığına buradan erişebilirsiniz. Gayet uzun ancak son derece faydalı bir makaledir. vSphere5 ile birlikte neyseki PDL mekanizması getirildi ve artık daha önceleri APD olarak değerlendirilen durumların çoğu PDL olarak değerlendirilmeye başlandı.

Konudan kısaca bahsettikten sonra gelelim vSphere6’nın VMCP ile kattıklarına. Artık APD ve PDL durumlarını, sanal sunucu mertebesinde değerlendirebiliyoruz. Bunu gerçekleştirmek için yapılması gereken bir kaç basit tanım. Aşağıdaki ekran görüntüsü gerekli tüm tanımlamaları içeriyor.

VMCP1

Önce mekanizmadan bahsedelim. Varsayalım ki, datastore olarak kullanılan bir diske erişim sıkıntısı baş gösterdi. Öncelikle ESXi sunucusu, disk ünitesinde SCSI kodlarının gelip gelmediğine bakar. Eğer cevap alabiliyorsa, durumu PDL olarak değerlendirir ve sonrasında özel bir süreç işlemez. Ancak cevap alınamıyorsa, ESXi sunucusu I/O komutlarını göndermeye devam eder, ta ki APD Timeout diye isimlendirilen ve varsayılan olarak 140 saniye olarak tanımlı süre dolana kadar (bu süre istenirse Misc.APDTimeout parametresi ile değiştirilebilir). Bu süre APD durumunun ilanı için geçen süredir. Daha sonra, yukarıdaki ekranda da görebileceğiniz, 3 dakikalık süre başlar. Bu süre tamamlandığında da artık tanımlı aksiyonunu alabilir demektir. Bu süreç aşağıdaki gibi ilerlemektedir.

VMCP2

Gerek APD gerekse PDL durumlarında yapabileceğimiz temelde üç adet tanım var;

  • Disable: Bu durumda HA hiçbir şey yapmaz.
  • Issue Events: HA hiçbir şey yapmaz ancak konu ile ilgili bir notification oluşur.
  • Power Off and Restart VMs: SUnucuları başka ESXi sunucuları üzerinde ayağa kaldırmaya çalışır.

Bir senaryo da, APD_TIMEOUT ile HA_TIMEOUT arasındaki üç dakikalık zaman diliminde eğer problem giderilirse, nasıl aksiyon alınacağı ile ilgili. Burada yine hiçbir şey yapmamak bir opsiyon. Ancak bazı uygulamaların, disklerine erişimleri gittikten sonra yeniden ayağa kalkmaları problemli olabileceğinden, sunucuları direk resetlemek de alternatiflerimiz arasında. Elbette bu değerleri küme bazında tanımlayıp, VM bazında tekrar düzenleyebiliyoruz.

Son olarak, limitasyonlarından da bahsetmek gerekirse;

  • FT desteklenmemektedir. FT tanımlı bir sanal sunucu otomatik olarak disabled olarak tanımlanacaktır.
  • vVOL ve Virtual SAN gibi çözümler desteklenmemektedir.
  • RDM diskler desteklenmemektedir ve bu konuda bir koruma sağlanmayacaktır.
  • Eğer küme üzerinde Host Monitoring kapalı ise veya VM Restart Priority disabled durumda ise, yine bir koruma sağlanmayacaktır.
Kategoriler:VMware Etiketler:,
  1. Henüz yorum yapılmamış.
  1. No trackbacks yet.

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: