Panoramica della replica

Dopo aver creato una condivisione file, è possibile configurare la replica.

Quando viene creata una condivisione di replica, la prima replica contiene i dati dell'intera condivisione. Successivamente, vengono aggiunte solo le modifiche che si sono verificate dopo la precedente replica.

È possibile creare una condivisione di replica in un'altra zona della stessa regione. Puoi anche creare una replica in un'altra regione nella stessa area geografica, se hai un altro VPC nella regione di destinazione. La replica tra aree geografiche non è supportata.

Quando si crea la condivisione file di replica in un'altra zona della stessa regione, la condivisione replica eredita il tipo di crittografia e la chiave dalla condivisione file di origine. Impossibile modificare la cifratura.

Quando si replica la propria condivisione file in un'altra regione, la replica deve corrispondere al tipo di codifica di cui dispone la condivisione di origine. Tuttavia, non eredita la codifica dall'origine. In altre parole, se la condivisione di origine è codificata con le chiavi gestite dal provider, anche la replica deve avere la codifica gestita dal provider. Se la condivisione di origine è codificata con una chiave gestita dal cliente, la replica deve essere codificata anche con una chiave gestita dal cliente. Tuttavia, non deve essere la stessa chiave. Quando si crea la replica, specificare il nome della risorsa cloud (CRN) della chiave che si desidera utilizzare.

In base alla pianificazione della replica, il servizio estrae i dati dalla condivisione file di origine alla condivisione file di replica. È possibile scegliere la frequenza con cui si desidera sincronizzare le modifiche dalla condivisione di origine alla replica. È possibile specificare una pianificazione di replica oraria, giornaliera, settimanale o mensile. Le repliche devono essere programmate ad almeno 15 minuti di distanza l'una dall'altra.

Sebbene non sia possibile creare istantanee di una condivisione di replica manualmente o programmaticamente, le istantanee della condivisione di origine vengono copiate nella condivisione di replica alla successiva sincronizzazione programmata. Se una condivisione di origine con snapshot viene replicata, le snapshot della condivisione corrispondente vengono create con nomi generati dal sistema, anziché ereditare i nomi delle snapshot della condivisione di origine. Poiché le istantanee replicate condividono l'ID dell'impronta digitale della sorgente, è possibile utilizzare l'impronta digitale per correlare le istantanee.

Quando esegui la replica tra le regioni, i dati superano i limiti VPC. Per la replica zonale delle condivisioni di file, sia le VPC che le condivisioni di file devono appartenere allo stesso account ed è necessario stabilire autorizzazioni da servizio a servizio tra i servizi di file delle due regioni.

I dati vengono crittografati in transito mentre si spostano tra le condivisioni file. Gli addebiti per i trasferimenti di dati tra le due condivisioni di file vengono calcolati con una tariffa fissa in incrementi di GB. Gli addebiti si basano sulla quantità di dati trasferiti durante l'intero periodo di fatturazione.

Quando replichi i dati tra le regioni, considera le leggi sulla residenza dei dati locali perché spostare i dati oltre i confini può avere implicazioni legali.

La replica è un'operazione asincrono e non è istantanea. È possibile utilizzare le informazioni di sincronizzazione della duplicazione per visualizzare la durata del processo di replica e la velocità di trasferimento. Riesaminando le informazioni di sincronizzazione della replica, è possibile regolare la pianificazione della replica e bilanciare i costi con la frequenza con cui è necessario aggiornare i dati sulla replica. Visualizzando i log del lavoro e le velocità di trasferimento, è inoltre possibile determinare se la dimensione dei dati che devono essere trasferiti si adatta alla finestra di replica.

Per completare la replica è necessario che la capacità inutilizzata della condivisione file sia sufficiente. Durante il processo di replica, i nuovi dati dell'origine vengono copiati sul volume di replica. I vecchi dati non vengono sovrascritti immediatamente, ma vengono rimossi al termine dell'operazione di copia. Ad esempio, se la condivisione ha una capacità del 95% e il tasso di modifica è del 10%, la replica potrebbe non avere spazio sufficiente per contenere le modifiche. Se la replica non dispone di spazio sufficiente per contenere gli aggiornamenti, il processo di replica fallisce. È possibile monitorare la capacità della condivisione file nella console e configurare avvisi per l'utilizzo. Per ulteriori informazioni, vedere Monitoraggio delle metriche per File Storage for VPC.

I dati relativi alla quota della replica sono di sola lettura. È possibile ottenere l'accesso in lettura / scrittura ai dati in due modi:

• Failover sul sito di replica- Le operazioni di lettura / scrittura dalla condivisione file di origine vengono sospese e una copia finale dei dati della condivisione file viene inserita nella condivisione replica. La condivisione della replica diventa accessibile in lettura/scrittura e viene stabilita una relazione di replica inversa. La condivisione del file sorgente originale diventa ora la condivisione della replica e viene impostata come di sola lettura. Il servizio inizia quindi a estrarre i dati dalla nuova condivisione file di origine.

  Se una condivisione file di origine è compromessa, le condivisioni di replica sono un buon modo per ripristinare le operazioni. Il failover su una condivisione replica contribuisce a garantire che i servizi non subiscano interruzioni.

  Quando si avvia il failover, è possibile specificare cosa accade alla relazione di replica se il processo di failover va in timeout o non riesce. Questa opzione viene solitamente utilizzata quando è necessario specificare per quanto tempo la condivisione di file può rimanere offline. È necessario specificare cosa si desidera che accada se l'operazione va in timeout o se la replica non riesce a causa del sito originale, che è danneggiato o non disponibile.

  • Se il sito di origine non è disponibile a causa di una manutenzione pianificata, è possibile scegliere di mantenere la relazione di replica. La replica riprende come pianificato quando il sito di origine originale è di nuovo operativo.
  • In una situazione di ripristino di emergenza, è possibile scegliere di suddividere i volumi per portare la condivisione della replica in linea il più presto possibile. Tuttavia, in questo caso, potresti non disporre del set di dati più recente e potrebbe essere necessario riconciliare manualmente lo stato nella tua applicazione. Poiché la relazione di duplicazione è stata interrotta, è necessario impostare nuovamente la replica quando il sito originale diventa nuovamente operativo.

• Rimuovi la relazione della replica- In questo caso, si dividono le due condivisioni e si creano due condivisioni file indipendenti. Entrambe le condivisioni sono accessibili in lettura / scrittura e i dati non sono più sincronizzati tra i due. Nell 'API, questa operazione è nota come operazione di split replica. La rimozione della relazione di replica è permanente, non è possibile ristabilirla tra le due condivisioni. Tuttavia, è possibile creare nuove repliche nella stessa zona o in altre zone della stessa regione.

La rimozione della relazione di replica o il failover sulla replica non si verifica quando viene eseguita un'altra operazione sulla condivisione del file di origine o di replica. Un esempio di tale operazione è l'espansione della dimensione della condivisione file. L'operazione di split o failover rimane in stato di attesa fino al completamento dell'altra operazione.

Casi di utilizzo

È possibile utilizzare la replica per risolvere i problemi di ripristino di emergenza. La replica si riferisce a questi scenari:

• Ripristino di emergenza da un malfunzionamento dell'applicazione.

  In questo scenario, l'applicazione che si sta eseguendo non riesce. I dati non sono interessati, ma l'applicazione non è operativa. È possibile eseguire un failover, in cui i dati vengono sospesi e inviati a un'altra zona. Le istanze del server virtuale in tale zona possono essere configurate per assumere il controllo del funzionamento dell'applicazione mentre i server primari vengono riparati.

• Ripristino di emergenza a causa di un errore dell'infrastruttura IBM Cloud.

  In questo scenario, la zona di disponibilità IBM Cloud in cui è in esecuzione la tua applicazione diventa inutilizzabile. È necessario avviare l'applicazione nell'ubicazione di replica il prima possibile e utilizzare i dati replicati dall'ultimo evento di replica. È possibile avviare il failover con l'opzione split per rendere indipendente il volume di replica. La replica è stata arrestata.

• Facilita la manutenzione regolare delle tue applicazioni.

  Utilizzare la replica per facilitare alcune attività di gestione, ad esempio gli aggiornamenti con una maggiore disponibilità. Migrare i dati tra due zone che potrebbero eseguire livelli differenti di codice dell'applicazione. L'esecuzione in due ambienti in modo indipendente consente una maggiore flessibilità nel processo di implementazione.

• Migrazione dei dati o espansione geografica.

  Puoi utilizzare la replica per migrare facilmente i dati tra due regioni MZR. Una volta replicati i dati, è possibile rimuovere la relazione di duplicazione e la condivisione del file di replica diventa disponibile con i dati pronti per essere utilizzati in modo indipendente nella nuova regione.

Passi successivi

1. Creare una condivisione di file di replica nella console, dalla CLI, con l'API o con Terraform.

   Per impostare la replica tra regioni diverse, è necessario innanzitutto stabilire autorizzazioni da servizio a servizio tra i servizi file delle due VPC.

   Se si desidera creare una condivisione di repliche in una regione differente in cui si utilizza una diversa soluzione KMS, stabilire le autorizzazioni service - to - service tra il servizio file e il KMS di destinazione.

2. Verificare che la replica stia funzionando controllando lo stato della replica e le informazioni di sincronizzazione della replica. Il sistema interroga l'ultimo stato di sincronizzazione ogni 15 minuti.

3. Utilizzare la condivisione file di replica - Se la condivisione file principale non riesce o diventa non disponibile per qualsiasi motivo, è possibile eseguire il failover sulla condivisione file di replica. Quando si esegue il failover, la condivisione della replica diventa la nuova condivisione del file primario, con capacità di lettura e scrittura.

4. Riavviare la replica con la condivisione file originale come pianificato quando è di nuovo online. In questo caso, è possibile continuare ad utilizzare il sito di replica come principale o eseguire il failback sul sito originale.