Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Esegui la migrazione dei dati MySQL da Persistent Disk a Hyperdisk in GKE

Autopilot Standard

Questo tutorial mostra come eseguire la migrazione dei dati MySQL esistenti da un Persistent Disk (DP) a Hyperdisk su Google Kubernetes Engine per migliorare le prestazioni di archiviazione. Hyperdisk offre un numero di IOPS e un throughput superiori rispetto a Persistent Disk, il che può migliorare le prestazioni di MySQL riducendo la latenza per le query e le transazioni del database. Puoi utilizzare gli snapshot del disco per eseguire la migrazione dei dati a tipi di disco diversi a seconda della compatibilità del tipo di macchina. Ad esempio, i volumi Hyperdisk sono compatibili solo con alcuni tipi di macchine di terza, quarta e generazioni successive, come N4, che non supportano i dischi permanenti. Per ulteriori informazioni, consulta le serie di macchine disponibili.

Per dimostrare la migrazione da Persistent Disk a Hyperdisk, questo tutorial utilizza il database Sakila per fornire un set di dati di esempio. Sakila è un database di esempio fornito da MySQL che puoi utilizzare come schema per tutorial ed esempi. Rappresenta un negozio di noleggio di DVD fittizio e include tabelle per film, attori, clienti e noleggi.

Questa guida è destinata agli specialisti e agli amministratori dello spazio di archiviazione che creano e allocano spazio di archiviazione e gestiscono la sicurezza e l'accesso ai dati. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli utente e attività comuni di GKE.

Architettura di deployment

Il seguente diagramma illustra il processo di migrazione da un Persistent Disk a un Hyperdisk.

Un'applicazione MySQL viene eseguita su un pool di nodi GKE con tipi di macchine N2 e archivia i dati su un Persistent Disk SSD.
Per garantire la coerenza dei dati, l'applicazione viene ridimensionata per impedire nuove scritture.
Viene creato uno snapshot del Persistent Disk, che funge da backup point-in-time completo dei dati.
Viene eseguito il provisioning di un nuovo Hyperdisk dallo snapshot e viene eseguito il deployment di una nuova istanza MySQL su un pool di nodi N4 separato e compatibile con Hyperdisk. Questa nuova istanza si collega all'Hyperdisk appena creato, completando la migrazione allo spazio di archiviazione con prestazioni più elevate.

Diagramma dell'architettura che mostra la migrazione dei dati MySQL da Persistent Disk a Hyperdisk utilizzando uno snapshot. — **Figura 1**: migrazione dei dati MySQL da Persistent Disk a Hyperdisk utilizzando uno snapshot.

Obiettivi

In questo tutorial imparerai a:

Esegui il deployment di un cluster MySQL.
Carica un set di dati di test.
Crea uno snapshot dei tuoi dati.
Crea un Hyperdisk dallo snapshot.
Avvia un nuovo cluster MySQL in un pool di nodi di tipo di macchina N4 abilitato per Hyperdisk.
Verifica l'integrità dei dati per confermare la riuscita della migrazione.

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

GKE
Compute Engine, which includes:
- Storage capacity provisioned for both Persistent Disk and Hyperdisk.
- Storage costs for the snapshots.

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi.

I nuovi utenti di Google Cloud potrebbero avere diritto a una prova senza costi.

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 senza costi 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.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Compute Engine, GKE, Identity and Access Management Service Account Credentials APIs, if any are not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the APIs

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

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Compute Engine, GKE, Identity and Access Management Service Account Credentials APIs, if any are not already enabled.

Roles required to enable APIs

Enable the APIs

Assicurati di disporre dei seguenti ruoli nel progetto: roles/container.admin, roles/iam.serviceAccountAdmin, roles/compute.admin
Controlla i ruoli
1. Nella console Google Cloud vai alla pagina IAM.
  Vai a IAM
2. Seleziona il progetto.
3. Nella colonna Entità, individua tutte le righe che identificano te o un gruppo di cui fai parte. Per scoprire in quali gruppi sei incluso, contatta il tuo amministratore.
4. Per tutte le righe che ti specificano o ti includono, controlla la colonna Ruolo per verificare se l'elenco dei ruoli include i ruoli richiesti.
Concedi i ruoli
1. Nella console Google Cloud vai alla pagina IAM.
  Vai a IAM
2. Seleziona il progetto.
3. Fai clic su Concedi l'accesso.
4. Nel campo Nuove entità, inserisci il tuo identificatore dell'utente. In genere si tratta dell'indirizzo email di un Account Google.
5. Fai clic su Seleziona un ruolo, quindi cerca il ruolo.
6. Per concedere altri ruoli, fai clic su Aggiungi un altro ruolo e aggiungi ogni ruolo successivo.
7. Fai clic su Salva.

