Concetti relativi a ripristino di emergenza e disponibilità elevata in SharePoint Server

**Si applica a:**SharePoint Foundation 2013, SharePoint Server 2013, SharePoint Server 2016

**Ultima modifica dell'argomento:**2017-08-01

**Riepilogo:**informazioni sui concetti di disponibilità elevata e ripristino di emergenza in SharePoint Server 2016 e SharePoint 2013 per scegliere la migliore strategia per la farm.

Disponibilità elevata e ripristino di emergenza sono la massima priorità quando si crea un piano e si definiscono le specifiche di sistema per una farm di SharePoint Server. Altri aspetti del piano, come prestazioni e capacità elevate, sono negati se i server della farm non offrono disponibilità elevata o una farm non può essere ripristinata.

Per progettare e implementare una strategia efficace che assicuri un'operatività ininterrotta ed efficiente, è necessario comprendere i concetti base della disponibilità elevata e del ripristino di emergenza. Tali concetti sono importanti anche per valutare e selezionare le migliori soluzioni tecniche per il proprio ambiente SharePoint.

Contenuto dell'articolo:

• Introduzione alla gestione della continuità aziendale

• Descrizione della disponibilità elevata

• Quantificazione del tempo di inattività

Introduzione alla gestione della continuità aziendale

La gestione della continuità aziendale è un processo o programma di gestione che definisce, stima e contribuisce a gestire i rischi connessi all'operatività ininterrotta di un'organizzazione. La gestione della continuità aziendale si concentra sulla creazione e la manutenzione di un piano di continuità aziendale, che definisce i passi da compiere per assicurare la continuità dell'operatività quando le operazioni aziendali normali vengono interrotte da condizioni avverse. Tali condizioni possono essere naturali, provocate o di entrambi i tipi. Un piano di continuità deriva dalle analisi e dagli input seguenti:

• Un'analisi di impatto aziendale

• Un'analisi di rischi e minacce

• Una definizione degli scenari di impatto

• Un set di requisiti di ripristino documentati

Il risultato è una progettazione di una soluzione o opzioni identificate, un piano di implementazione, un piano di testing e accettazione organizzazioni e un programma o una pianificazione di manutenzione.

Un esempio di gestione della continuità aziendale è Disaster recovery and protection for data and applications, che fornisce uno snapshot del programma di continuità aziendale Microsoft.

Naturalmente per molte organizzazioni l'aspetto IT (Information Technology) è determinante nella pianificazione della continuità aziendale. Il concetto di continuità aziendale è tuttavia più ampio e comprende tutte le operazioni necessarie per garantire la continuità di un'organizzazione durante e subito dopo un evento che ne compromette l'attività. Un piano di continuità aziendale prevede, tra l'altro, gli elementi seguenti:

• criteri, processi e procedure

• possibili scelte e responsabilità decisionali

• risorse umane e strutture

• IT

Benché disponibilità elevata e ripristino di emergenza vengano spesso identificati con la gestione della continuità aziendale, in realtà essi ne rappresentano solo dei sottoinsiemi.

Descrizione della disponibilità elevata

Per una data applicazione o servizio software, la disponibilità elevata viene in definitiva misurata in termini di esperienza e aspettative dell'utente finale. L'impatto aziendale tangibile e percepito del tempo di inattività può essere espresso in termini di perdita di informazioni, danno patrimoniale, riduzione della produttività, costi potenziali, danni contrattuali o disaffezionamento.

L'obiettivo principale di una soluzione a disponibilità elevata è minimizzare o ridurre l'impatto del tempo di inattività. La strategia ideale per raggiungere questo obiettivo bilancia in modo ottimale i processi aziendali e i contratti di servizio da un lato e i costi delle infrastrutture e le competenze tecniche dall'altro.

Una piattaforma viene considerata a disponibilità elevata in base al contratto e alle aspettative di clienti e altre parti interessate. La disponibilità di un sistema può essere espressa con il calcolo seguente:

Tempo di attività effettivo/Tempo di attività previsto X 100%

Il valore risultante è spesso indicato nel settore come il numero di 9 offerto dalla soluzione, a indicare il numero di minuti annui di potenziale attività o, di contro, di inattività.

Tempo di inattività pianificata rispetto a tempo di inattività non pianificata

Le interruzioni dei sistemi sono previste (o pianificate) oppure sono il risultato di un errore imprevisto. Il tempo di inattività non deve essere considerato negativamente, se viene gestito in modo appropriato. I tempi di inattività prevedibili rientrano in due categorie principali:

• Manutenzione pianificata Prevede un periodo di tempo prestabilito e coordinato in cui vengono svolte le attività di manutenzione pianificata quali l'installazione di patch software, gli aggiornamenti hardware, gli aggiornamenti delle password, la reindicizzazione offline, il caricamento dati e la prova delle procedure di ripristino di emergenza. Le procedure operative preventivate e ben gestite possono ridurre il tempo di inattività ed evitare la perdita di dati. Le attività di manutenzione pianificata possono essere viste come investimenti necessari per evitare o contenere altri scenari di interruzioni non pianificate di maggiore gravità.

