Reset the HP iLO Administrator password with hponcfg on ESXi

ESXi üzərində hponcfg ilə HP iLO Administrator parolunun sıfırlanması

Bəzən iLO Administrator parolunu sıfırlamaq lazım olur. Əlbəttə, serveri yenidən başladıb F8 düyməsinə basaraq Administrator parolunu dəyişmək olar. Amma əgər HP tərəfindən özəlləşdirilmiş ESXi image quraşdırmısınızsa, parolu sıfırlamaq üçün daha rahat bir yol var: HPONCFG.

/opt/hp/tools qovluğunu yoxlayın. Burada hponcfg adlı bir binary fayl tapacaqsınız.

~ # ls -l /opt/hp/tools/
total 5432
-r-xr-xr-x 1 root root 5129574 Oct 28 2014 conrep
-r--r--r-- 1 root root 108802 Oct 28 2014 conrep.xml
-r-xr-xr-x 1 root root 59849 Jan 16 2015 hpbootcfg
-r-xr-xr-x 1 root root 251 Jan 16 2015 hpbootcfg_esxcli
-r-xr-xr-x 1 root root 232418 Jul 14 2014 hponcfg
-r-xr-xr-x 1 root root 12529 Oct 31 2013 hptestevent
-r-xr-xr-x 1 root root 250 Oct 31 2013 hptestevent_esxcli

Sizə sadəcə sadə bir XML fayl lazımdır. Bunu VI editor ilə yarada bilərsiniz və ya WinSCP vasitəsilə faylı ESXi host-un root qovluğuna köçürə bilərsiniz. Mən VI istifadə etməyi üstün tuturam.

Əvvəlcə /opt/hp/tools qovluğuna keçin və sonra pwreset.xml faylını açın.

~ # vi pwreset.xml

Insert mode-a keçmək üçün i düyməsini basın və aşağıdakı məzmunu fayla yapışdırın. Cari parolu bilməyə ehtiyac yoxdur!

<RIBCL VERSION="2.0">
<LOGIN USER_LOGIN="Administrator" PASSWORD="unknown">
<USER_INFO MODE="write">
<MOD_USER USER_LOGIN="Administrator">
<PASSWORD value="password"/>
</MOD_USER>
</USER_INFO>
</LOGIN>
</RIBCL>

ESC düyməsini basın, sonra :wq<ENTER> yazaraq faylı yadda saxlayın və VI-dan çıxın.

İndi HPONCFG alətini XML faylı ilə birlikdə işə salaraq parolu sıfırlayın.

~ # /opt/hp/tools/hponcfg -f pwreset.xml

Nəticə belə olacaq:

HP Lights-Out Online Configuration utility

Version 4.4-0 (c) Hewlett-Packard Company, 2014
Firmware Revision = 1.85 Device type = iLO 3 Driver name = hpilo
iLO IP Address: 172.16.1.52
Script succeeded

🎉 Hazırdır!
Artıq Administrator istifadəçi adı və password parolu ilə iLO-ya daxil ola bilərsiniz.

ESXI CHECK DISK HEALTH

 

1️⃣ esxcli nvme device list

🔍 Ne işe yarar?

ESXi host’a bağlı tüm NVMe cihazları listeler.

📌 Örnek çıktı alanları (yorumlu):

Device: t10.NVMe____SAMSUNG_MZVL2512HCJQ2D00B00...
Adapter: vmhba1
Controller: vmhba1
Queue Depth: 1024
Firmware Version: EDA7901Q
Model: SAMSUNG MZVL2512HCJQ2D00
Namespace Count: 1

🧠 Nasıl yorumlanır?

• Queue Depth (1024+) → NVMe için normal ✅

• Firmware → Vendor önerisiyle aynı olmalı

• Namespace Count → Genelde 1 (normal)

🚨 Alarm:

• Queue Depth çok düşükse (128 altı)

• Firmware eskiyse

---

2️⃣ NVMe disk SMART bilgisi

esxcli storage core device smart get -d t10.NVMe____SAMSUNG_...

🔍 Ne işe yarar?

NVMe diskin sağlık durumunu gösterir.

---

📌 Kritik alanlar (tek tek açıklama)

