Comunicações Unificadas (UC)

Estava pensando escrever um artigo que fosse mais abrangente possível sobre Unified Communications (UC), ou simplesmente, Comunicações Unificadas para postar aqui no meu blog, quando percebi que não era necessário já que havia muitos bons artigos já publicados na Internet e escrever mais um seria trabalho duplicado.

Dentre os muitos artigos encontrados, eu escolhi o publicado por Michael Finneran no site http://searchunifiedcommunications.techtarget.com. Dado a excelente qualidade do seu trabalho e pela grande experiência do autor resolvi traduzi-lo para o português e postá-lo aqui.


Na primeira parte, ele define o conceito de um sistema de Unified Communications (UC).

Em seguida, ele aborda uma implementação real de UC com mobilidade e suas premissas.

E, por último, ele descreve os elementos móveis de uma solução UC.

Início

Prossegue ...

Atualização do Projeto Asterisk

Com três meses de atraso, mas está aqui em português a postagem do Bryant a cerca das diretrizes do projeto Asterisk. Pra quem não sabe o Russell Bryant é um dos homens chave conjuntamente com o engenheiro de projeto Kevin Fleming no projeto Asterisk dentro da Digium.



Apresentação de Atualização do Projeto Asterisk

Fonte Original do texto: http://blogs.asterisk.org/2009/11/10/asterisk-project-update-astricon-2009/, 10/11/2009
Autor: Russell Bryant

Nesses últimos três anos, Eu tive a oportunidade de fazer a apresentação de Atualização do Projeto Asterisk na AstriCon. Realmente é bom olhar para trás e ver o que realizamos no ano passado e compartilhar alguns dos destaques. Este ano, a exposição de Atualização do Projeto Asterisk foi uma apresentação conjunta entre Eu e o Kevin P. Fleming.

Para aqueles que não puderam comparecer à conferência, gostaria de partilhar o que Kevin e Eu tínhamos a dizer. Havia três temas principais que abordamos:

   1. Crescimento da comunidade de Desenvolvedores do Asterisk;
      
   2. Atualizações no processo de liberação do Asterisk;
      
   3. Novas funcionalidades e melhorias na arquitetura.

1. Crescimento da Comunidade de Desenvolvedores

Tronco Asterisk é o ramo principal de desenvolvimento do Asterisk. Aqui é onde estamos preparando as novíssimas mudanças para a próxima grande liberação. Por exemplo, os novos recursos que entram no tronco Asterisk hoje estarão primeiro disponível no Asterisk 1.8 (espere aí um pouco, o que?! 1.8?! É, é isso mesmo. Eu voltarei a ele um pouco!) O tronco Asterisk está muito atarefado. Aqui estão alguns números importantes sobre a atividade no tronco durante o último ano:

    * 2320 entregas;
    * 825 arquivos alterados;
    * 322.148 linhas de código adicionado;
    * 53251 linhas de código removido.

Embora linhas de código não seja um número extremamente significativo por si só, ele pode ser usado junto com outros números para dar alguma luz. Por exemplo, se olharmos para o crescimento das linhas de código ao longo do tempo no tronco Asterisk, nós podemos perceber como a taxa de aumento no tamanho do código base tem crescido com o tempo de vida do projeto.

Gráfico 1 /trunk: Linhas de Código

Este crescimento não é resultado de uma única pessoa. No entanto, se alguém pode me ensinar como aumentar exponencialmente a minha produtividade ao longo do tempo, eu gostaria de falar com você! Um monte de pessoas contribui para o Asterisk. Entre os que escrevem código para o Asterisk, há um grupo seleto que tem acesso direto para fazer mudanças no código fonte (responsáveis). No início do projeto, havia efetivamente um único responsável, Mark Spencer. À medida que o projeto cresceu, foi preciso trabalhar duro com a escala em nossa comunidade de desenvolvimento de modo que pudéssemos processar mais código. O número de responsáveis hoje é superior a 50 (com o número de contribuidores muito maior do que isso). O gráfico seguinte mostra as linhas de código com o passar do tempo por responsável e ajuda a demonstrar como isso mudou ao longo da vida do projeto.

Gráfico 2 /trunk: Linhas de Código

Há inúmeras maneiras pelas quais nós podermos examinar o tamanho do grupo de pessoas que contribuem para o código do Asterisk. Uma maneira é olhar para quantidade de pessoas que já assinaram o contrato de licença de contribuidor ao longo do tempo. Anteriormente, isso era um formulário escrito gerenciado via fax. De algum tempo pra cá, a gestão desses acordos de licença é realizado eletronicamente. A partir desses dados, podemos ver que mais de 800 pessoas se inscreveram para contribuir com o Asterisk nos últimos dois anos.

Gráfico 3

2. Mudanças na Política de Liberação do Asterisk

Política de liberação é um acordo efetivo entre os desenvolvedores e as comunidades de usuários de como e quando as atualizações deverão ser entregues. Existem necessidades de satisfazer ambos os lados. A comunidade de desenvolvimento quer melhorar continuamente o projeto enquanto a comunidade de usuários precisa de software estável para que possam continuar operando de forma definida.

A história de lançamentos do Asterisk começou há 10 anos. Aqui estão algumas datas de liberações durante a primeira metade de vida do projeto:

     • 0.1 – Dezembro de 1999
     • 0.2 – Setembro de 2002
     • 0.3 – Fevereiro de 2003
     • 0.4 – Abril de 2003
     • 0.5 – Setembro de 2003
     • 0.7 – Janeiro de 2004
     • 0.9 – Abril de 2004

Se você estiver lendo isso e já usa o Asterisk há bastante tempo se lembra dessas versões. Muito bom! Isso significa que você se envolveu com o projeto a mais cedo do que Eu. Eu me envolvi no projeto Asterisk em meados de 2004. Quando da primeira Astricon no outono de 2004, Mark Spencer decidiu liberar o Asterisk 1.0 e me pediu para mantê-lo.


Asterisk 1.0:

     • Outono de 2004;
     • Atualizações regulares 1.0.X com correções de bug somente;
     • Finalmente entrou em manutenção de segurança somente, e hoje 
        não mais é mantido.

O desenvolvimento do Asterisk prosseguiu e continuou nos dois anos seguintes, foi então que nós lançamos o Asterisk 1.2 e o Asterisk 1.4. Fizemos algumas mudanças nos processos de desenvolvimento no que diz respeito a como e a quando portar correções de bugs e de como eles eram mesclados entre versões. No entanto, as políticas de liberação no que se refere ao que eram para atualizações e aproximadamente quantas vezes elas eram liberadas não sofreram alterações.


Asterisk 1.2:

     • Liberado em Novembro de 2005;
     • Ainda atualizado com correções de segurança somente.

Asterisk 1.4:

     • Liberado em Dezembro de 2006;
     • Ainda mantido completamente.

Neste ponto do projeto, nós identificamos alguns problemas e decidimos que gostaria de tentar algumas mudanças para melhorar nossas liberações. Nós decidimos modificar nossa abordagem para as liberações da série Asterisk 1.6.X. Nossos objetivos foram:

   1. Liberar atualização de um recurso durante a série 1.6.X a cada 3 meses 
      ou em torno disso;
      
   2. Entregar pequenos incrementos de recursos;
      
   3. Manter a compatibilidade com versões anteriores;
      
   4. Manter cada incremento pelo menos um ano com atualizações 
      regulares de correção de bug rotulado como 1.6.X.Y.

Os problemas identificados que queríamos atacar foram:

   1. Asterisk 1.4 teve um início difícil. Tomou mais tempo do que deveria realmente
      para estabilizar o código.
      
   2. O caminho seguido para gerenciar nossas liberações deixou claro que 
      o tempo para disponibilizar novos recursos ao mercado foi maior do que 
      nós gostaríamos.
      
   3. Algumas das nossas políticas no que diz respeito ao modo como as mudanças 
      foram implementadas mostraram que foi às vezes doloroso atualizações entre 
      versões principais.

Algumas dessas questões nós trabalhamos para resolver no planejamento das libertações da série 1.6.X. E outras, nós temos trabalhado na melhoria dos processos de desenvolvimento.


1. Qualidade da liberação

Nós melhoramos nossos processos de "release candidate". Agora fazemos um trabalho muito melhor para garantir essas liberações, incluindo atualizações de correção de bugs, se faz mais testes antes de serem liberadas.

Nós decidimos que precisaríamos encurtar nosso ciclo de liberação principal de sorte que, quando fosse hora de testar um novo conjunto de recursos, o objetivo fosse mais gerenciável.

Nós implementamos ferramentas e foram implementados processos para revisões mais rigorosas de código quando de alterações antes de serem consolidados.

Nós trabalhamos para educar a equipe de desenvolvimento sobre as melhores práticas e de como evitar problemas corriqueiros encontrados no Asterisk.


2. Tempo longo para disponibilizar ao mercado funcionalidades

Ao encurtar o ciclo de liberação, nós o fizemos de tal modo que os recursos estejam disponíveis o mais rápido possível do que era antes.


3. Atualizações Penosas

Nós abraçamos a retro-compatibilidade muito mais agressivamente do que no passado. Mesmo se houver uma nova maneira melhor de fazer algo, nós a manteremos no suporte se pudermos.

Nós documentamos cada mudança simples que atualizam os usuários entre versões devem estar cientes em UPGRADE.txt.

Na realidade, o Asterisk 1.6.X não funcionou exatamente como nós tínhamos imaginado. Ao passo que nós tínhamos planejado fazer atualizações a cada 3 meses, essas têm sido quase a cada 6 meses.

    * Asterisk 1.6.0 - Outubro de 2008
    * Asterisk 1.6.1 - Abril de 2009
    * Asterisk 1.6.2 - Q4 de 2009

Outro ponto interessante que nós imaginávamos é que as mudanças entre as versões 1.6.X e 1.6.X 1 seria muito menor do que se mostrou na prática. O ciclo longo de liberação e o crescimento da comunidade de desenvolvimento demonstraram que as mudanças no Asterisk entre as atualizações geravam diferenças muito significativas.

Com toda essa história em mente, agora nós chegamos ao presente. Após revisar o modo como s nosso plano para Asterisk 1.6.X estava funcionando, nós decidimos propor algumas mudanças em nossa política de liberações. A primeira mudança foi à introdução do conceito de tipo de liberação na liberação de recursos. O objetivo disso foi passar aos usuários antecipadamente uma percepção mais clara de quanto tempo uma liberação importante do Asterisk vai durar. Existem dois tipos de liberação: a liberação Standard e a LTS.

     1. Standard 
             o Mantida totalmente por 1 ano;
             o Correções de segurança somente por mais 1 ano.

     2. LTS 
             o Mantida totalmente por 4 anos;
             o Correções de segurança somente por mais 1 ano.

A outra mudança nas políticas de liberação que nós gostaríamos de fazer era voltar ao nosso esquema original de versionamento. Nós começamos fornecendo atualizações de recursos rotuladas por 1.6.X porque as mudanças entre as liberações foi imaginado ser bem menor do que um salto entre 1.0 e 1.2, ou entre a 1.2 para a 1.4, etc. Assim, em vez de a próxima liberação ser chamada de 1.6.3, simplesmente vamos chamá-la de 1.8 para melhor refletir o que ela realmente é.

Aqui está a anatomia de um número de versão do Asterisk:

   <Concept>.<Feature>.<Minor>[.Patch]
      
      • Concept – Algo próximo de uma reescrita completa seria necessária 
        para alterar esse;
      
      • Feature – Uma atualização para esse número indica uma mudança 
        para o conjunto de recursos;
      
      • Minor – Esse número reflete uma atualização com correções de bugs somente;
      
      • Patch – Mudanças Triviais (geralmente para uma liberação de segurança).

Aqui está uma tabela de liberações, seu tipo, e as datas associadas:

Tabela: Cronograma

