Seu cliente não quer saber se falhou Asterisk, AGI, MySQL ou datacenter. Ele so sabe que a chamada não completou.
A maioria dos provedores não acorda pensando em comprar alta disponibilidade. Eles compram depois da primeira queda seria, depois do primeiro pico de trafego, ou depois que um cliente mostra que a plataforma ficou mais importante do que a arquitetura por tras dela.
Marque o que e verdadeiro na sua operação
Isto não e um teste técnico. E uma verificação de risco do negocio. Se varias frases são verdadeiras, sua base de clientes ja passou do ponto de depender de um único caminho de chamadas.
Um servidor Asterisk ainda processa a maior parte das minhas chamadas de produção.Se esse servidor fica ocupado, instável ou offline, o negocio sente imediatamente.
O SIP Proxy recebe a chamada primeiro e envia para servidores Asterisk slave com pesos diferentes. Assim o trafego de produção não fica preso em uma única maquina. Voce pode adicionar novos slaves quando o trafego crescer ou colocar o weight do slave em 0 para remove-lo da produção sem trocar o endereço de proxy do cliente.
Se meu Asterisk principal cair, as chamadas não continuam automaticamente em outro servidor.Backup que depende de ação manual e recuperação, não alta disponibilidade.
O dispatcher do SIP Proxy pode enviar chamadas para outro slave disponível quando um slave esta indisponível ou sobrecarregado. Isso também permite retirar temporariamente um slave colocando weight 0 para manutenção, analise ou controle de capacidade.
Todas as chamadas ainda dependem de execução via AGI.AGI e util, mas em escala cada processo extra e cada atraso viram parte do limite de capacidade.
A Aplicação em C roda como uma aplicação nativa em C dentro do Asterisk, reduzindo a sobrecarga do AGI no caminho vivo da chamada. Como o papel do slave fica mais leve, muitos ambientes podem usar hardware modesto, como 2 CPU cores e 4 GB de RAM.
Meus slaves precisam do banco master online para continuar processando chamadas.Isso e simples, mas pode transformar o banco master no ponto que para tudo.
O slave pode ler tabelas locais replicadas para autorização das chamadas, enquanto a importação de CDR atualiza o master quando a conectividade voltar.
Tenho clientes que reclamariam depois de poucos minutos sem chamadas.Quando clientes dependem da sua plataforma, downtime vira problema comercial, não apenas técnico.
Proxy mais capacidade em slaves reduz a chance de um incidente em um servidor virar queda visível para o cliente. Tambem permite deixar capacidade preparada antes do proximo cliente grande chegar.
Quero usar mais de um datacenter, região ou grupo de servidores.Isso exige distribuição de trafego, pesos e uma forma limpa de associar proxies a slaves.
Cada proxy pode usar grupos específicos de slaves. Isso facilita separar regiões, datacenters ou trafego de clientes. Voce também pode dedicar slaves para um callcenter com muito trafego e mante-lo separado dos clientes comuns.
Quero um painel MagnusBilling, mas muitos servidores processando chamadas.Billing centralizado com processamento Asterisk distribuído e exatamente onde a Aplicação em C se encaixa.
O MagnusBilling continua sendo o painel master, enquanto a Aplicação em C nos slaves processa chamadas localmente. Voce mantem um painel centralizado e adiciona ou remove servidores de processamento quando precisar.
Uma hora ruim de trafego custaria mais que USD 40.A licença e pequena comparada ao custo de uma interrupção seria.
Por USD 40 por servidor, a app custa menos do que aceitar risco repetido de interrupção em trafego pago. A menor exigência de hardware também ajuda a escalar com mais slaves pequenos em vez de depender de um servidor caro.
O momento em que isso fica obvio geralmente ja e tarde
Clientes não perguntam se sua arquitetura e elegante. Eles perguntam por que as chamadas falharam, por que o saldo não foi atualizado, por que o failover era manual e por que voce não se preparou antes de vender trafego de produção.
O que muda com a Aplicação em C
Sem ela
- AGI continua no caminho vivo da chamada para cada decisão.
- Escalar normalmente significa servidores maiores, não uma arquitetura melhor.
- Failover depende de trabalho manual ou scripts improvisados.
- O banco master pode virar a dependência que para os slaves.
- Adicionar mais Asterisk aumenta a complexidade operacional.
Com ela
- O processamento roda dentro do Asterisk por modulo nativo em C.
- O SIP Proxy distribui chamadas para slaves usando weights.
- Proxies específicos podem usar grupos específicos de slaves.
- Slaves podem ler tabelas locais replicadas quando este modelo for escolhido.
- O MagnusBilling continua centralizado enquanto as chamadas são processadas em vários servidores.
Vantagens operacionais depois da instalação
A Aplicação em C não serve apenas para sobreviver a uma falha. Ela muda como voce opera, escala e analisa problemas no MagnusBilling todos os dias.
Com SIP Proxy e slaves com weight, voce adiciona capacidade quando chegam novos clientes ou quando o trafego cresce. Tambem pode remover um slave da produção colocando weight 0, sem trocar o endereço de proxy do cliente.
Em vez de esperar um servidor chegar ao limite, voce mantem a arquitetura pronta. Novos slaves podem ser preparados e adicionados ao pool do proxy conforme o negocio cresce.
Como o processamento roda em C nativo e o papel do slave e mais leve, muitos slaves podem usar servidores pequenos. Um servidor com 2 CPU cores e 4 GB de RAM pode ser suficiente nesta arquitetura.
Quando um cliente tem um problema difícil, voce pode parar o trafego normal para um slave colocando weight 0, apontar somente aquele cliente para o slave e analisar as chamadas sem ruído dos demais clientes.
Um callcenter com muito trafego não precisa compartilhar os mesmos servidores usados por clientes comuns. Voce pode isolar este cliente em slaves específicos e manter o resto da plataforma mais limpo.
Voce mantem o MagnusBilling centralizado enquanto o processamento real das chamadas fica distribuído. Isso aumenta o controle sem transformar cada Asterisk em um sistema de billing separado.
Motivos comuns para adiar, e a resposta honesta
Informações e condições antes de comprar
A primeira parte desta pagina ajuda voce a entender por que precisa da Aplicação em C. Esta parte explica exatamente o que voce esta comprando, como a arquitetura funciona e quais são as condições comerciais.
O pagamento mensal da direito ao uso da Aplicação em C do MagnusBilling em cada servidor onde ela for instalada. O valor e USD 40 por mes, por servidor.
A instalação/configuração da Aplicação em C exige acesso SSH root ao servidor, porque o modulo nativo do Asterisk precisa ser instalado e compilado no ambiente do Asterisk.
O pagamento mensal da Aplicação em C não inclui suporte, troubleshooting, treinamento, customização, ajuda emergencial ou assistência operacional. Suporte exige contrato comercial separado.
Suporte não e fornecido parcialmente, informalmente ou sob demanda sem o contrato comercial adequado. Não ha exceções.
Se voce tem suporte comercial, os pedidos devem ser claros e específicos. Solicite uma tarefa ou tópico por vez para que o atendimento seja eficiente.
MagnusBilling e open source. O pagamento mensal não e pelo MagnusBilling em si; ele e exclusivamente pelo uso do addon Aplicação em C.
Opções de banco de dados e CDR
Este modelo e mais simples e os saldos são atualizados imediatamente, mas e recomendado principalmente quando os servidores estão no mesmo datacenter ou possuem conectividade muito estável. Se o banco master ficar offline, os slaves podem parar de processar chamadas.
Este modelo permite que os slaves continuem lendo dados locais e processando chamadas quando o master esta temporariamente indisponível. E util para datacenters, regiões ou países diferentes.
O caminho da chamada na Aplicação em C e orientado a leitura. Os CDRs são importados depois no master, e o saldo e descontado quando esses CDRs são processados.
Se os slaves usam banco local e o master fica offline por muito tempo, chamadas podem continuar enquanto os CDRs aguardam importação. Quando o master volta, os saldos são atualizados e clientes pre-pagos podem ficar negativos.
Regras de proxy, slaves e crescimento
O SIP Proxy distribui chamadas para slaves usando weight. Servidores mais fortes podem receber mais chamadas, servidores menores podem receber menos.
Você pode preparar novos slaves e adiciona-los ao pool do proxy conforme o trafego cresce. Tambem pode colocar weight 0 para parar de enviar trafego normal para um slave sem alterar o endereço de proxy do cliente.
Um proxy pode ser configurado para usar slaves específicos. Isso permite estruturas separadas mantendo apenas um painel MagnusBilling centralizado.
Clientes de alto trafego, como callcenters, podem ser isolados em slaves dedicados em vez de ficarem misturados com clientes comuns.
Para troubleshooting, coloque o weight de um slave em 0, envie somente o cliente afetado para esse slave e analise as chamadas sem ruído dos outros clientes.
Como a Aplicação em C nativo e o papel do slave e mais leve, muitos slaves podem rodar com hardware modesto, como 2 CPU cores e 4 GB de RAM.
Se estes riscos descrevem sua operação, isso não e uma atualização futura. E o seu proximo passo de infraestrutura.
Voce estão compra a Aplicação em C porque ela e escrita em C. Voce compra porque o seu MagnusBilling ja e importante o suficiente para que as chamadas não dependam de um caminho frágil.