Skip to main content
Uma versão mais recente deste produto está disponível.
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 NetApp SnapMirror e Trident Protect

PDFs

Com Trident Protect, você pode usar os recursos de replicação assíncrona da tecnologia NetApp SnapMirror para replicar dados e alterações de aplicativos de um backend de armazenamento 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, os rótulos e anotações no namespace de destino são ajustados 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 já existentes 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ê usa Red Hat OpenShift, é importante observar o papel crucial das anotações de namespace em ambientes OpenShift. As anotações de namespace garantem que os pods restaurados sigam as permissões e configurações de segurança apropriadas definidas pelas restrições de contexto de segurança (SCCs) do OpenShift e possam acessar volumes sem problemas de permissão. Para mais informações, consulte o "OpenShift security context constraints documentação".

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:

helm upgrade trident-protect -n trident-protect netapp-trident-protect/trident-protect \
  --set-string restoreSkipNamespaceAnnotations="{<annotation_key_to_skip_1>,<annotation_key_to_skip_2>}" \
  --reuse-values
Observação Ao executar uma operação de restauração ou failover, quaisquer anotações e rótulos de namespace especificados em restoreSkipNamespaceAnnotations e restoreSkipNamespaceLabels são excluídos da operação de restauração ou failover. Certifique-se de que essas configurações sejam definidas durante a instalação inicial do Helm. Para saber mais, consulte "Configurar configurações adicionais do helm chart do Trident Protect".

Se você instalou o aplicativo de origem usando Helm com a --create-namespace flag, um tratamento especial é dado à chave de rótulo name. Durante o processo de restauração ou failover, 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 é copiado para o namespace de destino sem alterações.

Exemplo

O exemplo a seguir apresenta um namespace de origem e um de 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 os rótulos são combinados ou sobrescritos 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 do exemplo antes da operação de restauração ou failover:

Espaço de nomes Anotações Etiquetas

Namespace ns-1 (fonte)

  • annotation.one/key: "valoratualizado"

  • anotação.dois/chave: "true"

  • ambiente=produção

  • compliance=hipaa

  • name=ns-1

Espaço de nomes ns-2 (destino)

  • annotation.one/key: "true"

  • anotação.three/chave: "falso"

  • role=database

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, outras foram sobrescritas e o name rótulo foi atualizado para corresponder ao namespace de destino:

Espaço de nomes Anotações Etiquetas

Espaço de nomes ns-2 (destino)

  • annotation.one/key: "valoratualizado"

  • anotação.dois/chave: "true"

  • anotação.three/chave: "falso"

  • name=ns-2

  • compliance=hipaa

  • ambiente=produção

  • role=database
Observação Você pode configurar 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 Trident Protect".

Ganchos de execução durante failover e operações de reversão

Ao usar o relacionamento AppMirror para proteger sua aplicação, existem comportamentos específicos relacionados aos ganchos de execução que você deve conhecer durante operações de failover e reversão.

  • Durante o failover, os hooks de execução são copiados automaticamente do cluster de origem para o cluster de destino. Você não precisa recriá-los manualmente. Após o failover, os hooks de execução estão presentes na aplicação e serão executados durante quaisquer ações relevantes.

  • Durante a operação reversa ou ressincronização reversa, todos os ganchos de execução existentes no aplicativo são removidos. Quando o aplicativo de origem se torna o aplicativo de destino, esses ganchos de execução perdem a validade e são excluídos para impedir sua execução.

Para saber mais sobre ganchos de execução, consulte "Gerenciar os ganchos de execução do Trident Protect".

Estabeleça uma relação de replicação

Configurar uma relação de replicação envolve o seguinte:

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

  • Escolhendo o agendamento de replicação (inclui recursos do Kubernetes, bem como dados de volume persistente)

  • Definindo o horário para a criação do snapshot

