Skip to main content
NetApp public and hybrid cloud solutions
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Proteção de dados para aplicativos de contêiner na plataforma de contêiner OpenShift usando Trident Protect

Colaboradores kevin-hoke
PDFs

Esta seção do documento de referência fornece detalhes para criar instantâneos e backups de aplicativos de contêiner usando o Trident Protect. O NetApp Trident Protect fornece recursos avançados de gerenciamento de dados de aplicativos que aprimoram a funcionalidade e a disponibilidade de aplicativos Kubernetes com estado, apoiados pelos sistemas de armazenamento NetApp ONTAP e pelo provisionador de armazenamento NetApp Trident CSI. O Trident Protect cria snapshots e backups de aplicativos, o que significa que não apenas snapshots e backups de dados de aplicativos em volumes persistentes são criados, mas também snapshots e backups de metadados de aplicativos. Os snapshots e backups criados pelo Trident Protect podem ser armazenados em qualquer um dos seguintes Object Storages e restaurados a partir deles posteriormente.

  • AWS S3

  • Armazenamento de Blobs do Azure

  • Armazenamento em nuvem do Google

  • Ontap S3

  • StorageGrid

  • qualquer outro armazenamento compatível com S3

O Trident Protect usa o modelo Kubernetes de controle de acesso baseado em funções (RBAC). Por padrão, o Trident Protect fornece um único namespace de sistema chamado trident-protect e sua conta de serviço padrão associada. Se você tem uma organização com muitos usuários ou necessidades específicas de segurança, pode usar os recursos RBAC do Trident Protect para obter controle mais granular sobre o acesso a recursos e namespaces.

Informações adicionais sobre RBAC no Trident Protect podem ser encontradas em"Documentação de proteção do Trident"

Observação O administrador do cluster tem acesso aos recursos no namespace padrão trident-protect e também pode acessar recursos em todos os outros namespaces. Os usuários não podem criar recursos personalizados (CRs) de gerenciamento de dados de aplicativos, como CRs de instantâneo e backup, no namespace trident-protect. Como prática recomendada, os usuários precisarão criar essas CRs no namespace do aplicativo.

O Trident Protect pode ser instalado usando as instruções fornecidas na documentação"aqui" Esta seção mostrará o fluxo de trabalho para proteção de dados de aplicativos de contêiner e restauração dos aplicativos usando o Trident Protect. 1. Criação de snapshot (sob demanda e agendamento) 2. Restaurar do Snapshot (restaurar para o mesmo namespace e para um diferente) 3. Criação de backup 4. Restaurar do backup

Pré-requisito

Antes de criar os snapshots e backups para um aplicativo, um Object Storage deve ser configurado no Trident Protect para armazenar os snapshots e backups. Isso é feito usando o bucket CR. Somente administradores podem criar um CR de bucket e configurá-lo. O bucket CR é conhecido como AppVault no Trident Protect. Os objetos do AppVault são a representação declarativa do fluxo de trabalho do Kubernetes de um bucket de armazenamento. Um AppVault CR contém as configurações necessárias para que um bucket seja usado em operações de proteção, como backups, snapshots, operações de restauração e replicação do SnapMirror .

Neste exemplo, mostraremos o uso do ONTAP S3 como armazenamento de objetos. Aqui está o fluxo de trabalho para criar o AppVault CR para o ONTAP S3: 1. Crie um servidor de armazenamento de objetos S3 no SVM no cluster ONTAP . 2. Crie um bucket no Object Store Server. 3. Crie um usuário S3 no SVM. Mantenha a chave de acesso e a chave secreta em um local seguro. 4. No OpenShift, crie um segredo para armazenar as credenciais do ONTAP S3. 5. Crie um objeto AppVault para o ONTAP S3

Configurar o Trident Protect AppVault para ONTAP S3

Arquivo yaml de exemplo para configurar o Trident Protect com o ONTAP S3 como AppVault

# alias tp='tridentctl-protect'

appvault-secret.yaml

apiVersion: v1
stringData:
  accessKeyID: "<access key id created for a user to access ONTAP S3 bucket>"
  secretAccessKey: "corresponding Secret Access Key"
#data:
# base 64 encoded values
#  accessKeyID: <base64 access key id created for a user to access ONTAP S3 bucket>
#  secretAccessKey: <base 64  Secret Access Key>
kind: Secret
metadata:
  name: appvault-secret
  namespace: trident-protect
type: Opaque

appvault.yaml

apiVersion: protect.trident.netapp.io/v1
kind: AppVault
metadata:
  name: ontap-s3-appvault
  namespace: trident-protect
spec:
  providerConfig:
    azure:
      accountName: ""
      bucketName: ""
      endpoint: ""
    gcp:
      bucketName: ""
      projectID: ""
    s3:
      bucketName: <bucket-name for storing the snapshots and backups>
      endpoint: <endpoint IP for S3>
      secure: "false"
      skipCertValidation: "true"
  providerCredentials:
    accessKeyID:
      valueFromSecret:
        key: accessKeyID
        name: appvault-secret
    secretAccessKey:
      valueFromSecret:
        key: secretAccessKey
        name: appvault-secret
  providerType: OntapS3

# oc create -f appvault-secret.yaml -n trident-protect
# oc create -f appvault.yaml -n trident-protect

AppVault criado

Arquivo yaml de exemplo para instalar o aplicativo postgresql

postgres.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:14
        env:
        - name: POSTGRES_USER
          #value: "myuser"
          value: "admin"
        - name: POSTGRES_PASSWORD
          #value: "mypassword"
          value: "adminpass"
        - name: POSTGRES_DB
          value: "mydb"
        - name: PGDATA
          value: "/var/lib/postgresql/data/pgdata"
        ports:
        - containerPort: 5432
        volumeMounts:
        - name: postgres-storage
          mountPath: /var/lib/postgresql/data
      volumes:
      - name: postgres-storage
        persistentVolumeClaim:
          claimName: postgres-pvc
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: v1
kind: Service
metadata:
  name: postgres
