Tutorial: Instalar uma Central telefónica baseada em Elastix (P. II)

9 Comentários

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.

elastix_018_thumb


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.

e_000

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:

e_001

Nó 2:

e_002

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

e_003

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>

e_004

Guardamos o ficheiro e saímos do editor.

 

Instalar Pacemaker

Vamos então instalar o Pacemaker usando o comando:

yum install pacemaker pcs

e_005

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.

e_006

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

cluster_03

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

e_007

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.

e_008

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:

e_009

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.

e_010

Podemos verificar se o Cluster está a funcionar correctamente com o comando:

pcs status

e_011

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.

e_012

 

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

e_13

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_014

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.

http://videos.sapo.pt/cAM0qJ1KrBA7nJWnnuSY

 

No terceiro e último tutorial vamos ensinar a criar extensões e configurar softphones.

Partilhar:
Tags:

Comentários

9

Deixe um comentário

O seu endereço de email não será publicado. Campos obrigatórios marcados com *

  1. Avatar de Pedro
    Pedro

    Ó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

    1. Avatar de Duda
      Duda

      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….

      1. Avatar de Pedro
        Pedro

        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 ?

        1. Avatar de Duda
          Duda

          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 😉

  2. Avatar de Elton
    Elton

    show muito bom

  3. Avatar de brnf
    brnf

    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.

    1. Avatar de Pedro Pinto

      Boas brnf

      Estava na imagem. Já meti em texto.

  4. Avatar de Estou a usar o w10 porque fui obrigado
    Estou a usar o w10 porque fui obrigado

    Não ha nenhuma “central telefónica” POS?