Trasferimento dei dati

I trasferimenti di dati possono avvenire tra:

  1. PersistentVolumeClaim (PVC) e archiviazione di oggetti
  2. Archiviazione di oggetti e archiviazione di oggetti (all'interno di GDC)

L'archiviazione di oggetti su GDC è compatibile con S3 e viene definita di tipo s3 nei file YAML di Kubernetes.

Tipi di origini/destinazioni dati

  1. Archiviazione di oggetti (denominata "s3"): archiviazione di oggetti presente su GDC
  2. Archiviazione locale (denominata "local"): archiviazione su PVC collegati

Copia dall'archiviazione di oggetti all'archiviazione di oggetti

Assicurati di soddisfare i seguenti prerequisiti:

  • Un endpoint S3 con autorizzazioni di lettura per l'origine e un endpoint s3 con autorizzazioni di scrittura per la destinazione.
  • Se non hai l'autorizzazione per la creazione di bucket con le credenziali, il trasferimento non riesce se il bucket di destinazione non esiste. In questo caso, assicurati che il bucket di destinazione esista.
  • Privilegi per creare job e creare o leggere i secret all'interno del cluster o dello spazio dei nomi. Consulta l'esempio seguente per le autorizzazioni.

Crea un job

Per creare un job, segui questi passaggi:

  1. Crea uno spazio dei nomi:

    apiVersion: v1
    kind: Namespace
    metadata:
      name: transfer-ns
    
  2. Crea le credenziali:

    ---
    
    apiVersion: v1
    kind: Secret
    metadata:
      name: src-secret
      namespace: transfer-ns
    data:
      access-key-id: NkFDTUg3WDBCVDlQMVpZMU5MWjU= # base 64 encoded version of key
      access-key: VkRkeWJsbFgzb2FZanMvOVpnSi83SU5YUjk3Y0Q2TUdxZ2d4Q3dpdw== # base 64 encoded version of secret key
    ---
    apiVersion: v1
    kind: Secret
    metadata:
      name: dst-secret
      namespace: transfer-ns
    data:
      access-key-id: NkFDTUg3WDBCVDlQMVpZMU5MWjU= # base 64 encoded version of key
      access-key: VkRkeWJsbFgzb2FZanMvOVpnSi83SU5YUjk3Y0Q2TUdxZ2d4Q3dpdw== # base 64 encoded version of secret key
    ---
    

    Queste credenziali sono le stesse che hai ottenuto nella sezione relativa all'archiviazione di oggetti.

  3. Crea un account di servizio (SA) utilizzato dal trasferimento, quindi aggiungi le autorizzazioni all'account per leggere e scrivere i secret utilizzando ruoli e associazioni di ruoli. Non devi aggiungere autorizzazioni se il SA dello spazio dei nomi predefinito o il SA personalizzato le hanno già.

    ---
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: transfer-service-account
      namespace: transfer-ns
    ---
    
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: read-secrets-role
      namespace: transfer-ns
    rules:
    - apiGroups: [""]
      resources: ["secrets"]
      verbs: ["get", "watch", "list"]
    
    ---
    
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: read-secrets-rolebinding
      namespace: transfer-ns
    subjects:
    - kind: ServiceAccount
      name: transfer-service-account
      namespace: transfer-ns
    roleRef:
      kind: Role
      name: read-secrets-role
      apiGroup: rbac.authorization.k8s.io
    
    ---
    
  4. Ottieni i certificati CA per i sistemi di archiviazione di oggetti. Puoi ottenere gli stessi certificati dal tuo AO/PA.

    ---
    
    apiVersion: v1
    kind: Secret
    metadata:
      name: src-cert
      namespace: transfer-ns
    data:
      ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURBekNDQWV1Z0F3SUJBZ0lSQUpHM2psOFZhTU85a1FteGdXUFl3N3d3RFFZSktvWklodmNOQVFFTEJRQXcKR3pFWk1CY0dBMVVFQXhNUVltOXZkSE4wY21Gd0xYZGxZaTFqWVRBZUZ3MHlNekF5TVRVd01USXlNakZhRncweQpNekExTVRZd01USXlNakZhTUJzeEdUQVhCZ05WQkFNVEVHSnZiM1J6ZEhKaGNDMTNaV0l0WTJFd2dnRWlNQTBHCkNTcUdTSWI== # base 64 encoded version of certificate
    
    ---
    
    apiVersion: v1
    kind: Secret
    metadata:
      name: dst-cert
      namespace: transfer-ns
    data:
      ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURBekNDQWV1Z0F3SUJBZ0lSQUtoaEJXWWo3VGZlUUZWUWo0U0RpckV3RFFZSktvWklodmNOQVFFTEJRQXcKR3pFWk1CY0dBMVVFQXhNUVltOXZkSE4wY21Gd0xYZGxZaTFqWVRBZUZ3MHlNekF6TURZeU16TTROVEJhRncweQpNekEyTURReU16TTROVEJhTUJzeEdUQVhCZ05WQkFNVEVHSnZiM1J6ZEhKaGNDMTNaV0l0WTJFd2dnRWlNQTBHCkNTcUdTSWIzRFFF== # base 64 encoded version of certificate. Can be same OR different than source certificate.
    
    ---
    
    
  5. (Facoltativo) Crea un LoggingTarget per visualizzare i log del servizio di trasferimento in Loki.

    apiVersion: logging.gdc.goog/v1
    kind: LoggingTarget
    metadata:
      namespace: transfer-ns # Same namespace as your transfer job
      name: logtarg1
    spec:
      # Choose matching pattern that identifies pods for this job
      # Optional
      # Relationship between different selectors: AND
      selector:
    
        # Choose pod name prefix(es) to consider for this job
        # Observability platform will scrape all pods
        # where names start with specified prefix(es)
        # Should contain [a-z0-9-] characters only
        # Relationship between different list elements: OR
        matchPodNames:
          - transfer-job # Choose the prefix here that matches your transfer job name
      serviceName: transfer-service
    
  6. Crea il job:

    ---
    
    apiVersion: batch/v1
    kind: Job
    metadata:
      name: transfer-job
      namespace: transfer-ns
    spec:
      template:
        spec:
          serviceAccountName: transfer-service-account #service account created earlier
          containers:
            - name: storage-transfer-pod #
              image: gcr.io/private-cloud-staging/storage-transfer:latest
              imagePullPolicy: Always #will always pull the latest image
              command:
                - /storage-transfer
              args:
                - '--src_endpoint=objectstorage.zone1.google.gdch.test' #Your endpoint here
                - '--dst_endpoint=objectstorage.zone1.google.gdch.test' #Your endpoint here
                - '--src_path=aecvd-bucket1' #Please use Fully Qualified Name
                - '--dst_path=aklow-bucket2' #Please use Fully Qualified Name
                - '--src_credentials=transfer-ns/src-secret' #Created earlier
                - '--dst_credentials=transfer-ns/dst-secret' #Created earlier
                - '--dst_ca_certificate_reference=transfer-ns/dst-cert' #Created earlier
                - '--src_ca_certificate_reference=transfer-ns/src-cert' #Created earlier
                - '--src_type=s3'
                - '--dst_type=s3'
                - '--bandwidth_limit=10M' #Optional of the form '10K', '100M', '1G' bytes per second
          restartPolicy: OnFailure #Will restart on failure.
    ---
    

Monitora il trasferimento dei dati

Dopo aver creato un'istanza del job, puoi monitorarne lo stato utilizzando kubectl comandi, ad esempio kubectl describe. Per verificare il trasferimento, elenca gli oggetti all'interno del bucket di destinazione per convalidare il trasferimento dei dati. Lo strumento di trasferimento dei dati è indipendente dalla località degli endpoint coinvolti nel trasferimento.

Esegui questo comando:

kubectl describe transfer-job -n transfer-ns

Il comando precedente indica lo stato del job.

Il job richiede a un pod di trasferire i dati. Puoi recuperare il nome del pod e consultare i log per verificare la presenza di errori durante il trasferimento.

Per visualizzare i log dei pod, esegui questo comando:

kubectl logs transfer-job-<pod_id_suffix_obtained_from_describe_operation_on_job> -n transfer-ns

Log dei job riusciti:

DEBUG : Starting main for transfer
I0607 21:34:39.183106       1 transfer.go:103]  "msg"="Starting transfer "  "destination"="sample-bucket" "source"="/data"
2023/06/07 21:34:39 NOTICE: Bandwidth limit set to {100Mi 100Mi}
I0607 21:34:49.238901       1 transfer.go:305]  "msg"="Job finished polling "  "Finished"=true "Number of Attempts"=2 "Success"=true
I0607 21:34:49.239675       1 transfer.go:153]  "msg"="Transfer completed."  "AvgSpeed"="10 KB/s" "Bytes Moved"="10.0 kB" "Errors"=0 "Files Moved"=10 "FilesComparedAtSourceAndDest"=3 "Time since beginning of transfer"="1.0s"

