Este artigo foi publicado em Julho no blog do Cleviton Mendes de Araujo (http://clevitonmendes.blogspot.com/2008/07/alta-disponibilidade-ao-modo-fonebridge.html) . Achei interessante reproduzir aqui. Ele é uma tradução do White-Paper da RedFone, empresa que produz os equipamentos FoneBridge http://www.red-fone.com/assets/documents/HA_Whitepaper.pdf. Os produtos da Redfone agora podem ser adquiridos no Brasil no ShopVoIP, http://www.shopvoip.com.br/index.php?cPath=4_5803
Reproduzido conforme licença Creative Commons, mais detalhes verificar a origem.
Introdução
Obter um sistema confiável, tolerante a falhas e de alta disponibilidade com o ASTERISK® tem sido difícil e até quase impossível especialmente do ponto de vista da rede telefonia tradicional (PRI/MFC-R2/TDM). Um conjunto de ferramentas oriundas do mundo IP existiu ao longo dos anos para permitir aos integradores à capacidade de fornecer o mecanismo de tolerância à falha no lado da rede de voz sobre IP de suas implementações. Até hoje, contudo, o fornecimento de failover rápido, confiável e robusto nas redes tradicionais de telefonia (T1/E1) tem sido quase inexistente. O produto foneBRIDGE preenche esse vazio para permitir aos Gestores de TI e Integradores de Sistemas implementarem o Asterisk em ambientes de demandas importantes onde o tempo de downtime (interrupção do sistema devido a falha ou para manutenção) é um luxo que um empresa simplesmente não pode se permitir.
Alta Disponibilidade
Um cem número de ferramentas abertas e comerciais estão disponíveis para construção de clusters Linux tolerante a falhas de alta disponibilidade. O objetivo geral de implementação HA (alta disponibilidade) em um ambiente servidor é fornecer confiabilidade, disponibilidade e funcional (RAS). No modelo tradicional de implementação do Asterisk, a conectividade com rede de telefonia legada (T1/E1) é fornecida por meio de cartões de interface instalado no barramento PCI em um único servidor. Nesse cenário a integridade e a disponibilidade dos sistemas como um todo fica então limitado a confiabilidade desse único servidor. Para muitas empresas, assumir tal premissa em um sistema de missão crítica como de voz é inaceitável.
Quando um ponto de terminação T1/E1 for colocado externamente, o foneBRIDGE fica desacoplado da limitação de um único servidor e quando for combinado com o conjunto apropriado de ferramentas pode ser implementado para fornecer o mecanismo failover rápido e automático dentro de um cluster de servidores.
O conjunto de ferramentas mais comum usado para fornecer essa funcionalidade quando se associa o par foneBRIDGE e o Asterisk é a ferramenta 'heartbeat' do projeto Linux-HA (www.linux-ha.org). Como o nome diz, 'heartbeat' monitora o estado de 2 ou mais Nós (servidores) em um cluster Asterisk. Se ele detectar uma falha, por exemplo, quando um Nó primário pára de responder as trocas de mensagens heartbeat, ele executa um script que permite que ele execute o failover rapidamente para um servidor secundário. Tudo isso é feito transparentemente e sem a intervenção de usuário.
Figura: Exemplo de cluster de servidores Asterisk rodando heartbeat para Alta Disponibilidade no Linux com o foneBRIDGE2.
Restabelecimento Rápido
Com o foneBRIDGE, a execução de failover rápido e a recuperação do sistema podem ocorrer em questões de segundos, e não em minutos ou horas. Apesar das opções de re-configurações rápidas do foneBRIDGE, nós podemos programá-lo durante a operação através das ferramentas de alta disponibilidade para que ele comece a rotear o fluxo TDM e as ligações para o servidor secundário (de standby) em menos de um segundo. Some-se a isso o lapso de tempo que ele gasta para o servidor iniciar o Asterisk e limpar os alarmes de circuitos e o seu servidor de standby para que ele possa ficar operacional e possa tratar as ligações em menos de 3 segundos, tudo transparentemente e sem intervenção do administrador.
Uptime Durante Manutenção e Atualizações
Além do mais, existem momentos em que é necessário desativar um servidor para aplicação de pach ou para atualização de software. Com o foneBRIDGE, o administrador do servidor pode executar o failover manualmente (ou seja, fazer o switchover) para um servidor de backup e manter o sistema de voz operando normalmente enquanto se executa atualizações ou se aplica patch no servidor principal. Essa funcionalidade única também proporciona elegantemente por si só a capacidade de fazer o failover para um servidor onde, então, podem-se fazer testes de homologação antes da colocação efetiva em produção de uma nova liberação de código ou funcionalidades e também no evento de descoberta de um bug ou de um problema que poderia colocar em risco a integridade das operações do sistema quando em produção que o administrador do sistema pode facilmente fazer o failback para um servidor principal com segundos de downtime somente.
Escalabilidade
Com a conectividade colocada externamente, e colocado na Ethernet e não prendida a qualquer cartão PCI ou a um único servidor, acrescenta capacidade T1/E1 adicional a uma implementação Asterisk é simplificada e pode ser conseguido com pouco ou nenhum downtime as operações.
Melhores Práticas HA
• Teste seu plano de discagem, funcionalidade de PABX, desempenho de sistema e tudo sobre qualidade de ligação antes de colocar em produção. Tente emular o ambiente de produção montando um segundo servidor Asterisk para atuar como um link T1/E1 de telecom e usá-lo para gerar e receber ligações que chegam de suas máquinas em produção. Estresse bastante a máquina para tentar determinar quais são os limites críticos dos seus recursos iniciais do sistema. Conhecendo o que sua instalação é capaz antes de colocá-la em produção ajudará você evitar quaisquer coisas do tipo não tinha pensado nisso quando o sistema cresce devido ao acréscimo de novos usuários e de linhas de troncos T1/E1.
• Padronize sua plataforma de hardware isso anda de mãos dadas com o ponto acima. Uma vez você tenha superado o problema de avaliação de desempenho das capacidades e deficiências do seu servidor e do hardware relacionado e tenha chegado a um ambiente de produção funcionando com qualidade, documente tudo que foi feito até a esse ponto. Anote os parâmetros da BIOS, opções de boot do kernel, versões de aplicações, etc... Se você pensa fazer ampliação adicional do mesmo sistema faça previsão das necessidades de seu hardware e invista em uma pequena reserva sobressalente de hardware que você vá precisar. O mercado de hardware servidor é um eterno processo evolutivo. O servidor Dell, HP, IBM, etc. que você comprou hoje não será o mesmo muito provavelmente amanhã independentemente do tipo de modelo, especificações de sistema, etc... Se você decidir seguir a direção de atualização do fabricante do seu servidor então é aconselhável fazer testes de desempenho completo.
• Coloque e retire de operação seus servidores diariamente. Se estiver trabalhando em um cluster simples com dois servidores rodando em um modo Ativo/Passivo force a execução do failover às noites quando conveniente para garantir que ambos servidores estejam devidamente operacionais. Isso ajudará você a identificar quaisquer problemas potenciais de hardware antes mesmo da necessidade de executar failover durante uma falha de hardware no servidor principal. Isso também permite a você melhor utilizar seu investimento em hardware do seu servidor.
• Monitore pro-ativamente seus servidores para antever problemas potenciais. Cacti, Nagios, Zenoss, monit são todas ferramentas excelentes de monitoração de software livre. O Asterisk-1.4x agora inclui suporte snmp para permitir uma perspectiva mais granular de monitoração mais de perto do daemon da aplicação Asterisk.
• Ferramentas de replicação/sincronização de Cluster - DRBD - fornece espelhamento de disco compreensivo em um cluster de servidores. O Rsync e o csync2 são fáceis de gerenciar e mais conveniente se o objetivo for simplesmente espelhar alguns diretórios e não partições inteiras.
Obter um sistema confiável, tolerante a falhas e de alta disponibilidade com o ASTERISK® tem sido difícil e até quase impossível especialmente do ponto de vista da rede telefonia tradicional (PRI/MFC-R2/TDM). Um conjunto de ferramentas oriundas do mundo IP existiu ao longo dos anos para permitir aos integradores à capacidade de fornecer o mecanismo de tolerância à falha no lado da rede de voz sobre IP de suas implementações. Até hoje, contudo, o fornecimento de failover rápido, confiável e robusto nas redes tradicionais de telefonia (T1/E1) tem sido quase inexistente. O produto foneBRIDGE preenche esse vazio para permitir aos Gestores de TI e Integradores de Sistemas implementarem o Asterisk em ambientes de demandas importantes onde o tempo de downtime (interrupção do sistema devido a falha ou para manutenção) é um luxo que um empresa simplesmente não pode se permitir.
Alta Disponibilidade
Um cem número de ferramentas abertas e comerciais estão disponíveis para construção de clusters Linux tolerante a falhas de alta disponibilidade. O objetivo geral de implementação HA (alta disponibilidade) em um ambiente servidor é fornecer confiabilidade, disponibilidade e funcional (RAS). No modelo tradicional de implementação do Asterisk, a conectividade com rede de telefonia legada (T1/E1) é fornecida por meio de cartões de interface instalado no barramento PCI em um único servidor. Nesse cenário a integridade e a disponibilidade dos sistemas como um todo fica então limitado a confiabilidade desse único servidor. Para muitas empresas, assumir tal premissa em um sistema de missão crítica como de voz é inaceitável.
Quando um ponto de terminação T1/E1 for colocado externamente, o foneBRIDGE fica desacoplado da limitação de um único servidor e quando for combinado com o conjunto apropriado de ferramentas pode ser implementado para fornecer o mecanismo failover rápido e automático dentro de um cluster de servidores.
O conjunto de ferramentas mais comum usado para fornecer essa funcionalidade quando se associa o par foneBRIDGE e o Asterisk é a ferramenta 'heartbeat' do projeto Linux-HA (www.linux-ha.org). Como o nome diz, 'heartbeat' monitora o estado de 2 ou mais Nós (servidores) em um cluster Asterisk. Se ele detectar uma falha, por exemplo, quando um Nó primário pára de responder as trocas de mensagens heartbeat, ele executa um script que permite que ele execute o failover rapidamente para um servidor secundário. Tudo isso é feito transparentemente e sem a intervenção de usuário.
Figura: Exemplo de cluster de servidores Asterisk rodando heartbeat para Alta Disponibilidade no Linux com o foneBRIDGE2.Restabelecimento Rápido
Com o foneBRIDGE, a execução de failover rápido e a recuperação do sistema podem ocorrer em questões de segundos, e não em minutos ou horas. Apesar das opções de re-configurações rápidas do foneBRIDGE, nós podemos programá-lo durante a operação através das ferramentas de alta disponibilidade para que ele comece a rotear o fluxo TDM e as ligações para o servidor secundário (de standby) em menos de um segundo. Some-se a isso o lapso de tempo que ele gasta para o servidor iniciar o Asterisk e limpar os alarmes de circuitos e o seu servidor de standby para que ele possa ficar operacional e possa tratar as ligações em menos de 3 segundos, tudo transparentemente e sem intervenção do administrador.
Uptime Durante Manutenção e Atualizações
Além do mais, existem momentos em que é necessário desativar um servidor para aplicação de pach ou para atualização de software. Com o foneBRIDGE, o administrador do servidor pode executar o failover manualmente (ou seja, fazer o switchover) para um servidor de backup e manter o sistema de voz operando normalmente enquanto se executa atualizações ou se aplica patch no servidor principal. Essa funcionalidade única também proporciona elegantemente por si só a capacidade de fazer o failover para um servidor onde, então, podem-se fazer testes de homologação antes da colocação efetiva em produção de uma nova liberação de código ou funcionalidades e também no evento de descoberta de um bug ou de um problema que poderia colocar em risco a integridade das operações do sistema quando em produção que o administrador do sistema pode facilmente fazer o failback para um servidor principal com segundos de downtime somente.
Escalabilidade
Com a conectividade colocada externamente, e colocado na Ethernet e não prendida a qualquer cartão PCI ou a um único servidor, acrescenta capacidade T1/E1 adicional a uma implementação Asterisk é simplificada e pode ser conseguido com pouco ou nenhum downtime as operações.
Melhores Práticas HA
• Teste seu plano de discagem, funcionalidade de PABX, desempenho de sistema e tudo sobre qualidade de ligação antes de colocar em produção. Tente emular o ambiente de produção montando um segundo servidor Asterisk para atuar como um link T1/E1 de telecom e usá-lo para gerar e receber ligações que chegam de suas máquinas em produção. Estresse bastante a máquina para tentar determinar quais são os limites críticos dos seus recursos iniciais do sistema. Conhecendo o que sua instalação é capaz antes de colocá-la em produção ajudará você evitar quaisquer coisas do tipo não tinha pensado nisso quando o sistema cresce devido ao acréscimo de novos usuários e de linhas de troncos T1/E1.
• Padronize sua plataforma de hardware isso anda de mãos dadas com o ponto acima. Uma vez você tenha superado o problema de avaliação de desempenho das capacidades e deficiências do seu servidor e do hardware relacionado e tenha chegado a um ambiente de produção funcionando com qualidade, documente tudo que foi feito até a esse ponto. Anote os parâmetros da BIOS, opções de boot do kernel, versões de aplicações, etc... Se você pensa fazer ampliação adicional do mesmo sistema faça previsão das necessidades de seu hardware e invista em uma pequena reserva sobressalente de hardware que você vá precisar. O mercado de hardware servidor é um eterno processo evolutivo. O servidor Dell, HP, IBM, etc. que você comprou hoje não será o mesmo muito provavelmente amanhã independentemente do tipo de modelo, especificações de sistema, etc... Se você decidir seguir a direção de atualização do fabricante do seu servidor então é aconselhável fazer testes de desempenho completo.
• Coloque e retire de operação seus servidores diariamente. Se estiver trabalhando em um cluster simples com dois servidores rodando em um modo Ativo/Passivo force a execução do failover às noites quando conveniente para garantir que ambos servidores estejam devidamente operacionais. Isso ajudará você a identificar quaisquer problemas potenciais de hardware antes mesmo da necessidade de executar failover durante uma falha de hardware no servidor principal. Isso também permite a você melhor utilizar seu investimento em hardware do seu servidor.
• Monitore pro-ativamente seus servidores para antever problemas potenciais. Cacti, Nagios, Zenoss, monit são todas ferramentas excelentes de monitoração de software livre. O Asterisk-1.4x agora inclui suporte snmp para permitir uma perspectiva mais granular de monitoração mais de perto do daemon da aplicação Asterisk.
• Ferramentas de replicação/sincronização de Cluster - DRBD - fornece espelhamento de disco compreensivo em um cluster de servidores. O Rsync e o csync2 são fáceis de gerenciar e mais conveniente se o objetivo for simplesmente espelhar alguns diretórios e não partições inteiras.
| < Anterior | Próximo > |
|---|
