Cluster disker på passiv node og WWN på HBA

Ved feilsøking av noen rare clusterproblemer begynte jeg plutselig å lure på hvordan clusterdisker var representert på den passive noden i et Windows 2008 cluster. De var nemlig ikke å se i Disk Management, og forsøk på failover av diskressurser feilet spektakulert og fullstendig. Litt forskning viste kjapt at joda, de skulle vært listet omtrent som dette:

image

Dermed måtte feilen være et annet sted. Litt mer fundering avslørte at vi hadde oppdatert bios og managementprosessor på dette clusteret for kort tid siden, og vi begynte å ane hvor grevlingen var. Av en eller annen grunn hadde ikke serveren fått satt riktig WWN ved omstart. Dette er et IBM HS22 blade med Qlogic HBA som får sine WWN fra managementmodulen, og en rask sjekk i SanSurfer avslørte at WWN ikke stemte overens med det som var definert i SANet. Dermed trengs en kaldstart av managementmodueln i bladet, noe som betyr å slå av serveren, trekke ut bladet, vente et minutt og sette det inn igjen. Deretter må man vente en 5 minutters tid mens IMM booter. Man kan se at den er ferdig ved at powerlyset i front av bladet begynner å blinke med betydelig langsommere takt. Først da vil bladet la seg slå på.

Update: Det har også fungert i enkelte tilfeller å ta en full shutdown av bladet, vente to minutter og så starte det igjen. Det er verdt et forsøk, da man sparer en tur til serverrommet.

Samme situasjon har jeg tidligere opplevd på HP BL460 blade. Disse har vanligvis Emulex-kort som liker å komme opp med blank WWN (00-00-00-…), eller med en WWN som begynner på 1 istedenfor 5. Dette er noe som er litt lettere å oppdage enn et nummer som er tilsynelatende riktig. Løsningen er den samme, ut med bladet for å få kaldstartet managementmodulen.

SNAGHTML109f57a

Dersom feilen oppstår på en helt ny server/nytt HostBusAdapter er det vanligvis firmware på HBA som er utdatert eller på annen måte ikke samsvarer med firmware til bladets managementmodul. Emulex liker å splitte denne i flere deler, en HBA bios og en HBA firmware, pass på at du oppdaterer alle. Og oppdater firmware på bladet samtidig. Det anbefales å bruke firmware fra bladeprodusenten og ikke fra Qlogic/Emulex. Pass også på at du oppdaterer firmwaren til den sentrale managementmodulen på IBM Bladecenter samtidig. Denne kalles AMM. På HP C7000 har man ofte Virtual Connect fibermoduler istedenfor fiberswitcher fra feks Brocade. Rent teknisk er det store forskjeller på AMM og Virtual Connect, men i denne sammenhengen er det viktigste at versjonene stemmer overens.

Bladeservere fusker under/etter oppdatering av UEFI (BIOS)

Det hender at maskiner med UEFI istedenfor BIOS nekter plent å starte opp etter at man har oppdatert UEFI. Det er da viktig å passe på at du har oppdatert management-modulen samtidig (ILO, IMM, DRAC e.l.). Dersom disse ikke er kompatible blir det bare rot. Det samme gjelder forsåvidt de sentrale managementmodulene i chassiet, de må ofte oppdateres samtidig som UEFI for at bladene skal kunne snakke sammen med chassiet. Eksemplene som er nevnt her er stort sett hentet fra IBM Bladecenter H med HS22 blade, men det meste er også opplevd på HP BL460. Flere av løsningene vil med litt fantasi fungere også på HP, eller om ikke ihvertfall peke i retning av en løsning.

Maskinen starter ikke i det hele tatt eller henger på UEFI initialisering

Forsøk disse i rekkefølge til du får respons.

  • Før du begynte burde du ha sjekket at IPv4 innstillingene for eventuelle IBM USB RNDIS nettverkskortet var satt riktig og at dette ikke var deaktivert. Sjekk dette når du får serveren opp igjen for å unngå fremtidige problemer.IBM RNDIS Og så fremt du ikke bruker IPv6, slå dette av på alle nettverkskortene.
  • Slå  av bladet og ta det ut av chassiet. Vent 2 minutt, sett det inn igjen. Vent til On-lampen blinker langsomt(1-5 minutt), og slå på.
  • Vent i minst 10 minutt på at maskinen skal boote.
  • Slå av bladet, ta det ut av chassiet og ta ut biosbatteriet under den blå gummihetten og eventuelle fiberkort. Vent i 2 minutt, sett inn batteriet men ikke eventuelle fiberkort. Sett inn bladet, vent på langsom blink og slå på.
  • Vent i opptil 30 minutt på at maskinen skal boote. Første boot etter batteribortfall eller firmwareoppdatering tar av og til fryktelig lang tid, og så plutselig bare virker den. Etter 30 minutt kan du dog trygt gi opp.
  • Dersom første boot etter batteribortfall feiler, slå av og slå på igjen.
  • Dersom det fortsatt ikke virker, feilmeld til produsenten. Du har da klart å “forsteine” hovedkortet og det må sannsynligvis skiftes.

