Cópia de segurança e restauro do CSI do Cassandra

Pode fazer uma cópia de segurança e restaurar os seus dados híbridos através de capturas instantâneas da CSI (interface de armazenamento de contentores). A cópia de segurança da CSI aciona as capturas instantâneas de disco feitas pelo sistema de armazenamento subjacente através do controlador da CSI fornecido. A cópia de segurança da CSI não precisa de um contentor do Google Cloud Storage nem de um servidor remoto para armazenar dados de cópia de segurança.

Recomendamos a cópia de segurança da CSI para instâncias híbridas alojadas no Google Cloud, na AWS ou no Azure.

Esta página descreve os passos para usar a cópia de segurança e o restauro de CSI híbrido. Para uma vista geral da cópia de segurança e do restauro híbridos em geral, consulte a vista geral da cópia de segurança e do restauro do Cassandra.

Limitações da cópia de segurança e do restauro

Tenha em atenção estas limitações quando usar a cópia de segurança e o restauro da CSI:

  • O controlador CSI usado pela classe de armazenamento configurada tem de suportar instantâneos de CSI. Consulte esta lista de controladores CSI do Kubernetes para obter informações sobre os controladores.
  • Nem todas as plataformas são suportadas. Apenas são suportadas as plataformas Google Cloud, AWS e Azure.
  • A OpenShift Container Platform não é suportada devido a limitações de instantâneos de volumes.
  • Apenas são suportadas plataformas na nuvem. As plataformas no local não são suportadas.
  • Os dados de cópia de segurança da CSI e os dados de cópia de segurança híbrida não CSI são incompatíveis. Não é possível usar cópias de segurança não CSI com o restauro CSI, e não é possível usar cópias de segurança CSI com o restauro não CSI.
  • A instalação e a funcionalidade do controlador CSI são da responsabilidade do fornecedor do controlador CSI.
  • Os utilizadores são responsáveis por garantir que existem recursos de cluster adequados para o aprovisionamento de instantâneos da CSI.
  • Os utilizadores são responsáveis pela remoção de dados de instantâneos antigos.

Configure cópias de segurança de CSI

Para agendar cópias de segurança híbridas através da CSI, siga estes passos:

  1. Se não tiver configurado anteriormente uma cópia de segurança híbrida:
    1. Execute o seguinte comando create-service-account para criar uma conta de serviço (SA) do Google Cloud com a função roles/storage.objectAdmin padrão. Esta função de SA permite-lhe escrever dados de cópias de segurança no Cloud Storage. Execute o seguinte comando no diretório adequado para a sua ferramenta de gestão:
      • Gráficos Helm: $APIGEE_HELM_CHARTS_HOME/apigee-operator/etc/
      • apigeectl: HYBRID_BASE_DIRECTORY/hybrid-files/
      ./tools/create-service-account --env non-prod --dir ./service-accounts

      Este comando cria uma única conta de serviço com o nome apigee-non-prod para utilização em ambientes de não produção e coloca o ficheiro de chave transferido no diretório ./service-accounts.

      Para mais informações sobre as contas de serviço do Google Cloud, consulte os artigos Criar e gerir contas de serviço.

    2. O comando create-service-account guarda um ficheiro JSON que contém a chave privada da conta de serviço. O ficheiro é guardado no mesmo diretório onde o comando é executado. Vai precisar do caminho para este ficheiro nos passos seguintes.
  2. Abra o ficheiro overrides.yaml. Defina os seguintes parâmetros, conforme mostrado nos ficheiros de substituições de exemplo.

    1. Defina os parâmetros gerais apresentados abaixo no bloco backup. Se já tiver definido estes parâmetros para a solução de cópia de segurança híbrida não CSI, pode usar os mesmos parâmetros para as suas capturas instantâneas CSI. Consulte a tabela de referência das propriedades de substituição para ver mais informações sobre cada valor.

      Para backup:

      • enabled: definido como true para ativar as cópias de segurança agendadas.
      • pullPolicy na imagem: definida como Always.
      • schedule: faculte uma programação de expressões cron.
    2. Defina estes parâmetros para a cópia de segurança específica da CSI:
      • Valores do grupo de armazenamento do Cassandra: a classe de armazenamento do Cassandra configurada tem de suportar instantâneos da CSI para que a cópia de segurança e o restauro da CSI funcionem. Para verificar se uma classe de armazenamento suporta instantâneos da CSI, execute o seguinte comando para obter as classes de armazenamento disponíveis:
        kubectl get sc
        Consulte o resultado do "Provisioner" para cada classe de armazenamento. Os aprovisionadores que usam o CSI têm normalmente uma parte ".csi." no nome, como "pd.csi.storage.gke.io". Procure o nome do aprovisionador nesta lista de controladores CSI do Kubernetes. Se a coluna "Outras funcionalidades" do aprovisionador contiver a palavra "SNAPSHOT", a classe de armazenamento que usa o aprovisionador suporta instantâneos da CSI.

        Adicione estes parâmetros no grupo de armazenamento. Ambos os valores são obrigatórios.

        • storageclass: o nome de uma classe de armazenamento com instantâneos de CSI ativados.
        • capacidade: a capacidade do disco.
      • Tipo de fornecedor de nuvem:

        Assim que a capacidade de instantâneo da CSI for validada, modifique o ficheiro de substituições para usar a cópia de segurança e o restauro da CSI:

        • cloudProvider: defina cloudProvider em backup e restore como CSI.

