Agendar cópias de segurança num servidor remoto

Está a ver a versão 1.12 da documentação do Apigee híbrido. This version is end of life. You should upgrade to a newer version. Para mais informações, consulte Versões suportadas.

Version 1.12 

Versões com suporte:

• v1.15 (mais recente)                        
• v1.14                        
• v1.13                         
• Lista de versões com suporte

Versões sem suporte:

• v1.12                         
• v1.11
• v1.10                                      
• v1.9
• v1.8                                         
• v1.7
• v1.6
• v1.5
• v1.4
• v1.3
• v1.2
• v1.1

Aviso: as versões do Apigee Hybrid anteriores à 1.12.4 têm um problema conhecido que afeta as cópias de segurança que usam os fornecedores de nuvem HYBRID ou GCP. Verifique a opção Limpar instantâneos residuais para saber se a sua configuração é afetada e quais os passos necessários para a resolução.

Esta página descreve como agendar cópias de segurança para o Cassandra sem o Cloud Storage. Neste método, as cópias de segurança são armazenadas num servidor remoto especificado por si, em vez de num contentor do Cloud Storage. O Apigee usa o SSH para comunicar com o servidor remoto.

Tem de agendar as cópias de segurança como tarefas cron. Depois de aplicar uma programação de cópias de segurança ao cluster híbrido, é executado periodicamente um trabalho de cópia de segurança do Kubernetes de acordo com a programação no plano de tempo de execução. A tarefa aciona um script de cópia de segurança em cada nó do Cassandra no seu cluster híbrido que recolhe todos os dados no nó, cria um ficheiro de arquivo (comprimido) dos dados e envia o arquivo para o servidor especificado no seu ficheiro overrides.yaml.

Nota:

• Tem de garantir que existe espaço suficiente no sistema de ficheiros para as cópias de segurança e ajustar a frequência das cópias de segurança para evitar preencher desnecessariamente o espaço de armazenamento atribuído. O Apigee não dita uma política de retenção para os ficheiros de cópia de segurança. É recomendável criar uma política de retenção para ficheiros adequados à sua instalação.
• A aplicação da configuração de cópia de segurança no cluster existente vai reiniciar os pods do Cassandra.

Os passos seguintes incluem exemplos comuns para concluir tarefas específicas, como criar um par de chaves SSH. Use os métodos adequados à sua instalação.

O procedimento tem as seguintes partes:

• Configure o servidor e o SSH
• Defina o horário e o destino da cópia de segurança

Configure o servidor e o SSH

1. Selecione um servidor de cópia de segurança: escolha um servidor Linux ou Unix com armazenamento adequado para as suas cópias de segurança e certifique-se de que é possível aceder ao mesmo através de SSH a partir do plano de tempo de execução híbrido do Apigee.
2. Configure o servidor SSH: instale um servidor SSH ou confirme se um servidor existente é seguro.
Atenção: por motivos de segurança, certifique-se de que o seu servidor SSH está atualizado.
3. Crie um par de chaves SSH: gere um par de chaves SSH sem uma frase de acesso. Por exemplo:

   ssh-keygen -t rsa -b 4096 -C [e-mail]
     Enter file in which to save the key (/Users/exampleuser/.ssh/id_rsa): $APIGEE_HOME/hybrid-files/certs/ssh_key
     Enter passphrase (empty for no passphrase):
     Enter same passphrase again:
     Your identification has been saved in ssh_key
     Your public key has been saved in ssh_key.pub
     The key fingerprint is:
     SHA256:DWKo334XMZcZYLOLrd/8HNpjTERPJJ0mc11UYmrPvSA [e-mail]
     The key's randomart image is:
     +---[RSA 4096]----+
     |          +.  ++X|
     |     .   . o.=.*+|
     |    . o . . o==o |
     |   . . . =oo+o...|
     |  .     S +E oo .|
     |   . .   .. . o .|
     |    . . .  . o.. |
     |     .  ...o ++. |
     |      .. .. +o+. |
     +----[SHA256]-----+

   Em que: [e-mail] é uma string. Qualquer string que siga -C no comando ssh-keygen torna-se um comentário incluído na chave ssh recém-criada. A string de entrada pode ser qualquer string. Quando usa um nome de conta no formato [e-mail], pode identificar rapidamente a conta associada à chave.

   O comando gera dois ficheiros de chave SSH: um ficheiro de chave privada (por exemplo, `ssh_key.rsa`) e um ficheiro de chave pública (por exemplo, `ssh_key.pub`).

   Guarde a chave privada numa localização à qual o plano de tempo de execução possa aceder.

4. Adicione uma conta de utilizador: no servidor de cópia de segurança, crie um utilizador denominado apigee com um diretório principal em /home/apigee. Certifique-se de que o novo utilizador apigee tem um diretório pessoal em /home.
5. Configure o diretório .ssh: no servidor de cópias de segurança, crie um diretório .ssh em /home/apigee/.ssh. Por exemplo:

   cd /home/apigee
         mkdir .ssh
         cd .ssh
         vi authorized_keys

6. Instale a chave pública: coloque a chave pública no ficheiro authorized_keys no diretório /home/apigee/. O diretório de cópia de segurança pode ser qualquer diretório, desde que o utilizador apigee tenha acesso ao mesmo.Cole o conteúdo do ficheiro ssh public key no ficheiro.
7. Valide o acesso SSH: teste a ligação a partir da sua máquina local ou de um nó do cluster:

ssh -i PATH_TO_PRIVATE_KEY_FILE apigee@BACKUP_SERVER_IP