Configura Cloud Shell

Nella console Google Cloud , attiva Cloud Shell.

Attiva Cloud Shell

Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell e viene visualizzato un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installata e con valori già impostati per il progetto corrente. L'inizializzazione della sessione può richiedere alcuni secondi.

Viene avviata una sessione di Cloud Shell e viene visualizzato un prompt della riga di comando. L'inizializzazione della sessione può richiedere alcuni secondi.

Imposta il progetto predefinito:
```
  gcloud config set project PROJECT_ID
```
Sostituisci PROJECT_ID con l'ID progetto.

Prepara l'ambiente

In Cloud Shell, imposta le variabili di ambiente per il progetto, la località e il prefisso del cluster.
```
export PROJECT_ID=PROJECT_ID
export EMAIL_ADDRESS=EMAIL_ADDRESS
export KUBERNETES_CLUSTER_PREFIX=offline-hyperdisk-migration
export LOCATION=us-central1-a
```
Sostituisci quanto segue:
- PROJECT_ID: il tuo Google Cloud ID progetto.
- EMAIL_ADDRESS: il tuo indirizzo email.
- LOCATION: la zona in cui vuoi creare le risorse di deployment. Ai fini di questo tutorial, utilizza la zona us-central1-a.

Clona il repository di codice campione da GitHub:

git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples

Vai alla directory offline-hyperdisk-migration per iniziare a creare risorse di deployment:
```
cd kubernetes-engine-samples/databases/offline-hyperdisk-migration
```

Crea il cluster GKE e i node pool

Questo tutorial utilizza un cluster a livello di zona per semplicità, perché i volumi Hyperdisk sono risorse di zona e sono accessibili solo all'interno di una singola zona.

Crea un cluster GKE di zona:

gcloud container clusters create ${KUBERNETES_CLUSTER_PREFIX}-cluster \
    --location ${LOCATION} \
    --node-locations ${LOCATION} \
    --shielded-secure-boot \
    --shielded-integrity-monitoring \
    --machine-type "e2-micro" \
    --num-nodes "1"

Aggiungi un pool di nodi con un tipo di macchina N2 per il deployment iniziale di MySQL:

gcloud container node-pools create regular-pool \
    --cluster ${KUBERNETES_CLUSTER_PREFIX}-cluster \
    --machine-type n2-standard-4 \
    --location ${LOCATION} \
    --num-nodes 1

Aggiungi un pool di nodi con un tipo di macchina N4 su Hyperdisk in cui verrà eseguita la migrazione e l'esecuzione del deployment di MySQL:

gcloud container node-pools create hyperdisk-pool \
    --cluster ${KUBERNETES_CLUSTER_PREFIX}-cluster \
    --machine-type n4-standard-4 \
    --location ${LOCATION} \
    --num-nodes 1

Connettiti al cluster:

gcloud container clusters get-credentials ${KUBERNETES_CLUSTER_PREFIX}-cluster --location ${LOCATION}

Esegui il deployment di MySQL su Persistent Disk

In questa sezione, esegui il deployment di un'istanza MySQL che utilizza un Persistent Disk per l'archiviazione e caricala con dati di esempio.

Crea e applica un StorageClass per Hyperdisk. Questo StorageClass verrà utilizzato più avanti nel tutorial.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: balanced-storage
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: hyperdisk-balanced
  provisioned-throughput-on-create: "250Mi"
  provisioned-iops-on-create: "7000"

kubectl apply -f manifests/01-storage-class/storage-class-hdb.yaml

Crea e implementa un'istanza MySQL che includa l'affinità dei nodi per garantire che i pod vengano pianificati sui nodi regular-pool e che venga eseguito il provisioning di un volume SSD Persistent Disk.

apiVersion: v1
kind: Service
metadata:
  name: regular-mysql
  labels:
    app: mysql
spec:
  ports:
    - port: 3306
  selector:
    app: mysql
  clusterIP: None
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
  labels:
    app: mysql
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi
  storageClassName: premium-rwo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: existing-mysql
  labels:
    app: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mysql:8.0
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: migration
        - name: MYSQL_DATABASE
          value: mysql
        - name: MYSQL_USER
          value: app
        - name: MYSQL_PASSWORD
          value: migration
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      affinity: 
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: "node.kubernetes.io/instance-type"
                operator: In
                values:
                - "n2-standard-4"
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim

kubectl apply -f manifests/02-mysql/mysql-deployment.yaml

