Failover replica

Il failover comporta il cambio dei ruoli di replica. La replica diventa la fonte in lettura/scrittura, mentre la fonte originale diventa di sola lettura, garantendo così la disponibilità dei dati durante le interruzioni di servizio.

Concetti di failover della replica

Quando si crea una condivisione file di replica, la replica estrae i dati dalla condivisione file di origine in base a una pianificazione di replica. I dati sulla condivisione file di replica sono impostati su sola lettura. Il failover commuta la relazione di replica. La condivisione file di replica di sola lettura diventa la condivisione file di origine di lettura/scrittura e la condivisione originale diventa di sola lettura. Ora è possibile montare la condivisione file attiva e gestirla come una normale condivisione file.

Quando si avvia un failover, è possibile scegliere cosa accade se l'operazione di failover non riesce o va in timeout. Il timeout predefinito è di 5 minuti.

  • Se si decide di mantenere la relazione di duplicazione, il sistema "ritorna" alla condivisione di origine. Anche se l'operazione non è andata a buon fine, il sistema tenta di replicare nuovamente i dati all'ora successiva prevista. Questa opzione può essere utilizzata quando il sito principale viene pianificato per la manutenzione di routine. È possibile tornare alla condivisione originale quando la manutenzione è completa e il sito è di nuovo stabile. La replica può riprendere.

  • Se si decide di rimuovere la relazione di replica, il sistema suddivide le due condivisioni file e queste diventano condivisioni file di lettura/scrittura indipendenti. Questa opzione può essere utilizzata per il failover in una situazione di ripristino di emergenza quando è più importante avviare l'applicazione il più rapidamente possibile. Quindi, è possibile continuare le normali operazioni sul sito di replica, mentre il futuro del sito originale è incerto.

Un'operazione di failover o una suddivisione di replica non può verificarsi quando un'altra operazione viene eseguita sulla condivisione file di origine o replica (ad esempio, la dimensione della condivisione file viene espansa). L'operazione di split o failover rimane in sospeso fino al completamento dell'altra operazione.

Lo stato di failover mostra failover_pending mentre l'operazione è in corso o mentre il servizio è in attesa del completamento di un'altra operazione.

Failover per manutenzione di routine

Utilizzare un failover per la manutenzione di routine sul sito primario o quando il sito ha problemi. Il processo funziona come segue.

  • La condivisione file di origine nella zona A rifiuta tutte le operazioni di lettura e scrittura. Quindi, il sistema tenta di estrarre una copia finale dei dati della condivisione nella condivisione di replica nella zona B.
  • I dati vengono copiati nella condivisione del file di replica, che diventa lettura / scrittura ed è considerato il nuovo sito di origine. (La relazione di replica è invertita.)
  • Il servizio tenta di replicare i dati dall'origine attiva nella zona B alla condivisione originale nella zona A come pianificato. Se il trasferimento dei dati ha esito negativo, il sistema tenta di nuovo alla successiva ora di replica pianificata.
  • È possibile tornare alla condivisione originale quando la manutenzione è effettuata e il sito è di nuovo stabile. In alternativa, è possibile mantenere la condivisione della replica come condivisione di origine.

Failover in una situazione di ripristino di emergenza

Failover è anche un'opzione per il ripristino di emergenza. Se viene confermata l'indisponibilità del sito originale e si desidera che l'applicazione venga avviata il prima possibile nella posizione di replica, si può scegliere di rimuovere la relazione di replica. L'eliminazione della relazione di replica è un'opzione per il criterio di fallback quando si avvia il failover. Il failover per il ripristino di emergenza funziona nel modo seguente:

  • La condivisione file sul sito di origine rifiuta tutte le operazioni di lettura e scrittura e il sistema tenta di estrarre una copia finale dei dati della condivisione nella condivisione file di replica.
  • Quando il data - pull va in timeout e non riesce, il servizio file interrompe la relazione di replica. La condivisione file di replica diventa di lettura/scrittura e opera come condivisione file indipendente. Può essere montato e gestito come una normale condivisione di file.
  • Impossibile ristabilire la relazione di replica. Tuttavia, è possibile impostare una nuova replica sul sito originale se e quando il sito diventa nuovamente operativo.

