Skip to main content
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.

Replique aplicações usando o NetApp SnapMirror e o Trident Protect

Colaboradores netapp-aruldeepa
PDFs

Com o Trident Protect, você pode usar os recursos de replicação assíncrona da tecnologia NetApp SnapMirror para replicar alterações de dados e aplicações de um back-end de storage para outro, no mesmo cluster ou entre clusters diferentes.

Anotações e rótulos de namespace durante operações de restauração e failover

Durante as operações de restauração e failover, rótulos e anotações no namespace de destino são feitos para corresponder aos rótulos e anotações no namespace de origem. Rótulos ou anotações do namespace de origem que não existem no namespace de destino são adicionados, e quaisquer rótulos ou anotações que já existem são sobrescritos para corresponder ao valor do namespace de origem. Rótulos ou anotações que existem apenas no namespace de destino permanecem inalterados.

Observação Se você usar o Red Hat OpenShift, é importante observar o papel crítico das anotações de namespace em ambientes OpenShift. As anotações de namespace garantem que os pods restaurados aderem às permissões apropriadas e às configurações de segurança definidas pelas restrições de contexto de segurança OpenShift (SCCs) e possam acessar volumes sem problemas de permissão. Para obter mais informações, consulte o "Documentação de restrições de contexto de segurança OpenShift".

Você pode impedir que anotações específicas no namespace de destino sejam sobrescritas definindo a variável de ambiente do Kubernetes RESTORE_SKIP_NAMESPACE_ANNOTATIONS antes de executar a operação de restauração ou failover. Por exemplo:

kubectl set env -n trident-protect deploy/trident-protect-controller-manager RESTORE_SKIP_NAMESPACE_ANNOTATIONS=<annotation_key_to_skip_1>,<annotation_key_to_skip_2>

Se instalou a aplicação de origem utilizando Helm com o --create-namespace sinalizador, é dado um tratamento especial à name tecla de identificação. Durante o processo de restauração ou failover, o Trident Protect copia esse rótulo para o namespace de destino, mas atualiza o valor para o valor do namespace de destino se o valor da origem corresponder ao namespace de origem. Se esse valor não corresponder ao namespace de origem, ele será copiado para o namespace de destino sem alterações.

Exemplo

O exemplo a seguir apresenta um namespace de origem e destino, cada um com anotações e rótulos diferentes. Você pode ver o estado do namespace de destino antes e depois da operação e como as anotações e rótulos são combinados ou substituídos no namespace de destino.

Antes da operação de restauração ou failover

A tabela a seguir ilustra o estado dos namespaces de origem e destino de exemplo antes da operação de restauração ou failover:

Namespace Anotações Etiquetas

Namespace ns-1 (fonte)

  • annotation.one/key: "updatedvalue"

  • annotation.two/key: "true"

  • ambiente de produção

  • conformidade hipaa

  • nome: ns-1

Namespace ns-2 (destino)

  • annotation.one/key: "true" (verdadeiro)

  • annotation.three/key: "false"

  • banco de dados

Após a operação de restauração

A tabela a seguir ilustra o estado do namespace de destino de exemplo após a operação de restauração ou failover. Algumas chaves foram adicionadas, algumas foram sobrescritas e o name rótulo foi atualizado para corresponder ao namespace de destino:

Namespace Anotações Etiquetas

Namespace ns-2 (destino)

  • annotation.one/key: "updatedvalue"

  • annotation.two/key: "true"

  • annotation.three/key: "false"

  • nome: ns-2

  • conformidade hipaa

  • ambiente de produção

  • banco de dados
Observação Você pode configurar o Trident Protect para congelar e descongelar sistemas de arquivos durante operações de proteção de dados. "Saiba mais sobre como configurar o congelamento do sistema de arquivos com o Trident Protect".

Configure uma relação de replicação

A configuração de uma relação de replicação envolve o seguinte:

  • Escolhendo com que frequência você deseja que o Trident Protect tire um snapshot do aplicativo (que inclui os recursos do Kubernetes do aplicativo, bem como os snapshots de volume de cada um dos volumes do aplicativo)

  • Escolha do cronograma de replicação (inclui recursos do Kubernetes e dados de volume persistente)

  • Definir o tempo para a captura instantânea

