Sistemas Operacionais LinuxSistemas operacionais Oracle SolarisSistemas Operacionais AIXSistemas operacionais Mac OS X

Configurando o Cliente de Backup-Archive em um Ambiente em Cluster

Editar on-line

O cliente de backup e archive foi projetado para gerenciar o baclup das unidades de cluster, colocando o cliente de backup e archive no contexto dos grupos de recursos do cluster.

Sobre esta tarefa

A vantagem disso é a possibilidade de se fazer backup de dados de recursos locais (ao contrário de acessar os dados na rede) para maximizar o desempenho da operação de backup e para gerenciar os dados de backup em relação ao grupo de recursos. Portanto, o cliente de backup e archive poderá sempre fazer backup de dados em recursos do cluster como se os dados fossem locais e maximizar o desempenho do backup. Isto assegura que seja feito backup dos dados críticos nas falhas do sistema.

Por exemplo, um ambiente em cluster ativo/ativo possui três hosts físicos no cluster chamados NodeA, NodeB e NodeC.

Os nós possuem as seguintes qualidades:

  • NodeA possui o recurso de cluster com sistemas de arquivos /A1 e /A2
  • NodeB possui os recursos de cluster com sistemas de arquivos /B1 e /B2
  • NodeC possui os recursos de cluster com sistemas de arquivos /C1 e /C2
Nota: NodeA também pode ter dois volumes não clusos, /fs1 e /fs2, que devem ser apoiados.

Para obter um melhor desempenho do backup, talvez você queira que todos os nós do cluster execute os backups dos sistemas de arquivos compartilhados que possuem. Quando ocorre failover de um nó, as tarefas de backup do nó com falha são deslocadas para o nó para o qual ocorreu failover. Por exemplo, quando ocorre failover do NodeA para o NodeB, o backup de /A1 e /A2 é movido para o NodeB.

A seguir, os pré-requisitos necessários antes da configuração do cliente de backup e archive para fazer backup de volumes de cluster e não-cluster:

  • É necessário executar um processo de planejador de cliente de backup e archive separado para cada grupo de recursos que está sendo protegido. Em condições normais, cada nó teria dois processos de planejador: um para os recursos de cluster e outro para os sistemas de arquivos locais. Depois de uma falha, são iniciados processos adicionais do planejador em um nó para proteger os recursos que foram movidos de outro nó.
  • Os arquivos de senha do cliente de backup e archive devem ser armazenados em discos do cluster para que, depois de uma falha, a senha gerada do cliente de backup e archive esteja disponível para o nó de transferência.
  • Os sistemas de arquivos a serem protegidos como parte de um grupo de recursos são definidos utilizando-se a opção de domínio do cliente de backup e archive. A opção de domínio é especificada no arquivo dsm.sys, que também deve ser armazenada em um disco do cluster para que possa ser acessada pelo nó de controle.

Siga as etapas abaixo para configurar o cliente de backup e archive em um ambiente em cluster.

Procedimento

  1. Registre as definições do nó de cliente de backup-archive no servidor IBM® Storage Protect Todos os nós no cluster devem ser definidos no servidor do IBM Storage Protect Se vários recursos de cluster estiverem sendo definidos em um ambiente em cluster para failover independente, nomes de nós exclusivos deverão ser definidos por grupo de recursos. Para a configuração de cluster ativo / ativo de amostra acima, defina três nós (um por recurso), da seguinte forma: (1) Protect: IBM>register node nodeA nodeApw domain=standard, (2) Protect: IBM>register node nodeB nodeBpw domain=standard, (3) Protect: IBM>register node nodeC nodeCpw domain=standard.
  2. Configure o arquivo de opções do sistema do cliente de backup e archive. Cada nó do cluster deve ter sub-rotinas de servidor separadas para cada grupo de recursos do cluster para permitir o backup em cada arquivo dsm.sys respectivo. É necessário assegurar-se de que as sub-rotinas do servidor sejam idênticas nos arquivos de opções do sistema em cada nó. Alternativamente, é possível colocar o arquivo dsm.sys em um local de cluster compartilhado. As sub-rotinas do servidor definidas para fazer backup de volumes em cluster devem ter as seguintes características especiais:
    • A opção nodename deve se referir ao nome do nó cliente registrado no servidor IBM Storage Protect . Se o nome do nó cliente não for definido, o nome do nó assumirá como padrão o nome do host do nó, que pode ser conflitante com outros nomes de nós usados para o mesmo sistema do cliente.
      Importante: Use a opção nodename para definir explicitamente o nó do cliente.
    • A opção tcpclientaddress deve referir-se ao endereço IP do serviço do nó do cluster.
    • A opção passworddir deve referir-se a um diretório nos volumes compartilhados que fazem parte do grupo de recursos do cluster.
    • As opções errorlogname e schedlogname devem referir-se aos arquivos nos volumes compartilhados que fazem parte do grupo de recursos do cluster para manter um único arquivo de log contínuo.
    • Todas as instruções de inclusão/exclusão devem referir-se aos arquivos nos volumes compartilhados que fazem parte do grupo de recursos do cluster.
    • Se você utilizar a opção inclexcl, ela deverá referir-se a um caminho de arquivo nos volumes compartilhados que fazem parte do grupo de recursos do cluster.
    • Os nomes das sub-rotinas identificados com a opção servername devem ser idênticos em todos os sistemas.
  3. É possível configurar outras opções do cliente de backup e archive, conforme necessário. No exemplo a seguir, todos os três nós, NodeA, NodeBe NodeC, devem ter as três estrofes do servidor a seguir em seu arquivo dsm.sys :
    Servername        server1_nodeA