• Interruzione non pianificata. Gli errori a livello di sistema, di infrastruttura o di processo possono essere del tutto imprevisti e incontrollabili o magari prevedibili, ma considerati troppo improbabili oppure sostenibili. Un'efficace soluzione a disponibilità elevata individua questi tipi di errori, supera l'interruzione automaticamente e quindi ristabilisce la tolleranza di errore.

Quando si stabiliscono contratti di servizio che prevedono la disponibilità elevata, è necessario calcolare indicatori di prestazione chiave (KPI) distinti per le attività di manutenzione pianificata e il tempo di inattività non pianificata. Questo consente di compensare l'investimento in attività di manutenzione pianificata con i vantaggi derivanti dall'assenza di tempo di inattività non pianificata.

Disponibilità ridotta

La disponibilità elevata non deve essere intesa come una condizione esclusiva. Come alternativa a un'interruzione completa, per l'utente finale è spesso accettabile che un sistema sia parzialmente disponibile, che abbia funzionalità limitate o prestazioni ridotte. I diversi gradi di disponibilità sono:

• Operazioni in sola lettura e rinviate. All'interno di una finestra di manutenzione o durante un ripristino di emergenza distribuito in fasi, il recupero dei dati resta possibile, ma i nuovi flussi di lavoro e l'elaborazione in background possono essere temporaneamente interrotti o messi in coda.

• Latenza dei dati e tempi di risposta delle applicazioni. In presenza di un considerevole carico di lavoro, un backlog di elaborazione o un errore parziale della piattaforma, alcune risorse hardware possono risultare sovraccariche o sottodimensionate. L'esperienza utente può risentirne, ma il sistema resterà funzionante, benché meno produttivo.

• Errori parziali, temporanei o incombenti. Affidabilità della logica delle applicazioni o dello stack hardware che riprova o esegue una correzione automatica in caso di errore. Questi tipi di problemi possono apparire all'utente finale sotto forma di latenza dei dati o tempi di risposta delle applicazioni eccessivi.

• Errore end-to-end parziale. Interruzioni pianificate o non pianificate possono verificarsi normalmente nei livelli verticali dello stack della soluzione (infrastruttura, piattaforma e applicazione) oppure orizzontalmente, tra vari componenti funzionali. Può conseguirne la riduzione o il successo parziale delle operazioni, a seconda delle funzionalità o dei componenti interessati.

L'accettabilità di questi scenari non ottimali deve essere considerata nel quadro di uno spettro di disponibilità ridotte che preludono a un'interruzione completa e come fasi intermedie di un ripristino di emergenza distribuito in fasi.

Quantificazione del tempo di inattività

In caso di tempo di inattività, sia essa pianificata o meno, l'obiettivo aziendale principale è ripristinare l'attività del sistema e ridurre al minimo la perdita di dati. Ogni minuto di inattività produce costi diretti e indiretti. Di fronte a un tempo di inattività non pianificato occorre bilanciare il tempo e le risorse necessari per determinare le cause dell'interruzione, lo stato corrente del sistema e i passaggi da eseguire per superare l'interruzione.

A un punto prestabilito di un'interruzione, è necessario prendere o sollecitare la decisione aziendale di interrompere l'analisi del problema o l'esecuzione delle attività di manutenzione e superare l'interruzione ripristinando l'attività del sistema e, se necessario, ristabilendo la tolleranza di errore.

Obiettivi del recupero

La ridondanza dei dati è un componente chiave di una soluzione di database a disponibilità elevata. L'attività transazionale sull'istanza principale di SQL Server viene applicata in modo sincrono o asincrono a una o più istanze secondarie. In caso di interruzione, le transazioni in corso possono essere oggetto di rollback o possono andare perdute nelle istanze secondarie per ritardi nella propagazione dei dati.

È possibile sia misurare l'impatto che impostare obiettivi per il ripristino in termini di tempo necessario per ripristinare l'efficienza del sistema e di tempo di latenza dell'ultima transazione recuperata:

• Obiettivo in termini di tempo di ripristino (RTO, Recovery Time Objective). È la durata dell'interruzione. Il primo obiettivo consiste nel riportare il sistema in funzione almeno in modalità di sola lettura per facilitare l'analisi dell'errore. L'obiettivo principale è comunque ripristinare appieno le funzionalità affinché sia possibile eseguire nuove transazioni.

• Obiettivo in termini di punto di ripristino (RPO, Recovery Point Objective). Vi si fa spesso riferimento come una misura accettabile in termini di perdita di dati. Rappresenta l'intervallo di tempo o latenza tra l'ultima transazione dati avviata prima dell'errore e i dati più recenti recuperati dopo l'errore. La perdita di dati effettiva può variare a seconda del carico di lavoro a cui era sottoposto il sistema al momento dell'errore, del tipo di errore e del tipo di soluzione a disponibilità elevata utilizzata.

  Nota

  Un obiettivo di questo genere è l'obiettivo relativo al livello di ripristino (RLO, Recovery Level Objective). Tale obiettivo definisce il livello di dettaglio con cui deve essere possibile ripristinare i dati, ad esempio l'intera farm, l'applicazione Web, la raccolta siti, il sito, l'elenco o la raccolta oppure l'elemento. Per ulteriori informazioni, vedere Pianificazione del backup e del ripristino in SharePoint Server.