Passos

  1. No cluster de origem, crie um AppVault para o aplicativo de origem. Dependendo do seu fornecedor de storage, modifique um exemplo no "Recursos personalizados do AppVault" para se adequar ao seu ambiente:

    Crie um AppVault usando um CR

    1. Crie o arquivo de recurso personalizado (CR) e nomeie-o (por exemplo, trident-protect-appvault-primary-source.yaml ).

    2. Configure os seguintes atributos:

      • metadata.name: (required) o nome do recurso personalizado do AppVault. Anote o nome que você escolher, porque outros arquivos CR necessários para uma relação de replicação referem-se a esse valor.

      • spec.providerConfig: (required) armazena a configuração necessária para acessar o AppVault usando o provedor especificado. Escolha um bucketName e quaisquer outros detalhes necessários para o seu provedor. Anote os valores que você escolher, porque outros arquivos CR necessários para uma relação de replicação se referem a esses valores. "Recursos personalizados do AppVault"Consulte para obter exemplos de AppVault CRS com outros provedores.

      • spec.providerCredentials: (required) armazena referências a qualquer credencial necessária para acessar o AppVault usando o provedor especificado.

        • spec.providerCredentials.valueFromSecret: (required) indica que o valor da credencial deve vir de um segredo.

          • Key: (required) a chave válida do segredo para selecionar.

          • Name: (required) Nome do segredo que contém o valor deste campo. Deve estar no mesmo namespace.

        • spec.providerCredentials.secretAccessKey: (required) a chave de acesso usada para acessar o provedor. O nome deve corresponder a spec.providerCredentials.valueFromSecret.name.

      • spec.providerType: (required) determina o que fornece o backup; por exemplo, NetApp ONTAP S3, S3 genérico, Google Cloud ou Microsoft Azure. Valores possíveis:

        • aws

        • azure

        • gcp

        • generic-s3

        • ONTAP-s3

        • StorageGRID-s3

    3. Depois de preencher o trident-protect-appvault-primary-source.yaml ficheiro com os valores corretos, aplique o CR:

      kubectl apply -f trident-protect-appvault-primary-source.yaml -n trident-protect
    Crie um AppVault usando a CLI

    1. Crie o AppVault, substituindo valores entre parênteses por informações do seu ambiente:

      tridentctl-protect create vault Azure <vault-name> --account <account-name> --bucket <bucket-name> --secret <secret-name>

  2. No cluster de origem, crie a aplicação de origem CR:

    Crie o aplicativo de origem usando um CR

    1. Crie o arquivo de recurso personalizado (CR) e nomeie-o (por exemplo, trident-protect-app-source.yaml ).

    2. Configure os seguintes atributos:

      • metadata.name: (required) o nome do recurso personalizado do aplicativo. Anote o nome que você escolher, porque outros arquivos CR necessários para uma relação de replicação referem-se a esse valor.

      • spec.includedNamespaces: (required) um array de namespaces e rótulos associados. Use nomes de namespace e, opcionalmente, restrinja o escopo dos namespaces com rótulos para especificar recursos que existem nos namespaces listados aqui. O namespace da aplicação deve fazer parte desse array.

        Exemplo YAML:

      ---
apiVersion: protect.trident.netapp.io/v1
kind: Application
metadata:
  name: my-app-name
  namespace: my-app-namespace
