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 NetApp SnapMirror e 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 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 espaço de nomes de destino permanecem inalterados.

Observação Se você usa 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 cumpram 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 "Documentação sobre restrições de contexto de segurança do 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:

helm upgrade trident-protect --set 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 opções de filtragem de namespace e AutoSupport".

Se você instalou o aplicativo de origem usando o Helm com o --create-namespace bandeira, tratamento especial é dado ao name Legenda da etiqueta. 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 um de destino, cada um com anotações e rótulos diferentes. É possível visualizar o estado do namespace de destino antes e depois da operação, bem como a forma 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

Espaço de nomes ns-1 (fonte)

  • anotação.um/chave: "valoratualizado"

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

  • ambiente=produção

  • conformidade=hipaa

  • nome=ns-1

Espaço de nomes ns-2 (destino)

  • anotação.um/chave: "verdadeiro"

  • anotação.três/chave: "falso"

  • função=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, outras foram sobrescritas, e a name O rótulo foi atualizado para corresponder ao namespace de destino:

Espaço de nomes Anotações Etiquetas

Espaço de nomes ns-2 (destino)

  • anotação.um/chave: "valoratualizado"

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

  • anotação.três/chave: "falso"

  • nome=ns-2

  • conformidade=hipaa

  • ambiente=produção

  • funçã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.".

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

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

  • Durante um 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 a falha, os ganchos de execução permanecem presentes na aplicação e serão executados durante quaisquer ações relevantes.

  • Durante a reversão ou resincronização reversa, todos os ganchos de execução existentes no aplicativo são removidos. Quando a aplicação de origem se torna a aplicação de destino, esses ganchos de execução deixam de ser válidos e são excluídos para impedir sua execução.

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

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

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

  • Escolher a frequência com que o Trident Protect deve tirar 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).

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

  • Definir a hora em que a foto será tirada.

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 se adequar 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. Configure os seguintes atributos:

      • metadata.name: (Obrigatório) O nome do recurso personalizado do AppVault. Anote o nome escolhido, pois outros arquivos CR necessários para uma relação de replicação farão 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 nome para o bucket e quaisquer outros detalhes necessários para o seu provedor. Anote os valores que você escolher, pois outros arquivos CR necessários para uma relação de replicação fazem referência a esses valores. Consulte"Recursos personalizados do AppVault" Para exemplos de solicitações de configuração (CRs) do AppVault com outros provedores.

      • spec.providerCredentials: (Obrigatório) Armazena referências a quaisquer credenciais 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 selecionado.

          • nome: (Obrigatório) Nome do segredo que contém o valor deste campo. Devem estar no mesmo espaço de nomes.

        • spec.providerCredentials.secretAccessKey: (Obrigatório) A chave de acesso usada para acessar o provedor. O nome 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

        • azul

        • gcp

        • genérico-s3

        • ontap-s3

        • storagegrid-s3

    3. Depois de preencher o trident-protect-appvault-primary-source.yaml Arquivo 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 os valores entre colchetes pelas 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 solicitação de configuração (CR) do aplicativo de origem:

    Crie o aplicativo de origem usando um CR (Código de Referência).

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

    2. Configure 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 uma relação de replicação farão referência a esse valor.

      • spec.includedNamespaces: (Obrigatório) Uma matriz de namespaces e rótulos associados. Utilize nomes de namespaces 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 deste array.

        Exemplo de 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 Arquivo 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 (linha de comando)

    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, tire um snapshot do aplicativo de origem. Este instantâneo é usado como base para a aplicação no cluster de destino. Se você pular esta etapa, precisará aguardar a próxima captura de instantâneo agendada para obter um instantâneo recente.

    Observação

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

    Caso ocorra uma falha, o sistema pode usar esses snapshots por até 7 dias para operações de reversão. Essa abordagem torna o processo inverso mais rápido e eficiente, pois apenas as alterações feitas desde o último instantâneo serão transferidas, e 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.
    Tire uma foto usando uma CR (Câmera de Reprodução).

    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. Configure 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 para o aplicativo 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.granularity: Deve ser definido como Custom .

        • spec.recurrenceRule: Define uma data de início em UTC e um intervalo de recorrência.

        • spec.snapshotRetention: Deve ser definido como 2.

          Exemplo de 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 Arquivo com os valores corretos, aplique o CR:

        kubectl apply -f trident-protect-schedule.yaml -n my-app-namespace
    Tire uma captura de tela usando a CLI

    1. Crie o instantâneo, substituindo os valores entre colchetes pelas 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 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 ).

  5. Aplicar o CR:

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

  6. Crie uma solicitação de configuração (CR) do AppVault 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 se adequar 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. Configure os seguintes atributos:

      • metadata.name: (Obrigatório) O nome do recurso personalizado do AppVault. Anote o nome escolhido, pois outros arquivos CR necessários para uma relação de replicação farão 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 fornecedor. Anote os valores que você escolher, pois outros arquivos CR necessários para uma relação de replicação fazem referência a esses valores. Consulte"Recursos personalizados do AppVault" Para exemplos de solicitações de configuração (CRs) do AppVault com outros provedores.

      • spec.providerCredentials: (Obrigatório) Armazena referências a quaisquer credenciais 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 selecionado.

          • nome: (Obrigatório) Nome do segredo que contém o valor deste campo. Devem estar no mesmo espaço de nomes.

        • spec.providerCredentials.secretAccessKey: (Obrigatório) A chave de acesso usada para acessar o provedor. O nome 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

        • azul

        • gcp

        • genérico-s3

        • ontap-s3

        • storagegrid-s3

    3. Depois de preencher o trident-protect-appvault-secondary-destination.yaml Arquivo 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 de relacionamento AppMirror:

    Crie um relacionamento AppMirror usando um CR

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

    2. Configure 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.storageClassName: (Obrigatório) Escolha o nome de uma classe de armazenamento válida no cluster. A classe de armazenamento deve ser vinculada a uma VM de armazenamento ONTAP que esteja emparelhada com o ambiente de origem.

      • spec.recurrenceRule: Define uma data de início em UTC e um intervalo de recorrência.

        Exemplo de 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 Arquivo com os valores corretos, aplique o CR:

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

    1. Crie e aplique o objeto AppMirrorRelationship, substituindo os valores entre colchetes pelas 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. (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

Failover para o cluster de destino

Usando o 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 aplicativo 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. (Opcional) Crie quaisquer cronogramas de proteção que você precise no aplicativo em caso de falha.

  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 que falhou

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 aplicativo 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. Aplicar 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-o. Qualquer agendamento pendente causa falhas no snapshot de volume.

Reverter a resincronização de uma relação de replicação que falhou

Ao reverter a resincronização de uma relação de replicação que falhou, 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 o failover são mantidas.

Passos

  1. No cluster de destino original, exclua o CR AppMirrorRelationship. Isso faz com que o destino se torne a origem. Se ainda houver alguma programação de proteção no novo cluster de destino, remova-a.

  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 original) esteja configurado com ambas as solicitações de configuração (CRs) do AppVault.

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