Maskinen finner ikke boot disk

  • Sjekk at start options er satt riktig i bios:
    Start options
  • Sjekk om du får kontakt med disken ved å boote til en windows server setup cd med samme versjon som er installert på disken. Pass på forskjellen på 64 og 32 bit.
  • Start installasjonen og gå frem til valg av disk. Sjekk at disken står listet der. Avbryt installasjonen, velg repair and recovery, og åpne et kommandoprompt.
  • Start diskpart (den kan bruke noen minutt på å starte opp)
  • Skriv kommandoen “select disk n”, der n er nummeret på den disken som operativsystemet ligger på (Du kan se hvilke du har ved å kjøre list disk)
  • Skriv kommandoen “select volume n”, der n er nummeret på den partisjonen som operativsystemet ligger på (Du kan se hvilke du har ved å kjøre list volume)
  • Skriv kommandoen “online volume”
  • Du kan sjekke om det virker ved å skrive kommandoen “detail volume”
  • Gå ut av diskpart ved å skrive “exit”image
  • Kjør disksjekk på C: (“chkdsk c: /F”) og vent til den er ferdig
  • Restart server.

Maskinen krasjer etter oppdatering, BSOD (HS22)

Under gitte forutsetninger kan man ende opp med et ustabilt system etter oppdatering, der maskinen går en stund for så å gå i blåskjerm. En analyse av minidump ga meg følgende:

BUGCHECK_STR:  0x124_GenuineIntel
 
CUSTOMER_CRASH_COUNT:  1
 
DEFAULT_BUCKET_ID:  DRIVER_FAULT_SERVER_MINIDUMP
 
PROCESS_NAME:  System
 
CURRENT_IRQL:  f
 
STACK_TEXT:
fffffa60`01b91958 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
 
STACK_COMMAND:  kb
 
FOLLOWUP_NAME:  MachineOwner
 
MODULE_NAME: hardware
 
IMAGE_NAME:  hardware
 
DEBUG_FLR_IMAGE_TIMESTAMP:  0
 
FAILURE_BUCKET_ID:  X64_0x124_GenuineIntel__UNKNOWN
 
BUCKET_ID:  X64_0x124_GenuineIntel__UNKNOWN
 
Followup: MachineOwner

Dette gjentok seg en par tre ganger i løpet av 12 timer, så jeg feilmeldte. De hyggelige folkene hos IBM kunne da fortelle meg at jo, dette var en kjent feil. Det har seg nemlig sånn at dersom man hadde rett type ekspansjonskort installert i serveren så må man endre en av standardinnstillingene i BIOS. Mer spesifikt må man endre System Settings –> Devices and I/O Ports –> PCIe Gen1/Gen2 Speed Selection fra Gen2 til Gen1.

image

Tilleggskort som fører til denne feilen per 2010.11.12:

Broadcom 10 Gb 2-port Ethernet Expansion Card (CFFh) for
IBM BladeCenter, Option 44W4466, FRU 44W4469
Broadcom 10 Gb 4-port Ethernet Expansion Card (CFFh) for
IBM BladeCenter, Option 44W4465, FRU 44W4472
Emulex 8 Gb Fibre Channel Expansion Card (CIOv) for IBM
BladeCenter, Option 46M6140, FRU 46M6138
NetXen 10 Gb Ethernet Expansion Card (CFFh), Option
39Y9271, FRU 39Y9269
QLogic 2-port 10 Gb Converged Network Adapter (CFFh) for
IBM BladeCenter, Option 42C1830, FRU 42C1832
QLogic 4 Gb Fibre Channel Expansion Card (CIOv) for IBM
BladeCenter, Option 46M6065, FRU 46M6068
QLogic 8 Gb Fibre Channel Expansion Card (CIOv) for IBM
BladeCenter, Option 44X1945, FRU 44X1948
QLogic Ethernet and 4 Gb Fibre Channel Expansion Card
(CFFh) for IBM BladeCenter, Option 39Y9306, FRU 39Y9304
QLogic Ethernet and 8 Gb Fibre Channel Expansion Card
(CFFh) for IBM BladeCenter, Option 44X1940, FRU 44X1943
SAS Connectivity Card (CIOv) for IBM BladeCenter, Option
43W4068, FRU 46C4069
ServeRAID-MR10ie (CIOv) Controller for IBM BladeCenter,
Option 46C7167, CRU 46C7171