ESXi Multipath nedir?

ESXi Multipathing, bir ESXi host’un storage’a (SAN/NAS) birden fazla yol (path) üzerinden erişebilmesini sağlayan mekanizmadır.

Amaçları:

Yüksek erişilebilirlik (HA) → Bir yol koparsa diğeri devreye girer
Yük dengeleme (Load Balancing) → IO’ları birden fazla yol arasında dağıtmak
Performans artışı

Örnek:


ESXi Host
   |  |  
HBA1 HBA2
   |  |
SAN Switch A / SAN Switch B
   |  |
Storage Controller A / B

VMware tarafındaki temel kavramlar

1️⃣ NMP (Native Multipathing Plugin)

VMware’in varsayılan multipath framework’ü.

Path’leri yönetir
Hangi yolun aktif olacağına karar verir
PSP’leri kullanır

2️⃣ PSP (Path Selection Policy)

IO’nun hangi path üzerinden gideceğini belirler.

En yaygın PSP’ler:

Fixed → Tek yol aktif
Most Recently Used (MRU) → Son kullanılan yol
Round Robin (RR) ✅ (en performanslı)

Senin kullandığın komutların açıklaması

1️⃣ Device ve multipath durumunu görmek


esxcli storage core device list

➡️ Diskin:

NAA ID’sini
PSP’sini
Queue Depth
Path bilgilerini gösterir


esxcli storage nmp device list

➡️ Diskin:

Hangi PSP kullandığını
Aktif / pasif path’leri
Storage vendor bilgilerini gösterir

2️⃣ Round Robin ayarını IOPS = 1 yapmak


esxcli storage nmp psp roundrobin deviceconfig set \
-d <naa-adi> -t iops -I 1 -U true

Bu çok önemli bir performans ayarıdır 👇

Ne yapar?

Round Robin her 1 IOPS’te bir path değiştirir
Varsayılan değer genelde 1000 IOPS’tur (performans kaybı yaratır)

Parametreler:

-d → Disk NAA ID
-t iops → Path değiştirme tipi (IOPS bazlı)
-I 1 → Her 1 IO’da path değiştir
-U true → Ayarı kalıcı yap (reboot sonrası da geçerli)

📌 Özellikle:

All-Flash
iSCSI
Active/Active SAN’larda şiddetle önerilir

3️⃣ Aynı ayarı ayrı ayrı vermen


-t iops -I 1
-U true

Bu iki komut:

İlk komut → Performans ayarı
İkinci komut → Persist (kalıcı) yapar

Birleştirerek yazman daha temiz ama ayrı ayrı da çalışır 👍

4️⃣ PowerShell – `winsat disk`


winsat disk -drive c

Bu ESXi değil, Windows tarafında yapılan bir testtir.

Ne işe yarar?

Disk IOPS
Latency
Throughput ölçer

👉 Ama:

Production ortamda önerilmez
Storage’a ciddi yük bindirir
Test amaçlı ve kısa süreli kullanılmalı

Alternatif (daha güvenli):

DiskSpd
Storage vendor test tool’ları

Kısa özet 🧠

ESXi Multipath = Storage’a birden fazla yol
NMP = VMware multipath altyapısı
Round Robin + IOPS=1 = En iyi performans
-U true = Reboot sonrası ayar kaybolmaz
winsat disk = Windows disk benchmark

1️⃣ Hangi storage’da Round Robin (RR) kullanılır?

✅ RR kullanılabilecek (önerilen) storage tipleri

Active / Active controller yapısı olan storage’lar:

All-Flash Array’ler
iSCSI SAN
FC SAN (Active/Active)
Vendor örnekleri:
- NetApp (A/A)
- Dell EMC Unity / PowerStore
- Pure Storage
- HPE Nimble (iSCSI)
- IBM FlashSystem

➡️ Bu storage’larda tüm path’ler aynı anda IO alabilir, yani load balancing gerçekten işe yarar.

❌ RR kullanılmaması gereken durumlar

Active / Passive storage
Tek controller aktif olan sistemler
Eski SAN mimarileri

➡️ RR kullanırsan:

Sürekli path switch
Path thrashing
Latency artışı

2️⃣ Fixed mi RR mi?

🔹 Fixed PSP

Tek path aktif
Diğerleri standby
Manuel path seçersin

Ne zaman mantıklı?

Active/Passive storage
Vendor “Fixed önerilir” diyorsa
Controller affinity gerekiyorsa

📉 Dezavantaj:

Load balancing yok
Performans sınırlı

🔹 Round Robin PSP

