ESXi All Path Down ve Permanent Device Loss – Bölüm 1

Merhaba,

Bu yazımda sizlere All path down ve Permanent Device Loss yaşandığında yapılacak işlemlerden, log analizlerinden bahsedeceğim. Zaten bu bölümde ağırlıklı olarak log inceleme üzerinde duracağım. Benim lab ortamımda ISCSI datastore’lar bulunduğu için makaleyi’de ISCSI datastore’ları baz alarak yazıyorum. All Path Down ve Permanent Device Loss bunların arasındaki fark ile ilgili daha detaylı bilgiyi ayrı ayrı anlatacağım.

All path down ve  Permanent Device Loss senaryolarının 2 türü vardır planlı ve plansız yani ansızın zamanlarda oluşan problemler. Ben bu yazımda plansız zamanlarda oluşan APD ve PDL üzerinde duracağım. Eğer siz LUN’u planlı bir şekilde unmount ederseniz zaten herhangi bir sorun olmayacaktır ki buda zaten bilerek (planlı) yapılan bir işlemdir.

Bir ESXi host üzerinde beklenmedik bir şekilde LUN bağlantısı kaybolduğunda veya kesildiğinde bunun iki olası sonucu vardır. Host normal çalışmasına devam eder ancak host içerisindeki LUN gri renk olur yani kullanılmaz hale gelir. Zaten Path’lere bakıldığında, kaybolan LUN’un bağlı olduğu path unmounted olarak görülür. Bu durumda hala ESXi host’a vSphere Client ile bağlanıp normal bir şekilde çalışmaya devam edebilirsiniz. Diğer ihtimal ise; ESXi host’un bağlantısı kaybolur. Bu durum ile açıkcası pek karşılaşmak istemezsiniz. Bunu daha detaylı olarak aşağıda bahsedeceğim.

APD ve PDL durumlarında ESX’in neden kilitlendiğini merak ediyor olabilirsiniz. Kilitlenmenin sebebi, ESXi’in mevcut tüm kaynaklar ile LUN’a yeniden bağlanmaya çalıştığı içindir. Şimdi böyle bir durumda hatayı ayıklamak için yapmanız gereken SSH’a girmek olacaktır. Ancak SSH’a girmek için sunucu üzerinde SSH’ı açmanız gerekiyor ki herkes SSH’ı sürekli açık bırakmıyordur:) Bu durumda yapmanız sunucunuzun ILO veya IDRAC / KVM’den bağlanıp SSH’ı açmanız olacaktır. ESXi konsoluna ulaştığınızda öncelik ile yapmanız gereken 2 şey var. Bunlardan birtanesi SSH’ı açmak diğeri ise management agent’ı restart ederek LUN bağlanma işlemini kesebilirsiniz. Eğer sizin ESXi konsolu’da kilitlenmiş/donmuş ise yapacağınız tek şey ESXi host’u resetlemek olacaktır.

Şunuda belirtmek istiyorum. APD ve PDL’de 2 çeşit sonuç vardır. Bu sorun yaşandığında VM’leriniz ayakta olabilir ping atabilir ancak host’a bağlanamayabilirsiniz. Host, vCenter üzerinde disconnect gözükür ve Connect ile bağlamaya çalıştığınızda hata alırsınız. Ancak belirttiğim gibi virtual machine’lerde hiçbir kesinti olmaz. Bu durumda yapmanız gereken ILO veya IDRAC’dan sunucuyu resetlemek olacaktır çünkü ESXi konsoluna’da erişemezsiniz. Diğer durum ise; LUN’ların kaybolması ve virtual machine’lerine erişimin kesilmesidir ki asıl en büyük problem budur. Yine budurum yaşandığında ESXi host’a bağlanamazsınız ve ESXi’i reboot etmek durumunda kalırsınız.

APD ve PDL’i log dosyalarında görmek:

Bunun sonunca log dosyalarını incelemek ve bu durumu log’larda görmek isteyebilirsiniz. Ancak bu işlemleri gerçekleştirebilmeniz için host’un SSH’ı açık olması gerekmektedir. SSH’ımız açık ise; /var/log içerisindeki log’ları inceleyebiliriz. Burada inceleyeceğimiz log’lar aşağıdaki gibidir;

• hostd.log (ESX Service Log)
• vmkernel.log (VMKernel Messages)
• vmkwarning.log (VMKernel Warnings)

Yukarıdaki log’ların her biri bize APD veya PDL’in neden gerçekleştiğine dair ipucu verebiilr. Hatta bu log’lardan LUN’un neden kaybolduğunu bile tespit edebilirsiniz.

Hostd.log incelemek:

hostd.log içerisinde girdiğimizde aşağıdaki log’lar ile karşılaşıyoruz. Ben evdeki lab ortamımda APD ve PDL’i oluşturmak için storage üzerinden LUN’u disconnect hale getirdim. Sizde bunu kendiniz test edebilirsiniz.

Not: Gizlilik açısından aşağıdaki log’larda host ismini, datastore name’i ve lun id’leri değiştirdim.

timeofevent [77180B90 info 'VmkVprobSource'] VmkVprobSource::Post event: (vim.event.EventEx) {
dynamicType = ,
key = 1990376604,
chainId = 0,
createdTime = "2014-03-21T03:21:10Z",
userName = "",
datacenter = (vim.event.DatacenterEventArgument) null,
computeResource = (vim.event.ComputeResourceEventArgument) null,
host = (vim.event.HostEventArgument) {
dynamicType = ,
name = "esxi-host-name",
host = 'vim.HostSystem:ha-host',
},
vm = (vim.event.VmEventArgument) null,
ds = (vim.event.DatastoreEventArgument) {
dynamicType = ,
name = "datastore-name",
datastore = 'vim.Datastore:12312323-1234aaa9-a1a1-ac333a3a3ac3',
},
net = (vim.event.NetworkEventArgument) null,
dvs = (vim.event.DvsEventArgument) null,
fullFormattedMessage = ,
changeTag = ,
eventTypeId = "esx.problem.vmfs.heartbeat.timedout",
severity = ,
message = ,
arguments = (vmodl.KeyAnyValue) [
(vmodl.KeyAnyValue) {
dynamicType = ,
key = "1",
value = "12312323-1234aaa9-a1a1-ac333a3a3ac3",
},
(vmodl.KeyAnyValue) {
dynamicType = ,
key = "2",
value = (vim.event.DatastoreEventArgument) {
dynamicType = ,
name = "datastore-name",
datastore = 'vim.Datastore:12312323-1234aaa9-a1a1-ac333a3a3ac3',
},
}
],
objectId = "12312323-1234aaa9-a1a1-ac333a3a3ac3",
objectType = "vim.Datastore",
objectName = "datastore-name",
fault = (vmodl.MethodFault) null,
}

VMkernel.log incelemek:

VMkernel.log dosyaları; hostd.log’a göre daha fazla bilgi vermektedir. Yazının başında belirttiğim gibi benim ortamım ISCSI olduğu için VMknernel.log içerisinde lost duruma düşen ISCSI Lun’ları görebiliriz. Tabi sizin yapınızda Fiber bağlı lun’larınız var ise onlarıda görebilirsiniz.

NMP: nmp_ThrottleLogForDevice:2319: Cmd 0x28 (0x41248919c240, 8235) to dev "naa.xxx" on path "vmhba32:C1:T2:L0" Failed: H:0x5 D:0x0 P:0x0 Possible sense data: 0x2 0x3a 0x0. Act:EVAL

WARNING: iscsi_vmk: iscsivmk_TaskMgmtIssue: vmhba32:CH:1 T:2 L:0 : Task mgmt "Abort Task" with itt=0x2b5bd (refITT=0x2b5bc) timed out.

WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237:NMP device "naa.xxx" state in doubt; requested fast path state update...

ScsiDeviceIO: 2316: Cmd(0x41248919c240) 0x28, CmdSN 0xc42383 from world 8235 to dev "naa.xxx" failed H:0x5 D:0x0 P:0x0 Possible sense data: 0x2 0x3a 0x0.

Ben tek bir LUN üzerinde problem yaşadığım için sadece bu LUN’a ait log’ları yukarıya ekledim. Yukarıdaki log’larda gördüğünüz naa.xxx uzantılı isimleri LUN ile eşleştirebilirsiniz. Bu eşleştirmeyi isterseniz hostd.log içerisinden bulup, istersenizde esxi host içerisinden hangi lun olduğunu bulabilirsiniz. (LUN üzerinde sağ click  > properties) Yukarıdaki log’larda gördüğünüz gibi LUN, esxi host’a cevap vermiyor ve Esxi host sürekli bu LUN’a re-connect olmaya çalışıyor.

Şimdi sorun yaşanan LUN için rescan datastore yapmamız gerekiyor. Bunun için esxcfg-rescan vmhbaXX komutunu çalıştırıyoruz. Sizin ISCSI adapter’iniz ne ise XX yazan yere onu yazabilirsiniz.

 esxcfg-rescan vmhba32 

Yukarıda bahsettiğim gibi LUN disconnect durumda ise rescan yaptığınızda LUN geriye gelebilir. Eğer siz rescan yaptığınız halde hala LUN’a ulaşamıyorsanız aşağıdaki hataları görebilirsiniz.

Partition: 414: Failed read for "naa.xxx": I/O error
Partition: 1020: Failed to read protective mbr on "naa.xxx" : I/O error
WARNING: Partition: 1129: Partition table read from device naa.xxx: I/O error

vmkwarning.log incelemek:

Aslında vmkwarning.log içerisinde gördükleriniz vmkernel.log ile benzerlik gösterecektir. vmkwarning.log dosyasına sadece uyarılar gelecektir. Yani vmkernel.log’da olduğu gibi kesin tespitler yapmanız zor olabilir. Şahsen ben böyle bir sorun ile karşılaşsam vmkwarning.log dosyası üzerinde çok fazla durmam ama tabi yinede anlatmak gerekiyor:)

WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237:NMP device "naa.xxx" state in doubt; requested fast path state update...

Daha fazla bilgi istiyorsanız:

Log’ları incelemek yeterlidir ancak buna alternatif olarak çeşitli komutlar kullanarak bu problemi doğrulayabilirsiniz. Tek bir komut kullanarak, LUN’un VM tarafından kullanıldığını veya inaccesible durumda olduğunu görebilirsiniz.
Öncelikle bahsi geçen hostta LUN’un gerçekten var olup olmadığını doğrulamalıyız. Eğer loglar bu LUN hakkında bilgi içeriyorsa, aşağıdaki komut ile bulunacaktır. Eğer azıcık da olsa emin değilseniz, doğrulamanız için bu size yardımcı olacak:

~ # ls /vmfs/devices/disks/ | grep naa.xxx
naa.xxx
naa.xxx:1
~ #

LUN üzerinde herhangi bir problem olup olmadığını görmek için aşağıdaki komutu kullanabilirsiniz.

esxcli storage core device world list -d naa.xxx

Device World ID Open Count World Name
------------------------------------ -------- ---------- ----------
naa.xxxx xxx 1 idle0

Sonuç olarak; Open Count 1 ve idle 0 olarak gözükmesi bu lun’un şuanda aktif ve VM’ler tarafından kullanılan bir LUN olduğu anlamına gelir.

2. bölüm’de LUN’un nasıl kurtarılacağı yönünde bilgi vereceğim.

Umarım faydalı olmuştur.

İyi çalışmalar.