Alarm Vermeyen Arıza: ESXi'de Fibre Channel Yol Yedekliliğini Sessizce Kaybetmek

Veri merkezindeki en tehlikeli arızalar, alarm üretmeyen arızalardır. Sunucu ayakta, sanal makineler çalışıyor, datastore’lar bağlı, kullanıcı hiçbir şey hissetmiyor — ama sistemin yedekliliği çoktan yok olmuş durumda. Yapı artık tek bir kablonun, tek bir SFP’nin ya da tek bir switch’in omzunda duruyor ve bunu kimse fark etmiyor.

Bu yazıda tam olarak böyle bir vakayı ele alacağız: iki adet Fibre Channel HBA’sı bulunmasına rağmen SAN depolamaya yalnızca tek fabric üzerinden erişen bir ESXi hostu. Sorunun nasıl fark edildiğini, ESXi ve SAN switch tarafında hangi komutlarla teşhis edildiğini, kök nedenin neden iki ayrı problemin üst üste binmesi olduğunu ve yedekliliğin nasıl geri kazanıldığını adım adım göreceğiz.

Aşağıdaki tüm host adları, WWN değerleri, port numaraları ve çıktılar kurgusal bir laboratuvar ortamına aittir. Komutlar gerçektir; değerler örnektir. Kendi ortamınızda uygularken kendi topolojinizin karşılıklarını kullanın.

FC dünyası kendi terminolojisiyle gelir. Tanımadığınız bir kısaltmaya rastlarsanız yazının sonundaki terimler sözlüğüne bakabilirsiniz.

Neden SAN Var? Diskleri Sunucunun İçinden Neden Çıkardık?

Sorunu anlamak için önce bu mimarinin neden böyle kurulduğunu bilmek gerekiyor. Çünkü bir sunucunun diski neden kendi kasasında değil de metrelerce ötedeki bir dolapta duruyor sorusunun cevabı, aynı zamanda “neden iki ayrı fabric çekiyoruz” sorusunun da cevabıdır.

Eski dünya: DAS (Direct Attached Storage)

Klasik yaklaşımda diskler sunucunun içindedir. Basittir, ucuzdur ve tek bir sunucu için yeterlidir. Ama sanallaştırılmış bir veri merkezinde şu duvarlara çarpar:

• Disk, sunucuya hapsolur. Sunucu 1’in boştaki 4 TB’ını Sunucu 2 kullanamaz. Her sunucu kendi kapasite adasıdır ve toplamda ciddi bir israf oluşur.
• Sanal makine taşınamaz. Bir VM’in diski o sunucunun içindeyse, VM’i çalışır durumda başka bir sunucuya taşımak (vMotion) mümkün değildir.
• Sunucu ölürse hizmet de ölür. Fiziksel sunucu arızalandığında, diskleri de onunla birlikte erişilemez hale gelir. Başka bir host, o VM’leri açamaz — çünkü disklere ulaşamaz.
• Bakım kesinti demektir. Donanım bakımı için sunucuyu kapatmak, üzerindeki tüm VM’leri kapatmak anlamına gelir.

Yeni dünya: SAN (Storage Area Network)

SAN, diskleri sunucudan söküp merkezî bir depolama ünitesine (storage array) koyar ve tüm sunucuları bu havuza kendi özel ağı üzerinden bağlar. Sonuç:

flowchart TB
    subgraph DASX["DAS — Her sunucu kendi adası"]
        direction LR
        S1["Sunucu 1<br/>+ yerel disk"]
        S2["Sunucu 2<br/>+ yerel disk"]
        S3["Sunucu 3<br/>+ yerel disk"]
    end
    subgraph SANX["SAN — Ortak disk havuzu"]
        direction LR
        T1["Sunucu 1"] --> SW["FC Fabric"]
        T2["Sunucu 2"] --> SW
        T3["Sunucu 3"] --> SW
        SW --> ST["Storage Array<br/>LUN havuzu"]
    end
    DASX -->|"diskleri ortak havuza taşı"| SANX
    classDef bad fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
    classDef good fill:#dcfce7,stroke:#16a34a,color:#14532d
    classDef hub fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
    class S1,S2,S3 bad
    class T1,T2,T3 good
    class SW,ST hub

Diskler ortak havuza taşındığı anda kilitlenmiş olan tüm yetenekler açılır:

• vMotion: VM’in diski zaten ortak depolamada olduğu için, çalışan bir VM’i bir hosttan diğerine kesintisiz taşımak mümkün hale gelir. Taşınan tek şey RAM içeriğidir.
• vSphere HA: Bir host çökerse, aynı LUN’lara erişebilen başka bir host o VM’leri kendi üzerinde otomatik olarak yeniden başlatır — çünkü diskler hâlâ ortak havuzda erişilebilir durumdadır.
• DRS: Küme, yük dengesi için VM’leri hostlar arasında otomatik gezdirebilir.
• Kapasite verimliliği: Boş alan tek bir havuzdadır; ihtiyacı olan hangi sunucuysa oradan kullanır.
• Merkezî snapshot, replikasyon ve yedekleme: Bu işler artık 30 sunucuda ayrı ayrı değil, tek bir üniteden yapılır.

Yani SAN, sanallaştırmanın kurumsal yeteneklerini mümkün kılan altyapıdır. Sanallaştırmanın sunduğu esnekliğin bedeli şudur: sunucu artık diskini kaybettiğinde çalışamaz hale gelir. Disk, ağın öbür ucundadır — ve o ağ artık kritik bir bileşendir.

İşte bu yüzden SAN ağı, kurumsal ortamda asla tek hat üzerine kurulmaz. Bir sunucunun ağ kablosu koparsa uygulama erişilemez olur; ama SAN kablosu koparsa sunucunun diski kaybolur. Bu ikisi aynı ağırlıkta olaylar değildir.

Neden Ethernet değil de Fibre Channel?

SAN kurmanın birden fazla yolu vardır. Fibre Channel, bu işi Ethernet’ten tamamen ayrı, kendine ait switch’leri ve adresleme mantığı olan özel bir ağ üzerinden yapar:

Fibre Channel’ın kurumsal ortamda hâlâ tercih edilmesinin sebebi öngörülebilirliktir. Trafiği aynı Ethernet ağını paylaşan yedekleme veya kullanıcı trafiğiyle yarışmaz; FC protokolü kayıpsız (lossless) çalışacak şekilde tasarlanmıştır ve gecikme dalgalanması (jitter) çok düşüktür. Veritabanı ve sanallaştırma yükleri bu kararlılığa duyarlıdır.

Bedeli ise ayrı bir dünya öğrenmektir: ayrı switch’ler, ayrı kablolar, ayrı adresleme ve — bu yazının konusu olan — ayrı bir hata alanı.

Çift Fabric Mimarisi: A ve B Neden Ayrıdır?

Artık asıl tasarım kuralına gelebiliriz. Kurumsal FC mimarisinin altın kuralı, birbirinden tamamen bağımsız iki fabric kurmaktır: Fabric A ve Fabric B. Sunucunun bir HBA’sı A’ya, diğeri B’ye bağlanır; depolamanın kontrolcüleri de aynı şekilde ikiye bölünür.

Bu ayrımın sebebi yalnızca “kablo kopabilir” değildir — asıl sebep daha inceliklidir. İki fabric arasında hiçbir bağlantı yoktur; ISL yoktur, ortak zoneset yoktur, ortak yönetim düzlemi yoktur. Dolayısıyla:

• A’da yapılan hatalı bir zoneset activate B’yi etkilemez.
• A’daki bir firmware yükseltmesi sırasında tüm I/O B üzerinden akmaya devam eder.
• A’da bir fabric-wide kararsızlık (RSCN fırtınası, name server bozulması) yaşansa bile B temiz kalır.

Yani çift fabric yalnızca donanım değil, operasyonel hata ve bakım yedekliliğidir. Ethernet dünyasında iki switch’i birbirine bağlarız; FC dünyasında ise bilerek bağlamayız.

Kablo Bağlantı Şeması (A ve B Hattı)

Doğru kurulmuş bir hostun kablolaması şöyledir. Kırmızı hat A tarafını, mavi hat B tarafını temsil eder ve ikisinin hiçbir noktada kesişmediğine dikkat edin:

flowchart LR
    subgraph HOST["ESXi Host · VMHOST09"]
        direction TB
        HBA1["HBA 1 · vmhba1<br/>WWPN ...7d:2a:14"]
        HBA2["HBA 2 · vmhba2<br/>WWPN ...b6:91:c3"]
    end
    FA["FABRIC A<br/>MDS-A"]
    FB["FABRIC B<br/>MDS-B"]
    subgraph ARRAY["Storage Array"]
        direction TB
        C0["Controller 0"]
        C1["Controller 1"]
    end
    HBA1 -->|"A1 · fc1/11"| FA
    FA -->|"A2 · fc1/43"| C0
    FA -->|"A3 · fc1/44"| C1
    HBA2 -->|"B1 · fc1/11"| FB
    FB -->|"B2 · fc1/43"| C0
    FB -->|"B3 · fc1/44"| C1
    linkStyle 0,1,2 stroke:#dc2626,stroke-width:2.5px
    linkStyle 3,4,5 stroke:#2563eb,stroke-width:2.5px
    classDef host fill:#f1f5f9,stroke:#64748b,color:#0f172a
    classDef fabA fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
    classDef fabB fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
    classDef arr fill:#fef3c7,stroke:#d97706,color:#78350f
    class HBA1,HBA2 host
    class FA fabA
    class FB fabB
    class C0,C1 arr

Diyagramdaki her ok fiziksel bir fiber kablodur. Toplam altı kablo vardır ve her birinin iki ucu da kayıt altında olmalıdır:

Kablolamanın altın kuralı: Aynı sunucunun iki HBA’sı asla aynı switch’e takılmaz; aynı kontrolcünün iki portu da öyle. Bir bileşenin her iki kopyası aynı fabric’e düşüyorsa, o bileşen için yedeklilik kâğıt üzerinde vardır ama gerçekte yoktur. Array’in fc1/45–fc1/46‘ya bağlı ek portları da aynı fabric’tedir; bu hostun zone’unda yer almadıkları için şemada gösterilmemiştir.

Bu Kablolama Kaç Yol Üretir?

Host, LUN’a bir fabric üzerinden ulaşırken o fabric’te görebildiği her target portu için ayrı bir yol oluşturur. Buradaki tasarımda:

vmhba1 (Fabric A) → Controller 0  =  1 yol
vmhba1 (Fabric A) → Controller 1  =  1 yol
vmhba2 (Fabric B) → Controller 0  =  1 yol
vmhba2 (Fabric B) → Controller 1  =  1 yol
                            TOPLAM =  4 yol

Bu dört yol, ESXi’de vmhba1:C0:T0:L12 biçiminde adlandırılır ve Round Robin politikası sayesinde I/O hepsine dağıtılır. Bu tasarımın gerçek değerini ise arıza tablosu gösterir:

Tablonun anlattığı şey şudur: dört yolun varlığı değil, bu yolların iki bağımsız hata alanına dağılmış olması yedekliliği oluşturur. Şimdi göreceğimiz vakada tam olarak bu dağılım bozulmuştu — dört yol yerine iki yol vardı ve ikisi de aynı fabric’ten geçiyordu.

Vaka: “Her Şey Çalışıyor” Diyen Bir Host

Rutin bir envanter kontrolünde VMHOST09 adlı ESXi hostunun depolama yollarında bir tuhaflık göze çarptı. Host sorunsuz çalışıyordu; üzerindeki sanal makineler ayaktaydı, datastore’lar erişilebilir durumdaydı, vCenter’da hiçbir alarm yoktu.

Ancak sunucunun içinde iki adet tek portlu FC HBA takılıydı ve kart bilgileri şöyleydi:

Kâğıt üzerinde tasarım doğruydu. Gerçekte ise host, depolamaya yalnızca vmhba2 üzerinden, yani sadece Fabric B’den erişiyordu. Yani gerçek tablo, az önceki kablo şemasının A tarafı kopmuş haliydi:

flowchart LR
    subgraph HOST["ESXi Host · VMHOST09"]
        direction TB
        HBA1["HBA 1 · vmhba1<br/>link-down"]
        HBA2["HBA 2 · vmhba2<br/>link-up"]
    end
    FA["FABRIC A<br/>MDS-A · fc1/11"]
    FB["FABRIC B<br/>MDS-B · fc1/11"]
    subgraph ARRAY["Storage Array"]
        direction TB
        C0["Controller 0"]
        C1["Controller 1"]
    end
    HBA1 -. "A1 · link yok" .-> FA
    FA -. "A2 · bu host zone'lu değil" .-> C0
    FA -. "A3 · bu host zone'lu değil" .-> C1
    HBA2 -->|"B1 · aktif"| FB
    FB -->|"B2 · aktif"| C0
    FB -->|"B3 · aktif"| C1
    linkStyle 0,1,2 stroke:#94a3b8,stroke-width:1.5px
    linkStyle 3,4,5 stroke:#2563eb,stroke-width:2.5px
    classDef host fill:#f1f5f9,stroke:#64748b,color:#0f172a
    classDef dead fill:#e2e8f0,stroke:#94a3b8,color:#475569
    classDef fabB fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
    classDef arr fill:#fef3c7,stroke:#d97706,color:#78350f
    class HBA2 host
    class HBA1,FA dead
    class FB fabB
    class C0,C1 arr

A hattı bu host için baştan sona işlevsizdi. A1 hattında link hiç kurulamıyordu; A2 ve A3 hatları ise fiziksel olarak sağlamdı — diğer sunucular onları sorunsuz kullanıyordu — ama vmhba1 için bir zone tanımı olmadığından bu hostun kullanımına kapalıydı. Yani sorun tek bir noktada değil, A hattının iki farklı katmanındaydı.

Sistem yine de çalışmaya devam ediyordu, çünkü B hattı tüm yükü tek başına taşıyabiliyordu. Ancak arıza tablosundaki “Fabric B tamamen giderse” satırının karşılığı artık 0 yol ve APD idi.

1. Adım: ESXi Tarafında Teşhis

Sorun giderirken her zaman sunucudan başlamak mantıklıdır; çünkü hostun kendi gördüğü tablo, sorunun hangi katmanda olduğunu daha en baştan daraltır. ESXi’ye SSH ile bağlanıp adaptörleri listeledik:

[root@vmhost09:~] esxcli storage core adapter list

HBA Name  Driver      Link State  UID                                     Description
--------  ----------  ----------  --------------------------------------  -----------------------------------------
vmhba0    lsi_msgpt3  link-n/a    sas.51402ec01a9f3c00                    (0000:18:00.0) Broadcom SAS3408
vmhba1    qlnativefc  link-down   fc.20000024ff7d2a14:21000024ff7d2a14    (0000:5e:00.0) QLogic 16Gb FC Adapter
vmhba2    qlnativefc  link-up     fc.20000024ffb691c3:21000024ffb691c3    (0000:af:00.0) QLogic 16Gb FC Adapter

İlk bulgu burada: vmhba1 için link-down. Kart tanınıyor, sürücü yüklü, WWN’ler okunuyor — ama fiziksel bağlantı yok. Detaya inelim:

[root@vmhost09:~] esxcli storage san fc list

   Adapter: vmhba1
   Port ID: 000000
   Node Name: 20:00:00:24:ff:7d:2a:14
   Port Name: 21:00:00:24:ff:7d:2a:14
   Speed: 0 Gbps
   Port Type: Unknown
   Port State: LINK DOWN
   Model Description: QLogic 16Gb FC Adapter

   Adapter: vmhba2
   Port ID: 9e0140
   Node Name: 20:00:00:24:ff:b6:91:c3
   Port Name: 21:00:00:24:ff:b6:91:c3
   Speed: 16 Gbps
   Port Type: NPort
   Port State: ONLINE
   Model Description: QLogic 16Gb FC Adapter

Fark net: vmhba2 fabric’e giriş yapmış ve kendisine bir FCID (Port ID: 9e0140) atanmış. vmhba1 ise Port ID: 000000 ile duruyor — yani fabric login (FLOGI) hiç gerçekleşmemiş.

FCID’nin ilk baytı, cihazın bağlı olduğu switch’in domain ID‘sidir. Buradaki 9e, Fabric B’nin domain’i; Fabric A’da aynı hostun ileride alacağı FCID 7c ile başlayacak. İki fabric birbirinden bağımsız olduğu için domain ID’lerini bilinçli olarak farklı seçmek, hangi çıktının hangi fabric’e ait olduğunu bir bakışta anlamanızı sağlar.

Peki bu, LUN’lara kaç yol kaldığı anlamına geliyor? Bir datastore LUN’unu inceleyelim:

[root@vmhost09:~] esxcli storage core path list -d naa.600a09803830443859244e5a41763721 | grep -i "runtime name"

   Runtime Name: vmhba2:C0:T0:L12
   Runtime Name: vmhba2:C0:T1:L12

[root@vmhost09:~] esxcli storage nmp device list -d naa.600a09803830443859244e5a41763721

naa.600a09803830443859244e5a41763721
   Storage Array Type: VMW_SATP_ALUA
   Path Selection Policy: VMW_PSP_RR
   Working Paths: vmhba2:C0:T0:L12, vmhba2:C0:T1:L12

İşte sorunun özeti: olması gereken dört yol yerine yalnızca iki yol var ve her ikisi de aynı adaptör üzerinden geçiyor. Yol sayısı ikiye bölündüğü için tablo “çok yollu” görünüyor, ama gerçekte tek bir HBA, tek bir kablo ve tek bir switch tüm erişimi taşıyor.

Bu noktada, sorunun ne zaman başladığını anlamak için host loglarına da bakmakta fayda var:

[root@vmhost09:~] grep -i "vmhba1" /var/log/vmkernel.log | tail -5

Bizim vakamızda log, portun hiçbir zaman ayağa kalkmadığını gösteriyordu — yani bu bir “sonradan bozulma” değil, kurulumdan beri var olan bir eksiklikti. Bu ayrım önemlidir: sonradan bozulan bir yol donanım arızasını, hiç kalkmamış bir yol ise devreye alma (commissioning) hatasını işaret eder.

2. Adım: SAN Switch Tarafında Teşhis

Host tarafı “link kuramıyorum” diyorsa, sıradaki durak switch’tir. Bu ortamda Fabric A iki Cisco MDS switch’inden oluşuyor (MDS-A ve MDS-A2, aralarında bir ISL var); VMHOST09 bunlardan MDS-A‘ya bağlı. Ona bağlanıp önce portların genel durumuna baktık:

2.1. Fiziksel Katman: Port Durumu ve Optik Seviyeler

MDS-A# show interface brief

-------------------------------------------------------------------------------
Interface  Vsan   Admin  Admin   Status         SFP   Oper  Oper    Port
                  Mode   Trunk                        Mode  Speed   Channel
                         Mode                               (Gbps)
-------------------------------------------------------------------------------
fc1/9      10     auto   on      up             swl   F     16       --
fc1/10     10     auto   on      up             swl   F     16       --
fc1/11     10     auto   on      linkFailure    swl   --    --       --
fc1/12     10     auto   on      up             swl   F     16       --

fc1/11 portu linkFailure durumunda. SFP takılı (swl = short wave laser), port yönetimsel olarak kapalı değil, ama link kurulmuyor. Detaya inelim:

MDS-A# show interface fc1/11

fc1/11 is down (Link failure or not-connected)
    Hardware is Fibre Channel, SFP is short wave laser w/o OFC (SN)
    Port WWN is 20:0b:00:2d:ec:5a:8f:c0
    Admin port mode is auto, trunk mode is on
    Port vsan is 10
    Receive data field Size is 2112
    Beacon is turned off
    5 minutes input rate 0 bits/sec, 0 bytes/sec, 0 frames/sec
    5 minutes output rate 0 bits/sec, 0 bytes/sec, 0 frames/sec
      0 frames input, 0 bytes
      0 frames output, 0 bytes
      14 link failures, 0 sync losses, 0 signal losses

Buradaki kombinasyon dikkat çekici: signal losses sayacı sıfır — yani switch karşı uçtan ışık alıyor — ama 0 frames input ve sürekli artan link failures, linkin bir türlü kurulamadığını gösteriyor. Kablo kopuk ya da çıkmış olsaydı sinyal kaybı sayacı artardı. Öyleyse sorun kabloda değil, ışığın yönlerinden birinde. Hangisinde olduğunu söyleyebilmek için optik seviyeleri okumak gerekir — SFP arızalarını kesin olarak burada yakalarsınız:

MDS-A# show interface fc1/11 transceiver detail

fc1/11 sfp is present
    Name is CISCO-AVAGO
    Cisco pid is DS-SFP-FC16G-SW
    FC Transmitter type is short wave laser w/o OFC (SN)

           SFP Detail Diagnostics Information
--------------------------------------------------------------------
                          Değer        Alarm(Low)     Warning(Low)
--------------------------------------------------------------------
  Temperature            38.94 C        -5.00 C          0.00 C
  Voltage                 3.28 V         2.97 V          3.13 V
  Tx Power              -21.80 dBm      -9.50 dBm       -8.20 dBm
  Rx Power               -3.18 dBm     -14.40 dBm      -13.40 dBm

Tablo teşhisi tek başına tamamlıyor. Rx Power normal: switch, sunucunun HBA’sından gelen ışığı sorunsuz alıyor — demek ki fiber kablo da, host tarafındaki optik de sağlam. Buna karşılık Tx Power, yani switch’in kendi gönderdiği ışık gücü, alarm eşiğinin 12 dB altında.

Bir SFP modülünde verici (lazer) ve alıcı birbirinden bağımsız iki bileşendir ve ayrı ayrı bozulabilirler. Burada olan tam olarak budur: modülün lazeri yaşlanıp sönmüş, alıcısı çalışmaya devam ediyor. Sonuç olarak switch sunucuyu “duyuyor” ama sunucu switch’i duymuyor; FC linki çift yönlü ışık olmadan kurulamayacağı için ESXi tarafındaki HBA link-down olarak bekliyor. Tek bir arıza, iki uçta iki farklı belirti üretiyor — bu yüzden yalnızca hostun raporuna bakarak karar vermek yanıltıcıdır.

Aynı switch’te sağlıklı bir portta Tx Power ve Rx Power tipik olarak -2 ile -5 dBm aralığındadır. Tx tarafındaki ~19 dB’lik sapma, tahminle değil ölçümle konuşmamızı sağlıyor.

Teşhis disiplini: Bir FC portu ayağa kalkmıyorsa sıralama şudur — önce optik seviye (transceiver detail), sonra fabric login (show flogi database), en son zoning (show zoneset active). Bu sırayı atlayıp doğrudan zoning’e bakmak, sorunu bulmayı ciddi biçimde geciktirir.

Fabric login tablosuna baktığımızda, beklendiği gibi hostun izi bile yoktu:

MDS-A# show flogi database

--------------------------------------------------------------------------------
INTERFACE   VSAN    FCID           PORT NAME               NODE NAME
--------------------------------------------------------------------------------
fc1/9       10    0x7c0100  21:00:00:24:ff:41:0d:9a 20:00:00:24:ff:41:0d:9a
fc1/10      10    0x7c0120  21:00:00:24:ff:52:e8:37 20:00:00:24:ff:52:e8:37
fc1/12      10    0x7c0160  21:00:00:24:ff:6a:b1:d5 20:00:00:24:ff:6a:b1:d5
fc1/43      10    0x7c01e0  50:0a:09:83:8d:4f:2c:71 50:0a:09:80:8d:4f:2c:71
fc1/44      10    0x7c0200  50:0a:09:84:8d:4f:2c:71 50:0a:09:80:8d:4f:2c:71

Total number of flogi = 5.

2.2. İkinci Problem: Eksik Zoning

Arızalı SFP tek başına bir açıklamaydı, ama işi orada bırakmadık. Çünkü link geldiğinde iş bitmiş olmayacaktı: hostun WWPN’i fabric tarafında tanımlı değilse, port ayağa kalksa bile depolama görünmeyecekti.

Önce port etiketlerine bakarak envanterin tutarlılığını kontrol ettik:

MDS-A# show interface description

-------------------------------------------------------------------------------
Interface                Description
-------------------------------------------------------------------------------
fc1/1                    VMHOST01_HBA1_P1
fc1/2                    VMHOST02_HBA1_P1
fc1/3                    VMHOST03_HBA1_P1
fc1/4                    VMHOST04_HBA1_P1
fc1/5                    VMHOST05_HBA1_P1
fc1/6                    VMHOST06_HBA1_P1
fc1/7                    VMHOST07_HBA1_P1
fc1/8                    VMHOST08_HBA1_P1
fc1/9                    VMHOST10_HBA1_P1
fc1/10                   VMHOST11_HBA1_P1
fc1/11                   --
fc1/12                   VMHOST12_HBA1_P1
fc1/13                   VMHOST13_HBA1_P1
fc1/14                   --
fc1/15                   BACKUP_MEDIA1_HBA1
fc1/16                   BACKUP_MEDIA2_HBA1
fc1/17                   DBCLU_N1_HBA1_P1
fc1/18                   DBCLU_N2_HBA1_P1
fc1/19                   --
fc1/20                   TAPELIB_DRV1
fc1/43                   ARRAY_CTRL0_P1
fc1/44                   ARRAY_CTRL1_P1
fc1/45                   ARRAY_CTRL0_P3
fc1/46                   ARRAY_CTRL1_P3
fc1/47                   --
fc1/48                   ISL_TO_MDS_A2
-------------------------------------------------------------------------------

fc1/11 portunun açıklaması bile boştu. Bu küçük ayrıntı, aslında hikâyenin tamamını anlatıyor: kablo fiziksel olarak takılmıştı, ancak port hiçbir zaman düzgün biçimde devreye alınmamıştı. Etiketleme yapılmadığı gibi, muhtemelen zoning de yapılmamıştı. Doğrulayalım:

MDS-A# show device-alias database | include 7d:2a:14
MDS-A#

MDS-A# show zoneset active vsan 10 | include 7d:2a:14
MDS-A#

Her iki komut da boş döndü. Yani hostun Fabric A tarafındaki 21:00:00:24:ff:7d:2a:14 WWPN’i için ne bir device-alias, ne de bir zone tanımı vardı.

Bir tarafta devreye alma eksiği bulduğunuzda, diğer tarafı da mutlaka aynı gözle kontrol edin — aynı gün, aynı kişi tarafından yapılan bir kurulumun her iki fabric’te de benzer bir boşluk bırakması hiç şaşırtıcı olmaz. Aynı sorguları MDS-B üzerinde vmhba2‘nin WWPN’i için de çalıştırdık; B tarafında hem device-alias hem zone eksiksizdi ve array’in her iki kontrolcü portu da zone içindeydi. Şu an yükü taşıyan tek hat gerçekten sağlamdı — bu, onarımı rahat yapabileceğimiz anlamına da geliyordu.

Kök neden böylece netleşti — bu tek bir arıza değil, üst üste binmiş iki eksiklikti:

1. fc1/11 portundaki SFP modülü arızalıydı (Tx gücü alarm eşiğinin altında).
2. vmhba1‘in WWPN’i için Fabric A’da device-alias ve zone tanımı hiç yapılmamıştı.

Sadece birini düzeltmek yeterli olmazdı: SFP’yi değiştirseniz link gelir ama LUN görünmez; zoning’i yapsanız fabric login olmadığı için zone hiçbir işe yaramaz.

3. Adım: Çözüm

3.1. Arızalı SFP’nin Değiştirilmesi

Portu değişim öncesinde yönetimsel olarak kapatmak, gereksiz link flap’lerinin ve log gürültüsünün önüne geçer:

MDS-A# configure terminal
MDS-A(config)# interface fc1/11
MDS-A(config-if)# shutdown

Modül fiziksel olarak değiştirildikten sonra port etiketlendi ve tekrar açıldı:

MDS-A(config-if)# description VMHOST09_HBA1_P1
MDS-A(config-if)# no shutdown
MDS-A(config-if)# end

Yeni SFP ile optik seviyeleri hemen kontrol ettik:

MDS-A# show interface fc1/11 transceiver detail | include "Power"

  Tx Power               -2.91 dBm
  Rx Power               -3.44 dBm

Değerler artık normal aralıkta. Portun durumu da beklendiği gibi:

MDS-A# show interface fc1/11 brief

-------------------------------------------------------------------------------
Interface  Vsan   Admin  Admin   Status   SFP   Oper  Oper    Port
                  Mode   Trunk                 Mode  Speed   Channel
-------------------------------------------------------------------------------
fc1/11     10     auto   on      up       swl   F     16       --

Ve en önemlisi, host artık fabric’e giriş yapabiliyor:

MDS-A# show flogi database interface fc1/11

--------------------------------------------------------------------------------
INTERFACE   VSAN    FCID           PORT NAME               NODE NAME
--------------------------------------------------------------------------------
fc1/11      10    0x7c0140  21:00:00:24:ff:7d:2a:14 20:00:00:24:ff:7d:2a:14

FLOGI gerçekleşti; WWPN artık fabric’in ad sunucusunda (name server) kayıtlı:

MDS-A# show fcns database vsan 10

VSAN 10:
--------------------------------------------------------------------------
FCID        TYPE  PWWN                    (VENDOR)     FC4-TYPE:FEATURE
--------------------------------------------------------------------------
0x7c0140    N     21:00:00:24:ff:7d:2a:14 (Qlogic)     scsi-fcp:init
0x7c01e0    N     50:0a:09:83:8d:4f:2c:71 (NetApp)     scsi-fcp:target
0x7c0200    N     50:0a:09:84:8d:4f:2c:71 (NetApp)     scsi-fcp:target

Host init (initiator), depolama portları target olarak görünüyor. Fiziksel katman tamam.

3.2. Device-Alias Tanımı

Zone’ları çıplak WWPN’lerle yazmak teknik olarak mümkündür ama bakımı kâbusa döner. 21:00:00:24:ff:7d:2a:14 gibi bir dizinin hangi sunucuya ait olduğunu altı ay sonra kimse hatırlamaz. Bu yüzden önce device-alias tanımlıyoruz:

MDS-A# configure terminal
MDS-A(config)# device-alias database
MDS-A(config-device-alias-db)# device-alias name VMHOST09_HBA1_P1 pwwn 21:00:00:24:ff:7d:2a:14
MDS-A(config-device-alias-db)# exit
MDS-A(config)# device-alias commit
MDS-A(config)# end

device-alias commit unutulmamalıdır. MDS’te device-alias veritabanı değişiklikleri commit edilene kadar geçerli olmaz ve fabric geneline dağıtılmaz. Commit edilmemiş bir alias’a zone içinde referans verdiğinizde, zone sessizce çalışmaz.