Direção de replicação inversa do aplicativo

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

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

Passos

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

    Crie um instantâneo de desligamento usando uma CR (Código de Requisição).

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

    2. Crie um arquivo CR de ShutdownSnapshot:

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

      2. Configure 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 para o aplicativo de origem.

        • spec.ApplicationRef: (Obrigatório) Este valor deve corresponder ao campo metadata.name do arquivo CR do aplicativo de origem.

          Exemplo de 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 Arquivo com os valores corretos, aplique o CR:

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

    1. Crie o instantâneo 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 spec.promotedSnapshot No arquivo CR AppMirrorRelationship, defina o valor do campo para o nome base que você registrou na etapa 3 acima.

  5. Execute as etapas de resincronização reversa emReverter a resincronização de uma relação de replicação que falhou .

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

Resultado

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

  • É feita uma captura instantânea dos recursos Kubernetes do aplicativo de origem original.

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

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

  • Os relacionamentos SnapMirror foram desfeitos, 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 original.

Utilizando o Trident Protect, você pode realizar o "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 (ressincroniza) quaisquer alterações do aplicativo de volta para o aplicativo de origem original antes de inverter a direção da replicação.

Esse processo começa com um relacionamento que concluiu uma transição de 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á os dados gravados no cluster de destino durante o procedimento de failover.

  • Inverta o sentido da replicação.

Passos

  1. Realize oReverter a resincronização de uma relação de replicação que falhou passos.

  2. Realize oDireção de replicação inversa 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 CR AppMirrorRelationship:

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