Murphy és a "jó" design

Elég mozgalmas volt ez az április, így nem sok időm volt blogolni bármiről is, de azért egy "emlékezetes" issue úgy érzem megérdemel annyit, hogy megmaradjon az utókornak.

Hol volt, hol nem volt (az óperenciás rendszeren is túl) volt egy szerver, aminek a design-ját okos emberek kialakították, és megítélendék jónak. Persze az okos emberek teljesen másra szánták a gépet mint amire azt később a customer nevű állatfaj elképzelte. Így alakulnak ki a természetben az olyan félvér állatfajok, amik inkább csak a hibáikkal tűnnek ki, mint sem a használhatóságukkal, és tuti biztos, hogy a lelkes adminisztrátorok előbb utóbb rájönnek, hogy az ilyen szerverek is inkább csak elrettentő példának jók, min tsem produktív dolgok futtatására, de hát a customert ez a legkisebb mértékben se szokta érdekelni, neki csak az a fontos, hogy az über-fontos dolgok menjenek a gépen..

Na most.. Ha még vannak olvasók akik nálam jobb emlékezettel vannak megáldva, akkor nekik lehet dereng valami a múltból, amikor a design hibákat ecsetelgettem, és már akkor is elmondtam, hogy az adott architect-nek jó rejszolást kívánok egy sajtreszelő társaságában, hogy ezt a design-t képes volt megálmodni

Hogy, hogy nem, most Áprilisban jött el az ideje annak, hogy Murphy ismét szórakozni akarjon, és kitalálta, hogy ez az igen fontos gép amúgy is billeg a szakadék szélén, hát miért ne lökjön rajta egy kicsit.. Persze ha már ott van, akkor a mentőalakulatok útjába is felállít 1-2 csapdát, mert az úgy még is csak nagyobb a FUN faktor.

A valóságban mindez a következőképp realizálódott:
Első körben a fenti design-ban szereplő RAID 5 tömb alól 2 diszk úgy gondolta, hogy őt már nem becsülik meg eléggé, így Seppuku-t hajt végre. "Mázlira" csak az Egyik diszk volt aktív, a másik csak Hotspare, így elméletben még itt nem kéne nagy problémának lennie. Így hát új diszk beszerez, hotplug manager elő, aztán cseréljük on-the-fly a temetőbe szánt Hotplug diszket, ahogy az a nagykönyvben is meg van írva.

Sajna azonban a Nagykönyvekkel mindig az a baj, hogy az emberek elfogadják a benne leírtakat egyfajta axiómának, ami -ha Murphy is a képben van- általában nem teljesen szokta lefedni a valóságot: Így hát persze így se minden úgy működött ahogy kellett volna.. Történt ugyan is, hogy a teljesen szabályosan kicserélt új diszket a rendszer nem volt képes lekezelni, mivel a régi konnekciós azonosítót valamiért nem akarta felszámolni.
Hogy szemléletesebb legyen a dolog, kb ezt látja a szerencsétlen adminisztrátor:

# sissasraidmgr -L -j1 -l sissas5
------------------------------------------------------------------------
Name      Resource  State       Description              Size                  
------------------------------------------------------------------------
sissas5   FFFFFFFF  Primary     PCI-X266 Ext Tri-x4 3Gb SAS RAID Adapter
 sissas6  00000000  AWC linked  Redundant cache protection for sissas5  

hdisk3    00FF0000  Degraded    RAID 5 Array            1135GB                 
 pdisk0   00000200  Failed      Array Member           283.8GB                 
 pdisk1   00000300  Active      Array Member           283.8GB                 
 pdisk3   00000500  Active      Array Member           283.8GB                 
 pdisk2   00000400  Active      Array Member           283.8GB                 
 pdisk4   00000600  Active      Array Member           283.8GB                 

*unknwn*  00000700  RWProtected Array Candidate            N/A                 
pdisk5    00000700  Missing     Disk                   283.8GB