Depolama portlarının alias’ları zaten mevcuttu:

MDS-A# show device-alias database | include ARRAY

device-alias name ARRAY_CTRL0_P1 pwwn 50:0a:09:83:8d:4f:2c:71
device-alias name ARRAY_CTRL1_P1 pwwn 50:0a:09:84:8d:4f:2c:71

3.3. Zone ve Zoneset

Zoning’de yerleşik en iyi uygulama tek initiator kuralıdır: her zone’da yalnızca bir sunucu portu bulunur, karşısında ise erişmesi gereken depolama portları yer alır. Bu sayede bir sunucunun ürettiği RSCN (registered state change notification) fırtınası diğer sunucuları etkilemez ve bir host asla başka bir hostun portunu görmez.

Bu ortamda smart zoning açık; bu özellik sayesinde zone üyelerini init ve target olarak etiketleyebiliyoruz. MDS, initiator’lar arasında gereksiz erişim girdileri üretmeyerek switch’in TCAM kullanımını ciddi biçimde azaltır. Kendi fabric’inizde açık olup olmadığını show zone smart-zoning status vsan 10 ile kontrol edebilirsiniz; kapalıysa:

MDS-A(config)# zone smart-zoning enable vsan 10

Smart zoning kapalıyken aşağıdaki init / target anahtar kelimeleri kabul edilmez. O durumda üyeleri etiketsiz yazın (member device-alias VMHOST09_HBA1_P1); zone yine çalışır, yalnızca donanım kaynağı daha fazla tüketilir.

MDS-A# configure terminal
MDS-A(config)# zone name Z_VMHOST09_HBA1_ARRAY vsan 10
MDS-A(config-zone)# member device-alias VMHOST09_HBA1_P1 init
MDS-A(config-zone)# member device-alias ARRAY_CTRL0_P1 target
MDS-A(config-zone)# member device-alias ARRAY_CTRL1_P1 target
MDS-A(config-zone)# exit

Oluşturduğumuz zone’u aktif zoneset’e ekleyip yeniden aktive ediyoruz:

MDS-A(config)# zoneset name ZS_FABRIC_A vsan 10
MDS-A(config-zoneset)# member Z_VMHOST09_HBA1_ARRAY
MDS-A(config-zoneset)# exit
MDS-A(config)# zoneset activate name ZS_FABRIC_A vsan 10
Zoneset activation initiated. check zone status
MDS-A(config)# end

Dikkat: zoneset activate komutu, adı geçen zoneset’i olduğu gibi fabric’e uygular. Aktif zoneset’i önce show zoneset active vsan 10 ile alıp çalışma kopyanızın onu tamamen içerdiğinden emin olun; eksik bir zoneset’i aktive etmek, o an çalışan sunucuların erişimini anında keser. Bu komut, çift fabric mimarisinin neden sadece donanım değil operasyonel yedeklilik de sağladığının en iyi örneğidir.

Yapılandırmayı kalıcı hale getirmeyi unutmayın:

MDS-A# copy running-config startup-config

Doğrulayalım:

MDS-A# show zoneset active vsan 10 | begin Z_VMHOST09

  zone name Z_VMHOST09_HBA1_ARRAY vsan 10
  * fcid 0x7c0140 [pwwn 21:00:00:24:ff:7d:2a:14] [VMHOST09_HBA1_P1]
  * fcid 0x7c01e0 [pwwn 50:0a:09:83:8d:4f:2c:71] [ARRAY_CTRL0_P1]
  * fcid 0x7c0200 [pwwn 50:0a:09:84:8d:4f:2c:71] [ARRAY_CTRL1_P1]

Baştaki * işareti kritik bir ayrıntıdır: o üyenin fabric’te o anda oturum açmış olduğunu gösterir. Yıldızsız bir üye, zone’da tanımlı ama fabric’e bağlı olmayan bir cihaz demektir — zoning sonrası ilk bakılacak yer burasıdır.

3.4. Depolama Tarafında Host Tanımı

Fabric işini bitirdi, ancak zincirin son halkası depolama ünitesindedir. Array üzerinde ilgili host nesnesine yeni WWPN’in eklenmesi ve LUN maskeleme (mapping) ayarlarının güncellenmesi gerekir. Bu adım üretici ve model bağımlıdır; ancak mantık her yerde aynıdır:

• Hostun 21:00:00:24:ff:7d:2a:14 WWPN’i, mevcut host nesnesine ikinci initiator olarak eklenir.
• Yeni bir host nesnesi oluşturulmaz — aksi halde aynı LUN iki farklı hosta map edilmiş gibi görünür ve veri bütünlüğü riski doğar.
• Mevcut LUN eşleştirmelerinin, aynı LUN ID ile her iki initiator’a da sunulduğu doğrulanır.

En sık yapılan hata: İkinci HBA için depolamada yeni bir host nesnesi açmak. LUN’un aynı hosta iki ayrı kimlikle sunulması, ALUA ve multipath katmanında öngörülemez davranışlara ve en kötü senaryoda veri bozulmasına yol açar. WWPN’i daima mevcut host nesnesine ekleyin.

4. Adım: Doğrulama

Değişikliklerden sonra ESXi’de yeniden tarama yaptık:

[root@vmhost09:~] esxcli storage core adapter rescan --all

Adaptör durumu:

[root@vmhost09:~] esxcli storage core adapter list

HBA Name  Driver      Link State  UID                                     Description
--------  ----------  ----------  --------------------------------------  -----------------------------------------
vmhba1    qlnativefc  link-up     fc.20000024ff7d2a14:21000024ff7d2a14    (0000:5e:00.0) QLogic 16Gb FC Adapter
vmhba2    qlnativefc  link-up     fc.20000024ffb691c3:21000024ffb691c3    (0000:af:00.0) QLogic 16Gb FC Adapter

Her iki adaptör de link-up. Asıl önemli olan ise yol sayısı:

[root@vmhost09:~] esxcli storage core path list -d naa.600a09803830443859244e5a41763721 | grep -i "runtime name"

   Runtime Name: vmhba1:C0:T0:L12
   Runtime Name: vmhba1:C0:T1:L12
   Runtime Name: vmhba2:C0:T0:L12
   Runtime Name: vmhba2:C0:T1:L12