Nota: certifique-se de que consegue aceder ao servidor remoto sem lhe ser pedida uma palavra-passe ou uma frase secreta. Se lhe for pedida uma frase de acesso, regenere o par de chaves SSH sem especificar uma frase de acesso. Caso lhe seja pedida uma palavra-passe, verifique novamente a configuração de SSH no servidor remoto, uma vez que é muito provável que não esteja configurada corretamente.

Defina a programação e o destino da cópia de segurança

Define o horário e o destino das cópias de segurança no ficheiro overrides.yaml.

1. Adicione os seguintes parâmetros ao ficheiro overrides.yaml:

   Parâmetros

   cassandra:
     backup:
       enabled: true
       keyFile: "PATH_TO_PRIVATE_KEY_FILE"
       server: "BACKUP_SERVER_IP"
       storageDirectory: "/home/apigee/BACKUP_DIRECTORY"
       cloudProvider: "HYBRID" # required verbatim "HYBRID" (all caps)
       schedule: "SCHEDULE"

   Exemplo

   cassandra:
     backup:
       enabled: true
       keyFile: "private.key" # path relative to apigee-datastore path
       server: "34.56.78.90"
       storageDirectory: "/home/apigee/cassbackup"
       cloudProvider: "HYBRID"
       schedule: "0 2 * * *"

   Onde:

   Propriedade	Descrição
   backup:enabled	A cópia de segurança está desativada por predefinição. Tem de definir esta propriedade como true.
   backup:keyFile	PATH_TO_PRIVATE_KEY_FILE O caminho no seu sistema de ficheiros local para o ficheiro de chave privada de SSH (denominado ssh_key no passo em que criou o par de chaves SSH). Este caminho tem de ser relativo ao diretório do gráfico apigee-datastore.
   backup:server	BACKUP_SERVER_IP O endereço IP do seu servidor de reserva.
   backup:storageDirectory	BACKUP_DIRECTORY O nome do diretório de cópia de segurança no servidor de cópia de segurança. Tem de ser um diretório em home/apigee (o diretório de cópia de segurança tem o nome cassandra_backup no passo em que criou o diretório de cópia de segurança).
   backup:cloudProvider	HYBRID Para uma cópia de segurança do servidor remoto, defina a propriedade como HYBRID.
   backup:schedule	SCHEDULE A hora em que a cópia de segurança começa, especificada na sintaxe crontab padrão. As horas estão no fuso horário local do cluster Kubernetes. Predefinição: 0 2 * * * Nota: Evite agendar uma cópia de segurança que comece pouco tempo depois de aplicar a configuração da cópia de segurança ao cluster. Quando aplica a configuração da cópia de segurança, o Kubernetes recria os nós do Cassandra. Se a cópia de segurança começar antes do reinício dos nós, a primeira cópia de segurança falha e as cópias de segurança subsequentes são bem-sucedidas.

2. Aplique a configuração da cópia de segurança ao âmbito de armazenamento do seu cluster:

   helm upgrade datastore apigee-datastore/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f OVERRIDES_FILE.yaml
   

   Em que OVERRIDES_FILE é o caminho para o ficheiro de substituições que acabou de editar.

3. Valide a tarefa de cópia de segurança. Por exemplo:

   kubectl get cronjob -n APIGEE_NAMESPACE

   NAME                      SCHEDULE     SUSPEND   ACTIVE   LAST SCHEDULE   AGE
   apigee-cassandra-backup   33 * * * *   False     0        <none>          94s

Inicie uma cópia de segurança manual

As tarefas de cópia de segurança são acionadas automaticamente de acordo com o agendamento cron definido em cassandra.backup.schedule no seu ficheiro overrides.yaml. No entanto, também pode iniciar manualmente uma tarefa de cópia de segurança, se necessário, usando o seguinte comando:

kubectl create job -n APIGEE_NAMESPACE --from=cronjob/apigee-cassandra-backup MANUAL_BACKUP_JOB_NAME

Em que MANUAL_BACKUP_JOB_NAME é o nome de uma tarefa de cópia de segurança manual a ser criada.

Resolução de problemas

1. Teste a ligação a partir de um pod do Cassandra. Tem de garantir que os seus pods do Cassandra conseguem estabelecer ligação ao servidor de cópia de segurança através de SSH:
   1. Inicie sessão na shell do seu pod do Cassandra. Por exemplo:

      kubectl exec -it -n APIGEE_NAMESPACE APIGEE_CASSANDRA_POD -- /bin/bash

      Em que APIGEE_CASSANDRA_POD é o nome de um pod do Cassandra. Altere para o nome do hub a partir do qual quer estabelecer ligação.

   2. Estabeleça ligação por SSH ao servidor de cópia de segurança, usando a chave SSH privada montada no pod do Cassandra e no endereço IP do servidor:

      ssh -i /var/secrets/keys/key apigee@BACKUP_SERVER_IP

      Nota: pode ver um aviso neste momento a indicar que a impressão digital do servidor não é reconhecida e a perguntar se quer continuar. Pode continuar nesse comando e validar a configuração de SSH.
2. Se tiver problemas ao aceder ao seu servidor remoto a partir do pod do Cassandra, verifique novamente a configuração do SSH no servidor remoto e certifique-se de que a atualização do armazenamento de dados foi bem-sucedida.
3. Pode verificar se o Cassandra usa a chave privada correta executando o seguinte comando enquanto tem sessão iniciada no seu pod do Cassandra e comparar o resultado com a chave privada que criou:

   cat /var/secrets/keys/key