IO’lar path’ler arasında dağıtılır
Gerçek load balancing

Ne zaman en iyisi?

Active/Active storage
Flash / yüksek IOPS ortamları

📈 Avantaj:

Daha düşük latency
Daha yüksek throughput

📌 Özet karar tablosu

Storage tipi	PSP
Active/Active	✅ RR
Active/Passive	❌ Fixed
Vendor özel plugin	Vendor ne diyorsa

3️⃣ ALUA vs Active / Passive farkı

🔹 Active / Passive (klasik)

Sadece 1 controller aktif
Diğeri beklemede
Pasif yoldan IO giderse → failover olur

Örnek:


Controller A (Active)  ✅
Controller B (Passive) ❌

➡️ PSP genelde Fixed veya MRU

🔹 ALUA (Asymmetric Logical Unit Access)

Controller’lar eşit değil
Ama ikisi de IO alabilir

Path türleri:

Optimized Path → En iyi yol
Non-Optimized Path → Çalışır ama yavaş

➡️ ESXi optimized path’i tercih eder

📌 Çoğu modern storage:

NetApp
Unity
Nimble
ALUA kullanır

➡️ ALUA + Active/Active = RR için ideal

4️⃣ IOPS=1 her zaman doğru mu?

Kısa cevap: ❌ Hayır, ama çoğu modern ortamda evet

✅ IOPS=1 önerilen senaryolar

All-Flash storage
iSCSI
NVMe-oF
Yüksek IOPS / düşük latency ortamları

Neden?

IO’lar daha dengeli dağılır
Queue’lar dolmaz
Latency düşer

⚠️ Dikkat edilmesi gereken durumlar

Eski SAN’lar
Yavaş controller’lar
Çok yüksek path sayısı (8+)
Vendor “dokunma” diyorsa 😅

Bu durumda:

1 yerine 4 / 8 / 16 daha stabil olabilir

🎯 Pratik öneri (sahadan)

Ortam	IOPS değeri
All-Flash	1
Hybrid SAN	4 – 8
Eski FC	16
Vendor plugin	Değiştirme

Altın kurallar 🥇

Vendor guide her şeyden önce gelir
Active/Active → RR
Active/Passive → Fixed
ALUA varsa → optimized path’leri kullan
IOPS=1 performans silahıdır ama bilinçli kullan

1️⃣ ESXCLI ile Optimized / Non-Optimized path kontrolü

🔹 Disk bazlı path’leri gör


esxcli storage core path list -d naa.xxx

Örnek çıktıdan bakacağın alanlar:


Path Selection Policy: VMW_PSP_RR
Target Transport Details: ALUA
State: active
Preferred: true

🔹 ALUA durumunu net görmek


esxcli storage nmp path list -d naa.xxx

Örnek:


Path State: active (I/O)
Path Type: Primary
Storage Array Type: ALUA

Path yorumlama:

Görülen değer	Anlamı
active (I/O) + Primary	✅ Optimized
active + Secondary	⚠️ Non-Optimized
standby	Pasif

📌 RR varsa:
Optimized path’ler arasında IO döner
Non-optimized sadece failover içindir

2️⃣ Canlı ortamda doğru PSP nasıl tespit edilir?

🔹 Adım 1 – Storage vendor’u öğren


esxcli storage core device list -d naa.xxx

Bakacağın satırlar:


Vendor: NETAPP
Model: LUN

🔹 Adım 2 – Kullanılan SATP / PSP


esxcli storage nmp device list -d naa.xxx

Örnek:


Storage Array Type: VMW_SATP_ALUA
Path Selection Policy: VMW_PSP_RR

🔹 Adım 3 – Vendor önerisi ile karşılaştır

NetApp → RR (IOPS=1)
Unity → RR
Active/Passive → Fixed

📌 Kritik kural

“Storage Active/Active + ALUA → RR”

Eğer:

PSP = Fixed
Storage = A/A

➡️ Performans boşa gidiyor demektir.

3️⃣ Queue Depth & RR ilişkisi

Bu konu genelde atlanır ama performansın %30’u burada 👀

🔹 Queue Depth nedir?

Bir path üzerinden aynı anda kaç IO gidebilir.

Katmanlar:

HBA Queue
Device Queue
Datastore Queue

Kontrol:


esxcli storage core device list -d naa.xxx | grep Queue

Örnek:


Device Max Queue Depth: 64

🔹 RR ile Queue Depth ilişkisi

❌ Yanlış senaryo:

RR + IOPS=1
Queue Depth = 32
8 path

➡️ Her path boş kalır, context switch artar

