Tem alguns "data sheet", ou seja, literalmente, folha de dados, que são tão resumidos que mal se obtém as especificações técnicas de um produto. Mas esse "data sheet" da fabricante RedFone sobre o seu produto foneBridge é diferente.
Ele é conciso, mas o suficientemente claro para expor a questão da alta disponibilidade quando o produto foneBridge é inserido na solução com Asterisk. Embora seja um texto de natureza técnico-comercial próprio de "data sheet", mas possui uma didática clara e concisa sobre a abordagem de alta disponibilidade do Asterisk quando entra no contexto de integração do produto deles, principalmente para quem é iniciante, ele é bem didático. Por isso, esse material mereceu um lugar no meu blog com status de um artigo interessante sobre alta disponibilidade Asterisk, com uma versão para o português.
Qualquer pessoa sem muito conhecimento técnico sobre o assunto vai entender facilmente o conceito HA. O original em inglês pode ser acessado diretamente do link: http://www.red-fone.com/assets/documents/HA_Whitepaper.pdf. Isso só poderia ser coisa de empresa Americana!!
Cordialmente
Cléviton Mendes de Araújo
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
Inúmeras 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 usabilidade (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 acesso com terminação T1/E1 for implementado externamente ao servidor, o foneBRIDGE vai funcionar desacoplado da limitação de se ter um único servidor e quando ele for combinado com o conjunto apropriado de ferramentas poderá ser implementado para fornecer um mecanismo de 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 indica, '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 patch´s 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 por si só a capacidade de fazer elegantemente o failover para um servidor, então, quando 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 como parte da rede Ethernet e não presa a qualquer cartão PCI ou a um único servidor, acrescenta capacidade adicional a conexão T1/E1 de uma implementação Asterisk ser simplificada e pode se conseguir pouco ou nenhum downtime das 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 recursos iniciais do seu 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 antes quando o sistema crescer devido ao acréscimo de novos usuários e de linhas 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 que inclui 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.
Nenhum comentário:
Postar um comentário