Na szóval.. Vagy egy hdisk3 néven létező RAID 5 tömbünk, ami épp Degrad állapotban leledzik, mindez a sissas5 adapteren. Van 2 halott diszkünk (pdisk0,pdisk5), ami közül pdisk5-öt igyekszünk épp kicserélni, ami jelenleg épp Missing státuszban leledzik. A pdisk5 kapcsolati címén (00000700) azonban van még egy diszk, ami épp RWProtected, amúgy meg unknown (tehát a rendszer nem tud róla semmit). Így meg persze még neki se lehet állni új Hotspare-t definiálni (hogy aztán azt majd bedobjuk a pdisk0 helyére)

Na ez az a rész, amiről a nagykönyv nem ír semmit (Murphy viszont a Pop-corn egy részét már elfogyasztotta).. Ergo akkor nincs más, csak kidobni a vak hitet, és menni az ember saját feje után.
Első körben az előzőleg kicserélt diszk-et kivéve a slotból lehetőség nyílt az unknown device "elvesztésére" ám a rendszer pofátlan módon ragaszkodott a pdisk5 jelenlétéhez, attól függetlenül, hogy az már közel, s távol nem volt a gépben. Külön poénként ezt a meggyőződését még akkor se volt hajlandó elfelejteni amikor a pdisk5-öt 'rmdev -dl'-el lelőttem, majd a config managert (cfgmgr) futtattam, mivelhogy az rendkívül ragaszkodóan visszahozta a pdisk5-öt "Available" státuszban (a RAID vezérlő persze még mindig Missing-nek látta).

Na akkor itt álljunk meg egy picit.. Felmerül a kérdés -gondolom- az olvasóban, hogy biztosan a jó diszk lett kihúzva? Igen, ez volt az első felmerülő kérdés bennem is, de többszöri vizsgálat után is csak az jött ki, hogy valóban a jó diszket piszkálom és az AIX (VIO, de a lényegen semmit nem változtat) az aki foggal körömmel ragaszkodik ahhoz a diszkhez.

Fejvakarás, cseresznyefák, és wattafák.. Avagy csak fák.. Kinek mi esik jól.. Murphy közben a Pop-corn mellett már elindította a háttérben a Kokaku Kidotai (Ghost in the Shell) OST-t is, mert ehhez a jelenethez ez illik a legjobban..

Adminisztrátor részről persze teljes értetlenség, keresés, látott e már valaki valami ilyesmit? Aztán szembejön ez a bug, és fény gyúlik a katakombákban : IZ72353 - SAS PDISK DISPLAYED AS *UNKNWN* AFTER REPLACE/REBUILD APPLIES TO AIX 6100-03

Jah hogy úgy... Hát úgy.. A gáz csak annyi, hogy a patch magában nem elérhető (mivel VIO-ról beszélünk, így csak VIO frissítéssel együtt oldható meg a csótányirtás), így (mivel már mindenki a hátunk mögött van, és a messzeségben már a mesterlövészek is a mi monitorunkat lesik a fejünk mellett) a leggyorsabb megoldás a restart marad. Persze előtte minden kliens azonnal állj, addig a VIO se mozduljon semerre..

Restart, öröm és boduttá.. A pdisk5 végre defined-ban jön fel, sőt az újonnan beletett vinyót is már látja a rendszer.. Sínen vagyunk mint József Attila..
HotPlug diszk megformáz 528 Byte Szektor mérettel, majd a pdisk0 kipöccintése után nyomban be is áll a helyére az immár hamvaiból feltámadt pdisk5 Főnix madár, indulhat az Array Rebuild, semmi ok a pánikra, minden a Ctrl billentyű alatt van

Hátradőlünk, és szépen várjuk, hogy a tömb újjáépítése befejeződjön. A háttérben viszont Murphy ráadást követel, így hát újabb szám zendül fel a hangszórókból.