Passos

  1. No cluster de origem, crie um AppVault para o aplicativo de origem. Dependendo do seu provedor de armazenamento, modifique um exemplo em "Recursos personalizados do AppVault" para adequá-lo ao seu ambiente:

    Crie um AppVault usando um CR

    1. Crie o arquivo de recurso personalizado (CR) e dê um nome a ele (por exemplo, trident-protect-appvault-primary-source.yaml).

    2. Configurar os seguintes atributos:

      • metadata.name: (Obrigatório) O nome do recurso personalizado AppVault. Anote o nome escolhido, pois outros arquivos CR necessários para um relacionamento de replicação fazem referência a esse valor.

      • spec.providerConfig: (Obrigatório) 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 escolhidos, pois outros arquivos CR necessários para um relacionamento de replicação fazem referência a esses valores. Consulte "Recursos personalizados do AppVault" para exemplos de CRs do AppVault com outros provedores.

      • spec.providerCredentials: (Obrigatório) Armazena referências a quaisquer credencial necessárias para acessar o AppVault usando o provedor especificado.

        • spec.providerCredentials.valueFromSecret: (Obrigatório) Indica que o valor da credencial deve vir de um segredo.

          • chave: (Obrigatório) A chave válida do segredo a ser selecionada.

          • nome: (Obrigatório) Nome do segredo que contém o valor deste campo. Deve estar no mesmo namespace.

        • spec.providerCredentials.secretAccessKey: (Obrigatório) A chave de acesso usada para acessar o provedor. O name deve corresponder a spec.providerCredentials.valueFromSecret.name.

      • spec.providerType: (Obrigatório) 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. Após preencher o arquivo trident-protect-appvault-primary-source.yaml com os valores corretos, aplique a CR:

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

    1. Crie o AppVault, substituindo os valores entre colchetes por informações do seu ambiente:

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

  2. No cluster de origem, crie o CR do aplicativo de origem:

    Crie o aplicativo de origem usando um CR

    1. Crie o arquivo de recurso personalizado (CR) e dê um nome a ele (por exemplo, trident-protect-app-source.yaml).

    2. Configurar os seguintes atributos:

      • metadata.name: (Obrigatório) O nome do recurso personalizado do aplicativo. Anote o nome escolhido, pois outros arquivos CR necessários para um relacionamento de replicação fazem referência a esse valor.

      • spec.includedNamespaces: (Obrigatório) Uma matriz 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 do aplicativo deve fazer parte desta matriz.

        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. Após preencher o arquivo trident-protect-app-source.yaml com os valores corretos, aplique a CR:

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

    1. Crie a aplicação 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, tire um snapshot do aplicativo de origem. Esse snapshot é usado como base para o aplicativo no cluster de destino. Se você ignorar esta etapa, precisará aguardar a próxima execução de snapshot agendado para ter um snapshot recente. Para criar um snapshot sob demanda, consulte "Criar um snapshot sob demanda".

  4. No cluster de origem, crie o CR de agendamento de replicação:

    Observação

    Além da programação fornecida abaixo, recomenda-se criar uma programação diária de snapshots separada, com um período de retenção de 7 dias, para manter um snapshot comum entre clusters ONTAP interligados. Isso garante que os snapshots estejam disponíveis por até 7 dias, mas o período de retenção pode ser personalizado de acordo com as necessidades do usuário.

    Em caso de failover, o sistema pode usar esses snapshots por até 7 dias para operações de reversão. Essa abordagem torna o processo de reversão mais rápido e eficiente porque apenas as alterações feitas desde o último snapshot serão transferidas, não todos os dados.

    Se um cronograma existente para o aplicativo já atender aos requisitos de retenção desejados, não serão necessários cronogramas adicionais.
    Crie a programação de replicação usando uma CR

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

      1. Crie o arquivo de recurso personalizado (CR) e dê um nome a ele (por exemplo, trident-protect-schedule.yaml).

      2. Configurar os seguintes atributos:

        • metadata.name: (Obrigatório) O nome do recurso personalizado de agendamento.

        • spec.appVaultRef: (Obrigatório) Este valor deve corresponder ao campo metadata.name do AppVault da aplicação de origem.

        • spec.applicationRef: (Obrigatório) Este valor deve corresponder ao campo metadata.name do CR da aplicação de origem.

        • spec.backupRetention: (Obrigatório) Este campo é obrigatório e o valor deve ser definido como 0.

        • spec.enabled: deve ser definido como verdadeiro.

        • spec.granularidade: Deve ser definida como Custom.

        • spec.recurrenceRule: Defina uma data de início em 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
  namespace: my-app-namespace