I valori di RTO e RPO sono obiettivi che indicano la tolleranza aziendale per il tempo di inattività e la perdita di dati accettabile e fungono da metriche per il monitoraggio dello stato di disponibilità.

Giustificazione del rendimento dell'investimento (ROI) o del costo di opportunità

I costi aziendali del tempo di inattività possono esprimersi in termini finanziari o di disaffezione dei clienti. Tali costi possono accumularsi nel tempo o presentarsi in un determinato momento del periodo di interruzione. Oltre a prevedere il costo di un'interruzione con un dato tempo di ripristino e un dato punto di ripristino dei dati, è anche possibile calcolare il processo aziendale e gli investimenti infrastrutturali necessari per conseguire gli obiettivi RTO e RPO o perché l'interruzione non si verifichi affatto. Tali temi di investimento sono:

• Prevenzione dei tempi di inattività. I costi di recupero dalle interruzioni vengono evitati del tutto se l'interruzione non si verifica affatto. Gli investimenti includono il costo dell'hardware o dell'infrastruttura ridondante a tolleranza di errore, la distribuzione dei carichi di lavoro su punti di errore isolati e i tempi di inattività pianificati per la manutenzione preventiva.

• Recupero automatico. Se si verifica un errore del sistema, è possibile contenere fortemente l'impatto del tempo di inattività sull'esperienza dei clienti tramite il recupero automatico e trasparente.

• Utilizzo delle risorse. L'infrastruttura secondaria o di standby può restare inattiva in attesa di un'interruzione. Può anche essere utilizzata esclusivamente per carichi di lavoro di sola lettura o per migliorare le prestazioni generali del sistema distribuendo i carichi di lavoro su tutto l'hardware disponibile.

Per determinati obiettivi RTO e RPO, gli investimenti necessari per la disponibilità e il recupero, insieme ai costi previsti per il tempo di inattività, possono essere espressi e giustificati in funzione del tempo. Durante un'interruzione reale, questo consente di prendere decisioni basate sui costi in base al tempo di inattività trascorso.

Monitoraggio dello stato di disponibilità

Da un punto di vista operativo, durante un'interruzione reale è sconsigliabile cercare di considerare tutte le variabili in gioco per calcolare il ROI o i costi di opportunità in tempo reale. È invece necessario monitorare la latenza dei dati sulle istanze in standby come un indicatore dell'RPO previsto.

In caso di interruzione è inoltre opportuno limitare il tempo iniziale impiegato per l'analisi della causa di origine e concentrarsi invece sulla verifica dello stato dell'ambiente di ripristino affidandosi a log di sistema dettagliati e copie secondarie dei dati per la successiva analisi forense.

Pianificazione del ripristino di emergenza

Mentre la disponibilità elevata implica la prevenzione dell'interruzione, il ripristino di emergenza implica una serie di operazioni per il recupero della disponibilità elevata dopo l'interruzione.

Per quanto possibile, le procedure e le responsabilità relative al ripristino di emergenza vanno definite prima che si verifichi un'interruzione reale. In base agli avvisi e al monitoraggio attivo, la decisione di iniziare un piano di failover e ripristino automatico o manuale deve essere associata a soglie di RTO e RPO prestabilite. L'ambito di un piano di ripristino di emergenza valido deve includere:

• Granularità di errore e ripristino. A seconda del luogo e del tipo di errore, è possibile intraprendere un'azione correttiva a diversi livelli (data center, infrastruttura, piattaforma, applicazione o carico di lavoro).

• Materiale di analisi di riferimento. Cronologia di monitoraggio di base e recente, avvisi di sistema, registri eventi e query di diagnostica devono essere tutti prontamente accessibili dagli operatori appropriati.

• Coordinamento delle dipendenze. All'interno dello stack delle applicazioni e tra le parti interessate, quali sono le dipendenze aziendali e di sistema?

• Albero decisionale. Una struttura decisionale predeterminata, ripetibile e convalidata che include responsabilità dei ruoli, valutazione degli errori, criteri di failover in termini di obiettivi RPO e RTO e procedure di recupero predefinite.

• Convalida. Dopo aver eseguito le procedure per la risoluzione dell'interruzione, in che modo è possibile verificare che il sistema sia di nuovo funzionante?

• Documentazione. Riunire tutti gli elementi illustrati sopra in una raccolta di documentazione sufficientemente chiara e dettagliata da consentire a un team esterno di eseguire il piano di ripristino con un'assistenza minima. Questo tipo di documentazione è solitamente denominata "vademecum" o "prontuario".

• Prove di ripristino. Eseguire con regolarità il piano di ripristino di emergenza per definire le aspettative di base per gli obiettivi RTO e considerare l'opportunità di ospitare il sito di produzione principale sul sito principale e su ogni sito di ripristino di emergenza in base a una rotazione regolare.

See also

Scegliere una strategia di ripristino di emergenza per SharePoint Server