Descrizione di alta disponibilità e di ripristino di emergenza per Secrets Manager
L'alta disponibilitàLa capacità di un servizio o di un carico di lavoro di resistere ai guasti e di continuare a fornire capacità di elaborazione secondo un livello di servizio predefinito. (HA) è la capacità di un servizio di rimanere operativo e accessibile in presenza di guasti imprevisti. Il disaster recoveryLa capacità di un servizio o di un carico di lavoro di riprendersi da incidenti rari e gravi e da guasti su larga scala, come l'interruzione del servizio. Ciò include un disastro fisico che colpisce un'intera regione, il danneggiamento di un database o la perdita di un servizio che contribuisce a un carico di lavoro. L'impatto supera la capacità del progetto di alta disponibilità di gestirlo. è il processo di ripristino dell'istanza di servizio in uno stato funzionante.
Secrets Manager è un servizio regionale che soddisfa gli obiettivi di livello di servizio(SLO) definiti con il piano Standard. Per ulteriori informazioni sulle regioni e sui data center disponibili per IBM Cloud Secrets Manager, vedere Disponibilità di servizi e infrastrutture per località.
Architettura ad alta disponibilità
Un'istanza del servizio Secrets Manager viene fornita in tre zone di una regione multizona senza un singolo punto di guasto. Le richieste API vengono instradate attraverso un bilanciatore di carico globale a tre nodi di istanza HA, ciascuno in una zona di disponibilità diversa.
Se una zona di disponibilità subisce dei guasti, il servizio continuerà a funzionare con le richieste API che vengono instradate attraverso un bilanciatore di carico globale verso i nodi di istanza HA sopravvissuti. Può trascorrere un breve periodo di tempo (secondi) tra l'interruzione e il riconoscimento del guasto da parte del bilanciatore di carico globale, durante il quale le richieste possono essere inviate all'istanza guasta. I carichi di lavoro che accedono programmaticamente all'istanza del servizio devono seguire la logica di riprova della disponibilità del client per mantenere la disponibilità. Non si nota alcun degrado del servizio durante un guasto zonale.
le istanze di IBM Cloud® Secrets Manager sono altamente disponibili e non richiedono alcuna configurazione.
Architettura di disaster recovery
Per recuperare un'istanza di servizio interrotta, è necessario creare un'istanza di servizio di recupero in una regione di recupero. In generale, l'istanza del servizio di recupero dovrebbe essere configurata con gli stessi dati dell'istanza del servizio di origine, ma ci sono delle eccezioni a questa guida.
Alcuni segreti dovranno essere adattati alla regione di recupero, ad esempio le stringhe di connessione o le chiavi API possono fare riferimento a istanze di servizio specifiche per la regione. Questi valori saranno diversi nell'istanza del servizio di recupero.
L'istanza del servizio Secret Manager potrebbe avere dipendenze create dal cliente su questi servizi opzionali; verificare che questi esistano nell'area recuperata.
Tale istanza deve essere creata prima del fatto (prima di qualsiasi potenziale disastro) e mantenuta in sincronia con l'istanza di origine.
Funzionalità di disaster recovery
Secrets Manager supporta le seguenti funzioni di disaster recovery:
Pianificare il recupero in una regione di recupero. L'istanza di recupero deve allinearsi al carico di lavoro " approcci di ripristino in caso di disastro all'interno del " IBM Cloud. L'istanza di recupero deve tracciare le modifiche dei dati all'istanza di servizio primaria per i dati che includono gruppi, segreti, versioni di segreti, certificati, notifiche di eventi.
Se il disastro non ha un impatto sull'istanza del servizio di produzione, ad esempio se i dati sono danneggiati, il cliente può riparare i dati nell'istanza del servizio in uso.
Il servizio supporta le seguenti opzioni di disaster recovery:
| Funzione | Descrizione | Considerazione |
|---|---|---|
| Rotazione | Ripristino della versione segreta precedente | L'istanza del servizio di produzione deve essere disponibile. Nella cronologia delle versioni è presente un numero limitato di versioni. Vedere i problemi e i limiti noti. |
Tutte le altre opzioni di disaster recovery sono create e supportate dal cliente.
| Funzione | Descrizione | Considerazione |
|---|---|---|
| Fonte esterna di verità | Tutti i segreti sono stati creati tramite uno script, descritto di seguito. | Il cliente deve creare lo script e mantenere la configurazione in modo che possa essere utilizzata in caso di disastro |
| Backup e ripristino | Eseguire il backup di un'istanza del servizio utilizzando uno script scritto dal cliente. | Il cliente deve creare lo script e conservare la copia di backup in modo che possa essere utilizzata durante il ripristino |
| Sincronizzazione live | Le modifiche segrete in produzione vengono osservate automaticamente e propagate al recupero dell'istanza del servizio, vedere la descrizione seguente | Il cliente deve creare e mantenere gli strumenti. I dati danneggiati saranno sincronizzati con l'istanza di recupero. |
Funzione di rotazione
I segreti del Secret Manager vengono generalmente aggiornati tramite "rotazione", dove la scrittura di un valore determina la creazione di una nuova versione del segreto. Potrebbe essere possibile ripristinare i dati danneggiati ripristinando i segreti da versioni precedenti nell'istanza di produzione. Viene mantenuto solo un numero fisso di versioni. Vedere Gestione delle versioni segrete.
Fonte di verità esterna fornita dal cliente
Il cliente deve creare e utilizzare una combinazione di terraform, script o programma come fonte di verità. Aggiornare prima l'origine della verità e poi utilizzare l'origine della verità per creare/aggiornare l'istanza del servizio primario e l'istanza del servizio di ripristino. L'origine deve essere disponibile per la versione di ripristino e rappresenta un singolo punto di errore.
Se un cliente dichiara un disastro nell'istanza primaria, verrà utilizzato il servizio nella regione di recupero (Minimal Operation) o creato (Zero Footprint). Reindirizzare i componenti del carico di lavoro all'istanza recuperata o, facoltativamente, inserire nel codice di retry all'interno dell'applicazione per reindirizzare le richieste alla seconda istanza (operazione minima).
Il repository che contiene la fonte della verità dovrebbe avere un recupero point-in-time, come i bucket Object Storage con versioning o i repository Github.
Backup e ripristino della funzione fornita dal cliente
Per eseguire manualmente il backup dei segreti da una regione all'altra, è necessario disporre di un'istanza di Secrets Manager in un'altra regione. Utilizza quindi la seguente procedura per garantire la disponibilità inter-regionale.
Elencare e scaricare i segreti dalla tua istanza utilizzando la Secrets Manager API o CLI.
Se si dispone di configurazioni esistenti sui motori segreti nell'istanza, è anche possibile richiamare le informazioni programmaticamente in modo che possa essere ricreata in una nuova istanza. Per ulteriori informazioni, vedere la sezione Ottenere la configurazione di un tipo di segreto API.
Aggiungere i segreti scaricati alla nuova istanza creata.
La creazione di un backup automatico dei vostri segreti è possibile automatizzando il flusso manuale, che può essere realizzato in vari modi. Esaminate i seguenti esempi per verificare se uno di essi può fare al caso vostro.
Funzione di sincronizzazione live fornita dal cliente
Il cliente può creare uno script o un programma per scaricare i segreti dalla tua istanza di servizio primaria utilizzando l'API Secrets Manager o e popolare l'istanza di servizio di ripristino con i dati. Lo script può sfruttare un IBM Cloud Logs audit events of the primary instance to keep the recovery instance in sync along with Code Engine. I backup gestiti dal cliente devono essere conservati per il ripristino dal disastro.
Creare uno script che scarichi periodicamente i segreti e li importi nell'istanza di backup.
Creare una destinazione e una sottoscrizione in Event Notifications che punti a un'azione di IBM Cloud Code Engine. Configurare l'azione per ascoltare gli eventi del ciclo di vita, come secret_created e secret_rotated.
Poi, quando l'azione riceve l'evento, l'azione scarica il segreto da un'istanza e lo aggiunge all'istanza di backup.
Secrets Manager supporta le notifiche per i diversi tipi di segreto che fornisce. Per conoscere i vari tipi di evento del ciclo di vita disponibili, consultare Abilitazione notifiche eventi.
Pianificazione del ripristino in caso di disastro
Le fasi di disaster recovery devono essere praticate regolarmente. Nel costruire il vostro piano, considerate i seguenti scenari di fallimento e le relative soluzioni.
| Operazione non riuscita | Risoluzione |
|---|---|
| Guasto hardware (punto singolo) | IBM fornisce un'istanza resiliente da un singolo punto di guasto hardware all'interno di una zona, senza necessità di configurazione. |
| malfunzionamento zona | IBM fornisce un'istanza resiliente a un guasto della zona, senza necessità di configurazione. |
| Dati danneggiati | Utilizzare la rotazione per ripristinare la versione segreta precedente in un'istanza di servizio disponibile. |
| Dati danneggiati | Ripristinare una versione non corrotta in un determinato momento dalla fonte esterna di verità o dal backup e ripristino. |
| Fallimento regionale | Passare i carichi di lavoro critici all'uso della versione ripristinata in una regione di ripristino. Ripristinare l'istanza utilizzando una fonte di verità esterna, il backup e il ripristino o la sincronizzazione live. |
Le vostre responsabilità per HA e DR
La seguente lista di controllo associata a ciascuna caratteristica può aiutarvi a creare e mettere in pratica il vostro piano.
- Rotazione
- Creare un'istanza di risorsa di prova ed esercitarsi a ruotare le versioni dei segreti e a ripristinare una versione segreta.
- Fonte esterna di verità
- Verificare che l'origine della verità si trovi in un repository disponibile nella posizione di ripristino.
- Verificare che l'origine della verità non dipenda dalla regione disastrata per evitare la dipendenza da una regione guasta.
- Backup e ripristino
- Verificare che il backup sia in un repository disponibile nella posizione di ripristino.
- Verificare che lo script scritto dal cliente per il ripristino dei dati sia disponibile nell'area di ripristino.
- Verificare che lo script e il backup non dipendano dalla regione di emergenza per evitare la dipendenza da una regione in fallimento. Si consideri un Object Storage cross bucket regionale.
- Sincronizzazione dal vivo
- Verificare che l'istanza del servizio di recupero sia attualmente disponibile nell'area di ripristino
- Sia per la fonte esterna di verità che per la sincronizzazione dal vivo:
- Verificare che i carichi di lavoro di recupero nell'area di recupero siano integrati con l'istanza del servizio di recupero
- Verificare che i segreti specifici della regione siano disponibili nell'istanza del servizio di recupero.
Per saperne di più sulla responsabilità tra il cliente e IBM Cloud per l'utilizzo di Secrets Manager, vedere Comprendere le proprie responsabilità nell'utilizzo di Secrets Manager.
Le fasi di disaster recovery devono essere praticate regolarmente. Quando costruite il vostro piano, prendete in considerazione i seguenti scenari di fallimento e le relative soluzioni.
Recupero del cliente dalla perdita di BYOK
Se l'istanza del servizio è stata fornita utilizzando la chiave principale da IBM® Key Protect for IBM Cloud® o Hyper Protect Crypto Services e la chiave principale è stata accidentalmente eliminata, aprire un caso di assistenza per il servizio e includere le seguenti informazioni:
- Il CRN dell'istanza di servizio
- Il CRN della vostra istanza di backup di Key Protect o HPCS
- Il nuovo ID della Key Protect o della chiave root HPCS
- Il CRN e l'ID chiave dell'istanza Key Protect o HPCS originale, se disponibili
Vedere Recupero da una perdita accidentale di chiavi per l'autorizzazione nei documenti Key Protect e HPCS.
Obiettivo di tempo di recupero (RTO) e obiettivo di punto di recupero (RPO)
| Funzione | RTO e RPO |
|---|---|
| Ripristino della versione segreta precedente | RTO = minuti, la pratica e potenzialmente lo scripting miglioreranno i tempi di RTO, RPO = 0. |
| Fonte esterna di verità - impronta zero | RTO = pochi minuti. Tempo necessario per il provisioning e il popolamento dei dati. Considerate anche il tempo necessario per adattare i carichi di lavoro recuperati al nuovo endpoint dell'istanza di servizio. RPO = 0, la fonte di verità viene modificata prima di apportare modifiche alla produzione. |
| Fonte di verità esterna - backup pienamente operativo | RTO = pochi secondi, RPO = 0. Migliorare la descrizione dell'impronta zero per mantenere un'istanza di servizio attiva nell'area di ripristino. |
| Backup e ripristino | RTO = pochi minuti. Tempo necessario per il provisioning e il popolamento dei dati. Considerate anche il tempo necessario per adattare i carichi di lavoro recuperati al nuovo endpoint dell'istanza di servizio. RPO = ora dell'ultimo backup. |
| Sincronizzazione live | RTO = minuti, RPO = minuti se si tratta di eventi o del periodo, ad esempio giornaliero, se si utilizzano backup periodici. |
Quando si crea una nuova istanza di servizio, l'RTO del carico di lavoro utilizzando Secrets Manager includerà il tempo necessario per adattare i carichi di lavoro recuperati all'endpoint della nuova istanza di servizio.
Gestione delle modifiche
La gestione delle modifiche comprende attività quali aggiornamenti, modifiche alla configurazione e cancellazioni.
Si consiglia di assegnare agli utenti e ai processi i ruoli e le azioni IAM con i privilegi minimi richiesti per il loro lavoro.
Ad esempio, limitare la possibilità di eliminare le risorse di produzione.
Come IBM® aiuta a garantire il disaster recovery
IBM® intraprende azioni specifiche di ripristino in caso di disastro.
Come IBM® recupera i guasti di zona
In caso di guasto di una zona, IBM Cloud risolverà l'interruzione della zona e quando questa tornerà online, il bilanciatore di carico globale riprenderà a inviare le richieste API al nodo di istanza ripristinato, senza bisogno di interventi da parte del cliente.
Come IBM® si riprende dai fallimenti regionali
Quando una regione viene ripristinata dopo un guasto, IBM tenterà di ripristinare l'istanza di servizio dallo stato regionale, senza perdita di dati e ripristinando l'istanza di servizio con le stesse stringhe di connessione.
- RTO = pochi minuti
- RPO = 0 minuti
Se lo stato regionale è danneggiato, il servizio verrà ripristinato allo stato dell'ultimo backup interno. Tutti i dati associati al servizio vengono sottoposti a backup una volta al giorno dal servizio in un bucket Cloud Object Storage interregionale gestito dal servizio. È possibile che si verifichi una perdita di dati di 24 ore. Questi backup non sono disponibili per il disaster recovery gestito dal cliente. Quando un servizio viene ripristinato dai backup, viene ripristinato anche l'ID dell'istanza, in modo che i client che utilizzano l'endpoint non debbano essere aggiornati con nuove stringhe di connessione.
- RTO = 2 ore
- RPO = 24 ore al massimo
Nel caso in cui IBM non sia in grado di ripristinare l'istanza del servizio, il cliente deve eseguire il ripristino come descritto nella sezione Ripristino d'emergenza.
Come IBM® mantiene i servizi
Tutti gli aggiornamenti seguono le best practice del servizio IBM® e prevedono un piano di ripristino e un processo di rollback. Gli aggiornamenti regolari per le nuove funzionalità e la manutenzione fanno parte delle normali operazioni. Tale manutenzione può occasionalmente causare brevi intervalli di interruzione che vengono gestiti dalla logica di riprova della disponibilità del client. Le modifiche vengono introdotte in modo sequenziale, regione per regione e zona per zona all'interno di una stessa regione. Gli aggiornamenti vengono annullati al primo segno di difetto.
Le modifiche complesse vengono attivate e disattivate con flag di funzione per controllare l'esposizione.
Le modifiche che hanno un impatto sui carichi di lavoro dei clienti sono dettagliate nelle notifiche. Per ulteriori informazioni, consultare le notifiche e lo stato di monitoraggio della manutenzione programmata, gli annunci e le note di rilascio che hanno un impatto su questo servizio.