Non è un segreto che conosco abbastanza bene la soluzione di clustering di database di Oracle. Di recente, ho completato una soluzione di clustering e disponibilità elevata di SQL Server che ha richiesto due anni dalla progettazione iniziale all'implementazione finale. Tale processo ha comportato la documentazione dei requisiti, la determinazione delle opzioni, la mappatura dei requisiti sui dettagli di implementazione, la definizione del budget, l'approvvigionamento, l'installazione, la configurazione e il test.
Ora che il mio progetto è completo, ho pensato di fornire alcuni elementi sul clustering di SQL Server dal punto di vista di un ragazzo Oracle RAC. Sappiamo tutti che SQL Server e Oracle sono entrambi motori RDBMS e potrebbero avere alcune cose in comune. Ma sono anche creature completamente diverse. Quindi, se sei a tuo agio con Grid Infrastructure e RAC e Data Guard di Oracle e stai cercando di implementare una soluzione SQL Server HA, forse questo ti fornirà alcune buone informazioni.
Il nostro attuale sistema di produzione è un database primario Oracle RAC a 4 nodi. Ciò fornisce disponibilità elevata (e prestazioni elevate) all'interno del nostro data center principale. Usiamo Data Guard per trasportare il redo in un database di standby fisico RAC a 3 nodi. Anche se SQL Server <> Oracle, volevo mantenere la nostra configurazione il più simile possibile per semplificare l'amministrazione. Quindi abbiamo distribuito un cluster di failover di SQL Server a 2 nodi nel nostro sito principale e un database "standby" a 1 nodo nel nostro sito di ripristino di emergenza.
Passiamo ora alle mie osservazioni, in ordine sparso.
- La soluzione di clustering HA di SQL Server è attiva/passiva. Oracle è attivo/attivo che per me è "meglio", e sì... è un termine soggettivo. Per la nostra implementazione attiva/passiva, non mi piaceva l'idea di due server fisici seduti lì con uno essenzialmente inattivo per tutto il tempo. Quindi abbiamo un server fisico che è il nodo "preferito" e un server virtuale. Se il server fisico si guasta, il clustering eseguirà automaticamente il failover dell'istanza di SQL Server sul server virtuale e saremo di nuovo operativi. Questo cluster attivo/passivo non fa nulla per affrontare la scalabilità come fa Oracle RAC, ma mi offre una maggiore disponibilità nel nostro ambiente principale.
- L'implementazione del clustering è semplicissimo. Attiva il clustering a livello di sistema operativo. Poiché si tratta di uno stack interamente Microsoft, hanno creato il clustering nel sistema operativo. È già lì per te. Devi solo accenderlo. Quindi avvia Strumenti di amministrazione -> Failover Cluster Manager e le procedure guidate ti guideranno attraverso l'installazione. È molto più semplice dell'installazione dell'infrastruttura di rete. Ma Oracle deve fare i conti con diverse piattaforme OS, il che lo rende più difficile. Sarà interessante vedere come SQL Server 2016 su Linux gestisce il clustering di failover.
- Oracle utilizza un modello di disco condiviso mentre SQL Server non è condiviso. Ma è necessario utilizzare "disco condiviso" in un modo perché il disco deve essere disponibile su entrambi i nodi. Tuttavia, MS Failover Clustering (MSFC) monta il disco in cluster sul nodo attivo. Quando SQL Server viene spostato nell'altro nodo, automaticamente o manualmente, MSFC smonta il disco su un nodo e poi lo monta sull'altro. È un po' strano avere una finestra di Esplora risorse aperta e vedere il disco apparire o scomparire durante questa transizione.
- Grid Infrastructure utilizza il Voting Disk per le operazioni di quorum. In MSFC è possibile avere un disco Quorum, utilizzare una condivisione file o configurare senza quorum. Se scegli quest'ultimo, ostacolerai la tua capacità di failover automatico.
- Sono abituato al fatto che il mio primario abbia il proprio cluster e lo standby il proprio cluster. Con SQL Server, i nodi primari ei nodi di standby devono far parte dello stesso cluster. Per fortuna, il cluster può attraversare le sottoreti che è diverso da Oracle GI. Aggiungere il nodo standby è stato semplicissimo, abbiamo appena rimosso i suoi diritti di voto e non abbiamo configurato il disco quorum per il nodo standby. Per noi andava bene perché vogliamo che il failover in standby sia un'operazione manuale.
- Per un database in standby, puoi utilizzare il mirroring del database, il log shipping o i gruppi di disponibilità AlwaysOn (AG). I primi due stanno per uscire, quindi sono andato con gli AG. Gli AG richiedono che il nodo di standby faccia parte dello stesso cluster del primario. C'è una procedura guidata che ti guiderà attraverso l'impostazione dei database per partecipare all'AG. Questo è molto più semplice che configurare uno standby fisico Oracle.
- Per quelli di voi che odiano la documentazione di Oracle, è tempo di essere grati. Molte volte durante questo processo ho scoperto che nella documentazione MS mancavano pezzi molto grandi. Ad esempio, non ho mai scoperto come configurare il mio nodo di standby in modo che non abbia diritti di voto. Fortunatamente siamo stati in grado di fare clic su di esso.
Alla fine, l'implementazione della soluzione SQL Server non è stata così difficile. A volte dovevo fare affidamento sulla mia conoscenza del clustering. Altre volte, la terminologia di Microsoft si è messa in mezzo. Ad esempio, il resto del mondo lo chiama "cervello diviso", ma la SM lo chiama "cluster diviso". A volte superare le differenze di lessico era l'ostacolo più grande.
