Ambiente com Redundância
Last updated
Last updated
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.
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)
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.
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
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.
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.
Seguem etapas adicionais a serem realizadas após a execução dos procedimentos já descritos anteriormente.
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
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
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
Decorrente das interações necessárias para que os servidores operem de forma conjunta, é necessário que sejam realizadas algumas liberações de firewall.
Primário(1.1.1.1)
Secundário(2.2.2.2)
TCP 5432
Secundário(2.2.2.2)
Primário(1.1.1.1)
TCP 5432
Primário(1.1.1.1)
Servidor SNMP
Vai depender da Configuração do Servidor
Secundário(2.2.2.2)
Primário(1.1.1.1)
TCP 443
