Με την έλευση του Exchange 2007 SP1 εμφανίστηκε ένα νέο feature γνωστό ως Standby Continuous Replication (SCR). Το SCR αναπτύχθηκε κυρίως για εφαρμογή σε site resilience σενάρια. Το ήδη υπάρχον CCR feature βελτιώθηκε έχοντας πλέον την δυνατότητα να έχει τα Windows failover cluster nodes σε διαφορετικά subnets. Παρόλα αυτά υπήρξε η απαίτηση να αναπτυχθούν multi-site CCR clusters σε μεγάλες εγκαταστάσεις Exchange . Το multi-site CCR cluster είναι η βέλτιστη λύση έαν έχουμε την κατάλληλη υποδομή που το υποστηρίζει . Βέβαια είναι ένας πραγματικός εφιάλτης έαν πάμε να το υλοποιήσουμε σε μια τοπολογία που δεν το υποστηρίζει ( Λέγε με σωστό Planning ).

Η αμέσως επόμενη λογική ερώτηση είναι σε τι λειτουργικό σύστημα είναι το καλύτερο να το βάλω. Φυσικά σε Windows 2008 ή 2008 R2 ( Αναβαθμίστε , αναβαθμίστε , αναβαθμίστε ) .

Μεταξύ των βελτιώσεων του CCR συγκαταλέγεται η υποστήριξη για multi-subnet failover clusters και ταχύτερο log file shipping. Όπως γνωρίζουμε η Exchange Replication Service χρησιμοποιεί SMB για το log file shipping. Στα Windows Server 2008 έχουμε την εμφάνιση του SMB v2, το οποίο βελτιώνει κατά 30-40% την ταχύτητα σε σχέση με το SMB.

Η εγκατάσταση των Windows 2008 Failover Cluster είναι ευκολότερη σε σχέση με αυτή των Windows Server 2003. Επιπλέον είναι γνωστό ότι το in-place upgrade των Windows Server 2003 based Exchange 2007 servers σε Windows Server 2008 θα είναι αδύνατη και θα πρέπει να αντικαταστήσουμε τους υπάρχοντες servers με Windows Server 2008 based Exchange 2007 SP1 servers.

Εάν εγκαθιστούμε multi-site CCR cluster nodes σε Windows Server 2003 τα cluster nodes πρέπει να βρίσκονται στο ίδιο subnet γιατί δεν υπάρχει υποστήριξη εύρεσης cluster nodes σε διαφορετικά subnets. Σε αυτή την περίπτωση πρέπει να αναδιοργανώσουμε τα subnets μας που σημαίνει ότι το broadcast traffic ( heartbeat ) θα γίνεται μέσω WAN μεταξύ των σημείων μας .

Με χρήση Windows Server 2008 η αναδιοργάνωση των subnets εφόσον τα Windows Server 2008 παρέχουν πλήρη υποστήριξη για routed networks. Όπως βλέπουμε έχουμε δυνατότητα να ορίσουμε 2 IP addresses για το Windows Server 2008 Failover Cluster

Μπορούμε να δούμε την δομή μας. Το σχέδιο η τοπολογία εξαρτάται απο την υλοποίηση ( ίδιο ή διαφορετικό subnet ,όνομα , κλπ).

Για την διημιουργία μιας αναφοράς κάνουμε δεξί κλικ στο network name του cluster και επιλέγουμε Dependency Report

Όταν το Windows Server 2008 Failover Cluster έχει διημιουργηθεί και εγκαθιστούμε τον Exchange 2007 Active Mailbox ρόλο, έχουμε την δυνατότητα να ορίσουμε την IP address που θα γίνει assigned στον Clustered Mailbox Server (CMS) σε κάθε subnet.

Αν και μπορούμε να εγκαταστήσουμε τους Active και Passive Mailbox server ρόλους μέσω του Exchange 2007 Setup wizard είναι προτιμότερο να χρησιμοποιήσουμε το command line όταν εγκαθιστούμε έναν νέο CMS ( Ναι δυστυχώς δεν τα κάνει όλα το setup μόνο του ).Η εγκατάσταση γίνεται μέσω της ακόλουθης εντολής:

Setup.com /Mode:install /Roles:mailbox /NewCMS /CMSName:<CMS name> -CMSIPv4Addresses:<IP1>,<IP2>

Και για την εγκατάσταση του Passive Mailbox:

Setup.com /Roles:mailbox

Ώς best practice προτείνονται 4 ή περισσότερες κάρτες δικτύου σε κάθε CCR cluster node. Συνήθως προτιμούνται 5 με την εξής διάταξη:

- 2 κάρτες σε WAN team (μόνο για fault tolerance και χωρίς load balance διότι παρουσιάζουν τυχαία κολήματα ).

- 2 κάρτες για log shipping (log shipping redundancy).

-1 κάρτα ως backup (disabled για cluster use) εφόσον δεν θέλουμε backups μέσω WAN.