Questo manifest crea un servizio e un deployment MySQL, con un Persistent Disk di cui viene eseguito il provisioning dinamico per l'archiviazione dei dati. La password per l'utente root è migration.

Esegui il deployment di un pod client MySQL per caricare i dati e verificare la migrazione dei dati:

apiVersion: v1
kind: Pod
metadata:
  name: mysql-client
spec:
  containers:
  - name: main
    image: mysql:8.0
    command: ["sleep", "360000"]
    resources:
      requests:
        memory: 1Gi
        cpu: 500m
      limits:
        memory: 1Gi
        cpu: "1"
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: migration

kubectl apply -f manifests/02-mysql/mysql-client.yaml
kubectl wait pods mysql-client --for condition=Ready --timeout=300s

Connettiti al pod client:
```
kubectl exec -it mysql-client -- bash
```

Dalla shell del pod client, scarica e importa il set di dati di esempio Sakila:

# Download the dataset
curl --output dataset.tgz "https://downloads.mysql.com/docs/sakila-db.tar.gz"

# Extract the dataset
tar -xvzf dataset.tgz -C /

# Import the dataset into MySQL (the password is "migration").
mysql -u root -h regular-mysql.default -p
    SOURCE /sakila-db/sakila-schema.sql;
    SOURCE /sakila-db/sakila-data.sql;

Verifica che i dati siano stati importati:

USE sakila;
SELECT      table_name,      table_rows  FROM      INFORMATION_SCHEMA.TABLES  WHERE TABLE_SCHEMA = 'sakila';

L'output mostra un elenco di tabelle con i conteggi delle righe.

| TABLE_NAME                 | TABLE_ROWS |
+----------------------------+------------+
| actor                      |        200 |
| actor_info                 |       NULL |
| address                    |        603 |
| category                   |         16 |
| city                       |        600 |
| country                    |        109 |
| customer                   |        599 |
| customer_list              |       NULL |
| film                       |       1000 |
| film_actor                 |       5462 |
| film_category              |       1000 |
| film_list                  |       NULL |
| film_text                  |       1000 |
| inventory                  |       4581 |
| language                   |          6 |
| nicer_but_slower_film_list |       NULL |
| payment                    |      16086 |
| rental                     |      16419 |
| sales_by_film_category     |       NULL |
| sales_by_store             |       NULL |
| staff                      |          2 |
| staff_list                 |       NULL |
| store                      |          2 |
+----------------------------+------------+
23 rows in set (0.01 sec)

Esci dalla sessione mysql:
```
exit;
```
Esci dalla shell del pod client:
```
exit
```
Recupera il nome del PersistentVolume (PV) creato per MySQL e memorizzalo in una variabile di ambiente:
```
export PV_NAME=$(kubectl get pvc mysql-pv-claim -o jsonpath='{.spec.volumeName}')
```

Esegui la migrazione dei dati a un volume Hyperdisk

Ora hai un workload MySQL con dati archiviati su un volume SSD Persistent Disk. Questa sezione descrive come eseguire la migrazione di questi dati a un volume Hyperdisk utilizzando uno snapshot. Questo approccio alla migrazione conserva anche il volume del Persistent Disk originale, il che ti consente di eseguire il rollback all'utilizzo dell'istanza MySQL originale, se necessario.

Anche se puoi creare snapshot dai dischi senza scollegarli dai workload, per garantire l'integrità dei dati per MySQL devi interrompere qualsiasi nuova scrittura sul disco durante la creazione dello snapshot. Fai lo scale down del deployment MySQL a 0 repliche per interrompere le scritture:
```
kubectl scale deployment existing-mysql --replicas=0
```

Crea uno snapshot dal Persistent Disk esistente:

gcloud compute disks snapshot ${PV_NAME} --zone=${LOCATION} --snapshot-names=original-snapshot --description="snapshot taken from pd-ssd"

Crea un nuovo volume Hyperdisk denominato mysql-recovery dallo snapshot:

gcloud compute disks create mysql-recovery --project=${PROJECT_ID} \
    --type=hyperdisk-balanced \
    --size=150GB --zone=${LOCATION} \
    --source-snapshot=projects/${PROJECT_ID}/global/snapshots/original-snapshot

Aggiorna il file manifest per il VP ripristinato con l'ID progetto:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: backup
spec:
  storageClassName: balanced-storage
  capacity:
    storage: 150G
  accessModes:
    - ReadWriteOnce
  claimRef:
    name: hyperdisk-recovery
    namespace: default
  csi:
    driver: pd.csi.storage.gke.io
    volumeHandle: projects/PRJCTID/zones/us-central1-a/disks/mysql-recovery
    fsType: ext4
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  namespace: default
  name: hyperdisk-recovery
