1.4. Gerenciamento de Serviço de Alta Disponibilidade

O Gerenciamento de Serviço de Alta Disponibilidade fornece a habilidade de criação e gerencia a alta disponibilidade nos serviços de cluster em um cluster Red Hat. A chave componente para o gerenciamento de serviço de alta disponibilidade num cluster Red Hat, rgmanager, implementa a falha fria para aplicações off-the-shelf ( fora da prateleira ). Em um cluster Red Hat, a aplicação é configurada com outros recursos para formar um serviço de cluster de alta disponibilidade. Um serviço de cluster de alta disponibilidade pode falhar de um para outro nó de cluster sem nenhuma interrupção aparente para clientes de cluster. A falha do serviço de cluster pode ocorrer caso um nó de cluster falhar, ou se um administrador de sistema de cluster mover o serviço de cluster de um para outro nó de cluster. ( por exemplo, para uma interrupção planejada de um nó de cluster ).

Para criar um serviço de alta disponibilidade, você deve configurá-lo no arquivo de configuração de cluster. O serviço de cluster compreende os recursos de cluster. Os recursos de cluster são obstáculos construídos que você pode criar e gerenciar num arquivo de configuração de cluster — por exemplo, um endereço IP, um script de inicialização de aplicação, ou um Red Hat GFS de partição dividido.

You can associate a cluster service with a failover domain. A failover domain is a subset of cluster nodes that are eligible to run a particular cluster service (refer to Figura 1.9, “Domínios de Falha”).

Um serviço de cluster pode executar apenas um nó de cluster, de cada vez, para manter a integridade de dados. Você pode especificar a prioridade da falha num domínio de falha. A especificação da prioridade da falha consiste em designar o nível de prioridade para cada nó, num domínio de falha. O nível de prioridade determina a ordem de falha — especificando o nó em que o serviço de cluster deve falhar. Caso você não especifique a prioridade de falha, um serviço de cluster poderá falhar em qualquer nó de seu domínio de falha. Além disso, você pode especificar se um serviço de cluster é restrito para atuar nos nós de seu domínio de falha associado. ( Quando associado a um domínio de falha sem restrição, o serviço cluster pode iniciar qualquer nó de cluster, num evento onde o membro do domínio de falha não é disponível. )

In Figura 1.9, “Domínios de Falha”, Failover Domain 1 is configured to restrict failover within that domain; therefore, Cluster Service X can only fail over between Node A and Node B. Failover Domain 2 is also configured to restrict failover with its domain; additionally, it is configured for failover priority. Failover Domain 2 priority is configured with Node C as priority 1, Node B as priority 2, and Node D as priority 3. If Node C fails, Cluster Service Y fails over to Node B next. If it cannot fail over to Node B, it tries failing over to Node D. Failover Domain 3 is configured with no priority and no restrictions. If the node that Cluster Service Z is running on fails, Cluster Service Z tries failing over to one of the nodes in Failover Domain 3. However, if none of those nodes is available, Cluster Service Z can fail over to any node in the cluster.

Figura 1.10, “Web Server Cluster Service Example” shows an example of a high-availability cluster service that is a web server named "content-webserver". It is running in cluster node B and is in a failover domain that consists of nodes A, B, and D. In addition, the failover domain is configured with a failover priority to fail over to node D before node A and to restrict failover to nodes only in that failover domain. The cluster service comprises these cluster resources:

Os clientes podem acessar o serviço de cluster através do endereço IP 10.10.10.201, capacitando a interação com o aplicativo do servidor da web, httpd-content. O aplicativo httpd-content usa o sistema de arquivo gfs-content-webserver. Caso o nó B falhasse, o serviço de cluster content-webserver falharia o nó D. Se o nó D não estivesse disponível e também falhasse, o serviço falharia o nó A. A falha poderia aparecer sem nenhuma interrupção aparente para os clientes de cluster. O cliente de cluster poderia ser acessível de um outro nó de cluster por meio do mesmo endereço, pois este foi falhado anteriormente.