Alan	Anlam	Normal
Health Status	Disk sağlığı	OK
Media Wearout Indicator	Ömür yüzdesi	> 80
Power On Hours	Çalışma süresi	Bilgi
Unsafe Shutdowns	Ani kapama	0–az
Temperature	Disk sıcaklığı	< 70°C

📌 Media Wearout %70 altı → planla
📌 Unsafe Shutdown artıyorsa → power / UPS sorunu

---

3️⃣ NVMe SMART log (adapter bazlı)

esxcli nvme device log smart get -A vmhba1
esxcli nvme device log smart get -A vmhba2

🔍 Ne işe yarar?

NVMe controller (path) bazında hata ve sağlık kontrolü.

---

📌 Önemli alanlar

Alan	Açıklama	Alarm
Critical Warning	Genel sağlık	0 olmalı
Media Errors	Okuma/yazma hata	>0 ❌
Error Log Entries	Toplam hata	Artıyorsa ❌
Temperature	Controller sıcaklığı	>80 ❌

📌 vmhba1 ile vmhba2 benzer değerlerde olmalı
Biri yüksekse → path / PCI / slot sorunu

---

4️⃣ esxcli storage core device list

🔍 Ne işe yarar?

Diskin ESXi tarafından nasıl görüldüğünü gösterir.

---

📌 Kritik alanlar:

Display Name: Local ATA Disk
Vendor: NVMe
Model: SAMSUNG...
Multipath Plugin: NMP
Devfs Path: /vmfs/devices/disks/...
Queue Full Sample Size
Device Max Queue Depth

🧠 Yorum:

• Multipath Plugin:

  • NVMe-oF → NMP / HPP

  • Local NVMe → multipath yok

• Queue Depth → Storage performans limiti

🚨 Alarm:

• Queue Depth çok düşük

• Path sayısı beklenenden az

---

5️⃣ ATA disk (TOSHIBA) SMART analizi

esxcli storage core device smart get \
-d t10.ATA_____TOSHIBA_MG04ACA200EY...

🔍 Ne işe yarar?

Klasik SATA / SAS disk sağlık kontrolü.

---

📌 Kritik SMART alanları

Alan	Normal	Alarm
Reallocated Sector Count	0	>0
Current Pending Sector	0	>0
Uncorrectable Errors	0	>0
Temperature	< 50°C	> 60°C

📌 HDD ise:

• Latency doğal olarak yüksek

• Queue çok çabuk dolar

---

🔥 NVMe vs ATA – canlı fark

Özellik	NVMe	ATA HDD
Queue Depth	1024+	32
Latency	<1 ms	5–15 ms
SMART detay	Çok zengin	Sınırlı

---

🚨 Sahada sık görülen red flag’ler

❌ NVMe var ama latency yüksek
➡️ PCI slot paylaşımı / NUMA

❌ vmhba1 OK, vmhba2 hata dolu
➡️ Path / firmware / kablo

❌ SMART OK ama performans kötü
➡️ Queue & multipath ayarı

---

🧠 Kısa checklist (ezber)

• esxcli nvme device list

• SMART = OK

• vmhba path’ler dengeli

• Queue Depth mantıklı

• esxtop DAVG < 1 ms

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	Önce	Sonra
QAVG	18 ms	0.3 ms
VM freeze	Var	Yok
IO dağılımı	Dengesiz	Dengeli

📌 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

Özellik	iSCSI	FC
Latency	Bir tık yüksek	Daha düşük
Maliyet	Düşük	Yüksek
Yönetim	Kolay	Karmaşık
Multipath hassasiyeti	Yüksek	Orta

📌 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

Durum	Anlam
VM GAVG yüksek, host düşük	VM içi problem
VM + Host yüksek	Storage
VM tek başına yüksek	Noisy 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

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ğer	Normal	Alarm
  DAVG	< 5 ms (flash)	> 20 ms
  KAVG	< 1 ms	> 2 ms
  QAVG	≈ 0	> 5 ms
  GAVG	DAVG + 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	Önce	Sonra
  DAVG	Yüksek	⬇
  QAVG	Yüksek	⬇⬇
  Path IO	Dengesiz	Dengeli

  📌 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.”

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 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