Questa pagina è stata tradotta dall'API Cloud Translation.

Ripristino di emergenza per Dataproc Metastore

Dataproc Metastore

Questo tutorial propone una strategia di ripristino di emergenza e continuità aziendale a due regioni utilizzando Dataproc Metastore. Il tutorial utilizza bucket a due regioni per l'archiviazione di set di dati Hive e esportazioni di metadati Hive.

Dataproc Metastore è un servizio di metastore completamente gestito, a disponibilità elevata, con scalabilità automatica, riparazione automatica e nativo del sistema operativo OSS che semplifica notevolmente la gestione dei metadati tecnici. Il nostro servizio gestito si basa su Apache Hive Metastore e funge da componente fondamentale per i data lake aziendali.

Questo tutorial è progettato per i clienti di Google Cloud che richiedono un'alta disponibilità per i propri dati e metadati Hive. Utilizza Cloud Storage per l'archiviazione, Dataproc per il computing e Dataproc Metastore (DPMS), un servizio Hive Metastore completamente gestito su Google Cloud. Il tutorial presenta anche due diversi modi per orchestrare i failover: una utilizza Cloud Run e Cloud Scheduler, l'altra Cloud Composer.

L'approccio a due regioni utilizzato nel tutorial presenta vantaggi e svantaggi:

Vantaggi

I bucket a due regioni sono con ridondanza geografica.
I bucket a due regioni hanno uno SLA (accordo sul livello del servizio) con disponibilità del 99,95%, rispetto alla disponibilità del 99,9% dei bucket per una singola regione.
I bucket a due regioni offrono prestazioni ottimizzate in due regioni, mentre i bucket a regione singola non offrono prestazioni altrettanto buone quando si utilizzano risorse in altre regioni.

Svantaggi

Le scritture di bucket a due regioni non vengono immediatamente replicate in entrambe le regioni.
I bucket a due regioni hanno costi di archiviazione più elevati rispetto ai bucket a singola regione.

Architettura di riferimento

I seguenti diagrammi dell'architettura mostrano i componenti che utilizzi in questo tutorial. In entrambi i diagrammi, la grande X rossa indica l'errore della regione principale:

Figura 1: utilizzo di Cloud Run e Cloud Scheduler

Utilizzo di Cloud Composer per il failover da una regione principale a una regione secondaria. Figura 2: utilizzo di Cloud Composer

I componenti della soluzione e le loro relazioni sono:

Due bucket a due regioni per Cloud Storage: puoi creare un bucket per i dati Hive e un bucket per i backup periodici dei metadati Hive. Creare entrambi i bucket a due regioni in modo da utilizzare le stesse regioni dei cluster Hadoop che accedono ai dati.
Un metastore Hive che utilizza DPMS: devi creare questo metastore Hive nella tua regione principale (regione A). La configurazione del metastore punta al bucket di dati Hive. Un cluster Hadoop che utilizza Dataproc deve trovarsi nella stessa regione dell'istanza DPMS a cui è associato.
Una seconda istanza DPMS:creerai una seconda istanza DPMS nella tua regione di standby (regione B) per prepararti a un errore a livello di regione. Quindi importi il file di esportazione hive.sql più recente dal tuo bucket di esportazione nel DPMS in standby. Creerai anche un cluster Dataproc nella regione in standby e lo collegherai all'istanza DPMS in standby. Infine, in uno scenario di ripristino di emergenza, reindirizzi le tue applicazioni client dal cluster Dataproc nella regione A al cluster Dataproc nella regione B.
Un deployment Cloud Run: crei un deployment Cloud Run nella regione A che esporta periodicamente i metadati DPMS in un bucket di backup dei metadati utilizzando Cloud Scheduler (come mostrato nella Figura 1). L'esportazione assume la forma di un file SQL che contiene un dump completo dei metadati DPMS.

Nota: Cloud Scheduler ha una dipendenza da App Engine. Di conseguenza, può essere configurato per una sola regione per progetto Google Cloud. Pertanto, utilizza Cloud Scheduler solo per scenari di ripristino di emergenza a breve termine in cui la durata del failover alla regione B viene misurata in ore o giorni anziché in settimane o mesi.