spec:
  includedNamespaces:
    - namespace: my-app-namespace
      labelSelector: {}

    3. Depois de preencher o trident-protect-app-source.yaml ficheiro com os valores corretos, aplique o CR:

      kubectl apply -f trident-protect-app-source.yaml -n my-app-namespace
    Crie o aplicativo de origem usando a CLI

    1. Crie o aplicativo de origem. Por exemplo:

      tridentctl-protect create app <my-app-name> --namespaces <namespaces-to-be-included> -n <my-app-namespace>

  3. Opcionalmente, no cluster de origem, faça um snapshot de desligamento do aplicativo de origem. Este instantâneo é utilizado como base para a aplicação no cluster de destino. Se você pular esta etapa, precisará esperar que o próximo snapshot agendado seja executado para que você tenha um snapshot recente.

    Tire um instantâneo de encerramento utilizando um CR

    1. Crie um agendamento de replicação para o aplicativo de origem:

      1. Crie o arquivo de recurso personalizado (CR) e nomeie-o (por exemplo, trident-protect-schedule.yaml ).

      2. Configure os seguintes atributos:

        • metadata.name: (required) o nome do recurso personalizado de agendamento.

        • Spec.AppVaultRef: (required) este valor deve corresponder ao campo metadata.name do AppVault para o aplicativo de origem.

        • Spec.ApplicationRef: (required) este valor deve corresponder ao campo metadata.name da aplicação de origem CR.

        • Spec.backupRetention: (required) este campo é obrigatório e o valor deve ser definido como 0.

        • Spec.enabled: Deve ser definido como true.

        • spec.granularity: tem de estar definido para Custom.

        • Spec.recurrenceRule: Defina uma data de início no horário UTC e um intervalo de recorrência.

        • Spec.snapshotRetention: Deve ser definido como 2.

          Exemplo YAML:

      ---
apiVersion: protect.trident.netapp.io/v1
kind: Schedule
metadata:
  name: appmirror-schedule-0e1f88ab-f013-4bce-8ae9-6afed9df59a1
  namespace: my-app-namespace
spec:
  appVaultRef: generic-s3-trident-protect-src-bucket-04b6b4ec-46a3-420a-b351-45795e1b5e34
  applicationRef: my-app-name
  backupRetention: "0"
  enabled: true
  granularity: custom
  recurrenceRule: |-
    DTSTART:20220101T000200Z
    RRULE:FREQ=MINUTELY;INTERVAL=5
  snapshotRetention: "2"

      1. Depois de preencher o trident-protect-schedule.yaml ficheiro com os valores corretos, aplique o CR:

        kubectl apply -f trident-protect-schedule.yaml -n my-app-namespace
    Faça um instantâneo de encerramento usando a CLI

    1. Crie o snapshot, substituindo valores entre parênteses por informações do seu ambiente. Por exemplo:

      tridentctl-protect create snapshot <my_snapshot_name> --appvault <my_appvault_name> --app <name_of_app_to_snapshot> -n <application_namespace>

  4. No cluster de destino, crie um aplicativo de origem AppVault CR idêntico ao AppVault CR aplicado no cluster de origem e nomeie-o (por exemplo, trident-protect-appvault-primary-destination.yaml ).

  5. Aplicar o CR:

    kubectl apply -f trident-protect-appvault-primary-destination.yaml -n my-app-namespace

  6. Crie um AppVault CR de destino para o aplicativo de destino no cluster de destino. Dependendo do seu fornecedor de storage, modifique um exemplo no "Recursos personalizados do AppVault" para se adequar ao seu ambiente:

    1. Crie o arquivo de recurso personalizado (CR) e nomeie-o (por exemplo, trident-protect-appvault-secondary-destination.yaml ).

    2. Configure os seguintes atributos:

      • metadata.name: (required) o nome do recurso personalizado do AppVault. Anote o nome que você escolher, porque outros arquivos CR necessários para uma relação de replicação referem-se a esse valor.

      • spec.providerConfig: (required) armazena a configuração necessária para acessar o AppVault usando o provedor especificado. Escolha um bucketName e quaisquer outros detalhes necessários para o seu provedor. Anote os valores que você escolher, porque outros arquivos CR necessários para uma relação de replicação se referem a esses valores. "Recursos personalizados do AppVault"Consulte para obter exemplos de AppVault CRS com outros provedores.

      • spec.providerCredentials: (required) armazena referências a qualquer credencial necessária para acessar o AppVault usando o provedor especificado.

        • spec.providerCredentials.valueFromSecret: (required) indica que o valor da credencial deve vir de um segredo.

          • Key: (required) a chave válida do segredo para selecionar.

          • Name: (required) Nome do segredo que contém o valor deste campo. Deve estar no mesmo namespace.

        • spec.providerCredentials.secretAccessKey: (required) a chave de acesso usada para acessar o provedor. O nome deve corresponder a spec.providerCredentials.valueFromSecret.name.

      • spec.providerType: (required) determina o que fornece o backup; por exemplo, NetApp ONTAP S3, S3 genérico, Google Cloud ou Microsoft Azure. Valores possíveis:

        • aws

        • azure

        • gcp

        • generic-s3

        • ONTAP-s3

        • StorageGRID-s3

    3. Depois de preencher o trident-protect-appvault-secondary-destination.yaml ficheiro com os valores corretos, aplique o CR:

      kubectl apply -f trident-protect-appvault-secondary-destination.yaml -n my-app-namespace

  7. No cluster de destino, crie um arquivo CR AppMirrorRelationship:

    Crie um AppMirrorRelationship usando um CR

    1. Crie o arquivo de recurso personalizado (CR) e nomeie-o (por exemplo, trident-protect-relationship.yaml ).

    2. Configure os seguintes atributos:

      • metadata.name: (obrigatório) o nome do recurso personalizado AppMirrorRelationship.

      • spec.destinationAppVaultRef: (required) esse valor deve corresponder ao nome do AppVault para o aplicativo de destino no cluster de destino.

      • spec.namespaceMapping: (required) os namespaces de destino e origem devem corresponder ao namespace de aplicativo definido no respetivo CR de aplicação.

      • Spec.sourceAppVaultRef: (required) este valor deve corresponder ao nome do AppVault para o aplicativo de origem.

      • Spec.sourceApplicationName: (required) esse valor deve corresponder ao nome do aplicativo de origem definido no CR do aplicativo de origem.

      • Spec.storageClassName: (required) escolha o nome de uma classe de armazenamento válida no cluster. A classe de storage deve ser vinculada a uma VM de storage do ONTAP que esteja vinculada ao ambiente de origem.

      • Spec.recurrenceRule: Defina uma data de início no horário UTC e um intervalo de recorrência.

        Exemplo YAML:

      ---
