What is ESXi multipathing?


 

ESXi Multipath nədir?

ESXi Multipathing, bir ESXi hostun storage-ə (SAN/NAS) birdən çox yol (path) üzərindən daxil ola bilməsini təmin edən mexanizmdir.
Məqsədləri:
  • Yüksək əlçatanlıq (HA) → Bir yol qoparsa, digəri dövrəyə girir.
  • Yük balansı (Load Balancing) → IO-ları birdən çox yol arasında paylayır.
  • Performans artımı
Nümunə:
text
ESXi Host

   |  |  
HBA1 HBA2

   |  |
SAN Switch A / SAN Switch B

   |  |
Storage Controller A / B
Koddan ehtiyatla istifadə edin.
VMware tərəfindəki əsas anlayışlar
1️⃣ NMP (Native Multipathing Plugin)
VMware-in standart multipath strukturudur.
  • Yolları idarə edir.
  • Hansı yolun aktiv olacağına qərar verir.
  • PSP-lərdən istifadə edir.
2️⃣ PSP (Path Selection Policy)
IO-nun hansı yol üzərindən gedəcəyini təyin edir.
Ən geniş yayılmış PSP-lər:
  • Fixed → Tək yol aktivdir.
  • Most Recently Used (MRU) → Son istifadə olunan yol aktivdir.
  • Round Robin (RR) ✅ (Ən performanslı olan variantdır).
Sizin istifadə etdiyiniz komandaların izahı
1️⃣ Cihaz və multipath statusunu görmək
  • esxcli storage core device list
    • Diskinizin NAA ID-sini, PSP-sini, Queue Depth və yol məlumatlarını göstərir.
  • esxcli storage nmp device list
    • Diskinizin hansı PSP-dən istifadə etdiyini, aktiv/passiv yollarını və Storage vendor (istehsalçı) məlumatlarını göstərir.
2️⃣ Round Robin parametrini IOPS = 1 etmək
bash
esxcli storage nmp psp roundrobin deviceconfig set -d <naa-adi> -t iops -I 1 -U true
Bu, çox vacib bir performans tənzimləməsidir 👇
Nə işə yarayır?
  • Round Robin hər 1 IOPS-dan bir yol dəyişir.
  • Standart dəyər adətən 1000 IOPS olur (bu isə performans itkisi yaradır).
Parametrlər:
  • -d → Disk NAA ID
  • -t iops → Yol dəyişmə növü (IOPS əsaslı)
  • -I 1 → Hər 1 IO-da yolu dəyiş
  • -U true → Tənzimləməni qalıcı et (reboot variantından sonra da qüvvədə qalır)
📌 Xüsusilə All-Flash, iSCSI və Active/Active SAN sistemlərində qətiyyətlə tövsiyə olunur.
3️⃣ Eyni tənzimləməni ayrı-ayrı daxil etmək
  • -t iops -I 1 (Performans tənzimləməsi)
  • -U true (Kalıcı / persistent edir)
  • Bu iki parametri birləşdirərək yazmağınız daha səliqəlidir, lakin ayrı-ayrılıqda da işləyir. 👍
4️⃣ PowerShell – winsat disk
powershell
winsat disk -drive c
  • Bu, ESXi deyil, Windows tərəfində edilən bir testdir.
  • Nə işə yarayır? Disk IOPS, Latency (gecikmə) və Throughput (ötürmə qabiliyyəti) dəyərlərini ölçür.
  • 👉 Amma: Canlı (Production) mühitdə tövsiyə edilmir. Storage-ə ciddi yük salır. Yalnız test məqsədli və qısamüddətli istifadə olunmalıdır.
  • Alternativ (daha təhlükəsiz): DiskSpd və ya Storage istehsalçısının xüsusi test alətləri.
Qısa xülasə 🧠
  • ESXi Multipath = Storage-ə birdən çox yol ilə bağlanmaq.
  • NMP = VMware multipath infrastrukturu.
  • Round Robin + IOPS=1 = Ən yaxşı performans.
  • -U true = Reboot sonrası tənzimləmənin silinməməsi.
  • winsat disk = Windows disk benchmark aləti.
1️⃣ Hansı storage mühitində Round Robin (RR) istifadə olunur?
✅ RR istifadə edil bələn (tövsiyə olunan) storage növləri:
Active / Active controller arxitekturası olan storage-lər:
  • All-Flash Array-lər
  • iSCSI SAN
  • FC SAN (Active/Active)
İstehsalçı (Vendor) nümunələri:
  • NetApp (A/A)
  • Dell EMC Unity / PowerStore
  • Pure Storage
  • HPE Nimble (iSCSI)
  • IBM FlashSystem
  • ➡️ Bu storage-lərdə bütün yollar eyni anda IO qəbul edə bilir, yəni yük balansı (load balancing) tam funksional işləyir.