Se hai già un ambiente Cloud Composer, puoi orchestrare le esportazioni e le importazioni dei metadati DPMS eseguendo un DAG Airflow su quell'ambiente (come mostrato nella Figura 2). Questo utilizzo di un DAG Airflow sostituisce il metodo Cloud Run citato in precedenza.

Obiettivi

Configura l'archiviazione a due regioni per i backup di dati Hive e Hive Metastore.
Esegui il deployment di Dataproc Metastore e di un cluster Dataproc nelle regioni A e B.
Esegui il failover del deployment nella regione B.
Fai tornare il deployment nella regione A.
Crea backup automatizzati del metastore Hive.
Orchestra esportazioni e importazioni di metadati tramite Cloud Run.
Orchestrare le esportazioni e le importazioni di metadati tramite Cloud Composer.

Costi

In questo documento, utilizzi i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

Prima di iniziare

Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

Abilita le API Dataproc, and Dataproc Metastore.

Abilita le API

Create a service account:

In the Google Cloud console, go to the Create service account page.
Go to Create service account
Select your project.
In the Service account name field, enter a name. The Google Cloud console fills in the Service account ID field based on this name.

In the Service account description field, enter a description. For example, Service account for quickstart.
Click Create and continue.
Grant the Project > Owner role to the service account.

To grant the role, find the Select a role list, then select Project > Owner.

Note: The Role field affects which resources the service account can access in your project. You can revoke these roles or grant additional roles later. In production environments, do not grant the Owner, Editor, or Viewer roles. Instead, grant a predefined role or custom role that meets your needs.
Click Continue.
Click Done to finish creating the service account.

Do not close your browser window. You will use it in the next step.

Create a service account key:

In the Google Cloud console, click the email address for the service account that you created.
Click Keys.
Click Add key, and then click Create new key.
Click Create. A JSON key file is downloaded to your computer.
Click Close.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

Abilita le API Dataproc, and Dataproc Metastore.

Abilita le API

Create a service account:

In the Google Cloud console, go to the Create service account page.
Go to Create service account
Select your project.
In the Service account name field, enter a name. The Google Cloud console fills in the Service account ID field based on this name.

In the Service account description field, enter a description. For example, Service account for quickstart.
Click Create and continue.
Grant the Project > Owner role to the service account.

To grant the role, find the Select a role list, then select Project > Owner.

Note: The Role field affects which resources the service account can access in your project. You can revoke these roles or grant additional roles later. In production environments, do not grant the Owner, Editor, or Viewer roles. Instead, grant a predefined role or custom role that meets your needs.
Click Continue.
Click Done to finish creating the service account.

Do not close your browser window. You will use it in the next step.

Create a service account key:

In the Google Cloud console, click the email address for the service account that you created.
Click Keys.
Click Add key, and then click Create new key.
Click Create. A JSON key file is downloaded to your computer.
Click Close.

inizializza l'ambiente

In Cloud Shell, avvia un'istanza di Cloud Shell.

Clona il repository GitHub del tutorial:

git clone https://github.com/GoogleCloudPlatform/metastore-disaster-recovery.git

Abilita le seguenti API Google Cloud:

gcloud services enable dataproc.googleapis.com metastore.googleapis.com

Imposta alcune variabili di ambiente:

export PROJECT=$(gcloud info --format='value(config.project)')
export WAREHOUSE_BUCKET=${PROJECT}-warehouse
export BACKUP_BUCKET=${PROJECT}-dpms-backups
export DPMS_PRIMARY_REGION=us-central1
export DPMS_STANDBY_REGION=us-east1
export DPMS_PRIMARY_INSTANCE=dpms1
export DPMS_STANDBY_INSTANCE=dpms2
export HADOOP_PRIMARY=dataproc-cluster1
export HADOOP_STANDBY=dataproc-cluster2

Creazione di spazio di archiviazione per i dati Hive e i backup di Hive Metastore

In questa sezione creerai i bucket Cloud Storage per ospitare i dati Hive e i backup di Hive Metastore.

Crea archiviazione dati Hive

