Πώς διαβάζετε το multipath state σε έναν Linux host

Αν ο server σας κρατά τα δεδομένα του σε SAN, η σημαντικότερη αναφορά υγείας στο μηχάνημα έρχεται από μια εντολή που οι περισσότεροι δεν τρέχουν ποτέ. Το multipath -ll σάς λέει πόσοι δρόμοι οδηγούν στον δίσκο σας, ποιους από αυτούς προτιμά η συστοιχία, και αν ο host θα επιβίωνε αν έχανε έναν. Έτσι το διαβάζετε, και τι αλλάζετε όταν δεν φαίνεται σωστό.

Πλεονασμός που δεν μπορείτε να δείτε δεν είναι πλεονασμός

Όταν ένα path πεθαίνει αθόρυβα, κανείς δεν το προσέχει. Ο host συνεχίζει να τρέχει με ό,τι απέμεινε, και το πρώτο σημάδι προβλήματος είναι η μέρα που φεύγει και το δεύτερο path και το volume εξαφανίζεται κάτω από μια βάση δεδομένων. Ένας server που παραδόθηκε με τη συσκευή multipath προσαρτημένη και δεν ξανακοιτάχτηκε ποτέ έχει πλεονασμό μόνο στα χαρτιά. Ο έλεγχος παίρνει τριάντα δευτερόλεπτα και πρέπει να είναι μέρος κάθε build, κάθε συντήρησης και κάθε ανασκόπησης περιστατικού.

Διαβάζοντας την έξοδο, γραμμή προς γραμμή

Ένα γενικό παράδειγμα από host με δύο θύρες HBA και δύο θύρες συστοιχίας με zoning ανά fabric:

mpatha (360002ac000000000000000000000abcd) dm-2 3PARdata,VV
size=50G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
`-+- policy='service-time 0' prio=50 status=active
  |- 1:0:0:1 sdb 8:16 active ready running
  |- 1:0:1:1 sdc 8:32 active ready running
  |- 2:0:0:1 sdd 8:48 active ready running
  `- 2:0:1:1 sde 8:64 active ready running

Η πρώτη γραμμή δίνει το φιλικό όνομα, το WWID και τις συμβολοσειρές vendor και product. Το WWID είναι η ταυτότητα του volume όπως την αναφέρει η συστοιχία. Αν χρειαστεί ποτέ να αποδείξετε ποιο volume της συστοιχίας είναι ποια συσκευή Linux, συγκρίνετε αυτή τη συμβολοσειρά με τη λίστα volumes της ίδιας της συστοιχίας, ποτέ με γράμμα συσκευής, γιατί τα γράμματα συσκευών αλλάζουν μεταξύ εκκινήσεων.

Η δεύτερη γραμμή κρατά τις ρυθμίσεις που καθορίζουν τη συμπεριφορά σε αποτυχία. Το queue_if_no_path σημαίνει ότι αν χαθούν όλα τα paths, το I/O περιμένει αντί να αποτύχει. Το hwhandler='1 alua' σημαίνει ότι η συστοιχία μιλά ALUA, τον πρότυπο τρόπο με τον οποίο μια συστοιχία λέει στον host ποιες θύρες προτιμώνται.

Η γραμμή του path group δείχνει την πολιτική επιλογής και την προτεραιότητα. Μια συμμετρική active/active συστοιχία σαν την παραπάνω βάζει κάθε path σε ένα group με ίση προτεραιότητα. Μια ασύμμετρη συστοιχία δείχνει δύο groups: ένα group υψηλότερης προτεραιότητας με optimized paths σημειωμένα active, και ένα group χαμηλότερης προτεραιότητας σημειωμένο enabled που μεταφέρει I/O μόνο αν αποτύχει το πρώτο. Και οι δύο διατάξεις είναι υγιείς. Αυτό που μετράει είναι η διάταξη να ταιριάζει με όσα τεκμηριώνει ο κατασκευαστής της συστοιχίας σας για τον τύπο host σας.

Κάθε γραμμή path διαβάζεται host:channel:target:lun, μετά η συσκευή, μετά τρεις καταστάσεις. Ο πρώτος αριθμός είναι ο SCSI host, που σε server Fibre Channel σημαίνει τη θύρα HBA. Κάθε volume πρέπει να δείχνει paths και από τους δύο αριθμούς θυρών HBA. Αν κάθε path ενός volume μοιράζεται τον ίδιο αριθμό host, το volume είναι προσβάσιμο μόνο μέσω ενός fabric, ό,τι κι αν λέει το διάγραμμα καλωδίωσης. Οι τρεις καταστάσεις είναι η κατάσταση του device-mapper (active ή failed), το αποτέλεσμα του path checker (ready, faulty, ghost) και η άποψη του kernel για τη συσκευή (running ή offline).

Ένας υγιής host, ως λίστα ελέγχου

• Κάθε volume δείχνει τον ίδιο αριθμό paths, και ο αριθμός ισούται με θύρες HBA επί θύρες συστοιχίας με zoning ανά fabric.
• Κάθε volume έχει paths και από τους δύο αριθμούς host των HBA.
• Κανένα path δεν είναι failed, faulty, offline ή shaky.
• Η συμβολοσειρά vendor, ο hardware handler και οι προτεραιότητες ταιριάζουν με τον οδηγό host του κατασκευαστή της συστοιχίας, και ο host είναι καταχωρημένος στη συστοιχία με το αντίστοιχο host persona ή host type.
• Η συμπεριφορά όταν χαθούν όλα τα paths (no_path_retry) επιλέχθηκε συνειδητά, δεν κληρονομήθηκε.
• Το LVM χρησιμοποιεί μόνο τις συσκευές multipath, ποτέ τα υποκείμενα paths sd.