A moziban ilyenkor kezdenének el villogni a piros villogók, felharsognának a szirénák, és valami kis rangú emberke kétségbe esve megszólalna, hogy "Sir, Something is wrong!" (Thank you, Caption obvious). A valóságban azonban az embert csak egy ilyen hibaüzenet fogadja a fekete putty ablak mögött:

# sissasraidmgr -L -j1 -l sissas5
------------------------------------------------------------------------
Name      Resource  State       Description              Size                  
------------------------------------------------------------------------
sissas5   FFFFFFFF  Primary     PCI-X266 Ext Tri-x4 3Gb SAS RAID Adapter
 sissas6  00000000  AWC linked  Redundant cache protection for sissas5  

hdisk3    00FF0000  Failed      RAID 5 Array            1135GB Rebuild Failed 04
 pdisk5   00000700  Failed      Array Member           283.8GB                 
 pdisk4   00000600  RWProtected Array Member           283.8GB                 
 pdisk3   00000500  RWProtected Array Member           283.8GB                 
 pdisk2   00000400  RWProtected Array Member           283.8GB                 
 pdisk1   00000300  Failed      Array Member           283.8GB                 

pdisk0    00000200  RWProtected Array Candidate        283.8GB

Őőő.. 'nyádat... Újratervezés..
- A pdisk5 most lett kicserélve, leformázva, leellenőrizve, így az garantáltan nem lehet halott (hacsak nem a vezérlő halt meg, de akkor már az ima is édeskevés lesz)
- A pdisk1re eddig nem jött egy hibajelentés se, így azt vessük górcső alá.
- Az errpt entry-jeit elnézegetve (54E8A127 error code (DEVICE OR MEDIA ERROR), ha valakit érdekel) az összes hibajegy a pdisk1-el megegyező Serial ID-ra jön, így tételezzük fel, hogy a pdisk5 Failed státusza az újraépítés során tapasztalt pdisk1 hibájának mellékhatása csak.

Ezzel viszont egy újabb probléma üti fel a fejét: A RAID5 tömb egyszerre csak 1 aktív diszk halált bír ki, kettőt már nem. Amennyiben a pdisk1-et is ki kell cserélni, akkor kalap,kabát, búcsút lehet mondani az adatainknak, mert 3 diszkből már nem engedi a vezérlő se helyreállítani a tömböt (Én megpróbáltam, de hát ez nem linux).
Egy mázli volt - amennyiben az ember újraindítja ebben a fázisban a VIO-t, akkor a SAS RAID vezérlő újra megpróbálja a tömböt össze-eszkábálni, ami viszont kitűnő alkalmat teremt arra, hogy az ember megpróbálja menteni ami menthető.

És itt most álljunk meg ismét egy pillanatra.
- Adott egy fél lábbal már a sírban lévő RAID5 tömb
- A tömbön lévő adatok egy része már garantáltan nem elérhető, tehát a disaster recovery elkerülhetetlen (ugye van disaster recovery plan? :) Megsúgom, az ilyen rendszereknél rendszerint nincs.. Itt a remek alkalom, hogy most fejben összeüss egyet, és imádkozz, hogy az a minimális backup process ami eddig volt elégséges legyen :D )
- Ha mindenképpen kell DR, akkor minek akarok én menteni bármit is?

Nos, a válasz némileg komikus: Az egyik kliens egy Linux rendszer (SLES 10), amely system VG-je 1 VIO-n található LV-re lett ráhúzva (az LVM kell, ha az ember normálisan akarja skálázni a meglévő erőforrásokat, szóval ez még érthető is). Ahhoz, hogy ezt visszaimádkozzuk 3 út maradt:
- Csinálni egy low level mentést byte szinten a "Guest" System VG-jét tartalmazó PV-ről (azaz a VIO-n lévő LV-ről) valahova a RAID tömbön kívűl, és azt megpróbálni visszatölteni amint az új RAID tömbünket kénytelenek voltunk újra kreálni
- Csinálni egy FS szintű backupot (SLES gyárilag tud ilyet), a RAID tömb 0ról való építése után pedig felhúzni egy alap SLES rendszert, és arra visszatölteni az itt készült backup-ot
- Megpróbálni csinálni egy bootolható ISO file-t, azt odaadni a VIO-nak, majd mint CD/DVD-t kiallokálni a kliens felé, és arról visszatölteni az adatokat (Standard Linux környezetben ez szépen megy is, de amúgy vannak direkt erre a célra elkészített programok is, mint pl a Mondo Rescue)