Exemplo de configuração da cópia de segurança

Esta secção mostra as partes relacionadas com a cópia de segurança de um ficheiro overrides.yaml de exemplo.
cassandra:
  hostNetwork: false
  replicaCount: 3
  storage:
    storageclass: standard-rwo
    capacity: 100Gi
  image:
    pullPolicy: Always

  backup:
    enabled: true
    image:
      pullPolicy: Always
    cloudProvider: "CSI"
    schedule: "0 * * 11 *"

Inicie uma cópia de segurança manual

As cópias de segurança de CSI são geradas automaticamente de acordo com a programação cron definida no ficheiro overrides.yaml.

Para iniciar uma cópia de segurança de CSI manual, use este comando:

kubectl create job -n APIGEE_NAMESPACE --from=cronjob/apigee-cassandra-backup BACKUP_POD_NAME
em que BACKUP_POD_NAME é o nome do pod de cópia de segurança que vai ser criado.

Valide as cópias de segurança

Uma forma de verificar se foi criada uma cópia de segurança com êxito é verificar as imagens instantâneas de volumes no cluster do Kubernetes através deste comando:

kubectl get volumesnapshot -n APIGEE_NAMESPACE

O resultado mostra a lista atual de capturas instantâneas no cluster. O processo de cópia de segurança da CSI cria um instantâneo de cada disco do Cassandra. O número de instantâneos gerados deve corresponder ao número total de pods do Cassandra no cluster.

Restaure uma cópia de segurança

Use este processo para restaurar uma cópia de segurança de CSI gerada anteriormente. Para obter informações gerais sobre como restaurar cópias de segurança e uma vista geral do processo, consulte a página de vista geral do restauro.

Para iniciar uma restauração de uma cópia de segurança de CSI, siga as instruções para a restauração híbrida de região única não CSI, mas use estes valores no bloco restore no seu overrides.yaml. Consulte a tabela de referência das propriedades de cópia de segurança para mais informações sobre cada valor e a configuração de restauro de exemplo para ver um exemplo.

  • enabled: defina como true para ativar o restauro da cópia de segurança referenciada com a data/hora snapshotTimestamp.
  • snapshotTimestamp: indique a data/hora de uma cópia de segurança de CSI anterior.
  • pullPolicy na imagem: definida como Always.

Para encontrar o valor de snapshotTimestamp a restaurar, execute este comando para obter a lista de instantâneos disponíveis:

kubectl get volumesnapshot -n APIGEE_NAMESPACE
Na lista devolvida, os nomes das capturas de ecrã contêm a indicação de tempo:
pvc-us-west2-b-20220803004907-47beff0e306d8861
Neste exemplo, a data/hora é 20220803004907.

Exemplo de configuração de restauro

Esta secção mostra as partes relacionadas com o restauro de um ficheiro overrides.yaml de exemplo.
cassandra:
  hostNetwork: false
  replicaCount: 3
  storage:
    storageclass: standard-rwo
    capacity: 100Gi
  image:
    pullPolicy: Always

  restore:
    enabled: true
    snapshotTimestamp: "20220908222130"
    cloudProvider: "CSI"
    image:
      pullPolicy: Always

Migre para a cópia de segurança e o restauro da CSI

Se não tiver usado anteriormente a cópia de segurança e o restauro híbridos, pode seguir as instruções em Configure as cópias de segurança de CSI para criar novas cópias de segurança de CSI sem os passos desta secção. Estes passos explicam como migrar da solução de cópia de segurança e restauro não CSI para as cópias de segurança CSI.

  1. Gere uma nova cópia de segurança através do método de cópia de segurança não CSI configurado atualmente.
  2. Altere a configuração da cópia de segurança no ficheiro overrides.yaml híbrido para usar as substituições da cópia de segurança do CSI, conforme mostrado na configuração de cópia de segurança de exemplo.
  3. Aplique as alterações no ficheiro overrides.yaml:
    helm upgrade datastore apigee-datastore/ \
      --namespace APIGEE_NAMESPACE \
      --atomic \
      -f OVERRIDES_FILE.yaml
    
  4. Valide a tarefa de cópia de segurança:
    kubectl get cronjob -n APIGEE_NAMESPACE
  5. Após a conclusão de uma tarefa de cópia de segurança, verifique se foram criadas capturas instantâneas. O número de instantâneos gerados deve ser equivalente ao número de nós do Cassandra na instância híbrida.
    kubectl get volumesnapshot -n APIGEE_NAMESPACE