Xylos brands

Hoe vind ik FC-opslagpaden terug in Linux?

We weten allemaal wel hoe belangrijk het is om je firmwareniveaus goed te ondersteunen, zeker als het om bedrijfskritieke primaire opslag gaat. Maar hoe krijg je dat precies voor elkaar? In deze blog leggen we je een handige tip uit voor Linux.

De context

Bij Xylos raden we aan dat je je firmware minstens een keer per jaar patcht, zodat alle firmware van je hardware naar de nieuwste stabiele release of het recentste HPE SPP-pakket wordt geüpdatet. Tijdens een van die patchrondes moest HPE de 3PAR-opstelling van een van onze klanten upgraden. Dit gebeurde zonder downtime, want elke opstelling bestond uit twee controllers en elke host beschikte over redundante paden naar beide controllers. Wanneer één controller in zo’n systeem wordt heropgestart, herstellen de hosts automatisch het verloren pad en verloopt alles weer normaal. Voor de Windows- en ESXI-hosts verliep alles vlekkeloos, maar bij de fysieke Linux-servers moest er manueel worden ingegrepen om de paden naar de heropgestarte controller terug te vinden.

Het probleem

Tijdens de 3PAR-upgrade verloren de Linux-servers hun pad naar de heropgestarte 3PAR-controller. Dit kwam aan het licht toen 'showhost-pathsum' tijdens de upgrade in de 3PAR CLI werd uitgevoerd. Normaal gezien zouden de hosts in dit voorbeeld twee WWN's, vier poorten en een verbinding naar nodes 0 en 1 moeten bevatten, zoals je in de onderstaande screenshot ziet:

Maar na de eerste node reboot was de helft van de verbindingen verdwenen:

Om te controleren of alle paden nog actief waren in Linux, voerden we de opdracht 'multipath -ll' uit op de SELS-server. Wanneer er vier opslagpaden naar een gegeven opstelling moeten zijn, moet de opdracht hierboven de volgende output genereren:

Voor de probleemoplossing zetten we dit even om in mensentaal:

  • '60002AC0000000000000001300021001' is de volume identifier of de WWN van het volume in je opslagsysteem. Elk geëxporteerd volume heeft een eigen identifier. Met deze informatie zie je dus eenvoudig naar welk volume een pad ontbreekt op de server.
  • 3PARdata,VV’ vertelt je dat het volume op een 3PAR-opslagopstelling staat.
  • Size=2.0T is de grootte van het volume.
  • Daarna komen de functies en hardware handlers:
    • het gebruikte scheduling-algoritme, in dit geval round-robin;
    • of de groep actief is of niet;
    • de prioriteit van de groep;
    • de paden in de groep.
  • Elk pad bevat de volgende informatie:
    • een fysiek adres met de indeling host:bus:target:lun. Bijvoorbeeld: het eerste pad sdi is toegankelijk via hostpoort 0 op bus 0, met doelpoort 3 en lun-ID 12;
    • de nodenaam van het apparaat op de server;
    • major: minor-waarden;
    • de apparaatstatus.

Wanneer je een controller in je opslagopstelling moet heropstarten, zoals bij een online firmware-upgrade waarbij beide controllers een voor een worden heropgestart, kan er na dit proces een pad ontbreken. Het is dus erg belangrijk dat je controleert of alle paden actief zijn voordat je verdergaat en de volgende controller of fabric heropstart.

De Linux-oplossing

Om de ontbrekende paden terug te vinden, moet je een Fibre Channel LIP-reset uitvoeren en de hostpoort op de Linux-server opnieuw scannen. Maar voordat je dit doet, moet je weten welke hostpoorten op de server in gebruik zijn.

Met de volgende opdrachten roep je een lijst met beschikbare hostpoorten op:

ls /sys/class/fc_host/

 of

systool -c fc_host

Je ziet dan de volgende informatie:

In dit geval zijn er vier hostpoorten beschikbaar. Dat is logisch: er zijn twee PCIe HBA's op de server geïnstalleerd, elk met twee FC-poorten voor hardware-redundantie. Op elke HBA is slechts één FC-poort actief. De gemakkelijkste manier om te ontdekken welke hostpoorten actief zijn, is door de opdracht 'systool -c fc_host -v host0' voor elke hostpoort uit te voeren. In het onderstaande voorbeeld vragen we informatie op over host0. De waarde die we nodig hebben, is 'port_state'.

Wil je de poortstatus van alle hostpoorten controleren? Dan gebruik je de opdracht ‘systool -c fc_host -A port_state’:

Hier zie je dat de actieve poorten host0 en host4 zijn. De ene is gelinkt aan de top fabric, de andere aan de bottom fabric. Nu kunnen we de LIP-reset uitvoeren en de hostpoorten opnieuw scannen met de volgende opdrachten:

rescan-scsi-bus.sh -i --hosts=0

rescan-scsi-bus.sh -i --hosts=4

Door deze opdrachten een voor een uit te voeren, haal je de verdwenen paden terug. Controleer wel of dit gelukt is voordat je verdergaat met het firmware-upgradeproces.

Is je interesse gewekt? Lees meer over meerdere paden gebruiken en bekijk hier onze datacenter-oplossingen.

Deel dit blogbericht

Laat een antwoord achter

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd.

Breng jouw kennis en skills naar een hoger niveau

Schrijf nu in voor onze nieuwsbrief en krijg maandelijks:

  • Uitnodigingen voor Xylos' events & webinars
  • De laatste blogposts en cases
  • Nieuwste IT-trends