A baj csak az volt, hogy mind3 út buktatókkal volt kikövezve:
- Bootolható ISO készítés: Az elmélet jó, de az egyik verzióban fel kéne raknom a Mondo Rescue (vagy azzal egyenértékű) progit, ami sajna PPC-re nem elérhető. A Debian féle módszer még működne is, de sajna a pSeries gépeken a boot loader nem grub, hanem Yaboot, ami meg nyomban úgy kezdi, hogy külön FAT16 típusú partíció neki, ami az ISO image-em szempontjából így nem járható.
- Az FS szintű backup azért necces, mert egy teljesen új rendszer felinstallálása szükséges hozzá, ami meg iszonyat nagy macera.
- A low-level (dd) szintű backup tűnt a legjobbnak (és akkor még az LVM struktúra is megmarad), ám amennyiben a RAID5 tömb ezen belül hibásodott meg, akkor meg megint ott vagyok ahol a part szakad..

Nem volt mit tenni: Úgy döntöttem, hogy amit lehet menteni kell (lehetőleg minél többféle képen), mivel a jelenlegi állapotot tutira újra is kell építeni. Tehát csináltam egy dd szintű mentést (LPAR lekapcsolva természetesen), meg egy FS szintűt is, felkészülve a legrosszabbra (az applikációs adatokért nem tudtam semmit se tenni, azt majd remélhetőleg a standard backup process által készített backup lefedi az adat visszaállítás során)

Ez után jött a másik 2 diszk cseréje (pdisk0, pdisk1), majd a halott RAID tömb törlése, és egy új készítése. Mindeközben sűrű miatyánk Mekka irányába..
Amint az új RAID tömb elkészült (immár hiba nélkül) lehetett visszahozni a régi LVM struktúrát, majd nekilendülni az adat visszaállításnak..
És igen.. Mázlim volt.. nettó 40 perc alatt a ~100 GB-os system VG-ről készített dd backup visszatöltődött (yaboot-al együtt), és az LPAR képes volt felbootolni (igaz RC 2ig nem jutott el, de ezen már lehetett segíteni), ergo már csak a tényleges applikációs adatok visszatöltése maradt vissza (meglepő módon azok visszatöltése közben nem nagyon akadt probléma)

Tapasztalatok a jövőre nézve:
- Ha tényleg über fontos adatról/alkalmazásról beszélünk, akkor erőltessük már meg magunkat, és a környezetet tényleg redundánsan alakítsuk már ki
- A RAID 5 addig jó, amíg kevés diszk van alatta. A tömb növekedésével együtt növekszik a teljes tömb meghalásának esélye is (mivel nagyobb az esélye, hogy 1 időn belül 2 aktív diszk hal ki, ahogy itt is történt (nagy eséllyel a használt diszkek ugyan abból a sorozatból valóak, ergo közel ugyan annyi idő alatt is halnak meg))
- Disaster recovery plan még akkor se árt ha van, ha amúgy a rendszer nem indokolja azt meg. A probléma a jelen setuppal az, hogy nem nagyon lehet rá 100%-os plan-t készíteni (ami effektíven használható lenne), a bootolható backup hiánya miatt (személyes véleményem szerint SLES pSeries-re nem való)
- Nagykönyv lehet, hogy létezik, de inkább tekintsünk rá amolyan "Kalóz Kódexként" ami inkább csak útmutatás, mintsem sérthetetlen szabály.. Valami úgy is valamikor el fog romlani, amire persze hogy nem leszünk felkészülve
- A szokásos halandzsa - update, update, update. Tudom, hogy az überfontos applikáció überfontos uptime-al kell üzemeljen, de kalkuláljunk már maintenance window-t is a rendszerhez, hogy az ilyen hülye önszopatásoktól megkíméljük magunkat.
- Murphy sose alszik, és mindig pörgős zenét hallgat :)