spec:
  appVaultRef: my-appvault-name
  applicationRef: my-app-name
  backupRetention: "0"
  enabled: true
  granularity: Custom
  recurrenceRule: |-
    DTSTART:20220101T000200Z
    RRULE:FREQ=MINUTELY;INTERVAL=5
  snapshotRetention: "2"

      1. Após preencher o arquivo trident-protect-schedule.yaml com os valores corretos, aplique a CR:

        kubectl apply -f trident-protect-schedule.yaml -n my-app-namespace
    Crie o agendamento de replicação usando a CLI

    1. Crie o cronograma de replicação, substituindo os valores entre colchetes pelas informações do seu ambiente:

      tridentctl-protect create schedule --name appmirror-schedule --app <my_app_name> --appvault <my_app_vault> --granularity Custom --recurrence-rule <rule> --snapshot-retention <snapshot_retention_count> -n <my_app_namespace>

      Exemplo:

      tridentctl-protect create schedule --name appmirror-schedule --app <my_app_name> --appvault <my_app_vault> --granularity Custom --recurrence-rule  "DTSTART:20220101T000200Z\nRRULE:FREQ=MINUTELY;INTERVAL=5" --snapshot-retention 2 -n <my_app_namespace>

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

  6. Aplique o CR:

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

  7. Crie um AppVault CR de destino para o aplicativo de destino no cluster de destino. Dependendo do seu provedor de armazenamento, modifique um exemplo em "Recursos personalizados do AppVault" para adequá-lo ao seu ambiente:

    1. Crie o arquivo de recurso personalizado (CR) e dê um nome a ele (por exemplo, trident-protect-appvault-secondary-destination.yaml).

    2. Configurar os seguintes atributos:

      • metadata.name: (Obrigatório) O nome do recurso personalizado AppVault. Anote o nome escolhido, pois outros arquivos CR necessários para um relacionamento de replicação fazem referência a esse valor.

      • spec.providerConfig: (Obrigatório) 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 escolhidos, pois outros arquivos CR necessários para um relacionamento de replicação fazem referência a esses valores. Consulte "Recursos personalizados do AppVault" para exemplos de AppVault CRs com outros provedores.

      • spec.providerCredentials: (Obrigatório) Armazena referências a quaisquer credencial necessárias para acessar o AppVault usando o provedor especificado.

        • spec.providerCredentials.valueFromSecret: (Obrigatório) Indica que o valor da credencial deve vir de um segredo.

          • chave: (Obrigatório) A chave válida do segredo a ser selecionada.

          • nome: (Obrigatório) Nome do segredo que contém o valor deste campo. Deve estar no mesmo namespace.

        • spec.providerCredentials.secretAccessKey: (Obrigatório) A chave de acesso usada para acessar o provedor. O name deve corresponder a spec.providerCredentials.valueFromSecret.name.

      • spec.providerType: (Obrigatório) 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. Após preencher o arquivo trident-protect-appvault-secondary-destination.yaml com os valores corretos, aplique a CR:

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

  8. No cluster de destino, crie um arquivo CR AppMirrorRelationship.

    Observação Ao usar uma CR, crie manualmente o namespace de destino antes de aplicar a CR. Trident Protect cria namespaces automaticamente apenas quando se usa a CLI.
    Crie um AppMirrorRelationship usando um CR

    1. Crie o arquivo de recurso personalizado (CR) e dê um nome a ele (por exemplo, trident-protect-relationship.yaml).

    2. Configurar os seguintes atributos:

      • metadata.name: (Obrigatório) O nome do recurso personalizado AppMirrorRelationship.

      • spec.destinationAppVaultRef: (Obrigatório) Este valor deve corresponder ao nome do AppVault para o aplicativo de destino no cluster de destino.

      • spec.namespaceMapping: (Obrigatório) Os namespaces de destino e de origem devem corresponder ao namespace do aplicativo definido no respectivo CR do aplicativo.

      • spec.sourceAppVaultRef: (Obrigatório) Este valor deve corresponder ao nome do AppVault para o aplicativo de origem.

      • spec.sourceApplicationName: (Obrigatório) Este valor deve corresponder ao nome do aplicativo de origem que você definiu no CR do aplicativo de origem.

      • spec.sourceApplicationUID: (Obrigatório) Este valor deve corresponder ao UID do aplicativo de origem que você definiu no CR do aplicativo de origem.

      • spec.storageClassName: (Opcional) Escolha o nome de uma classe de armazenamento válida no cluster. A classe de armazenamento deve estar vinculada a uma VM de armazenamento ONTAP que esteja emparelhada com o ambiente de origem. Se a classe de armazenamento não for fornecida, a classe de armazenamento padrão do cluster será usada por padrão.

      • spec.recurrenceRule: Defina uma data de início em 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. Após preencher o arquivo trident-protect-relationship.yaml com os valores corretos, aplique a 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 os valores entre colchetes por informações do seu ambiente:

      tridentctl-protect create appmirrorrelationship <name_of_appmirorrelationship> --destination-app-vault <my_vault_name> --source-app-vault <my_vault_name> --recurrence-rule <rule> --namespace-mapping <ns_mapping> --source-app-id <source_app_UID> --source-app <my_source_app_name> --storage-class <storage_class_name> -n <application_namespace>

      Exemplo:

      tridentctl-protect create appmirrorrelationship my-amr --destination-app-vault appvault2 --source-app-vault appvault1 --recurrence-rule "DTSTART:20220101T000200Z\nRRULE:FREQ=MINUTELY;INTERVAL=5" --source-app my-app --namespace-mapping "my-source-ns1:my-dest-ns1,my-source-ns2:my-dest-ns2" --source-app-id 373f24c1-5769-404c-93c3-5538af6ccc36 --storage-class my-storage-class -n my-dest-ns1

  9. (Opcional) No cluster de destino, verifique o estado e o status da relação de replicação:

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