apiVersion: protect.trident.netapp.io/v1
kind: AppMirrorRelationship
metadata:
  name: amr-16061e80-1b05-4e80-9d26-d326dc1953d8
  namespace: my-app-namespace
spec:
  desiredState: Established
  destinationAppVaultRef: generic-s3-trident-protect-dst-bucket-8fe0b902-f369-4317-93d1-ad7f2edc02b5
  namespaceMapping:
    - destination: my-app-namespace
      source: my-app-namespace
  recurrenceRule: |-
    DTSTART:20220101T000200Z
    RRULE:FREQ=MINUTELY;INTERVAL=5
  sourceAppVaultRef: generic-s3-trident-protect-src-bucket-b643cc50-0429-4ad5-971f-ac4a83621922
  sourceApplicationName: my-app-name
  sourceApplicationUID: 7498d32c-328e-4ddd-9029-122540866aeb
  storageClassName: sc-vsim-2

    3. Depois de preencher o trident-protect-relationship.yaml ficheiro com os valores corretos, aplique o CR:

      kubectl apply -f trident-protect-relationship.yaml -n my-app-namespace
    Crie um AppMirrorRelationship usando a CLI

    1. Crie e aplique o objeto AppMirrorRelationship, substituindo valores entre parênteses por informações do seu ambiente. Por exemplo:

      tridentctl-protect create appmirrorrelationship <name_of_appmirorrelationship> --destination-app-vault <my_vault_name> --recurrence-rule <rule> --source-app <my_source_app> --source-app-vault <my_source_app_vault> -n <application_namespace>

  8. (Optional) no cluster de destino, verifique o estado e o estado da relação de replicação:

    kubectl get amr -n my-app-namespace <relationship name> -o=jsonpath='{.status}' | jq

Failover para o cluster de destino