Dual Network VIO - SEA adapter buktatók

Normálisabb helyeken ugyebár a az ember minimum 2 VIO szervert használ (ha másért nem, hát a redundancia végett), ami meg nyomban meg is követeli a SEA (Shared Ethernet Adapter) használatát control chanellel (plusz persze a megfelelő trunk priority beállításával). Ezzel nincs is semmi gond..
Aztán amikor az embernek valami baja van az egyik VIO-val, akkor meg pont örül, hogy milyen jó is a redundancia, majd teljes lelki nyugalommal nekiáll a hibás dolgot megjavítani.. Az általam tapasztalt esetben a hiba épp egy SEA adapter alatt lévő fizikai adaptereknél jelentkezett. Ebben az esetben az ember 2 dolgot tehet:

- Lebontja a SEA-t (illetve jelen esetben az ether channel-t is), majd elkezdi szépen darabonként szétcincálni az alatta lévő eszközöket, hogy vajon merre is lehet a probléma
- Azt mondja az ember, hogy a végén úgy is újra kell inicializálni az egészet, úgy is redundáns a rendszer, gyorsabb ha újraindítom (amúgy tényleg)

Mind2 esetben persze meg kell bizonyosodni róla, hogy a másik VIO átvette az összes hálózat vezérlését, amit az entstat -all [SEA]-val meg is lehet tenni (padmin alól; root alól standard entstat -d [SEA]).. Amennyiben a másik VIO átvette, akkor az összes hálózaton a SEA-nak a 'PRIMARY' állapotot kell mutatnia. Amint ez a helyzet már nyugodtabbak lehetünk, mert a másik VIO-n kedvünkre lehet matatni, az nem fog kihatni a kliensekre..

Mind emellett persze még van egy dolog amire figyelnünk kell, miszerint hogy az éppen hibás VIO-n a ha_mode hogy is áll.. Nyomban 3 lehetőségünk is van chdev-el ezt megpiszkálni:

chdev -dev [SEA]-attr ha_mode=auto -> ezt használjuk ha azt akarjuk, hogy a Trunk Priority alapján döntse el a 2 VIO egymás között, hogy épp ki szolgálja ki az adott hálózatot. Amennyiben az éppen aktuális VIO ezt mégse tudja megtenni, akkor nyomban átpasszolja a másik VIO-nak a hálózatot.

chdev -dev [SEA]-attr ha_mode=standby -> Ez amolyan "illedelmes (gently)" kérés a VIO felé, hogy hagyjon fel a hálózat kiszolgálásával (ha netán nála lenne). Amennyiben át akarjuk adni a másik VIO-nak a hálózatot, úgy illik ezt használni

chdev -dev [SEA]-attr ha_mode=disable -> Ez a módszer meg azt mondja, hogy a SEA adapter mostantól nincs HA módban, ergo bármiféle hálózati failoverre esély sincs.

Az utóbbi esetben viszont van 1-2 érdekes viselkedés, ami ha jól láttam sehol se volt dokumentálva (kb ezért is született ez a bejegyzés):

Amennyiben egy már bekonfigurált dual-network VIO-s környezet alól szedjük ki a HA módot a chdev-el, úgy attól még az entstat alatt láthatjuk, hogy a VIO még tud a primary VIO-ról, viszont persze nem fogja tudni átvenni a hálózatot, viszont a vicc az, hogy amíg újra nem indítjuk a gépet, addig nem is fog a hálózat átvételére kísérletet tenni. Ergo itt még el lehet játszani, hogy:

chdev -dev [SEA] -attr ha_mode=disable
chdev -dev [SEA] -attr ha_mode=standby ctl_chan=[Control_channel_adapter]

Majd ez után olyan szépen visszaáll a HA módba, hogy öröm nézni. Mellékesen felhívnám a figyelmet arra, hogy ebben az esetben a 2 VIO között használt (dedikált VLAN-al rendelkező) Control Channel adaptert újra kell konfigurálni, mivel a disable azt teljesen kitörli a beállítások közül! (Ez szintén nincs ledokumentálva sehol se)

A másik dolog ami ilyenkor problémát okozhat, ha olyan okosak vagyunk, hogy restartoljuk a gépet.. Ekkor ugyan is a SEA már nem fog semmit tudni arról, hogy ő eredetileg egy HA módban lévő dual network VIO volt, és annak rendje és módja szerint ő is "magáévá" szeretné tenni az adott VLAN taggelt hálózat irányítását.. Ez persze felvet egy olyan alapvető problémát, hogy mi van akkor ha már az adott hálózatot a switch-en használja valaki (tekintve, hogy dual VIO esetén a fentebb sorolt módon nagy eséllyel épp átadtuk a restart előtt a hálózatot a másik VIO-nak így szinte biztos, hogy ez a helyzet)?

Nos.. A helyzet koránt sem vicces -> A HA módból leválasztott SEA egy kisebb ARP tornádót fog a switch felé indítani (network storm) ami miatt meg a switch nem lesz képes kiszolgálni a kéréseket, ergo az a hálózat innentől nem elérhető, aminek a legtöbb customer csak ritkán örül, szóval dual network VIO-s környezetben mindenki felejtse el a ha_mode esetében a disable módot!!

Járulékosan az elmúlt pár napban felmerült részemről az igény egy kis network VIO monitoring scriptre, szóval ha valaki úgy érzi, hogy ez egy háztartásból se hiányozhat, úgy nyugodtan használja egészséggel :))

#!/usr/bin/ksh
# Script created by Gabor Lukacs
# Note - please use the script only on a dual-network VIO environment!
# Version 0.2

# Run as root pls :)
if [ "$(id -u)" != "0" ]; 
then
 echo "You must have root rights to run this script!"
 exit 1
fi

export ODMDIR=/etc/objrepos
NEED_MAIL=0
MAIL_SUBJECT="Warning! Some error(s) detected on $(hostname) VIO server!"
MAIL_ADDRESS=    # Fill this out before use :)

# Checking SEA adapters
if [ $(lsdev -Cc adapter |grep "Shared Ethernet Adapter" |grep -c Defined) -ne 0 ]
then
 echo "Warning! - There are one or more non-available SEA adapters:"
 lsdev -Cc adapter |grep "Shared Ethernet Adapter" |grep Defined
 NEED_MAIL=1
fi