A causa della natura del failover di ripristino di emergenza, è possibile che il set di dati più recente non sia stato copiato. In tal caso, è necessario riconciliare lo stato dell'applicazione manualmente quando la condivisione file di origine è nuovamente disponibile. Se la zona di condivisione file di origine diventa di nuovo disponibile, i dati sono disponibili dalla condivisione di replica da riconciliare dal momento dell'incidente al punto di ripristino.

Limitazioni

Queste limitazioni si applicano quando si esegue un failover.

  • Il timeout predefinito per un failover riuscito è 5 minuti. È possibile modificare questo valore quando si avviano le opzioni di failover.

  • Un failover rimane in sospeso quando vengono eseguite altre operazioni sulla condivisione file di origine, come l'espansione della dimensione della condivisione. Una volta completata l'operazione, il failover riprende.

Avvio di un failover nella console

  1. Passare alla lista di tutte le condivisioni file. Nella console IBM Cloud, fai clic sull'icona del menu di navigazione > icona VPC infrastruttura > Archiviazione > Condivisioni di archiviazione file.

  2. Fare clic sul nome di una condivisione file di replica per aprirne la pagina dei dettagli.

  3. Dal menu Azioni icona Azioni, selezionare Esegui failover. Prima del failover, viene eseguita una sincronizzazione finale dei file per garantire che la condivisione di failover contenga i contenuti più recenti. Una volta completato il failover, la condivisione file di replica diventa la nuova condivisione file di origine. La precedente condivisione di origine diventa la nuova condivisione di replica di sola lettura.

  4. Per impostare un valore di timeout, selezionare la casella in Timeout (facoltativo) e specificare un valore di tempo. Questo valore specifica un limite di tempo assoluto per il completamento del failover. Impostare un valore di timeout in base al tempo per cui è possibile avere la condivisione file offline.

  5. In Politica di failover, se l'operazione di failover non riesce o va in timeout, scegliere di mantenere la relazione di replica o modificarla:

    • Mantieni relazione di replica - Non vengono apportate modifiche alla condivisione file di replica o alla condivisione file di origine.
    • Rimuovi relazione di replica - Questa azione crea due condivisioni file di lettura/scrittura separate. Poiché la relazione è interrotta, le modifiche a una condivisione file non influiscono sull'altra.

    Dopo aver rotto la relazione, non può essere ristabilito.

  6. Fare clic su Esegui failover. Vengono visualizzati dei messaggi che indicano che il failover è stato richiesto e viene eseguito.

La pagina dei dettagli della condivisione file viene aggiornata e la relazione di replica mostra la condivisione file di replica come nuova condivisione file di origine.

Avvio di un failover dalla CLI

Prima di poter utilizzare la CLI, è necessario installare la CLI di “ IBM Cloud ” e il plug-in CLI per VPC. Per ulteriori informazioni, vedi i prerequisiti della CLI.

  1. Individuare la condivisione file di replica su cui si desidera eseguire il failover elencando tutte le condivisioni file nella regione con il comando ibmcloud is shares

    ibmcloud is shares
    
    Listing shares in all resource groups and region us-south under account Test Account as user test.user@ibm.com...
    ID                                          Name                    Lifecycle state   Zone         Profile   Size(GB)   Resource group   Replication role   Accessor binding role   Snapshot count   Snapshot size
    r006-a8d6af48-0c97-4c6b-bab1-fbefdc1e1e03   my-file-share           stable            us-south-2   dp2       10         defaults         none               none                    0                0
    r006-aaf4bfe9-358c-4faa-a4ec-0b955090b940   my-file-share-2         stable            us-south-2   dp2       10         defaults         none               none                    0                0
    r006-a60bfa90-a893-40ad-be34-28ab51a963f9   replica-dal-2           stable            us-south-2   dp2       10         defaults         replica            none                    0                0
    r006-3f21e3c3-e12d-425f-ab77-810cabfde8df   source-dal-1            stable            us-south-1   dp2       10         defaults         source             none                    0                0
    r006-455b601c-8fc1-4476-8771-4708c49c8ef7   my-replica-share-dal-1  stable            us-south-1   dp2       10         defaults         replica            none                    0                0
    r006-4dadac27-cd17-42df-a5fe-1388705d33e0   my-source-share-dal-2   stable            us-south-2   dp2       10         defaults         source             none                    0                0
    
    
  2. Eseguire il comando di ibmcloud is share-replica-failover e specificare la proprietà fallback-policy. È possibile specificare fail o split per questa proprietà.

    • Il seguente esempio specifica fail per la proprietà fallback-policy. Se l'operazione di failover ha esito negativo o viene raggiunto il timeout, l'operazione di failover ha esito negativo. La condivisione di origine rimane attiva e la replica riprende come pianificato.
    ibmcloud is share-replica-failover r006-a60bfa90-a893-40ad-be34-28ab51a963f9 --fallback-policy fail
    
    The file share r006-a60bfa90-a893-40ad-be34-28ab51a963f9 failover request was accepted under account Test Account as user test.user@ibm.com...
    The file share failover request was accepted.
    
    • Il seguente esempio specifica split per la proprietà fallback-policy. Se l'operazione di failover non riesce, la condivisione della replica viene suddivisa dalla condivisione del file di origine. Se il failover ha esito negativo, il risultato è due condivisioni file di lettura/scrittura indipendenti.
    ibmcloud is share-replica-failover my-source-share-dal-2 --fallback-policy split
    
    The file share r006-4dadac27-cd17-42df-a5fe-1388705d33e0 failover request was accepted under account Test Account as user test.user@ibm.com...
    The file share failover request was accepted.
    