nodename          NodeA
commmethod        tcpip
tcpport           1500
tcpserveraddress  server1.example.com
tcpclientaddres   nodeA.example.com
passwordaccess    generate
passworddir       /A1/tsm/pwd
managedservices   schedule
schedlogname      /A1/tsm/dsmsched.log
errorlogname      /A1/tsm/errorlog.log

Servername        server1_nodeB
nodename          NodeB
commmethod        tcpip
tcpport           1500
tcpserveraddress  server1.example.com
tcpclientaddres   nodeB.example.com
passwordaccess    generate
passworddir       /B1/tsm/pwd
managedservices   schedule
schedlogname      /B1/tsm/dsmsched.log
errorlogname      /B1/tsm/errorlog.log

Servername        server1_nodeC
nodename          NodeC
commmethod        tcpip
tcpport           1500
tcpserveraddress  server1.example.com
tcpclientaddres   nodeC.example.com
passwordaccess    generate
passworddir       /C1/tsm/pwd
managedservices   schedule
schedlogname      /C1/tsm/dsmsched.log
errorlogname      /C1/tsm/errorlog.log
  4. Configure o arquivo de opções do usuário do cliente de backup e archive. O arquivo de opções (dsm.opt) deve residir nos volumes compartilhados no grupo de recursos do cluster. Defina a variável de ambiente DSM_CONFIG para referir-se a esse arquivo. Certise-se de que o arquivo dsm.opt contém as seguintes configurações:
    • O valor da opção servername deve ser a sub-rotina do servidor no arquivo dsm.sys que define parâmetros para fazer backup dos volumes em cluster.
    • Defina para que seja feito backup dos sistemas de arquivos em cluster com a opção domain.
      Nota: Certifique-se de que você defina a opção de domínio no arquivo dsm.opt ou especifique a opção no planejamento ou na linha de comando do cliente de backup-archive. Isso é para restringir operações em cluster a recursos do cluster e operações fora do cluster a recursos fora do cluster.

    No exemplo, nós NodeA, NodeBe NodeC configuram o seu arquivo dsm.opt correspondente e DSM_CONFIG ambiente variável da seguinte forma:

    NodeA: 

1) Set up the /A1/tsm/dsm.opt file:

servername server1_nodeA
domain     /A1 /A2

2) Issue the following command or include it in your user profile:

export DSM_CONFIG=/A1/tsm/dsm.opt

NodeB:

1) Set up the /B1/tsm/dsm.opt file:

servername server1_nodeB
domain     /B1 /B2

2) Issue the following command or include it in your user profile:

export DSM_CONFIG=/B1/tsm/dsm.opt

NodeC:

1) Set up the /C1/tsm/dsm.opt file:

servername server1_nodeC
domain     /C1 /C2

2) Issue the following command or include it in your user profile:

export DSM_CONFIG=/C1/tsm/dsm.opt
  5. Configure as definições de planejamento de cada grupo de recursos do cluster. Após a conclusão da configuração básica, defina os planejamentos automatizados para fazer backup de recursos do cluster para atender aos requisitos de backup. O procedimento ilustra a configuração de planejamento usando o planejador IBM Storage Protect integrado. Se você estiver utilizando um planejador adquirido do fornecedor, consulte a documentação fornecida pelo fornecedor do planejador.
    • Defina um planejamento no domínio de política em que os nós do cluster estejam definidos. Assegure que a janela de inicialização do planejamento seja grande o suficiente para reiniciar o planejamento no nó de failover no caso de um evento de falha e fallback. Isto significa que a duração do planejamento deve ser configurada com um tempo maior do que ele leva para concluir o backup dos dados do cluster para esse nó, sob condições normais.

      Se a reconexão ocorrer dentro da janela de início desse evento, o comando planejado será iniciado novamente. Esse backup incremental planejado reexaminará os arquivos enviados para o servidor antes do failover. O backup "retoma", então, de onde ele parou antes da situação de failover.

      No exemplo a seguir, o planejamento clus_backup é definido no domínio padrão para iniciar o backup às 12h30 A.M. todos os dias com a duração configurada em duas horas (que é o tempo de backup normal para cada dado do nó).
      Protect: IBM>define schedule standard clus_backup action=incr