Asterisk 1.8 está atualmente marcado para segundo trimestre de 2010, então ainda temos tempo para fazer alterações. Sinta-se livre para postar seus comentários aqui ou na lista de email Asterisk-dev se você tiver algum feedback!



3. Recursos do Asterisk

Um monte de código foi escrito esse ano. Algumas deles são muito visíveis aos usuários, enquanto outros são alterações de natureza arquitetônica e a fim de propiciar melhorias na implementação subjacente. Aqui está uma lista de algumas coisas legais que foram implementadas. Para obter uma lista completa dos novos recursos, veja o arquivo CHANGES no tronco do Asterisk.


1. Melhorias no Suporte a Fax (Todas as versões)
O suporte a negociação T.38 no Asterisk foi completamente reescrito para funcionar melhor;

Suporte completo para enviar/receber T.38 (suporte a gateway em andamento);

As opções de configuração adicionadas para melhorar a interoperabilidade com implementações em não-conformidade com T.38;

Muitas mudanças foram feitas em chan_dahdi e DAHDI para melhorar a estabilidade de FAX sobre a PSTN;

Centenas de horas foram postas em rigorosos testes de suporte a FAX no Asterisk.


2. Melhorias na Integração XMPP/Jabber (1.8+)
A função JABBER_RECEIVE() foi adicionada para lhe permitir receber mensagens XMPP no dialplan do Asterisk;

Há código em testes para usar XMPP como transporte para eventos distribuídos. Isso permitirá aos servidores Asterisk emparelhados via XMPP compartilhar o estado do dispositivo e informações MWI.


3. Suporte Party ID Connected/Redirecting (1.8+)
Controle total das atualizações ID da parte conectada. O display dos Telefones agora ficará correto após as transferências!;

Suporte ao redirecionando do party_ID significa que você pode ver quando a sua chamada foi encaminhada, ou quando você receber uma chamada que foi encaminhada;

Veja o vídeo da apresentação de Mark Michelson na AstriCon para mais informações sobre essa funcionalidade.


4. Serviços Suplementares de Estabelecimento de Chamada (Espera-se 1.8+)
“Camp on extensions”;

Suporte tanto para CCNR quanto para CCBS;

Suporte genérico no Asterisk, bem como suporte para fazer CCSS sobre SIP e sobre ISDN.


5. Integração de Calendário (1.8+)
Suporte para iCal, CalDAV, Exchange 2003;

Uso de informação de calendário como um provedor de estado de dispositivo;
Acessar estado de calendário no dialplan;

Originação de Chamadas baseados nas entradas de calendários;

Veja o vídeo da apresentação de Terry Wilson na AstriCon para mais informações a respeito dessa funcionalidade.


6. Framework para Eventos de Segurança (1.8+)
Essa infra-estrutura possibilita aos componentes do Asterisk reportar eventos que estão potencialmente relacionados a ataques no sistema;

Esse também inclui um módulo que escreverá eventos de segurança em um arquivo de log em um formato definido que pode ser usado por aplicações externas.


7. Melhorias no SIP TCP/TLS (1.6.X+)
Houve uma série de testes adicionais nessa funcionalidade;

As opções de configuração relacionadas foram melhoradas;

Há relatos de integração bem sucedida com o Microsoft OCS;

Há um trabalho contínuo em curso para tornar essa funcionalidade mais robusta em condições adversas de rede.


8. Atualização do Suporte PSTN
Houve muitas melhorias para suportar BRI via mISDN em todas as versões suportadas do Asterisk;

Suporte nativo BRI em LibPRI e em chan_dahdi foi adicionado ao Asterisk 1.6. Recursos foram trabalhados ativamente nesse código;

Suporte a sinalização MFC/R2 foi adicionado a chan_dahdi usando libopenr2 na versão 1.6.2 e posterior do Asterisk;

Suporte SS7 foi adicionado no Asterisk 1.6.0 e continua a amadurecer.


9. API do Núcleo de Bridging (1.6.2+)
Agora é muito mais fácil de escrever módulos para Asterisk que faz ponte com os canais;

Essa nova infra-estrutura de ponte pode estabelecer conferências entre canais sem precisar da biblioteca DAHDI instalada no sistema;

A nova aplicação de conferência (ConfBridge) foi fornecida, que permite fechar conferência usando essa nova infra-estrutura.


10. API do Núcleo de Temporização (1.6.1+)
Suporte para temporização no Asterisk foi abstraído em vez de depender diretamente de temporizadores DAHDI. Assim, a DAHDI não mais é necessária como fonte de temporização para o Asterisk.


11. Atualização da API do Núcleo de Canal (1.8+)
O gerenciamento da estrutura de dados usado muito amplamente no Asterisk, ast_channel, foi reescrita. Ela agora usa o modelo de objeto astobj2. O resultado é que menos travas atuando sobre esses dados são necessárias, e o código que faz interação nos canais ou buscas é mais eficiente.


12. Atualização da API do Núcleo do Escalonador (1.6.2+)
A API do escalonador é usada no Asterisk quando os componentes precisam escalonar alguma tarefa para acontecer no futuro. Por exemplo, isso é usado para retransmissões de mensagens e expiração dos temporizadores. É usado muito intensamente nos drivers de canal do Asterisk. A API do escalonador passou por duas rodadas de melhorias no desempenho do Asterisk 1.6 (1.6.1 e novamente no 1.6.2). Ao traçar o perfil, os resultados desse trabalho mostram que o escalonador chega perto do ápice da queda dos consumidores de CPU até sumir completamente do radar.


Enfim

Muita coisa aconteceu esse ano. Nossa comunidade de desenvolvimento continua crescendo em um ritmo saudável. Nossos processos de liberação estão mudando para melhor atender as necessidades dos usuários e desenvolvedores. Um monte de código bom está sendo realmente escrito.

Eu estou realmente ansioso com o próximo ano. Eu posso lhe prometer agora que ele será ainda mais emocionante do que esse.

Obrigado pela leitura.

Volta

O que fazer quando o fornecedor UC é comprado?

Meu fabricante de comunicações unificadas foi adquirido: E agora o que fazer?


Gary Audin, 08/01/2010
Fonte original: http://www.techtarget.com
Link direto ao texto: http://searchunifiedcommunications.techtarget.com/tip/0,289483,sid186_gci1378419,00.html?track=NL-1041&ad=744076&asrc=EM_NLN_10613741&uid=5714441


Mercados mudam, empresas crescem, outras desaparecem e algumas são adquiridas. Temos visto muitas dessas aquisições na comunidade de Tecnologia da Informação e Comunicação (TIC). Muitas aquisições afetarão o crescimento e adoção no mercado de comunicações unificadas. Nós vimos:


• Avaya comprar Nortel
• HP comprar 3Com
• Cisco comprar Tandberg
• Mitel comprar Inter-Tel
• Aastra comprar Ericsson e Intecom
• NEC comprar Sphere


Por que ocorrem aquisições de fabricantes?

Existem muitos vetores que atraem uma empresa para comprar outra:


Aumentar a base de clientes
Uma aquisição entrega os clientes existentes. Eles agora se tornam os clientes da empresa adquirente, aumentando assim a sua base e alcance ao cliente.


Aumentar a receita
A aquisição aumenta a receita total da empresa adquirente e, portanto, em muitos casos, o valor das ações.


Reduzir a concorrência
Uma aquisição diminui a concorrência e ajuda a solidificar o controle do mercado pela empresa adquirente.


Ganho de novos produtos
A empresa adquirida pode ter produtos que irá expandir o portfólio de produtos da empresa adquirente.


Ampliar o alcance geográfico
A empresa adquirida pode ter uma presença mais forte em outras partes do mercado global. A empresa adquirida já pode ter uma boa reputação na nova região geográfica que vai ajudar a empresa adquirente se expandir em novos mercados.


Ampliar sua imagem
A imagem da empresa adquirida pode ser necessária para a empresa adquirente para estabelecer uma imagem ampliada no mercado.


Bom negócio financeiramente
A empresa adquirida pode ser posta à venda. A venda pode oferecer uma compra financeiramente atrativa que de outra forma não seria atraente.


Clientes: É importante notar que essas justificativas para aquisição de empresas não têm nada a ver com o que vai lhe beneficiar, o cliente, exceto que a empresa adquirida pode ter chegado perto do encerramento e da falência. No caso de falência, a aquisição ajuda continuar o suporte de produtos para os clientes da empresa adquirida por um período maior.

O que pode acontecer com o fabricante adquirido é a questão em aberto. Tem importância quem as compra? A controladora é uma empresa pública ou privada? Se for pública, o preço das ações pode levar a decisões após aquisição, e as decisões podem ser de curto prazo. Um comprador privado pode se permitir analisar uma visão de longo prazo e pode investir na empresa adquirida de forma diferente.

O pessoal da empresa adquirida faz parte dos seus ativos. Alguns funcionários serão mantidos através de ofertas para permanecer, enquanto o pessoal duplicado será demitido. Também pode haver demissões de membros chaves. Por exemplo, a Cisco tem uma reputação de reter o pessoal da empresa adquirida. Outra questão pessoal é a cultura das duas empresas. Lembre-se da aquisição da IBM-Rolm? Não funcionou bem. O conceito da IBM-Rolm funcionou bem apenas no papel. Finalmente, alguns clientes da empresa adquirida vão buscar outros fornecedores. A empresa adquirente se beneficiará com a absorção dos clientes da empresa adquirida - mas nem todos.

Um resultado muito negativo de uma aquisição pode ser a venda de alguns dos ativos da empresa adquirida para pagar, em parte, a aquisição. Se esses ativos/produtos forem aqueles dos quais depende uma organização, então o cliente vai experimentar um segundo ciclo de aquisição do fornecedor, levando a mais tumulto. Em alguns casos, a empresa adquirente compra a tecnologia, a propriedade intelectual e funcionários chaves e descontinua os produtos.


Os possíveis resultados para a empresa são:

• A companhia combinada terá maior poder financeiro, maior cobertura geográfica e uma equipe de suporte aumentada.

• Os produtos da empresa adquirida podem ser retirados no prazo de um a dois anos.

• O suporte do produto pode estar disponível apenas de três a quatro anos, obrigando o cliente a migrar para novos produtos.

• Pode ser dado ao cliente incentivos financeiros/compensações para migrar para os produtos da empresa adquirente.




Sobre o autor:
O Gary Audin tem mais de 40 anos de experiência em comunicações e segurança de computador. Ele planejou, especificou, implementou e operou redes LAN de dados e telefonia. Elas incluem redes de âmbito local, nacional e internacionais, bem como redes convergentes de VoIP e IP nos Estados Unidos, Canadá, Europa, Austrália e Ásia.

... Retorna

Início

Prossegue ...

Impacto do 802.11n na Segurança da WLAN

Impacto do Padrão 802.11n na Segurança da Rede WLAN


Lisa Phifer
17/03/2009
SearchNetworking.com



À medida que as empresas se movem a toda força na direção de redes WLAN’s mais rápidas e mais abrangentes, vários fatores precisam ser considerados – incluindo a segurança. O padrão 802.11n promete expandir a cobertura e capacidade de rede, mas cuidados precisam ainda ser tomados para fornecer igual, ou melhor, segurança.



Antigo Padrão 802.11a/b/g

Igual ao padrão 802.11a/b/g anterior, o padrão 802.11n de elevada taxa de transferência emprega o 802.11i "robust security". Realmente, é exigido de todos os produtos Draft N dar suporte ao WiFi Protected Access version 2 (WPA2) – o programa de teste para o 802.11i do WiFi Alliance.


A boa notícia: todas as redes WLAN’s 802.11n construídas a partir do zero podem se despreocupar de invasores WEP e ataques WPA (TKIP MIC), porque todo dispositivo 802.11n pode cifrar dados com o algoritmo AES. O truque: as redes WLAN’s que precisam suportar tanto clientes antigos no padrão 802.11a/b/g quanto os novos clientes 802.11n precisam ser forçados a permitir o algoritmo TKIP. Fazendo assim torna possível aos clientes mais antigos não-AES a se conectarem seguramente. Infelizmente, o padrão 802.11n proíbe taxas de transmissão de dados elevadas quando se usa o algoritmo TKIP.


Consequentemente é melhor dividir clientes antigos 802.11a/b/g e clientes novos 802.11n em SSID’s separados: uma rede WLAN de taxa elevada de transferência exige o AES (WPA2) e uma rede WLAN legada que permita o TKIP ou o AES (WPA+WPA2). Isso pode ser feito usando duas definições SSID’s sobre um AP virtual ou dedicando diferentes portadoras sobre os AP’s dual-rádio. Contudo, isso é apenas um expediente temporário. Tão logo você possa retirar ou substituir aqueles dispositivos legados, livre-se do TKIP para melhorar tanto a velocidade quanto a segurança.



Tomando emprestado a Robustez do WPA2

O padrão 802.11n herda a robustez do WPA2 – e também os pontos fracos. Os dispositivos 802.11a/b/g e 802.11n podem usar AES para prevenir escutas de quadros de dados, falsificação e repetição da rede Wireless. Os APs 802.11a/b/g e 802.11n podem usar o padrão 802.1X para conectar usuários autenticados ao mesmo tempo que nega acesso a estranhos. Contudo, o padrão 802.11n ainda não pode evitar que intrusos envie quadros falsos de gerenciamento – um método de ataque usado para desconectar usuários legítimos ou fingir ser um AP’s "evil twin".


evil twin:
É um access point (AP) mau intencionado instalado por um atacante externo com uma facilidade com um rede wireless. O AP bandido captura beacons (sinais que anunciam sua presença) do AP legitimo da empresa e transmitem beacons idênticos, com algumas máquinas clientes internas ao prédio o qual se associa. Logo que a segurança wireless esteja habilitada, esse tipo de ataque não consegue afetar as máquinas usuárias. Contudo, ele pode causar prejuízo deixando as conexões lentas ou causando aos usuários perder conexões com rede real.



Como resultado, as novas redes padrão 802.11n precisam permanecer vigilantes a ataques oriundos do mundo de rede Wireless. Muitas redes WLAN’s pequenas podem ainda usar escaneamentos periódicos para detectar AP’s maliciosos, enquanto redes WLAN’s comerciais devem usar sistemas de prevenção de intrusão (WIPS) o tempo todo para barrar falsificadores, associações acidentais, ‘ad hoc’s não autorizados e outros tipos de ataques WiFi.


Redes WLANs existentes que implementa uma ou ambas dessas práticas de segurança, contudo, não podem ficar só dormindo em berço esplêndido. Dispositivos 802.11n possui alcance de distância duas vezes maior que seus pares 11a/b/g. AP’s maliciosos, de visinhos ou de área metropolitana que antes estavam tão distantes podem agora se tornar uma ameaça. Não apenas intrusos serão capazes de se conectarem a sua rede WLAN facilmente, mas usuários legítimos vão muito provavelmente se conectar acidentalmente a redes estranhas. Dado uma escolha entre o seu antigo AP 11a/g e um rápido AP 802.11n malicioso, os clientes promíscuos que “se conectam a qualquer rede disponível” vão tentar o tempo todo burlar.


Em resumo, a abrangência do alcance do padrão 802.11n agrava a freqüência de incidentes convencionais da segurança de rede Wireless e expõe configurações frágeis que contam com o desempenho ruim. Pior ainda, sensores WIPS existentes baseados no padrão 11a/b/g pode perder inteiramente muitos incidentes. Cada ativação de AP 802.11n deve incluir um upgrade do dispositivo WIPS para monitorar a maior cobertura das novas redes WLAN's, analisando o tráfego 11a/b/g e 11n nos canais 20MHz e 40MHz em ambas as bandas.



O Novo padrão 802.11n trás novas ameaças de segurança e complexidade

Toda tecnologia nova introduz alguns riscos não descobertos; uma inovação tão significativa quanto do padrão 802.11n não será provavelmente a exceção.

Os dispositivos 802.11n são novos produtos que podem conter alguns bugs não descobertos. Por exemplo, as primeiras versões do AP WN802T da Netgear não fazia corretamente parse dos parâmetros SSID’s (nulo) de comprimento zero (WVE-2008-0010). Drivers Atheros usados nos novos AP’s 802.11n (como o Linksys WRT350N) não tratava corretamente certos elementos de informação de gerenciamento de quadro (WVE-2008-0008). Tais vulnerabilidades não são incomuns; administradores de rede WLAN simplesmente precisam ficar atentos aos alertas quanto à segurança e de atualizações de firmware/driver.

As opções 802.11n são também consideravelmente mais complexas, aumentando as possibilidades de configurações mal feitas. Por exemplo, existem dúzias de possíveis taxas de transmissão de dados elevada, cada uma associada com uma combinação de capacidades e parâmetros que precisam bater em ambas as pontas. Em muitos casos, configuração mal feita causa desempenho parcial – isso pode não parecer uma questão de segurança, mas pode afetar a disponibilidade. Em casos extremos, um AP 802.11n mal configurado pode resultar em negação de serviço a redes WLANs vizinhas. Educação e análise no local são necessárias para descobrir e resolver esses problemas.

Finalmente, o padrão 802.11n introduz alguns quadros MAC novos, um dos quais se descobriu poder ser explorável. Especificamente, o padrão 802.11n fornece suporte mais eficiente a aplicações que trata stream pela confirmação de recebimento de vários quadros de dados usando único bloco reconhecimento (ACK). Um ataque de negação de serviço (DoS, em inglês) pode ser lançado contra redes WLAN’s 802.11n pelo envio de reconhecimentos falsos de bloco ao receptor (WVE-2008-0006). Um dispositivo WIPS que suporta o padrão 802.11n pode detectar esse ataque, mas a única forma de evitar isso é barrar o uso da funcionalidade Add Block-ACK (ADDBA).



