Depolama dünyasında çoğu performans sorunu gürültülü bir arıza yerine sessiz bir yanlış yapılandırmadan doğar. Disk dizisi sağlamdır, ağ ayaktadır, sunucular çalışır ama IO trafiği yollar arasında olması gerektiği gibi dağıtılmadığı için sistem potansiyelinin altında performans verir.
İşte VMware ortamlarında “path yönetimi” dediğimiz konu tam da bu sessiz alanı düzenler. Ve çoğu zaman gözden kaçar çünkü çalışan bir sistem “yeterince iyi” görünür.
Bu makalemde Dell’in üç Power platformunda PowerFlex, PowerMax ve PowerStore pathing konusunu tek bir yerde anlaşılır bir dille toparlamak.
Konuyla ilgili bilgiler aslında belgelenmiş durumda ama birden fazla dokümana dağılmış olduğu için aynı sorular tekrar tekrar gündeme geliyor.
Burada çok derine inmeden asıl önemli olan iki şeyi netleştireceğiz varsayılan davranış nedir ve önerilen en iyi uygulama (best practice) nedir.
Bir de zamanlama açısından konu artık daha kritik. PowerPath/VE’nin kullanımdan kalkmasıyla birlikte VMware’in kendi pathing mekanizması tek seçenek hâline geldi.
Yani eskiden üçüncü taraf bir çözüme bırakabileceğiniz bu işi artık VMware’in araçlarıyla doğru kurmanız gerekiyor.
Önce Temel Soru: Path (Yol) Neden Çoklu Olur?
Bir konuya girmeden önce neden var olduğunu anlamak işleri kolaylaştırır. Bir ESXi sunucusu ile depolama dizisi arasında genellikle birden fazla fiziksel yol bulunur farklı HBA portları, farklı switch’ler, dizinin farklı kontrolcüleri üzerinden.
Bu çoklu yolların iki temel sebebi vardır;
- Dayanıklılık (redundancy): Bir yol koparsa (kablo, port, switch arızası) trafik diğer yoldan akmaya devam eder ve kesinti yaşanmaz.
- Performans: IO yükünü birden fazla yola dağıtarak tek bir yolun darboğaza dönüşmesini engelleyebilirsiniz.
İşte “multipathing” yani çoklu yol yönetimi bu yolları akıllıca kullanma sanatıdır.
Hangi yolun ne zaman, ne kadar kullanılacağına karar veren mekanizma ise VMware’in pathing eklentileridir.
NMP ve HPP
VMware’in iki pathing eklentisi vardır ve isimlerinden ne işe yaradıkları anlaşılır;
- NMP (Native Multipathing Plug-in) : VMware’in geleneksel, yerleşik çoklu yol eklentisi.
- HPP (High Performance Plug-in) : yüksek performanslı depolama için tasarlanmış, daha yalın ve hızlı eklenti.
Burada en sık yapılan kafa karışıklığı şu İnsanlar bu ikisini “hangisi daha iyi” diye karşılaştırmaya çalışır. Oysa aralarındaki ilişki bir rekabet değil bir iş bölümüdür. Çünkü her biri farklı bir aygıt sunum türüne hizmet eder.
- NMP, geleneksel SCSI tabanlı sunumlarla ilgilenir yani FC (Fibre Channel) ve iSCSI üzerinden gelen aygıtlarla.
- HPP, modern NVMe-over-Fabrics (NVMeoF) sunumlarıyla ilgilenir yani NVMe/FC ve NVMe/TCP üzerinden gelen aygıtlarla.
Bunu şöyle düşünebilirsiniz NMP daha köklü ve genel amaçlı bir araç HPP ise NVMe’nin getirdiği yüksek hız ve düşük gecikme dünyası için optimize edilmiş gereksiz yükten arındırılmış bir araç.
İşin en rahatlatıcı yanı şu Hangi aygıt için hangi eklentinin devreye gireceğini sizin belirtmenize gerek yok. VMware aygıtın SCSI mi yoksa NVMeoF mi olduğunu kendisi anlar ve doğru eklentiyi otomatik olarak görevlendirir. Yani burada elle bir “şunu kullan” demeniz gerekmiyor.
Bir Aygıt ESXi’ye Sunulduğunda Sahne Arkasında Ne Olur?
Yeni bir LUN ya da NVMe namespace ESXi sunucusuna sunulduğunda eklentilerden biri o aygıtı “claim” eder yani “bu benim, ben yöneteceğim” der.
Ardından aygıta bir kural uygular. Bu kural VMware’e o aygıtın IO trafiğini nasıl yöneteceğini söyler.
Kuralın yapısı, hangi eklentinin devrede olduğuna göre değişir:
- NMP’de kural iki parçadan oluşur. Bir SATP (Storage Array Type Plug-in) ve bir PSP (Path Selection Policy).
- HPP’de ise yalnızca bir PSP vardır, SATP yoktur.
Bu iki kavramı biraz açalım çünkü konunun kalbi burada.
SATP
SATP kabaca “bu dizi ne tür bir dizi ve yolları nasıl davranır” bilgisini taşıyan bileşendir.
Örneğin bir yolun aktif mi yoksa pasif mi olduğunu dizinin yol durumlarını nasıl raporladığını bu katman bilir.
Burada güzel bir ayrıntı var VMware, ESXi kodu içinde birçok depolama dizisi için “özel” görünen SATP’ler dağıtır ama gerçekte bunların çoğu yeniden adlandırılmış aynı temel SATP’dir.
Örneğin PowerMax için kullanılan SATP VMW_SATP_SYMM‘dir. Eğer dizi ALUA (Asymmetric Logical Unit Access) kullanıyorsa PowerStore’da olduğu gibi o zaman tüm ALUA dizileri için ortak tek bir SATP devreye girer: VMW_SATP_ALUA.
Akılda tutulması gereken kritik nokta şu SATP yalnızca SCSI üzerinden sunulan aygıtlar için geçerlidir. NVMeoF tarafında (yani HPP’nin dünyasında) SATP diye bir şey yoktur orada işler doğrudan PSP üzerinden yürür.
PSP
PSP asıl kararı veren bileşendir: “Bu IO’yu hangi yoldan göndereyim?” sorusunu o yanıtlar. Başlıca seçenekler şunlardır:
- Round Robin (RR): Yolları sırayla dolaşır, yükü dağıtır. Hem SCSI hem de NVMe aygıtları için varsayılan PSP budur. Varsayılan ayarıyla her 1000 IO’da bir yol değiştirir.
- Fixed: Yalnızca NMP’de bulunur. Tek bir yolu sabit olarak kullanır, ancak o yol koparsa yedeğe geçer.
- Latency (gecikme tabanlı): Hem NMP’de hem HPP’de bulunur. Yolların gerçek performansını (gecikmesini) ölçer ve o anda en hızlı olan yolu tercih eder. Yani statik bir sıralama yerine, anlık koşullara göre karar verir.
Buradaki “1000 IO’da bir yol değiştirme” ayrıntısı önemli çünkü best practice bölümünde göreceğimiz gibi, bu değeri 1’e çekmek çoğu Dell dizisinde önerilen yaklaşımın temelini oluşturur.
Mantığı basit 1000 IO’yu tek bir yola yığıp sonra geçmek yerine her IO’yu sırayla dağıtmak yükü yollar arasında çok daha dengeli paylaştırır.
Şimdi her bir diziye geçelim ve hem NMP hem de HPP için önerilen ayarları görelim. Burada bir kalıp dikkatinizi çekecek — ki bu aslında iyi haber, çünkü hatırlaması kolay.
PowerFlex
NMP tarafı bu dizide en kolayı çünkü hiç devreye girmiyor. PowerFlex NMP kullanmaz.
Bunun nedeni mimarisidir SDC (Storage Data Client) adı verilen bileşen ESXi içinde yazılım tanımlı bir depolama adaptörü gibi çalışır ve NMP’yi tamamen baypas eder.
Yani yolların arasında yük dengelemeyi VMware değil doğrudan PowerFlex’in kendi yazılımı yapar ve bunu kendi dağıtık mimarisine göre çok daha verimli biçimde yürütür.
Burada kafa karıştırabilecek bir görsel ayrıntı var ESXi üzerinde aygıta baktığınızda onu NMP’nin claim ettiğini görürsünüz.
Ama bu yalnızca görünüştedir kodda fiilen kullanılmaz. Ayrıca VMware’in her aygıt için yalnızca tek bir yol gösterdiğini fark edersiniz. Bunların ikisi de normaldir ve “bir şeyler yanlış” anlamına gelmez sadece işin PowerFlex tarafından yürütüldüğünün göstergesidir.
HPP tarafında öneri ise Load Balance – Latency (LB-Latency) kullanmaktır.
Yeni aygıtların otomatik olarak bu ayarı almasını istiyorsanız bir kural oluşturmanız gerekir; mevcut aygıtları ise tek tek manuel olarak ayarlayabilirsiniz.
Önemli bir uyarı: Dell, LB-Latency‘ye ait parametrelerin hiçbirini değiştirmemenizi önerir varsayılanlarıyla bırakınız.
PowerMax
NMP tarafında varsayılan olan Round Robin kullanılır, ancak tek bir kritik değişiklikle IOPS değerini 1000’den 1’e çekersiniz.
Böylece her IO sırayla farklı bir yoldan gider ve yük gerçek anlamda dengelenir. Bunu yeni aygıtlar için otomatikleştirmek isterseniz bir kural oluşturmanız, mevcut aygıtlarda ise manuel uygulamanız gerekir.
İyi haber: VSI (Virtual Storage Integrator) eklentisi bu iki işi de kural oluşturma ve değer ayarlama sizin yerinize otomatik olarak halleder. Yani elle uğraşmak zorunda değilsiniz.
HPP tarafında ise öneri yine LB-Latency‘dir. Aynı şekilde yeni aygıtlar için kural oluşturulur, mevcutlar manuel ayarlanır ve bu işlemler de VSI üzerinden otomatik yürütülebilir. Burada da Dell, LB-Latency parametrelerinin değiştirilmemesini önerir.
PowerStore
NMP tarafında kural diğerleriyle aynı Round Robin, IOPS değeri 1’e çekilmiş. Ancak PowerStore’un güzel bir ayrıcalığı var bu en iyi uygulamayı doğrudan ESXi koduna gömmüş tek dizi odur.
Eğer vSphere 7.x veya daha yeni bir sürüm çalıştırıyorsanız, ilgili kural zaten kodun içinde hazır gelir. Yani sizin hiçbir şey yapmanıza gerek kalmaz PowerStore’u sunarsınız doğru ayar kendiliğinden uygulanır.
HPP tarafında ise hikâye değişmiyor öneri yine LB-Latency’dir. Yeni aygıtlar için kural oluşturulur mevcutlar manuel ayarlanır ve Dell, LB-Latency parametrelerinin değiştirilmemesini önerir.
Tabloyu Toparlayalım
Üç diziye baktığımızda başta karmaşık görünen konunun aslında şaşırtıcı derecede tutarlı bir tabloya indiğini görüyoruz:
| Dizi | NMP (SCSI: FC/iSCSI) | HPP (NVMeoF) |
|---|---|---|
| PowerFlex | Kullanılmaz (yük dengelemeyi SDC yapar) | LB-Latency |
| PowerMax | Round Robin, IOPS = 1 (VSI otomatikleştirir) | LB-Latency |
| PowerStore | Round Robin, IOPS = 1 (vSphere 7.x’te hazır gelir) | LB-Latency |
Yani aslında ezberlenmesi gereken iki cümle var:
- NMP için: Round Robin, IOPS = 1
- HPP için: LB-Latency
PowerFlex bu tablonun dışında durur çünkü NMP’yi hiç kullanmaz ve işi tamamen kendi üstlenir. PowerStore ise NMP en iyi uygulamasını hazır sunarak sizi bir adım öne taşır. Geri kalanı bu iki cümlenin tekrarından ibaret.
Bu noktayı özellikle vurgulamak istiyorum çünkü pratikte sürekli gündeme geliyor ve gereksiz endişeye yol açıyor: Yukarıdaki ayarların hepsi birer en iyi uygulamadır, katı kurallar değil.
Farklı bir şey yapmayı tercih ederseniz, bu aldığınız desteği etkilemez. Performansınızı etkileyebilir elbette ama isterseniz NMP’de varsayılan 1000 IOPS değerini de kullanabilirsiniz bu tamamen geçerli bir tercihtir. Aynı şekilde IOPS = 1 yerine latency tabanlı seçeneği de kullanabilirsiniz.
Bu öneriler kurulumların büyük çoğunluğunu kapsayacak şekilde, yapılan testlere dayanılarak belirlenmiştir. Ama her ortam aynı değildir. İşte tam da bu yüzden istisnaları bilmek önemli.
Örneğin ağ altyapınız düzensizse yolların performansı birbirinden belirgin biçimde farklıysa NMP’de IOPS = 1 yerine latency ayarını kullanmak çok daha mantıklı olabilir.
Çünkü IOPS = 1 yaklaşımı, en başta şöyle bir varsayıma dayanır: “Tüm yollar aşağı yukarı aynı şekilde davranır.” Oysa sorunlu bir ağda bu varsayım çöker bir yol diğerinden çok daha yavaş olabilir.
Latency tabanlı seçenek ise yolları sürekli ölçtüğü için yavaş yola IO yığmaktan kaçınır ve bu olumsuz etkiyi gözle görülür biçimde azaltır.
Varsayılanı ve en iyi uygulamayı biliniz çoğu zaman ona güvenin ama ortamınızın kendine özgü koşullarını da gözden kaçırmayın. İyi yapılandırılmış bir pathing, çoğu zaman fark edilmeyen ama her gün karşılığını veren bir yatırımdır.