starttime=00:30 startdate=TODAY  Duration=2
    • Associe o planejamento com os todos os nós do cliente de backup-archive definidos a recursos de cluster de backup, conforme a seguir: (1) Protect: IBM>define association standard clus_backup nodeA, (2) Protect: IBM>define association standard clus_backup nodeB, (3) Protect: IBM>define association standard clus_backup nodeC.
  6. Configure o serviço do planejador para backup. Em cada nó cliente, um serviço de planejador deve ser configurado para cada recurso pelo qual o nó é responsável por fazer backup, em condições normais. A variável de ambiente DSM_CONFIG para cada serviço de planejador de recursos deve ser configurado para se referir ao arquivo dsm.opt correspondente para esse recurso. Para a configuração de amostra, os seguintes scripts shell devem ser criados para permitir que os processos dsmcad sejam iniciados, conforme necessário, a partir de qualquer nó no cluster. 
    NodeA: /A1/tsm/startsched
#!/bin/ksh
export DSM_CONFIG=/A1/tsm/dsm.opt
dsmcad
NodeB: /B1/tsm/startsched
#!/bin/ksh
export DSM_CONFIG=/B1/tsm/dsm.opt
dsmcad
NodeC: /C1/tsm/startsched
#!/bin/ksh
export DSM_CONFIG=/C1/tsm/dsm.opt
dsmcad
  7. Defina o cliente de backup e archive para o aplicativo de cluster. Para continuar o backup do recurso com falha após uma condição de failover, o serviço do planejador IBM Storage Protect (para cada nó cliente do cluster) deve ser definido como um recurso para o aplicativo de cluster para participar do processamento de failover. Isso é necessário para continuar o backup dos recursos com falha a partir do nó que controla o recurso. Se isso não for feito, o backup do recurso com falha ficará incompleto. Os scripts de amostra na etapa 5 podem ser associados aos recursos do cluster para assegurar que sejam iniciados nos nós do cluster enquanto os recursos do disco que estão sendo protegidos são movidos de um nó para o outro. As etapas reais necessárias para configurar o serviço de planejador como um recurso de cluster são específicas para o software de cluster. Consulte a documentação do aplicativo de cluster para obter informações adicionais.
  8. Certifique-se de que a senha para cada nó é gerada e armazenada em cache corretamente no local especificado usando a opção passworddir . Isso pode ser validado executando-se as etapas a seguir:
    1. Valide se cada nó pode se conectar ao servidor IBM Storage Protect sem o prompt de senha É possível fazê-lo executando a interface da linha de comandos do cliente de backup e archive e emitindo o seguinte comando em cada nó:
      #dsmc query session

      Se a submissão de senha for solicitada, digite-a para executar o comando com êxito e execute novamente o comando. Na segunda vez, o comando deve ser executado sem o prompt de senha. Se a senha for solicitada, verifique a configuração.

    2. Validar que os outros nós no cluster possam iniciar sessões para o servidor IBM Storage Protect para o nó com falha. Isso pode ser feito executando-se os mesmos comandos, conforme descrito na etapa acima, nos nós de backup. Por exemplo, para validar se NodeB e NodeC pode iniciar uma sessão como NodeA no evento de failover sem aviso para a senha, execute os seguintes comandos em NodeB e NodeC
      #export DSM_CONFIG=/A1/tsm/dsm.opt