for SEA in $(lsdev -Cc adapter |awk '/Shared Ethernet Adapter/ && /Available/ {print $1}')
do
 echo "\nChecking ${SEA} SEA adapter"
 USED_VLAN=$(odmget -q "name=${SEA} and attribute=pvid" CuAt|awk -F "\"" '/value/ {print $2}')
 SEA_STATE=$(entstat -d ${SEA} 2>&1|grep -E "ETHERNET STATISTICS|State|Priority" |awk '{ gsub("ETH", "\nETH"); print }' |grep -p ${SEA} |grep State)
 SEA_USED_TRUNK_PRIORITY=$(entstat -d ${SEA} 2>&1|grep -E "ETHERNET STATISTICS|State|Priority" |awk '{ gsub("ETH", "\nETH"); print }' |grep -p ${SEA} |grep Priority)
 SEA_USED_CTL_CHAN=$(odmget -q "name=${SEA} and attribute=ctl_chan" CuAt |awk -F "\"" '/value/ {print $2}')
 SEA_HA_MODE=$(odmget -q "name=${SEA} and attribute=ha_mode" CuAt |awk -F "\"" '/value/ {print $2}')
 echo "\tVLAN ID: $USED_VLAN"
 echo "\t${SEA_STATE}"
 echo "\t${SEA_USED_TRUNK_PRIORITY}"
 
 # In case the SEA adapter's state isn't Primary or backup send a mail
 if [[ $(echo "${SEA_STATE}"|awk '{print $NF}') != "BACKUP" && $(echo "${SEA_STATE}"|awk '{print $NF}') != "PRIMARY" ]]
 then
  NEED_MAIL=1
 fi
 
 if [ ${SEA_USED_CTL_CHAN} ]
 then
  echo "\tSEA used control channel adapter: ${SEA_USED_CTL_CHAN}"
 else
  echo "\tSEA used control channel adapter: No adapter defined (Please check in case it's a dual network-VIO setup!)"
 fi
 echo "\tSEA HA mode: ${SEA_HA_MODE}"
 
 REAL_ADAPTER=$(odmget -q "name=${SEA} and attribute=real_adapter" CuAt |awk -F "\"" '/value/ {print $2}')
 
 # Is the adapter in defined state?
 if [ $(lsdev -l ${REAL_ADAPTER} |grep -c Defined) -eq 1 ]
 then
  echo "\WARNING - The ${REAL_ADAPTER} adapter is in defined state!"
  NEED_MAIL=1
 # Ok.. It's not defined.. Move forward
 else
  if [ $(lsdev -l ${REAL_ADAPTER} |grep -c EtherChannel) -eq 1 ]
  # In case SEA using link aggregation
  then
   echo "\tSEA used real adapter: ${REAL_ADAPTER} (Etherchannel)"
   ETH_CHAN_ADAPTERS=$(odmget -q "name=${REAL_ADAPTER} and attribute=adapter_names" CuAt|awk -F "\"" '/value/ {print $2}' |sed "s/,/ /g")
   echo "\tUsed physical adapters under ${REAL_ADAPTER} Etherchannel adapters:"
   for ETH_CHAN_ADAPTER in ${ETH_CHAN_ADAPTERS}
   do
    # 2nd check - is any of the etherchannel used physical adapter in defined state?
    if [ $(lsdev -l ${ETH_CHAN_ADAPTER} |grep -c Defined) -eq 1 ]
    then
     echo "WARNING - The ${ETH_CHAN_ADAPTER} adapter is in Defined state!"
    # No.. Grand.. move forward
    else
     echo "\t\t${ETH_CHAN_ADAPTER}"
     ADAPTER_STATUS=$(entstat -d ${SEA} 2>&1|grep -E "ETHERNET STATISTICS|Link Status|Media Speed Running" |awk '{ gsub("ETH", "\nETH"); print }' |grep -p ${ETH_CHAN_ADAPTER} |awk '/Link Status/ {print $NF}')
     ADAPTER_MEDIA_SPEED=$(entstat -d ${SEA} 2>&1|grep -E "ETHERNET STATISTICS|Link Status :|Media Speed Running" |awk '{ gsub("ETH", "\nETH"); print }' |grep -p ${ETH_CHAN_ADAPTER} |grep Media)
     echo "\t\t\tStatus: ${ADAPTER_STATUS}"
     echo "\t\t\t${ADAPTER_MEDIA_SPEED}"
     # If adapter Status isn't up, send a mail
     if [ ${ADAPTER_STATUS} != "Up" ]
     then
      NEED_MAIL=1
     fi
    fi
   done
  # In case it not using Link aggregation
  else
   echo "\tSEA used real adapter: ${REAL_ADAPTER} (physical adapter)"
   ADAPTER_STATUS=$(entstat -d ${SEA} 2>&1|grep -E "ETHERNET STATISTICS|Link Status|Media Speed Running" |awk '{ gsub("ETH", "\nETH"); print }' |grep -p ${REAL_ADAPTER} |awk '/Link Status/ {print $NF}')
   ADAPTER_MEDIA_SPEED=$(entstat -d ${SEA} 2>&1|grep -E "ETHERNET STATISTICS|Link Status|Media Speed Running" |awk '{ gsub("ETH", "\nETH"); print }' |grep -p ${REAL_ADAPTER} |grep Media)
   echo "\t\tStatus: ${ADAPTER_STATUS}"
   echo "\t\t${ADAPTER_MEDIA_SPEED}"
   # If adapter Status isn't up, send a mail
   if [ ${ADAPTER_STATUS} != "Up" ]
   then
    NEED_MAIL=1
   fi
  fi
 fi