In Cloud Shell, crea un bucket a due regioni per ospitare i dati di Hive:
```
gsutil mb -c standard -l us-east1+us-central1 gs://${WAREHOUSE_BUCKET}
```

Copia alcuni dati di esempio nel bucket di dati Hive:

gsutil -m cp -r gs://retail_csv gs://${WAREHOUSE_BUCKET}/retail

Crea spazio di archiviazione per i backup dei metadati

In Cloud Shell, crea un bucket a due regioni per ospitare i backup dei metadati DPMS:
```
gsutil mb -c standard -l us-east1+us-central1 us gs://${BACKUP_BUCKET}
```

Deployment di risorse di computing nella regione principale

In questa sezione eseguirai il deployment di tutte le risorse di computing nella regione principale, inclusi l'istanza DPMS e il cluster Dataproc. Inoltre, compila Dataproc Metastore con metadati di esempio.

crea l'istanza DPMS

In Cloud Shell, crea l'istanza DPMS:
```
gcloud metastore services create ${DPMS_PRIMARY_INSTANCE} \
    --location=${DPMS_PRIMARY_REGION} \
    --hive-metastore-version=3.1.2
```
Il completamento di questo comando può richiedere diversi minuti.

Nota: Hive Metastore versione 3.1.2 è compatibile con Dataproc Image versione 2.0. Entrambi usano Hive versione 3.1.2. Se utilizzi una versione diversa di Hive Metastore, assicurati di utilizzare un'immagine Dataproc compatibile che corrisponda alla versione di Hive.

Imposta il bucket di dati Hive come directory del warehouse predefinito:

gcloud metastore services update ${DPMS_PRIMARY_INSTANCE} \
    --location=${DPMS_PRIMARY_REGION} \
    --update-hive-metastore-configs="hive.metastore.warehouse.dir=gs://${PROJECT}-  warehouse"

Il completamento di questo comando può richiedere diversi minuti.

Crea un cluster Dataproc

In Cloud Shell, crea un cluster Dataproc e collegalo all'istanza DPMS:
```
gcloud dataproc clusters create ${HADOOP_PRIMARY} \
    --dataproc-metastore=projects/${PROJECT}/locations/${DPMS_PRIMARY_REGION}/services/${DPMS_PRIMARY_INSTANCE} \
    --region=${DPMS_PRIMARY_REGION} \
    --image-version=2.0
```
Specifica l'immagine del cluster come versione 2.0, ovvero l'ultima versione disponibile a partire da giugno 2021. È inoltre la prima versione che supporta DPMS.

Compila il metastore

In Cloud Shell, aggiorna l'esempio retail.hql fornito nel repository di questo tutorial con il nome del bucket di dati Hive:
```
sed -i -- 's/${WAREHOUSE_BUCKET}/'"$WAREHOUSE_BUCKET"'/g' retail.hql
```

Esegui le query contenute nel file retail.hql per creare le definizioni della tabella nel metastore:

gcloud dataproc jobs submit hive \
    --cluster=${HADOOP_PRIMARY} \
    --region=${DPMS_PRIMARY_REGION} \
    --file=retail.hql

Verifica che le definizioni della tabella siano state create correttamente:

gcloud dataproc jobs submit hive \
    --cluster=${HADOOP_PRIMARY} \
    --region=${DPMS_PRIMARY_REGION} \
    --execute="
    desc departments;
    desc categories;
    desc products;
    desc order_items;
    desc orders;
    desc customers;

    select count(*) as num_departments from departments;
    select count(*) as num_categories from categories;
    select count(*) as num_products from products;
    select count(*) as num_order_items from order_items;
    select count(*) as num_orders from orders;
    select count(*) as num_customers from customers;
  "

L'output è simile al seguente:

+------------------+------------+----------+
|     col_name     | data_type  | comment  |
+------------------+------------+----------+
| department_id    | int        |          |
| department_name  | string     |          |
+------------------+------------+----------+

L'output contiene anche il numero di elementi in ogni tabella, ad esempio:

+----------------+
| num_customers  |
+----------------+
| 12435          |
+----------------+

Esegui il failover nella regione in standby