Com o Trident Protect, você pode fazer failover de aplicações replicadas para um cluster de destino. Este procedimento interrompe a relação de replicação e coloca a aplicação online no cluster de destino. O Trident Protect não interrompe o aplicativo no cluster de origem se ele estiver operacional.

Passos

  1. No cluster de destino, edite o arquivo CR AppMirrorRelationship (por exemplo, trident-protect-relationship.yaml ) e altere o valor de spec.desiredState para Promoted.

  2. Salve o arquivo CR.

  3. Aplicar o CR:

    kubectl apply -f trident-protect-relationship.yaml -n my-app-namespace

  4. (Optional) Crie todos os programas de proteção que você precisa no aplicativo com falha.

  5. (Optional) Verifique o estado e o estado da relação de replicação:

    kubectl get amr -n my-app-namespace <relationship name> -o=jsonpath='{.status}' | jq

Ressincronizar uma relação de replicação com falha

A operação ressincronizada restabelece a relação de replicação. Depois de executar uma operação ressincronizada, o aplicativo de origem original se torna o aplicativo em execução e quaisquer alterações feitas no aplicativo em execução no cluster de destino serão descartadas.

O processo pára o aplicativo no cluster de destino antes de restabelecer a replicação.

Importante Todos os dados gravados na aplicação de destino durante o failover serão perdidos.
Passos

  1. Opcional: No cluster de origem, crie um instantâneo do aplicativo de origem. Isso garante que as alterações mais recentes do cluster de origem sejam capturadas.

  2. No cluster de destino, edite o arquivo CR AppMirrorRelationship (por exemplo, trident-protect-relationship.yaml ) e altere o valor de spec.desiredState para Established.

  3. Salve o arquivo CR.

  4. Aplicar o CR:

    kubectl apply -f trident-protect-relationship.yaml -n my-app-namespace

  5. Se você criou quaisquer programações de proteção no cluster de destino para proteger o aplicativo com falha, remova-os. Quaisquer programações restantes causam falhas de snapshot de volume.

Ressincronização reversa de uma relação de replicação com falha

Quando você faz a ressincronização reversa de uma relação de replicação com falha, o aplicativo de destino se torna o aplicativo de origem e a origem se torna o destino. As alterações feitas na aplicação de destino durante o failover são mantidas.

Passos

  1. No cluster de destino original, exclua o AppMirrorRelationship CR. Isso faz com que o destino se torne a fonte. Se houver planos de proteção restantes no novo cluster de destino, remova-os.

  2. Configure uma relação de replicação aplicando os arquivos CR usados originalmente para configurar a relação com os clusters opostos.

  3. Certifique-se de que o novo destino (cluster de origem original) esteja configurado com o AppVault CRS.

  4. Configure uma relação de replicação no cluster oposto, configurando valores para a direção inversa.

Sentido de replicação da aplicação inversa

Quando você inverte a direção da replicação, o Trident Protect move o aplicativo para o back-end de storage de destino e continua replicando de volta para o back-end de storage de origem original. O Trident Protect interrompe a aplicação de origem e replica os dados para o destino antes de fazer o failover para a aplicação de destino.

Nesta situação, você está trocando a origem e o destino.

Passos

  1. No cluster de origem, crie um instantâneo de encerramento:

    Crie um instantâneo de encerramento utilizando um CR

    1. Desative as programações de políticas de proteção para o aplicativo de origem.

    2. Criar um ficheiro ShutdownSnapshot CR:

      1. Crie o arquivo de recurso personalizado (CR) e nomeie-o (por exemplo, trident-protect-shutdownsnapshot.yaml ).

      2. Configure os seguintes atributos:

        • metadata.name: (required) o nome do recurso personalizado.

        • Spec.AppVaultRef: (required) este valor deve corresponder ao campo metadata.name do AppVault para o aplicativo de origem.

        • Spec.ApplicationRef: (required) este valor deve corresponder ao campo metadata.name do arquivo CR da aplicação de origem.

          Exemplo YAML:

      ---
