Utilizzo del mirroring in uno scenario di esempio di ripristino di emergenza
Questo scenario di ripristino di emergenza end-to-end dimostra come utilizzare il mirroring per fornire una maggiore disponibilità e mantenere in funzione le applicazioni nel caso in cui un grave incidente influisca su una regione completa di IBM Cloud.
Due cluster sono stati forniti in regioni differenti e configurati per il mirroring (seguendo le informazioni in Abilitazione del mirroring) utilizzando A e B come alias del cluster. Un
produttore pubblica i record su un argomento denominato accounting.invoices e un consumatore legge i messaggi da tale argomento nel cluster A.
Il cluster di origine diventa non disponibile
Consideriamo cosa succede se si verifica un disastro nella regione del cluster di origine.
È responsabilità del proprietario dell'istanza Event Streams determinare se l'impatto dell'evento è tale da dichiarare un disastro. Il proprietario dell'istanza del servizio deve coordinare il failover delle applicazioni, inclusa la loro riconfigurazione, ridistribuzione e riavvio, se necessario.
Failover dei produttori
Per eseguire il failover, effettuare le seguenti operazioni:
- Arrestare i produttori che puntavano al cluster A.
- Se il cluster A e il link da A al cluster B sono ancora operativi, assicurarsi che venga eseguito il mirroring del maggior numero possibile di dati controllando che il ritardo su tali argomenti nel cluster B sia zero.
- Riavviare i produttori per puntare agli endpoint del cluster B.
- Disabilitare qualsiasi mirroring ancora abilitato sugli argomenti dal cluster A al cluster B. Questa operazione può essere eseguita utilizzando i Controlli utente.
Il producer è ora passato al cluster B e invia messaggi a un nuovo argomento locale con lo stesso nome dell'originale.
Failover dei consumatori
Per eseguire il failover, effettuare le seguenti operazioni:
- Se il cluster A e il link da A al cluster B sono ancora operativi, consentire ai consumer di leggere tutti i dati del messaggio negli argomenti sul cluster A e di eseguire il commit dei relativi offset alla fine dell'argomento.
- Arrestare i consumer che puntavano al cluster A.
- Riavviare i consumer per puntare agli endpoint del cluster B.
Il consumer può ora continuare a utilizzare i messaggi esistenti dall'argomento accounting.invoices.A dal cluster B mentre i nuovi messaggi provengono da accounting.invoices.
Se l'applicazione richiede un ordine rigoroso, gli argomenti remoti devono essere utilizzati completamente prima di iniziare a utilizzare gli argomenti locali. In questo modo, i messaggi vengono elaborati nell'ordine in cui sono stati prodotti.
Reimpostazione di un ambiente di mirroring
Il proprietario dell'istanza del servizio Event Streams è responsabile di decidere cosa accade quando il cluster A viene ripristinato.
Nel caso in cui il cluster A non è recuperabile, il proprietario dell'istanza del servizio Event Streams è responsabile dell'abilitazione del mirroring tra il cluster B e un'istanza di cui è stato appena eseguito il provisioning. Per abilitare il mirroring su una nuova istanza, completare la seguente procedura:
- Failover dei produttori e dei consumatori da A a B come descritto in precedenza.
- Disabilitare il mirroring corrente dal cluster A al cluster B. Per ulteriori informazioni, consultare Disabilitazione del mirroring.
- Dopo che il mirroring è stato disabilitato, abilitare il mirroring tra il cluster B (ora l'origine) nel cluster di cui è stato appena eseguito il provisioning (la destinazione). Per ulteriori informazioni, consultare Abilitazione del mirroring.
In alternativa, se il cluster A è stato ripristinato, di solito un utente restituisce le operazioni al cluster A. Completare la seguente procedura per restituire le operazioni primarie al cluster A.
Prima di eseguire il fallback, il mirroring deve essere abilitato nella direzione opposta:
- Assicurarsi che il cluster A sia completamente operativo.
- Disabilitare il mirroring corrente dal cluster A al cluster B. Per ulteriori informazioni, consultare Disabilitazione del mirroring.
- Una volta disabilitato il mirroring, abilitare il mirroring tra il cluster B (ora l'origine) e il cluster A (ora la destinazione). Per ulteriori informazioni, consultare Abilitazione del mirroring.
- Il cluster di origine A diventa ora il cluster di destinazione.
- Il cluster di destinazione B diventa il nuovo cluster di origine.
- Abilitare tutti gli argomenti da sottoporre a mirroring dal cluster B al cluster A. È possibile farlo utilizzando i Controlli utente.
Successivamente, assicurarsi che i dati vengano replicati nel cluster A esaminando gli argomenti del cluster B che appaiono sul cluster A. Questi argomenti hanno il suffisso del nuovo cluster di origine, B.
Non eseguire il mirroring dell'argomento di destinazione originale sul cluster B poiché ciò causerebbe un effetto ciclico indesiderato. Come mostrato nel diagramma, eseguiamo il mirroring di accounting.invoices dal cluster B al cluster A, non di accounting.invoices.A.
Failback
La decisione di eseguire di nuovo il failback è di proprietà del proprietario dell'istanza Event Streams. Il proprietario dell'istanza del servizio deve coordinare il failback delle applicazioni, inclusa la loro riconfigurazione, ridistribuzione e riavvio, se necessario.
A differenza del caso di failover, in questo caso non si è verificata alcuna emergenza sul cluster B. Pertanto, il failback è un'operazione controllata e può essere ottenuto con la minima perdita di dati o la rielaborazione dei dati.
Infine, riportare il mirroring alla configurazione originale, il che significa che il cluster A è di nuovo l'origine e il cluster B riprende come destinazione.
- Verificare che il cluster A e il cluster B siano completamente operativi.
- Disabilitare il mirroring corrente dal cluster B al cluster A. Per ulteriori informazioni, consultare Disabilitazione del mirroring.
- Dopo aver disabilitato il mirroring, abilitare il mirroring tra il cluster A (ora l'origine) e il cluster B (ora la destinazione). Per ulteriori informazioni, consultare Abilitazione del mirroring.