пятница, 12 декабря 2025 г.

ESXi Real Troubleshooting Scenario

 

1️⃣ Gerçek troubleshooting senaryosu (Case Study)

🎯 Senaryo

  • Storage: All-Flash iSCSI (Active/Active, ALUA)

  • ESXi: 7.x

  • Şikayet:

    “VM’ler arada donuyor ama storage dashboard yeşil”

🔍 Adım 1 – esxtop (disk)

DAVG/cmd: 3–4 ms  ✅
KAVG/cmd: 0.5 ms  ✅
QAVG/cmd: 15–20 ms ❌

➡️ Storage hızlı ama IO queue’da bekliyor

🔍 Adım 2 – Path dağılımı

Path1: 90% IO
Path2–4: %3–4

➡️ RR var gibi ama fiilen Fixed çalışıyor

🔍 Adım 3 – PSP kontrolü

PSP: VMW_PSP_RR
IOPS: 1000 (default)

🎯 Root cause bulundu

🛠️ Çözüm

esxcli storage nmp psp roundrobin deviceconfig set \
-d naa.xxx -t iops -I 1 -U true

📈 Sonuç

MetricÖnceSonra
QAVG18 ms0.3 ms
VM freezeVarYok
IO dağılımıDengesizDengeli

📌 Storage değil, multipath ayarı suçluydu.

2️⃣ iSCSI vs FC – Latency farkları (gerçek hayat)

🔹 iSCSI

  • TCP/IP

  • CPU etkisi var

  • NIC & MTU hassas

Tipik latency (All-Flash):

  • 0.8 – 2 ms

🔹 Fibre Channel

  • Dedicated fabric

  • Daha stabil

  • CPU yükü yok

Tipik latency:

  • 0.5 – 1 ms

⚖️ Karşılaştırma tablosu

ÖzellikiSCSIFC
LatencyBir tık yüksekDaha düşük
MaliyetDüşükYüksek
YönetimKolayKarmaşık
Multipath hassasiyetiYüksekOrta

📌 Yanlış iSCSI tuning = FC’den 5 kat yavaş

3️⃣ NVMe-oF multipath tuning

NVMe-oF = latency canavarı ⚡
Ama yanlış ayarla çöpe gider.

🔹 NVMe-oF vs SCSI farkı

  • Queue depth çok daha yüksek

  • Path switching çok hızlı

🔹 En iyi pratikler

  • PSP: RR

  • IOPS: 1

  • Path sayısı: 2–4 (fazlası gereksiz)

  • Queue Depth: Vendor default

🔹 Kontrol komutları

esxcli nvme device list
esxcli nvme path list

Latency esxtop’ta:

DAVG < 1 ms
QAVG ≈ 0

🚨 Eğer QAVG > 1 ms ise:

  • Fazla path

  • NIC oversubscription

4️⃣ VM bazlı latency analizi (altın değerinde)

🔹 esxtop → VM view

v

Açılacak kolonlar:

  • GAVG

  • DAVG

  • KAVG

  • QAVG

🔍 Yorumlama

DurumAnlam
VM GAVG yüksek, host düşükVM içi problem
VM + Host yüksekStorage
VM tek başına yüksekNoisy neighbor

🔹 VM içinden teyit

Windows

diskspd -c10G -d30 -r -w30 -b8K -t4 -o32 c:\test.dat

Linux

iostat -x 1

🚨 En kritik red flag (ezberle)

“Host storage hızlı ama tek VM yavaşsa,
suçlu %90 VM içi IO pattern’dır.”

🎯 Final özet

  • esxtop = gerçek hayat

  • QAVG = multipath alarmı

  • iSCSI doğru ayarlanırsa FC’ye yaklaşır

  • NVMe-oF küçük hatayı affetmez

  • VM bazlı analiz = root cause buldurur

Автор: на Комментариев нет:

понедельник, 7 июля 2025 г.

