Como programar backups em um servidor remoto

Nesta página, descrevemos como programar backups do Cassandra sem o Cloud Storage. Neste método, os backups são armazenados em um servidor remoto especificado por você, em vez de um bucket do Cloud Storage. A Apigee usa SSH para se comunicar com o servidor remoto.

É necessário programar os backups como jobs cron. Depois que uma programação de backup é aplicada ao cluster híbrido, um job de backup do Kubernetes é executado periodicamente de acordo com a programação no plano de ambiente de execução. O job aciona um script de backup em cada nó do Cassandra no cluster híbrido que coleta todos os dados no nó, cria um arquivo arquivado (compactado) e envia o arquivo ao servidor especificado no arquivo overrides.yaml.

As etapas a seguir incluem exemplos comuns de como concluir tarefas específicas, como criar um par de chaves SSH. Use os métodos apropriados para a instalação.

O procedimento tem as seguintes partes:

Configurar o servidor e o SSH
Definir a programação e o destino do backup

Configurar o servidor e o SSH

Designe um servidor Linux ou Unix para seus backups. Esse servidor precisa ser acessível via SSH pelo plano do ambiente de execução da Apigee híbrida. Ele deve ter armazenamento suficiente para seus backups.
Configure um servidor SSH ou verifique se há um servidor SSH seguro configurado.
Atenção: por motivos de segurança, verifique se o servidor SSH está atualizado.

Crie um par de chaves SSH e armazene o arquivo da chave privada em um caminho acessível no plano do ambiente de execução híbrido. Use uma senha em branco para o par de chaves ou o backup falhará. 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 após -C no comando ssh-keygen se torna um comentário incluído na chave ssh recém-criada. A string de entrada pode ser qualquer string. Quando você usa um nome de conta no formato exampleuser@example.com, é possível identificar rapidamente qual conta corresponde à chave.

Crie uma conta de usuário no servidor de backup com o nome apigee. Verifique se o novo usuário apigee tem um diretório principal em /home.
No servidor de backup, crie um diretório .ssh no novo diretório /home/apigee.
Copie a chave pública (ssh_key.pub no exemplo anterior) em um arquivo chamado authorized_keys no novo diretório /home/apigee/.ssh. Por exemplo:
```
cd /home/apigee
mkdir .ssh
cd .ssh
vi authorized_keys
```
No servidor de backup, crie um diretório de backup dentro do diretório /home/apigee/. O diretório de backup pode ser qualquer diretório, desde que o usuário apigee tenha acesso a ele. Por exemplo:
```
cd /home/apigee
mkdir cassandra-backup
```
Para testar a conexão, acesse o servidor remoto com a chave SSH recém-gerada da sua máquina local ou de um nó de cluster. O comando deve ser parecido com isto:
```
ssh -i PATH_TO_PRIVATE_KEY_FILE apigee@BACKUP_SERVER_IP
```
Observação: verifique se você consegue acessar o servidor remoto sem que seja necessário digitar uma senha ou uma senha longa. Se você receber uma solicitação para inserir uma senha longa, gere novamente o par de chaves SSH sem especificar uma senha longa. Se uma senha for solicitada, verifique novamente a configuração do SSH no servidor remoto, porque é provável que ela não esteja definida corretamente.

Definir a programação e o destino do backup

Você define a programação e o destino dos backups no arquivo overrides.yaml.

Adicione os seguintes parâmetros ao seu arquivo 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: "/Users/exampleuser/apigee-hybrid/hybrid-files/service-accounts/private.key"
    server: "34.56.78.90"
    storageDirectory: "/home/apigee/cassbackup"
    cloudProvider: "HYBRID"
    schedule: "0 2 * * *"

Em que:

Propriedade	Descrição
`backup:enabled`	O backup está desativado por padrão. É preciso definir essa propriedade como `true`.
`backup:keyFile`	`PATH_TO_PRIVATE_KEY_FILE` O caminho no sistema de arquivos local para o arquivo de chave privada SSH (chamado `ssh_key` na etapa em que você criou o par de chaves SSH).
`backup:server`	`BACKUP_SERVER_IP` O endereço IP do servidor de backup.
`backup:storageDirectory`	`BACKUP_DIRECTORY` O nome do diretório de backup no servidor de backup. Precisa ser um diretório dentro de `home/apigee` (o diretório de backup se chama `cassandra_backup` na etapa em que você criou o diretório de backup).
`backup:cloudProvider`	`GCP/HYBRID` Para um backup do Cloud Storage, defina a propriedade como `GCP`. Por exemplo, `cloudProvider: "GCP"`. Para um backup remoto do servidor, defina a propriedade como `HYBRID`. Por exemplo, `cloudProvider: "HYBRID"`.
`backup:schedule`	`SCHEDULE` O horário de início do backup, especificado na sintaxe padrão de crontab. As horas estão no fuso horário local do cluster do Kubernetes. Padrão: `0 2 * * ` Observação:* Evite programar um backup que inicie pouco tempo depois de aplicar a configuração de backup ao cluster. Quando você aplica a configuração de backup, o Kubernetes recria os nós do Cassandra. Se o backup começar antes da reinicialização dos nós, o primeiro vai falhar e os próximos serão transmitidos.

Aplique a configuração de backup ao escopo de armazenamento do cluster:
```
helm upgrade datastore apigee-datastore/ \
  --namespace apigee \
  --atomic \
  -f OVERRIDES_FILE.yaml
```
Observação: se você vir um erro dizendo Error: UPGRADE FAILED: "datastore" has no deployed releases, substitua upgrade por install e repita o comando.

Em que OVERRIDES_FILE é o caminho para o arquivo de substituição que você acabou de editar.

Verifique o job de backup. Por exemplo:

kubectl get cronjob -n apigee

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

Solução de problemas

Teste a conexão de um pod do Cassandra. Verifique se os pods do Cassandra podem se conectar ao servidor de backup usando SSH:
1. Faça login no shell do pod do Cassandra. Por exemplo:
```
kubectl exec -it -n apigee APIGEE_CASSANDRA_DEFAULT_0 -- /bin/bash
```
  Em que APIGEE_CASSANDRA_DEFAULT_0 é o nome de um pod do Cassandra. Altere para o nome do pod a partir do qual você quer se conectar.
2. Conecte-se por SSH ao servidor de backup usando a chave SSH privada ativa o pod e o endereço IP do servidor do Cassandra:
```
ssh -i /var/secrets/keys/key apigee@BACKUP_SERVER_IP
```
  Observação: talvez você veja um aviso dizendo que a impressão digital do servidor não é reconhecida e pergunta se você quer continuar. Continue nesse comando e verifique a configuração do SSH.
Se você tiver problemas para acessar o servidor remoto no pod do Cassandra, verifique novamente a configuração do SSH no servidor remoto e verifique se a atualização do repositório de dados foi concluída.
Para verificar se o Cassandra usa a chave privada correta, execute o comando a seguir enquanto estiver conectado ao pod do Cassandra e compare a saída com a chave privada que você criou:
```
cat /var/secrets/keys/key
```