Per ulteriori informazioni relative alle opzioni del comando, consultare ibmcloud is share-replica-failover.

Avvio di un failover con l'API

Effettuare una richiesta POST /shares/{share_id}/failover e specificare le proprietà timeout e fallback_policy. Il timeout minimo è 300 secondi e il timeout massimo è 3600 secondi. Questa richiesta avvia un failover di una condivisione file di origine nella condivisione replica, che è specificata dall'ID condivisione file di replica.

La proprietà fallback_policy può avere i valori: split o fail. Quando viene specificato fail, se l'operazione di failover ha esito negativo o se viene raggiunto il timeout, l'operazione di failover ha esito negativo. La relazione di replica rimane invariata.

Se si specifica split per la proprietà fallback_policy, la condivisione della replica viene suddivisa dalla condivisione di origine ogni volta che un'operazione di failover non riesce. Il risultato è due condivisioni file di lettura/scrittura indipendenti. In questo caso, poiché la sincronizzazione finale del file non è stata completata, la condivisione della replica potrebbe non contenere tutti i dati della condivisione del file di origine. Utilizzare questa opzione per il ripristino di emergenza, quando è noto che la condivisione file di origine non è raggiungibile.

Se la proprietà fallback_policy non è specificata nella richiesta, il sistema assume il valore predefinito split quando l'operazione di failover non riesce.

Questo esempio specifica fail per la proprietà fallback_policy. La proprietà timeout è facoltativa. È possibile utilizzare il timeout predefinito.

curl -X POST \
"$vpc_api_endpoint/v1/shares/$replica_id?/failover?version=2023-08-08"\
-H "Authorization: Bearer $iam_token"\
-d '{
     "fallback_policy": "fail",
      "timeout": 600
    }'

Una risposta corretta indica che la richiesta di failover della condivisione file è stata accettata.

È possibile utilizzare l'API per verificare che il failover della replica sia riuscito, in sospeso o non riuscito. Effettuare una chiamata GET /shares/{replica_id}. Esaminare la proprietà latest_job. Per ulteriori informazioni, consultare Verifica della replica con l'API.

Avvio di un failover con Terraform

Quando viene eseguito un failover, la condivisione della replica diventa l'origine e la condivisione dell'origine diventa la replica. La configurazione terraform deve essere modificata per corrispondere a questa modifica. La proprietà " fallback_policy " definisce l'azione da intraprendere nel caso in cui la richiesta di failover venga accettata ma non possa essere eseguita o superi il limite di tempo. I valori accettati sono split o fail. Se si specifica split e il failover ha esito negativo, il sistema interrompe la relazione di replica e le due condivisioni file diventano indipendenti l'una dall'altra.

resource "ibm_is_share_replica_operations" "test" {
  share_replica = ibm_is_share.replica.id
  fallback_policy = "split"
  timeout = 500
}

Per ulteriori informazioni sugli argomenti e gli attributi, vedi ibm_is_share_replica_operations.

Passi successivi

Gestisci replica.