Kurumsal sanallaştırma ortamlarında depolama altyapısının doğru yapılandırılması, sanal makinelerin performansı kadar hizmet sürekliliği açısından da önemlidir. Özellikle VMware ESXi sunucularının Fibre Channel (FC) üzerinden Huawei OceanStor gibi merkezi depolama sistemlerine bağlandığı ortamlarda, depolama yollarının doğru yönetilmesi kritik bir rol oynar.
Bir ESXi sunucusunun storage sistemine yalnızca tek bir fiziksel bağlantı üzerinden erişmesi, bağlantı üzerinde oluşabilecek arızalarda hizmet kesintisi riskini artırabilir. Bu nedenle kurumsal SAN mimarilerinde genellikle birden fazla HBA, SAN fabric ve storage controller bağlantısıyla yedeklilik sağlanır.
VMware ESXi, bu bağlantı yollarını yönetmek için Native Multipathing (NMP) mekanizmasını kullanır. NMP sayesinde aynı LUN’a birden fazla yol üzerinden erişilebilir, uygun durumlarda I/O yükü yollar arasında dağıtılabilir ve bağlantı arızalarında alternatif yollar kullanılabilir.
Bu makalede, Huawei Storage sistemine Fibre Channel üzerinden bağlı üç VMware ESXi sunucusunda gerçekleştirdiğimiz Multipathing kontrollerini ele alacağız. Gerçek ortamdan elde edilen komut çıktılarını inceleyerek SATP ve PSP politikalarının nasıl çalıştığını, Huawei’nin önerdiği kuralların nasıl tanımlandığını ve mevcut yapılandırmanın nasıl doğrulandığını açıklayacağız.
Çalışmada kullanılan sunucu adları güvenlik amacıyla anonimleştirilmiştir.
| ESXi sunucusu | İnceleme kapsamı |
|---|---|
| ABC-ESX01 | LUN keşfi, SATP kuralları, Round Robin ve path kontrolü |
| ABC-ESX02 | LUN keşfi, SATP kuralları, Round Robin ve path kontrolü |
| ABC-ESX03 | LUN keşfi, SATP kuralları, Round Robin ve path kontrolü |
Tüm örnekler, ortamda tespit edilen HUAWEI / XSG1 cihazlarına dayanmaktadır. XSG1 değeri ESXi’nin gördüğü SCSI model tanımlayıcısıdır; Huawei cihazının kesin ticari modelini tek başına belirlemez.
VMware Native Multipathing (NMP) nasıl çalışır?
VMware NMP, depolama cihazlarının erişim yollarını yönetir. Bu yapının iki temel bileşeni SATP ve PSP’dir.
SATP (Storage Array Type Plugin), storage sisteminin yol yönetimi ve failover davranışını belirler. Bir depolama sisteminin Active/Active veya ALUA erişim modeline uygun şekilde çalışmasını sağlar.
PSP (Path Selection Plugin) ise I/O işlemlerinin hangi erişim yolundan gönderileceğini belirler.
Örneğin VMW_PSP_RR olarak adlandırılan Round Robin politikası, kullanılabilir ve uygun durumdaki birden fazla depolama yolu arasında I/O işlemlerini dağıtabilir.