spec:
  storageClassName: balanced-storage
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 150G

sed -i "s/PRJCTID/$PROJECT_ID/g" manifests/02-mysql/restore_pv.yaml

Crea il PersistentVolume (PVC) e il PersistentVolumeClaim dal nuovo Hyperdisk:
```
kubectl apply -f manifests/02-mysql/restore_pv.yaml
```

Verificare la migrazione dei dati

Esegui il deployment di una nuova istanza MySQL che utilizza il volume Hyperdisk appena creato. Questo pod verrà pianificato sul pool di nodi hyperdisk-pool, costituito da nodi N4.

Esegui il deployment della nuova istanza MySQL:

apiVersion: v1
kind: Service
metadata:
  name: recovered-mysql
  labels:
    app: new-mysql
spec:
  ports:
    - port: 3306
  selector:
    app: new-mysql
  clusterIP: None
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: new-mysql
  labels:
    app: new-mysql
spec:
  selector:
    matchLabels:
      app: new-mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: new-mysql
    spec:
      containers:
      - image: mysql:8.0
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: migration
        - name: MYSQL_DATABASE
          value: mysql
        - name: MYSQL_USER
          value: app
        - name: MYSQL_PASSWORD
          value: migration
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      affinity: 
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: "cloud.google.com/gke-nodepool"
                operator: In
                values:
                - "hyperdisk-pool"      
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: hyperdisk-recovery

kubectl apply -f manifests/02-mysql/recovery_mysql_deployment.yaml

Per verificare l'integrità dei dati, connettiti di nuovo al pod del client MySQL:
```
kubectl exec -it mysql-client -- bash
```
All'interno del pod client, connettiti al nuovo database MySQL (recovered-mysql.default) e verifica i dati. La password è migration.
```
mysql -u root -h recovered-mysql.default -p
USE sakila;
SELECT table_name, table_rows FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'sakila';
```
I dati devono essere gli stessi dell'istanza MySQL originale sul Persistent Disk permanente.

Operazione riuscita: hai eseguito correttamente la migrazione dei dati MySQL da un Persistent Disk a un Hyperdisk.
Esci dalla sessione mysql:
```
exit;
```
Esci dalla shell del pod client:
```
exit
```

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.

Elimina il progetto

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à descritte in questo documento, eliminerai anche tutto il lavoro che hai 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.

Elimina un progetto Google Cloud :

gcloud projects delete PROJECT_ID

Elimina singole risorse

Se hai utilizzato un progetto esistente e non vuoi eliminarlo, elimina le singole risorse:

Imposta le variabili di ambiente per la pulizia e recupera il nome del volume Persistent Disk creato da mysql-pv-claim PersistentVolumeClaim:

export PROJECT_ID=PROJECT_ID
export KUBERNETES_CLUSTER_PREFIX=offline-hyperdisk-migration
export location=us-central1-a
export PV_NAME=$(kubectl get pvc mysql-pv-claim -o jsonpath='{.spec.volumeName}')

Sostituisci PROJECT_ID con l'ID progetto.

Elimina lo snapshot:

gcloud compute snapshots delete original-snapshot --quiet

Elimina il cluster GKE:

gcloud container clusters delete ${KUBERNETES_CLUSTER_PREFIX}-cluster --location=${LOCATION} --quiet

Elimina i volumi Persistent Disk e Hyperdisk:

gcloud compute disks delete ${PV_NAME} --zone=${LOCATION} --quiet
gcloud compute disks delete mysql-recovery --zone=${LOCATION} --quiet

Passaggi successivi

Esamina altri esempi di codice nel repository GitHub di esempi di GKE.
Scopri come scalare le prestazioni di archiviazione con i volumi Hyperdisk.
Scopri di più sull'utilizzo del driver CSI per il disco permanente di Compute Engine per la gestione dei volumi Persistent Disk e Hyperdisk.
Esplora architetture, diagrammi e best practice di riferimento su Google Cloud. Consulta il nostro Cloud Architecture Center.

Esegui la migrazione dei dati MySQL da Persistent Disk a Hyperdisk in GKE Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Architettura di deployment

Obiettivi

Costi

Prima di iniziare

Controlla i ruoli

Concedi i ruoli

Configura Cloud Shell

Prepara l'ambiente

Crea il cluster GKE e i node pool

Esegui il deployment di MySQL su Persistent Disk

Esegui la migrazione dei dati a un volume Hyperdisk

Verificare la migrazione dei dati

Esegui la pulizia

Elimina il progetto

Elimina singole risorse

Passaggi successivi

Esegui la migrazione dei dati MySQL da Persistent Disk a Hyperdisk in GKE