❌ RR istifadə edilməməli olan hallar:
  • Active / Passive storage sistemləri
  • Yalnız tək controlleri aktiv olan sistemlər
  • Köhnə SAN arxitekturaları
  • ➡️ Bu hallarda RR istifadə etsəniz: Daimi yol dəyişməsi (path switch), yolların sıradan çıxması (path thrashing) və Latency (gecikmə) artımı baş verər.
2️⃣ Fixed yoxsa RR?
🔹 Fixed PSP
  • Tək bir yol aktivdir.
  • Digərləri gözləmə (standby) rejimindədir.
  • Aktiv yolu əllə (manuel) seçirsiniz.
  • Nə zaman məntiqlidir? Active/Passive storage-lərdə, istehsalçı xüsusi olaraq "Fixed tövsiyə edilir" deyirsə və ya Controller affinity tələb olunursa.
  • 📉 Mənfi cəhəti: Yük balansı yoxdur, performans məhduddur.
🔹 Round Robin PSP
  • IO-lar mövcud yollar arasında paylanılır.
  • Real yük balansı təmin edilir.
  • Nə zaman ən yaxşısıdır? Active/Active storage-lərdə və Flash / yüksək IOPS tələb edən mühitlərdə.
  • 📈 Üstünlüyü: Daha aşağı gecikmə (latency) və daha yüksək ötürmə qabiliyyəti (throughput).
📌 Qərar Cədvəli
Storage NövüPSP
Active/Active✅ RR
Active/Passive❌ Fixed
İstehsalçıya özəl pluginİstehsalçı nə tövsiyə edirsə
3️⃣ ALUA və Active / Passive fərqi
🔹 Active / Passive (Klassik)
  • Sadece 1 controller aktivdir, digəri isə gözləmədədir.
  • Əgər passiv yoldan IO keçərsə → failover baş verir.
  • Nümunə: Controller A (Active) ✅ / Controller B (Passive) ❌
  • ➡️ Bu sistemlərdə PSP adətən Fixed və ya MRU olur.
🔹 ALUA (Asymmetric Logical Unit Access)
  • Controller-lər bərabər hüquqlu deyil, amma hər ikisi də IO qəbul edə bilir.
  • Yol növləri:
    • Optimized Path → Ən yaxşı və birbaşa yol.
    • Non-Optimized Path → İşlək olan amma digər controller üzərindən keçən yavaş yol.
  • ➡️ ESXi hər zaman optimized (optimallaşdırılmış) yolu seçir.
  • 📌 NetApp, Unity, Nimble kimi əksər müasir storage sistemləri ALUA istifadə edir.
  • ➡️ ALUA + Active/Active kombinasiyası RR üçün tam ideal mühitdir.
4️⃣ IOPS=1 hər zaman doğrudurmu?
Qısa cavab: ❌ Xeyr, amma müasir mühitlərin böyük əksəriyyətində bəli.
✅ IOPS=1 tövsiyə edilən ssenarilər:
  • All-Flash storage sistemləri
  • iSCSI bağlantıları
  • NVMe-oF
  • Yüksək IOPS və aşağı gecikmə (latency) tələb edən mühitlər.
  • Səbəbi: IO-lar yollar arasında daha balanslı paylanır, növbələr (queue) dolmur və gecikmə azalır.
⚠️ Diqqət edilməli olan hallar:
  • Köhnə SAN sistemləri
  • Yavaş controller-lər
  • Çox yüksək yol sayı (8+)
  • İstehsalçı rəsmi sənəddə "dəyməyin" deyirsə 😅 (Bu halda 1 yerinə 4 / 8 / 16 dəyərləri daha stabil ola bilər).
🎯 Praktik tövsiyə:
  • All-Flash mühit: 1
  • Hybrid SAN mühit: 4 – 8
  • Köhnə FC (Fibre Channel): 16
  • Xüsusi Vendor eklentisi (plugin): Dəyişdirməyin
Qızıl Qaydalar 🥇
  1. İstehsalçının rəsmi bələdçisi (Vendor guide) hər şeydən üstündür.
  2. Active/Active → RR
  3. Active/Passive → Fixed
  4. ALUA varsa → optimized yollardan istifadə edin.
  5. IOPS=1 ciddi bir performans silahıdır, lakin şüurlu şəkildə tətbiq edilməlidir.
1️⃣ ESXCLI ilə Optimized / Non-Optimized yol kontrolu
🔹 Disk bazlı yolları görmək:
bash
esxcli storage core path list -d naa.xxx
Çıxışda yoxlamalı olduğunuz sahələr:
  • Path Selection Policy: VMW_PSP_RR
  • Target Transport Details: ALUA
  • State: active
  • Preferred: true
🔹 ALUA statusunu dəqiq görmək:
bash
esxcli storage nmp path list -d naa.xxx
Nümunə çıxış dəyərləri:
* `Path State: active (I/O)`
* `Path Type: Primary`
* `Storage Array Type: ALUA`