La visualizzazione dei log consente di vedere la velocità di trasferimento dei dati, che non è la stessa della larghezza di banda utilizzata, dei byte spostati, del numero di file con errori e dei file spostati.

Copia l'archiviazione a blocchi nell'archiviazione di oggetti

Assicurati di soddisfare i seguenti prerequisiti:

  • Un endpoint S3 con un ID chiave S3 e una chiave di accesso secret con almeno le autorizzazioni di SCRITTURA per il bucket dedicato in cui vuoi trasferire i dati.
  • Un cluster funzionante con connettività all'endpoint S3.
  • Privilegi per creare job e secret all'interno del cluster.
  • Per la replica dell'archiviazione a blocchi, un pod con un PersistentVolumeClaim (PVC) collegato di cui vuoi eseguire il backup nell'archiviazione di oggetti e privilegi per controllare i job e i PVC in esecuzione.
  • Per la replica dell'archiviazione a blocchi, una finestra durante la quale non vengono eseguite scritture nel PersistentVolume (PV).
  • Per il ripristino dell'archiviazione a blocchi da un endpoint di archiviazione di oggetti, privilegi per allocare un PV con capacità sufficiente.

Per replicare un PV nell'archiviazione di oggetti, devi collegare un volume a un pod esistente. Durante la finestra di trasferimento, il pod non deve eseguire alcuna scrittura. Per evitare di scollegare il PV montato dal job, il processo di trasferimento dei dati funziona eseguendo il job di trasferimento sulla stessa macchina del pod e utilizzando un montaggio hostPath per esporre il volume sul disco. In preparazione al trasferimento, devi prima trovare il nodo su cui è in esecuzione il pod e metadati aggiuntivi come l'UID del pod e il tipo di PVC per fare riferimento al percorso appropriato sul nodo. Devi sostituire questi metadati nel file YAML di esempio descritto nella sezione seguente.