Το παραπάνω design μας προσφέρει 3 ανεξάρτητα paths για replication και 3 ανεξάρτητα paths για heartbeat επικοινωνία μεταξύ των cluster nodes.
Καλό θα ήταν επίσης να ονομάσουμε τις κάρτες μας για να μην μπερδευόμαστε όπως φαίνεται παρακάτω.

 

Προσοχή χρειάζεται και το Scalable Networking pack feature ειδικά όταν έχουμε Windows 2003 based Exchange 2007 servers Για περισσότερα στο: http://msexchangeteam.com/archive/2007/07/18/446400.aspx.

Ασχέτως αν χρησιμοποιούμε Windows Server 2003 ή Windows Server 2008 τα CCR cluster nodes πρέπει να βρίσκονται στο ίδιο Active Directory (AD) site.Το πρόβλημα εδώ είναι ότι ενώ τα Windows Server 2008 Failover Clusters υποστηρίζουν nodes διαφορετικών AD sites, ο Exchange δεν μπορεί να τα κάνει locate.

Επειδή τα CCR cluster nodes πρέπει να ανήκουν στο ίδιο AD site τα μηνύματα μεταξύ των χρηστών που έχουν mailbox στον CMS του primary datacenter θεωρητικά μπορούν να αποσταλούν και να ληφθούν απο τους Hub Transport (HT) servers του backup datacenter. Το ίδιο ισχύει και για τα Exchange client requests ( Autodiscover, OWA, EAS, POP3, και IMAP ). Επιπλέον τα DAP/auth requests στους Global Catalog servers (GCs) μπορούν να εξυπηρετηθούν απο το backup datacenter. Αυτό έχει ως αποτέλεσμα τεράστιο traffic λόγω της MAPI over RPC επικοινωνίας .

Αυτό βέβαια μπορεί να ελεγχθεί μέσω της εντολής Set-MailboxServer cmdlet μαζί με την παράμετρο -SubmissionServerOverrideList που καθορίζει ποιοί Hub Transport servers θα χρησιμοποιούνται.Σε περίπτωση disaster απλά κάνουμε update την submission override list

Για να μπλοκάρουμε τα CAS server requests/connections εκμεταλευόμαστε τους load balancing μηχανισμούς . Σε μεγάλα περιβάλλοντα όπου θα έχουμε υλοποιήσει hardware based ή WNLB based λύση τα βήματα που ακολουθούμε είναι τα εξής:

• Διημιουργούμε ένα NLB array με όλους τους CAS servers του primary datacenter.
• Ρυθμίζουμε την internal URL για Autodiscover, OWA, OAB, EWS και UM να δείχνει στο FQDN όνομα (namespace.company.com) του load balancing solution.
• Κάνουμε ένα δεύτερο NLB array για τους CAS servers του backup datacenter, uχρησιμοποιούμε το ίδιο FQDN αλλά διαφορετική IP address απο την πρώτη και προσέχουμε να υπάρχουν μοναδικές εγγραφές στον DNS
• Για τους GCs, ρυθμίζουμε τους Outlook clients να χρησιμοποιούν GCs στο primary datacenter. Using two Active Directory Sites in the Backup Datacenter

Για να αποφύγουμε οι servers και clients του primary datacenter να επικοινωνούν με τους Exchange 2007 servers και GCs του backup datacenter, μπορούμε να διημιουργήσουμε ένα επιπλέον AD site στο backup datacenter και να μετακινήσουμε όλους τους servers εκτός των Windows Failover Cluster στον οποίο έχουμε τον Mailbox role.

Σε περίπτωση disaster στο the primary datacenter αυτό που πρέπει να γίνει είναι η μετακίνηση των servers απο το δεύτερο AD site στο πρώτο AD site με αλλαγές IP address ή με αλλαγή των AD site definitions στο Active Directory Sites and Services. Εδώ να σημειώσουμε ότι η απλή μετακίνηση του CMS στο δεύτερο AD site δεν θα επιτρέπει στον HT server το re-submit των μηνυμάτων στον CMS πράγμα που θα επιφέρει data loss.

Προσοχή χρειάζεται επίσης στην διατήρηση του network latencyσε επίπεδα κάτω των 500 milliseconds (ms).Τα default tolerance settings για τα missed cluster heartbeats είναι ρυθμισμένα στον αριθμό 5 missed heartbeats για τα nodes ίδιου subnet ή διαφορετικού subnets.Σε περίπτωση multi-site clusters προτείνεται αλλαγή σε 10 missed heartbeats (περίπου 12 seconds).

Για την αλλαγή του CrossSubnetThreshold threshold εκτελούμε την παρακάτω εντολή:

cluster ClusterName /prop CrossSubnetThreshold=10

Μπορούμε να επιβεβαιώσουμε την παραπάνω εντολή με το :

Cluster.exe /cluster:<ClusterName> /prop

 

Όταν συμβαίνει μετακίνηση του CMS από ένα cluster node σε ένα άλλο cluster node και η IP address και το network resource name επανέλθουν online , το failover cluster ξεκινάει έναν timer. Μετά από 10 minutes αποστέλεται ένα DNS.