Αυτές οι εντολές σάς δίνουν όλη την εικόνα:

multipath -ll
multipathd show paths
multipathd show maps status
cat /sys/class/fc_host/host*/port_state
cat /sys/class/fc_host/host*/port_name

Για να μετρήσετε τα ζωντανά paths ανά volume με μία κίνηση:

multipath -ll | awk '/ dm-/{m=$1} /active ready/{c[m]++} END{for (k in c) print k, c[k]}'

Τρέξτε το μετά από κάθε αλλαγή zoning, κάθε αλλαγή στη συστοιχία και κάθε επανεκκίνηση. Ένα πλήθος που διαφέρει μεταξύ volumes αξίζει να το κυνηγήσετε σήμερα.

Οι ρυθμίσεις που μετρούν περισσότερο

Οι περισσότερες διανομές έρχονται με έναν λογικό ενσωματωμένο πίνακα προεπιλογών ανά συστοιχία, αλλά ο οδηγός host του κατασκευαστή της συστοιχίας είναι η αυθεντία. Μια τυπική ενότητα device μοιάζει έτσι:

defaults {
    user_friendly_names yes
    find_multipaths yes
}
devices {
    device {
        vendor               "3PARdata"
        product              "VV"
        path_grouping_policy group_by_prio
        prio                 alua
        hardware_handler     "1 alua"
        path_checker         tur
        failback             immediate
        no_path_retry        18
    }
}

Η μία τιμή που αξίζει να σκεφτείτε μόνοι σας είναι το no_path_retry. Το queueing για λίγο επιτρέπει σε έναν host να περάσει ένα failover controller ή μια επανεκκίνηση fabric χωρίς να φτάσει σφάλμα I/O στην εφαρμογή. Το queueing για πάντα μπορεί να παγώσει έναν host βάσης δεδομένων με τρόπο που ανακάμπτει δυσκολότερα από μια καθαρή αποτυχία. Διαλέξτε έναν αριθμό επαναλήψεων που καλύπτει τον τεκμηριωμένο χρόνο failover της συστοιχίας σας με περιθώριο, γράψτε γιατί, και εφαρμόστε τον σε κάθε host αυτού του τύπου.

Το άλλο κλασικό πρόβλημα είναι το LVM να σαρώνει τα raw paths και να παραπονιέται για διπλά physical volumes. Σε σύγχρονα συστήματα η λίστα συσκευών (lvmdevices) ή ένα φίλτρο στο lvm.conf που δέχεται μόνο συσκευές /dev/mapper το τακτοποιεί. Οι προειδοποιήσεις για διπλά PV δεν είναι κοσμητικές: σημαίνουν ότι το LVM μπορεί να ανοίξει ένα μόνο path αντί για τη συσκευή multipath, και τότε δεν είναι πια προστατευμένο.

Αποδείξτε το failover πριν το χρειαστείτε

Ένα path που δεν έκανε ποτέ failover είναι μια θεωρία. Πριν ένας host αναλάβει παραγωγή, αφαιρέστε ένα path και παρακολουθήστε:

# terminal 1: keep reading from the volume
dd if=/dev/mapper/mpatha of=/dev/null bs=1M iflag=direct status=progress

# terminal 2: take one path offline, watch, then bring it back
echo offline > /sys/block/sdb/device/state
multipathd show paths
echo running > /sys/block/sdb/device/state
journalctl -k -f

Η ανάγνωση στο πρώτο terminal πρέπει να συνεχίσει χωρίς να σταματήσει για πάνω από μια στιγμή. Όταν το path επιστρέψει, το multipathd show paths πρέπει να το επαναφέρει σε active ready. Μετά κάντε τη μεγαλύτερη δοκιμή που μετράει: απενεργοποιήστε τη θύρα του host στο ένα fabric από το switch, επιβεβαιώστε ότι το volume τρέχει μόνο με το άλλο fabric, επαναφέρετέ την, επιβεβαιώστε ότι κάθε path επιστρέφει, και επαναλάβετε για το δεύτερο fabric. Αν κάποιο βήμα σάς εκπλήξει, βρήκατε το πρόβλημα ένα ήσυχο απόγευμα αντί για τη διάρκεια μιας διακοπής.

Πώς το κάνουμε εμείς

Στην πλατφόρμα μας κάθε host με σύνδεση SAN, hypervisor ή dedicated server, παίρνει μία θύρα HBA σε καθένα από δύο ανεξάρτητα Fibre Channel fabrics και καταχωρείται στις all-flash συστοιχίες HPE 3PAR μας με το persona που κάνει το ALUA να συμπεριφέρεται ακριβώς όπως περιμένει το λειτουργικό του σύστημα. Όταν μετακινούμε ένα ζωντανό volume μεταξύ συστοιχιών, ο host κάνει rescan, βλέπει τα νέα του paths και συνεχίζει, και το πλήθος των paths είναι η απόδειξη ότι η μετακίνηση ολοκληρώθηκε.

Αν η έξοδος του multipath σας δεν μοιάζει με το υγιές παράδειγμα παραπάνω, ή δεν είστε σίγουροι πώς θα έπρεπε να μοιάζει η δική σας, ευχαρίστως να τη διαβάσουμε μαζί σας.

cta: Μιλήστε με έναν μηχανικό

Related

• /what-we-do/storage-compute/enterprise-san-storage/
• /what-we-do/storage-compute/fibre-channel-fabrics/
• /what-we-do/storage-compute/bare-metal-servers/