#dsmc query session

      O prompt de senha poderá aparecer agora, mas é improvável. Se aparecer, a senha não foi armazenada no local compartilhado corretamente. Verifique a configuração da opção passworddir utilizada para NodeA e siga as etapas de configuração novamente.

    3. Assegure-se de que os planejamentos sejam executados corretamente pelos nós. Você pode acionar um planejamento, configurando o horário de início do planejamento para now. Lembre-se de reconfigurar a hora de início após a conclusão do teste.
      Protect: IBM>update sched standard clus_backup starttime=now
    4. Failover e fallback entre nodeA e nodeB, enquanto nodeA fica no meio do backup e a janela inicial do planejamento, ainda é válida. Verifique se o backup incremental continua em execução e conclua com êxito após o failover e o fallback.
    5. Emita-se o comando abaixo para fazer com que a senha de um nó (nodeA) expirar. Assegure-se de que o backup continue normalmente em operações normais do cluster, assim como o failover e o fallback:
      Protect: IBM>update node nodeA forcep=yes
  9. Configure o cliente de backup e archive para fazer backup de recursos locais.
    1. Defina nós clientes no servidor IBM Storage Protect . Nunca deve-se fazer backup ou archive de recursos locais utilizando-se nomes de nós definidos para fazer backup de dados do cluster. Se os volumes locais não definidos como recursos de cluster forem submetidos a backup, nomes de nós separados (e instâncias do cliente separadas) deverão ser usados para volumes em cluster e não em cluster.

      No exemplo a seguir, suponha que apenas NodeA tenha sistemas de arquivos locais /fs1 e /fs2 para serem apoiados. Para gerenciar os recursos locais, registre um nó NodeA_local no servidor IBM Storage Protect : Protect: IBM>register node nodeA_local nodeA_localpw domain=standard

    2. Adicionar uma estrofe separada no arquivo de opções do sistema de cada nó dsm.sys que deve fazer backup de recursos locais com as seguintes características especiais:
      • O valor da opção tcpclientaddress deve ser o nome do host ou o endereço IP local. Este é o endereço IP utilizado para o tráfego principal para/do nó.
      • Se o cliente fizer backup e restaurar volumes não em cluster sem estar conectado ao cluster, o valor da opção tcpclientaddress deverá ser o endereço IP de inicialização. Esse é o endereço IP utilizado para iniciar o sistema (nó) antes de unir novamente o cluster:
        Example stanza for NodeA_local: 

Servername        server1_nodeA_local
nodename          nodeA_local
commmethod        tcpip
tcpport           1500
tcpserveraddress  server1.example.com
tcpclientaddres   nodeA_host.example.com
passwordaccess    generate
managedservices   schedule
    3. Defina o arquivo de opções do usuário dsm.opt em um caminho que está em um recurso não em clusão.
      • O valor da opção servername deve ser a sub-rotina do servidor no arquivo dsm.sys que define parâmetros para fazer backup de volumes fora do cluster.
      • Utilize a opção de domínio para definir que seja feito backup dos sistemas de arquivos fora do cluster.
      Nota: Certifique-se de que você defina a opção de domínio no arquivo dsm.opt ou especifique a opção no planejamento ou na linha de comandos do cliente de backup-archive, a fim de restringir as operações de backup-arquivo a volumes não agrupados.

      No exemplo a seguir, nodeA usa o arquivo /home/admin/dsm.opt a seguir e configura o ambiente DSM_CONFIG para se referir a /home/admin/A1.dsm.opt.

      Conteúdo de /home/admin/A1.dsm.opt
      servername ibm_nodeA_local
domain     /fs1 /fs2


export DSM_CONFIG=/home/admin/A1.dsm.opt
    4. Defina e configure um planejamento para fazer backup incremental de sistemas de arquivo não armazenados em cluster.
      Protect: IBM>define schedule standard local_backup action=incr 
starttime=00:30 startdate=TODAY  Duration=2
      Associe o planejamento a todos os nós clientes de archive de backup definidos para fazer backup de recursos fora do cluster.
      Protect: IBM>define association standard nodeA_local
  10. Restaure os dados do sistema de arquivo em cluster. É feito backup de todos os volumes de um recurso de cluster no nó de destino definido para esse recurso de cluster. Se for necessário restaurar os dados residentes em um volume de cluster, a restauração poderá ser feita a partir do nó cliente que possui o recurso de cluster no momento da restauração. O cliente de backup-archive deve utilizar o mesmo arquivo de opções de usuário (dsm.opt) que foi usado durante o backup para restaurar os dados. Não há necessidade de requisitos adicionais de configuração para restauração de dados em volumes de cluster.
  11. Restaure os dados do sistema de arquivos local. O backup dos volumes fora do cluster é feito na configuração do nome de nó separado para operações fora do cluster. Para restaurar esses dados, o cliente de backup e archive deve usar o mesmo arquivo de opções do usuário, dsm.opt, que foi usado durante o backup. No exemplo, configure a variável de ambiente DSM_CONFIG para referir-se a /home/admin/A1.dsm.opt antes de realizar uma restauração do cliente para o nó local nodeA_local.