Questa sezione illustra i passaggi per eseguire il failover dalla regione principale (regione A) a quella in standby (regione B).

In Cloud Shell, esporta i metadati dell'istanza DPMS principale nel bucket di backup:

gcloud metastore services export gcs ${DPMS_PRIMARY_INSTANCE}  \
    --location=${DPMS_PRIMARY_REGION} \
    --destination-folder=gs://${BACKUP_BUCKET}

L'output è simile al seguente:

metadataManagementActivity:
metadataExports:
‐ databaseDumpType: MYSQL
    destinationGcsUri: gs://qa01-300915-dpms-backups/hive-export-2021-05-04T22:21:53.288Z
    endTime: '2021-05-04T22:23:35.982214Z'
    startTime: '2021-05-04T22:21:53.308534Z'
    state: SUCCEEDED

Prendi nota del valore nell'attributo destinationGcsUri. Questo attributo archivia il backup che hai creato.

Crea una nuova istanza DPMS nella regione in standby:

gcloud metastore services create ${DPMS_STANDBY_INSTANCE} \
    --location=${DPMS_STANDBY_REGION} \
    --hive-metastore-version=3.1.2

Imposta il bucket di dati Hive come directory del warehouse predefinito:

gcloud metastore services update ${DPMS_STANDBY_INSTANCE} \
    --location=${DPMS_STANDBY_REGION} \
    --update-hive-metastore-configs="hive.metastore.warehouse.dir=gs://${PROJECT}-warehouse"

Recupera il percorso dell'ultimo backup dei metadati:

IMPORT_DIR=`gsutil ls gs://${BACKUP_BUCKET} | sort -k 1 | tail -1`
IMPORT_SQL="${IMPORT_DIR}hive.sql"
echo ${IMPORT_SQL}

Importa i metadati di cui hai eseguito il backup nella nuova istanza Dataproc Metastore:

gcloud metastore services import gcs ${DPMS_STANDBY_INSTANCE} \
    --location=${DPMS_STANDBY_REGION} \
    --dump-type=mysql \
    --database-dump=${IMPORT_SQL} \
    --import-id=import-$(date +"%Y-%m-%d-%H-%M-%S")

Crea un cluster Dataproc nella regione in standby (regione B):

gcloud dataproc clusters create ${HADOOP_STANDBY} \
    --dataproc-metastore=projects/${PROJECT}/locations/${DPMS_STANDBY_REGION}/services/${DPMS_STANDBY_INSTANCE} \
    --region=${DPMS_STANDBY_REGION} \
    --image-version=2.0

Verifica che i metadati siano stati importati correttamente:
```
gcloud dataproc jobs submit hive \
    --cluster ${HADOOP_STANDBY} \
    --region ${DPMS_STANDBY_REGION} \
    --execute "select count(*) as num_orders from orders;"
```
L'num_ordersoutput è il più importante per il tutorial. È simile al seguente:
```
+-------------+
| num_orders  |
+-------------+
| 68883       |
+-------------+
```
Il Dataproc Metastore principale è diventato il nuovo metastore in standby, mentre Dataproc Metastore in standby è diventato il nuovo metastore principale.

Aggiorna le variabili di ambiente in base a questi nuovi ruoli:

export DPMS_PRIMARY_REGION=us-east1
export DPMS_STANDBY_REGION=us-central1]
export DPMS_PRIMARY_INSTANCE=dpms2
export DPMS_STANDBY_INSTANCE=dpms1
export HADOOP_PRIMARY=dataproc-cluster2
export HADOOP_STANDBY=dataproc-cluster1

Verifica di poter scrivere nel nuovo Dataproc Metastore principale nella regione B:

gcloud dataproc jobs submit hive \
    --cluster ${DPMS_PRIMARY_INSTANCE} \
    --region ${DPMS_PRIMARY_REGION} \
    --execute "create view completed_orders as select * from orders where order_status = 'COMPLETE';"

gcloud dataproc jobs submit hive \
    --cluster ${HADOOP_PRIMARY} \
    --region ${DPMS_PRIMARY_REGION} \
    --execute "select * from completed_orders limit 5;"

L'output contiene quanto segue:

+----------------------------+------------------------------+-------------------------------------+--------------------------------+
| completed_orders.order_id  | completed_orders.order_date  | completed_orders.order_customer_id  | completed_orders.order_status  |
+----------------------------+------------------------------+-------------------------------------+--------------------------------+
| 3                          | 2013-07-25 00:00:00.0        | 12111                               | COMPLETE                       |
| 5                          | 2013-07-25 00:00:00.0        | 11318                               | COMPLETE                       |
| 6                          | 2013-07-25 00:00:00.0        | 7130                                | COMPLETE                       |
| 7                          | 2013-07-25 00:00:00.0        | 4530                                | COMPLETE                       |
| 15                         | 2013-07-25 00:00:00.0        | 2568                                | COMPLETE                       |
+----------------------------+------------------------------+-------------------------------------+--------------------------------+

Il failover è stato completato. Ora devi reindirizzare le applicazioni client al nuovo cluster Dataproc principale nella regione B aggiornando i file di configurazione del client Hadoop.

Ripristino della regione originale in corso...

Questa sezione illustra i passaggi per eseguire il failover alla regione originale (regione A).

In Cloud Shell, esporta i metadati dall'istanza DPMS:

gcloud metastore services export gcs ${DPMS_PRIMARY_INSTANCE} \
    --location=${DPMS_PRIMARY_REGION} \
    --destination-folder=gs://${BACKUP_BUCKET}

Recupera il percorso dell'ultimo backup dei metadati:

IMPORT_DIR=`gsutil ls gs://${BACKUP_BUCKET} | sort -k 1 | tail -1`
IMPORT_SQL="${IMPORT_DIR}hive.sql"
echo ${IMPORT_SQL}

Importa i metadati nell'istanza DPMS in standby nella regione originale (regione A):

gcloud metastore services import gcs ${DPMS_STANDBY_INSTANCE} \
    --location=${DPMS_STANDBY_REGION} \
    --dump-type=mysql \
    --database-dump=${IMPORT_SQL} \
    --import-id=import-$(date +"%Y-%m-%d-%H-%M-%S")

Verifica che i metadati siano stati importati correttamente:

gcloud dataproc jobs submit hive \
    --cluster ${HADOOP_STANDBY} \
    --region ${DPMS_STANDBY_REGION} \
    --execute "select * from completed_orders limit 5;"

L'output include quanto segue:

+----------------------------+------------------------------+-------------------------------------+--------------------------------+
| completed_orders.order_id  | completed_orders.order_date  | completed_orders.order_customer_id  | completed_orders.order_status  |
+----------------------------+------------------------------+-------------------------------------+--------------------------------+
| 3                          | 2013-07-25 00:00:00.0        | 12111                               | COMPLETE                       |
| 5                          | 2013-07-25 00:00:00.0        | 11318                               | COMPLETE                       |
| 6                          | 2013-07-25 00:00:00.0        | 7130                                | COMPLETE                       |
| 7                          | 2013-07-25 00:00:00.0        | 4530                                | COMPLETE                       |
| 15                         | 2013-07-25 00:00:00.0        | 2568                                | COMPLETE                       |
+----------------------------+------------------------------+-------------------------------------+--------------------------------+

I ruoli Dataproc Metastore e Dataproc Metastore principali sono stati scambiati di nuovo.

Aggiorna le variabili di ambiente in base a questi nuovi ruoli:

export DPMS_PRIMARY_REGION=us-central1
export DPMS_STANDBY_REGION=us-east1
export DPMS_PRIMARY_INSTANCE=dpms1
export DPMS_STANDBY_INSTANCE=dpms12
export HADOOP_PRIMARY=dataproc-cluster1
export HADOOP_STANDBY=dataproc-cluster2

Il failover è stato completato. Ora devi reindirizzare le applicazioni client al nuovo cluster Dataproc principale nella regione A aggiornando i file di configurazione del client Hadoop.

Creazione di backup automatici dei metadati

