Ambiente com Redundância
Last updated
Was this helpful?
Last updated
Was this helpful?
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