✅ Doğru denge:

RR load balancing sağlar
Ama Queue yeterli değilse path’ler aç kalır

📌 Pratik formül:


Toplam efektif queue ≈ Path sayısı × Queue Depth

Yani:

4 path × 64 = 256 IO kapasitesi

🔹 Ne zaman Queue artırılır?

Latency düşük ama IOPS düşükse
Storage hızlı ama ESXi sınırlıyorsa

⚠️ Vendor limitlerini aşma (özellikle iSCSI)

4️⃣ Vendor plugin farkları

(PowerPath, SATP, NMP)

🔹 VMware Native (NMP + SATP + PSP)

Varsayılan VMware yapısı:

SATP → Storage davranışını tanır
PSP → IO nasıl gitsin karar verir

Avantaj:

Ücretsiz
Stabil
Modern SAN’larda yeterli

🔹 Dell EMC PowerPath / VE

Özellikler:

Kendi multipath engine’i
Dinamik load balancing
Latency bazlı path seçimi

Avantaj:

Büyük OLTP sistemler
Oracle / SQL ağır workload

Dezavantaj:

Lisans 💰
Ek agent

🔹 Vendor SATP’leri (Pure, NetApp, vb.)

VMware NMP’yi kullanır
Ama davranışları optimize eder
Genelde RR default gelir

📌 Güncel storage’larda:

Vendor SATP + RR = yeterli

🔥 Sahadan “altın öneriler”

All-Flash + ALUA → RR + IOPS=1
PSP değiştirmeden önce:
```
esxcli storage nmp device list
```
Queue Depth = körlemesine artırılmaz
PowerPath → ancak gerçekten ihtiyaç varsa

1️⃣ ESXCLI ile Optimized / Non-Optimized path kontrolü

🔹 Disk bazlı path’leri gör


esxcli storage core path list -d naa.xxx

Örnek çıktıdan bakacağın alanlar:


Path Selection Policy: VMW_PSP_RR
Target Transport Details: ALUA
State: active
Preferred: true

🔹 ALUA durumunu net görmek


esxcli storage nmp path list -d naa.xxx

Örnek:


Path State: active (I/O)
Path Type: Primary
Storage Array Type: ALUA

Path yorumlama:

Görülen değer	Anlamı
active (I/O) + Primary	✅ Optimized
active + Secondary	⚠️ Non-Optimized
standby	Pasif

📌 RR varsa:
Optimized path’ler arasında IO döner
Non-optimized sadece failover içindir

2️⃣ Canlı ortamda doğru PSP nasıl tespit edilir?

🔹 Adım 1 – Storage vendor’u öğren


esxcli storage core device list -d naa.xxx

Bakacağın satırlar:


Vendor: NETAPP
Model: LUN

🔹 Adım 2 – Kullanılan SATP / PSP


esxcli storage nmp device list -d naa.xxx

Örnek:


Storage Array Type: VMW_SATP_ALUA
Path Selection Policy: VMW_PSP_RR

🔹 Adım 3 – Vendor önerisi ile karşılaştır

NetApp → RR (IOPS=1)
Unity → RR
Active/Passive → Fixed

📌 Kritik kural

“Storage Active/Active + ALUA → RR”

Eğer:

PSP = Fixed
Storage = A/A

➡️ Performans boşa gidiyor demektir.

3️⃣ Queue Depth & RR ilişkisi

Bu konu genelde atlanır ama performansın %30’u burada 👀

🔹 Queue Depth nedir?

Bir path üzerinden aynı anda kaç IO gidebilir.

Katmanlar:

HBA Queue
Device Queue
Datastore Queue

Kontrol:


esxcli storage core device list -d naa.xxx | grep Queue

Örnek:


Device Max Queue Depth: 64

🔹 RR ile Queue Depth ilişkisi

❌ Yanlış senaryo:

RR + IOPS=1
Queue Depth = 32
8 path

➡️ Her path boş kalır, context switch artar

✅ Doğru denge:

RR load balancing sağlar
Ama Queue yeterli değilse path’ler aç kalır

📌 Pratik formül:


Toplam efektif queue ≈ Path sayısı × Queue Depth

Yani:

4 path × 64 = 256 IO kapasitesi

🔹 Ne zaman Queue artırılır?

Latency düşük ama IOPS düşükse
Storage hızlı ama ESXi sınırlıyorsa

⚠️ Vendor limitlerini aşma (özellikle iSCSI)

4️⃣ Vendor plugin farkları

(PowerPath, SATP, NMP)