[root@vmhost09:~] esxcli storage nmp device list -d naa.600a09803830443859244e5a41763721

naa.600a09803830443859244e5a41763721
   Storage Array Type: VMW_SATP_ALUA
   Path Selection Policy: VMW_PSP_RR
   Working Paths: vmhba1:C0:T0:L12, vmhba1:C0:T1:L12, vmhba2:C0:T0:L12, vmhba2:C0:T1:L12

İki yoldan dörde çıktık ve Working Paths listesinde artık her iki adaptör de yer alıyor. Yol Seçim Politikası VMW_PSP_RR (Round Robin) olduğu için I/O yükü artık her iki fabric arasında dağıtılıyor — yedekliliğin yanında performans kazancı da elde ettik.

Ama yol sayısının dörde çıkması tek başına yeterli değildir. Yolların gerçekten farklı fabric’lerden geldiğini de doğrulamak gerekir; dört yolun dördü aynı switch üzerinden geçiyorsa, sayı doğru olsa bile yedeklilik yoktur. Host tarafındaki çıktı bunun yalnızca yarısını söyler:

[root@vmhost09:~] esxcli storage core path list -d naa.600a09803830443859244e5a41763721 | grep -E "Runtime Name|Adapter Transport Details"

   Runtime Name: vmhba1:C0:T0:L12
   Adapter Transport Details: WWNN: 20:00:00:24:ff:7d:2a:14 WWPN: 21:00:00:24:ff:7d:2a:14
   Runtime Name: vmhba1:C0:T1:L12
   Adapter Transport Details: WWNN: 20:00:00:24:ff:7d:2a:14 WWPN: 21:00:00:24:ff:7d:2a:14
   Runtime Name: vmhba2:C0:T0:L12
   Adapter Transport Details: WWNN: 20:00:00:24:ff:b6:91:c3 WWPN: 21:00:00:24:ff:b6:91:c3
   Runtime Name: vmhba2:C0:T1:L12
   Adapter Transport Details: WWNN: 20:00:00:24:ff:b6:91:c3 WWPN: 21:00:00:24:ff:b6:91:c3

Bu çıktı yolların iki ayrı fiziksel karta dağıldığını kanıtlar — ama fabric ayrımını kanıtlamaz. İki HBA yanlışlıkla aynı switch’e takılmış olsaydı bu çıktı birebir aynı görünürdü. Fabric ayrımının tek kesin kanıtı switch tarafındadır: her WWPN kendi fabric’inin name server’ında görünmeli, diğerinde görünmemelidir.

MDS-A# show fcns database vsan 10 | include 7d:2a:14
0x7c0140    N     21:00:00:24:ff:7d:2a:14 (Qlogic)     scsi-fcp:init

MDS-A# show fcns database vsan 10 | include b6:91:c3
MDS-A#

MDS-B# show fcns database vsan 20 | include b6:91:c3
0x9e0140    N     21:00:00:24:ff:b6:91:c3 (Qlogic)     scsi-fcp:init

MDS-B# show fcns database vsan 20 | include 7d:2a:14
MDS-B#

Aranan tablo tam olarak budur: her WWPN kendi fabric’inde var, diğerinde yok. İkisi de aynı fabric’te görünseydi, dört yola ve iki HBA’ya rağmen yedeklilik yine kâğıt üzerinde kalırdı.

4.1. Asıl Sınav: Kontrollü Failover Testi

Buraya kadarki doğrulamaların hepsi durağan bir tabloyu okuyor: yollar var, dağılım doğru, isimler yerinde. Ama yedekliliğin gerçekten çalıştığının tek kanıtı, onu bilerek bozup hizmetin devam ettiğini görmektir. Bu testi yapmadan “yedeklilik tesis edildi” demek, bu yazının en başta eleştirdiği varsayımın ta kendisidir.

Test, üzerinde I/O olan bir VM çalışırken yapılmalıdır. Fabric A tarafındaki host portunu yönetimsel olarak kapatıyoruz:

MDS-A# configure terminal
MDS-A(config)# interface fc1/11
MDS-A(config-if)# shutdown

Host tarafında yol sayısı anında yarıya inmeli, ancak Working Paths boş kalmamalıdır:

[root@vmhost09:~] esxcli storage nmp device list -d naa.600a09803830443859244e5a41763721

naa.600a09803830443859244e5a41763721
   Path Selection Policy: VMW_PSP_RR
   Working Paths: vmhba2:C0:T0:L12, vmhba2:C0:T1:L12

Bu sırada VM’lerde hiçbir kesinti, donma veya disk hatası gözlenmemelidir. vmkernel.log içinde yol kaybına dair Path ... state changed to dead satırları görürsünüz; bunlar beklenen kayıtlardır, sorun değildir. Görmemeniz gereken şey APD veya PDL uyarılarıdır.

Portu geri açıp yolların döndüğünü doğruluyoruz:

MDS-A(config-if)# no shutdown

[root@vmhost09:~] esxcli storage core adapter rescan --all
[root@vmhost09:~] esxcli storage nmp device list -d naa.600a09803830443859244e5a41763721 | grep -i "working paths"

   Working Paths: vmhba1:C0:T0:L12, vmhba1:C0:T1:L12, vmhba2:C0:T0:L12, vmhba2:C0:T1:L12

Aynı testi MDS-B tarafında da tekrarlayın. Her iki yön de kesintisiz geçtiyse yedeklilik artık bir tasarım iddiası değil, ölçülmüş bir gerçektir.

Testi yalnızca bakım penceresinde yapın. Bu adım, yazının başındaki riski bilerek üretir: eğer diğer fabric’te bilmediğiniz bir eksiklik varsa, portu kapattığınız anda gerçek bir APD yaşarsınız. Zaten testin amacı da tam olarak bunu güvenli bir zamanda öğrenmektir.

Başlangıçtaki kablo şemasıyla karşılaştırıldığında nihai durum şudur — A hattı artık kesik değil, üstelik bu kez test edilmiş durumda:

flowchart LR
    H["ESXi Host<br/>VMHOST09"]
    FA["FABRIC A<br/>MDS-A · fc1/11"]
    FB["FABRIC B<br/>MDS-B · fc1/11"]
    C0["ARRAY_CTRL0"]
    C1["ARRAY_CTRL1"]
    L["LUN 12<br/>4 aktif yol"]
    H -->|"A1 · vmhba1 — onarıldı"| FA
    FA -->|"A2"| C0
    FA -->|"A3"| C1
    H -->|"B1 · vmhba2"| FB
    FB -->|"B2"| C0
    FB -->|"B3"| C1
    C0 --> L
    C1 --> L
    linkStyle 0,1,2 stroke:#dc2626,stroke-width:2.5px
    linkStyle 3,4,5 stroke:#2563eb,stroke-width:2.5px
    classDef host fill:#f1f5f9,stroke:#64748b,color:#0f172a
    classDef fabA fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
    classDef fabB fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
    classDef arr fill:#fef3c7,stroke:#d97706,color:#78350f
    classDef lun fill:#dcfce7,stroke:#16a34a,color:#14532d
    class H host
    class FA fabA
    class FB fabB
    class C0,C1 arr
    class L lun

Bu Sorun Neden Kritikti?

Düzeltme öncesinde host çalışıyordu, uygulamalar ayaktaydı, kimse şikâyetçi değildi. Buna rağmen tablo şuydu:

• Fabric B’deki tek bir switch arızası, bakım için yapılan tek bir firmware yükseltmesi ya da hatalı bir zoneset aktivasyonu, hostun tüm datastore’larını anında kaybetmesine yol açardı.
• Bu, üzerindeki tüm sanal makineler için APD (All Paths Down) durumu demektir. APD’de VM’ler kilitlenir, dosya sistemleri salt-okunur moda düşer ve toparlanma çoğu zaman yeniden başlatma gerektirir.
• Klasik vSphere HA bu senaryoda kurtarma sağlamaz; çünkü depolama erişimi kaybolduğunda hostun kendisi ayakta kalmaya devam eder — HA’nın izlediği host arızası hiç gerçekleşmez.

vSphere 6.0 ile gelen VM Component Protection (VMCP), tam olarak bu boşluğu kapatmak için vardır: APD veya PDL algılandığında etkilenen VM’leri başka bir hostta yeniden başlatabilir. Ancak iki uyarıyla — küme ayarlarında varsayılan olarak kapalıdır ve APD durumunda devreye girmesi yapılandırılmış bir gecikme süresi (varsayılan 180 saniye) sonrasında olur. Yani açık olsa bile, bu vakadaki riski ortadan kaldırmaz; yalnızca sonucunu hafifletir. Yedekliliğin yerini tutmaz.

Yani sunucuda iki HBA bulunması, tek başına yedeklilik anlamına gelmiyordu. Yedeklilik, donanımın varlığıyla değil, uçtan uca doğrulanmış yolla ölçülür.

Böyle Sorunlar Neden Sessizce Oluşur?

Bu vakanın en öğretici tarafı, sorunun “bozulmamış”, hiç düzgün kurulmamış olmasıdır. Devreye alma sırasında biri kabloyu takmış, ancak switch tarafındaki port yapılandırması ve zoning tamamlanmamıştır. Host o günden beri tek fabric üzerinden mutlu mesut çalıştığı için hiçbir alarm üretilmemiştir.

Bunu önlemenin yolu, devreye alma ve izleme süreçlerine birkaç basit kontrol eklemektir:

Devreye alma kontrol listesi (her yeni host için):

• Her iki HBA da esxcli storage core adapter list çıktısında link-up mı?
• Her iki WWPN de kendi fabric’inin show flogi database çıktısında görünüyor mu?
• Her iki fabric’te de aktif zoneset içinde ilgili zone var mı ve üyeler * işaretli mi?
• Depolamada WWPN’ler tek bir host nesnesine eklendi mi?
• LUN başına yol sayısı beklenen değerde mi (tipik olarak 4) ve yollar iki adaptöre dağılmış mı?
• Switch portlarının description alanları doldurulmuş mu?
• Her iki fabric için ayrı ayrı failover testi yapıldı mı ve host üretime alınmadan önce yollar geri döndü mü?

İzleme tarafında:

Bu kontrolleri tek seferlik yapmak yeterli değildir; bir yıl sonra bir kablo çekilir, bir SFP yaşlanır ve tablo sessizce yine bozulur. İzleme sisteminizde şu iki alarmın bulunması, bu yazıdaki vakanın bir daha yaşanmamasını sağlar:

• LUN başına aktif yol sayısı beklenenin altına düştüğünde uyarı üretin. vSphere alarmları veya bir betikle toplanan esxcli storage nmp device list çıktısı bunun için yeterlidir.
• FC switch portlarının optik seviyelerini (Tx/Rx dBm) düzenli olarak toplayın. Bir SFP genellikle bir anda ölmez; haftalar boyunca kademeli olarak zayıflar. Bu eğilimi görebiliyorsanız, arızayı kesinti yaşanmadan önce yakalarsınız.

Sonuç

Bu vakada VMHOST09 hostu, iki adet Fibre Channel HBA’sına rağmen depolamaya yalnızca tek fabric üzerinden erişiyordu. Kök neden tek bir arıza değil, üst üste binmiş iki eksiklikti: fc1/11 portundaki arızalı SFP modülü ve vmhba1‘in WWPN’i için Fabric A’da hiç yapılmamış device-alias/zoning tanımı.

SFP değişimi, port etiketleme, device-alias ve zone tanımlarının tamamlanması ve depolama tarafında WWPN’in mevcut host nesnesine eklenmesiyle host artık her iki fabric üzerinden depolamaya erişiyor. LUN başına yol sayısı ikiden dörde çıktı ve Round Robin politikasıyla I/O her iki fabric arasında dağıtılır hale geldi. En önemlisi, bu durum yalnızca komut çıktılarına bakılarak varsayılmadı: her iki fabric için ayrı ayrı yapılan kontrollü failover testiyle ölçüldü. Böylece tek switch, tek fabric, tek kablo veya tek HBA kaynaklı bir arıza artık hizmeti kesintiye uğratamayacak.

Akılda kalması gereken tek cümle şudur: Bir sunucuda iki HBA olması yedeklilik değildir; yedeklilik, uçtan uca test edilmiş ve düzenli olarak izlenen yol sayısıdır. Alarm üretmeyen arızalar, en pahalı arızalardır — çünkü onları ancak gerçek kesinti anında keşfedersiniz.

Ek: Bu Yazıda Geçen Terimler