Fail over para o cluster de destino

Com Trident Protect, você pode realizar o failover de aplicativos replicados para um cluster de destino. Este procedimento interrompe a relação de replicação e coloca o app online no cluster de destino. Trident Protect não interrompe o app 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. Aplique o CR:

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

  4. (Opcional) Crie quaisquer cronogramas de proteção que você precise no aplicativo com failover.

  5. (Opcional) Verifique o estado e o status 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 failover

A operação de ressincronização restabelece a relação de replicação. Após a execução de uma operação de ressincronização, o aplicativo de origem original torna-se o aplicativo em execução e quaisquer alterações feitas no aplicativo em execução no cluster de destino são descartadas.

O processo interrompe o app no cluster de destino antes de restabelecer a replicação.

Importante Quaisquer dados gravados no aplicativo de destino durante a transição de falha serão perdidos.
Passos

  1. Opcional: No cluster de origem, crie um snapshot 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. Aplique o CR:

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

  5. Se você criou algum agendamento de proteção no cluster de destino para proteger o aplicativo em failover, remova-os. Quaisquer agendamentos restantes causam falhas no snapshot de volume.

Resincronizar reversamente uma relação de replicação com failover

Ao reverter a resincronização de uma relação de replicação com falha, o aplicativo de destino torna-se o aplicativo de origem e a origem torna-se o destino. As alterações feitas no aplicativo de destino durante a falha são mantidas.

