2011. szeptember 15., csütörtök

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

AIX 5.3 TL12 SP04 + WAS6 == Oops...

Na jó.. Nem kernel Oops, de attól még fájó élmény a WAS-nak (Web's Fear Application Server az én olvasatomban). A helyzet ugyan is az, hogy AIX 5.3 TL12 SP04, illetve AIX 6.1 TL06 SP4 alatt a WAS6 által használt 1.4.2-es JRE nem érzi annyira jól magát, és a garbage collector hajlamos lockokba kergetni magát, ami aztán lassan a WAS halálát eredményezi.

Angolul tudóknak íme a 6.1es AIX-hoz kiadott tájékoztató: https://www-304.ibm.com/support/docview.wss?uid=swg21514823
# Note - az eredeti tájékoztató hibás, és az 5.3 alatt is totál ugyan ez a hiba jön elő
Abstract: WebSphere Application Server (WAS) is hanging after running successfully for a while. The problem happens intermittently, and there is no particular pattern that triggers this behavior.

Symptom: After starting and running successfully for a while, the WebSphere Application Server hangs. When this hang occurs, WebSphere Application Server becomes unresponsive and needs to be killed and restarted.

Cause: This is not a software problem with Information Server or WebSphere Application Server. A defect was introduced within the AIX operating system fix for APAR IZ93027 which causes WebSphere Application Server 6.0.2 to hang intermittently. This APAR is included in the TL06, SP04 package for AIX 6.1, so the issue appears after upgrading AIX to this technology and service pack level.

Resolving the problem : The issue can be solved immediately by downgrading AIX 6.1 to TL06, SP03. This downgrade is accomplished by reinstallation of service pack 3 (SP03). For assistance in performing the downgrade, or for requesting patch availability, please open a service request with IBM Technical support for the AIX operating system.

A hibára nyitották a IV07564-es APAR-t. A probléma jelenleg vele csupán annyi, hogy még nincs kiadva a javítás 5.3 alá (6.1 alatt a TL06 SP05 már tartalmazza a javítást), azt majd a TL12 Sp05-ben tervezik mellékelni.. Addig is az alábbi oldalon fel lehet iratkozni a SPAM listára, ha esetleg valaki tudni szeretné mikor is lehetne uprgade-elni szeretett AIX-ét (Note: IBM ID kell hozzá):
https://www-304.ibm.com/support/entdocview.wss?uid=isg1IV07564