Tutorial: Instalar uma Central telefónica baseada em Elastix (P. II)
As redes de dados têm evoluído significativamente nos últimos anos, abrindo portas a que novos serviços assentem nestas infraestruturas. Se há uns anos atrás as chamadas telefónicas eram efectuadas exclusivamente pelo serviço telefónico tradicional, hoje em dia os serviços de voz assentam também em redes de dados.
Depois de termos ensinado a instalar o Elastix, hoje vamos aprender a criar um cluster usando o Pacemaker.
Para a configuração de um cluster vamos criar duas máquinas virtuais com Elastix. Neste caso, vamos fazer um clone da máquina criada no primeiro tutorial, com as seguintes alterações:
- Nome da máquina, neste caso vamos utilizar Elastix node 2 e reiniciar o MAC address quando clonamos a máquina virtual, para ser atribuído um novo IP à nova máquina.
- No clone type escolhemos full clone.
Após criada a segunda máquina, iniciamos os dois nós para começarmos a configuração.
Primeiro vamos anotar os IPs dos dois nós. No nosso caso, vamos ter a seguinte configuração:
- Nó 1: 192.168.1.123
- Nó 2: 192.168.1.124
- IP virtual dos nós: 192.168.1.115 (configurado mais à frente no tutorial)
Nó 1:
Nó 2:
Nota: para todos os comandos que vamos executar a seguir deverão ter privilégios de root. Caso tenham criado um outro utilizador, necessitam do comando sudo antes de cada comando.
De seguida, vamos necessitar de editar alguns ficheiros de texto. Por omissão, esta distribuição não vem com o editor nano, mas quem quiser instalar basta executar o comando:
yum install nano |
Editamos o ficheiro /etc/hosts e adicionamos as seguintes linhas:
- “IP_primeiro_nó” node1.pplware.com node1
- “IP_segundo_nó” node2.pplware.com node2
Gravamos o ficheiro e saímos. Reiniciamos ambas as máquinas para assumirem o novo nome dado anteriormente.
De seguida, vamos definir alguns parâmetros no apache editando o ficheiro /etc/httpd/conf.d/status.conf. Depois devem proceder as seguintes alterações:
<Location /server-status> SetHandler server-status Order Deny,Allow Deny from all Allow from 127.0.0.1 </Location> |
Guardamos o ficheiro e saímos do editor.
Instalar Pacemaker
Vamos então instalar o Pacemaker usando o comando:
yum install pacemaker pcs |
Após a instalação estar finalizada, executamos os seguintes comandos:
systemctl start pcsd.service
systemctl enable pcsd.service |
Sendo o primeiro para iniciar o pcs daemon, que é utilizado para sincronizar o Corosync e o segundo para iniciar o pcs daemon cada vez que a máquina é iniciada.
Depois de instalados estes pacotes, foi criado um novo utilizador no sistema com o nome hacluster.
Alteramos a palavra passe desse utilizador com: passwd hacluster
De seguida, verificamos se a firewall está activa usando o comando:
firewall-cmd --state |
Caso não esteja, activamos com o seguinte comando:
systemctl start firewalld.service |
Agora é a vez de adicionar uma excepção na firewall para o Cluster
firewall-cmd --permanent --add-service=high-availability |
e reiniciamos a firewall com o comando:
firewall-cmd –reload |
A partir deste momento, os dois nós já devem conseguir comunicar. Portanto vamos executar os comandos seguintes apenas no primeiro nó.
Configuramos a autenticação do cluster com o comando:
pcs cluster auth node1 node2 |
No campo Username colocamos “hacluster” e no campo Password a palavra passe definida anteriormente.
Se esta informação estiver correta, devemos receber a mensagem:
- node1: Authorized
- node2: Authorized
De seguida, vamos correr o comando:
pcs cluster setup --name clusterPplware node1 node2 |
Se tudo correr bem, devem receber uma mensagem semelhante à imagem apresentada em baixo:
Após isto, a configuração do Corosync foi criada. Podem aceder ao ficheiro criado em /etc/corosync/corosync.conf
Podemos então iniciar o cluster com: pcs cluster start --all e de seguida executar os comandos:
Para o Corosync e o Pacemaker iniciarem quando as máquinas forem iniciadas. Estes dois últimos comandos devem ser executados nos dois nós.
Podemos verificar se o Cluster está a funcionar correctamente com o comando:
pcs status |
Após terminados com sucesso os passos anteriores, vamos desativar o STONITH e o Quorum. STONITH é uma sigla que significa “Shoot The Other Node In The Head”, ou seja, quando um Cluster não consegue determinar o estado de um dos seus nós, é aplicada uma técnica denominada de “Fencing” que faz o Cluster voltar ao seu estado normal.
Node Level Fencing garante que um nó não utiliza todos os recursos.
Como a configuração do Node Level Fencing varia bastante para cada ambiente(Windows, Mac OS,...), vamos desactivá-lo para este tutorial.
Um Quorum é criado quando mais de metade dos seus nós estão online. O comportamento por omissão é de parar o Cluster quando não se verifica esse estado, por isso vamos também desativá-lo.
- pcs property set stonith-enabled=false
- pcs property set no-quorum-policy=ignore
Estas alterações são necessárias nos dois nós.
Criação de IP Virtual (floating IP)
De seguida, vamos criar um IP virtual o qual será partilhado pelos dois nós e pelo qual poderemos aceder à configuração do Elastix.
Para tal, executamos o comando apenas no primeiro nó:
pcs resource create Cluster_PPLWARE ocf:heartbeat:IPaddr2 ip=192.168.1.115 cidr_netmask=24 op monitor interval=20s |
- Onde atribuímos o IP virtual que desejarmos, neste caso atribuímos 192.168.1.115
- Neste caso colocamos cidr_netmask=24, mas este valor depende da rede.
- O interval=20s é o tempo de espera entre a verificação que cada nó faz para ver o estado do outro nó.
Com pcs status verificamos se o Cluster_PPLWARE foi iniciado
Reiniciamos ambos os nós para assumirem as últimas configurações
Após o reiniciarmos ambos os nós, caso o Cluster não esteja iniciado basta activá-lo com o comando:
sudo pcs resource enable Cluster_PPLWARE |
E está feita a configuração do Cluster. Podemos comprovar entrando no IP virtual que atribuímos e será apresentada uma página do tipo:
E está feita esta configuração também. Como referido, com este tutorial passamos a ter um serviço de alta disponibilidade com dois nós a servir o mesmo serviço.
No terceiro e último tutorial vamos ensinar a criar extensões e configurar softphones.
Este artigo tem mais de um ano
Óptimo post.
Nunca configurei clusters e tenho algumas perguntas
Ele vai syncronizar os 2 nodes, correcto ?
Isto é, se fizer configurações em um dos nodes (alterar configurações no elastix: adicionar telefones, sip accounts, .. ) ele vai fazer essas alterações nos 2 nós ?
Como garante o pacemaker que as alterações são feitas no vários nós (ao nível do sistema de ficheiros, serviços , rede, …) ?
Obrigado
Não.
O pacemaker é para criar redundancia de servidores (nodes) ou de serviços.
Ex.: se um dos nodes for abaixo, o outro ganha o IP do que ficou offline, e começa a funcionar e a gerir os serviços.
Neste exemplo, se o Node 1 ficar offline, o Node 2 retoma o IP do Node 1, e todos os equipamentos na rede que estava a utilizar o Node 1 vao continuar a trabalhar como se nada se tivesse passado (ou quase, pois há uma latencia de segundos entre o recovery do Node1 para Node 2).
Para redundancia de serviços, é muito semelhante, só que ao invés de criares uma regra para um IP (como é o caso do exemplo), crias para um serviço. Se o serviço Asterisk for abaixo no Node 1, o Node 2 detecta e inicia o serviço Asterisk.
Pacemaker + Corosync é muito util para fazer uma série de regras: crias IPs virtuais (VIPs) partilhados por ambos os nodes, crias serviços partilhados por ambos os nodes. Se o Node 1, que é o node que detém o VIP activo, perder o serviço Asterisk, o Node 2 inicia o serviço Asterisk e retoma o VIP para ele próprio. Assim, na rede, os telefones continuam a apontar para o mesmo IP (ou VIP neste caso) e passa tudo despecebido. No máximo, as chamadas vão abaixo na altura em que o VIP muda de servidor.
Para sincronização de dados entre servidores utiliza outro serviço como o fsniper (embora não seja mto certinho…) , onde o colocas a “ouvir” determinadas pastas ou ficheiros, e sempre que houver uma alteraçao, executa um script.
Ex.:
watch {
# watch a directory for new files
/var/www/html {
recurse = true
# matches all files
* {
handler = echo %%; /root/.clustersync/sync_www_folders
}
}
/etc/ {
recurse = true
* { handler = echo $$; /root/.clustersync/sync_etc_folders }
}
}
Tb podes utilizar crontab + rsync , muito embora seja muito rudimentar….
Muito obrigado pela resposta. Esclarecedora.
Pelo que entendi se um servidor Elastix for a baixo, as chamadas activas perdem-se, correcto ?
Porque não utilizar “Hyper-V replica” ou algo parecido ?
quais as vantagens deste sistema ?
nao há solução nenhuma que te permita mudar de servidor Asterisk e manter a chamadas activas, e isso por motivos técnicos: o telefone SIP está sempre registado num dos servidores (mesmo que seja via VIP), e como tal a chamada e o stream de dados passa por esse servidor. Se o servidor for abaixo, o stream é interrompido e o registo do telefone SIP também.
Pior ainda quando esse servidor está ligado fisicamente à rede fixa (BRI, E1, whatever) : se o stream de voz passa de e para a rede fixa só vai passar por 1 servidor, pois é esse servidor que está ligado à rede fixa e que tem o canal de voz activo e que reencaminha (routing) para o telefone SIP e vice versa. Se esse servidor for abaixo, o canal da rede fixa também vai, e perdes sempre a chamada.
Imagina que tens 2 clusters com 2 servidores cada a fazer redundancia. Estás a fazer transferencia de dados entre 1 cluster e outro, e como tal, entre um servidor de um cluster para outro servidor do outro cluster.
O que acontece se desligares o cabo de rede ou de power de um desses servidores? A transferencia é interrompida e só podes voltar a fazê-la se reiniciares essa transferencia com os outros servidores disponiveis.
Infelizmente não há milagres!
HyperV pode te fazer a mesma coisa que o Pacemaker e Corosyn, quanto a redundancia, mas nunca te vai resolver a queda de chamadas se uma das VMs for abaixo 😉
Além disso, não sou nada apologista em utilizar VMs para sistemas de VoIP 😉
show muito bom
Não faltará 1 passo no tutorial ? Ou escapou-me algo …
“No campo Username colocamos “hacluster” e no campo Password a palavra passe definida anteriormente.”
Onde é que esta password foi definida? E qual é, ou como se define, sff?
Obrigado.
Boas brnf
Estava na imagem. Já meti em texto.
Não ha nenhuma “central telefónica” POS?
POS?