apiVersion: protect.trident.netapp.io/v1
kind: ShutdownSnapshot
metadata:
  name: replication-shutdown-snapshot-afc4c564-e700-4b72-86c3-c08a5dbe844e
  namespace: my-app-namespace
spec:
  appVaultRef: generic-s3-trident-protect-src-bucket-04b6b4ec-46a3-420a-b351-45795e1b5e34
  applicationRef: my-app-name

    3. Depois de preencher o trident-protect-shutdownsnapshot.yaml ficheiro com os valores corretos, aplique o CR:

      kubectl apply -f trident-protect-shutdownsnapshot.yaml -n my-app-namespace
    Crie um instantâneo de encerramento usando a CLI

    1. Crie o instantâneo de encerramento, substituindo valores entre parênteses por informações do seu ambiente. Por exemplo:

      tridentctl-protect create shutdownsnapshot <my_shutdown_snapshot> --appvault <my_vault> --app <app_to_snapshot> -n <application_namespace>

  2. No cluster de origem, após a conclusão do instantâneo de encerramento, obtenha o status do instantâneo de encerramento:

    kubectl get shutdownsnapshot -n my-app-namespace <shutdown_snapshot_name> -o yaml

  3. No cluster de origem, encontre o valor de shutdownsnapshot.status.appArchivePath usando o seguinte comando, e Registre a última parte do caminho do arquivo (também chamado de basename; isso será tudo após a última barra):

    k get shutdownsnapshot -n my-app-namespace <shutdown_snapshot_name> -o jsonpath='{.status.appArchivePath}'

  4. Faça um failover do novo cluster de destino para o novo cluster de origem, com a seguinte alteração:

    Observação Na etapa 2 do procedimento de failover, inclua o spec.promotedSnapshot campo no arquivo AppMirrorRelationship CR e defina seu valor para o nome de base registrado na etapa 3 acima.

  5. Execute as etapas de ressincronização reversa no Ressincronização reversa de uma relação de replicação com falha.

  6. Ative programações de proteção no novo cluster de origem.

Resultado

As seguintes ações ocorrem devido à replicação reversa:

  • Um snapshot é obtido dos recursos do Kubernetes do aplicativo de origem original.

  • Os pods do aplicativo de origem original são interrompidos graciosamente ao excluir os recursos do Kubernetes do aplicativo (deixando PVCs e PVS no lugar).

  • Depois que os pods são desativados, snapshots dos volumes do aplicativo são feitos e replicados.

  • As relações do SnapMirror são quebradas, tornando os volumes de destino prontos para leitura/gravação.

  • Os recursos do Kubernetes do aplicativo são restaurados a partir do snapshot de pré-encerramento, usando os dados de volume replicados após o desligamento do aplicativo de origem original.

  • A replicação é restabelecida na direção inversa.

Falha de aplicativos para o cluster de origem original

Usando o Trident Protect, você pode obter "failback" após uma operação de failover usando a seguinte sequência de operações. Nesse fluxo de trabalho para restaurar a direção de replicação original, o Trident Protect replica (ressincrones) qualquer aplicativo é alterado de volta para o aplicativo de origem original antes de reverter a direção de replicação.

Esse processo começa a partir de um relacionamento que concluiu um failover para um destino e envolve as seguintes etapas:

  • Comece com um estado com falha em excesso.

  • Reverta a ressincronização da relação de replicação.

    Cuidado Não execute uma operação de ressincronização normal, pois isso descartará os dados gravados no cluster de destino durante o procedimento de failover.

  • Inverta a direção da replicação.

Passos

  1. Execute os Ressincronização reversa de uma relação de replicação com falha passos.

  2. Execute os Sentido de replicação da aplicação inversa passos.

Excluir uma relação de replicação

Você pode excluir um relacionamento de replicação a qualquer momento. Quando você exclui a relação de replicação do aplicativo, isso resulta em dois aplicativos separados sem relação entre eles.

Passos

  1. No cluster de dessinização atual, exclua o AppMirrorRelationship CR:

    kubectl delete -f trident-protect-relationship.yaml -n my-app-namespace