Esta página foi traduzida pela API Cloud Translation.

Agendar cópias de segurança num servidor remoto

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.

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

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.
Configure o servidor SSH: instale um servidor SSH ou confirme se um servidor existente é seguro.

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 exampleuser@example.com
  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 exampleuser@example.com
  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: exampleuser@example.com é 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 exampleuser@example.com, 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.

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.
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
```
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.
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

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.

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.

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.

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

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.
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.
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
```