Patching σε ένα CloudStack cloud ενώ τα instances των tenants συνεχίζουν να τρέχουν

Όταν μια ανακοίνωση ασφαλείας αφορά την πλατφόρμα που τρέχει τους servers άλλων ανθρώπων, υπάρχουν δύο κακά ένστικτα. Το ένα είναι να περιμένετε, γιατί το να αγγίξετε το cloud μοιάζει πιο επικίνδυνο από την ευπάθεια. Το άλλο είναι να αναβαθμίσετε τα πάντα μαζί και να ελπίζετε. Το Apache CloudStack ανταμείβει μια τρίτη προσέγγιση: κατανοήστε τα επίπεδά του, ενημερώστε τα με τη σωστή σειρά, και αφήστε τα στοιχεία να αποφασίσουν ποια βήματα αγγίζουν πραγματικά τους tenants.

Ένα cloud είναι πολλά πράγματα προς patching, όχι ένα

Μια εγκατάσταση CloudStack είναι ένα stack συστατικών με διαφορετική ακτίνα επίπτωσης:

• Οι management servers και η βάση δεδομένων τους. Το control plane: portal, API, ενορχήστρωση. Όσο είναι κάτω, οι χρήστες δεν μπορούν να δημιουργήσουν ή να αλλάξουν πόρους, αλλά τα instances που τρέχουν δεν εξαρτώνται από αυτό.
• Οι agents σε κάθε KVM host. Συνδέουν τους hypervisors με τον management server. Η επανεκκίνηση ενός agent δεν σταματά τα instances που ήδη τρέχουν σε αυτόν τον host.
• Τα system VMs. Το secondary storage VM χειρίζεται templates και snapshots, το console proxy σερβίρει κονσόλες στον browser. Η επανεκκίνησή τους διακόπτει για λίγο αυτές τις λειτουργίες, όχι τους φόρτους εργασίας των tenants.
• Οι virtual routers. Αυτοί κάθονται στη διαδρομή δεδομένων των δικτύων των tenants, παρέχοντας DHCP, DNS, NAT, firewalling και load balancing. Η επανεκκίνηση ενός διακόπτει για μια στιγμή τις υπηρεσίες αυτού του δικτύου.

Η σειρά της δουλειάς προκύπτει από αυτή τη λίστα: πρώτα τα μέρη που οι tenants δεν νιώθουν ποτέ, τελευταία τα μέρη που μπορεί να νιώσουν, και τα τελευταία μόνο όταν υπάρχει πραγματικός λόγος.

Βήμα ένα: διαβάστε την ανακοίνωση σε σχέση με τη δική σας διαμόρφωση

Οι περισσότερες ανακοινώσεις αφορούν ένα συγκεκριμένο χαρακτηριστικό, συχνά προαιρετικό. Πριν σχεδιάσετε παράθυρο, μάθετε αν το επηρεαζόμενο χαρακτηριστικό είναι ενεργοποιημένο στο cloud σας. Οι global settings είναι ορατές μέσω του API, για παράδειγμα με το CloudMonkey:

cmk list configurations name=<setting from the advisory>
cmk list zones
cmk list hosts type=Routing

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

Βήμα δύο: πάρτε backup ό,τι θα χρειαζόσασταν για να γυρίσετε πίσω

Πριν από οποιαδήποτε αλλαγή πακέτων, πάρτε ένα συνεπές dump των βάσεων δεδομένων του CloudStack και αντιγράψτε τα αρχεία διαμόρφωσης του management server εκτός μηχανήματος:

mysqldump --single-transaction --routines --triggers cloud > cloud-before-update.sql
mysqldump --single-transaction cloud_usage > cloud_usage-before-update.sql
tar czf cloudstack-etc-before-update.tgz /etc/cloudstack

Κρατήστε τα dumps εκτός του management server.

Βήμα τρία: οι management servers

Μετά την ενημέρωση των πακέτων management, ελέγξτε δύο πράγματα. Και μετά ελέγξτε δύο πράγματα μετά από κάθε ενημέρωση. Πρώτον, ότι η υπηρεσία είναι ενεργοποιημένη να ξεκινά στην εκκίνηση, όπως το θέλετε. Δεύτερον, ότι όντως ολοκλήρωσε την εκκίνησή της, όχι απλώς ότι η διεργασία υπάρχει:

systemctl is-enabled cloudstack-management
systemctl status cloudstack-management
journalctl -u cloudstack-management -f
cmk list capabilities

Περιμένετε το log να δείξει ότι η εκκίνηση ολοκληρώθηκε και το API να απαντά πριν προχωρήσετε. Αν τρέχετε πολλούς management servers πίσω από load balancer, ενημερώστε τους έναν τη φορά ώστε το API να μένει διαθέσιμο σε όλη τη διάρκεια.

Βήμα τέσσερα: agents, έναν host τη φορά, με φρένο

Ενημερώστε το πακέτο agent σε έναν KVM host, επανεκκινήστε τον agent, και περιμένετε μέχρι ο management server να δει αυτόν τον host ξανά Up πριν προχωρήσετε στον επόμενο. Κάντε το script αν έχετε πολλούς hosts, αλλά δώστε στο script ένα φρένο:

for h in $(cat kvm-hosts.txt); do
  ssh "$h" 'dnf -y update cloudstack-agent && systemctl restart cloudstack-agent' || exit 1
  until cmk list hosts name="$h" filter=state | grep -q Up; do sleep 10; done
done

Αν κάποιος host αποτύχει να ενημερωθεί ή να επανασυνδεθεί, ο βρόχος σταματά εκεί, με έναν host προς διερεύνηση αντί για όλο το cloud. Τα instances συνεχίζουν να τρέχουν στους hosts τους σε όλη τη διάρκεια, γιατί ο agent δεν είναι στη διαδρομή τους.

Βήμα πέντε: system VMs, μετά routers με βάση τα στοιχεία

Τα system VMs κουβαλούν scripts και πακέτα από τον management server. Μετά την ενημέρωση, επανεκκινήστε τα ή κάντε τους patch μέσω του API ώστε να πάρουν τον νέο κώδικα, και μετά επιβεβαιώστε ότι επιστρέφουν Running και συνδεδεμένα:

cmk list systemvms

Οι virtual routers αξίζουν περισσότερη σκέψη, γιατί κάθονται στην κίνηση των tenants. Η πλατφόρμα μπορεί να σημειώσει routers ως χρήζοντες αναβάθμισης, αλλά αυτή η σημαία μπορεί να τεθεί ενώ ο κώδικας μέσα τους δεν έχει αλλάξει ουσιαστικά. Συγκρίνετε τα scripts που θα λάμβανε ο router μετά την ενημέρωση με αυτά που ήδη τρέχει. Αν ο κώδικας του router δεν άλλαξε, αφήστε τον ήσυχο και γλιτώστε στους tenants σας τη διακοπή. Αν άλλαξε, προγραμματίστε επανεκκινήσεις routers ανά δίκτυο, ενημερώστε τους επηρεαζόμενους tenants, και κάντε τες μία τη φορά.

cmk list routers requiresupgrade=true

Βήμα έξι: αποδείξτε την τελική κατάσταση

Τρέξτε τους ίδιους ελέγχους με το βήμα ένα και συγκρίνετε: κάθε host Up, κάθε system VM Running, κάθε router στην αναμενόμενη κατάστασή του, η ρύθμιση της ανακοίνωσης εκεί που τη θέλετε, και ένα δοκιμαστικό instance δημιουργημένο, εκκινημένο και καταστραμμένο μέσω του API. Μετά σημειώστε τον χρόνο από την πρώτη αλλαγή μέχρι το πράσινο, που σας λέει πόσο μεγάλο πρέπει να είναι το επόμενο παράθυρο.

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

Χτίζουμε Apache CloudStack clouds ανά πελάτη, σύμφωνα με τις προδιαγραφές του πελάτη, σε KVM hosts σε hardware HPE και Dell με enterprise SAN storage από κάτω και την εμπορική υποστήριξη της ShapeBlue πίσω από την πλατφόρμα. Οι ανακοινώσεις ασφαλείας ακολουθούν την παραπάνω διαδικασία. Όταν δημοσιεύτηκε ανακοίνωση για το CloudStack, εφαρμόσαμε τη διόρθωση σε ένα cloud παραγωγής την ίδια εβδομάδα με αυτόν τον τρόπο, και κάθε instance πελάτη που έτρεχε έμεινε up σε όλη τη διάρκεια.

Τα εύσημα εκεί που ανήκουν: η κοινότητα του Apache CloudStack και η ShapeBlue κάνουν τη δύσκολη δουλειά της εύρεσης, διόρθωσης και τεκμηρίωσης αυτών των ζητημάτων. Αν το δικό σας cloud έχει μια ενημέρωση σε αναμονή επειδή η διαδικασία μοιάζει επικίνδυνη, ευχαρίστως να την περπατήσουμε μαζί σας.

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

Related

• /what-we-do/storage-compute/dedicated-cloudstack/
• /what-we-do/storage-compute/private-cloud-olvm/
• /what-we-do/storage-compute/container-platform-openshift/