spec:
  selector:
    app: postgres
  ports:
  - protocol: TCP
    port: 5432
    targetPort: 5432
  type: ClusterIP

Now create the Trident protect application CR for the postgres app. Include the objects in the namespace postgres and create it in the postgres namespace.
# tp create app postgres-app --namespaces postgres -n postgres

Aplicativo criado

Criar instantâneos

Criando um snapshot sob demanda

# tp create snapshot postgres-snap1 --app postgres-app --appvault ontap-s3-appvault -n postgres
Snapshot "postgres-snap1" created.

Snapshot criado

snapshot-pvc criado

Criando um agendamento Usando o comando a seguir, os snapshots serão criados diariamente às 15:33 e dois snapshots e backups serão mantidos.

# tp create schedule schedule1 --app postgres-app --appvault ontap-s3-appvault --backup-retention 2 --snapshot-retention 2 --granularity Daily --hour 15 --minute 33 --data-mover Restic -n postgres
Schedule "schedule1" created.

Anexo 1 criado

Criando uma programação usando yaml

# tp create schedule schedule2 --app postgres-app --appvault ontap-s3-appvault --backup-retention 2 --snapshot-retention 2 --granularity Daily --hour 15 --minute 33 --data-mover Restic -n postgres --dry-run > hourly-snapshotschedule.yaml

cat hourly-snapshotschedule.yaml

apiVersion: protect.trident.netapp.io/v1
kind: Schedule
metadata:
  creationTimestamp: null
  name: schedule2
  namespace: postgres
spec:
  appVaultRef: ontap-s3-appvault
  applicationRef: postgres-app
  backupRetention: "2"
  dataMover: Restic
  dayOfMonth: ""
  dayOfWeek: ""
  enabled: true
  granularity: Hourly
  #hour: "15"
  minute: "33"
  recurrenceRule: ""
  snapshotRetention: "2"
status: {}

Schedule2 criado

Você pode ver instantâneos criados nesta programação.

Snap criado conforme programado

Snapshots de volume também são criados.

PVC Snap criado conforme o cronograma

Excluir o aplicativo para simular a perda do aplicativo 
# oc delete deployment/postgres -n postgres
# oc get pod,pvc -n postgres
No resources found in postgres namespace.
Restaurar do Snapshot para o mesmo namespace 
# tp create sir postgres-sir --snapshot postgres/hourly-3f1ee-20250214183300 -n postgres
SnapshotInplaceRestore "postgres-sir" created.

Senhor criou

O aplicativo e seus PVCis são restaurados para o mesmo namespace.

Aplicativo restaurado, senhor

Restaurar do Snapshot para um namespace diferente 
# tp create snapshotrestore postgres-restore --snapshot postgres/hourly-3f1ee-20250214183300 --namespace-mapping postgres:postgres-restore -n postgres-restore
SnapshotRestore "postgres-restore" created.

snapRestore criado

Você pode ver que o aplicativo foi restaurado para um novo namespace.

Aplicativo restaurado, snapRestore

Criar backups

Criando um backup sob demanda

# tp create backup postgres-backup1 --app postgres-app --appvault ontap-s3-appvault -n postgres
Backup "postgres-backup1" created.

Backup criado

Criando agendamento para backup

Os backups diários e horários na lista acima são criados a partir da programação configurada anteriormente.

# tp create schedule schedule1 --app postgres-app --appvault ontap-s3-appvault --backup-retention 2 --snapshot-retention 2 --granularity Daily --hour 15 --minute 33 --data-mover Restic -n postgres
Schedule "schedule1" created.

Cronograma criado anteriormente

Restaurar do backup

Exclua o aplicativo e os PVCs para simular uma perda de dados.

Cronograma criado anteriormente

Restaurar para o mesmo namespace #tp create bir postgres-bir --backup postgres/hourly-3f1ee-20250224023300 -n postgres BackupInplaceRestore "postgres-bir" criado.

restaurar para o mesmo namespace

O aplicativo e os PVCs são restaurados no mesmo namespace.

aplicação e restauração de pvcs para o mesmo namespace

Restaurar para um namespace diferente Criar um novo namespace. Restaurar de um backup para o novo namespace.

restaurar para um namespace diferente

Migrar aplicativos

Para clonar ou migrar um aplicativo para um cluster diferente (executar uma clonagem entre clusters), crie um backup no cluster de origem e restaure o backup em um cluster diferente. Certifique-se de que o Trident Protect esteja instalado no cluster de destino.

No cluster de origem, execute as etapas conforme mostrado na imagem abaixo:

restaurar para um namespace diferente

Do cluster de origem, alterne o contexto para o cluster de destino. Em seguida, certifique-se de que o AppVault esteja acessível a partir do contexto do cluster de destino e obtenha o conteúdo do AppVault do cluster de destino.

mudar o contexto para o destino

Use o caminho de backup da lista e crie um objeto CR de backuprestore, conforme mostrado no comando abaixo.

# tp create backuprestore backup-restore-cluster2 --namespace-mapping postgres:postgres --appvault ontap-s3-appvault --path postgres-app_4d798ed5-cfa8-49ff-a5b6-c5e2d89aeb89/backups/postgres-backup-cluster1_ec0ed3f3-5500-4e72-afa8-117a04a0b1c3 -n postgres
BackupRestore "backup-restore-cluster2" created.

restaurar para o destino

Agora você pode ver que os pods do aplicativo e os pvcs são criados no cluster de destino.

aplicativo no cluster de destino