🔹 VMware Native (NMP + SATP + PSP)

Varsayılan VMware yapısı:

SATP → Storage davranışını tanır
PSP → IO nasıl gitsin karar verir

Avantaj:

Ücretsiz
Stabil
Modern SAN’larda yeterli

🔹 Dell EMC PowerPath / VE

Özellikler:

Kendi multipath engine’i
Dinamik load balancing
Latency bazlı path seçimi

Avantaj:

Büyük OLTP sistemler
Oracle / SQL ağır workload

Dezavantaj:

Lisans 💰
Ek agent

🔹 Vendor SATP’leri (Pure, NetApp, vb.)

VMware NMP’yi kullanır
Ama davranışları optimize eder
Genelde RR default gelir

📌 Güncel storage’larda:

Vendor SATP + RR = yeterli

🔥 Sahadan “altın öneriler”

All-Flash + ALUA → RR + IOPS=1
PSP değiştirmeden önce:
```
esxcli storage nmp device list
```
Queue Depth = körlemesine artırılmaz
PowerPath → ancak gerçekten ihtiyaç varsa

1️⃣ ESXCLI ile Optimized / Non-Optimized path kontrolü

🔹 Disk bazlı path’leri gör


esxcli storage core path list -d naa.xxx

Örnek çıktıdan bakacağın alanlar:


Path Selection Policy: VMW_PSP_RR
Target Transport Details: ALUA
State: active
Preferred: true

🔹 ALUA durumunu net görmek


esxcli storage nmp path list -d naa.xxx

Örnek:


Path State: active (I/O)
Path Type: Primary
Storage Array Type: ALUA

Path yorumlama:

Görülen değer	Anlamı
active (I/O) + Primary	✅ Optimized
active + Secondary	⚠️ Non-Optimized
standby	Pasif

📌 RR varsa:
Optimized path’ler arasında IO döner
Non-optimized sadece failover içindir

2️⃣ Canlı ortamda doğru PSP nasıl tespit edilir?

🔹 Adım 1 – Storage vendor’u öğren


esxcli storage core device list -d naa.xxx

Bakacağın satırlar:


Vendor: NETAPP
Model: LUN

🔹 Adım 2 – Kullanılan SATP / PSP


esxcli storage nmp device list -d naa.xxx

Örnek:


Storage Array Type: VMW_SATP_ALUA
Path Selection Policy: VMW_PSP_RR

🔹 Adım 3 – Vendor önerisi ile karşılaştır

NetApp → RR (IOPS=1)
Unity → RR
Active/Passive → Fixed

📌 Kritik kural

“Storage Active/Active + ALUA → RR”

Eğer:

PSP = Fixed
Storage = A/A

➡️ Performans boşa gidiyor demektir.

3️⃣ Queue Depth & RR ilişkisi

Bu konu genelde atlanır ama performansın %30’u burada 👀

🔹 Queue Depth nedir?

Bir path üzerinden aynı anda kaç IO gidebilir.

Katmanlar:

HBA Queue
Device Queue
Datastore Queue

Kontrol:


esxcli storage core device list -d naa.xxx | grep Queue

Örnek:


Device Max Queue Depth: 64

🔹 RR ile Queue Depth ilişkisi

❌ Yanlış senaryo:

RR + IOPS=1
Queue Depth = 32
8 path

➡️ Her path boş kalır, context switch artar

✅ Doğru denge:

RR load balancing sağlar
Ama Queue yeterli değilse path’ler aç kalır

📌 Pratik formül:


Toplam efektif queue ≈ Path sayısı × Queue Depth

Yani:

4 path × 64 = 256 IO kapasitesi

🔹 Ne zaman Queue artırılır?

Latency düşük ama IOPS düşükse
Storage hızlı ama ESXi sınırlıyorsa

⚠️ Vendor limitlerini aşma (özellikle iSCSI)

4️⃣ Vendor plugin farkları

(PowerPath, SATP, NMP)

🔹 VMware Native (NMP + SATP + PSP)

Varsayılan VMware yapısı:

SATP → Storage davranışını tanır
PSP → IO nasıl gitsin karar verir

Avantaj:

Ücretsiz
Stabil
Modern SAN’larda yeterli

🔹 Dell EMC PowerPath / VE

Özellikler:

Kendi multipath engine’i
Dinamik load balancing
Latency bazlı path seçimi

Avantaj:

Büyük OLTP sistemler
Oracle / SQL ağır workload

Dezavantaj:

Lisans 💰
Ek agent

🔹 Vendor SATP’leri (Pure, NetApp, vb.)

