HPE MSA 2060 Storage’daki ISCSI LUN Bağlantısındaki Not Consymed Hatasinin Giderilmesi

Sanal altyapılarını büyüten BT ekipleri için yeni bir ESXi host eklemek sıradan bir işlem gibi görünse de kimi zaman ufak bir detay tüm süreci tıkar.

Özellikle iSCSI üzerinden bağlı bir LUN’un yeni eklenen ESXi sunucusunda görünmesine rağmen datastore olarak mount edilememesi görünüşte basit ama altında karmaşık mekanizmalar barındıran bir problemdir.

Bu makalemde HPE MSA2060 storage cihazı üzerinden sunulan bir LUN’un ESXi tarafından neden “foreign” olarak görüldüğünü ve sistemin bu davranışının ardındaki teknik motivasyonu ve çözüm yollarını tüm boyutlarıyla inceliyoruz.

Ortam Yapısı: Her Şey Yolunda Gibi…

Var olan bir ESXi ortamına yeni bir sunucu eklendi.

• HPE MSA2060 storage tüm ESXi host’larla iSCSI protokolüyle konuşuyor.
• Storage tarafında aynı Volume Group üzerinden oluşturulmuş beş adet LUN var.
• Her beş LUN da aynı Host Group üzerinden tanımlanmış durumda.
• Ancak… Yeni host bu LUN’lardan sadece birini datastore olarak görüyor.

İkincisi, “Storage Devices” sekmesinde görünse bile, “not consumed” olarak etiketleniyor. Yani fiziksel olarak bağlı ama sistem bu volume’ü kullanıma açmıyor.

VNware ESXi’ın Perspektifinden LUN Görünüyor ama Kullanılamıyor

Bir LUN’un fiziksel olarak erişilebilir olması VMware için onu otomatik olarak mount etmek için yeterli değildir. VMware mühendislerinin burada dikkatle tasarladığı bir güvenlik mekanizması devreye girer:

Eğer bir LUN daha önce başka bir host tarafından VMFS ile formatlandıysa, ESXi bu volume’ü otomatik olarak mount ETMEZ.

Neden?

• Çünkü LUN içeriği başka bir host tarafından aktif olarak kullanılıyor olabilir.
• Otomatik mount işlemi UUID çakışmasına veya veri bozulmasına yol açabilir.
• Bunun yerine sistem bu volume’ü “snapshot LUN” veya “foreign volume” olarak algılar.

Bu dışarıdan bakıldığında kafa karıştırıcı olabilir. Ancak VMware açısından bu bir bilinçli veri koruma refleksidir.

Tanılama: VMware ESXi Sessizce Ne Söylüyor?

Bu noktada yapılması gereken ilk şey SSH üzerinden ESXi’a bağlanıp snapshot volume’leri kontrol etmektir.

esxcli storage vmfs snapshot list

Örnek çıktı:

Volume Name: MSA-VOL-2TB
VMFS UUID: 88750024-2a9be8cc-790f-0100179100c6
Can mount: true
Can resignature: false

Buradaki Can mount: true satırı kritik.

Bu volume’ün aslında veri kaybı olmadan doğrudan mount edilebileceğini gösteriyor. Ancak GUI üzerinde bu işlem yapılabilir şekilde sunulmaz.

Bunun yerine kullanıcıdan açık bir komut beklenir.

Çözüm: Veri Güvenliğini Bozmadan Mount Etme

Seçenek 1: Mevcut UUID ile Doğrudan Mount (Tercih Edilen)

esxcli storage vmfs snapshot mount -u <VMFS_UUID>

Bu komut volume’ü olduğu gibi sistemin tanımasını sağlar.

Her şey yolundaysa birkaç saniye içinde “Datastore” sekmesinde aktif hale gelir.

Seçenek 2: Yeni UUID ile Resignature (Zorunlu Hallerde)

esxcli storage vmfs snapshot resignature -u <VMFS_UUID>

Bu yöntem volume’ü yeni bir UUID ile tanımlar.

Halihazırda çalışan VM’lerin bu datastore’a olan referansları kırılabilir.

Bu nedenle yalnızca dikkatli şekilde planlanarak kullanılmalıdır.

VMware’in bu yaklaşımı VMFS volume locking prensibine dayanır. Cluster yapılarında veri bütünlüğü sadece volume erişimiyle değil aynı zamanda metadata kilitleriyle korunur.

Eğer farklı bir host başka bir host’un aktif kullandığı bir volume’e aynı anda yazarsa bu veri yapısını tamamen bozabilir. İşte bu yüzden:

• ESXi bir LUN’un VMFS içerdiğini tespit eder etmez bunu otomatik olarak “foreign” olarak işaretler.
• Yani mount işlemi yalnızca kullanıcının bilinçli şekilde yaptığı bir eylemle mümkün olur.

Kaynak : https://knowledge.broadcom.com/external/article?legacyId=1011387