#### Yolların mənası:

| Görünən Dəyər | Anlamı |
| :--- | :--- |
| active (I/O) + Primary | ✅ Optimized (Optimallaşdırılmış) |
| active + Secondary | ⚠️ Non-Optimized |
| standby | Passiv (Gözləmədə) |

📌 **RR aktiv olduqda:** IO-lar yalnız optimized yollar arasında dövr edir. Non-optimized yollar isə yalnız failover (əsas yollar qopduqda) üçün saxlanılır.

---

### 2️⃣ Canlı mühitdə doğru PSP necə müəyyən edilir?

* **Addım 1 – Storage istehsalçısını öyrənin:**
  ```bash
  esxcli storage core device list -d naa.xxx
  ```
  *(Baxılacaq sətirlər: Vendor: NETAPP / Model: LUN)*
* **Addım 2 – İstifadə olunan SATP / PSP növlərini yoxlayın:**
  ```bash
  esxcli storage nmp device list -d naa.xxx
  ```
  *(Nümunə: Storage Array Type: VMW_SATP_ALUA / Path Selection Policy: VMW_PSP_RR)*
* **Addım 3 – İstehsalçı tövsiyəsi ilə müqayisə edin:**
  * NetApp → RR (IOPS=1)
  * Unity → RR
  * Active/Passive → Fixed

📌 **Kritik qayda:** Əgər Storage Active/Active + ALUA dəstəkləyirsə, amma hazırda PSP = Fixed olaraq qalıbsa, performansınız boşa gedir deməkdir.

---

### 3️⃣ Queue Depth & RR əlaqəsi
Bu parametr çox vaxt unudulur, lakin ümumi performansın təxminən %30-u bura bağlıdır. 👀

* **Queue Depth (Növbə Dərinliyi) nədir?** Bir yol üzərindən eyni anda maksimum neçə IO gedə biləcəyini göstərir. (HBA, Device və Datastore təbəqələri mövcuddur).
* **Yoxlama komandası:**
  ```bash
  esxcli storage core device list -d naa.xxx | grep Queue
  ```
  *(Nümunə çıxış: Device Max Queue Depth: 64)*

#### 🔹 RR ilə Queue Depth əlaqəsi:
* ❌ **Səhv ssenari:** RR + IOPS=1 təyin edilib, amma Queue Depth = 32-dir və cəmi 8 yol var. Bu halda hər yol boş qalır və keçid yükü (context switch) artır.
* ✅ **Doğru balans:** RR yük balansını təmin edir, lakin Queue kifayət qədər böyük deyilsə, yollar tam gücü ilə bəslənə bilmir.
* 📌 **Praktik formul:** `Ümumi effektiv növbə ≈ Yol sayı × Queue Depth` (Məsələn: 4 yol × 64 = 256 IO tutumu).
* 🔹 **Neçə zaman Queue artırılır?** Gecikmə (latency) aşağı olduğu halda IOPS dəyəri gözləniləndən azdırsa və storage sürətli olmasına baxmayaraq ESXi tərəfindən məhdudlaşdırılırsa. (⚠️ İstehsalçı limitlərini, xüsusilə iSCSI-də aşmayın).

---

### 4️⃣ İstehsalçı plugin fərqləri (PowerPath, SATP, NMP)

* **VMware Native (NMP + SATP + PSP):** VMware-in standart daxili strukturudur. SATP storage-in davranışını tanıyır, PSP isə IO-nun hansı yolla gedəcəyinə qərar verir. Pulsuzdur, stabildir və müasir SAN-lar üçün tamamilə kifayətdir.
* **Dell EMC PowerPath / VE:** Öz xüsusi multipath mühərrikinə malikdir. Dinamik yük balansı və gecikməyə əsaslanan yol seçimi edir. Böyük OLTP sistemləri (məsələn, ağır Oracle / SQL workload) üçün əladır. Lakin əlavə lisenziya xərci 💰 və hostlara əlavə agent tələb edir.
* **İstehsalçı SATP-ləri (Pure, NetApp və s.):** VMware NMP strukturunu istifadə edir, lakin onun daxili davranışlarını həmin storage-ə uyğun optimallaşdırır. Müasir storage sistemlərində adətən RR default olaraq gəlir və əlavə agentə ehtiyac qalmır.

🔥 **Təcrübəyə əsaslanan qızıl tövsiyələr:**
* All-Flash + ALUA → RR + IOPS=1 tətbiq edin.
* PSP-ni dəyişmədən öncə mütləq `esxcli storage nmp device list` ilə mövcud vəziyyəti yoxlayın.
* Queue Depth dəyərini kor-koranə artırmayın.
* PowerPath eklentisini yalnız həqiqətən xüsusi bir ehtiyac və ya istehsalçı tələbi olduqda quraşdırın.

Комментарии

Отправить комментарий