Dando maior atenção

Felizmente, tudo das melhores práticas atuais de segurança de rede ainda se aplica ao padrão 802.11n. É importante perceber, contudo, que o padrão 802.11n também pode aumentar o risco empresarial simplesmente porque fornece suporte a mais usuários e aplicações com área de abrangência mais ampla. Em resumo, os mesmos ataques antigos podem agora ser de longe mais impactante ao seu negócio.


Por último, as redes 802.11n podem ser implementadas tão segura quanto – se não mais segura que – as redes 11a/b/g de então. Tudo isso exige está ciente e seguir com os objetivos. Nessa dica, nós exploramos as formas nas quais o padrão 802.11n pode afetar a segurança da rede WLAN. Agora é a sua chance de dar esse passo.



Sobre a autora:
Lisa Phifer é Presidente e sócia da Core Competence, uma firma de consultoria focada em uso empresarial de rede emergente e tecnologias de segurança. Na Core Competence, Lisa tem trilhado os seus 27 anos de experiência em projeto de rede, implementação, e testes para fornecer uma gama de serviços, desde estimativa de vulnerabilidade e avaliação de produto até educação de usuário e desenvolvimento de ‘white paper’. Ela tem alertado grandes e pequenas companhias a considerar o uso de tecnologias de rede e melhores práticas de segurança para gerenciar risco e adequar as necessidades empresariais. Lisa ensina e escreve exaustivamente sobre uma faixa ampla de tecnologias, desde segurança de rede móvel/wireless e prevenção a intrusão até implementação de rede privada virtual a controle de acesso a rede. Ela também é uma especialista dos sites SearchMobileComputing.com e SearchNetworking.com.

Volta ...

Reavaliando o PABX IP SMB AA300 da Digium|Switchvox

Esse relato do Matthew Nickasch publicado na Network World sobre a linha de produto da Switchvox foi de grande valia pra mim porque eu não conhecia nada da Switchvox. Pelo relato dele é muito bom.





Simplesmente Poderoso! Reavalie o PABX IP SMB AA300 Digium|Switchvox


Submetido por Matthew Nickasch na Quarta, 13/08/2008 - 6:03am.
http://www.networkworld.com/community/node/31020

Obs.: A sigla SMB's (Small-Medium sized Businesses), quer significar, Pequenas e Medias Empresas - PME's


Eu recentemente tive a oportunidade de gastar algumas semanas com a appliance Switchvox SMB AA300 recentemente lançada. Em minha opinião, se existir uma appliance ou um PABX IP SMB a explorar, esse é um. Para PME’s, existem três funções imensamente importantes em uma appliance:

1) Fácil instalação, Fácil gerenciamento, Fácil de usar
2) Flexibilidade (Telefones, Opções de troncos, Conectividade Externa)
3) Conjunto de Funcionalidades Avançados

É raro que todo sistema possa combinar de forma adequada todas essas três dimensões, e os usuários normalmente concordam com um cenário “2 de 3”. Certamente, sistemas grandes podem se moldar as necessidades de uma organização que demandam bastante por programação avançada, mas muitas pequenas e medias empresas não possuem orçamento tão grande assim para telefonia para permitir tais cenários.

Hoje qualquer pessoa pode vender um sistema de telefonia a você. De fato, o mercado de sistemas formatados para pequenas e médias empresas, PABX’s IP e Key Systems foi equalizado em torno da mesma faixa de preço. Contudo, existem muitas diferenças que se tornam imediatamente evidentes.


Configuração de Pré-Venda

O AA300 é o “filho do meio” na linha de produto do appliance SMB da Switchvox. Ele foi pensado para o mercado de médias empresas, é raqueável e suporta de 1 até 150 usuários. O AA300 roda o novo software 3.5 SMB, que trás novas funcionalidades e características a linha do produto. Para organizações que exigem redundância de RAID, múltiplas fontes de alimentação e muitos usuários, o AA350 se ajusta a grana.

Digium|Switchvox orgulha-se de ter tornado o processo de pedido ajuda/orientação extremamente fácil ao usuário final. De fato, eu abordei essa reavaliação de um ponto de vista do usuário final, que tenha pouco ou nenhum conhecimento em TI ou nenhuma experiência anterior de telecomunicações. Através da loja online da Digium|Switchvox, ou por telefone, o processo fácil de pedido de ajuda/instrução ficou transparente rapidamente. Mesmo que os usuários tenham questões sobre funcionalidades ou sobre a linha de produto, o esclarecimento fica prontamente disponível.

Uma vez o pedido de ajuda seja feito, os usuários se divertem com um processo de configuração customizado onde o appliance Switchvox é configurado para refletir as suas configurações de rede. É tão simples quanto colocar o appliance no ambiente de rede do usuário, e simplesmente “ligar”.


Configuração Inicial

Para ajudar no processo de revisão, eu permiti a um colega que trabalha em serviço à cliente ajuda na configuração. Muitas PME’s não possuem staff de TI em tempo integral, e isso é moderadamente importante para qualquer cliente de escritório ser capaz de configurar e administrar o sistema. Depois de andar pela instalação inicial com o Guia de Começo Rápido, nós começamos acrescentar os telefones ao sistema. Digium|Switchvox tem parceria com a Polycom para fornecimento de telefones SIP para suas appliances. Claro, você pode configurar qualquer telefone SIP (ou telefones analógicos através dos cartões DAHDI, anteriormente chamado de Zaptel) para funcionar com o sistema, o appliance detecta automaticamente os telefones Polycom na rede do usuário. Uma vez que os telefones sejam descobertos automaticamente, é tão simples como adicionar usuários e atribuir número de ramais aos telefones. Em 20 minutos, nós tínhamos adicionados todos os telefones ao sistema.

