Temos dois servidores Asterisk. Um é um failover escaldante (ou seja, temos que fazê-lo funcionar manualmente caso o primeiro falhe, mas ele recebe atualizações regulares de configuração para que ele esteja sempre pronto para ser ativado) e o outro é o servidor ativo. Ambos têm o Digium Wildcard TE405P, e o hardware e o software são idênticos, mas a última vez que precisávamos usar o servidor de failover, as coisas correram mal quando ele foi conectado à linha PRI. Agora, estamos atualizando a caixa de failover para o Asterisk 1.6 e pressionando-a para o serviço.
Eu realmente preciso de uma maneira de testar exaustivamente (incluindo testes sob carga) o hardware e a configuração do TE405 antes que precisamos. Eu não posso simplesmente configurar e derrubar uma linha PRI para testes por uma hora ou um dia, e a despesa da linha nos impede de ter um backup completo. Da mesma forma, apenas trocar o cabo de um servidor para outro também é altamente prejudicial.
No passado, para situações semelhantes de teste, acabei de fazer um cabo de crossover T1 . O TE405P é um cartão com quatro portas, portanto, no sistema de failover, basta conectar duas das portas back-to-back com um crossover T1 e, em seguida, escrever um script rápido para que o asterisco coloque um grupo de chamadas em uma porta, respondendo-as na outra porta.
O teste de DR deve fazer parte dos seus planos de manutenção de sistemas que ocorrem regularmente ou, no mínimo, você deve realizar testes de DR anualmente, semestralmente, etc. Você pode fazer testes básicos usando o método ErikA sugerido, mas você Nunca saberá se funciona a menos que você teste com a verdadeira linha PRI, fazendo chamadas reais. Minha recomendação seria fazer lobby por um teste de RD ocorrendo regularmente, programado para um período que seja menos prejudicial para o negócio.
Os componentes de DR são como qualquer outra coisa (backups, por exemplo), eles não são úteis, a menos que realmente funcionem e, para confirmar que funcionam, você precisa testá-los.
Tags asterisk