Sessiz Tek Nokta Arıza: ESXi Hostunda Fibre Channel SAN Yol Yedekliliği

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.

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
+ yerel disk"]
        S2["Sunucu 2
+ yerel disk"]
        S3["Sunucu 3
+ 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
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ı.

Sözlük: Bu Yazıda Geçen Terimler

Aşağıdaki teşhis adımlarını rahat takip edebilmek için önce ortak bir sözlük kuralım. Bu tabloya yazının ilerleyen bölümlerinde geri dönebilirsiniz:

Ç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
WWPN ...7d:2a:14"]
        HBA2["HBA 2 · vmhba2
WWPN ...b6:91:c3"]
    end
    FA["FABRIC A
MDS-A"]
    FB["FABRIC B
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
link-down"]
        HBA2["HBA 2 · vmhba2
link-up"]
    end
    FA["FABRIC A
MDS-A · fc1/11"]
    FB["FABRIC B
MDS-B · fc1/11"]
    subgraph ARRAY["Storage Array"]
        direction TB
        C0["Controller 0"]
        C1["Controller 1"]
    end
    HBA1 -. "A1 · ışık yok" .-> FA
    FA -. "A2 · zone yok" .-> C0
    FA -. "A3 · zone yok" .-> 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 kablosunda hiç ışık yoktu; 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: 7c0140
   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: 7c0140) atanmış. vmhba1 ise Port ID: 000000 ile duruyor — yani fabric login (FLOGI) hiç gerçekleşmemiş.

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ı “bana ışık gelmiyor” diyorsa, sıradaki durak switch’tir. Fabric A’daki Cisco MDS switch’ine bağlanıp önce portların genel durumuna baktık:

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      notConnected   swl   --    --       --
fc1/12     10     auto   on      up             swl   F     16       --

fc1/11 portu notConnected 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
      12 link failures, 0 sync losses, 8 signal losses

0 frames input ve signal losses sayacı, kabloda hiç ışık gelmediğini söylüyor. Bir sonraki adım optik seviyeleri okumak — 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              -32.60 dBm     -14.40 dBm      -13.40 dBm

Tablo çok şey anlatıyor. Tx Power, yani switch’in kendi gönderdiği ışık gücü, alarm eşiğinin çok altında. Bu, karşı taraftaki sunucudan ya da kablodan kaynaklanan bir problem değildir; SFP modülünün lazeri artık düzgün ışık üretmiyor demektir. Rx Power değerinin de zeminde olması, karşı uçtan da sinyal gelmediğini gösterir — çünkü ESXi tarafındaki HBA, kendisine hiç ışık ulaşmadığı için link kurmayı reddetmiş durumdadır.

Aynı switch’te sağlıklı bir portta Tx Power ve Rx Power tipik olarak -2 ile -5 dBm aralığındadır. Aradaki 25-30 dB’lik fark, 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.

3. Adım: İ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ı.

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.

4. Adım: Çözüm

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

4.2. Device-Alias Tanımı

Zone’ları çıplak WWPN’lerle yazmak teknik olarak mümkündür ama bakımı kâbusa döner. 20: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

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

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.

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

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

Son olarak, yolların gerçekten farklı fabric’lerden geldiğini doğrulamak gerekir. Dört yolun dördü aynı switch üzerinden geçiyorsa, sayı doğru olsa bile yedeklilik yoktur:

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

Farklı WWPN’ler, farklı fiziksel kartlar, farklı fabric’ler. Yedeklilik gerçekten tesis edildi.

Başlangıçtaki kablo şemasıyla karşılaştırıldığında nihai durum şudur — A hattı artık kesik değil:

    
flowchart LR
    H["ESXi Host
VMHOST09"]
    FA["FABRIC A
MDS-A · fc1/11"]
    FB["FABRIC B
MDS-B · fc1/11"]
    C0["ARRAY_CTRL0"]
    C1["ARRAY_CTRL1"]
    L["LUN 12
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.
• vSphere HA bile bu senaryoda güvenilir bir kurtarma sağlayamaz; çünkü depolama erişimi kaybolduğunda hostun kendisi ayakta kalmaya devam eder ve HA olayı tetiklenmesi gecikir.

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?

İ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. 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 doğrulanmış 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.