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:
- Se não tiver configurado anteriormente uma cópia de segurança híbrida:
- Execute o seguinte comando
create-service-account
para criar uma conta de serviço (SA) do Google Cloud com a funçãoroles/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.
- Gráficos Helm:
- 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.
- Execute o seguinte comando
- Abra o ficheiro
overrides.yaml
. Defina os seguintes parâmetros, conforme mostrado nos ficheiros de substituições de exemplo.- 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.
- enabled: definido como
- 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:
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.kubectl get sc
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
embackup
erestore
comoCSI
.
- cloudProvider: defina
- 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:
- Defina os parâmetros gerais apresentados abaixo no bloco
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 ficheirooverrides.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
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/horasnapshotTimestamp
. - 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
pvc-us-west2-b-20220803004907-47beff0e306d8861
20220803004907
.
Exemplo de configuração de restauro
Esta secção mostra as partes relacionadas com o restauro de um ficheirooverrides.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.
- Gere uma nova cópia de segurança através do método de cópia de segurança não CSI configurado atualmente.
- 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. - Aplique as alterações no ficheiro
overrides.yaml
:helm upgrade datastore apigee-datastore/ \ --namespace APIGEE_NAMESPACE \ --atomic \ -f OVERRIDES_FILE.yaml
- Valide a tarefa de cópia de segurança:
kubectl get cronjob -n APIGEE_NAMESPACE
- 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