done > /tmp/vio_status.output

if [ ${NEED_MAIL} -eq 1 ]
then
 mail -s "${MAIL_SUBJECT}" "${MAIL_ADDRESS}" < /tmp/vio_status.output
fi

Hátlapát...

.. annak a baromnak aki ezt a szerver design-t kitalálta (avagy architect epic fail)
Adott egy Power6os box (p570), amelyen a következő setup-ot alkották meg az "okosok":
- Mivel a gép bírja, így pakoltak bele egy csomó diszket meg 1-2 SAS RAID controllert, mert miért ne.. Fiber Channelt persze minek..
- A gépen létrehoztak 2 VIO szervert, ahogy az a nagy könyvben meg van írva.. Egyedül annyi a gáz, hogy valszeg a nagy könyv első 20 oldala lehet csak meg, mert se a network-ot, se a storage-ot, de még a VIO-kat se csinálták redundánsra!
- Na de akkor minek a VIO - Fogták a 2 VIO szervert, majd 1-1 RAID controllert hozzájuk rendeltek. A gépben lévő megannyi szép nagy vinyókat meg pdiskenként bebaxták egy 1-1 nagyobbacska RAID5 tömbbe
- Ebből következik, hogy mint redundancia olyan nincs, mert a RAID kártyákat nem lehet több LPAR-hoz is hozzárendelni, ergo innentől van 2 külön VIO-nk 2 külön RAID5 tömbbel.. Na de mire kell ez?
- A megoldás egyszerű: Fogták magunkat, létre hoztak egy nagy VG-t a RAID tömbben, majd a VG-n belül létrehozott LV-ket Virtual Diszkként kiosztották az LPAR-oknak, hogy azok boldogan magukévá tehessék az immáron új diszkeket.. A probléma persze csak az, hogy mivel a RAID tömbök VIO-nként egyediek, így véletlenül se tudjuk ugyan azt a kiosztást megcsinálni mind2 VIO-nál, ergo a Virtual diszkek csak az 1ik VIO-n keresztül érhetőek el => A 2 VIO csak külön-külön LPAR-okat tud kiszolgálni!
Problémák ezzel a felállással:
- Nehezen bővíthető: Ha elfogy a RAID5 alól a hely, akkor aztán így járás, mert egy idő után a diszkek is elfogynak
- Mivel RAID5ről beszélünk, így a teljes RAID tömbben csak egy VG van. Ennek annyi előnye van, hogy 1 LPAR gond nélkül el tudja vinni a teljes kapacitást a többi elől, ha ő úgy akarja (és mivel applikáció is fut rajta, így persze, hogy úgy akarja )
- Redundancia mint olyan sehol nincs, sőt nem is nagyon lehet úgy átépíteni a rendszert, hogy legyen (az alapoktól újra kéne építeni).
- A vicc kedvéért az LPAR-okhoz használható NIM szerver ugyan azon boxon belül található, mint az LPAR-ok, így aztán komolyabb HW failure esetén (lehal a box) esélye nincs bárkinek is restore-olni az LPAR-okat..
- MINEK MINDEHHEZ VIO????