Από default το DNS Time to Live (TTL) value για το network name resource είναι 20 λεπτά .Αυτό σημαίνει ότι θα χρειαστεί αρκετός χρόνος για το update όλων των domain controllers όπως και για την resolver cache των Outlook clients.

Το best practice είναι η αλλαγή του DNS TTL value στα 5 λεπτά. Για να το κάνουμε αυτό πρέπει πρώτα να βρούμε το CMS cluster network name resource. Αυτό γίνεται μέσω της εντολής:

cluster /cluster:<Name of CMS> res

Τώρα μπορούμε να αλλάξουμε το TTL σε 5 λεπτά:

Cluster.exe res <CMSNetworkNameResource> /priv HostRecordTTL=300

Ακολουθεί επανεκίνηση του Clustered Mailbox Server (CMS) μέσω των εντολών Stop-ClusteredMailboxServer και Start-ClusteredMailboxServer .Να σημειώσουμε ότι η αλλαγή του DNS TTL μέσω των ιδιοτήτων του DNS record δεν είναι δυνατή καθώς η ρύθμιση θα γίνει overwrite απο την τιμή που είναι ρυθμισμένη για το HostRecordTTL κάθε φορά που ο CMS ξεκινάει,μετακινείται ή επανέρχεται online.

Για την επιβεβαίωση της αλλαγής του TTL για το DNS record ανοίγουμε τις ιδιότητες του CMS cluster network name resource DNS record στον DNS Manager.

Σε περίπτωση disaster στο primary datacenter όλοι οι servers θα είναι unavailable και όλα τα messages θα κρατηθούν στα transport dumpster των Hub Transport servers, χωρίς να μπορούν να γίνουν re-submitted στον CMS μετά το failover στον passive cluster node του backup datacenter. Βέβαια είναι δυνατόν να μετακινήσουμε το queue ενός HT server σε έναν HT server στο backup datacenter και να επιτύχουμε έτσι το re-submittion του queue. Αυτό βέβαια πρέπει να γίνει πριν το cluster δώσει την εντολή για το transport dumpster flush.

Ένα CCR based cluster χρησιμοποιεί το Node majority με File Share Witness (FSW) quorum μοντέλο. Σε αυτό τον τύπο του quorum , δύο nodes δεν είναι αρκετά σε περίπτωση failure ενός cluster node. Για να καταστεί αυτό δυνατό πρέπει να υπάρχουν τουλάχιστον 3 devices που να μπορούν να θεωρηθούν διαθέσιμες. Ο FSW λειτουργεί ως η 3η διαθέσιμη device σε ένα two-node Node majority με File Share Witness (FSW) quorum cluster. Επίσης ο FSW προστατεύει ενάντια στο cluster “split brain” syndrome και σε ένα πρόβλημα γνωστό ως “partition in time”.Η χρήση Hub Transport server ως FSW αποτελεί best practice όταν υιοθετούμε το παραπάνω μοντέλο.

Η χρήση CNAME record για υπόδειξη του FSW απλοποιοιέι τα πράγματα σε περίπτωση ανάγκης υπόδειξης 2ου FSW. Το μόνο που χρειάζεται είναι να προυπάρχει ένα pre-created FSW folder και μια ενημέρωση του CNAME record.Σήμερα μπορούμε να χρησιμοποιήσουμε το Cluster service’s built-in “force quorum”.

Σε περίπτωση disaster το failover δεν θα γίνει αυτόματα γιατί χρειάζονται 2 votes σε ένα MNS based cluster. Για να ενεργοποιήσουμε τα cluster resources online στον passive node, πρώτα διημιουργούμε ένα νέο FSW share στον HT server του backup datacenter ακολουθώντας αυτές τις οδηγίες, και μετά με την εντολή :

NET START CLUSSVC /forcequorum

ενεργοποιούμε την cluster service.Ανοίγωντας την Failover Cluster console και επιλέγοντας το cluster name επιλέγουμε Configure Cluster Quorum Settings .

Στα Windows 2003 το /forcequorum switch έχει έναν maintenance mode switch. Στα Windows Server 2008 η παραπάνω εντολή λέει στο cluster ότι το configuration σε αυτό το node είναι το master. Όταν το failed node επανέρθει θα κάνει replicate το configuration information απο αυτό το node.

Πατάμε Next.

Επιλέγουμε Node and File Share Majority (για clusters με ειδικό configurations) και πατάμε Next.

Πατάμε Browse και βάζουμε το όνομα του HT server που βρίσκεται το FSW share. Επιλέγουμε Show Shared Folders και διαλέγουμε το FSW share. Πατάμε OK.

Next - Next – Finish .

Όταν επανέλθει το primary datacenter διημιουργούμε ένα νέο FSW share στον παλιό HT server που είχε το FSW share και κάνουμε point το cluster σε αυτό το FSW share.

Όταν όλοι οι servers έρθουν online στο primary datacenter, μπορούμε να μεταφέρουμε τον CMS πίσω στο primary datacenter.Δυστυχώς όμως δεν υποστηρίζεται ο συνδυασμός FSW με DFS.