Agendar cópias de segurança num servidor remoto

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

  1. Designe um servidor Linux ou Unix para as suas cópias de segurança. Este servidor tem de estar acessível através de SSH a partir do plano de tempo de execução híbrido do Apigee. Tem de ter armazenamento suficiente para as suas cópias de segurança.
  2. Configure um servidor SSH no servidor ou certifique-se de que tem um servidor SSH seguro configurado.
  3. Crie um par de chaves SSH e armazene o ficheiro de chave privada num caminho acessível a partir do plano de tempo de execução híbrido. Tem de usar uma palavra-passe em branco para o seu par de chaves, caso contrário, a cópia de segurança falha. 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.

  4. Crie uma conta de utilizador no servidor de cópias de segurança com o nome apigee. Certifique-se de que o novo utilizador apigee tem um diretório pessoal em /home.
  5. No servidor de cópia de segurança, crie um diretório .ssh no novo diretório /home/apigee.
  6. Copie a chave pública (ssh_key.pub no exemplo anterior) para um ficheiro com o nome authorized_keys no novo diretório /home/apigee/.ssh. Por exemplo: 
    cd /home/apigee
mkdir .ssh
cd .ssh
vi authorized_keys
  7. No servidor de cópias de segurança, crie um diretório de cópias de segurança 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. Por exemplo: 
    cd /home/apigee
mkdir cassandra-backup
  8. Teste a ligação. Tem de garantir que os seus pods do Cassandra se podem ligar 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 pod a partir do qual quer estabelecer ligação.

    2. Estabeleça ligação por SSH ao servidor de cópia de segurança através da 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

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 de Helm

    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 * * *"

    Exemplo apigeectl

    cassandra:
  backup:
    enabled: true
    keyFile: "home/exampleuser/apigee-hybrid/hybrid-files/service-accounts/private.key"
    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).
    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 é iniciada, especificada na sintaxe crontab padrão. As horas estão no fuso horário local do cluster Kubernetes. Predefinição: 0 2 * * *
  2. Aplique a configuração da cópia de segurança ao âmbito de armazenamento do seu cluster:

    Leme

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

    apigeectl

    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE.yaml --datastore

    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
     
    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 a agenda cron definida 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 este valor para o nome do pod 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
  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