Raccogli i metadati

Per raccogliere i metadati necessari per creare il job di trasferimento dei dati, segui questi passaggi:

  1. Trova il nodo con il pod pianificato:

    kubectl get pod POD_NAME -o jsonpath='{.spec.nodeName}'
    

    Registra l'output di questo comando come NODE_NAME da utilizzare nel file YAML del job di trasferimento dei dati.

  2. Trova l'UID del pod:

    kubectl get pod POD_NAME -o 'jsonpath={.metadata.uid}'
    

    Registra l'output di questo comando come POD_UID da utilizzare nel file YAML del job di trasferimento dei dati.

  3. Trova il nome del PVC:

    kubectl get pvc www-web-0 -o 'jsonpath={.spec.volumeName}'
    

    Registra l'output di questo comando come PVC_NAME da utilizzare nel file YAML del job di trasferimento dei dati.

  4. Trova il provisioner di archiviazione del PVC:

    kubectl get pvc www-web-0 -o jsonpath='{.metadata.annotations.volume\.v1\.kubernetes\.io\/storage-provisioner}'
    

    Registra l'output di questo comando come il PROVISIONER_TYPE da utilizzare nel file YAML del job di trasferimento dei dati.

Crea i secret

Per replicare i file nell'archiviazione di oggetti tra i cluster, devi prima creare un'istanza dei secret all'interno del cluster Kubernetes. Per consentire allo strumento di recuperare le credenziali, devi utilizzare chiavi corrispondenti per i dati dei secret.

Per eseguire il trasferimento in uno spazio dei nomi esistente, consulta l'esempio seguente di creazione di secret in uno spazio dei nomi transfer:

apiVersion: v1
kind: Secret
metadata:
  name: src-secret
  namespace: transfer
data:
  access-key-id: c3JjLWtleQ== # echo -n src-key| base64 -w0
  access-key: c3JjLXNlY3JldA== # echo -n src-secret| base64 -w0
---
apiVersion: v1
kind: Secret
metadata:
  name: dst-secret
  namespace: transfer
data:
  access-key-id: ZHN0LWtleQ== # echo -n dst-key| base64 -w0
  access-key: ZHN0LXNlY3JldA== # echo -n dst-secret| base64 -w0

Crea il job

Con i dati raccolti nella sezione precedente, crea un job con lo strumento di trasferimento dei dati. Il job di trasferimento dei dati ha un montaggio hostPath che fa riferimento al percorso del PV di interesse e un nodeSelector per il nodo pertinente.

