differenze cluster mirroring e alwayson

[Nhio82]

Ciao a tutti, spero di non chiedere troppe cose tutte insieme...ma insomma... mi sto perdendo a leggere svariate cose su internet ma non ne vengo a capo. Vorrei capire in maniera estremamente basica (di sql so qualcosa vicino allo zero) la differenza tra le modalità in oggetto. Ciò che mi pare di aver capito fin ora:

- mirror: introdotto in sql 2005; non c'è bisogno di storage condiviso; 2 attori: c'è un server principale e uno che accetta i dati replicati; in caso di fault il failover è manuale (è una specie di backup incrementale del db); è possibile configurare un failover automatico mettendo un terzo server (witness) che si occupa di fare da "broker" tra il client e il db switchando automaticamente tra il db primario e il replica

- cluster: 2 server che condividono uno storage (quorum) che ospita i log per la sincronizzazione dei db; fa failover automatico senza l'esigenza di un terzo server e non ho ben capito cosa fa in più rispetto al mirror

- alwayson: introdotto in sql 2012 e integra i vantaggi di entrambe le modalità descritte; si possono clusterizzare fino a 4 server; il failover è automatico

Ecco se qualche "anima pia" mi facesse capire bene le differenze perchè non ne vengo a capo

grazie 1000

[Tasslehoff]

Non sono un dba MS SQL, e francamente spero di non aver più a che fare con quel prodotto, però le differenze dovrebbero essere queste.

La prima (mirror) è una semplice replica tra due server (la replica va attentamente monitorata, tipicamente questo genere di configurazioni finiscono a rotoli perchè nessuno la controlla e si scopre di catastrofici disallineamenti solo a seguito di un down del server master), ovvero le istruzioni di insert, update e delete vengono replicate tra il server master e lo slave in modo da avere dati allineati tra i due server.

La seconda è il classico cluster active/passive, ovvero il dbms gira sul nodo attivo, sul quale sono assegnati anche l'indirizzo/i ip su cui sta in ascolto il servizio ed è attestato lo storage che contiene datafile e tranlog.
In caso di down del server attivo avviene il passaggio al secondo server (relocate, che può anche essere lanciato manualmente per manutenzione, pensa ai millemila anacronistici riavvi inutili di Windows per l'installazione di aggiornamenti), lo storage viene montato sul secondo server (generalmente questo implica un meccanismo di sicurezza per evitare che venga montato contemporaneamente dai due causando una corruzione totale dei filesystem e quindi dei dati), l'ip viene assegnato al secondo server e il database viene fatto partire sul secondo server.
Come puoi immaginare le differenza rispetto al mirror sono evidenti, nel primo caso hai due dbms sempre attivi che replicano i dati (e che quindi immagino richiedano due diverse licenze, salvo diavolerie di licensing su cui non so nulla e dalle quali mi tengo a debita distanza), nel secondo hai sempre e solo un dbms attivo e lo switch è totale, nel senso che non può esistere disallineamenti dei dati tra i due visto che i datafile e i tranlog che usano i due nodi del cluster sono gli stessi (chiaramente per funzionare c'è bisogno di storage accessibile da entrambi i server, ad esempio tramite iSCSI oppure SAN).
Non pensare comunque che il relocate sia un meccanismo infallibile, relocate che si incastrano o corruzioni di dati causa mount multiplo dello storage sono un classico intramontabile, diciamo che in generale il cluster active/passive è una soluzione tecnicamente vecchia, delicata e tutt'altro che indolore.

La terza soluzione invece pare essere un cluster vero attivo/attivo, non conosco come sia stata implementata su MS SQL ma a occhio e croce sarà concettualmente simile al RAC Oracle.
Quindi avrai storage condiviso e mediato da un substrato software che permetterà a più nodi di accedere in scrittura ai datafile (Oracle per fare questo usa una feature proprietaria chiamata ASM, Automatic Storage Management) e presumibilmente un bilanciatore delle richieste verso gli N nodi del cluster (oppure definirai dei datasource applicativi che punteranno ai vari nodi).
Non so come funzioni questa nuova feature di MS SQL 2012, deo gratias comunque che finalmente anche loro ci siano arrivati, era imbarazzante questa mancanza visto che Oracle ce l'ha dal 2001 e IBM DB2 dal 2009.

Spero di esserti stato utile.

[Nhio82]

Non sono un dba MS SQL, e francamente spero di non aver più a che fare con quel prodotto, però le differenze dovrebbero essere queste.

La prima (mirror) è una semplice replica tra due server (la replica va attentamente monitorata, tipicamente questo genere di configurazioni finiscono a rotoli perchè nessuno la controlla e si scopre di catastrofici disallineamenti solo a seguito di un down del server master), ovvero le istruzioni di insert, update e delete vengono replicate tra il server master e lo slave in modo da avere dati allineati tra i due server.

La seconda è il classico cluster active/passive, ovvero il dbms gira sul nodo attivo, sul quale sono assegnati anche l'indirizzo/i ip su cui sta in ascolto il servizio ed è attestato lo storage che contiene datafile e tranlog.
In caso di down del server attivo avviene il passaggio al secondo server (relocate, che può anche essere lanciato manualmente per manutenzione, pensa ai millemila anacronistici riavvi inutili di Windows per l'installazione di aggiornamenti), lo storage viene montato sul secondo server (generalmente questo implica un meccanismo di sicurezza per evitare che venga montato contemporaneamente dai due causando una corruzione totale dei filesystem e quindi dei dati), l'ip viene assegnato al secondo server e il database viene fatto partire sul secondo server.
Come puoi immaginare le differenza rispetto al mirror sono evidenti, nel primo caso hai due dbms sempre attivi che replicano i dati (e che quindi immagino richiedano due diverse licenze, salvo diavolerie di licensing su cui non so nulla e dalle quali mi tengo a debita distanza), nel secondo hai sempre e solo un dbms attivo e lo switch è totale, nel senso che non può esistere disallineamenti dei dati tra i due visto che i datafile e i tranlog che usano i due nodi del cluster sono gli stessi (chiaramente per funzionare c'è bisogno di storage accessibile da entrambi i server, ad esempio tramite iSCSI oppure SAN).
Non pensare comunque che il relocate sia un meccanismo infallibile, relocate che si incastrano o corruzioni di dati causa mount multiplo dello storage sono un classico intramontabile, diciamo che in generale il cluster active/passive è una soluzione tecnicamente vecchia, delicata e tutt'altro che indolore.

La terza soluzione invece pare essere un cluster vero attivo/attivo, non conosco come sia stata implementata su MS SQL ma a occhio e croce sarà concettualmente simile al RAC Oracle.
Quindi avrai storage condiviso e mediato da un substrato software che permetterà a più nodi di accedere in scrittura ai datafile (Oracle per fare questo usa una feature proprietaria chiamata ASM, Automatic Storage Management) e presumibilmente un bilanciatore delle richieste verso gli N nodi del cluster (oppure definirai dei datasource applicativi che punteranno ai vari nodi).
Non so come funzioni questa nuova feature di MS SQL 2012, deo gratias comunque che finalmente anche loro ci siano arrivati, era imbarazzante questa mancanza visto che Oracle ce l'ha dal 2001 e IBM DB2 dal 2009.

Spero di esserti stato utile.

Grazie 1000 della risposta! Mi è stata molto utile... ora cercherò di approfondire la cosa!