Vmware Raw Device Mapping (RDM) Nedir? Tüm detaylarıyla RDM

Merhabalar,

Bu makalemde Raw Device Mapping (RDM) nedir ve neden böyle bir sistem kullandığımız hakkında bilgiler aktaracağım.

Biliyorsunuz ki cluster teknolojisi, ortak bir alanın, en az iki sunucu tarafından kullanılması mantığına dayanır. Sanallaştırmaya geçişle birlikte, artık sanallaştırılmış olan o eski sunucuların, sanal ortamda cluster çalışmalarına gerek olmayacağı, zaten sanallaştırma teknolojisinin esnek yapısı sayesinde, bu tip kullanım durumlarına gerek duyulmayacağı, her zaman kesintisiz çalışma gerçekleşeceği algısı oluştu bence.

Peki, en basitinden şunu soralım: sunucu güncellemeleri dolayısıyla bile restart edilemeyecek, kesintisiz çalışması gereken sistemler için ne yapacaksınız? Başka bir senaryo da şu olsun, kullandığınız sanal sistemin, işletim sistemi bazlı probleminde ne olacak? Yedekten ne kadar zamanda geri dönebileceksiniz, geri dönüş işlemi ne kadar zaman sürecek? Yani sıfır kesinti istiyorsanız, yine cluster yapısı düşünmek zorundasınız. Kimileri hemen High Availability (HA) ,ya da Fault Tolerance (FT) teknolojileri var, onları boşuna mı aldık? Kullanamaz mıyız? 🙂 diye düşüneceklerdir. Cevap, hayır kullanamayız. Bu teknolojiler, cluster yapı kullanımından farklı kullanım alanlarına hitap etmektedir. Başka bir makalenin konusu olacaklar.

Sadece cluster için değil, yüksek I/O istediğinizde nasıl bir çözüm düşünmelisiniz?

İşte RDM bu ve benzer ihtiyaçlarda ortaya çıkıyor. Şimdi RDM nedir konusunu incelemeye başlayalım.

Raw Device Mapping (RDM) nedir?

Bir sanal makinenin, bir Fiber ya da ISCSI storage üzerinde oluşturduğunuz bir LUN’a direkt olarak erişmesidir. Yani, fiziksel bir disk ortamının, bir sanal makineye doğrudan kullandırılmasıdır.

ESXi sunucu üzerinde çalışan bir sanal sunucu olsun ve RDM konfigürasyonu yapılsın.

RDM Mapping file pointer, storage üzerindeki LUN’u işaret eden bir dosyadır.

Eğer bir sanal makineye RDM yapılırsa, sanal makinenin durduğu dizinde bir mapping file oluşturularak proxy görevi tanımlanmış olur ve içerisinde tuttuğu metadata bilgisiyle de fiziksel diskin (LUN’un) yönetilmesi sağlanarak, erişimlerin fiziksel LUN’a yönlenmesi sağlanmış olur.

Önemli bir soru: Eğer RDM yapılmış bir sanal makineyi silersek, storage alanı üzerinden de tüm bilgiler silinir mi?

Cevap : Hayır silinmez. Siz sanal makineyi komple sildiğinizde, disk gibi gördüğünüz RDM Mapping file pointer dosyasını silmiş oluyorsunuz. RDM diskiniz storage üzerinde hala duruyor. Bu diski başka bir makineye bağladığınızda içindekilerin durduğunu da görebilirsiniz.

ESXi sunucuların RDM konfigürasyonları

Bu bölümde, RDM disk tanımı yapmak yerine, Host bazında düzgün konfigürasyonlarının yapılması konusunda bilgiler vereceğim. RDM ile ilgili, vm ya da cluster kurulumlarıyla ilgili makalemi çok yakında paylaşacağım.

Storage üzerinde birkaç tane LUN tanımladım. Daha sonraki makalelerimde de kullanmak üzere aşağıdaki ismi belirledim ve ESXi sunucularımın da bu alanı görmesini sağladım. Bu arada sonraki makalelerimin konusu hakkında da biraz spoiler vermis oluyorum. 🙂

Sonra da vCenter altından cluster üzerinde sağ tıklayıp Storage > Rescan Storage ile tüm ESXi sunucularımda bu LUN’ların algılanmasını sağlıyorum.