Passos

  1. No cluster de destino original, exclua o CR AppMirrorRelationship. Isso faz com que o destino se torne o cluster de origem. Se houver algum agendamento de proteção restante no novo cluster de destino, remova-os.

  2. Estabeleça uma relação de replicação aplicando os arquivos CR que você usou originalmente para configurar a relação aos clusters opostos.

  3. Certifique-se de que o novo destino (cluster de origem) esteja configurado com ambas as CRs AppVault.

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

Inverter a direção da replicação do aplicativo

Ao inverter a direção da replicação, Trident Protect move a aplicação para o backend de armazenamento de destino, enquanto continua a replicar de volta para o backend de armazenamento de origem original. Trident Protect interrompe a aplicação de origem e replica os dados para o destino antes de realizar o failover para a aplicação de destino.

Nessa situação, você está trocando o cluster de origem e o cluster de destino.

Passos

  1. No cluster de origem, crie um snapshot de desligamento:

    Crie um instantâneo de desligamento usando uma CR

    1. Desative os agendamentos da política de proteção para o aplicativo de origem.

    2. Crie um arquivo CR ShutdownSnapshot:

      1. Crie o arquivo de recurso personalizado (CR) e dê um nome a ele (por exemplo, trident-protect-shutdownsnapshot.yaml).

      2. Configurar os seguintes atributos:

        • metadata.name: (Obrigatório) O nome do recurso personalizado.

        • spec.AppVaultRef: (Obrigatório) Este valor deve corresponder ao campo metadata.name do AppVault da aplicação de origem.

        • spec.ApplicationRef: (Obrigatório) Este valor deve corresponder ao campo metadata.name do arquivo CR do aplicativo 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. Após preencher o arquivo trident-protect-shutdownsnapshot.yaml com os valores corretos, aplique a CR:

      kubectl apply -f trident-protect-shutdownsnapshot.yaml -n my-app-namespace
    Crie um Snapshot de desligamento usando a CLI

    1. Crie o snapshot de desligamento, substituindo os valores entre colchetes pelas 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 snapshot de desligamento, obtenha o status do snapshot de desligamento:

    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 chamada de nome base; isso será tudo o que vem depois da última barra):

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

  4. Realize 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 campo spec.promotedSnapshot no arquivo CR AppMirrorRelationship e defina seu valor para o basename que você registrou na etapa 3 acima.

  5. Execute as etapas de resincronização reversa em Resincronizar reversamente uma relação de replicação com failover.

  6. Ative os agendamentos de proteção no novo cluster de origem.

Resultado

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

  • É feita uma snapshot dos recursos Kubernetes do aplicativo de origem original.

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

  • Após o desligamento dos pods, snapshots dos volumes do aplicativo são criados e replicados.

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

  • Os recursos do Kubernetes do aplicativo são restaurados a partir do Snapshot anterior ao desligamento, usando os dados de volume replicados após o desligamento do aplicativo de origem original.

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

Restaurar aplicativos para o cluster de origem

Com Trident Protect, você pode realizar o "fail back" após uma operação de failover seguindo a seguinte sequência de operações. Nesse fluxo de trabalho para restaurar a direção de replicação original, Trident Protect replica (ressincroniza) quaisquer alterações do aplicativo de volta para o aplicativo de origem original antes de reverter a direção da replicação.

Esse processo começa a partir de uma relação que concluiu um failover para um destino e envolve as seguintes etapas:

  • Comece com um estado de failover.

  • Reverter a resincronização da relação de replicação.

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

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

Passos

  1. Execute as etapas Resincronizar reversamente uma relação de replicação com failover.

  2. Execute os Inverter a direção da replicação do aplicativo passos.

Excluir uma relação de replicação

Você pode excluir uma relação de replicação a qualquer momento. Ao excluir a relação de replicação do aplicativo, o resultado são dois aplicativos separados, sem nenhuma relação entre eles.

Passos

  1. No cluster de destino atual, exclua o AppMirrorRelationship CR:

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