Nosso sistema foi equipado com um cartão para linhas analógicas, ao qual nós conectamos 4 linhas a RTPC. Além disso, cartões T1/E1 podem ser acrescentados para fornecer realmente mais linhas troncos. Com alguns cliques simples, nós ajustamos o plano de discagem para controlar ligações entrantes e saintes. Em menos de 1 hora, nós configuramos os troncos SIP e IAX para várias operadoras, estabelecemos roteamento DID, e criamos duas URA’s e filas DAC funcionais. Meu colega ficou impressionado com a interface “simples, porém poderosa“ que a appliance forneceu.


Uso no Dia a Dia

Eu coloquei o sistema na frente de alguns usuários que usam um BCM da Nortel há poucos anos. Através do portal baseado em web, os usuários verificaram seus voicemail, administraram suas configurações de encaminhamento de chamada, e utilizaram a aplicação de monitoramento para visualizarem o status completo de seus colegas de trabalho. No final da semana, os usuários simplesmente não queriam voltar para o BCM. No fim, todos os usuários observaram que adoraram o sistema porque era poderoso e extremamente fácil de usar. Os usuários olharam com tristeza os terminais Nortel porque os Switchvox SMB foram removidos.

O sistema de teste que eu reavaliei utilizou a liberação “SMB” do software Switchvox. Esse software fornece funcionalidades avançadas, como a interface web de monitoração para gerenciamento de chamadas para os usuários finais, funcionalidade avançada de DAC e suporte a API customizada. Ao mesmo tempo em que existem bastantes funcionalidades avançadas embutidas, o mesmo é apresentado de uma forma bastante lógica e fácil de entender. Sempre existem ações disponíveis de ajuda quando o mouse passa próximo a cada funcionalidade e opção de configuração.


Conclusão

Simplesmente aposte, eu sou um suporte da enorme comunidade Asterisk. Alguns usuários, especialmente SMB’s, ficam confusos ou atrapalhados sobre a “complexidade” de configuração de um ambiente Asterisk. O software Switchvox facilmente permite aos usuários tirarem vantagens do poderio intrínseco do Asterisk, enquanto mantém simplicidade em gerenciamento. O sistema foi fácil de instalar, gerenciar e usar. Essa simplicidade, contudo, não afeta o conjunto de funcionalidade. Com mais funcionalidades comparáveis aos dos sistemas legados, a essa appliance ganha facilmente.

Para mais informações sobre o Switchvox SMB AA300, visite http://www.switchvox.com. Eu também recomendo olhar os screenshots no site da Switchvox que ilustra o “simples poder’ da interface de gerenciamento.



Quem é o autor original?
Nickasch é bastante envolvido com TI quando ele ainda tinha apenas 13 anos. Sua experiência em consultoria anterior e atual inclui arquitetura de sistemas, virtualização e redes convergentes para as indústrias financeira, educacional e saúde. Matthew atualmente ocupa-se na universidade de Wisconsin-Platteville, onde trabalha como assistente de gerenciamento de rede. Ao mesmo tempo em que o seu interesse inclui serviços de diretórios e protocolos de roteamento, o foco de Nickasch é em redes convergentes e voz sobre IP.

Desonerando Carga da CPU com a Tecnologia TOE

A tecnologia TOE (TCP/IP Offload Engine), não confundir com ToE (que significa Timing over Ethernet), tal característica me chamou a atenção na especificação de servidores. Então procurei aprofunda-me sobre a mesma e cheguei até o site da empresa IPBLAZE.

Por essa empresa ser desenvolvedora da tecnologia TOE para cartão de rede Ethernet, o material do seu site possui conotação de exposição comecial da tecnologia, mas pela qualidade do conteúdo da sua explanação sobre a tecnologia está aqui em meu Blog uma versão com status de artigo.

A razão do meu interese por essa tecnologia, é que ela promete melhorar o throughput da conexão de rede, aumentar substancialmente desempenho do servidor e reduzir drasticamente a latência. E tais características são de fundamental importância para aplicações críticas de tempo de resposta como aplicações de Voz sobre IP.

Para mim, tal tecnologia deve constar na especificação de servidores para PABX IP Asterisk, OpenSER e outras aplicações sensíveis a latência, dado ao ganho de desempenho que ela pode proporcionar em geral no sistema. Então, tal especificação é altamente recomendada para sistema de voz sobre IP.




Desempenho da Tecnologia TOE

