Storage-HBA-ESX fiaskó

A múlt héten bártor tettre szántuk el magunkat. Keddre – ugy gondoltam – minden információval rendelkezem ahhoz, hogy az új ESX szerverünket, illetve annak a majdani VMFS kötetet hordozó LUN-ját elhelyezzem a jelenlegi Exchange fürtünkkel közös storage partícióba, majd a SAN switchek zónázásával láthatóvá tegyem az ESX HBA-k számára a storage ezen részét.
A LUN elhelyezése gond nélkül ment, az ESX telepítés is problémamentesen lefutott, sőt, még az ESX Active Directory integrációját is sikerült bekonfigurálni egy VmWare cikk segítségével. A SAN switchek zónázását – bár értem az elvet – mégsem én végeztem el, hanem megkértem az IBM mérnökét, aki tíz perc alatt, távolról megoldotta. A zóna életbe léptetése "esetleges adatútvonal megszakadást" eredményezhetett volna, ezért az átállást délutánra időzítettük. A switch eredeti és új konfigjáról is készült konfig mentés, így egyetlen mozdulattal át- illetve vissza lehetett állni.
 
Az átállás utáni elvár viselkedés az volt, hogy az ESX lássa meg a saját LUN-ját, lássa meg a leendő Exchange LUN-okat ÉS a cluster viselje el, hogy még egy kiszolgáló került a storage partícióba. Nos, talán már a megfogalmazásból is érződik, hogy "nem az elvárt" viselkedés következett be. Az ESX nem látta meg a saját LUN-ját, viszont meglátta az Exchange-ét, és bár nem lett volna szabad, az Exchange node-jai teleszórták disk 51-es és ftdisk 50-es hibával a system logot. Nem volt más választásunk, vissza kellett állni a SAN switch előző konfigjára.
 
A következő napokban megpróbáltam kideríteni, mi lehetett a probléma. Nos, több hibát is elkövettünk. A legegyszerűbb ezek közül az ESX félrekonfigurálása, egészen pontosan, az alapértelmezett beállítások meghagyása volt. Az ESX az alapbeállítások szerint 8 db LUN-t lát, de ez szabályozható 0 és 128 között. Az Exchange cluster épp 8 db LUN-t használ, így fordulhatott előt, hogy azokat mind látta, miközben épp a sajátját nem. PAramétert átállítottam.
A másik probléma – valószínű –  megoldását a Microsoft szolgáltatta. A cikk szerint egy storage partícióban csak egyféle HBA kártyát lehet használni. Nos nekünk kétféle volt, ráadásul az Exchange fürttagokon még egy 1999-es gyártású BIOS-szal sem rendelkező Compaq HBA kártya van, amelyekkel már korábban is voltak problémák, még a FAStT500-ra való átálláskor.
A megoldás ebben az esetben egy kicsit körülményes. A rendszer "végső" állapotában a jelenlegi Exchange node-ok egyáltalán nem csatlakoznának a storage rendszerre, tehát HBA-kra sem lesz szükségük. Így aztán előbb kölcsön kell kérni és telepíteni kell őket, el kell végezni a migrációt az ESX-re, végül el kell távolítani a kártyákat. Jó érzés – és talán ez esetben nem etikátlan leírni a szállító nevét – hogy az IBM maximálisan partner ebben az akcióban.
Végezetül – emberből vagyunk – én is elkövettem egy hibát. A storage kontrollereket is konfigurálni kellett volna, pontosabban egy NVSRAM scriptet kellett volna lefuttatni.
 
A következő próbálkozásra felkészülök és beszezek egy storage-os szakembert, meg egy ESX-est is. Nem mintha nem tudnék NVSRAM scriptet futtatni, vagy ESX-et konfigurálni, de ha letérünk a karikacsapásról, nem fog ártani, ha lesz még egy két tapasztalt és gondolkodó ember mellettem. Megpróbáltam, hátha lehet egy kis pénzt spórolni  a cégnek. Más talán bele sem vágott volna ilyesmibe. Most azonban biztosra kell menni, mert nem hiszem, hogy megengedhető még egy leállás. Mer nagyon kell az az Exchange 2003.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: