Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

7.2. Criando um arquivo de Configuração de Cluster Básica

Desde que o hardware de cluster, o Red Hat Enterprise Linux e o software do Complemento de Alta Disponibilidade estão instalados, você pode criar um arquivo de configuração (/etc/cluster/cluster.conf) e inicie a execução do Complemento de Alta Disponibilidade. Como um ponto inicial somente, esta seção descreve como criar um esqueleto do arquivo de configuração de cluster sem fence, domínios failover e serviços de Alta Disponibilidade. Seções subsequentes descrevem como configurar estas partes do arquivo de configuração.

Importante

Este é somente um passo para criar um arquivo de configuração de cluster; o arquivo resultante não possui qualquer fence e não é considerado ser uma configuração suportada.
Os seguintes passos descrevem como criar e configurar um esqueleto do arquivo de configuração do cluster. Finalmente, o arquivo de configuração para seu cluster irá variar de acordo com o número de nós, o tipo de fence, o tipo e número de serviços de Alta Disponibilidade e outros requerimentos especificos do local.
  1. Em qualquer nó no cluster, crie o /etc/cluster/cluster.conf, usando o modelo do exemplo em Exemplo 7.1, “cluster.conf Exemplo: Configuração Básica”.
  2. Opcional se você está configurando um cluster de dois nós, você pode adicionar a seguinte linha ao arquivo de configuração para permitir que um nó único mantenha quorum (por exemplo, se um nó falhar):
    <cman two_node="1" expected_votes="1"/>
    Quando você adicionar ou remover a opção two_node do arquivo cluster.conf, você precisa reiniciar o cluster para que esta mudança seja efetuada ao atualizar a confiugração. Para obter informações sobre como atualizar uma configuração de cluster, consulte o Seção 8.4, “Atualizando uma Configuração”. Para um exemplo de especificação da opção two_node consulte o Exemplo 7.2, “cluster.conf Exemplo: Configuração de Nós Básica”.
  3. Especifique o nome do cluster e o número da versão da configuração usando os atributos do cluster: name e config_version (consulte o Exemplo 7.1, “cluster.conf Exemplo: Configuração Básica” ou Exemplo 7.2, “cluster.conf Exemplo: Configuração de Nós Básica”).
  4. Na seção clusternodes, especifique o nome do nó e a ID do nó para cada nó usando os atributos do clusternode: name e nodeid.
  5. Salve o /etc/cluster/cluster.conf.
  6. Valide o arquivo no esquema de cluster (cluster.rng) rodando o comando ccs_config_validate. Por exemplo:
    [root@example-01 ~]# ccs_config_validate 
    Configuration validates
    
  7. Propague o arquivo de configuração no /etc/cluster/ em cada nó no cluster. Por exemplo, você poderia propagar o arquivo a outros nós no cluster usando o comando scp.

    Nota

    Propagando o arquivo de configuração do cluster desta maneira é necessário na primeira vez que o cluster é criado. Uma vez o cluster é instalado e rodando, o arquivo de configuração do cluster pode ser propagado usando o cman_tool version -r. É possível usar o comando scp. Além disso, você deve rodar o ccs_config_validate se você propagar um arquivo de configuração atualizado pelo scp.

    Nota

    Enquanto existem outros elementos e atributos presentes no exemplo do arquivo de configuração (por exemplo o fence e o fencedevices, não há necessidade de popula-los agora.) Procedimentos subsequentes neste capítulo fornecem informações sobre especificar outros elementos e atributos.
  8. Inicie o cluster. Em cada nó no cluster, execute o seguinte comando:
    service cman start
    Por exemplo:
    [root@example-01 ~]# service cman start
    Starting cluster: 
       Checking Network Manager...                             [  OK  ]
       Global setup...                                         [  OK  ]
       Loading kernel modules...                               [  OK  ]
       Mounting configfs...                                    [  OK  ]
       Starting cman...                                        [  OK  ]
       Waiting for quorum...                                   [  OK  ]
       Starting fenced...                                      [  OK  ]
       Starting dlm_controld...                                [  OK  ]
       Starting gfs_controld...                                [  OK  ]
       Unfencing self...                                       [  OK  ]
       Joining fence domain...                                 [  OK  ]
    
  9. Em qualquer nó no cluster, rode o cman_tools nodes para verificar que os nós estão funcionando como membros no cluster (mostrados como "M" na coluna de estado "Sts"). Por exemplo:
    [root@example-01 ~]# cman_tool nodes
    Node  Sts   Inc   Joined               Name
       1   M    548   2010-09-28 10:52:21  node-01.example.com
       2   M    548   2010-09-28 10:52:21  node-02.example.com
       3   M    544   2010-09-28 10:52:21  node-03.example.com
    
  10. Se o cluster estiver rodando, vá para Seção 7.3, “Configuração de Fence”.

7.2.1. Exemplos de Configurações Básicas

Exemplo 7.1, “cluster.conf Exemplo: Configuração Básica” e Exemplo 7.2, “cluster.conf Exemplo: Configuração de Nós Básica” (para um cluster de dois nós) cada fornece um exemplo muito básico de arquivo de configuração como um ponto de início. Procedimentos subsequentes neste capítulos fornecem informações sobre configurar o fence dos serviços de Alta Disponibilidade.

Exemplo 7.1. cluster.conf Exemplo: Configuração Básica


<cluster name="mycluster" config_version="2">
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="node-03.example.com" nodeid="3">
         <fence>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>
   </fencedevices>
   <rm>
   </rm>
</cluster>

Exemplo 7.2. cluster.conf Exemplo: Configuração de Nós Básica


<cluster name="mycluster" config_version="2">
   <cman two_node="1" expected_votes="1"/>
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>
   </fencedevices>
   <rm>
   </rm>
</cluster>

7.2.2. O valor concensus para o totem em um cluster de dois nós.

Quando você cria um cluster de dois nós e você não pretende adicionar nós adicionais ao cluster depois, então você pode omitir o valor consensus na tag totem no arquivo cluster.conf para que o valor consensus seja calculado automaticamente. Quando o valor consensus é calculadoautomaticamente, as seguintes regras são usadas:
  • Se existem dois nós ou menos, o valor consensus será (token * 0.2), com um teto de 2000 milisegundos e um piso de 200 milisegundos.
  • Se existem três ou mais nós, o valor consensus será (token + 2000 milisegundos)
Se você permitir que o utilitário cman configure a expiração de seu consensus desta maneira e então mudar em um outro momento de dois para três nós (ou mais) isso irá requerer a reinicialização de um cluster, já que a expiração do consensus precisará mudar para um valor maior baseado na expiração do token.
Se você estiver configurando um cluster de dois nós e pretende atualizar no futuro para um número maior de dois nós, você pode sobrescrever a expiração consensus para que então uma reinicialização de cluster não seja necessária quando mover de dois para três (ou mais) nós. Isto pode ser feito no cluster.conf conforme se segue:

<totem token="X" consensus="X + 2000" />

Note que o análise da configuração não calcula X + 2000 automaticamente. Um número inteiro deve ser usado em vez de uma equação.
A vantagem de usar uma expiração de consensus otimizada para clusters de dois nós é que o período de failover geral é reduzido para o processo de dois nós, já que o consensus não é uma função de expiração de token.
Note que para a auto detecção de dois nós no cman, o número de nós físicos é o que importa e não a presença da directiva two_node=1 no arquivo cluster.conf.