Huawei için kullanılan SATP ve PSP kombinasyonları
| Huawei erişim modu | VMware SATP | VMware PSP |
|---|---|---|
| Load Balancing / ALUA kullanılmıyor | VMW_SATP_DEFAULT_AA | VMW_PSP_RR |
| Asymmetric / ALUA | VMW_SATP_ALUA | VMW_PSP_RR |
Huawei dokümantasyonunda tpgs_off ve tpgs_on koşullarına göre iki SATP kuralının aynı ESXi host üzerinde bulunabileceği açıklanmaktadır.
Burada önemli nokta, VMware tarafında kullanılacak SATP politikasının Huawei storage üzerindeki erişim moduyla uyumlu olmasıdır.
İncelenen VMware ve Huawei altyapısı
Yapılan kontrollerde üç ESXi sunucusunun aynı iki Huawei LUN’una eriştiği görülmüştür.
| Özellik | Birinci LUN | İkinci LUN |
|---|---|---|
| Kapasite | 10 TiB | 20 TiB |
| Vendor | HUAWEI | HUAWEI |
| Model | XSG1 | XSG1 |
| Revision | 6000 | 6000 |
| Protokol | Fibre Channel | Fibre Channel |
| Multipath Plugin | NMP | NMP |
| Cihaz durumu | on | on |
| SSD olarak bildiriliyor | Evet | Evet |
| Thin Provisioning | yes | yes |
| VAAI | supported | supported |
Storage cihazlarının NAA adresleri:
Birinci LUN (10 TiB):
naa.658be72100f678c3000fc01600000001
İkinci LUN (20 TiB):
naa.658be72100f678c300053b9400000000
NAA (Network Address Authority), ESXi’nin depolama cihazlarını tanımlarken kullandığı benzersiz kimlik bilgilerinden biridir. Multipathing komutlarında ilgili cihazın doğru NAA değerinin kullanılması gerekir.
Huawei Storage LUN’larının ESXi üzerinde keşfedilmesi
İlk aşamada ESXi sunucusuna SSH üzerinden bağlanıyoruz. Ardından Huawei Storage tarafından sunulan disklerin ESXi tarafından algılanıp algılanmadığını kontrol ediyoruz.
Çalıştırdığımız komut:
esxcli storage core device list | grep -i -A 20 HUAWEI
Bu komut ESXi üzerindeki depolama cihazları arasında Huawei üreticisine ait kayıtları bulur ve devamındaki cihaz bilgilerini listeler.
ABC-ESX01 üzerinde alınan gerçek çıktı
[root@ABC-ESX01:~] esxcli storage core device list | grep -i -A 20 HUAWEI
Display Name: HUAWEI Fibre Channel Disk (naa.658be72100f678c3000fc01600000001)
Has Settable Display Name: true
Size: 10485760
Device Type: Direct-Access
Multipath Plugin: NMP
Devfs Path: /vmfs/devices/disks/naa.658be72100f678c3000fc01600000001
Vendor: HUAWEI
Model: XSG1
Revision: 6000
SCSI Level: 6
Is Pseudo: false
Status: on
Is RDM Capable: true
Is Local: false
Is Removable: false
Is SSD: true
Is VVOL PE: false
Is Offline: false
Is Perennially Reserved: false
Queue Full Sample Size: 0
Queue Full Threshold: 0
Thin Provisioning Status: yes
Attached Filters:
VAAI Status: supported
Other UIDs: vml.0200020000658be72100f678c3000fc01600000001585347312020
Is Shared Clusterwide: true
Is SAS: false
--
Display Name: HUAWEI Fibre Channel Disk (naa.658be72100f678c300053b9400000000)
Has Settable Display Name: true
Size: 20971520
Device Type: Direct-Access
Multipath Plugin: NMP
Devfs Path: /vmfs/devices/disks/naa.658be72100f678c300053b9400000000
Vendor: HUAWEI
Model: XSG1
Revision: 6000
SCSI Level: 6
Is Pseudo: false
Status: on
Is RDM Capable: true
Is Local: false
Is Removable: false
Is SSD: true
Is VVOL PE: false
Is Offline: false
Is Perennially Reserved: false
Queue Full Sample Size: 0
Queue Full Threshold: 0
Thin Provisioning Status: yes
Attached Filters:
VAAI Status: supported
Other UIDs: vml.0200010000658be72100f678c300053b9400000000585347312020
Is Shared Clusterwide: true
Is SAS: false
Komut çıktısını nasıl yorumlamalıyız?
Çıktıda öncelikle Vendor: HUAWEI ve Model: XSG1 bilgilerini görüyoruz. Bu alanlar, ESXi sunucusuna tanıtılan depolama cihazının üretici ve model tanımlayıcılarını gösteriyor. Multipath Plugin: NMP bilgisi, cihazın VMware Native Multipathing tarafından yönetildiğini doğruluyor. Status: on ve Is Offline: false değerleri ise cihazın komut çalıştırıldığı anda ESXi tarafından erişilebilir durumda olduğunu gösteriyor. Ayrıca cihazlar Is SSD: true olarak bildiriliyor ve VAAI Status: supported özelliğine sahip. Burada dikkat edilmesi gereken nokta: NMP’nin aktif olması Round Robin’in etkin olduğunu göstermez. Hangi SATP ve PSP politikalarının kullanıldığını ayrı komutlarla incelememiz gerekir.
ABC-ESX01 üzerinde SATP ve PSP kontrolü
Huawei LUN’larını tespit ettikten sonra ikinci aşamada bu LUN’ların hangi Multipathing politikalarıyla çalıştığını kontrol ediyoruz.
Kullanacağımız temel komut:
esxcli storage nmp device list -d <LUN_NAA_ID>
Buradaki NAA değeri ilgili ortamın gerçek cihaz kimliğiyle değiştirilmelidir.
1. Birinci Huawei LUN
Komut:
esxcli storage nmp device list -d naa.658be72100f678c3000fc01600000001
Alınan gerçek çıktı:
[root@ABC-ESX01:~] esxcli storage nmp device list -d naa.658be72100f678c3000fc01600000001
naa.658be72100f678c3000fc01600000001
Device Display Name: HUAWEI Fibre Channel Disk (naa.658be72100f678c3000fc01600000001)
Storage Array Type: VMW_SATP_DEFAULT_AA
Storage Array Type Device Config: {action_OnRetryErrors=off}
Path Selection Policy: VMW_PSP_RR
Path Selection Policy Device Config: {policy=rr,iops=1000,bytes=10485760,useANO=0; lastPathIndex=3: NumIOsPending=0,numBytesPending=0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba1:C0:T4:L2, vmhba1:C0:T0:L2, vmhba2:C0:T6:L2, vmhba2:C0:T5:L2
Is USB: false
[root@ABC-ESX01:~]
Bu çıktıyı incelediğimizde iki önemli bilgiyle karşılaşıyoruz. İlki, Storage Array Type: VMW_SATP_DEFAULT_AA değeridir. Bu değer, LUN’un VMware tarafından Active/Active SATP üzerinden yönetildiğini gösteriyor. İkincisi ise Path Selection Policy: VMW_PSP_RR değeridir. Bu bilgi sayesinde Round Robin’in zaten etkin olduğunu doğruluyoruz. Ayrıca iops=1000, I/O sayısına dayalı mevcut yol değiştirme eşiğini gösteriyor. Çıktının Working Paths bölümünde ise dört yol bulunuyor:
vmhba1:C0:T4:L2
vmhba1:C0:T0:L2
vmhba2:C0:T6:L2
vmhba2:C0:T5:L2
Bu yolların ikisi vmhba1, diğer ikisi vmhba2 Fibre Channel adaptörü üzerinden sunuluyor.
Dolayısıyla birinci Huawei LUN için iki HBA üzerinden toplam dört çalışma yolu listelendiğini görüyoruz.
2. İkinci Huawei LUN
İkinci LUN için aynı sorgulamayı yapıyoruz.
esxcli storage nmp device list -d naa.658be72100f678c300053b9400000000
Gerçek komut çıktısı:
[root@ABC-ESX01:~] esxcli storage nmp device list -d naa.658be72100f678c300053b9400000000
naa.658be72100f678c300053b9400000000
Device Display Name: HUAWEI Fibre Channel Disk (naa.658be72100f678c300053b9400000000)
Storage Array Type: VMW_SATP_DEFAULT_AA
Storage Array Type Device Config: {action_OnRetryErrors=off}
Path Selection Policy: VMW_PSP_RR
Path Selection Policy Device Config: {policy=rr,iops=1000,bytes=10485760,useANO=0; lastPathIndex=3: NumIOsPending=0,numBytesPending=0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba1:C0:T4:L1, vmhba1:C0:T0:L1, vmhba2:C0:T6:L1, vmhba2:C0:T5:L1
Is USB: false
[root@ABC-ESX01:~]
İkinci LUN için de aynı SATP ve PSP politikalarının kullanıldığını görüyoruz. Her iki LUN’da VMW_SATP_DEFAULT_AA ile VMW_PSP_RR aktif ve Round Robin IOPS değeri 1000. Bu sonuç, ABC-ESX01 üzerindeki iki Huawei LUN’un aynı Multipathing politikalarıyla çalıştığını doğruluyor.
ABC-ESX02 üzerinde Multipathing kontrolü
Birden fazla ESXi sunucusunun ortak storage sistemine bağlandığı ortamlarda yalnızca bir hostun yapılandırmasını incelemek yeterli değildir.
Bu nedenle ikinci ESXi sunucusunda aynı kontrolleri gerçekleştiriyoruz.
1. Birinci Huawei LUN
esxcli storage nmp device list -d naa.658be72100f678c3000fc01600000001
Komut çıktısı:
[root@ABC-ESX02:~] esxcli storage nmp device list -d naa.658be72100f678c3000fc01600000001
naa.658be72100f678c3000fc01600000001
Device Display Name: HUAWEI Fibre Channel Disk (naa.658be72100f678c3000fc01600000001)
Storage Array Type: VMW_SATP_DEFAULT_AA
Storage Array Type Device Config: {action_OnRetryErrors=off}
Path Selection Policy: VMW_PSP_RR
Path Selection Policy Device Config: {policy=rr,iops=1000,bytes=10485760,useANO=0; lastPathIndex=1: NumIOsPending=0,numBytesPending=0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba1:C0:T3:L2, vmhba1:C0:T6:L2, vmhba2:C0:T7:L2, vmhba2:C0:T6:L2
Is USB: false
[root@ABC-ESX02:~]
2. İkinci Huawei LUN
esxcli storage nmp device list -d naa.658be72100f678c300053b9400000000
Komut çıktısı:
[root@ABC-ESX02:~] esxcli storage nmp device list -d naa.658be72100f678c300053b9400000000
naa.658be72100f678c300053b9400000000
Device Display Name: HUAWEI Fibre Channel Disk (naa.658be72100f678c300053b9400000000)
Storage Array Type: VMW_SATP_DEFAULT_AA
Storage Array Type Device Config: {action_OnRetryErrors=off}
Path Selection Policy: VMW_PSP_RR
Path Selection Policy Device Config: {policy=rr,iops=1000,bytes=10485760,useANO=0; lastPathIndex=2: NumIOsPending=0,numBytesPending=0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba1:C0:T3:L1, vmhba1:C0:T6:L1, vmhba2:C0:T7:L1, vmhba2:C0:T6:L1
Is USB: false
[root@ABC-ESX02:~]
ABC-ESX02 üzerinde de her iki Huawei LUN için aynı SATP ve PSP politikalarının kullanıldığını görüyoruz.
Her LUN için dört çalışma yolu bulunmakta ve iki Fibre Channel adaptörü kullanılmaktadır.
ESX01C-ESX03 üzerinde Multipathing kontrolü
Üçüncü ESXi host üzerinde de aynı LUN’lara erişim sağlanmaktadır.
1. Birinci Huawei LUN
esxcli storage nmp device list -d naa.658be72100f678c3000fc01600000001
Komut çıktısı:
[root@ESX01C-ESX03:~] esxcli storage nmp device list -d naa.658be72100f678c3000fc01600000001
naa.658be72100f678c3000fc01600000001
Device Display Name: HUAWEI Fibre Channel Disk (naa.658be72100f678c3000fc01600000001)
Storage Array Type: VMW_SATP_DEFAULT_AA
Storage Array Type Device Config: {action_OnRetryErrors=off}
Path Selection Policy: VMW_PSP_RR
Path Selection Policy Device Config: {policy=rr,iops=1000,bytes=10485760,useANO=0; lastPathIndex=2: NumIOsPending=0,numBytesPending=0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba1:C0:T4:L2, vmhba1:C0:T1:L2, vmhba2:C0:T5:L2, vmhba2:C0:T4:L2
Is USB: false
[root@ESX01C-ESX03:~]
2. İkinci Huawei LUN
esxcli storage nmp device list -d naa.658be72100f678c300053b9400000000
Komut çıktısı:
[root@ESX01C-ESX03:~] esxcli storage nmp device list -d naa.658be72100f678c300053b9400000000
naa.658be72100f678c300053b9400000000
Device Display Name: HUAWEI Fibre Channel Disk (naa.658be72100f678c300053b9400000000)
Storage Array Type: VMW_SATP_DEFAULT_AA
Storage Array Type Device Config: {action_OnRetryErrors=off}
Path Selection Policy: VMW_PSP_RR
Path Selection Policy Device Config: {policy=rr,iops=1000,bytes=10485760,useANO=0; lastPathIndex=3: NumIOsPending=0,numBytesPending=0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba1:C0:T4:L1, vmhba1:C0:T1:L1, vmhba2:C0:T5:L1, vmhba2:C0:T4:L1
Is USB: false
[root@ESX01C-ESX03:~]
Üçüncü ESXi sunucusunda da aynı Multipathing kombinasyonunun kullanıldığı görülmektedir.
Üç ESXi Sunucusunun Karşılaştırılması
| Özellik | ABC-ESX01 | ABC-ESX02 | ESX01C-ESX03 |
|---|---|---|---|
| Huawei LUN sayısı | 2 | 2 | 2 |
| SATP | DEFAULT_AA | DEFAULT_AA | DEFAULT_AA |
| PSP | Round Robin | Round Robin | Round Robin |
| IOPS | 1000 | 1000 | 1000 |
| LUN 1 çalışma yolu | 4 | 4 | 4 |
| LUN 2 çalışma yolu | 4 | 4 | 4 |
| FC HBA sayısı | 2 | 2 | 2 |

Üç host üzerindeki iki LUN için toplam 24 mantıksal path kaydı bulunmaktadır. Ancak bu, 24 ayrı fiziksel kablo veya bağımsız SAN bağlantısı olduğu anlamına gelmez.
Bu noktaya kadar yaptığımız incelemeler, üç ESXi sunucusunda da aynı SATP, PSP ve Round Robin IOPS yapılandırmalarının kullanıldığını doğrulamaktadır.
Huawei Storage için SATP kurallarının tanımlanması
Huawei Storage sistemlerinde SATP kuralı belirlenirken storage tarafındaki erişim modunun dikkate alınması gerekir.
Huawei’nin XSG1 modeli için tanımladığı iki SATP kuralı aşağıdaki gibidir.
1. Load Balancing (ALUA kullanılmıyor)
Huawei DeviceManager üzerinde Host Access Mode Load balancing olarak ayarlanmışsa veya karşılık gelen initiator switchover mode ALUA not used ise aşağıdaki kural kullanılabilir:
esxcli storage nmp satp rule add \
-V HUAWEI \
-M XSG1 \
-s VMW_SATP_DEFAULT_AA \
-P VMW_PSP_RR \
-c tpgs_off
Bu komutun temel amacı, HUAWEI / XSG1 tanımlayıcısına sahip ve TPGS kullanmayan cihazların Active/Active SATP ve Round Robin politikasıyla eşleşmesini sağlamaktır.
2. Asymmetric (ALUA kullanılıyor)
Storage üzerinde Host Access Mode Asymmetric veya ilgili initiator switchover mode Special mode ise aşağıdaki kural kullanılabilir:
esxcli storage nmp satp rule add \
-V HUAWEI \
-M XSG1 \
-s VMW_SATP_ALUA \
-P VMW_PSP_RR \
-c tpgs_on
Bu kural, ALUA kullanan Huawei XSG1 cihazları için VMW_SATP_ALUA ve Round Robin eşleşmesini oluşturur.
Huawei dokümantasyonuna göre, farklı TPGS koşullarına sahip bu iki kural aynı ESXi sunucusunda birlikte bulunabilir.
Komut parametrelerinin açıklaması
| Parametre | Açıklama |
|---|---|
-V HUAWEI | Storage üretici tanımlayıcısı |
-M XSG1 | Storage model tanımlayıcısı |
-s | Kullanılacak SATP |
-P VMW_PSP_RR | Varsayılan Round Robin PSP |
-c tpgs_off | TPGS kullanılmayan cihaz koşulu |
-c tpgs_on | TPGS kullanılan cihaz koşulu |
Komut sözdizimi ve seçeneklerin ayrıntıları Broadcom’un ESXCLI referansında da yer almaktadır.
Önemli: Bunlar yapılandırma değiştiren komutlardır. Mevcut kurallar kontrol edilmeden tekrar uygulanmamalıdır.
ABC-ESX01 üzerinde SATP kurallarının eklenmesi
Paylaşılan gerçek terminal kaydında ABC-ESX01 üzerinde iki SATP kuralının eklendiği görülmektedir.
İlk olarak Active/Active kuralı çalıştırılmıştır:
[root@ABC-ESX01:~] esxcli storage nmp satp rule add \
> -V HUAWEI \
> -M XSG1 \
> -s VMW_SATP_DEFAULT_AA \
> -P VMW_PSP_RR \
> -c tpgs_off
[root@ABC-ESX01:~]
Ardından ALUA kuralı eklenmiştir:
[root@ABC-ESX01:~] esxcli storage nmp satp rule add \
> -V HUAWEI \
> -M XSG1 \
> -s VMW_SATP_ALUA \
> -P VMW_PSP_RR \
> -c tpgs_on
[root@ABC-ESX01:~]
İki işlem sonrasında da terminal normal komut istemine dönmüştür. Ardından kural tablosu sorgulanmış ve kullanıcı tanımlı eşleşmelerin listelendiği doğrulanmıştır.
Pasted text.txt
SATP kurallarının doğrulanması
esxcli storage nmp satp rule list | grep -i HUAWEI
Gerçek çıktı, okunabilirlik için sütunlar hizalanarak aşağıda verilmiştir:
[root@ABC-ESX01:~] esxcli storage nmp satp rule list | grep -i HUAWEI
VMW_SATP_ALUA HUAWEI XSG1 system tpgs_on VMW_PSP_RR
VMW_SATP_ALUA Huawei VBS fileIO system tpgs_on VMW_PSP_RR
VMW_SATP_ALUA HUAWEI XSG1 user tpgs_on VMW_PSP_RR
VMW_SATP_DEFAULT_AA HUAWEI XSG1 system tpgs_off VMW_PSP_RR
VMW_SATP_DEFAULT_AA Huawei VBS fileIO system tpgs_off VMW_PSP_RR
VMW_SATP_DEFAULT_AA HUAWEI XSG1 user tpgs_off VMW_PSP_RR
[root@ABC-ESX01:~]
Çıktıda Huawei XSG1 için hem system hem de user kurallarının bulunduğu görülmektedir.
System ve User kuralları arasındaki fark
System kuralları, VMware ESXi tarafından sağlanan yerleşik kurallardır. Belirli üretici ve model eşleşmeleri için varsayılan SATP davranışını tanımlarlar.
User kuralları, yönetici veya otomasyon tarafından sonradan eklenmiş kurallardır.
Broadcom dokümantasyonunda kullanıcı kurallarının sistem kurallarına göre öncelik alabileceği, ayrıca sistem kurallarının normal yöntemlerle kaldırılamayacağı belirtilmektedir. Support Portal
Mevcut kayıtlarda Huawei XSG1 için iki sistem kuralı ve bunlarla aynı görünen SATP/PSP ve TPGS eşleşmelerine sahip iki kullanıcı kuralı bulunmaktadır.
Bu durum, eklenen kullanıcı kurallarının mevcut cihazlar için zorunlu olmadığına işaret etmektedir.
Ancak kullanıcı kurallarını kaldırmadan önce tam parametrelerinin ve oluşturulma amaçlarının incelenmesi gerekir.
Huawei / VBS fileIO kayıtları ise farklı bir model eşleşmesine aittir. Bunların XSG1 cihazlarından bağımsız değerlendirilmesi gerekir.
SATP kurallarının mevcut LUN’lara etkisi
Yeni SATP kuralı eklendiğinde mevcut LUN’un hemen farklı bir SATP kullanmaya başlaması beklenmemelidir.
Huawei’nin VMware bağlantı kılavuzuna göre yeni eşleşmeler, yeni tanıtılan LUN’ların ilk claim işleminde uygulanabilir. Önceden tanıtılmış LUN’larda ise kuralların uygulanabilmesi için hostun yeniden başlatılması gerekebilir. johnny-unitaz.info
Benzer şekilde Broadcom da Round Robin ve SATP kural değişikliklerinin mevcut cihazlara uygulanması için yeniden başlatma gerektirebilen senaryoları açıklamaktadır. Support Portal
Paylaşılan terminal kayıtlarında SATP kullanıcı kurallarının eklendiği ve listelendiği görülmektedir. Bununla birlikte bu işlemler sonrasında hostun yeniden başlatıldığına ilişkin bir kayıt bulunmamaktadır.
Dolayısıyla mevcut LUN’ların yeni bir claim işleminden geçtiği söylenemez.
Buna rağmen üç hostta da VMW_SATP_DEFAULT_AA ve VMW_PSP_RR aktif olarak görülmektedir. Bu nedenle mevcut cihazların Round Robin kullanması için ilave bir işlem gerektiğine dair bir bulgu yoktur.
Round Robin IOPS değerinin değerlendirilmesi
İncelenen altı host-LUN eşleşmesinin tamamında şu yapılandırma bulunmaktadır:
Path Selection Policy: VMW_PSP_RR
Path Selection Policy Device Config:
{policy=rr,iops=1000,bytes=10485760,useANO=0; ...}
Burada policy=rr, Round Robin politikasının etkin olduğunu gösterir.
iops=1000 değeri, I/O sayısına dayalı yol değiştirme eşiğidir. bytes=10485760 ise byte tabanlı yol değiştirme ayarı için görünen eşik değeridir. Hangi değerin aktif yol değiştirme davranışını belirlediği ilgili PSP yapılandırmasına bağlıdır.
useANO=0, Active Non-Optimized yolların kullanımına ilişkin parametredir.
lastPathIndex ise belirli bir anda kullanılan yol indeksine ilişkin bilgidir. Hostlar arasında farklı görünmesi tek başına bir tutarsızlık ya da hata anlamına gelmez.
IOPS=1 yapılmalı mı?
Bazı Huawei OceanStor kılavuzlarında Round Robin için IOPS değerinin 1 olarak yapılandırılması önerilmektedir. PDF
Ancak bu değer her model, firmware sürümü ve iş yükü için otomatik olarak uygulanmamalıdır.
Kullanılan Huawei storage modelinin üretici kılavuzu bu ayarı destekliyorsa cihaz bazında aşağıdaki komut kullanılabilir:
esxcli storage nmp psp roundrobin deviceconfig set \
--device naa.658be72100f678c3000fc01600000001 \
--type iops \
--iops 1
Ardından kontrol:
esxcli storage nmp device list -d naa.658be72100f678c3000fc01600000001
Bu işlem PSP ayarını değiştirdiğinden, üretim ortamında ancak üretici önerisi ve performans değerlendirmesi sonrasında gerçekleştirilmelidir.
Mevcut ortamda iops=1000 değerinin yanlış olduğunu veya değiştirilmesi gerektiğini gösteren bir ölçüm bulunmamaktadır.
Fibre Channel bağlantı yollarının kontrol edilmesi
SATP ve PSP politikalarının doğru görünmesi, fiziksel bağlantıların tamamının sağlıklı çalıştığını tek başına kanıtlamaz.
Bu nedenle her LUN için gerçek path durumları ayrıca incelenmelidir.
Birinci LUN:
esxcli storage core path list -d naa.658be72100f678c3000fc01600000001
İkinci LUN:
esxcli storage core path list -d naa.658be72100f678c300053b9400000000
Bu komutlarda özellikle yolun State bilgisine, HBA adaptörüne, target bağlantısına ve LUN numarasına bakılmalıdır.
Fibre Channel HBA bilgileri için:
esxcli storage san fc list
Yol istatistikleri için:
esxcli storage core path stats get
Bu sorgular, storage bağlantılarındaki olası hataların ve yol durumlarının değerlendirilmesine yardımcı olabilir.
Ayrıca Huawei DeviceManager üzerinden ilgili hostun initiator eşleşmeleri, controller portları, host mapping yapılandırması ve Host Access Mode ayarları kontrol edilmelidir.
SATP ve PSP ayarları doğrudan depolama erişimini etkileyebilir. Bu nedenle çalışan bir sanallaştırma ortamında gerekli doğrulamalar tamamlanmadan değişiklik yapılmamalıdır.
Özellikle üç hostun ortak storage üzerinde çalıştığı ortamlarda, hatalı bir yapılandırma birden fazla sanal makineyi etkileyebilir.
Önerilen yaklaşım, önce mevcut yapılandırmanın kaydedilmesi ve bütün hostlarda aynı kontrollerin tamamlanmasıdır. Ardından Huawei Storage erişim modu ile VMware SATP eşleşmesi karşılaştırılmalıdır.
Değişiklik gerekli görülürse bakım penceresi planlanmalı, mümkünse ilgili host üzerindeki sanal makineler diğer hostlara taşınmalı ve ESXi Maintenance Mode kullanılmalıdır.
Yeni SATP kuralı uygulanması için yeniden başlatma gerekirse işlem hostlar üzerinde kontrollü ve sırayla gerçekleştirilmelidir.
Değişiklik sonrası LUN erişimleri, datastore durumları, path sayıları ve PSP ayarları yeniden doğrulanmalıdır.

