NFS exports και mounts που αποτυγχάνουν με ασφάλεια

Το NFS είναι ένα από τα παλαιότερα εργαλεία στην εργαλειοθήκη ενός διαχειριστή Linux, και ένα από τα ευκολότερα να το κάνετε σχεδόν σωστά. Ένα share που κάνει mount δεν είναι το ίδιο με ένα share που συμπεριφέρεται σωστά όταν το δίκτυο τρεμοπαίξει, όταν ένας client συμπεριφέρεται άσχημα ή όταν ο filer κάνει επανεκκίνηση. Εδώ είναι οι ρυθμίσεις και οι έλεγχοι που κάνουν τη διαφορά, και στις δύο πλευρές του mount.

Γιατί πάνε στραβά τα κοινόχρηστα αρχεία

Ο συνηθισμένος λόγος για NFS είναι μια ομάδα web ή application servers που πρέπει να βλέπουν τα ίδια αρχεία: ανεβασμένα media, παραγόμενα assets, ένα κοινόχρηστο δέντρο εγγράφων. Στήνεται γρήγορα, συχνά αντιγράφοντας ένα παράδειγμα, και δουλεύει με την πρώτη. Τα προβλήματα εμφανίζονται αργότερα. Ένα export ανοιχτό σε ολόκληρο δίκτυο αφήνει ένα ξεχασμένο μηχάνημα δοκιμών να γράφει σε περιεχόμενο παραγωγής. Ένας client με mount options που παρατούν την προσπάθεια στα σφάλματα χάνει εγγραφές σιωπηλά. Ένας server που δεν μπορεί να φτάσει τον filer του στο boot κολλάει για λεπτά αντί να ξεκινήσει χωρίς το share. Τίποτα από αυτά δεν φαίνεται την ημέρα που ρυθμίζεται.

Στον filer: export σε ονόματα, squash του root

Κάντε export κάθε share στους hosts που το χρειάζονται, με όνομα, με τα στενότερα δικαιώματα που δουλεύουν:

# /etc/exports
/export/web   web1.example.internal(rw,sync,root_squash,no_subtree_check) \
              web2.example.internal(rw,sync,root_squash,no_subtree_check)
/export/media media-reader.example.internal(ro,sync,root_squash,no_subtree_check)

Επώνυμοι hosts, όχι δίκτυα. Ένα wildcard ή ένα ολόκληρο subnet σημαίνει ότι κάθε μηχάνημα που θα βρεθεί ποτέ σε αυτό το δίκτυο μπορεί να κάνει mount το share. Η λίστα με hosts κάνει κάθε client μια συνειδητή απόφαση.

root_squash. Ο root σε έναν client γίνεται μη προνομιούχος χρήστης στον filer. Χωρίς αυτό, όποιος έχει root σε οποιονδήποτε client κατέχει κάθε αρχείο του share.

sync. Ο server επιβεβαιώνει μια εγγραφή μόνο αφού έχει γραφτεί σε σταθερή αποθήκευση. Η ταχύτερη εναλλακτική επιβεβαιώνει εγγραφές που μια διακοπή ρεύματος μπορεί ακόμα να σβήσει.

Εφαρμόστε και ελέγξτε τι πραγματικά γίνεται export, που δεν είναι πάντα αυτό που νομίζετε ότι γράψατε:

exportfs -ra
exportfs -v

Μετά περιορίστε την υπηρεσία στο firewall του host στους ίδιους clients. Με το firewalld, μια αποκλειστική ζώνη το κρατά ευανάγνωστο:

firewall-cmd --permanent --new-zone=nfsclients
firewall-cmd --permanent --zone=nfsclients --add-source=<client address>
firewall-cmd --permanent --zone=nfsclients --add-service=nfs
firewall-cmd --reload

Τα exports και οι κανόνες firewall είναι δύο ανεξάρτητες κλειδαριές. Χρησιμοποιήστε και τις δύο.

Στον client: hard mounts που δεν κολλάνε το boot

Η πλευρά του client αποφασίζει τι συμβαίνει όταν ο filer είναι αργός ή για λίγο απρόσιτος:

# /etc/fstab
filer.example.internal:/export/web  /srv/web  nfs  hard,proto=tcp,timeo=600,retrans=2,_netdev,nofail,x-systemd.mount-timeout=30  0 0

hard, όχι soft. Ένα hard mount ξαναπροσπαθεί μέχρι να απαντήσει ο server. Ένα soft mount επιστρέφει σφάλμα μετά από έναν αριθμό προσπαθειών, και πολλές εφαρμογές δεν ελέγχουν αυτό το σφάλμα στην εγγραφή, οπότε δεδομένα μπορεί να χαθούν χωρίς να το μάθει κανείς. Αν ένα share κρατά οτιδήποτε σας ενδιαφέρει, κάντε το mount hard. Το τίμημα είναι ότι μια διεργασία που αγγίζει το share περιμένει όσο λείπει ο filer, που είναι η έντιμη συμπεριφορά.

_netdev και nofail. Το mount περιμένει το δίκτυο, και ένας filer που λείπει δεν εμποδίζει τον server να κάνει boot. Σε συνδυασμό με ένα mount timeout, το μηχάνημα σηκώνεται, η εφαρμογή μπορεί να αναφέρει καθαρά ότι λείπει το share, και το mount ολοκληρώνεται όταν ο filer επιστρέψει.

Καρφώστε το πρωτόκολλο που δοκιμάσατε. Clients και servers διαπραγματεύονται μια έκδοση πρωτοκόλλου. Ορίστε ρητά αυτή που δοκιμάσατε (nfsvers= ή vers=) ώστε μια ενημέρωση σε οποιαδήποτε πλευρά να μην μπορεί να αλλάξει σιωπηλά τη συμπεριφορά locking και caching κάτω από τα πόδια σας.

Ελέγξτε τι πραγματικά διαπραγματεύτηκε, όχι τι ζητήσατε:

nfsstat -m
findmnt -t nfs,nfs4
mountstats /srv/web

Το mountstats δείχνει μετρήσεις ανά λειτουργία, αναμεταδόσεις και χρόνους απόκρισης. Ένας αυξανόμενος αριθμός αναμεταδόσεων είναι η πρώιμη προειδοποίηση ότι η διαδρομή του δικτύου ή ο filer χρειάζεται προσοχή.

Πλεονασμός στο καλώδιο, snapshots στον δίσκο

Ένας filer είναι τόσο διαθέσιμος όσο οι συνδέσεις του δικτύου του. Συνδέστε τον με bonded links σε ένα ζεύγος switches, κάντε hash το bond με βάση διευθύνσεις και πόρτες ώστε και οι δύο συνδέσεις να μεταφέρουν κίνηση, και κρατήστε filer και clients στο ίδιο τμήμα Layer 2 όπου μπορείτε. Μια switched διαδρομή έχει λιγότερα κινούμενα μέρη από μια routed και κρατά την κίνηση αρχείων μέσα στο ιδιωτικό δίκτυο.

Στην πλευρά του storage, ένα filesystem με checksums και snapshots αλλάζει τον τρόπο που χειρίζεστε τα λάθη. Με το ZFS, για παράδειγμα:

zfs snapshot tank/web@before-deploy
zfs list -t snapshot
ls /export/web/.zfs/snapshot/before-deploy/

Ένα snapshot πριν από κάθε deployment ή μαζική αλλαγή κάνει μια κακή αλλαγή αναστρέψιμη σε δευτερόλεπτα, και ένας κρυφός κατάλογος snapshot επιτρέπει σε έναν διαχειριστή να αντιγράψει πίσω ένα μεμονωμένο αρχείο χωρίς εργασία restore.

Πότε ένα file share είναι η λάθος απάντηση

Το NFS είναι εξαιρετικό για περιεχόμενο που γράφεται περιστασιακά και διαβάζεται από πολλούς. Είναι κακό σπίτι για τα αρχεία δεδομένων μιας βάσης, για φόρτους εργασίας που κάνουν έντονο locking μεταξύ clients, ή για εκατομμύρια μικροσκοπικά αρχεία που ξαναγράφονται συνεχώς. Αυτά ανήκουν σε block storage. Όταν μια βιβλιοθήκη ξεπεράσει το file serving, μεταφέρετέ την, μετρήστε και κάντε checksum κάθε αρχείο και στις δύο πλευρές πριν το cutover, και κρατήστε το πρωτότυπο ως rollback μέχρι το νέο αντίγραφο να αποδειχθεί στη χρήση.

Μια σύντομη checklist για τα δικά σας shares

• Το exportfs -v δείχνει μόνο επώνυμους hosts, με root_squash και sync.
• Το firewall επιτρέπει NFS μόνο από αυτούς τους hosts.
• Κάθε mount client είναι hard, με _netdev, nofail και καρφωμένη έκδοση πρωτοκόλλου.
• Το nfsstat -m σε κάθε client δείχνει τις επιλογές που σκοπεύατε.
• Οι αναμεταδόσεις στο mountstats είναι κοντά στο μηδέν και δεν αυξάνονται.
• Ο filer έχει πλεονάζουσες συνδέσεις, και έχετε δοκιμάσει να χάσετε μία.
• Υπάρχουν snapshots, και τα backups τραβιούνται χωριστά.

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

Οι υπηρεσίες αρχείων μας τρέχουν σε ZFS πάνω σε volumes από το all-flash SAN μας, συνδέονται με bonded links σε ζεύγος switches στο ίδιο ιδιωτικό τμήμα με τους clients τους, και ενημερώνονται σε νέο boot environment ώστε το προηγούμενο να παραμένει εκκινήσιμο μέχρι η ενημέρωση να αποδειχθεί.

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

CTA

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

Related

Σχετικά: Υπηρεσίες αρχείων NAS, NFS και SMB · Enterprise SAN storage σε HPE 3PAR, all-flash · Disaster recovery και replicas μεταξύ sites