Pianificare il ripristino di emergenza

Questa pagina fornisce informazioni che puoi utilizzare per pianificare il ripristino di emergenza per i carichi di lavoro in esecuzione nell'ambiente Bare Metal Solution.

Bare Metal Solution viene fornito da un'estensione della regione. A partire da febbraio 2024, tutte le regioni Bare Metal Solution sono ospitate fisicamente in strutture non Google. A causa del modello di estensione della regione, Bare Metal Solution non segue il modello di separazione zonale convenzionale utilizzato da altri Google Cloud servizi, come Compute Engine. Ogni deployment di Bare Metal Solution all'interno di un'estensione della regione è noto come pod. In alcune regioni, le risorse Bare Metal Solution vengono fornite da più pod, ma non è necessario né previsto che i pod siano separati geograficamente.

Se esegui carichi di lavoro mission-critical, ti consigliamo di pianificare il ripristino di emergenza.

Risorse consigliate per la pianificazione del ripristino di emergenza

Ti consigliamo di consultare le seguenti risorse per pianificare il ripristino di emergenza:

Connettività tra i pod

I pod e le estensioni della regione non hanno connettività diretta. Tutto il traffico (in entrata e in uscita) del deployment di Bare Metal Solution transita su un'interconnessione e attraverso il Google Cloud backbone. Non è supportato alcun percorso dati per la replica a livello di archiviazione. In questo modo, le opzioni di ripristino di emergenza basate sulle tecnologie di archiviazione, come la replica dell'archiviazione a blocchi o la replica di snapshot remoti, vengono eliminate.

Pianificazione della regione di disaster recovery

Quando selezioni le regioni per la pianificazione del ripristino di emergenza, tieni presente i seguenti punti:

  • In genere, puoi selezionare una regione Bare Metal Solution in base ad altri Google Cloud servizi che utilizzi. Tuttavia, il ripristino di emergenza per i database in genere rientra nelle regioni utilizzate per le applicazioni corrispondenti e le relative integrazioni. Pertanto, quando pianifichi le regioni da utilizzare per ripristino di emergenza, tieni conto della latenza di rete tra le regioni.

  • A seconda del settore, potrebbero essere presenti requisiti normativi relativi alla località dei dati che determinano dove puoi replicare i dati. Ogni applicazione ha i propri requisiti, quindi la selezione della regione di ripristino di emergenza specifica dipende da te.

  • Bare Metal Solution gestisce determinati componenti del piano di controllo per un gruppo di regioni, collettivamente chiamate GeoSector. Un errore di questi componenti può influire sulle operazioni del piano di controllo, come la creazione di database, le operazioni di avvio e arresto o lo scaling dell'archiviazione in una o più regioni all'interno del GeoSector. A seconda dei requisiti aziendali, quando esegui il deployment in più regioni, ti consigliamo di selezionare regioni in GeoSector separati per una maggiore affidabilità.

    Per garantire la resilienza di Bare Metal Solution, ti consigliamo di procedere come indicato di seguito:

    1. Mappa gli ambienti di ripristino di emergenza primario e secondario ai GeoSector indicati nella tabella seguente:

      GeoSector Google Cloud regione
      ap1 asia-northeast1
      asia-northeast3
      ap2 asia-southeast1
      eu1 europe-west2
      europe-west3
      eu2 europe-west4
      us1 northamerica-northeast1
      northamerica-northeast2
      southamerica-east1
      us-central1
      us-west2
      us2 us-central2
      us-east4

    2. Configura la configurazione di ripristino di emergenza in GeoSector separati. Se non hai una configurazione di ripristino di emergenza o se gli ambienti primario e secondario sono sottoposti a deployment nello stesso GeoSector, esegui la transizione dell'ambiente secondario a un GeoSector diverso per una maggiore resilienza.

Considerazioni di networking

Isolare il traffico per l'interconnessione

In molti casi, potresti voler isolare il traffico di replica dalle sessioni dell'applicazione.

L'isolamento del traffico può essere ottenuto mediante il provisioning di interconnessioni partner separate in ogni regione che terminano in un VPC di transito utilizzato per la replica. Il seguente diagramma illustra questo tipo di configurazione.

Isolamento del traffico tramite interconnessioni separate.

Nel diagramma, i server Bare Metal Solution nella regione us-west2 utilizzano la rete 10.10.10.0/24 e i server Bare Metal Solution nella regione us-east4 utilizzano la rete 10.20.20.0/24. Il progetto utente contiene VPC separati per il traffico delle applicazioni e della replica, denominati rispettivamente Application VPC e Replication VPC. Gli annunci BGP sono configurati in modo che ogni router Cloud in Replication VPC annunci una route alla rete Bare Metal Solution cross-region, forzando il traffico cross-region a fluire su Replication VPC. I router Cloud in Application VPC annunciano una route 0.0.0.0/0 generica o route a blocchi CIDR specifici con cui i server Bare Metal Solution devono comunicare. In questo esempio, 0.0.0.0/0 viene utilizzato per indicare una route che invia il traffico a qualsiasi altra destinazione.

I server delle applicazioni e altri servizi che si connettono dai data center on-premise si connettono tramite Application VPC. Le istanze all'interno di Application VPC possono comunque comunicare con i database in esecuzione in entrambe le estensioni della regione Bare Metal Solution.

Le interconnessioni che terminano nel VPC di transito possono essere utilizzate anche per accedere a Google Cloud servizi come Cloud Storage, Filestore, o Backup e RE. Ciò può essere ottenuto creando l' istanza Filestore nel VPC di transito o utilizzando gli endpoint di Private Service Connect che si trovano all'interno del VPC di transito.