Di seguito è riportato un esempio di job di trasferimento dei dati:

apiVersion: batch/v1
kind: Job
metadata:
  name: transfer-job
  namespace: transfer
spec:
  template:
    spec:
      nodeSelector: NODE_NAME
      serviceAccountName: data-transfer-sa
      containers:
      - name: storage-transfer-pod
        image: storage-transfer
        command:
        - /storage-transfer
        args:
        - --dst_endpoint=https://your-dst-endpoint.com
        - --src_path=/pvc-data
        - --dst_path=transfer-dst-bucket
        - --dst_credentials=transfer/dst-secret
        - --src_type=local
        - --dst_type=s3
      volumeMounts:
      - mountPath: /pvc-data
        name: pvc-volume
      volumes:
      - name: pvc-volume
      hostPath:
        path: /var/lib/kubelet/pods/POD_UID/volumes/PROVISIONER_TYPE/PVC_NAME
      restartPolicy: Never

Come per il trasferimento dei dati S3, devi creare un secret contenente le chiavi di accesso per l'endpoint di destinazione nel cluster Kubernetes e il job di trasferimento dei dati deve essere eseguito con un account di servizio con privilegi sufficienti per leggere il secret dal server API. Monitora lo stato del trasferimento con i comandi kubectl standard che operano sul job.

Quando trasferisci l'archiviazione a blocchi nell'archiviazione di oggetti, tieni presente i seguenti dettagli:

  • Per impostazione predefinita, i link simbolici vengono seguiti e replicati nell'archiviazione di oggetti, ma viene eseguita una copia approfondita anziché superficiale. Al momento del ripristino, i link simbolici vengono eliminati.
  • Come per la replica dell'archiviazione di oggetti, la clonazione in una sottodirectory del bucket è distruttiva. Assicurati che il bucket sia disponibile esclusivamente per il tuo volume.

Ripristina dall'archiviazione di oggetti all'archiviazione a blocchi

Alloca un PV

Per ripristinare l'archiviazione a blocchi da un endpoint di archiviazione di oggetti:

  1. Alloca un volume permanente come destinazione del ripristino. Utilizza un PVC per allocare il volume, come mostrato nell'esempio seguente:

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: restore-pvc
      namespace: restore-ns
    spec:
      storageClassName: "default"
      accessModes:
    ReadWriteOnce
      resources:
        requests:
          storage: 1Gi # Need sufficient capacity for full restoration.
    
  2. Controlla lo stato del PVC:

    kubectl get pvc restore-pvc -n restore-ns
    

    Quando il PVC è nello stato Bound, è pronto per essere utilizzato all'interno del pod che lo reidrata.

  3. Se un set con stato utilizza il PV, devi abbinare i PVC del set con stato sottoposti a rendering. I pod prodotti dal set con stato utilizzano i volumi idratati. L'esempio seguente mostra i modelli di rivendicazione del volume in un set con stato denominato ss.

      volumeClaimTemplates:
      - metadata:
          name: pvc-name
        spec:
          accessModes: [ "ReadWriteOnce" ]
          storageClassName: "default"
          resources:
            requests:
              storage: 1Gi
    
  4. Prealloca i PVC con nomi come ss-pvc-name-0 e ss-pvc-name-1 per assicurarti che i pod risultanti utilizzino i volumi preallocati.

Idrata il PV

Dopo che il PVC è associato a un PV, avvia il job per popolare il PV:

apiVersion: batch/v1
kind: Job
metadata:
  name: transfer-job
  namespace: transfer
spec:
  template:
    spec:
      serviceAccountName: data-transfer-sa
      volumes:
      - name: data-transfer-restore-volume
        persistentVolumeClaim:
          claimName: restore-pvc
      containers:
      - name: storage-transfer-pod
        image: storage-transfer
        command:
        - /storage-transfer
        args:
        - --src_endpoint=https://your-src-endpoint.com
        - --src_path=/your-src-bucket
        - --src_credentials=transfer/src-secret
        - --dst_path=/restore-pv-mnt-path
        - --src_type=s3
        - --dst_type=local
      volumeMounts:
      - mountPath: /restore-pv-mnt-path
        name: data-transfer-restore-volume

Al termine dell'esecuzione del job, i dati del bucket di archiviazione di oggetti vengono inseriti nel volume. Un pod separato può utilizzare i dati utilizzando gli stessi meccanismi standard per il montaggio di un volume.