ESXTOP Disk View – Real Latency Analysis (Production Scenario)

  • 1️⃣ Gerçek latency analizi – esxtop (disk view)

    🔹 esxtop başlat

    esxtop

    🔹 Disk ekranına geç

    d

    🔹 Latency kolonlarını aç (çok kritik)

    f

    Aç (SPACE ile):

    • DAVG/cmd → Device latency (storage)

    • KAVG/cmd → Kernel latency (ESXi)

    • GAVG/cmd → Guest gördüğü latency

    • QAVG/cmd → Queue latency

    📊 Latency değerleri nasıl yorumlanır?

    DeğerNormalAlarm
    DAVG< 5 ms (flash)> 20 ms
    KAVG< 1 ms> 2 ms
    QAVG≈ 0> 5 ms
    GAVGDAVG + KAVG—

    🔥 Alarm senaryoları

    • DAVG yüksek → Storage tarafı yavaş

    • QAVG yüksek → Queue dolu (multipath / queue issue)

    • KAVG yüksek → ESXi / driver / HBA sorunu

    📌 Multipath problemi %90 QAVG olarak çıkar

    2️⃣ Path başına IO dağılımını canlı görmek

    🔹 esxtop → Disk → Path view

    d
p

    Bu ekran:

    • Her path’in ayrı IO aldığını gösterir

    • RR düzgün çalışıyor mu → burada belli olur

    Bakacağın kolonlar:

    • CMDS/s

    • READS/s

    • WRITES/s

    • LAT/rd, LAT/wr

    🔹 Sağlıklı RR nasıl görünür?

    • Path’ler arasında yakın değerler

    • 1 path %90 yükteyse ❌

    📌 Eğer:

    • Sadece 1 path IO alıyorsa
      ➡️ RR çalışmıyor / Fixed aktif

    3️⃣ PSP değiştirince performans nasıl ölçülür?

    🔹 Adım adım doğru yöntem

    1️⃣ Değişiklik öncesi snapshot al

    • esxtop değerleri (avg)

    • Latency not et

    • IO dağılımı

    2️⃣ PSP değiştir

    esxcli storage nmp device set -d naa.xxx -p VMW_PSP_RR

    IOPS=1 ver:

    esxcli storage nmp psp roundrobin deviceconfig set \
-d naa.xxx -t iops -I 1 -U true

    3️⃣ Load altında ölç

    • Prod workload açıkken

    • esxtop ile 5–10 dk izle

    📈 Beklenen sonuçlar

    MetricÖnceSonra
    DAVGYüksek⬇
    QAVGYüksek⬇⬇
    Path IODengesizDengeli

    📌 Sadece boşta ölçüm = yanlış sonuç

    4️⃣ Yanlış multipath red flag’ler 🚨

    Bunları görüyorsan dur ve incele 👇

    ❌ Red Flag #1

    RR var ama sadece 1 path IO alıyor

    ➡️ Sebep:

    • ALUA non-optimized path’ler

    • Storage Active/Passive

    ❌ Red Flag #2

    QAVG sürekli yüksek

    ➡️ Sebep:

    • Queue Depth düşük

    • RR + çok path + IOPS=1 dengesiz

    ❌ Red Flag #3

    Latency anlık zıplıyor

    ➡️ Sebep:

    • Path thrashing

    • Yanlış PSP

    • IOPS çok düşük / çok yüksek

    ❌ Red Flag #4

    APD / PDL event’leri

    /var/log/vmkernel.log

    ➡️ Multipath failover sorunu

    ❌ Red Flag #5

    Storage hızlı ama VM yavaş

    ➡️ %80 ihtimalle:

    • PSP yanlış

    • RR default (1000 IOPS)

    • Queue yanlış

    🧠 Mini teşhis checklist (ezberle bunu)

    • esxtop → DAVG / KAVG / QAVG

    • Path view → IO dağılıyor mu?

    • PSP = RR mi?

    • IOPS = 1 mi?

    • Queue Depth mantıklı mı?

    • Vendor guide uyuyor mu?

    🔥 Son söz (sahadan gerçek)

    “Latency problemi storage değil,
    %70 multipath & queue konfigürasyonudur.”

Автор: на Комментариев нет:

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

What is ESXi multipathing?

 

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 tipiPSP
Active/Active✅ RR
Active/Passive❌ Fixed
Vendor özel pluginVendor 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)

OrtamIOPS değeri
All-Flash1
Hybrid SAN4 – 8
Eski FC16
Vendor pluginDeğ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ğerAnlamı
active (I/O) + Primary✅ Optimized
active + Secondary⚠️ Non-Optimized
standbyPasif

📌 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ğerAnlamı
active (I/O) + Primary✅ Optimized
active + Secondary⚠️ Non-Optimized
standbyPasif

📌 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ğerAnlamı
active (I/O) + Primary✅ Optimized
active + Secondary⚠️ Non-Optimized
standbyPasif

📌 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


Автор: на Комментариев нет:
Подписаться на: Комментарии (Atom)