Ambiente com Redundância

Informações Importantes

Em instalações com redundância, existem alguns passos manuais adicionais que devem ser executados. Verifique atentamente cada um dos pontos apresentados.

Uma questão importante em relação a ambientes redundantes, é que a instalação é realizada de forma diferente nos servidores secundários. Ou seja, NÃO se deve clonar a instalação do servidor principal e achar que automaticamente o servidor clonado irá operar adequadamente como secundário.

Isso acontece porque os dados precisam estar sincronizados entre as bases de dados. Para garantir a sincronização de forma segura, evitando qualquer inconsistência nos dados, somente a base de dados do servidor principal opera em modo escrita.

A Figura apresentada ilustra o cenário. A base de dados no servidor secundário opera em modo somente leitura. Toda vez que o usuário está no servidor secundário e realiza alguma operação que envolve escrita na base de dados, o servidor secundário se comunica com o primário e pede para o primário realizar a escrita. Tudo que é escrito/alterado no banco de dados do servidor principal é então replicado para o banco de dados secundário.

Executando

O processo inicial de instalação do ambiente redundante é idêntico a uma instalação simples (ver seção 8.3). A diferença começa a partir da pergunta 4. Nela deve ser indicado que se trata de ambiente redundante e as perguntas seguintes irão ser distintas conforme o servidor sendo instalado (se é o servidor primário ou secundário)

Pergunta 4.

A pergunta apresentada na sequência é para saber se seu ambiente é redundante ou não. A resposta apresentada no exemplo a seguir considera que SIM, é um ambiente redundante.

Você está utilizando um ambiente de alta disponibilidade:

1 - Sim

2 - Não

Escolha uma das opções: 2

O valor de uso de ambiente de alta disponibilidade (caso haverá mais de um servidor) realmente é "1"? (s/n) s

Após a pergunta 4, as perguntas serão distintas conforme o servidor.

Conforme ilustração, dados adicionais a respeito dos servidores são solicitados no caso de ambientes redundantes. E para o servidor secundário, é necessário preencher dados específicos necessários para a replicação da base. mais detalhes a seguir.

Configuração Servidor Primário

Siga os passos a seguir se for a instalação do servidor primário.

Pergunta associada a servidores. Deve ser indicado qual servidor se trata e na sequência os dados dos servidores primário e secundário.

No que se refere à configuração do seu ambiente, esse é o servidor:

1 - Primário/Principal

2 - Secundário

Escolha uma das opções: 1

O valor de Servidor que está sendo configurado realmente é "1"? (s/n) s

Digite o endereco IP do servidor primário: 11.11.11.11

O valor de IP realmente é "11.11.11.11"? (s/n) s

Digite o FQDN alternativo para o servidor primário (exemplo: idpprimario.instituicao.br): primario.instituicao.br

O valor de hostname realmente é "primario.instituicao.br"? (s/n) s

Digite o endereco IP do servidor secundário: 22.22.22.22

O valor de IP realmente é "22.22.22.22"? (s/n) s

Na sequência, conforme a figura apresentada, devem ser respondidas as perguntas 5 a 7 já apresentadas anteriormente

Configuração Servidor Secundário

Siga os passos a seguir se for a instalação do servidor secundário.

ATENÇÃO, o primário deve ter sido instalado ANTES de iniciar a instalação do secundário.

Pergunta associada a servidores. Deve ser indicado qual servidor se trata e na sequência os dados dos servidores primário e secundário.

No que se refere à configuração do seu ambiente, esse é o servidor:

1 - Primário/Principal

2 - Secundário

Escolha uma das opções: 2

O valor de Servidor que está sendo configurado realmente é "2"? (s/n) s

Digite o endereco IP do servidor primário: 11.11.11.11

O valor de IP realmente é "11.11.11.11"? (s/n) s

Digite o FQDN alternativo para o servidor primário (exemplo: idpprimario.instituicao.br): primario.instituicao.br

O valor de hostname realmente é "primario.instituicao.br"? (s/n) s

Digite o endereco IP do servidor secundário: 22.22.22.22

O valor de IP realmente é "22.22.22.22"? (s/n) s

Pergunta de dados de replicação da base. Deve ser indicado a senha de replicação da base.

O local onde a informação deve ser verificada é indicado pelo script (arquivo /opt/dashboard/database.properties do servidor primário, no atributo database.repl.password.

Copiar o valor contido e preencher aqui. O valor da senha é um valor aleatório gerado no momento da instalação do primário. O valor abaixo é um mero exemplo. Verifique o valor no servidor primário conforme instruções.

Digite a senha para sincronizacao da base (veja no servidor primario em /opt/dashboard/database.properties o valor configurado em database.repl.password: kuj65RGe

O valor de Senha realmente é "kuj65RGe"? (s/n) s

Na sequência a instalação do secundário já é iniciada.

Pontos de Atenção

Depois de responder as perguntas (seja no primário ou no secundário), deve ser executado os procedimentos adicionais indicados nas seções Configurações Importantes - CAPTCHA (para os dois servidores). A configuração da seção SMTP associada ao servidor de e-mail é necessária somente no servidor primário. Após a execução dos procedimentos em questão, seguir com os procedimentos apresentados a seguir.

Etapas Adicionais

Seguem etapas adicionais a serem realizadas após a execução dos procedimentos já descritos anteriormente.

Cópia de chaves de segurança

No servidor principal, em /opt/shibboleth-idp/credentials, copie os arquivos a seguir para a mesma pasta no servidor secundário (sobrescrevendo no secundário os arquivos existentes):

● cafesealer.kver

● cafesealer.jks

Acerto de /etc/hosts

Em ambientes redundantes, precisamos garantir que os componentes em cada servidor se comuniquem entre si de forma adequada. Como as configurações são realizadas através da definição do FQDN, caso o DNS resolva um IP diferente a cada vez, isso pode ser um problema.

Assim é necessário editar o arquivo /etc/hosts de cada servidor para forçar que o servidor sempre resolva para o próprio IP.

Exemplo: Suponha IDP redundante de FQDN idp.instituicao.br que tem o servidor principal com IP 1.1.1.1 e o IP do servidor secundário seja 2.2.2.2. Para este caso hipotético, teremos:

Servidor principal - /etc/hosts terá uma entrada como:

1.1.1.1 idp.instituicao.br

Servidor secundário - /etc/hosts terá uma entrada como:

2.2.2.2 idp.instituicao.br

Certificado SSL

Nos casos em que o servidor secundário se comunica com o primário, é necessário um FQDN alternativo para o servidor primário. Este FQDN alternativo é utilizado para que o secundário possa se comunicar com o primário.

Ou o certificado do servidor primário precisa ter também este FQDN alternativo ou ele precisa ser um wildcard que comporte tanto o FDQN principal e secundário.

Exemplo, suponha que o FQDN do IDP seja “idp.istituicao.br” e o FQDN alternativo para o servidor primário seja “idpprimario.instituicao.br”. Assim o certificado deve responder tanto por “idp.inistuicao.br” como por “idpprimario.instiutuicao.br” (através de definiçao de alternative names no certificado) ou o certificado deve ser um wildcard como “*.instituicao.br”

É importante lembrar, que nestes casos, o Apache do primário deve ser configurado para responder aos dois domínios. Assim, é necessário adicionar na configuração do apache algo como:

ServerName idp.istituicao.br

ServerAlias idpprimario.instituicao.br

Libertações de Firewall

Decorrente das interações necessárias para que os servidores operem de forma conjunta, é necessário que sejam realizadas algumas liberações de firewall.

Last updated