VMware NMP’yi kullanır
Ama davranışları optimize eder
Genelde RR default gelir

📌 Güncel storage’larda:

Vendor SATP + RR = yeterli

🔥 Sahadan “altın öneriler”

All-Flash + ALUA → RR + IOPS=1
PSP değiştirmeden önce:
```
esxcli storage nmp device list
```
Queue Depth = körlemesine artırılmaz
PowerPath → ancak gerçekten ihtiyaç varsa

воскресенье, 23 февраля 2025 г.

What is ESXi multipathing?

ESXi Multipath nedir?

VMware tarafındaki temel kavramlar

1️⃣ NMP (Native Multipathing Plugin)

2️⃣ PSP (Path Selection Policy)

Senin kullandığın komutların açıklaması

1️⃣ Device ve multipath durumunu görmek

2️⃣ Round Robin ayarını IOPS = 1 yapmak

Ne yapar?

Parametreler:

3️⃣ Aynı ayarı ayrı ayrı vermen

4️⃣ PowerShell – winsat disk

Kısa özet 🧠

1️⃣ Hangi storage’da Round Robin (RR) kullanılır?

✅ RR kullanılabilecek (önerilen) storage tipleri

❌ RR kullanılmaması gereken durumlar

2️⃣ Fixed mi RR mi?

🔹 Fixed PSP

🔹 Round Robin PSP

3️⃣ ALUA vs Active / Passive farkı

🔹 Active / Passive (klasik)

🔹 ALUA (Asymmetric Logical Unit Access)

4️⃣ IOPS=1 her zaman doğru mu?

✅ IOPS=1 önerilen senaryolar

⚠️ Dikkat edilmesi gereken durumlar

🎯 Pratik öneri (sahadan)

Altın kurallar 🥇

1️⃣ ESXCLI ile Optimized / Non-Optimized path kontrolü

🔹 Disk bazlı path’leri gör

🔹 ALUA durumunu net görmek

Path yorumlama:

2️⃣ Canlı ortamda doğru PSP nasıl tespit edilir?

🔹 Adım 1 – Storage vendor’u öğren

🔹 Adım 2 – Kullanılan SATP / PSP

🔹 Adım 3 – Vendor önerisi ile karşılaştır

3️⃣ Queue Depth & RR ilişkisi

🔹 Queue Depth nedir?

🔹 RR ile Queue Depth ilişkisi

❌ Yanlış senaryo:

✅ Doğru denge:

🔹 Ne zaman Queue artırılır?

4️⃣ Vendor plugin farkları

🔹 VMware Native (NMP + SATP + PSP)

🔹 Dell EMC PowerPath / VE

🔹 Vendor SATP’leri (Pure, NetApp, vb.)

🔥 Sahadan “altın öneriler”

1️⃣ ESXCLI ile Optimized / Non-Optimized path kontrolü

🔹 Disk bazlı path’leri gör

🔹 ALUA durumunu net görmek

Path yorumlama:

2️⃣ Canlı ortamda doğru PSP nasıl tespit edilir?

🔹 Adım 1 – Storage vendor’u öğren

🔹 Adım 2 – Kullanılan SATP / PSP

🔹 Adım 3 – Vendor önerisi ile karşılaştır

3️⃣ Queue Depth & RR ilişkisi

🔹 Queue Depth nedir?

🔹 RR ile Queue Depth ilişkisi

❌ Yanlış senaryo:

✅ Doğru denge:

🔹 Ne zaman Queue artırılır?

4️⃣ Vendor plugin farkları

🔹 VMware Native (NMP + SATP + PSP)

🔹 Dell EMC PowerPath / VE

🔹 Vendor SATP’leri (Pure, NetApp, vb.)

🔥 Sahadan “altın öneriler”

1️⃣ ESXCLI ile Optimized / Non-Optimized path kontrolü

🔹 Disk bazlı path’leri gör

🔹 ALUA durumunu net görmek

Path yorumlama:

2️⃣ Canlı ortamda doğru PSP nasıl tespit edilir?

🔹 Adım 1 – Storage vendor’u öğren

🔹 Adım 2 – Kullanılan SATP / PSP

🔹 Adım 3 – Vendor önerisi ile karşılaştır

3️⃣ Queue Depth & RR ilişkisi

🔹 Queue Depth nedir?

🔹 RR ile Queue Depth ilişkisi

❌ Yanlış senaryo:

✅ Doğru denge:

🔹 Ne zaman Queue artırılır?

воскресенье, 23 февраля 2025 г.

4️⃣ PowerShell – `winsat disk`