Questa sezione illustra due diversi metodi per automatizzare le esportazioni e le importazioni del backup dei metadati. Il primo metodo, Opzione 1: Cloud Run e Cloud Scheduler, utilizza Cloud Run e Cloud Scheduler. Il secondo metodo, Opzione 2: Cloud Composer, utilizza Cloud Composer. In entrambi gli esempi, un job di esportazione crea un backup dei metadati dal DPMS principale nella regione A. Un job di importazione compila il DPMS in standby nella regione B dal backup.

Se hai già un cluster Cloud Composer, dovresti prendere in considerazione l'opzione 2: Cloud Composer (supponendo che il cluster abbia una capacità di calcolo sufficiente). Altrimenti, scegli l'opzione 1: Cloud Run e Cloud Scheduler. Questa opzione utilizza un modello di prezzi con pagamento a consumo ed è più economica di Cloud Composer, che richiede l'utilizzo di risorse di calcolo permanenti.

Opzione 1: Cloud Run e Cloud Scheduler

Questa sezione mostra come utilizzare Cloud Run e Cloud Scheduler per automatizzare le esportazioni delle importazioni dei metadati DPMS.

Servizi Cloud Run

Questa sezione mostra come creare due servizi Cloud Run per eseguire i job di esportazione e importazione dei metadati.

In Cloud Shell, abilita le API Cloud Run, Cloud Scheduler, Cloud Build e App Engine:
```
gcloud services enable run.googleapis.com cloudscheduler.googleapis.com cloudbuild.googleapis.com appengine.googleapis.com
```
Puoi abilitare l'API App Engine perché il servizio Cloud Scheduler richiede App Engine.

Crea l'immagine Docker con il Dockerfile fornito:

cd metastore-disaster-recovery
gcloud builds submit --tag gcr.io/$PROJECT/dpms_dr

Esegui il deployment dell'immagine container in un servizio Cloud Run nella regione principale (regione A). Questo deployment è responsabile della creazione dei backup dei metadati dal metastore principale:
```
gcloud run deploy dpms-export \
    --image gcr.io/${PROJECT}/dpms_dr \
    --region ${DPMS_PRIMARY_REGION} \
    --platform managed \
    --update-env-vars DPMS_STANDBY_REGION=${DPMS_STANDBY_REGION},BACKUP_BUCKET=${BACKUP_BUCKET},DPMS_STANDBY_INSTANCE=${DPMS_STANDBY_INSTANCE},DPMS_PRIMARY_INSTANCE=${DPMS_PRIMARY_INSTANCE},DPMS_PRIMARY_REGION=${DPMS_PRIMARY_REGION} \
    --allow-unauthenticated \
    --timeout=10m
```
Per impostazione predefinita, una richiesta di servizio Cloud Run scade dopo 5 minuti. Per garantire che tutte le richieste abbiano tempo sufficiente per il completamento, l'esempio di codice precedente estende il valore di timeout ad almeno 10 minuti.

Recupera l'URL di deployment per il servizio Cloud Run:

EXPORT_RUN_URL=$(gcloud run services describe dpms-export --platform
managed --region ${DPMS_PRIMARY_REGION} --format `
"value(status.address.url)")
echo ${EXPORT_RUN_URL}

Crea un secondo servizio Cloud Run nella regione in standby (regione B). Questo servizio è responsabile dell'importazione dei backup dei metadati da BACKUP_BUCKET nel metastore in standby:

gcloud run deploy dpms-import \
    --image gcr.io/${PROJECT}/dpms_dr \
    --region ${DPMS_STANDBY_REGION} \
    --platform managed \
    --update-env-vars DPMS_STANDBY_REGION=${DPMS_STANDBY_REGION},BACKUP_BUCKET=${BACKUP_BUCKET},DPMS_STANDBY_INSTANCE=${DPMS_STANDBY_INSTANCE} \
    --allow-unauthenticated \
    --timeout=10m

Recupera l'URL di deployment per il secondo servizio Cloud Run:

  IMPORT_RUN_URL=$(gcloud run services describe dpms-import --platform
  managed --region ${REGION_B} --format "value(status.address.url)")
  echo ${IMPORT_RUN_URL}

Pianificazione dei job

Questa sezione mostra come utilizzare Cloud Scheduler per attivare i due servizi Cloud Run.

In Cloud Shell, crea un'applicazione App Engine, che Cloud Scheduler richiede:
```
gcloud app create --region=${REGION_A}
```

Crea un job Cloud Scheduler per pianificare le esportazioni dei metadati dal metastore principale:

gcloud scheduler jobs create http dpms-export \
    --schedule "*/15 * * * *" \
    --http-method=post \
    --uri=${EXPORT_RUN_URL}/export\

Il job Cloud Scheduler invia una richiesta http al servizio Cloud Run ogni 15 minuti. Il servizio Cloud Run esegue un'applicazione containerizzata Flask con una funzione di esportazione e una di importazione. Quando viene attivata, la funzione di esportazione esporta i metadati in Cloud Storage utilizzando il comando gcloud metastore services export.

In generale, se i tuoi job Hadoop scrivono spesso su Hive Metastore, ti consigliamo di eseguire spesso il backup del metastore. Una buona pianificazione del backup è compresa tra 15 e 60 minuti.

Attiva un'esecuzione di prova del servizio Cloud Run:
```
gcloud scheduler jobs run dpms-export
```
Verifica che Cloud Scheduler abbia attivato correttamente l'operazione di esportazione DPMS:
```
gcloud metastore operations list --location ${REGION_A}
```
L'output è simile al seguente:
```
OPERATION_NAME                                           LOCATION     TYPE             TARGET                             DONE  CREATE_TIME          DURATION
 ...
operation-a520936204508-5v23bx4y23f60-920f0a0f-9c2b56b5  us-central1  update  dpms1                       True  2021-05-13T20:05:04  2M23S
```
Se il valore di DONE è False, l'esportazione è ancora in corso. Per confermare che l'operazione è stata completata, esegui nuovamente il comando gcloud metastore operations list --location ${REGION_A} finché il valore non diventa True.

Scopri di più sui comandi gcloud metastore operations nella documentazione di riferimento.

(Facoltativo) Crea un job Cloud Scheduler per pianificare le importazioni nel metastore in standby:

gcloud scheduler jobs create http dpms-import \
    --schedule "*/15 * * * *" \
    --http-method=post \
    --uri=${IMPORT_RUN_URL}/import

Questo passaggio dipende dai requisiti del Recovery Time Objective (RTO).

Se vuoi utilizzare un hot standby per ridurre al minimo il tempo di failover, devi pianificare questo job di importazione. Aggiorna il DPMS in standby ogni 15 minuti.

Se un cold standby è sufficiente per le tue esigenze RTO, puoi saltare questo passaggio ed eliminare anche il DPMS in standby e il cluster Dataproc per ridurre ulteriormente i costi mensili complessivi. Durante il failover nella regione di standby (regione B), esegui il provisioning del DPMS in standby e del cluster Dataproc ed esegui anche un job di importazione. Poiché i file di backup sono archiviati in un bucket a due regioni, sono accessibili anche se la regione principale (regione A) non è disponibile.

Failover di gestione

Una volta eseguito il failover nella regione B, devi seguire questi passaggi per preservare i requisiti per il ripristino di emergenza e proteggere la tua infrastruttura da potenziali errori nella regione B:

Metti in pausa i job Cloud Scheduler esistenti.
Aggiorna la regione DPMS dell'istanza principale alla regione B (us-east1).
Aggiorna la regione DPMS dello standby alla regione A (us-central1).
Aggiorna l'istanza principale DPMS a dpms2.
Aggiorna l'istanza in standby DPMS a dpms1.
Esegui di nuovo il deployment dei servizi Cloud Run in base alle variabili aggiornate.
Creare nuovi job Cloud Scheduler che puntano ai nuovi servizi Cloud Run.

I passaggi richiesti nell'elenco precedente ripetono molti passaggi delle sezioni precedenti, solo con piccole modifiche (come la sostituzione dei nomi delle regioni). Utilizza le informazioni contenute nell'opzione 1: Cloud Run e Cloud Scheduler per completare il lavoro richiesto.

Opzione 2: Cloud Composer

Questa sezione mostra come utilizzare Cloud Composer per eseguire i job di esportazione e importazione all'interno di un singolo grafo diretto aciclico (DAG) di Airflow.

In Cloud Shell, abilita l'API Cloud Composer:

gcloud services enable composer.googleapis.com

Crea un ambiente Cloud Composer:
```
export COMPOSER_ENV=comp-env
gcloud beta composer environments create ${COMPOSER_ENV} \
    --location ${DPMS_PRIMARY_REGION} \
    --image-version composer-1.17.0-preview.1-airflow-2.0.1 \
    --python-version 3
```
- L'immagine del compositore composer-1.17.0-preview.1-airflow-2.0.1 è la versione più recente alla pubblicazione.
- Gli ambienti Composer possono utilizzare solo una versione principale di Python. Python 3 è stato selezionato perché Python 2 ha problemi di supportabilità.

Configura il tuo ambiente Cloud Composer con queste variabili di ambiente:

gcloud composer environments update ${COMPOSER_ENV} \
    --location ${DPMS_PRIMARY_REGION} \
    --update-env-variables=DPMS_PRIMARY_REGION=${DPMS_PRIMARY_REGION},DPMS_STANDBY_REGION=${DPMS_STANDBY_REGION},BACKUP_BUCKET=${BACKUP_BUCKET},DPMS_PRIMARY_INSTANCE=${DPMS_PRIMARY_INSTANCE},DPMS_STANDBY_INSTANCE=${DPMS_STANDBY_INSTANCE}

Carica il file DAG nel tuo ambiente Composer:

gcloud composer environments storage dags import \
    --environment ${COMPOSER_ENV} \
    --location ${DPMS_PRIMARY_REGION} \
    --source dpms_dag.py

Recupera l'URL Airflow:

gcloud composer environments describe ${COMPOSER_ENV} \
    --location ${DPMS_PRIMARY_REGION} \
    --format "value(config.airflowUri)"

Nel browser, apri l'URL restituito dal comando precedente.

Dovresti vedere una nuova voce DAG chiamata dpms_dag. In una singola esecuzione, il DAG esegue un'esportazione, seguita da un'importazione. Il DAG presuppone che il DPMS in standby sia sempre attivo. Se non hai bisogno di un hot standby e vuoi solo eseguire l'attività di esportazione, devi commentare tutte le attività relative all'importazione nel codice (find_backup, wait_for_ready_status, current_ts, dpms_import).
Fai clic sull'icona Freccia per attivare il DAG in modo che esegua un'esecuzione di test:
Fai clic su Vista grafico del DAG in esecuzione per controllare lo stato di ogni attività:

Dopo aver convalidato il DAG, consenti ad Airflow di eseguirlo secondo una pianificazione regolare. La pianificazione è impostata su un intervallo di 30 minuti, ma può essere regolata modificando il parametro schedule_interval nel codice per soddisfare i requisiti di tempo.

Gestire i failover

Aggiorna la regione DPMS dell'istanza principale alla regione B (us-east1).
Aggiorna la regione DPMS dello standby alla regione A (us-central1).
Aggiorna l'istanza principale DPMS a dpms2.
Aggiorna l'istanza in standby DPMS a dpms1.
Crea un nuovo ambiente Cloud Composer nella regione B (us-east1).
Configurare l'ambiente Cloud Composer con le variabili di ambiente aggiornate.
Importa lo stesso DAG Airflow dpms_dag di prima nel tuo nuovo ambiente Cloud Composer.

I passaggi richiesti nell'elenco precedente ripetono molti passaggi delle sezioni precedenti, solo con piccole modifiche (come la sostituzione dei nomi delle regioni). Utilizza le informazioni nell'Opzione 2: Cloud Composer per completare il lavoro richiesto.

Esegui la pulizia

Per evitare che al tuo Account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività in questo documento, quando lo elimini elimini anche qualsiasi altro lavoro svolto nel progetto.
Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

Nella console Google Cloud, vai alla pagina Gestisci risorse.
Vai a Gestisci risorse
Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Passaggi successivi

Scopri come monitorare la tua istanza di Dataproc Metastore
Scopri come sincronizzare il metastore Hive con Data Catalog
Scopri di più sullo sviluppo dei servizi Cloud Run
Per altre architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.