ESXi sunucularım üzerinde ilgili LUN’ları gördüm.

Şimdi dikkat edeceğimiz konu bu aşamada başlıyor. Bu alanların RDM yapılması durumunda hem ESXi sunucularının, hem de sanal makinelerin gördüğü birkaç alan da yaratmış oluyorum değil mi? RDM yapılandırılması, ESXi host seviyesinde düzgün yapılmadığında, ciddi sıkıntılara dönüşebilir.

Peki ESXi sunucumu bakımlar ve güncellemeler sırasında restart ettiğimde ne olacak sizce? ESXi sunucu, storage üzerinde kendine tanımlanmış alanları algılamaya, keşfetmeye çalışacak boot sırasında değil mi? Fakat kendine de tanımlı bir diski, bir yerlerde çalışan başka bir sistem de kullanmaya çalışıyor ve rezerve etmiş. Genelde cluster yapılar için RDM kullanılıyor ve başka bir sistem tarafından bir LUN’a koyulmuş olan SCSI rezervasyonu, ESXi sunucunun timeout olana kadar bu keşif işlemini sürdürmesine ve boot işleminin uzun sürmesine neden olabilir. Tanımlanmış olan her bir RDM için çok uzun bekleme sürelerine dönüşebilir bu durum. Sonuçta vCenter altında da bu ESXi sunucunun hataları görülür.

Bu duruma engel olmak için, RDM’leri “perennially reserved” olarak konfigüre etmemiz gerekiyor.

Bu örnekte yukarıda oluşturduğum 40 GB LUN alanının özelliklerine bakalım. Öncelikle web client arabiriminden ilgili LUN’un tanımlayıcı numarasını kopyalayın. (naa.id)

Daha sonra aşağıdaki komutta -d parametresinden sonra kopyaladığınız numarayı kullanın.

esxcli storage core device list -d naa.60002ac0000000000000001e0001cfbf

Bu komut çıktısında “Is Perennially Reserved” anahtarının değeri false ise, bunu TRUE olarak değiştirmeliyiz.

Aşağıdaki komutla da bu değişim işlemini yapabilirsiniz.

esxcli storage core device setconfig -d naa.60002ac0000000000000001e0001cfbf –perennially-reserved=true

sonrasında da değişimin olup olmadığını görmek için, az önceki komutu yeniden yazalım.

esxcli storage core device list -d naa.60002ac0000000000000001e0001cfbf

ÖNEMLİ NOT: vCenter sunucu altında kaç tane ESXi sunucunuz varsa, RDM yaptığınız LUN’a erişimi olan ESXi sunucuların herbirinde bu komutları tek tek uygulayarak, diğer hostların da host bazlı RDM konfigürasyonlarını tamamlamanız gerekiyor.

Gördüğünüz gibi bu değer true olarak değişti ve artık ESXi host bazlı dikkat etmemiz gereken noktayı da halletmiş olduk.

Burada birkaç komutu daha eklemek istiyorum.

RDM yapılmış VM ve diskleri bulmak için aşağıdaki komutu kullanabilirsiniz.

find /vmfs/volumes/ -type f -name ‘*.vmdk’ -size -1024k -exec grep -l ‘^createType=.*RawDeviceMap’ {} \;

Bir txt dosyasına da bu çıktıları aktarabilirsiniz isterseniz.

find /vmfs/volumes/ -type f -name ‘*.vmdk’ -size -1024k -exec grep -l ‘^createType=.*RawDeviceMap’ {} \; > /tmp/RDM.txt

RDM kullanma senaryoları

Şimdi hangi tip senaryolarda RDM kullanıyoruz onları listeleyelim.

Microsoft cluster kurma ihtiyacı varsa
Bir sanal makinenin N_Port ID virtualization teknolojisini kullanabilmesi için (NPIV)
Bir SAN yönetim yazılımının, bir sanal makine içerisinde kullanılabilmesi için
Bir sanal makinenin, Hardware-spesific SCSI komutlarını kullanarak bir donanıma bağlantı sağlaması için
Yüksek I/O ihtiyacı olan sanal makineler için
Storage’a bağlı, çok büyük boyutlu diske sahip bir fiziksel makineniz varsa, bu makineyi Fiziksel-to-Sanal conversion işlemi yapmadan, sanala migration işlemlerini yaparken kullanışlıdır.