Στο προηγούμενο μου post παρουσίασα την διαδικασία υλοποίησης των AlwaysOn Availability Groups στον SQL Server 2012.
Σε αυτό θα απαντήσω στις διάφορες ερωτήσεις που συχνά μου γίνονται κάθε φορά που παρουσιάζω το θέμα αυτό. Ερωτήσεις που συνήθως έχουν σχέση με το database mirroring. Χαρακτηριστική είναι η παρακάτω ερώτηση που πρόσφατα μου τέθηκε από μια συνάδελφο.
«Ποιο θεωρείς ότι είναι το μεγαλύτερο ατού των AlwaysOn Availability Groups; Για μένα ήταν οι πολλαπλές replicas και το ότι μπορείς να τρέχεις OLTP jobs στην primary και reporting στις secondaries. Μετά όμως άρχισα να καταλαβαίνω ότι αυτό μπορούσες να το υλοποιήσεις και πριν τον 2012 με το database mirroring και manual configuration του backup ή reporting στους secondaries. Άρα; Υπάρχει κάποιο αυτόματο brokering ή απλά γλυτώνει ο administrator άπειρο χρόνο σε ρυθμίσεις και στο να είναι σίγουρος ότι αυτό που έστησε δουλεύει;»
Ξεκινώντας θα πρέπει να γίνει ξεκάθαρα κατανοητό ότι τα AlwaysOn Availability Groups είναι η εξέλιξη του database mirroring με πολλές βελτιώσεις, αλλά με την σημαντική διαφορά ότι πλέον μπορώ να έχω πολλές databases μαζί στο ίδιο availability group και όχι 1:1 όπως στο απλό database mirroring. Ιδιαίτερα σημαντικό στοιχείο για εφαρμογές που έχουν παραπάνω από μια databases ή ακόμα και για servers όπως ο SharePoint Server που έχει περισσότερες από μια databases. Γιατί κακά τα ψέματα άλλο είναι να πηγαίνουν όλες μαζί στο επόμενο διαθέσιμο node και άλλο είναι κάποιες να είναι στο Α node και κάποιες στο Β. Δηλαδή είναι πολύ καλύτερα να έχεις ένα failover για όλες μαζί παρά να έχεις failover ανά mirror session.
Στο σημείο αυτό θα πρέπει να επισημανθεί ο πληρέστερος έλεγχος στο automatic failover μέσω των policies και conditions που μπορώ να δημιουργήσω.
Και μιας και αναφέρθηκε το automatic failover θα πρέπει να τονιστεί ότι πλέον δεν υπάρχει η ανάγκη του witness server καθώς πλέον υπάρχει το Windows Server Failover Cluster (WSFC) quorum που παίζει το ρόλο αυτό με περισσότερη επιτυχία και το σημαντικότερο με διαδικασίες που είναι γνωστές και δοκιμασμένες από το παρελθόν. Επίσης όλη αυτή η υποδομή προσφέρει ένα ενοποιημένο ΗΑ Management στο εκάστοτε DBA με συνέπεια να έχει αυτός καλύτερο έλεγχο.
Πέρα όμως από το έλεγχο και τις ευκολίες εγκατάστασης σημαντικό ρόλο παίζει και η απόδοση και εδώ θα πρέπει να ληφθεί υπόψη ότι τα δεδομένα που στέλνονται είναι by default compressed, άρα μικρότερο stream στο καλώδιο.
Αλλά και η ασφάλεια δεν είναι κάτι που έχει παραγκωνιστεί by default τα δεδομένα που στέλνονται είναι encrypted.
Όπως αναφέρθηκε παραπάνω το στοιχείο που τα AG υπερτερούν σε σχέση με το database mirroring είναι έχω περισσότερες από μια replicas. Για την ακρίβεια μπορώ έκτος από την primary να έχω μέχρι τέσσερεις secondary replicas!.
Κάτι που επίσης είναι δυνατό στοιχείο είναι ότι υπάρχουν πραγματικά readable replicas χωρίς να χρειάζεται να κάνω κάτι περίπλοκο ή επαναλαμβανόμενο για αυτό παρά μόνο να το δηλώσω την στιγμή που ορίζω την replica. Στο database mirroring μπορούσα να έχω κάτι τέτοιο μόνο αν έφτιαχνα database snapshot στη mirror database στο mirror server.
Το γεγονός ότι μπορώ να πραγματοποιώ backups από κάποιο ή κάποια secondaries replicas στα AlwaysOn AG στο SQL Server 2012 είναι κάτι το οποίο δεν υπήρχε/υπάρχει ούτε κατά διάνοια στο database mirroring. Σημαντικό αν σκεφτεί κανείς την αποφόρτιση που θα έχει o primary από task που δεν θα τρέχουν πλέον σε αυτόν.
Εξίσου σημαντική βελτίωση είναι οι availability groups listeners. Αυτοί είναι στην ουσία virtual network names για το εκάστοτε availability group μέσω του οποίου οι εφαρμογές μπορούν συνδεθούν σε αυτό. Για αυτούς που είναι εξομοιωμένοι με clustering αυτό είναι το ίδιο σαν χρησιμοποιείς το cluster name αντί να χρησιμοποιείς ξεχωριστά τα node names. Κάθε listener παρέχει την δυνατότητα για αυτόματο και γρήγορο failover σε περίπτωση βλάβης. Φυσικά αυτό μπορούσε να γίνει και πριν με την εισαγωγή στο connection string της εκάστοτε εφαρμογής του failover partner attribute. Όμως τι θα γίνονταν αν αυτό δεν το έβαζε αυτός που έφτιαχνε το connection string. Και να πάμε ένα βήμα παραπέρα τι μπορούσαμε να κάνουμε στις περιπτώσεις που δεν είχαμε την δυνατότητα να αλλάξουμε το connection string στις εφαρμογές καθώς αυτό ήταν εσωτερικά φυτεμένο και στο οποίο δεν μπορούμε να προσθέσουμε το failover partner attribute; Τίποτα…. Ενώ με το listener απλά αναφέρουμε αυτόν στην θέση του server name και καθαρίσαμε τόσο απλά. Έτσι ακόμα και εφαρμογές παλιές μπορούν πλέον να είναι high available…
Με όλα τα παραπάνω σε καμία περίπτωση δεν απαξιώνω το database mirroring. Ήμουν είμαι και θα είμαι από αυτούς που σθεναρά το υποστηρίζω και πιστεύω ότι ήταν ένα ξεχωριστό και δυνατό χαρακτηριστικό του SQL Server που απλά με τον χρόνο γίνεται καλύτερο. Ποιος είναι αυτός που δεν θέλει κάτι καλό να γίνεται καλύτερο και καλύτερο με την πάροδο του χρόνο και από έκδοση σε έκδοση;
/*antonch*/