Quando si parla di rivedere e Office 365 con i clienti, volevo avere una serie di post per illustrare le fasi durante la distribuzione di Office 365. Nelle bozze fiorenti cartella ADFS era in cima, in modo che ha fatto finito prima!
L'atto di distribuzione e la configurazione ADFS 2012 R2 per Office 365 sarà suddiviso in tre post del blog separati
Installare ADFS (questo post)
Installare ADFS Proxy
ADFS leva con Office 365
Identità, Identità, Identità
Il panorama della sicurezza informatica continua evoluzione. Uno dei recenti cambiamenti è un allontanamento da ACL sul file nel file system NTFS di un sistema di controllo di accesso basato sui crediti. Claims autenticazione basata è un settore protocollo di sicurezza standard di per autenticare gli utenti. Questa è la standard WS- * sottostanti che descrivono l'uso di Security Assertion Markup Language (SAML) gettoni. Reclami auth base richiede questi token, e per estensione un'entità che può emettere il token. Questa è la sicura Token Service (STS). Il server STS può essere basata su Active Directory Federation Services (ADFS) o altre piattaforme che forniscono questo servizio.
ADFS illumina una delle tre opzioni per la gestione delle identità Office 365, che è l'opzione # 3 nella lista qui sotto:
Nube Identity - gli utenti sono creati, e gestito, in Windows Azure Active Directory (Waad). Nessun collegamento a qualsiasi altra directory. Questo è il modello più semplice in quanto non c'è integrazione a qualsiasi altra directory. Ogni utente ha un account creato nel cloud che non sincronizzare altrove. Si noti che è ancora in genere bisogno di ulteriori credenziali locali per accedere a una postazione di lavoro locale e le risorse locali.
Directory Sincronizzazione - Gli utenti vengono creati e gestiti nella directory locale e sincronizzate fino a Office 365 in modo che possano accedere alle risorse di Office 365. In genere questo significa correre l'apparecchio DirSync, o in alcuni casi FIM con Windows Azure Active Directory Connector. La build più recenti di DirSync consentire hash della password dell'utente per essere sincronizzato fino a Office 365. Nota questo non lo dice chiaro la password di testo. Questo permette all'utente di accedere al di Office 365 utilizzando le stesse credenziali come on-premises con nessuna infrastruttura aggiuntiva.
Federated Identity - Federazione si basa sulla sincronizzazione delle directory in modo che Waad è popolato. Quando la richiesta di autenticazione viene presentato Office 365, il servizio sarà quindi contattare l'infrastruttura on-premises ADFS in modo che AD è responsabile per l'autenticazione della richiesta.
ADFS è la scelta primaria per i clienti che desiderano utilizzare le identità federate con Office 365. Oltre a questo ci sono una varietà di fornitori di identità terzi qualificati che può essere collegato con Office 365 per fornire l'impianto idraulico necessario per la federazione. Il collegamento URL aka.ms/SSOProviders link ai 'funziona con Office 365' programma Identity, ed elenca i provider di identità che si sono qualificati con Office 365. Si prega di leggere le note sulla pagina TechNet per quanto riguarda gli aspetti di analisi e di supporto di questi servizi.
Alcuni clienti potranno utilizzare questi servizi in quanto non vogliono investire in un errore di implementazione ADFS tollerante e geograficamente dispersa. La disponibilità di ADFS è un punto di discussione fondamentale quando si parla di federazione. Per qualsiasi motivo, se l'infrastruttura ADFS non è disponibile, quindi Office 365 non può completare il processo di autenticazione e quindi gli utenti non possono accedere a Office 365.
Inoltre dal DirSync ora replica la password hash dell'utente a Waad, alcuni clienti utilizzano ora DirSync fornire Same Sign On / Single Sign On (SSO). DirSync versione 1.0.6385.12, che è stato pubblicato nel maggio 2013, e quest'ultimo costruisce fornire la possibilità di sincronizzare le password. DirSync può essere scaricato qui , e il TechNet Wiki ha dettagli sulla storia di rilascio. Quando si esegue la procedura guidata di configurazione con questa release si otterrà la finestra lucido "Sincronizzazione Password":
Windows Azure Active Directory Sync Tool Abilita sincronizzazione password
Questo vale la pena di menzionare in quanto vi è ancora una percezione che ADFS è un requisito difficile da ottenere SSO. Questo è soooooooooooo Q1 2013!
Comunque, sto divagando torniamo ad ADFS ... ..
Noi guardiamo l'installazione di ADFS 2012 R2 in quanto ci sono numerose caratteristiche interessanti di questa versione!
Cosa c'è di nuovo e migliorato In ADFS 2012 R2
La risposta più immediata è molto! Alcuni esempi includono:
La dipendenza IIS rimosso
Opzione di installazione del server singolo rimossa e ora hanno unico per azienda di installazione (consigliato installare una fattoria sempre in release precedente comunque)
Indipendente ruolo delega ADFS rimosso. ADFS delega ora basato off Application Proxy Web (WAP), e viene utilizzato per pubblicare il server ADFS a Internet. WAP può pubblicare molte altre applicazioni, non solo ADFS.
ADFS extranet lockout - aggiunge la protezione di blocco account sul proxy ADFS
Controllo di accesso in base alla posizione di rete per controllare l'autenticazione dell'utente per ADFS
Ci sono molti altri, ma controllare qui per loro dal momento che ci concentriamo su Office 365 utilizzo per ADFS.
Si noti che non mi vedrete chiamo questa versione ADFS 3.0. Il suo nome completo e corretto è ADFS 2012 R2. per riferimento qui sono le versioni precedenti e quello che alcune persone li chiamano:
ADFS Costruire
Note
ADFS 1.0 Rilasciato con Windows 2003 R2. Costruito in OS.
ADFS 1.1 Rilasciato con Windows 2008 e 2008 R2. Costruito in OS.
ADFS 2.0 Rilasciato Dopo che Windows 2008/2008 R2. Download separato da qui .
ADFS 2.1 Di Windows 2012
ADFS 3.0 Di Windows 2012 R2
Aggiornamento 2014/05/05: Si veda anche questo post su esplorare ADFS 2012 R2 protezione Extranet Lockout.
Aggiornare 29-5-2014: Ti invitiamo anche aggiornamento 2.948.086 aggiornamento che migliora AD FS proxy e STS affidabilità in Windows Server 2012 R2 quando più client accedi .
Aggiornamento 2014/09/09: Per gli altri messaggi su ADFS, si prega di consultare il tag cloud .
Pianificazione E Prerequisiti e altri Fun Dettagli
Prerequisiti
I prerequisiti sono elencati su TechNet . Naturalmente prima di saltare in installare l'installazione deve essere pianificata.
ADFS Ruolo Pianificazione
Il ruolo ADFS deve essere implementato all'interno della rete aziendale, e non nella DMZ. Il ruolo di proxy ADFS è destinato ad essere installato nella DMZ.
La topologia di default per Active Directory Federation Services (ADFS) è un server farm federativa, utilizzando il database interno di Windows (WID), che consiste di un massimo di cinque server federativi ospitano Federation servizio dell'organizzazione. In questa topologia, AD FS usa WID come il negozio per il database di configurazione di AD FS per tutti i server federativi che fanno parte di tale azienda. L'azienda replica e mantiene i dati Servizio federativo nel database di configurazione su ogni server della farm.
Dal momento che la disponibilità di Office 365 si basa sulla disponibilità di ADFS quando il dominio è federato c'è una forte raccomandazione di avere almeno due server ADFS con un'infrastruttura delega ADFS ridondante.
Si prega di leggere la guida di progettazione su TechNet.
Account ADFS Servizio
Ora possiamo utilizzare un account di servizio standard o un account di servizio gruppo gestito in ADFS 2012 R2.
In questo caso, poiché la chiave principale KDS non è stato configurato, consente di sfruttare un account di servizio standard.
Il processo di installazione dovrebbe impostare il servizio richiesto nomi principali (SPN) sul conto.
Namespace ADFS
Selezionare quale nome si è da utilizzare per accedere ADFS. In genere questo è lungo le linee di:
sts.wingtiptoys.ca
adfs.tailspintoys.ca
Si noti che questo è lo spazio per il servizio ADFS. Dal saremo utilizzando Kerberos per accedere ADFS all'interno, ci deve essere un Service Principle Name (SPN) registrato per questo nome. Questo sarà associato all'account del servizio, e dal momento che SPN operano in "Highlander - non ci può essere solo uno!" Modo non si vuole duplicare il SPN sul server ADFS nominando il computer lo stesso spazio dei nomi ADFS.
Anche voi volete discutere di ciò che il nome visualizzato deve essere scelto, in quanto questo sarà visibile agli utenti.
Certificati
Dal ADFS sfrutta SSL, abbiamo bisogno di avere un certificato SSL. Si potrebbe provare a tre opzioni, ma solo uno funzionerà:
Un'autocertificazione
Certificato rilasciato da PKI interna
Certificato dal 3rd party CA pubblica
Office 365 ha bisogno di vedere un valido certificato Servizio di Comunicazione sull'infrastruttura ADFS, in modo che si sta per comprare un certificato da una CA pubblica Office 365 non fidarsi di un certificato di comunicazione di servizio che è o auto-firmato o dalla CA interna, che si traduce in lacrime. Siamo in grado di utilizzare i certificati autofirmati per il Token Decrypting e Token certificato di firma . Questi sono separati dal cert comunicazione di servizio.
Si prega di seguire la documentazione del CA scelto di richiedere, installare e completare il certificato. I passi necessari variano da fornitore a fornitore e anche nel tempo. Assicurarsi che non mancano i certificati intermedi aggiornati! Come lo sai? Seguire il loro processo !!
Ai fini di questo post vedremo distribuire il server ADFS iniziale, e in futuro aggiungere un altro server ADFS per la ridondanza.
Installazione di ADFS In Windows Server 2012 R2
Dopo l'avvio aggiungere ruoli e funzionalità wizard di server manager, selezionare Active Directory Federation Services, quindi fare clic su Avanti.
ADFS 2012 R2 Installazione di ruoli
Non abbiamo bisogno di aggiungere qualsiasi funzionalità aggiuntive. Ricordate che la dipendenza IIS è stato rimosso in ADFS 2012 R2.
ADFS 2012 R2 Installazione di ruoli
Facendo clic accanto ci porta alla schermata di ADFS spruzzata. Si noti che ci dice utilmente che il ruolo specifico di proxy ADFS è stata rimossa in Windows 2012 R2 e come fare per installarlo. Peccato che ho perso la prima volta ho incontrato questo, e non riusciva a trovare la vecchia scuola ruolo ADFS Proxy ...
ADFS 2012 R2 Installazione di ruoli
Cliccando prossima sarà quindi installare i bit necessari.
ADFS 2012 R2 Installazione Ruolo Conferma
I bit vengono mescolate in giro ...
ADFS 2012 R2 Installazione Ruolo In Progress
Shuffling è stata completata, e l'installazione è completa. È possibile avviare la procedura guidata di configurazione di ADFS da qui, oppure se questa finestra viene chiusa può essere lanciato dal gestore del server.
ADFS 2012 R2 Installare Role
Prima di avviare la procedura guidata di configurazione di ADFS Ho già installato il mio certificato 3rd party e provato che è stato installato correttamente.
Inoltre, un account di servizio denominato ADFS-Service è stato anche pre-creato.
La procedura guidata afferma inoltre che è necessario avere accesso al Domain Admin (DA) credenziali!
Si noti che si è data solo la possibilità di procedere a nuova farm ADFS o aggiungere questa casella per una farm esistente. Ciò consente di risparmiare il problema doloroso da ADFS anziani costruisce, dove ADFS non è stato installato in una farm si erano poi in grado di facilità la aggiungere il secondo server ADFS per la ridondanza.
ADFS 2012 R2 Installazione Schermata di benvenuto
Fornire le credenziali di amministratore di dominio.
ADFS 2012 R2 Installare Connect To AD
Abbiamo bisogno di selezionare il certificato SSL che useremo e anche fornire il nome ADFS abbiamo selezionato nel processo di progettazione.
In questo caso il nome è adfs.tailspintoys.ca - notare che non esiste il concetto di InternalURL o ExternalURL per lo spazio dei nomi ADFS. I clienti potranno utilizzare lo stesso nome sulla rete intranet e internet per individuare ADFS. Così DNS divisione renderà la vita semplice!
Fornire il nome visualizzato prescelto, e fare clic su Avanti.
ADFS 2012 R2 Installare specificare le proprietà di servizio
Come accennato in precedenza, è possibile utilizzare un GMSA come account di servizio ADFS. GMSA aggiornerà automaticamente le credenziali di account di servizio e amministratori sarà anche ignari circa la sua password.
In questo caso è stato utilizzato un account di servizio standard.
ADFS 2012 R2 Installare Specifica account di servizio
Selezionare la configurazione database come da progetto.
La società Tailspintoys utilizzerà WID.
ADFS 2012 R2 Installa Specificare Database
Rivedere le opzioni, e quando felici tirare il grilletto!
ADFS 2012 R2 Opzioni di installazione Recensione
Per riferimento lo script PowerShell è mostrato qui:
#
# script di Windows PowerShell per AD FS Deployment
#
Import-Module ADFS
# Ottenere le credenziali utilizzate per l'account del servizio federativo
$ serviceAccountCredential = Get-Credential -message "Immettere le credenziali per l'account di servizio della Federazione."
Installare-AdfsFarm `
-CertificateThumbprint: "5804746A7980C8682FBF408D48EF6C3B02A5ZORG" `
-FederationServiceDisplayName: "Tailspintoys STS" `
-FederationServiceName: "adfs.Tailspintoys.ca" `
-ServiceAccountCredential: $ serviceAccountCredential
Il ADFS controlli pre-requisito sono fatto, e possiamo procedere alla configurazione:
ADFS 2012 R2 Installare Controlli pre-requisito completati
Un caffè più tardi, abbiamo un nuovo server ADFS lucido - Whoo !!
ADFS 2012 R2 Installazione completata
Non siamo ancora del tutto finito, e un paio di cose aggiuntive che facciamo!
Passi successivi
ADFS Aggiornamento (s)
Aggiornare 29-5-2014: Ti invitiamo anche aggiornamento 2.948.086 aggiornamento che migliora AD FS proxy e STS affidabilità in Windows Server 2012 R2 quando più client accedi .
Aggiornamento 2014/11/12: questo aggiornamento 2.948.086 è ora fornito in questo rollup: maggio 2014 aggiornamento cumulativo per Windows RT 8.1, Windows 8.1 e Windows Server 2012 R2
Aggiornamento 16-7-2014: altri aggiornamenti si consiglia di rivedere sono in fondo a questo post .
Quando più client (oltre 200 client) tentano di accedere utilizzando una Directory Federation Services (ADFS) delega attiva, il proxy AD FS consuma l'utilizzo al 100% della CPU. In questa situazione, l'AD prestazioni delega FS è lenta, e provoca un ritardo che supera 10 secondi. Questo fa sì che anche STS a lavorare sotto carico minimo. Pertanto, STS rifiuta le richieste o serve solo 5 a 10 richieste al secondo.
DNS A Record
Dobbiamo creare il record DNS per l'istanza di ADFS. Questa mappa al namespace ADFS che abbiamo precedentemente programmato. Creare questo record nell'infrastruttura DNS interno.
Una volta che il record DNS è stato creato un propagato assicurarsi che risolve correttamente.
Una cosa da ricordare qui, se si crea un CNAME e punto che al server che ospita ADFS è probabile che vi imbatterete in una autenticazione senza fine la situazione pronta.
Nell'esempio che segue lo spazio dei nomi ADFS è chiamato adfs.tailspintoys.ca e CNAME è stato utilizzato per il traffico diretto al server ADFS chiamato tail-ca-sts.tailspintoys.ca. Ciò probabilmente causerà il client per ottenere un ticket Kerberos per il nome non corretto.
ADFS risoluzione dei nomi Utilizzando DNS CNAME Record
Il modo più semplice per fermare questo è quello di utilizzare un normale un record, in questo modo:
ADFS risoluzione dei nomi Utilizzando DNS A Record
C'è anche una opzione contenuta in KB 911149 che alcune persone hanno già detto.
Passaggi aggiuntivi
Questo argomento riguarda ulteriori passaggi per configurare ADFS dopo aver installato il primo server federativo, tra cui:
Apertura del ADFS Gestione snap-in
Configurazione della risoluzione dei nomi per AD FS Servizi
Aggiunta di nodi alla fattoria
Aggiunta di un proxy Web Application
Attivazione dispositivo Registration Service
Per ulteriori informazioni su come distribuire ADFS, vedere Come distribuire ADFS in Windows Server 2012 R2 .
Verificare Federazione Service Metadata
Aprite Internet Explorer e raggiungere l'URL metadati federazione del server ADFS.
Sarà qualcosa di simile al di sotto, basta cambiare il nome di dominio in base all'ambiente.
https://adfs.tailspintoys.ca/federationmetadata/2007-06/federationmetadata.xml
https://sts.contoso.com/federationmetadata/2007-06/federationmetadata.xml
Il risultato dovrebbe mostrare questo:
Test ADFS Federazione Metadata
Verificare ADFS pagina di accesso
Individuare il ADFS pagina di accesso e di test che si è in grado di autenticare.
L'URL sarà simile al di sotto, ancora una volta cambiare il nome di dominio completo per abbinare l'organizzazione di.
https://adfs.tailspintoys.ca/adfs/ls/idpinitiatedsignon.htm
https://sts.contoso.com/adfs/ls/idpinitiatedsignon.htm
Si dovrebbe vedere il seguito, e che venga richiesto di firmare in:
ADFS 2012 R2 Sign-In Pagina
A seconda di come è configurato IE si sia richiesto di fornire le credenziali o essere-in firmato automaticamente.
Se si desidera avere utenti da firmare-in automatico quindi configurare le impostazioni del browser a fidarsi del ruolo server federativo aggiungendo il nome del servizio federativo (ad esempio, https: //adfs.tailspintoys.c una ) per Intranet locale del browser. Ciò consentirà seamless segno-in utilizzando l'autenticazione integrata di Windows.
ADFS 2012 R2 Abilitazione Sign-in automatico per Intranet locale
Una volta che siamo felici che l'istanza ADFS funziona in modo appropriato possiamo passa poi sulla installazione del ruolo del proxy ADFS.
Questo sarà coperto in un post a parte, per evitare che questo si ottiene troppo lungo!
Saluti,
Rhoderick
lunedì 26 gennaio 2015
giovedì 15 gennaio 2015
BSOD Perpetual su Windows 7 Enterprise macchina
iao ragazzi, ho un Dell Optiplex 780 con Windows 7 Enterprise che mi rende duri giorni cercando di ottenere sano. C'è un BSOD di tanto in tanto, e in fondo alla settimana, se non ogni giorno e mi could't sbarazzarsi di esso.
Il registro è:
Microsoft (R) Windows Debugger versione 6.2.9200.16384 X86
Copyright (c) Microsoft Corporation. . Tutti i diritti riservati Caricamento Dump File [\\ EB-OR1019945 \ c $ \ Windows \ Minidump \ 011515-11310-01.dmp] Mini Kernel File: Solo registri e stack sono disponibiliSymbol percorso di ricerca è: SRV *; c : \ Simboli percorso di ricerca è eseguibile: SRV * Windows 7 Kernel Version 7601 (Service Pack 1) MP (2 procs) Libera x64 prodotto: WinNt, Suite: TerminalServer SingleUserTS Costruito da: 7601.18409.amd64fre.win7sp1_gdr.140303-2144 Nome macchina: Base Kernel = 0xfffff800`03010000 PsLoadedModuleList = 0xfffff800`03253890 Debug tempo di sessione: Gio 15 Gen 09: 47: 28,179 2015 (UTC + 2:00) Sistema Uptime: 0 giorni 10: 53: 13,263 Loading Kernel Simboli Utente Caricamento lista modulo scaricato ...... ************************************** ***************************************** * * * Analisi Bugcheck * * * * ************************************************** **************************** Usa! analizzare -v per ottenere informazioni dettagliate di debug. BugCheck 1, {77a1132a, 0, ffff, fffff88009921c60 }Probabilmente causata da: ntkrnlmp.exe (! nt KiSystemServiceExit + 245) Followup: MachineOwner --------- 0: kd> analizzare -v *************** ************************************************** ************** * ** Analisi Bugcheck * * * **************************** ************************************************** *APC_INDEX_MISMATCH (1) Si tratta di un errore interno del kernel. La ragione più comune per vedere questo controllo errori è quando un file system o un driver ha un numero non corrispondenti dichiamate per disattivare e riattivare APC. Il dato fondamentale è la filettatura> campo CombinedApcDisable. Questo è costituito da due a 16 bit separati campi, la SpecialApcDisable e KernelApcDisable. Un valore negativo di uno indica che il conducente ha disattivato APC speciali o normali (rispettivamente) senza re-permettendo loro; un valore positivo indica che un pilota ha permesso APC speciali o normali (rispettivamente) troppe volte. Argomenti: Arg1: 0000000077a1132a, Indirizzo della funzione chiamata di sistema o lavoratore di routine Arg2: 0000000000000000, filettatura> ApcStateIndex Arg3: 000000000000ffff, (filettatura> SpecialApcDisable << 16) | filettatura> KernelApcDisable Arg4: fffff88009921c60, chiamata tipo (0 - chiamata di sistema, 1 - di routine lavoratore) Debug Dettagli: ------------------ FAULTING_IP: +0 00000000`77a1132a ?? ???CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT BUGCHECK_STR: 0x1nome_processo: svchost.exe CURRENT_IRQL: 0 LAST_CONTROL_TRANSFER: dal fffff80003085169 a fffff80003085bc0 STACK_TEXT: fffff880`09921a28 fffff800`03085169: 00000000`00000001 00000000`77a1132a 00000000`00000000 00000000`0000ffff: nt! KeBugCheckEx fffff880`09921a30 fffff800`030850a0: 00000000`00000000 0000007f`ffffffff 00000000`00000000 00000980`00000000: nt KiBugCheckDispatch + 0x69 fffff880`09921b70 00000000`77a1132a: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000: nt KiSystemServiceExit + 0x24500000000`00fbe318 00000000`00000000: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000: 0x77a1132a STACK_COMMAND: kb FOLLOWUP_IP: ! nt KiSystemServiceExit + 245fffff800`030850a0 4883ec50 sub RSP, 50h SYMBOL_STACK_INDEX: 2 nome_simbolico: nt KiSystemServiceExit + 245 FOLLOWUP_NAME: MachineOwner NOME_MODULO: nt nome_immagine: ntkrnlmp.exe DEBUG_FLR_IMAGE_TIMESTAMP: 531590fb FAILURE_BUCKET_ID: X64_0x1_SysCallNum_4_nt KiSystemServiceExit + 245 BUCKET_ID: X64_0x1_SysCallNum_4_nt KiSystemServiceExit + 245! Followup: MachineOwner
Copyright (c) Microsoft Corporation. . Tutti i diritti riservati Caricamento Dump File [\\ EB-OR1019945 \ c $ \ Windows \ Minidump \ 011515-11310-01.dmp] Mini Kernel File: Solo registri e stack sono disponibiliSymbol percorso di ricerca è: SRV *; c : \ Simboli percorso di ricerca è eseguibile: SRV * Windows 7 Kernel Version 7601 (Service Pack 1) MP (2 procs) Libera x64 prodotto: WinNt, Suite: TerminalServer SingleUserTS Costruito da: 7601.18409.amd64fre.win7sp1_gdr.140303-2144 Nome macchina: Base Kernel = 0xfffff800`03010000 PsLoadedModuleList = 0xfffff800`03253890 Debug tempo di sessione: Gio 15 Gen 09: 47: 28,179 2015 (UTC + 2:00) Sistema Uptime: 0 giorni 10: 53: 13,263 Loading Kernel Simboli Utente Caricamento lista modulo scaricato ...... ************************************** ***************************************** * * * Analisi Bugcheck * * * * ************************************************** **************************** Usa! analizzare -v per ottenere informazioni dettagliate di debug. BugCheck 1, {77a1132a, 0, ffff, fffff88009921c60 }Probabilmente causata da: ntkrnlmp.exe (! nt KiSystemServiceExit + 245) Followup: MachineOwner --------- 0: kd> analizzare -v *************** ************************************************** ************** * ** Analisi Bugcheck * * * **************************** ************************************************** *APC_INDEX_MISMATCH (1) Si tratta di un errore interno del kernel. La ragione più comune per vedere questo controllo errori è quando un file system o un driver ha un numero non corrispondenti dichiamate per disattivare e riattivare APC. Il dato fondamentale è la filettatura> campo CombinedApcDisable. Questo è costituito da due a 16 bit separati campi, la SpecialApcDisable e KernelApcDisable. Un valore negativo di uno indica che il conducente ha disattivato APC speciali o normali (rispettivamente) senza re-permettendo loro; un valore positivo indica che un pilota ha permesso APC speciali o normali (rispettivamente) troppe volte. Argomenti: Arg1: 0000000077a1132a, Indirizzo della funzione chiamata di sistema o lavoratore di routine Arg2: 0000000000000000, filettatura> ApcStateIndex Arg3: 000000000000ffff, (filettatura> SpecialApcDisable << 16) | filettatura> KernelApcDisable Arg4: fffff88009921c60, chiamata tipo (0 - chiamata di sistema, 1 - di routine lavoratore) Debug Dettagli: ------------------ FAULTING_IP: +0 00000000`77a1132a ?? ???CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT BUGCHECK_STR: 0x1nome_processo: svchost.exe CURRENT_IRQL: 0 LAST_CONTROL_TRANSFER: dal fffff80003085169 a fffff80003085bc0 STACK_TEXT: fffff880`09921a28 fffff800`03085169: 00000000`00000001 00000000`77a1132a 00000000`00000000 00000000`0000ffff: nt! KeBugCheckEx fffff880`09921a30 fffff800`030850a0: 00000000`00000000 0000007f`ffffffff 00000000`00000000 00000980`00000000: nt KiBugCheckDispatch + 0x69 fffff880`09921b70 00000000`77a1132a: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000: nt KiSystemServiceExit + 0x24500000000`00fbe318 00000000`00000000: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000: 0x77a1132a STACK_COMMAND: kb FOLLOWUP_IP: ! nt KiSystemServiceExit + 245fffff800`030850a0 4883ec50 sub RSP, 50h SYMBOL_STACK_INDEX: 2 nome_simbolico: nt KiSystemServiceExit + 245 FOLLOWUP_NAME: MachineOwner NOME_MODULO: nt nome_immagine: ntkrnlmp.exe DEBUG_FLR_IMAGE_TIMESTAMP: 531590fb FAILURE_BUCKET_ID: X64_0x1_SysCallNum_4_nt KiSystemServiceExit + 245 BUCKET_ID: X64_0x1_SysCallNum_4_nt KiSystemServiceExit + 245! Followup: MachineOwner
venerdì 9 gennaio 2015
SQL Server 2012 AlwaysOn- la guida passo passo di Ruggiero Lauria
Ciao a tutti,
Visto che la tecnologia AlwaysOn è una delle novità importante di SQL Server 2012, Ruggiero Lauria si è dedicato a realizzare una guida passo passo che ha voluto condividere anche con voi, appassionati di SQL che volete approfondire il contenuto.
Eccola qui sotto, tutto il contenuto lo trovate anche sul suo Tech Blog. Condividere ha il suo costo, ma alla fine finisce per arricchire tutti ;-)
Introduzione
Una delle più grandi novità introdotte da SQL Server 2012 sotto il profilo dell'alta disponibilità è la tecnologia AlwaysOn.
Questa si suddivide in due tipologie:
AlwaysOn Failover Cluster Instance: Protezione a livello di singola istanza, miglioramento della tradizionale installazione in Cluster di SQL Server nel monitoraggio dello stato di salute e nelle implementazioni Multi-Subnet
AlwaysOn Availability Group: Protezione a livello di Database, evoluzione del DB mirroring delle versioni precedenti di SQL Server
La prima soluzione in termini archietturali poco aggiunge alle precedenti versioni se non l'eliminazione della necessità di creazione di una VLAN per i nodi del cluster; invece i gruppi di diponibilità sono una vera novità, forse uno di quei particolari per cui varrebbe la pena di migrare ad SQL 2012.
AlwaysOn Availability Group
Generale
Questa tecnologia sfrutta i vantaggi offerti dal Windows Server Failover Cluster (WSFC) per fornire una soluzione di alta disponibilità per i Database SQL Server. E' un evoluzione della tecnologia di DB mirroring, introdotta con la versione SQL Server 2005, ma offre questi fondamentali vantaggi aggiuntivi:
Il numero dei nodi non è più limitato a 2
Il failover non è più fatto dal client, ma avviene lato server in maniera trasparente per i client
E' possibile accedere in sola lettura ad un nodo passivo del gruppo di disponibilità
E' possibile eseguire le operazioni di backup su un nodo passivo del gruppo di disponibilità
Nonostante questa tecnologia si basi sul Failover Cluster non è necessario:
Avere uno storage condiviso fra i nodi del cluster
Fare un installazione in Cluster di SQL Server
Quindi ogni nodo avrà un'installazione autonoma di SQL Server con i dati su uno storage locale del nodo.
Note:
In Windows Server 2012 la funzionalità di Failover Cluster è disponibile anche sulla versione Standard
Non esiste nessun problema nel creare nodi virtualizzati, se non le solite raccomandazioni relative al fare girare SQL Server su una macchina virtuale
Terminologia
AlwaysOn Availability Group: gruppo di server (in cluster) che mette in alta disponibilità uno o più Database
Primary Replica: istanza che ospita la copia in lettura e scrittura del Database
Secondary Replica: host che ospita una copia del database su cui è possibile abilitare accessi in sola lettura
Listener: consiste di un nome DNS, una porta TCP ed uno o più indirizzi IP attraverso cui i client si connettono al gruppo di disponibilità
Availability Modes: modalità di replica dei dati fra il membro primario ed i secondari, può essere:
Commit-Synchronous: la replica primaria attende conferma che le modifiche siano state apportate sul membro secondario prima di chiudere la transazione. Affidabile ma pericoloso per le performances
Commit-Asynchronous: il membro primario invia le modifiche al secondario e chiude la transazione senza aspettare conferma sull'esito.Non affidabile ma performante.
Failover: processo attraverso il quale il ruolo di replica primaria viene passato ad una replica secondaria, chiamata failover target. Sono disponibili 3 tipi di failover:
Failover automatico (senza perdita di dati): disponibile quando sia la replica primaria che la secondaria operano in modalità sincrona (Commit-Synchronous). In questo caso la modalità di failover nel gruppo è impostata su automatica ed il passaggio di ruoli avviene senza alcun intervento amministrativo.
Failover manuale pianificato (senza perdita di dati): come nel caso precedente i due membri operano in modalità sincrona, ma non essendo stato impostato il failover automatico è necessario l'intervento amministrativo per inviare il comando di failover.
Failover manuale forzato (con possibile perdita di dati): i due membri di replica operano in modalità asincrona e quindi l'amministratore può forzare il failover sapendo che eventuali transazioni del membro primario non ancora sincronizzate andranno perse.
Active Secondary Replicas: per migliorare le performance e gestire in maniera più efficiente le risorse del gruppo di disponibilità è possibile indirizzare le richieste di sola lettura e backup verso repliche secondarie
Installazione
L'obiettivo di questo articolo è centrato sugli Availability Group e non sulla configurazione del Cluster di Failover, quindi non entrerò nei dettagli su questa parte.
1) Installare la funzionalità di Failover Cluster sui Server
2) Creare un Cluster di Failover che comprenda tutti i Server
nel nostro esempio abbiamo creato un cluster MIA-CLUSTER a cui partecipano i server:
MIA-CLUST1
MIA-CLUST2
MIA-CLUST3
Notare che nel Cluster non c'è Storage condiviso.
3) Installare un'istanza Standalone di SQL Server 2012 su ogni Server
Note:
Usate un account di dominio per il Servizio SQL
Potete installare solo il Motore di Database, opzionalmente anche gli strumenti di gestione
4) Attraverso il Configuration Manager abilitate AlwaysOn Availability Group su ogni Server
Riavviate i servizi di SQL Server
5) Create una condivisione di rete per i file di Backup utilizzati per sincronizzare le repliche
6) Creiamo i DataBase che vogliamo proteggere sul Server che diventerà la Replica Primaria
Nel nostro caso il Server che svolgerà il ruolo di Replica Primaria è MIA-CLUST1 e mettiamo in alta disponibilità il Database Sales
Controllate che il Recovery Model sia Full
7) Facciamo un Backup Full nello Share di cui al punto 5
8) Creiamo un AlwaysOn Avalaibilty Group
Lanciamo il Wizard dal Server Primario
Specifichiamo il nome del nostro AG
Selezioniamo il database Sales
Aggiungiamo le Repliche Secondarie: Add Replica...
Configuriamo il Listener
Impostiamo il Folder per la sincronizzazione
Controlliamo l'esito
Il warning ricevuto relativo al WSFC è trascurabile
Risultato Finale:
Il Database Sales è replicato su tutti e tre i Server
Nel cluster è stato creato un servizio il cui Owner è il nostro Primary Replica
Configurazione
Adesso facciamo un esempio di configurazione.
Entriamo nelle proprietà del nostro Availability Group
Impostiamo MIA-CLUST2 in modalità sincrona ed abilitiamo il failover automatico
Lasciamo MIA-CLUST3 in modalità asincrona, e quindi il failover può essere solo manuale
Rendiamo ambedue le Repliche Secondarie leggibili ed analizziamo meglio le opzioni disponibili.
Ricordiamo che ogni server può potenzialmente agire in due modalità: Primario e Secondario, qui abbiamo le opzioni disponibili per ogni server in base al ruolo che svolge (la situazione può essere dinamica):
Connections in primary role: quando agisce da primario, può accettare tutte le connessioni o solo quelle in scrittura.
Readable Secondary: quando agisce da secondario può non accettare connessioni, accettarle tutte (ma dare errore se si prova a modificare i dati) o accettare solo le connessioni che abbiano esplicitamente Intent=Readonly
Andiamo poi nella sezione Backup Preferences
Lasciamo il default a Prefer Secondary, in questo modo i backup verrano sempre fatti sui secondari, se disponibili.
Cambiamo la priorità del backup mettendo avanti il Server MIA-CLUST3
I risultati delle nostre impostazioni sono anche visibili dalla Dashboard dell' AG
READ-ONLY ROUTING
Dopo aver reso le nostre repliche secondarie leggibili già possible accedervi puntando direttamente al nome del Server.
Esempio di accesso al MIA-CLUST2
Esempio di accesso a MIA-CLUST3 (impostato read-intent only, notare l'errore nel primo tentativo)
Ma se vogliamo creare un meccanismo che indirizzi automaticamente le richieste di sola lettura verso le Repliche Secondarie dobbiamo implementare in Read-Only Routing.
Per la configurazione potete fare riferimento a questo articolo ma riassumendo:
Dobbiamo avere configurato un Listener e noi lo abbiamo fatto nel wizard:
DNS: MIA-SQL-CLUSTER
IP: 10.10.0.40
TCP Port: 1433
Identifichiamo la URL per connessione ad ogni Server membro del nostro AG
Nel nostro caso: TCP://MIA-CLUST1.AdventureWorks.msft:1433
TCP://MIA-CLUST2.AdventureWorks.msft:1433
TCP://MIA-CLUST3.AdventureWorks.msft:1433
Potete utilizzare questo script realizzato da Matt Neerincx che fornisce un output del tipo
Configuriamo i nostri Read_only_routing dando questi comandi sulla nostra Replica Primaria:
___________________ Start ____________________________
-- Configure Read_Only_Routing
-- This script need to be paramatrized with your deployment data!
-- Ruggiero Lauria
-- Enable Server as Readable when acting as Secondary Replica
-- This command is not strictly necessary because we have already configured it
-- trough AG propriety. But for completeness I preferred to include it in the script
ALTER AVAILABILITY GROUP [MIA-SQL-AG]
MODIFY REPLICA ON
N'MIA-CLUST1' WITH
(SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));
-- Define Server Read_only_routing URL
ALTER AVAILABILITY GROUP [MIA-SQL-AG]
MODIFY REPLICA ON
N'MIA-CLUST1' WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://MIA-CLUST1.AdventureWorks.msft:1433'));
-- Enable Server as Readable when acting as Secondary Replica
-- This command is not strictly necessary because we have already configured it
-- trough AG propriety. But for completeness I preferred to include it in the script
ALTER AVAILABILITY GROUP [MIA-SQL-AG]
MODIFY REPLICA ON
N'MIA-CLUST2' WITH
(SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));
-- Define Server Read_only_routing URL
ALTER AVAILABILITY GROUP [MIA-SQL-AG]
MODIFY REPLICA ON
N'MIA-CLUST2' WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://MIA-CLUST2.AdventureWorks.msft:1433'));
-- Enable Server as Readable when acting as Secondary Replica
-- This command is not strictly necessary because we have already configured it
-- trough AG propriety. But for completeness I preferred to include it in the script
ALTER AVAILABILITY GROUP [MIA-SQL-AG]
MODIFY REPLICA ON
N'MIA-CLUST3' WITH
(SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));
-- Define Server Read_only_routing URL
ALTER AVAILABILITY GROUP [MIA-SQL-AG]
MODIFY REPLICA ON
N'MIA-CLUST3' WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://MIA-CLUST3.AdventureWorks.msft:1433'));
ALTER AVAILABILITY GROUP [MIA-SQL-AG]
MODIFY REPLICA ON
N'MIA-CLUST1' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('MIA-CLUST2','MIA-CLUST3')));
-- Define Read Routing List when Server is acting as Primary Replica
ALTER AVAILABILITY GROUP [MIA-SQL-AG]
MODIFY REPLICA ON
N'MIA-CLUST2' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('MIA-CLUST1','MIA-CLUST3')));
-- Define Read Routing List when Server is acting as Primary Replica
ALTER AVAILABILITY GROUP [MIA-SQL-AG]
MODIFY REPLICA ON
N'MIA-CLUST3' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('MIA-CLUST1','MIA-CLUST2')));
GO
_________________End ________________________
Nota: I Server indicati nella routing list verranno usati in sequenza in base alla disponibilità, non esiste alcuna forma di Load Balancing o round robin.
Test di connettività
Di seguito il processo utilizzato dal Read Only Routing:
-- Define Read Routing List when Server is acting as Primary Replica
Il client si connettono al Listener del nostro Availability Group
Il client viene reindirizzato (sempre!) verso la Primary Replica
Il client ha specificato nella stringa di connessione ApplicationIntent=ReadOnly
Il sever controlla che il database di destinazione faccia parte di un Availability Group
Se è vero il punto 4, il server controlla se è impostata una read_only_routing_list sulla Primary Replica
Se è vero il punto 5 il server controlla in ordine che i server elencati nella Routing_List stiano sincronizzando ed accettino connessioni (allow_connections=read_only or all)
Il server legge la read_only_routing_url della prima replica secondaria pronta ad accettare connessioni e la passa al client
Il client legge la URL e si ridireziona verso l'istanza secondaria leggibile
Per eseguire un test di connettività si possono utilizzare i Reporting Services, quindi nel nostro esempio farò un semplice report (l'esempio è banale!) sulla tabella sales.dbo.orders includendo il nome del server che sta rispondendo con la seguente query:
Select OrderDate, OrderTotal, @@ServerName as Server from Orders
Primo Test: accediamo con ApplicationIntent=ReadWrite
E riceviamo risposta dalla Primary Replica
Adesso cambiamo il tipo di connessione in ApplicationIntent=ReadOnly
E rilanciando il report
Siamo stati reindirizzati verso il primo server della routing list definita per Primary Replica:
ALTER AVAILABILITY GROUP [MIA-SQL-AG]
MODIFY REPLICA ON
N'MIA-CLUST1' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('MIA-CLUST2','MIA-CLUST3')));
Comandi Utili
Esempio di stringa di connessione:
Server=tcp:MIA-SQL-CLUST,1433;Database=Sales;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly;MultiSubnetFailover=True
Restart del listener
ALTER AVAILABILITY GROUP [MIA-SQL-AG] RESTART LISTENER 'MIA-SQL-CLUST';
Related System Views
SELECT * FROM sys.dm_tcp_listener_states
SELECT * from sys.availability_replicas
SELECT * from sys.availability_read_only_routing_lists
Conclusione
Spero che questa guida passo passo possa esservi di aiuto per sfruttare appieno questa opportunità che ci viene offerta da SQL Server 2012.
Tutte le correzioni ed i commenti sono i benvenuti.
Buon divertimento!
Visto che la tecnologia AlwaysOn è una delle novità importante di SQL Server 2012, Ruggiero Lauria si è dedicato a realizzare una guida passo passo che ha voluto condividere anche con voi, appassionati di SQL che volete approfondire il contenuto.
Eccola qui sotto, tutto il contenuto lo trovate anche sul suo Tech Blog. Condividere ha il suo costo, ma alla fine finisce per arricchire tutti ;-)
Introduzione
Una delle più grandi novità introdotte da SQL Server 2012 sotto il profilo dell'alta disponibilità è la tecnologia AlwaysOn.
Questa si suddivide in due tipologie:
AlwaysOn Failover Cluster Instance: Protezione a livello di singola istanza, miglioramento della tradizionale installazione in Cluster di SQL Server nel monitoraggio dello stato di salute e nelle implementazioni Multi-Subnet
AlwaysOn Availability Group: Protezione a livello di Database, evoluzione del DB mirroring delle versioni precedenti di SQL Server
La prima soluzione in termini archietturali poco aggiunge alle precedenti versioni se non l'eliminazione della necessità di creazione di una VLAN per i nodi del cluster; invece i gruppi di diponibilità sono una vera novità, forse uno di quei particolari per cui varrebbe la pena di migrare ad SQL 2012.
AlwaysOn Availability Group
Generale
Questa tecnologia sfrutta i vantaggi offerti dal Windows Server Failover Cluster (WSFC) per fornire una soluzione di alta disponibilità per i Database SQL Server. E' un evoluzione della tecnologia di DB mirroring, introdotta con la versione SQL Server 2005, ma offre questi fondamentali vantaggi aggiuntivi:
Il numero dei nodi non è più limitato a 2
Il failover non è più fatto dal client, ma avviene lato server in maniera trasparente per i client
E' possibile accedere in sola lettura ad un nodo passivo del gruppo di disponibilità
E' possibile eseguire le operazioni di backup su un nodo passivo del gruppo di disponibilità
Nonostante questa tecnologia si basi sul Failover Cluster non è necessario:
Avere uno storage condiviso fra i nodi del cluster
Fare un installazione in Cluster di SQL Server
Quindi ogni nodo avrà un'installazione autonoma di SQL Server con i dati su uno storage locale del nodo.
Note:
In Windows Server 2012 la funzionalità di Failover Cluster è disponibile anche sulla versione Standard
Non esiste nessun problema nel creare nodi virtualizzati, se non le solite raccomandazioni relative al fare girare SQL Server su una macchina virtuale
Terminologia
AlwaysOn Availability Group: gruppo di server (in cluster) che mette in alta disponibilità uno o più Database
Primary Replica: istanza che ospita la copia in lettura e scrittura del Database
Secondary Replica: host che ospita una copia del database su cui è possibile abilitare accessi in sola lettura
Listener: consiste di un nome DNS, una porta TCP ed uno o più indirizzi IP attraverso cui i client si connettono al gruppo di disponibilità
Availability Modes: modalità di replica dei dati fra il membro primario ed i secondari, può essere:
Commit-Synchronous: la replica primaria attende conferma che le modifiche siano state apportate sul membro secondario prima di chiudere la transazione. Affidabile ma pericoloso per le performances
Commit-Asynchronous: il membro primario invia le modifiche al secondario e chiude la transazione senza aspettare conferma sull'esito.Non affidabile ma performante.
Failover: processo attraverso il quale il ruolo di replica primaria viene passato ad una replica secondaria, chiamata failover target. Sono disponibili 3 tipi di failover:
Failover automatico (senza perdita di dati): disponibile quando sia la replica primaria che la secondaria operano in modalità sincrona (Commit-Synchronous). In questo caso la modalità di failover nel gruppo è impostata su automatica ed il passaggio di ruoli avviene senza alcun intervento amministrativo.
Failover manuale pianificato (senza perdita di dati): come nel caso precedente i due membri operano in modalità sincrona, ma non essendo stato impostato il failover automatico è necessario l'intervento amministrativo per inviare il comando di failover.
Failover manuale forzato (con possibile perdita di dati): i due membri di replica operano in modalità asincrona e quindi l'amministratore può forzare il failover sapendo che eventuali transazioni del membro primario non ancora sincronizzate andranno perse.
Active Secondary Replicas: per migliorare le performance e gestire in maniera più efficiente le risorse del gruppo di disponibilità è possibile indirizzare le richieste di sola lettura e backup verso repliche secondarie
Installazione
L'obiettivo di questo articolo è centrato sugli Availability Group e non sulla configurazione del Cluster di Failover, quindi non entrerò nei dettagli su questa parte.
1) Installare la funzionalità di Failover Cluster sui Server
2) Creare un Cluster di Failover che comprenda tutti i Server
nel nostro esempio abbiamo creato un cluster MIA-CLUSTER a cui partecipano i server:
MIA-CLUST1
MIA-CLUST2
MIA-CLUST3
Notare che nel Cluster non c'è Storage condiviso.
3) Installare un'istanza Standalone di SQL Server 2012 su ogni Server
Note:
Usate un account di dominio per il Servizio SQL
Potete installare solo il Motore di Database, opzionalmente anche gli strumenti di gestione
4) Attraverso il Configuration Manager abilitate AlwaysOn Availability Group su ogni Server
Riavviate i servizi di SQL Server
5) Create una condivisione di rete per i file di Backup utilizzati per sincronizzare le repliche
6) Creiamo i DataBase che vogliamo proteggere sul Server che diventerà la Replica Primaria
Nel nostro caso il Server che svolgerà il ruolo di Replica Primaria è MIA-CLUST1 e mettiamo in alta disponibilità il Database Sales
Controllate che il Recovery Model sia Full
7) Facciamo un Backup Full nello Share di cui al punto 5
8) Creiamo un AlwaysOn Avalaibilty Group
Lanciamo il Wizard dal Server Primario
Specifichiamo il nome del nostro AG
Selezioniamo il database Sales
Aggiungiamo le Repliche Secondarie: Add Replica...
Configuriamo il Listener
Impostiamo il Folder per la sincronizzazione
Controlliamo l'esito
Il warning ricevuto relativo al WSFC è trascurabile
Risultato Finale:
Il Database Sales è replicato su tutti e tre i Server
Nel cluster è stato creato un servizio il cui Owner è il nostro Primary Replica
Configurazione
Adesso facciamo un esempio di configurazione.
Entriamo nelle proprietà del nostro Availability Group
Impostiamo MIA-CLUST2 in modalità sincrona ed abilitiamo il failover automatico
Lasciamo MIA-CLUST3 in modalità asincrona, e quindi il failover può essere solo manuale
Rendiamo ambedue le Repliche Secondarie leggibili ed analizziamo meglio le opzioni disponibili.
Ricordiamo che ogni server può potenzialmente agire in due modalità: Primario e Secondario, qui abbiamo le opzioni disponibili per ogni server in base al ruolo che svolge (la situazione può essere dinamica):
Connections in primary role: quando agisce da primario, può accettare tutte le connessioni o solo quelle in scrittura.
Readable Secondary: quando agisce da secondario può non accettare connessioni, accettarle tutte (ma dare errore se si prova a modificare i dati) o accettare solo le connessioni che abbiano esplicitamente Intent=Readonly
Andiamo poi nella sezione Backup Preferences
Lasciamo il default a Prefer Secondary, in questo modo i backup verrano sempre fatti sui secondari, se disponibili.
Cambiamo la priorità del backup mettendo avanti il Server MIA-CLUST3
I risultati delle nostre impostazioni sono anche visibili dalla Dashboard dell' AG
READ-ONLY ROUTING
Dopo aver reso le nostre repliche secondarie leggibili già possible accedervi puntando direttamente al nome del Server.
Esempio di accesso al MIA-CLUST2
Esempio di accesso a MIA-CLUST3 (impostato read-intent only, notare l'errore nel primo tentativo)
Ma se vogliamo creare un meccanismo che indirizzi automaticamente le richieste di sola lettura verso le Repliche Secondarie dobbiamo implementare in Read-Only Routing.
Per la configurazione potete fare riferimento a questo articolo ma riassumendo:
Dobbiamo avere configurato un Listener e noi lo abbiamo fatto nel wizard:
DNS: MIA-SQL-CLUSTER
IP: 10.10.0.40
TCP Port: 1433
Identifichiamo la URL per connessione ad ogni Server membro del nostro AG
Nel nostro caso: TCP://MIA-CLUST1.AdventureWorks.msft:1433
TCP://MIA-CLUST2.AdventureWorks.msft:1433
TCP://MIA-CLUST3.AdventureWorks.msft:1433
Potete utilizzare questo script realizzato da Matt Neerincx che fornisce un output del tipo
Configuriamo i nostri Read_only_routing dando questi comandi sulla nostra Replica Primaria:
___________________ Start ____________________________
-- Configure Read_Only_Routing
-- This script need to be paramatrized with your deployment data!
-- Ruggiero Lauria
-- Enable Server as Readable when acting as Secondary Replica
-- This command is not strictly necessary because we have already configured it
-- trough AG propriety. But for completeness I preferred to include it in the script
ALTER AVAILABILITY GROUP [MIA-SQL-AG]
MODIFY REPLICA ON
N'MIA-CLUST1' WITH
(SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));
-- Define Server Read_only_routing URL
ALTER AVAILABILITY GROUP [MIA-SQL-AG]
MODIFY REPLICA ON
N'MIA-CLUST1' WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://MIA-CLUST1.AdventureWorks.msft:1433'));
-- Enable Server as Readable when acting as Secondary Replica
-- This command is not strictly necessary because we have already configured it
-- trough AG propriety. But for completeness I preferred to include it in the script
ALTER AVAILABILITY GROUP [MIA-SQL-AG]
MODIFY REPLICA ON
N'MIA-CLUST2' WITH
(SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));
-- Define Server Read_only_routing URL
ALTER AVAILABILITY GROUP [MIA-SQL-AG]
MODIFY REPLICA ON
N'MIA-CLUST2' WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://MIA-CLUST2.AdventureWorks.msft:1433'));
-- Enable Server as Readable when acting as Secondary Replica
-- This command is not strictly necessary because we have already configured it
-- trough AG propriety. But for completeness I preferred to include it in the script
ALTER AVAILABILITY GROUP [MIA-SQL-AG]
MODIFY REPLICA ON
N'MIA-CLUST3' WITH
(SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));
-- Define Server Read_only_routing URL
ALTER AVAILABILITY GROUP [MIA-SQL-AG]
MODIFY REPLICA ON
N'MIA-CLUST3' WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://MIA-CLUST3.AdventureWorks.msft:1433'));
ALTER AVAILABILITY GROUP [MIA-SQL-AG]
MODIFY REPLICA ON
N'MIA-CLUST1' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('MIA-CLUST2','MIA-CLUST3')));
-- Define Read Routing List when Server is acting as Primary Replica
ALTER AVAILABILITY GROUP [MIA-SQL-AG]
MODIFY REPLICA ON
N'MIA-CLUST2' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('MIA-CLUST1','MIA-CLUST3')));
-- Define Read Routing List when Server is acting as Primary Replica
ALTER AVAILABILITY GROUP [MIA-SQL-AG]
MODIFY REPLICA ON
N'MIA-CLUST3' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('MIA-CLUST1','MIA-CLUST2')));
GO
_________________End ________________________
Nota: I Server indicati nella routing list verranno usati in sequenza in base alla disponibilità, non esiste alcuna forma di Load Balancing o round robin.
Test di connettività
Di seguito il processo utilizzato dal Read Only Routing:
-- Define Read Routing List when Server is acting as Primary Replica
Il client si connettono al Listener del nostro Availability Group
Il client viene reindirizzato (sempre!) verso la Primary Replica
Il client ha specificato nella stringa di connessione ApplicationIntent=ReadOnly
Il sever controlla che il database di destinazione faccia parte di un Availability Group
Se è vero il punto 4, il server controlla se è impostata una read_only_routing_list sulla Primary Replica
Se è vero il punto 5 il server controlla in ordine che i server elencati nella Routing_List stiano sincronizzando ed accettino connessioni (allow_connections=read_only or all)
Il server legge la read_only_routing_url della prima replica secondaria pronta ad accettare connessioni e la passa al client
Il client legge la URL e si ridireziona verso l'istanza secondaria leggibile
Per eseguire un test di connettività si possono utilizzare i Reporting Services, quindi nel nostro esempio farò un semplice report (l'esempio è banale!) sulla tabella sales.dbo.orders includendo il nome del server che sta rispondendo con la seguente query:
Select OrderDate, OrderTotal, @@ServerName as Server from Orders
Primo Test: accediamo con ApplicationIntent=ReadWrite
E riceviamo risposta dalla Primary Replica
Adesso cambiamo il tipo di connessione in ApplicationIntent=ReadOnly
E rilanciando il report
Siamo stati reindirizzati verso il primo server della routing list definita per Primary Replica:
ALTER AVAILABILITY GROUP [MIA-SQL-AG]
MODIFY REPLICA ON
N'MIA-CLUST1' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('MIA-CLUST2','MIA-CLUST3')));
Comandi Utili
Esempio di stringa di connessione:
Server=tcp:MIA-SQL-CLUST,1433;Database=Sales;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly;MultiSubnetFailover=True
Restart del listener
ALTER AVAILABILITY GROUP [MIA-SQL-AG] RESTART LISTENER 'MIA-SQL-CLUST';
Related System Views
SELECT * FROM sys.dm_tcp_listener_states
SELECT * from sys.availability_replicas
SELECT * from sys.availability_read_only_routing_lists
Conclusione
Spero che questa guida passo passo possa esservi di aiuto per sfruttare appieno questa opportunità che ci viene offerta da SQL Server 2012.
Tutte le correzioni ed i commenti sono i benvenuti.
Buon divertimento!
lunedì 5 gennaio 2015
Esce la Newsletter TechNet, scoprila subito!
iao a tutti,
É sempre molto difficile per un IT PRO destreggiarsi tra l’abbondante documentazione, i problemi tecnici e la vita lavorativa quotidiana. Da diverso tempo TechNet pubblica una Newsletter che ha lo scopo di tenere sempre aggiornati gli IT PROs e mettere in evidenza le notizie e le novità più importanti del mese. Per riceverla gratuitamente ricordiamo i passaggi:
1. Vai al link http://technet.microsoft.com/it-it/bb291016.aspx e clicca su Iscriviti subito alla newsletter: è semplice e gratuito!
2. Fai click per l’accettazione
3. E poi vai al link “Accedere Ora” come in figura
4. Se si dispone di un account Microsoft, inserire indirizzo mail e la password, altrimenti passare al punto 6.
5. Compilare i campi richiesti e cliccare Continua e l’iscrizione è fatta! È possibile che venga richiesta la verifica dell’indirizzo di posta elettronica: in tal caso riceverete una mail con un link di conferma. Click sul link e quindi seguire le istruzione per la verifica.
6. Se non si dispone di un account Microsoft, registrarsi al link in basso alla pagina
7. Una volta creato l’account riaccedere alla pagina del punto 3.
Buona scoperta a tutti!!
É sempre molto difficile per un IT PRO destreggiarsi tra l’abbondante documentazione, i problemi tecnici e la vita lavorativa quotidiana. Da diverso tempo TechNet pubblica una Newsletter che ha lo scopo di tenere sempre aggiornati gli IT PROs e mettere in evidenza le notizie e le novità più importanti del mese. Per riceverla gratuitamente ricordiamo i passaggi:
1. Vai al link http://technet.microsoft.com/it-it/bb291016.aspx e clicca su Iscriviti subito alla newsletter: è semplice e gratuito!
2. Fai click per l’accettazione
3. E poi vai al link “Accedere Ora” come in figura
4. Se si dispone di un account Microsoft, inserire indirizzo mail e la password, altrimenti passare al punto 6.
5. Compilare i campi richiesti e cliccare Continua e l’iscrizione è fatta! È possibile che venga richiesta la verifica dell’indirizzo di posta elettronica: in tal caso riceverete una mail con un link di conferma. Click sul link e quindi seguire le istruzione per la verifica.
6. Se non si dispone di un account Microsoft, registrarsi al link in basso alla pagina
7. Una volta creato l’account riaccedere alla pagina del punto 3.
Buona scoperta a tutti!!
Iscriviti a:
Post (Atom)