Fonte original inglês: site da empresa IPBLAZE (http://www.ipblaze.dk)
Escrito por Andreas Magnusson


Introdução

A necessidade de redes com alta velocidade é fator de sobrevivência. Essa tendência não é somente ditada por supercomputadores, clusters de servidores, tecnologias de mapeamento de imagem médica tão somente, mas também exigências para vídeo de alta resolução e streaming de áudio. O explosivo crescimento da Telefonia IP e a próxima geração de Vídeo Conferência IP estão tudo puxando a demanda por aumento fortíssimo de banda.

Crescimento da Demanda vs Melhoramento da Capacidade dos Hardwares

Hoje em dia computadores em cluster mais do que nunca são comuns e a existência de uma variedade de escolhas para a sua interconexão. A escolha certa para uma instalação particular dependerá de uma variedade de fatores, incluindo preço, alto desempenho, escalabilidade, etc. As tecnologias mais populares de rede disponíveis hoje incluem a Ethernet Gigabit, Ethernet 10 Gigabit, Myrinet, SCI, Quadrics e InfiniBand.


A moderna supercomputação está passando por uma drástica mudança de conceito, saindo dos sistemas monolíticos tradicionais de supercomputação para seguir na direção de uma nova geração de sistemas usando computadores "comerciais fora do shelf”, fortemente integrado com System Area Networks (SANs) de alto desempenho. No conjunto, esses computadores e redes de interconexão se integram para formar um supercomputador com memória distribuída ou cluster que oferecem significativamente melhor preço/desempenho do que os supercomputadores tradicionais.

A Tecnologia TOE no Centro da Rede de Interconexão de Sistemas de Alta Desempenho

Ethernet 1 Gigabit e Ethernet 10 Gigabit

A Ethernet se tornou incrivelmente popular nos últimos 25 anos. A Ethernet substituiu muitas interfaces proprietárias e se tornou um padrão de fato com um enorme ecossistema em torno de si. A Ethernet implica no possível risco de perda de pacotes e o protocolo TCP é adicionado no topo para fornecer transferência de dados confiável usando retransmissão em caso de perda de pacotes. A alta velocidade de processamento do protocolo TCP (acima de 5 Mbit/s) requer uma CPU potente. O TOE (TCP Offload Engine - Mecanismo que Desonera a CPU do Sistema de fazer o Processamento da Pilha TCP/IP e Transfere tal processamento para o Hardware da Placa de Rede Ethernet) resolve essas questões executando o processamento do protocolo TCP em hardware.

Integração da Tecnologia TOE com os Sistemas Atuais

A rede Ethernet de algum tipo sempre foi usada entre computadores do cluster e mesmo hoje está presente em quase todos os clusters. Enquanto que a Fast Ethernet era normalmente usada como a interconexão de alta velocidade anos atrás, ela ficou relegada a rede de serviço atualmente em muitos sistemas.

Uma questão significativa com Ethernet sempre foi relativamente a alta carga de consumo da CPU pelo processamento da pilha TCP/IP inteira e a alta latência comparada relativamente com outras tecnologias de rede. Essa questão era fator enormemente limitante no desempenho em sistemas passados. Um outro fator limitante com a Ethernet no mundo de cluster sempre foi o switch. Já que a arquitetura Ethernet subjacente exige switches rápidos que possa assumir o peso total de roteamento de pacotes que os switches Ethernet precisam para manter tabelas inteiras de roteamento e serem capazes de fazer cálculos de rotas no compasso da velocidade de transmissão.

Além do mais, grandes pressões de mercado frequentemente fizeram que os switches incluissem funcionalidades extras como roteamento baseado na camada 3 e superior que não são necessários no mundo de cluster. Essas questões já foram sanadas por alguns dos fabricantes de switch.



Solução Ethernet de Custo Benefício e Baixa Latência

A IPBlaze apresenta uma solução TOE de alto desempenho em Ethernet Gigabit com muito baixo latência. A tecnologia TOE da IPBlaze é atualmente implementada em FPGA e também é mirada por implementações ASIC.

Latência baixa é importante para desempenho de sistema para um grande número de aplicações e o mesmo se aplica para aplicações intensiva em CPU.



Plataforma de Teste

A plataforma de teste usada está usando um processador Pentium M 1.6GHz da Intel. A interface de host é uma interface PCI-X 66MHz. A placa TOE é baseado em um Xilinx Vertex II FPGA com MAC externo e PHY.

Comparação de Desempenho da Tecnologia TOE

Modelo de Performance

Um modelo de desempenho foi desenvolvido para predizer o desempenho do sistema, incluindo latência fim a fim. A latência fim a fim depende de inúmeros fatores. Os fatores mais importantes são taxa de linha, banda do barramento PCI/-X/-e, latência PCI/-X/-e, desempenho de CPU e eficiência de implementação.



Medidas de Latência

As medidas mostram melhoras de desempenho significativas usando o TOE IPBlaze. A implementação atual FPGA usa um MAC externo que aumenta a latência. Um número de latência planejada e otimização de desempenho estão em andamento.

A latência TOE é comparada com uma solução NIC padrão e com tecnologia SCI.

O protocolo wire é padrão TCP/IP em Ethernet e as medidas são baseadas na Ethernet 1 Giga.

As medições de desempenho foram feitas pelas seguintes ferramentas:

* netperf para teste performance;
* A plataforma de teste está no Linux 2.6 e inúmeras ferramenats Linux são usadas para verificar a exatidão das medições (netstat, gnome-system-monitor, ifconfig);
* chip scope para análise exata de tempo de transações PCI e outros tempos de processamento relevantes na FPGA da IPBlaze (chip scope em uma ferramenta não-intrusiva para amostragem de sinais com precisão do clock).



Otimizações

As diferenças entre as implementações TOE 1G FPGA e ASIC da IPBlaze se relaciona com a integração do MAC no ASIC e aumento da taxa de clock. Existem inúmeras otimizações que pode ser implementadas se for decidido (dependente da definição e requirimentos de produto).



Solução 10G

Os dados de desempenho para a solução TOE/NIC 10G leva vantagens do ganho de performance alcançado por:

* Mais baixa latência de transmissão devido a transmissão 10 vezes mais rápida;
* Interface de host PCI-e x8;
* Taxa de clock mais elevada devido à implementação em ASIC em vez de FPGA.

O core TOE e o software permancem o mesmo.



Solução 2.5G

Do ponto de vista de desempenho uma solução Ethernet 2.5G é também interessante. Os Phy’s 2.5G estão disponível um custo muito atrativo. Uma das questões chaves é a disponibilidade de portas Ethernet comutadas com 2.5G. A latência de switch será também relativamente baixa.



Switches Ethernet

Os switches Ethernet 1G usados nesse teste tem um delay de store e forward, por padrão. O modo Cut-Through é suportado por alguns chips de switch. A latência de switch que nós temos medidos em switches Ethernet 1G de baixo custo são de aproximadamente 1,5 us + 1,1*tempo de transmissão de pacotes. É possível configurar o chip do switch para operar no modo Cut-Through (sem atraso o store-and-forward). Isso não foi verificado por medições ainda.




Conclusão

A boa notícia é que com a Ethernet Gigabit com TOE da IPBlaze, o mercado tem agora uma boa escolha para fazer interconexão de alta velocidade a um preço muito atrativo. A Ethernet Gigabit pode ser agora transformada em uma rede de escolha para interconexão. E o seu suporte de software sólido e em toda parte torna-lhe uma escolha boa para aplicações que exigem também desempenho máximo de comunicação.

Inúmeras otimizações de desempenho pode ser aplicadas ao sistema se for preciso.

Alta Disponibilidade Asterisk ao modo FoneBridge

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.