Guida all'architettura AlwaysOn: creazione di una soluzione per
disponibilità elevata e ripristino di emergenza con istanze del cluster
di failover e gruppi di disponibilità
Articolo tecnico su SQL Server
Autori: Joseph Sack (SQLskills.com), Sanjay Mishra (Microsoft)
Revisori tecnici: Min He (Microsoft), Chuck Heinzelman (Microsoft), Alexi Khalyako (Microsoft),
Charles Mathews (Microsoft), Prem Mehra (Microsoft), Juergen Thomas (Microsoft), Mike
Weiner (Microsoft), Amitabh Tamhane (Microsoft), Brent Ozar (Brent Ozar PLF), Gianluca Hotz
(SolidQ), David P. Smith (ServiceU), Michael Steineke (Edgenet), Glenn Berry (SQLskills.com)
Content Program Manager: Glenn Minch (Microsoft)
Data di pubblicazione: giugno 2012
Contesto di applicazione: SQL Server 2012
Riepilogo: le istanze del cluster di failover e i gruppi di disponibilità di SQL Server 2012 AlwaysOn
forniscono una soluzione completa per la disponibilità elevata e il ripristino di emergenza. Prima
di SQL Server 2012, molti clienti utilizzavano le istanze del cluster di failover per assicurare
elevata disponibilità locale all'interno di un data center e il mirroring del database per il ripristino
di emergenza in un data center remoto. Con SQL Server 2012 è possibile sostituire questo
modello di progettazione con un'architettura basata sulle istanze del cluster di failover per
assicurare disponibilità elevata e i gruppi di disponibilità per soddisfare le esigenze aziendali di
ripristino di emergenza. I gruppi di disponibilità sfruttano la tecnologia Windows Server Failover
Clustering (WSFC) e includono molte funzionalità non disponibili nel mirroring del database. In
questo documento verranno trattati in dettaglio i requisiti fondamentali della topologia di questo
specifico modello di progettazione, con particolare attenzione alle considerazioni sull'archiviazione
asimmetrica, la scelta del modello di quorum, i voti del quorum, i passaggi necessari per creare
l'ambiente e un flusso di lavoro in cui viene illustrata la ripartizione della gestione di un evento di
ripristino di emergenza nella nuova topologia tra i diversi ruoli partecipanti.
Copyright
Il documento viene fornito “com'è”. Le informazioni e le opinioni espresse nel presente documento,
inclusi gli URL e altri riferimenti a siti Web, possono essere soggette a modifiche senza preavviso.
L'utente accetta di utilizzarlo a proprio rischio.
Alcuni esempi utilizzati in questo documento vengono forniti a scopo puramente illustrativo e sono
fittizi. Nessuna associazione reale o connessione è intenzionale o può essere desunta.
Il presente documento non implica la concessione di alcun diritto di proprietà intellettuale relativo ai
prodotti Microsoft. È possibile copiare e utilizzare questo documento per fini di riferimento interno.
© 2012 Microsoft. Tutti i diritti sono riservati.
2
Sommario
Introduzione.................................................................................................................................................. 4
Istanze del cluster di failover per HA e mirroring del database per DR........................................................ 4
Istanze del cluster di failover per HA locale e gruppi di disponibilità per DR ............................................... 5
Pianificazione e considerazioni ..................................................................................................................... 7
Requisiti WSFC .......................................................................................................................................... 7
Archiviazione asimmetrica ........................................................................................................................ 7
Denominazione e percorso di file delle istanze ........................................................................................ 7
Modalità di disponibilità e modalità di failover ........................................................................................ 8
Modello di quorum e voti dei nodi ........................................................................................................... 8
Strumenti per visualizzare e modificare il modello di quorum e i voti dei nodi ................................. 11
Configurazione del modello di quorum WSFC .................................................................................... 11
Utilizzo delle DMV e del dashboard AlwaysOn per visualizzare le informazioni sul quorum............. 12
Configurazione dei voti dei nodi ......................................................................................................... 13
Connettività dei client ............................................................................................................................. 14
Carichi di lavoro di lettura/scrittura ................................................................................................... 14
Carichi di lavoro di sola lettura ........................................................................................................... 14
Supporto per la connessione a più subnet ......................................................................................... 15
Configurazione della soluzione FCI+AG ...................................................................................................... 15
Prerequisiti di installazione ..................................................................................................................... 15
Configurazione della soluzione nel data center primario ....................................................................... 16
Configurazione della soluzione nel data center di DR ............................................................................ 21
Considerazioni sul monitoraggio ................................................................................................................ 26
Ripristino in seguito a un'emergenza ......................................................................................................... 27
Ripristino del data center primario ............................................................................................................. 33
Conclusione ................................................................................................................................................. 38
Riferimenti .................................................................................................................................................. 38
3
Introduzione
Microsoft SQL Server 2012 AlwaysOn offre opzioni di progettazione flessibili per realizzare la soluzione
per la disponibilità elevata (HA, High Availability) e il ripristino di emergenza (DR, Disaster Recovery) più
adeguata alle proprie esigenze. Per ulteriori informazioni sulle scelte disponibili, vedere il post sui
modelli di progettazione per la disponibilità elevata e il ripristino di emergenza di SQL Server 2012 AlwaysOn.
In questo white paper viene descritta una soluzione che utilizza le istanze del cluster di failover (FCI,
Failover Cluster Instance) per la disponibilità elevata e i gruppi di disponibilità (AG, Availability Group)
per il ripristino di emergenza. Questa architettura combina una soluzione di archiviazione condivisa
(FCI) e una soluzione di archiviazione non condivisa (AG).
Prima di SQL Server 2012, un'architettura di distribuzione per HA e DR richiedeva normalmente l'uso
delle istanze del cluster di failover per la disponibilità elevata locale e il mirroring del database (DBM,
Database Mirroring) per il ripristino di emergenza remoto. Con SQL Server 2012 i gruppi di disponibilità
possono sostituire la componente di mirroring del database della soluzione.
Questo documento contiene alcune considerazioni sulla pianificazione e la descrizione dettagliata della
procedura di creazione di questa soluzione. Vengono inoltre illustrati i passaggi necessari per il ripristino in
seguito a una situazione di emergenza e le modalità per tornare al data center primario dopo tale
operazione.
Gli argomenti trattati in questo documento presuppongono una conoscenza di base dei concetti di istanza
del cluster di failover, gruppo di disponibilità, disponibilità elevata e ripristino di emergenza. Per ulteriori
informazioni sulla serie completa di funzionalità delle soluzioni AlwaysOn, vedere il white paper Guida
alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza. Per
ulteriori informazioni sui passaggi relativi alla migrazione, vedere il white paper Guida alla migrazione:
migrazione al clustering di failover e ai gruppi di disponibilità di SQL Server 2012 da distribuzioni
precedenti basate su clustering e mirroring.
Il white paper è destinato agli amministratori di database e agli architetti della tecnologia SQL Server,
nonché agli amministratori di sistema che collaborano con il ruolo di amministratore di database per
gestire Windows Server, Servizi di dominio Active Directory, WSFC e i servizi di rete.
Istanze del cluster di failover per HA e mirroring del database per DR
Come già detto nell'introduzione, prima di SQL Server 2012 un'architettura di distribuzione di SQL Server
richiedeva normalmente l'uso delle istanze del cluster di failover per la disponibilità elevata locale e del
mirroring del database per il ripristino di emergenza tra data center. Questa soluzione è stata definita
FCI+DBM. In questo tipo di soluzione, viene configurata un'istanza del cluster di failover nel data center
primario utilizzando l'archiviazione su disco condivisa (ad esempio tramite rete SAN) per assicurare
protezione a livello di istanza di SQL Server. Se si verifica un errore hardware su uno dei nodi, un altro
nodo può assumere il ruolo di host dell'istanza del cluster di failover all'interno dello stesso data center.
Tra il sito primario e il sito di ripristino di emergenza viene utilizzato il mirroring del database per assicurare
protezione a livello di database. In caso di interruzione del data center primario o di errore delle risorse
di archiviazione condivisa nel data center primario, è possibile utilizzare il mirror nel data center di ripristino
di emergenza (DR) per ripristinare il servizio alle applicazioni. Nel data center di DR viene ospitata un'altra
istanza del cluster di failover su un cluster WSFC separato, con risorse di archiviazione condivisa proprie.
L'architettura di questa soluzione è illustrata nella Figura 1.
4
Data center primario
Data center di ripristino di emergenza
Cluster
Cluster WSFC
WSFC "B"
"A"
Cluster WSFC "A"
SQLFCIPrimary\INST_A
SQLFCIDR\INST_A
Mirroring del
database
Database
principale
Database
mirror
Figura 1: istanza del cluster di failover per la disponibilità elevata e mirroring del database per il ripristino di emergenza
In genere il data center di DR è situato a una certa distanza dal data center primario e la sessione di
mirroring è impostata sulla modalità asincrona a prestazioni elevate per ridurre al minimo l'overhead
delle transazioni. In alcuni casi viene anche utilizzato il mirroring del database sincrono tra i data center.
Per ulteriori informazioni, incluso un esempio pratico di questa specifica soluzione, vedere Disponibilità
elevata e ripristino di emergenza in ServiceU: case study tecnico su SQL Server 2008.
Istanze del cluster di failover per HA locale e gruppi di disponibilità per DR
Con SQL Server 2012 una soluzione simile comporta l'utilizzo delle istanze del cluster di failover per la
disponibilità elevata locale, come nella soluzione FCI+DBM, ma utilizzando i gruppi di disponibilità per il
ripristino di emergenza. Questa soluzione è definita FCI+AG.
La Figura 2 mostra la soluzione con le istanze del cluster di failover per la disponibilità elevata locale
e i gruppi di disponibilità per il ripristino di emergenza tra data center.
Figura 2: istanze del cluster di failover per la disponibilità elevata e gruppi di disponibilità per il ripristino di emergenza
La Figura 2 mostra due istanze del cluster di failover, una nel data center primario e l'altra nel data
center di ripristino di emergenza. Ciascuna istanza include due nodi e risorse di archiviazione condivisa
proprie. Tutti e quattro i nodi, tuttavia, fanno parte dello stesso cluster WSFC. L'appartenenza di tutti
i nodi allo stesso cluster WSFC è un requisito per i gruppi di disponibilità.
5
La topologia illustrata nella Figura 2 corrisponde a uno scenario semplice con due data center, in
ciascuno dei quali è ospitata una replica del gruppo di disponibilità su un'istanza del cluster di failover
con due nodi. L'architettura consente variazioni a questa topologia:
Più data center
Più repliche: fino a cinque, inclusa una replica primaria e da una a quattro repliche secondarie
Più di due nodi in ogni istanza del cluster di failover se si desidera aggiungere nodi passivi
a scopo di HA
Non tutte le repliche in un gruppo di disponibilità devono trovarsi su istanze del cluster di
failover; alcune possono trovarsi su istanze di SQL Server autonome e non del cluster di failover
Più gruppi di disponibilità basati sul raggruppamento logico di database per l'ambiente applicativo
Benché gli argomenti trattati in questo white paper siano incentrati sulla topologia mostrata nella Figura 2,
i concetti generali si applicano anche ad altre variazioni.
Poiché i quattro nodi dei due siti fanno parte dello stesso cluster WSFC, è necessario considerare alcuni
aspetti aggiuntivi riguardanti l'utilizzo delle risorse di archiviazione condivisa visibili solo ai nodi del data
center locale. Ulteriori considerazioni vanno dedicate ai voti del quorum e al modello di quorum. Il
documento tratterà questo e altri aspetti.
È possibile configurare il gruppo di disponibilità con uno o più database utente e impostarlo sullo
spostamento sincrono o asincrono dei dati. Le repliche sincrone aggiungono latenza alle transazioni del
database perché, prima di eseguire il commit di una transazione, la replica primaria deve ricevere la
conferma che i record del log sono stati finalizzati nei log delle repliche secondarie.
È anche importante notare che l'istanza di SQL Server di ripristino di emergenza non deve necessariamente
essere un'istanza del cluster di failover. Un gruppo di disponibilità potrebbe includere anche un'istanza
di SQL Server autonoma per la replica secondaria. Con i gruppi di disponibilità, è possibile combinare
istanze autonome e istanze del cluster di failover in una sola topologia sullo stesso cluster WSFC. Nella
Figura 3 viene illustrata una topologia mista.
Data center primario
Data center di ripristino di emergenza
Cluster WSFC (Windows Server Failover Clustering)
SQLFCIPrimary\INST_A
SQLDR\INST_B
Gruppo di
disponibilità
Database
primari
Database
secondari
Figura 3: istanza del cluster di failover per HA e gruppi di disponibilità per DR, con un'istanza autonoma con la funzione di
istanza di DR
La parte restante del documento si basa sul presupposto che la replica primaria e le repliche secondarie
siano tutte istanze del cluster di failover ospitate e non istanze autonome.
6
Pianificazione e considerazioni
In questa sezione vengono trattati in dettaglio i requisiti, i prerequisiti e alcune considerazioni relative
alla pianificazione di cui tenere conto prima di implementare una soluzione FCI+AG per la disponibilità
elevata e il ripristino di emergenza.
Requisiti WSFC
Una differenza fondamentale tra una soluzione FCI+DBM e una soluzione FCI+AG è che nella prima si
utilizzano due istanze del cluster di failover in due cluster WSFC separati, mentre nella seconda le due
istanze del cluster di failover si trovano in un unico cluster WSFC. Tutte le repliche di un gruppo di
disponibilità devono trovarsi in un unico cluster WSFC all'interno di un singolo dominio Active Directory,
anche tra data center.
Archiviazione asimmetrica
In presenza di due istanze del cluster di failover, una in ciascun sito del cluster WSFC multisito, è necessario
valutare in che modo gestire l'archiviazione condivisa. Ciascuna istanza del cluster di failover dispone
delle proprie risorse di archiviazione condivisa. I nodi nel sito primario condividono le risorse di archiviazione
tra loro per formare un'istanza del cluster di failover con archiviazione condivisa; analogamente, i nodi
nel sito di DR condividono le risorse di archiviazione fra loro per formare un'altra istanza del cluster di
failover con archiviazione condivisa. Le risorse di archiviazione nel sito primario non sono visibili ai nodi
nel sito di ripristino di emergenza e viceversa. Questa organizzazione delle risorse di archiviazione, in cui
un disco del cluster è condiviso tra un subset di nodi all'interno di un cluster WSFC, viene definita
archiviazione asimmetrica. Prima dell'introduzione della funzionalità di archiviazione asimmetrica, le
risorse di archiviazione condivisa dovevano essere visibili a tutti i nodi del cluster WSFC (archiviazione
simmetrica). L'archiviazione asimmetrica è stata introdotta come opzione di distribuzione per Windows
Server 2008 tramite un hotfix. È supportata anche in Windows Server 2008 R2 tramite Service Pack 1.
Per ulteriori informazioni, vedere l'articolo della Knowledge Base sull'hotfix per aggiungere supporto per
le archiviazioni asimmetriche allo snap-in MMC Gestione cluster di failover per un cluster di failover che
esegue Windows Server 2008 o Windows Server 2008 R2.
Questo miglioramento di Windows Server è l'elemento chiave che rende possibile l'architettura FCI+AG
descritta in questo white paper. Questa funzionalità consente infatti di combinare la soluzione di
archiviazione condivisa (istanze del cluster di failover) e la soluzione di archiviazione non condivisa
(gruppi di disponibilità) in un'unica soluzione per HA+DR. Di conseguenza, consente anche di utilizzare
lettere di unità identiche per le risorse disco condivise tra data center.
Notare che quando si configura l'archiviazione asimmetrica, durante i test di convalida del cluster WSFC
potrebbe apparire il messaggio “Il disco con ID XYZ è visibile o impostabile come disco di tipo cluster solo
da un sottoinsieme di nodi”. Per l'archiviazione asimmetrica si tratta di un comportamento previsto
e non indica la presenza di problemi.
Denominazione e percorso di file delle istanze
Le due istanze del cluster di failover devono utilizzare nomi diversi all'interno dello stesso cluster WSFC,
ad esempio “INST_A” come nome dell'istanza del cluster di failover primaria e ”INST_B” come nome
dell'istanza del cluster di failover di DR. Contrariamente ai gruppi di disponibilità, il mirroring del
database consente a ogni istanza del cluster di failover di utilizzare lo stesso nome se le istanze si
trovano in cluster WSFC separati. Nella Figura 1, che rappresenta la soluzione FCI+DBM, le due istanze
del cluster di failover hanno lo stesso nome, INST_A.
7
Ogni istanza del cluster di failover ha risorse di archiviazione condivisa proprie che non sono accessibili
ai nodi presenti nell'altro data center. È opportuno utilizzare lettere di unità identiche per i dischi
e percorsi identici per i file di database e i log delle transazioni di entrambe le istanze. Benché non si
tratti di un requisito obbligatorio, se i percorsi di file differiscono sarà necessario eseguire un'azione
RESTORE WITH MOVE manuale nel momento del ripristino dei database di replica sulla replica secondaria.
Inoltre, percorsi eterogenei nelle due istanze del cluster di failover invalideranno le successive
operazioni di aggiunta di file, quali la creazione di gruppi di file o di file di dati o di log secondari. Per
ulteriori informazioni, incluso uno scenario di risoluzione del problema, vedere Risolvere i problemi
relativi a una operazione di aggiunta file non riuscita (Gruppi di disponibilità AlwaysOn).
Modalità di disponibilità e modalità di failover
Per il gruppo di disponibilità creato tra le due istanze del cluster di failover è possibile definire la modalità
di disponibilità con commit sincrono o asincrono. Se la modalità di disponibilità è sincrona, la replica
primaria attende che le transazioni utente siano state inviate e finalizzate nelle repliche secondarie
prima di eseguirne il commit. Questo meccanismo può comportare l'aggiunta di latenza alle transazioni
utente, ma riduce la possibilità di perdita dei dati nella replica secondaria facendo sì che le transazioni
vengano inviate all'istanza del cluster di failover di ripristino di emergenza prima che venga segnalato un
commit sulla transazione della replica primaria.
Se la modalità di disponibilità è asincrona, la replica primaria esegue il commit delle transazioni utente
senza attendere la finalizzazione delle transazioni nei log delle repliche secondarie. In tal modo viene
ridotta la latenza delle transazioni, ma aumenta il rischio di perdita di dati nell'eventualità di un'interruzione.
Per quanto riguarda le modalità di failover, quando le istanze del cluster di failover vengono utilizzate
nella topologia con i gruppi di disponibilità, la modalità di failover dei gruppi di disponibilità deve essere
manuale (non automatica). Tuttavia, all'interno di ogni istanza del cluster di failover, il failover dell'istanza
di SQL Server sugli altri nodi è automatico.
Modello di quorum e voti dei nodi
Nota: la trattazione sui modelli di quorum e le informazioni correlate in questo white paper si
riferiscono alle soluzioni in esecuzione sui sistemi operativi Windows Server 2008 e Windows
Server 2008 R2, con gli appropriati Service Pack e aggiornamenti software.
Poiché l'infrastruttura alla base della soluzione FCI+AG è un cluster WSFC, è importante valutare il modello
di quorum appropriato. La configurazione del quorum è gestita a livello di WSFC, indipendentemente dal
numero di istanze del cluster di failover, dal numero di repliche e dal numero di gruppi di disponibilità
ospitati nel cluster WSFC.
In WSFC sono disponibili quattro modelli di quorum: Maggioranza dei nodi, Maggioranza dei nodi
e delle condivisioni file, Maggioranza dei nodi e dei dischi, Nessuna maggioranza: Solo disco. Per
ulteriori informazioni sui modelli di quorum, vedere la sezione della guida dettagliata ai cluster di
failover relativa alla configurazione del quorum in un cluster di failover.
8
Prima di selezionare un modello di quorum è importante prendere in considerazione il numero di nodi
votanti. L'assegnazione dei voti ai nodi appropriati svolge un ruolo importante nella progettazione
HA+DR. Benché per impostazione predefinita ogni nodo in un cluster di failover possieda un voto,
questa configurazione potrebbe non essere adeguata a una specifica soluzione per HA+DR, a seconda
della distribuzione dei nodi nel data center primario e nel data center di ripristino di emergenza.
È disponibile un hotfix (http://support.microsoft.com/kb/2494036) che consente di assegnare 1 voto ad
alcuni nodi e 0 voti ad altri nel cluster WSFC. La proprietà NodeWeight del nodo WSFC rappresenta il
voto per quel particolare nodo. Il valore “0” indica che il nodo non ha voti. Il valore “1” indica che il nodo
dispone di un voto di quorum. Questo hotfix deve essere installato in ogni nodo nella topologia.
Suggerimenti di carattere generale per i voti del quorum relativi a una soluzione AlwaysOn per HA+DR
vengono forniti nell'argomento Modifiche consigliate ai voti quorum nella documentazione online di
SQL Server. Tali suggerimenti vanno considerati come linee guida per definire lo schema di voto della
soluzione AlwaysOn. In base a queste linee guida, per evitare che il quorum dei nodi nel data center
primario venga compromesso da interruzioni nel data center di DR o dalla perdita di connettività tra
i due data center, lo schema di voto per la soluzione FCI+AG presentata nella Figura 2 sarà:
1 voto per ogni nodo nel data center primario
0 voti per ogni nodo nel data center di ripristino di emergenza
Questa assegnazione di voti si traduce in un totale di 2 voti per il cluster WSFC. In base alla procedura
consigliata il numero totale di voti per il cluster WSFC dovrebbe essere un numero dispari. In presenza di
un numero pari di nodi votanti (come nella topologia di esempio), valutare l'aggiunta di una condivisione
file di controllo, quindi scegliere il modello di quorum Maggioranza dei nodi e delle condivisioni file.
Nota: in molti ambienti aziendali la condivisione file è spesso di proprietà di un team diverso,
che si occupa anche della sua gestione. In questo caso il team controlla il voto di un nodo
e quindi ha influenza sullo stato del cluster di failover. Una condivisione file diventa un voto
e deve pertanto essere sempre disponibile. Per assicurare la disponibilità del voto della
condivisione file, si consiglia di utilizzare funzionalità di clustering o altre tecnologie di HA.
In alternativa, è possibile aggiungere un altro nodo e utilizzare il modello di quorum Maggioranza dei
nodi. Il nodo aggiuntivo deve trovarsi all'interno del cluster WSFC ma non deve necessariamente fare
parte della configurazione delle istanze del cluster di failover. Deve inoltre essere situato nello stesso
data center primario, insieme agli altri due nodi WSFC presenti nel data center.
Nella Figura 4 viene mostrata l'allocazione dei voti basata sul modello di quorum Maggioranza dei nodi
e delle condivisioni file.
9
Figura 4: soluzione FCI+AG per HA/DR con assegnazione dei voti ai nodi
Nella Figura 4 ciascuno dei due nodi nel data center primario possiede un voto. Nel data center primario
è definita anche una condivisione file di controllo, che possiede anch'essa un voto. I due nodi nel data
center di ripristino di emergenza non possiedono voti e non possono influire sul quorum.
Gli altri possibili modelli di quorum selezionabili per questa architettura di distribuzione sono Maggioranza
dei nodi e dei dischi (con un disco asimmetrico) o Nessuna maggioranza: Solo disco (con un disco
asimmetrico). Prima che l'archiviazione asimmetrica fosse disponibile per i cluster WSFC, un disco condiviso
poteva fungere da risorsa di quorum se visibile a tutti i nodi WSFC. Con l'archiviazione asimmetrica, le risorse
di archiviazione del cluster possono essere visibili a un subset di nodi ed essere comunque utilizzate
come risorsa quorum. Con il modello di quorum asimmetrico Nessuna maggioranza: Solo disco, è possibile
implementare uno scenario di tipo “ultimo rimasto”, in cui il cluster WSFC mantiene il quorum purché
un singolo nodo abbia contatto con il disco asimmetrico che funge da risorsa quorum.
È possibile abilitare questa configurazione utilizzando la riga di comando cluster.exe, ma non tramite
Gestione cluster di failover o Windows PowerShell. Per un esempio di questa configurazione, vedere la
sezione sulla modifica della configurazione del quorum in un cluster di failover con archiviazione
asimmetrica nella sezione della guida dettagliata ai cluster di failover relativa alla configurazione del
quorum in un cluster di failover.
Importante: l'uso di un disco asimmetrico come risorsa quorum offre numerosi vantaggi, ma richiede
anche un livello molto più alto di competenza sui cluster e di pianificazione. È necessario acquisire
grande familiarità con questa configurazione prima di distribuirla in un ambiente di produzione.
In caso di un'interruzione del data center primario che richieda l'attivazione del servizio nel data center
di ripristino di emergenza, è necessario valutare nuovamente la configurazione del quorum. A ogni nodo
nel data center di ripristino di emergenza deve essere assegnato un voto, mentre è necessario rimuovere il
voto (impostandolo su “0”) di ogni nodo nel data center primario fino al ripristino del servizio.
Presupponendo la presenza di due nodi nell'istanza del cluster di failover e un'interruzione di lunga
durata del data center primario, è inoltre necessario configurare una condivisione file di controllo (o un
altro tipo di voto aggiuntivo) nel data center di DR e impostare di conseguenza il modello di quorum.
Quando il data center primario è pronto per tornare operativo, lo schema di voto deve essere nuovamente
modificato e il modello di quorum nuovamente valutato. Più avanti in questo documento verrà descritto
dettagliatamente uno scenario di ripristino di emergenza e il flusso di processi associato.
10
Nel modello di quorum e nelle assegnazioni dei voti illustrati nella Figura 4 si presuppone che la soluzione
comprenda due repliche, una per ogni data center. Se sono presenti più data center e si prevede di
includere una parte della soluzione in un terzo data center, le decisioni sul modello di quorum e le
assegnazioni dei voti possono variare.
Strumenti per visualizzare e modificare il modello di quorum e i voti dei nodi
Sono disponibili più modalità per visualizzare e modificare il modello di quorum e/o i voti del quorum
del cluster. Nella tabella seguente sono elencati i vari strumenti per queste attività.
Per visualizzare il modello di quorum
Gestione cluster di failover di Windows
Windows PowerShell
Cluster.exe
DMV di SQL Server
Dashboard AlwaysOn in SQL Server
Management Studio
Per modificare il modello di quorum
Gestione cluster di failover di Windows
Windows PowerShell
Cluster.exe
Nota: è possibile utilizzare solo Cluster.exe per
impostare il modello di quorum su “Maggioranza
dei nodi e dei dischi (asimmetrici)” o su “Nessuna
maggioranza: Solo disco (asimmetrico)”
Per visualizzare i voti dei nodi
Per modificare i voti dei nodi
Windows PowerShell
Cluster.exe
DMV di SQL Server
Dashboard AlwaysOn
Windows PowerShell
Cluster.exe
Configurazione del modello di quorum WSFC
Di seguito sono disponibili alcuni esempi dell'utilizzo di Windows PowerShell tramite riga di comando
per visualizzare l'attuale modello di quorum e modificarlo.
Per visualizzare il modello di quorum esistente
Get-ClusterQuorum
Per impostare il modello di quorum Maggioranza dei nodi
Set-ClusterQuorum -NodeMajority
Per impostare il modello di quorum su Maggioranza dei nodi e delle condivisioni file
Set-ClusterQuorum -NodeAndFileShareMajority \\FileShare\Witness
La condivisione file di controllo scelta non deve trovarsi su un nodo che fa già parte della configurazione
WSFC AlwaysOn, ma può essere aggiunta come condivisione in un'altra configurazione WSFC e deve
trovarsi all'interno dello stesso dominio Active Directory del cluster WSFC. Inoltre, l'account del servizio
cluster WSFC deve disporre di autorizzazioni di lettura e scrittura per la condivisione file di controllo.
Gestione cluster di failover include la logica per aggiungere queste autorizzazioni alla condivisione file di
controllo, purché l'account utilizzato per modificare il modello di quorum disponga delle autorizzazioni
per la condivisione file.
11
Utilizzo delle DMV e del dashboard AlwaysOn per visualizzare le informazioni sul quorum
Non è possibile impostare o modificare il modello di quorum o i voti dei nodi tramite gli strumenti SQL
Server, ma è possibile utilizzare query Transact-SQL sulle DMV e il dashboard AlwaysOn in SQL Server
Management Studio per visualizzare i voti dei nodi e il modello di quorum del cluster di Windows che
ospita il gruppo di disponibilità.
Per visualizzare il modello di quorum del cluster di Windows che ospita il gruppo di disponibilità,
eseguire una query sulla DMV sys.dm_hadr_cluster
(http://technet.microsoft.com/it-it/library/hh212952(v=sql.110).aspx).
SELECT
FROM
cluster_name, quorum_type_desc, quorum_state_desc
sys.dm_hadr_cluster;
Quando questa query viene eseguita nell'ambiente di esempio illustrato in questo white paper,
restituisce il risultato seguente.
cluster_name
-----------contosocluster
quorum_type_desc
---------------NODE_AND_FILE_SHARE_MAJORITY
quorum_state_desc
----------------NORMAL_QUORUM
Per visualizzare i voti dei nodi, eseguire una query sulla DMV sys.dm_hadr_cluster_members.
SELECT
FROM
member_name, number_of_quorum_votes
sys.dm_hadr_cluster_members;
Quando questa query viene eseguita nell'ambiente di esempio illustrato in questo white paper,
restituisce il risultato seguente (l'allocazione dei voti verrà trattata in una sezione successiva).
member_name
-----------------PrimaryNode1
PrimaryNode2
DRNode1
DRNode2
File Share Witness
number_of_quorum_votes
---------------------1
1
0
0
1
È possibile utilizzare anche il dashboard AlwaysOn in SQL Server Management Studio per visualizzare
i voti del quorum e lo stato del cluster. Nella Figura 5 vengono mostrate queste informazioni per un
cluster di Windows con il modello di quorum Maggioranza dei nodi (lo stato del cluster e i voti del
quorum sono evidenziati).
12
Figura 5: visualizzazione dei voti del quorum e dello stato del cluster nel dashboard AlwaysOn
Anche se la colonna Voti del quorum non viene visualizzata per impostazione predefinita, è possibile
aggiungerla al dashboard facendo clic con il pulsante destro del mouse sull'intestazione di colonna nella
tabella Replica di disponibilità e selezionando la colonna da visualizzare.
Per un modello di quorum Maggioranza dei nodi e delle condivisioni file, in questa vista del dashboard
AlwaysOn vengono mostrati solo i nodi, non la condivisione file. Per visualizzare le informazioni complete
sul quorum, fare clic su Visualizza informazioni sul quorum del cluster a destra. Verrà visualizzata una
finestra popup simile a quella illustrata nella Figura 6.
Figura 6: informazioni sul quorum del cluster per il modello di quorum Maggioranza dei nodi e delle condivisioni file
Configurazione dei voti dei nodi
La proprietà NodeWeight del nodo WSFC rappresenta il voto per quel particolare nodo. Negli esempi
seguenti viene mostrato come configurare il nodo NodeWeight da un nodo in un cluster WSFC utilizzando
Windows PowerShell. Per l'esecuzione di Windows PowerShell sul nodo server, fare clic su Start,
scegliere Strumenti di amministrazione, quindi Moduli di Windows PowerShell. In questo esempio
DRNode1 rappresenta un nodo WSFC specifico situato nel data center di ripristino di emergenza.
13
Per visualizzare le impostazioni di voto correnti per tutti i nodi
Get-ClusterNode | fl NodeName, NodeWeight
Per impostare il voto di un nodo su “0”
(Get-ClusterNode “DRNode1”).NodeWeight=0
Nota: il valore “0” indica che il nodo non ha voti. Il valore “1” indica che il nodo dispone di un
voto di quorum.
Connettività dei client
I metodi di connessione delle istanze del cluster di failover in SQL Server 2012 sono gli stessi delle versioni
precedenti, ma per le migrazioni dal mirroring del database ai gruppi di disponibilità è necessario
prendere in considerazione e pianificare alcune modifiche prima di poter utilizzare la nuova funzionalità
delle repliche secondarie leggibili. Per ulteriori informazioni sulla migrazione, inclusi alcuni passaggi
e considerazioni approfondite, vedere il white paper Guida alla migrazione: migrazione al clustering di
failover e ai gruppi di disponibilità di SQL Server 2012 da distribuzioni precedenti basate su clustering
e mirroring.
Carichi di lavoro di lettura/scrittura
Per i carichi di lavoro di lettura/scrittura eseguiti nei database di disponibilità in un gruppo di disponibilità,
è possibile connettersi alla replica primaria utilizzando due opzioni. La prima opzione consiste nel
connettersi direttamente al nome di rete virtuale (VNN) dell'istanza del cluster di failover, che è diverso
per ogni replica. La seconda opzione consiste nell'utilizzare il nome del listener del gruppo di disponibilità.
Questa è l'opzione preferita perché consente il reindirizzamento automatico e trasparente alla replica
primaria corrente e consente di mantenere lo stesso nome nella stringa di connessione per tutte le
istanze. Il listener del gruppo di disponibilità è un VNN che viene associato a uno o più indirizzi TCP/IP
e porte di attesa e utilizzato per connettersi automaticamente a qualsiasi replica senza dover definire in
modo esplicito ogni possibile replica del gruppo di disponibilità nella stringa di connessione.
Se si esegue la migrazione delle connessioni dell'applicazione dei carichi di lavoro di lettura/scrittura da
una soluzione basata sul mirroring del database che utilizza l'attributo Partner di failover, è comunque
possibile continuare a utilizzare la stringa di connessione per il mirroring del database, ma solo se il gruppo
di disponibilità viene configurato con una sola replica secondaria impostata per l'attività di
lettura/scrittura. È quindi possibile utilizzare il nome server della replica primaria iniziale come origine dati e,
facoltativamente, il nome della replica secondaria come partner di failover. Questa configurazione non va
tuttavia utilizzata come soluzione a lungo termine.
Carichi di lavoro di sola lettura
Anche per le connessioni dei carichi di lavoro di sola lettura sono disponibili due opzioni. È possibile
utilizzare il VNN dell'istanza del cluster di failover oppure il listener del gruppo di disponibilità
e specificare il nuovo attributo ApplicationIntent nella stringa di connessione come “ReadOnly”.
Se si utilizza una stringa di connessione per il mirroring del database legacy, è possibile connettersi al
gruppo di disponibilità solo se questo viene impostato come singola replica secondaria configurata per
l'attività di lettura/scrittura.
14
Se si desidera sfruttare il routing di sola lettura, è necessario utilizzare il nome del listener del gruppo di
disponibilità insieme all'attributo ApplicationIntent e al valore “ReadOnly”. È inoltre necessario fare
riferimento a un database di disponibilità all'interno del gruppo di disponibilità. Il gruppo di disponibilità
deve essere configurato anche per il routing di sola lettura alle repliche secondarie leggibili tramite la
creazione di URL di routing di sola lettura ed elenchi di routing di sola lettura. Per ulteriori informazioni
su questo processo, vedere Configurare il routing di sola lettura per un gruppo di disponibilità (SQL Server).
Supporto per la connessione a più subnet
Il listener del gruppo di disponibilità può sfruttare anche l'attributo di connessione MultiSubnetFailover
nelle librerie client. È consigliabile inserire nelle stringhe di connessione dei gruppi di disponibilità l'attributo
MultiSubnetFailover per le topologie a più subnet che fanno riferimento a un nome di listener del
gruppo di disponibilità. L'opzione di connessione MultiSubnetFailover abilita il supporto per le connessioni
a più subnet e apre socket TCP per gli indirizzi IP del listener del gruppo di disponibilità in parallelo. Per
le librerie client legacy che non supportano l'attributo MultiSubnetFailover, è necessario valutare la
definizione di un appropriato timeout di accesso client.
Per ulteriori informazioni sulla connettività dei client e il failover delle applicazioni, vedere Listener del
gruppo di disponibilità, connettività client e failover dell'applicazione (SQL Server) nella documentazione
online di SQL Server.
Configurazione della soluzione FCI+AG
In questo flusso di lavoro vengono descritti i passaggi necessari alla compilazione della soluzione
FCI+AG. Benché in questa sede non vengano approfonditi tutti i dettagli, l'obiettivo è chiarire i passaggi
di implementazione del flusso di lavoro e le attività di competenza di ciascun ruolo partecipante. Nei casi
appropriati viene fatto riferimento alla documentazione di supporto. I passaggi sono suddivisi per ruolo
perché la maggior parte degli ambienti delle grandi aziende prevede una separazione dei compiti tra
i ruoli di amministratore del database, amministratore di Windows (o del cluster) e amministratore di
rete. Per questo motivo è importante che tra i diversi ruoli si stabilisca una corretta comunicazione e un
efficace coordinamento delle attività.
Prerequisiti di installazione
Prima di distribuire la soluzione Gruppi di disponibilità AlwaysOn, è importante verificare che il sistema
soddisfi i requisiti, inclusi gli aggiornamenti. Per ulteriori informazioni sui prerequisiti della distribuzione
di una soluzione Gruppi di disponibilità AlwaysOn, vedere Prerequisiti, restrizioni e consigli per i gruppi
di disponibilità AlwaysOn (SQL Server). Si consiglia di leggere con molta attenzione questo argomento
prima di continuare.
Su tutti i nodi deve essere installata la stessa versione del sistema operativo Windows Server e degli
aggiornamenti software. Il sistema operativo server deve essere almeno Windows Server 2008 SP2
o Windows Server 2008 R2 SP1 con gli aggiornamenti minimi seguenti:
Archiviazione asimmetrica (se si utilizza Windows Server 2008):
http://support.microsoft.com/kb/976097
Voti dei nodi: http://support.microsoft.com/kb/2494036
Test di convalida dei dischi durante la convalida del cluster:
http://support.microsoft.com/kb/2531907
Potrebbero essere necessari aggiornamenti aggiuntivi.
15
Configurazione della soluzione nel data center primario
La Tabella 1 illustra il flusso di lavoro per la configurazione dei nodi del data center primario,
presupponendo la presenza di due nodi.
Passaggio
1. Aggiungere la funzionalità Clustering di
failover ai due nodi situati nel data
center primario. Per ulteriori
informazioni sul processo, vedere
Installare la funzionalità Clustering di
failover. Per ulteriori informazioni sulla
convalida dell'infrastruttura di rete
e gli altri requisiti, vedere Informazioni
sui requisiti per i cluster di failover.
2. Controllare i prerequisiti e installare gli
aggiornamenti di Windows Server
necessari in ogni nodo nel data center
primario.
3. Assicurarsi che i volumi di archiviazione
condivisa definiti per l'istanza del
cluster di failover del data center
primario siano formattati e provvisti di
lettera di unità.
È consigliabile che le lettere di unità e il
percorso di directory dell'istanza del
cluster di failover di DR corrispondano
a quelli dell'istanza del cluster di
failover primaria. Tenere presente
questo aspetto durante l'assegnazione
delle lettere di unità nell'istanza del
cluster di failover primaria.
16
Amministratore Amministratore
del database
di Windows
Server/
del cluster
Sì, per il
Sì
coordinamento
delle attività tra
i ruoli
Sì
Sì
Amministratore
di rete
Passaggio
4. Verificare che l'account che verrà
utilizzato per installare e configurare il
cluster WSFC sia un account di dominio.
Questo account deve disporre anche
delle autorizzazioni di amministratore
per ogni nodo del cluster e delle
autorizzazioni Create Computer
Objects e Read All Properties per il
contenitore utilizzato per gli account
dei computer del dominio.
In alternativa, è possibile preinstallare
gli account degli oggetti nome
anticipatamente o utilizzare un
account amministratore di dominio per
l'installazione. Per ulteriori
informazioni sulle autorizzazioni
necessarie e le opzioni di provisioning,
vedere la sezione della guida
dettagliata sui cluster di failover
relativa alla configurazione degli
account in Active Directory.
5. Utilizzando Gestione cluster di failover,
eseguire la convalida del cluster dei
due nodi server nel data center primario
e dell'archiviazione condivisa che verrà
aggiunta al cluster WSFC. Ripetere la
convalida fino alla scomparsa di tutti
gli errori che potrebbero impedire la
prosecuzione del processo.
Se viene consentito di passare al punto
successivo con gli avvisi esistenti,
è necessario comprendere tali avvisi
per garantire una configurazione
stabile. Per ulteriori informazioni
sull'esecuzione di un test di convalida,
vedere Convalidare la configurazione
di un cluster di failover.
6. Al termine del passaggio di convalida
del cluster, utilizzare Gestione cluster
di failover per creare un cluster WSFC
con due nodi. Per ulteriori informazioni,
inclusa una panoramica dettagliata di
questo processo, vedere Creare un
nuovo cluster di failover.
17
Amministratore Amministratore
del database
di Windows
Server/
del cluster
Sì
Amministratore
di rete
Sì
Sì, per eventuali
problemi relativi
alla connessione
in rete dei nodi
Sì
Sì, per eventuali
problemi relativi
alla connessione
in rete dei nodi
Passaggio
7. Assicurarsi che sia presente un numero
dispari di voti, ad esempio aggiungendo
una condivisione file o un altro nodo
aggiuntivo, come descritto in
precedenza in questo documento.
Se si sceglie Maggioranza dei nodi
e delle condivisioni file, prima di
modificare la configurazione accertarsi
di avere concesso le autorizzazioni di
lettura e scrittura per la condivisione
file di controllo all'account del cluster
WSFC.
8. Assicurarsi che nell'installazione
vengano utilizzate risorse di
archiviazione condivise e formattate,
accessibili solo ai due nodi situati nel
data center primario. Questi dischi
verranno utilizzati per SQL Server nel
passaggio successivo.
9. Installare un'istanza del cluster di
failover di SQL Server 2012 Enterprise
nel data center primario. Per ulteriori
informazioni, vedere Creare un nuovo
cluster di failover di SQL Server
(programma di installazione).
È necessario eseguire due opzioni di
installazione: la prima è Installazione
nuovo cluster di failover di SQL Server,
con la quale viene creata l'istanza del
cluster di failover, mentre la seconda
è Aggiungi nodo a cluster di failover di
SQL Server sul secondo nodo nel data
center primario.
18
Amministratore Amministratore
del database
di Windows
Server/
del cluster
Sì
Sì
Sì
Amministratore
di rete
Passaggio
10. Dopo avere installato la prima istanza
del cluster di failover, abilitare le
funzionalità Gruppi di disponibilità
AlwaysOn per entrambe le istanze di
SQL Server.
Per ulteriori informazioni sull'uso di
Gestione configurazione SQL Server o,
in alternativa, SQL Server PowerShell,
vedere Abilitare e disabilitare la
funzionalità Gruppi di disponibilità
AlwaysOn (SQL Server). Notare che,
quando si abilita Gruppi di disponibilità
AlwaysOn per un'istanza, è necessario
riavviare l'istanza per rendere effettiva
la modifica.
19
Amministratore Amministratore
del database
di Windows
Server/
del cluster
Amministratore
di rete
Passaggio
Amministratore Amministratore
del database
di Windows
Server/
del cluster
11. Dopo avere abilitato l'istanza del cluster
di failover di DR per il supporto di
Gruppi di disponibilità AlwaysOn,
eseguire il backup dei database utente
di produzione dalla topologia legacy,
quindi ripristinarli nell'istanza del
cluster di failover del data center
primario.
Nota: è possibile scegliere di rinviare
questo passaggio finché anche l'istanza
del cluster di failover non sia disponibile
e non sia possibile configurare il
gruppo di disponibilità con due repliche.
È inoltre necessario inserire in script gli
altri oggetti SQL Server della topologia
legacy da cui dipenderanno i database
utente e che non sono contenuti nei
database utente ripristinati (come gli
account di accesso di SQL server, le
autorizzazioni a livello di server associate
e i processi di SQL Server Agent).
Questo processo è simile a quello
utilizzato per inserire in script oggetti
dipendenti esterni al database
sottoposto a mirroring in una relazione
di mirroring. Sono disponibili diversi
metodi per trasferire oggetti e principi
di database tra istanze di SQL Server.
Uno di questi è l'attività Trasferisci
oggetti di SQL Server di Integration
Services. Un altro metodo utilizzato per
trasferire account di accesso e password
tra istanze viene descritto qui:
http://support.microsoft.com/kb/918992/
Tabella 1: compilazione della soluzione FCI+AG nel data center primario
20
Amministratore
di rete
Configurazione della soluzione nel data center di DR
Questa tabella contiene il flusso di lavoro per la configurazione dei nodi del data center di ripristino di
emergenza secondario e la creazione del gruppo di disponibilità.
Passaggio
Amministratore
del database
1. Aggiungere la funzionalità
Clustering di failover a tutti
i nodi situati nel data center di
ripristino di emergenza che
fanno parte della soluzione.
2. Controllare i prerequisiti
e installare gli aggiornamenti di
Windows Server necessari in
ogni nodo nel data center di DR.
3. Verificare che l'account che verrà
utilizzato per installare
e configurare il cluster WSFC sia
un account di dominio. Questo
account deve disporre anche
delle autorizzazioni di
amministratore per ogni nodo
del cluster e delle autorizzazioni
Create Computer Objects e Read
All Properties per il contenitore
utilizzato per gli account dei
computer del dominio. Se si
utilizzano gli stessi account del
data center primario, queste
autorizzazioni sono già
impostate correttamente.
4. Utilizzando Gestione cluster di
failover, eseguire la convalida del
cluster dei due nodi server
e dell'archiviazione condivisa
aggiunti al cluster WSFC
esistente. Se viene visualizzato
il messaggio di avviso relativo
all'archiviazione asimmetrica
“Il disco con ID XYZ è visibile
o impostabile come disco di tipo
cluster solo da un sottoinsieme
di nodi”, non è necessario
intraprendere alcuna azione, in
quanto si tratta di un messaggio
previsto e accettabile per
l'archiviazione asimmetrica.
Ripetere la convalida fino alla
scomparsa di tutti gli errori che
potrebbero impedire la
prosecuzione del processo.
Sì, per il
coordinamento
delle attività tra
i ruoli
21
Amministratore di
Windows Server/
del cluster
Sì
Amministratore
di rete
Sì
Sì
Sì
Sì, per eventuali
problemi relativi
alla connessione in
rete dei nodi
Passaggio
Amministratore
del database
5. Al termine della convalida,
utilizzare Gestione cluster di
failover per aggiungere i due
nodi di ripristino di emergenza al
cluster WSFC esistente.
6. Impostare la proprietà
NodeWeight dei nodi WSFC del
data center di ripristino di
emergenza sul peso 0 (zero). Per
un esempio, vedere la Figura 4:
soluzione FCI+AG per HA/DR con
assegnazione dei voti ai nodi.
7. Nell'installazione devono essere
utilizzate risorse di archiviazione
condivise e formattate, accessibili
solo ai due nodi situati nel data
center di DR. Questi dischi
verranno utilizzati per SQL Server
nel passaggio successivo.
Mantenere le stesse lettere di
unità e lo stesso mapping per
semplificare la distribuzione del
gruppo di disponibilità nei
passaggi successivi e consentire
le operazioni sui file di database
che non richiedono intervento
manuale o l'interruzione della
sessione del gruppo di
disponibilità.
8. Spostare le risorse di
archiviazione disponibili in uno
dei nodi del data center di DR
per poterle utilizzare nel
passaggio successivo.
9. Installare un'istanza del cluster
di failover di SQL Server 2012
Enterprise nel data center di
ripristino di emergenza.
È necessario eseguire l'opzione
Installazione nuovo cluster di
failover di SQL Server su uno dei
nodi per creare l'istanza del
cluster di failover, quindi
l'opzione Aggiungi nodo
a cluster di failover di SQL
Server sul secondo nodo nel
data center di DR.
22
Amministratore di
Windows Server/
del cluster
Sì
Amministratore
di rete
Sì, per eventuali
problemi relativi
alla connessione in
rete dei nodi
Sì
Sì
Sì
Sì
Sì, per coordinare
l'approccio a porte
e indirizzi IP (se si
utilizzano indirizzi
IP statici)
Passaggio
Amministratore
del database
10. Il passaggio successivo
all'installazione delle due istanze
del cluster di failover consiste
nell'abilitazione delle funzionalità
Gruppi di disponibilità AlwaysOn
nell'istanza di SQL Server del
data center di DR.
Sì
Per informazioni dettagliate
sull'uso di Gestione configurazione
SQL Server o, in alternativa, di
PowerShell, vedere Abilitare
e disabilitare la funzionalità
Gruppi di disponibilità AlwaysOn
(SQL Server). Notare che, per
rendere effettiva l'abilitazione di
Gruppi di disponibilità AlwaysOn
per l'istanza, sarà necessario
riavviare l'istanza.
11. Inserire in script gli altri oggetti
SQL Server della topologia legacy
da cui dipenderanno i database
utente e che non sono contenuti
nei database utente ripristinati
(come gli account di accesso di
SQL server, le autorizzazioni
a livello di server associate
e i processi di SQL Server Agent).
Si tratta degli stessi oggetti che
sono probabilmente già stati
inseriti in script e copiati
nell'istanza del cluster di failover
del data center primario.
12. Verificare la corretta
impostazione dei possibili
proprietari delle due istanze
del cluster di failover: i possibili
proprietari per INST_A devono
essere PRIMARYNODE1
e PRIMARYNODE2, mentre
i possibili proprietari per INST_B
devono essere DRNODE1
e DRNODE2.
23
Sì
Amministratore di
Windows Server/
del cluster
Amministratore
di rete
Passaggio
Amministratore
del database
13. Creare un gruppo di disponibilità Sì
(questo passaggio coinvolge le
istanze del cluster di failover
primarie e di DR). È possibile
impostare la modalità di
disponibilità come asincrona
o sincrona, a seconda delle
caratteristiche dei carichi di
lavoro e di rete dell'ambiente.
Selezionare il failover manuale
per il gruppo di disponibilità. In
una soluzione FCI+AG il failover
delle istanze del cluster di failover
è automatico e il failover dei
gruppi di disponibilità è manuale.
Per ulteriori informazioni sulla
configurazione del failover per
questa soluzione, vedere
Creazione e configurazione di
gruppi di disponibilità (SQL
Server).
14. Creare il listener del gruppo di
Sì
disponibilità. Questo passaggio
non è necessario se il listener
è già stato configurato come
parte della creazione del gruppo
di disponibilità. Per creare il
listener del gruppo di
disponibilità, è possibile
utilizzare Transact-SQL, SQL
Server PowerShell o una
procedura guidata di SQL Server
Management Studio. Per
ulteriori informazioni sull'utilizzo
dei diversi metodi, vedere Creare
o configurare un listener del
gruppo di disponibilità (SQL
Server).
Amministratore di
Windows Server/
del cluster
Amministratore
di rete
Sì, per assicurare
che le porte degli
endpoint siano
aperte e in fase di
risoluzione dei
problemi, in base
alle esigenze
Sì
Sì, per coordinare
l'approccio a porte
e indirizzi IP
Tabella 2: compilazione della soluzione FCI+AG nel data center di ripristino di emergenza
Dopo avere completato questi passaggi, si noterà che in Gestione cluster di failover di Windows, sotto
Servizi e applicazioni, è stato creato un nuovo gruppo con lo stesso nome del gruppo di disponibilità. Il
nuovo gruppo conterrà la risorsa listener del gruppo di disponibilità e gli indirizzi IP associati (vedere la
Figura 5).
24
Figura 7: situazione della soluzione dopo la configurazione delle istanze del cluster di failover per HA e del gruppo di
disponibilità per DR
Nella Figura 7 viene illustrata la distribuzione della soluzione nel cluster WSFC. Notare che al listener del
gruppo di disponibilità raffigurato è associato un solo indirizzo IP per scopi illustrativi, ma per le topologie
con più data center è frequente la presenza di due indirizzi IP.
Nota: anche se il gruppo di disponibilità viene visualizzato come risorsa nel cluster WSFC, non
è opportuno tentare di gestirlo con Gestione cluster di failover o altre interfacce mirate alla
gestione WSFC. Operare invece nel contesto dell'istanza di SQL Server tramite SQL Server
Management Studio, Transact-SQL o Windows PowerShell. Per ulteriori informazioni sui motivi
per cui evitare di utilizzare Gestione cluster di failover o altre interfacce mirate alla gestione
WSFC, vedere il post di blog Evitare di utilizzare Gestione cluster di failover di Windows per
eseguire il failover dei gruppi di disponibilità.
Nella Figura 8 viene illustrata la distribuzione in SQL Server Management Studio. Una delle istanze del
cluster di failover viene mostrata in Esplora oggetti con la gerarchia della cartella Disponibilità elevata
AlwaysOn aperta. In questo esempio l'istanza del cluster di failover di DR è la replica secondaria, mentre
l'altra istanza del cluster di failover è la replica primaria. Vengono elencati i tre database di disponibilità
che fanno parte del gruppo insieme al nome del listener del gruppo di disponibilità.
25
Figura 8: situazione della soluzione dopo la configurazione delle istanze del cluster di failover per HA e del gruppo di
disponibilità per DR in SQL Server Management Studio
Considerazioni sul monitoraggio
Quando si esegue la migrazione da una topologia con istanze del cluster di failover e mirroring del
database a una soluzione basata su istanze del cluster di failover e un gruppo di disponibilità,
è necessario adottare nuovi metodi per l'esecuzione del monitoraggio della topologia. I metodi e gli
strumenti che è possibile utilizzare per il monitoraggio dell'infrastruttura del gruppo di disponibilità
includono il dashboard AlwaysOn in SQL Server Management Studio, le informazioni sullo stato di
Esplora oggetti, i criteri della Gestione basata su criteri, i contatori delle prestazioni correlati al nuovo
gruppo di disponibilità, viste del catalogo, DMV e una sessione Eventi estesi che tiene traccia di esecuzioni
recenti di istruzioni correlate al DDL AlwaysOn, problemi di connettività WSFC, eventi di failover,
cambiamenti di stato e blocchi di thread di rollforward.
Il dashboard AlwaysOn è lo strumento consigliato per visualizzare rapidamente l'integrità di un gruppo
di disponibilità specifico. Nel dashboard vengono infatti inclusi il percorso dell'istanza primaria, la modalità
di failover delle repliche, lo stato di sincronizzazione delle repliche e la conformità del failover delle varie
repliche. I dati della sessione Eventi estesi di integrità AlwaysOn possono anche essere aperti direttamente
dal dashboard per visualizzare l'attività recente del gruppo di disponibilità, i cambiamenti di stato e gli eventi.
26
Figura 9: dashboard AlwaysOn
È inoltre possibile creare avvisi e risposte a processi di SQL Server Agent basati sulle soglie dei contatori
delle prestazioni e sui cambiamenti di stato del gruppo di disponibilità. Per ulteriori informazioni
e indicazioni sul monitoraggio dell'ambiente di un gruppo di disponibilità, vedere Monitoraggio di
Gruppi di disponibilità (SQL Server).
Ripristino in seguito a un'emergenza
In questa sezione vengono descritti dettagliatamente i passaggi da seguire in caso di interruzione della
replica primaria nel data center primario. Viene inoltre analizzata la procedura per ripristinare la disponibilità
della replica primaria dal data center di ripristino di emergenza. L'interruzione della replica primaria può
essere provocata da uno o più dei motivi seguenti:
Errori di tutti i nodi delle istanze del cluster di failover nel data center primario
Errori delle risorse di archiviazione delle istanze del cluster di failover nel data center primario
Errori o interruzioni della rete che interessano l'intero data center primario
In questi scenari si rendono necessarie determinate azioni nel data center di ripristino di emergenza per
riprendere l'esecuzione del servizio SQL Server alle applicazioni.
La Figura 10 mostra la finestra Informazioni sul quorum del cluster relativa a questo scenario. Le
informazioni sono accessibili dal dashboard AlwaysOn, utilizzando il collegamento Visualizza
informazioni sul quorum del cluster. Il quorum è quello di una situazione precedente al verificarsi di
un'emergenza, in cui entrambi i nodi di DR possiedono zero voti.
27
Figura 10: stato dei voti del quorum del cluster prima di una situazione di emergenza
Nel flusso di lavoro seguente vengono indicati i passaggi necessari per ripristinare un gruppo di disponibilità
nel data center di ripristino di emergenza in caso di interruzione del data center primario.
1. Forzare il quorum su uno dei nodi di DR e assicurarsi che i nodi nel data center primario non formino
il proprio quorum.
È improbabile che Gestione cluster di failover avviato su un nodo di ripristino di emergenza fornisca
inizialmente informazioni utili sullo stato del cluster WSFC, perché il cluster non possiede più il
quorum.
Figura 11: Gestione cluster di failover dopo che si è verificata un'emergenza e prima del ripristino
Poiché dipendono da un cluster WSFC funzionante, le istanze del cluster di failover sono accessibili
a meno che non siano attivi sia un quorum del cluster sia il servizio cluster. In uno scenario in cui lo
stato del data center primario è incerto e il servizio deve essere ripristinato dal data center secondario
di DR per rispettare l'obiettivo del tempo di recupero aziendale, è necessario forzare il quorum su
uno dei nodi di DR.
Il comando di Windows PowerShell seguente forza il quorum su uno dei nodi di DR.
28
Start-ClusterNode –Name “DRNODE1” –FixQuorum
Dopo aver eseguito il comando, si otterrà un output simile al seguente.
Name
------drnode1
State
-------Joining
Nota: se il servizio cluster è ancora in esecuzione su “DRNODE1”, è possibile utilizzare il
comando seguente in Windows PowerShell per arrestare il servizio prima di avviare
nuovamente il servizio cluster con il quorum forzato.
Stop-ClusterNode –Name “DRNODE1”
Per informazioni sugli altri strumenti che è possibile utilizzare per forzare il quorum, come
cluster.exe o Gestione cluster di failover, vedere Forzare l'avvio di un cluster WSFC senza quorum.
2. Aprire Gestione cluster di failover per verificare lo stato del cluster Windows. A questo punto il
cluster Windows deve essere attivo e in stato di quorum forzato e l'istanza del cluster di failover
secondaria deve essere attiva. L'istanza del cluster di failover del data center primario sarà ancora
offline, come le risorse del gruppo di disponibilità.
Figura 12: Gestione cluster di failover dopo la forzatura del quorum
3. Portare online il gruppo di disponibilità nell'istanza del cluster di failover di ripristino di emergenza.
Attenzione: se la replica è configurata con la modalità asincrona, il ripristino del servizio rischia di
causare la perdita di dati per gli eventuali record di log non inviati. Assicurarsi di valutare
correttamente le conseguenze di questa azione.
Per ulteriori informazioni sulle azioni da intraprendere prima, durante e dopo questo tipo di failover
manuale, vedere Eseguire un failover manuale forzato di un gruppo di disponibilità (SQL Server).
Tramite SQL Server Management Studio connettersi all'istanza del cluster di failover nel data center
di DR. I database di disponibilità dovrebbero indicare lo stato “Non in sincronizzazione”. L'istanza del
cluster di failover apparirà in stato “Risoluzione”, come illustrato nella Figura 13.
29
Figura 13: Esplora oggetti in SQL Server Management Studio dopo la forzatura del quorum
Notare nella Figura 13 che l'altra replica, che in questo esempio è ”SQLFCIPrimary\INST_A”, non
mostra alcuno stato in Esplora oggetti all'interno della cartella “Repliche di disponibilità” di AG1.
Si tratta dell'istanza del cluster di failover del data center primario che è non più accessibile
a causa dell'interruzione.
Se il rischio di perdita di alcuni dati è accettabile e il servizio deve essere ripristinato nel data
center, eseguire la sintassi Transact-SQL riportata di seguito nell'istanza del cluster di failover di
ripristino di emergenza per forzare il failover.
ALTER AVAILABILITY GROUP [AG1]
FORCE_FAILOVER_ALLOW_DATA_LOSS;
A questo punto, i database all'interno del gruppo di disponibilità dovrebbero essere disponibili.
Vedere la Figura 14 per un esempio di stato di failover successivo alla forzatura.
30
Figura 14: Esplora oggetti dopo la forzatura del failover
Con il ritorno online, nuove connessioni al listener del gruppo di disponibilità vengono
automaticamente indirizzate alla replica primaria attuale, che è ora ospitata nell'istanza del
cluster di failover di ripristino di emergenza.
Notare inoltre che verranno ancora visualizzati vari messaggi di avviso relativi alla non disponibilità
dei nodi del data center primario in SQL Server Management Studio. Nella Figura 15 viene
mostrato un esempio della schermata.
31
Figura 15: dashboard AlwaysOn dopo un failover forzato
4. Da un nodo WSFC di DR rimuovere i voti dai nodi del data center primario e assegnare voti ai nodi
del data center di DR. I voti possono essere rimossi anche se i nodi del data center primario non
sono disponibili. I due nodi a cui è assegnato un peso di “1” sono i nodi WSFC di DR.
(Get-ClusterNode “DRNode1”).NodeWeight=1
(Get-ClusterNode “DRNode2”).NodeWeight=1
(Get-ClusterNode “PrimaryNode1”).NodeWeight=0
(Get-ClusterNode “PrimaryNode2”).NodeWeight=0
Nota: se il sito di DR deve essere utilizzato per un periodo di tempo prolungato, si
consiglia di aggiungere altri membri votanti (nodo WSFC o condivisione file).
Prima di continuare, è possibile verificare che i voti dei nodi siano stati modificati nel modo
desiderato tramite il comando di Windows PowerShell riportato di seguito.
Get-ClusterNode | fl NodeName, NodeWeight
Come già detto nel documento, la maggior parte degli ambienti delle grandi aziende prevede normalmente
una separazione dei compiti tra i ruoli di amministratore del database, amministratore di Windows
Server (o del cluster) e amministratore di rete. Nella tabella seguente viene riepilogato il flusso di lavoro
del ripristino di emergenza descritto in precedenza, indicando le aree che tipicamente rientrano nella
competenza dei vari ruoli aziendali dal punto di vista della pianificazione.
32
Passaggio
Amministratore
del database
1. Verificare l'attuale stato del
data center primario e dei
restanti nodi di ripristino di
emergenza WSFC,
coordinando gli interventi.
2. Forzare il quorum su uno dei
nodi nel sito di DR per
accedere all'istanza del
cluster di failover di DR.
3. Forzare il failover del gruppo
di disponibilità all'istanza del
cluster di failover di ripristino
di emergenza.
4. Aggiungere i voti ai nodi di
DR e rimuovere i voti dai
nodi primari.
Sì
Amministratore di
Windows Server/del
cluster
Sì
Amministratore
di rete
Sì
Sì
Sì
Sì
Tabella 3: ripristino in seguito a un'emergenza in base al ruolo
Ripristino del data center primario
Nello scenario illustrato in questo documento si presuppone che il ripristino del servizio nel data center
di ripristino di emergenza costituisca uno stato temporaneo in attesa della risoluzione dei problemi del
data center primario. Uno scenario di interruzione può presentare diverse variazioni, che si ripetono
quindi anche nella fase di ripristino. Nello scenario descritto qui si presuppone una situazione di
emergenza in cui i server del data center primario sono inattivi per un periodo di tempo prolungato.
Una volta risolti i problemi e riattivati i nodi nel data center primario, tali nodi tentano di connettersi al
cluster WSFC. Dopo la riconnessione al cluster WSFC con i servizi cluster in esecuzione, i pesi assegnati al
nodo di ripristino di emergenza dovrebbero tornare effettivi. Inoltre, nello scenario si presuppone che le
installazioni originali di SQL Server e i database associati siano ancora intatti.
Lo stato della replica nell'istanza del cluster di failover nel data center primario in cui si è precedentemente
verificato l'errore sarà “Non in sincronizzazione” (vedere la Figura 16).
33
Figura 16: SQL Server Management Studio dopo il ripristino dell'istanza del cluster di failover primaria ma prima della ripresa
del gruppo di disponibilità
L'istanza di SQL Server del sito di DR (in questo esempio “SQLFCIDR\DC2”) è ancora la replica primaria.
Notare inoltre il simbolo di “Pausa” accanto a ogni database di disponibilità sotto la cartella Database di
disponibilità.
A questo punto è necessario valutare se sia necessario recuperare eventuali dati (ovvero le modifiche
apportate ai dati nella replica primaria originale non inviate alla replica DR appena prima del verificarsi
dell'emergenza) o procedere con la riattivazione delle sessioni di replica.
Attenzione: la ripresa delle repliche del gruppo di disponibilità in questa fase potrebbe provocare la
perdita di dati. Se tale perdita non è accettabile, è necessario recuperare i dati prima di riprenderne lo
spostamento. Per contro, se non si riprende l'attività del gruppo di disponibilità, i file di log delle transazioni
continuano ad aumentare di dimensione nei database di replica di DR.
Un metodo per recuperare i dati consiste nel creare uno snapshot del database nei database secondari
sospesi (ovvero i database primari originali) allo scopo di estrarre i dati appropriati necessari per la
risincronizzazione con la versione della replica di DR dei database di disponibilità. Nell'esempio seguente
viene mostrato come creare uno snapshot del database in un database di disponibilità con stato “Non in
sincronizzazione”.
-- Create the database snapshot
CREATE DATABASE AppDB_A1 ON
( NAME = AppDB, FILENAME =
'R:\MSSQL11.MSSQLSERVER\MSSQL\Data\AppDB_A1.ss' )
AS SNAPSHOT OF AppDB;
GO
34
È ora possibile estrarre i dati richiesti dallo snapshot del database e inserirli in modo appropriato nella
replica primaria attuale, prima di procedere con la ripresa dello spostamento dei dati.
Nota: per ulteriori informazioni sui rischi della forzatura del failover e sulla riduzione della
perdita di dati, vedere Failover e modalità di failover (gruppi di disponibilità AlwaysOn).
Una volta valutata e risolta in modo soddisfacente la questione della perdita di dati e giunto il momento
di ripristinare il servizio nel data center primario, il passaggio successivo consiste nel riportare in modo
controllato il ruolo di replica primaria al data center primario:
1. Avviare la migrazione controllata di ritorno al data center primario aggiungendo nuovamente
i voti del quorum ai due nodi del data center primario. Dopo avere configurato questa
impostazione, verificare di nuovo che tutti i nodi nel cluster WSFC possiedano un voto.
2. Per riprendere le sessioni di ogni database che fa parte del gruppo di disponibilità, eseguire una
serie di comandi ALTER DATABASE di Transact-SQL sull'istanza del cluster di failover del data
center primario. Esempio:
ALTER DATABASE AppDB SET HADR RESUME;
GO
ALTER DATABASE ConfigDB SET HADR RESUME;
GO
ALTER DATABASE ReportDB SET HADR RESUME;
GO
3. Per effettuare la sincronizzazione prima del failover, modificare il gruppo di disponibilità
nell'istanza del cluster di failover di DR in modo da utilizzare temporaneamente la modalità di
disponibilità con commit sincrono. Idealmente, il commit sincrono deve essere impostato
durante un periodo di bassa attività dell'applicazione per ridurre l'impatto sugli utenti della
latenza delle transazioni.
Di seguito è riportato un esempio del comando Transact-SQL (eseguito sull'istanza del cluster di
failover primaria attuale nel data center di ripristino di emergenza), dove AG1 è il gruppo di
disponibilità e la replica nel data center primario è definita come SQLFCIPrimary\INST_A.
USE [master]
GO
ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON N'SQLFCIPrimary\INST_A' WITH
(AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
GO
Nella stessa sessione di SQL Server Management Studio eseguire il comando riportato di seguito
per impostare il commit sincrono anche sulla replica di DR.
USE [master]
GO
ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON N'SQLFCIDR\INST_B' WITH
35
(AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
GO
4. Verificare lo stato della sincronizzazione tra le due posizioni. Per proseguire con il passaggio
successivo è necessario che lo stato delle due repliche sia “Integro”, a indicare che le repliche,
entrambe con commit sincrono, sono sincronizzate.
SELECT
role_desc,
synchronization_health_desc
FROM sys.dm_hadr_availability_replica_states;
5. Per eseguire il failover dall'istanza del cluster di failover del data center di ripristino di
emergenza all'istanza del cluster di failover del data center primario precedente, connettere ed
eseguire lo script riportato di seguito sull'istanza del cluster di failover del data center primario
che diventerà la nuova replica primaria.
ALTER AVAILABILITY GROUP [AG1] FAILOVER;
6. Se la topologia in uso è impostata sulla modalità a prestazioni elevate, come detto in precedenza,
impostare di nuovo il nodo della replica dell'istanza del cluster di failover di ripristino di
emergenza sul commit asincrono. Eseguire il comando Transact-SQL riportato di seguito sulla
replica primaria.
USE [master]
GO
ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON N'SQLFCIDR\INST_B' WITH
(AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT);
GO
USE [master]
GO
ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON N'SQLFCIPrimary\INST_A' WITH
(AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT);
GO
7. Rimuovere i voti del quorum dai nodi di ripristino di emergenza.
36
Nella tabella seguente viene riepilogato il flusso di lavoro del ripristino di emergenza descritto in
precedenza, indicando le aree che tipicamente rientrano nella competenza dei vari ruoli aziendali dal
punto di vista della pianificazione.
Passaggio
1. Dopo il ripristino del servizio,
dei nodi e delle istanze del
cluster di failover del data
center primario, aggiungere di
nuovo i voti del quorum ai nodi
primari originali.
2. Riprendere le sessioni dei
database di disponibilità su
ogni replica secondaria.
3. Impostare la replica
dell'istanza del cluster di
failover di ripristino di
emergenza e la replica
dell'istanza del cluster di
failover del data center
primario sul commit sincrono.
4. Verificare lo stato della
sincronizzazione tra le due
posizioni. Per proseguire con il
passaggio successivo
è necessario che lo stato di
entrambe le repliche sia
“Integro”.
5. Eseguire il failover a una
replica dell'istanza del cluster
di failover nel data center
primario.
6. Ripristinare il commit asincrono
nella replica di ripristino di
emergenza (per la
corrispondenza con la
configurazione originale).
7. Rimuovere i voti dai nodi WSFC
di DR.
Tabella 4: ripristino del data center primario
37
Amministratore
del database
Amministratore di
Windows
Server/del cluster
Sì
Sì
Sì
Sì
Sì
Sì
Sì
Amministratore
di rete
Conclusione
È possibile utilizzare i gruppi di disponibilità AlwaysOn di SQL Server 2012 per sostituire il mirroring del
database nelle topologie che utilizzano le istanze del cluster di failover per la disponibilità elevata e il
mirroring del database per il ripristino di emergenza. Questo modello di progettazione offre funzionalità
più ampie rispetto a quelle delle versioni precedenti, consentendo l'uso di unità di failover con più
database, repliche di sola lettura e altro ancora. Lo scopo di questo white paper è stato presentare una
nuova soluzione per HA e DR basata su istanze del cluster di failover AlwaysOn e gruppi di disponibilità
AlwaysOn per sostituire l'architettura legacy.
Il successo della distribuzione di una soluzione HA/DR di questo tipo dipende non solo dal team di
amministrazione del database, ma anche dalla stretta collaborazione tra tale team, il team di
amministrazione di Windows Server e il team dei servizi di rete dell'organizzazione IT. Lo scambio di
informazioni e il supporto incrociato delle competenze sono di estrema importanza nella distribuzione
della soluzione HA/DR.
Riferimenti
38
Modelli di progettazione per la disponibilità elevata e il ripristino di emergenza di SQL Server 2012
AlwaysOn (http://go.microsoft.com/fwlink/?LinkId=255048)
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di
emergenza (http://msdn.microsoft.com/library/hh781257.aspx)
Istanze del cluster di failover AlwaysOn (SQL Server)
(http://technet.microsoft.com/library/ms189134.aspx)
Panoramica di Gruppi di disponibilità AlwaysOn (SQL Server)
(http://technet.microsoft.com/library/ff877884(v=SQL.110).aspx)
Clustering di failover e gruppi di disponibilità AlwaysOn (SQL Server)
(http://technet.microsoft.com/library/ff929171.aspx)
Prerequisiti, restrizioni e consigli per i gruppi di disponibilità AlwaysOn (SQL
Server)(http://technet.microsoft.com/library/ff878487(v=sql.110).aspx)
Guida dettagliata sui cluster di failover: configurazione del quorum in un cluster di failover
(http://technet.microsoft.com/library/cc770620(v=WS.10).aspx)
Hotfix di Windows Server per i voti del quorum (http://support.microsoft.com/kb/2494036)
Windows PowerShell (http://technet.microsoft.com/library/bb978526)
Mapping dei comandi di Cluster.exe ai cmdlet di Windows PowerShell per i cluster di failover
(http://technet.microsoft.com/library/ee619744(v=WS.10).aspx)
Manuale di riferimento di base per Windows PowerShell
(http://social.technet.microsoft.com/wiki/contents/articles/183.windows-powershell-survivalguide-it-it.aspx)
Cmdlet specifici per i cluster di failover in Windows PowerShell
(http://technet.microsoft.com/library/ee461009.aspx)
SQL Server PowerShell (http://msdn.microsoft.com/it-it/library/hh245198.aspx)
Per ulteriori informazioni
Sito Web SQL Server (http://www.microsoft.com/italy/server/sql/)
TechCenter di SQL Server (http://technet.microsoft.com/it-it/sqlserver/)
Risorse online per gli sviluppatori di SQL Server (http://msdn.microsoft.com/it-it/sqlserver/)
Il documento è risultato utile? Esprimere una valutazione utilizzando una scala compresa tra
1 (scarso) e 5 (eccellente), indicandone i motivi. Ad esempio:
La valutazione è alta perché il documento contiene esempi validi, catture di schermate
nitide, spiegazioni chiare o altri motivi?
La valutazione è bassa perché il documento contiene esempi confusi, catture di
schermate sfocate, spiegazioni poco chiare?
I commenti aiuteranno Microsoft a migliorare la qualità dei white paper pubblicati.
Commenti e suggerimenti
39
