Projeto InterVoIP - Arquitetura - I Workshop CPqD de Inovação Tecnológica em VoIP Peering
-
Upload
cpqd -
Category
Technology
-
view
363 -
download
3
Transcript of Projeto InterVoIP - Arquitetura - I Workshop CPqD de Inovação Tecnológica em VoIP Peering
Agenda
• Contexto e desafios do Projeto InterVoIP (CPqD)• Apresentação do Projeto InterVoIP, motivação e etapas• Conceitos• ENUM – Convergência de Serviços • Tecnologias de Interconexão VoIP • Desafios da Pesquisa do Projeto InterVoIP
• Benchmarking de servidores DNS-ENUM (UFU)• Pesquisa de uma solução em VoIP Peering (CPqD)
• Padrões de implementação : IETF • Arquitetura• Estudo de caso do InterVoIP
SBE-I
SIP
SSP-I SSP – SIP Service Provider
SBE – Signaling Path Border Element
SIPPara qual operadora deve ser enviado o pacote?
Speermint - elementos
SBE-I
LRF
SSP-I
LUFLUF - Look-Up Function
Determina localização do domínio de um SF (Signaling Function) de destino
SFSF - Signaling Function
Envia as requisições SIP para estabelecimento e manutenção de sessões
LRF - Location Routing Function Determina SED necessária para roteamento da requisição
SED (Session Establishment Data)Dados necessários para rotear uma chamada para o próximo salto:
. FQDN ou IP
. Porta
. Protocolo de Transmissão
. Segurança
. Outros parâmetros de controle
Speermint - elementos
SIP
SSP1
SFSIP
SBE
SF
SSP2
DBE RTPRTPDBE
LUF
Proxy Redirectou
ENUMQ: Numero_ENUM
R: Dominio (AoR)
LRF DNSQ: SRV Dominio (AoR)
R: FQDN/IP Porta Protocolo Transmissão
Speermint - como funciona
SIP
SBE
LUF - Realiza consulta ENUM- Retorna o domínio AoR
(sip:[email protected])- Se não resolver, pode enviar para PSTN
DBE- Data Path border Element- Elemento de borda por onde passa o tráfego de mídia.
LRF- Descobre próximo salto a partir do
domínio de destino- Resolução DNS: NAPTR (Transporte) / SRV (Porta) / A (Endereço) – rfc 3263
SBE
LUF
LRF
SF
SSP
ENUM
DNS
Como aprovisionamos dados no DNS e no ENUM?
SIP
Aprovisionamento de dados
ENUM
DNSDatabase
Sugere modelamento para aprovisionamento de dados de encaminhamento:
Operadora B
Inseridos pelo SSP destino – Registrant
Operadora B
Consumido pela SSP que origina a chamada ou uma SSP Intermediaria
DRINKS - Aprovisionamento de dados
Visão simplificada da arquitetura
Base de dados
Fatores de decisão (custo, horário, etc)
Numero Telefônico
Range de Numeração
Prefixo
Grupo de Destino
n
n
n
1
ENUM Record Domínio
nn 11
SRV Record
NAPTR Record
A Record
n
1
11
SED
Grupo de Rota
n n
n
n
Peering Organization
1 n
DRINKS - Flexibilização de roteamento
Que arquitetura pode atender aomodelamento DRINKS, permitindoflexibilização no roteamento dachamada VoIP ?
Requisitos da Arquitetura• Alta taxa de vazão• Flexibilidade no encaminhamento de chamada• Facilidade de implementação• Escalabilidade de dados• Escalabilidade Horizontal• Aderência à infra-estrutura de TI das empresas do setor
Opções para a Arquitetura• Benchmarking realizado pela UFU:
• Bind• PowerDNS
Bind com Zone Files
PowerDNS com Mysql
Zone Files - Mysql
Como conseguir uma maiorindependência em relação aoservidor DNS ?
Abstração através de um Adaptador
• Biblioteca linkada ao servidor DNS em tempo de compilação.
• Trabalha integrada a backend customizado do servidor DNS.
• Recebe as consultas enviadas ao servidor DNS e repassa a resolução ao InterVoIP.
• Faz uso de sockets e trafega protocolo binário, definido sob medida, com baixo overhead.
Arquitetura adotada
Arquitetura do projeto
PowerDNS com Adaptador
• Por que PowerDNS ?• Concebido com a premissa de ser
extensivel.• Possui vários backends
implementados• Lembrando que um dos requisitos...
Facilidade de implementação
• Por outro lado ...• Para que seja satisteito mais um
requisito da arquitetura: Aderência à infra-estrutura de TI
• Apenas acoplar Adaptador ao novo servidor DNS
• Demais módulos são reaproveitados
Servidor de Consultas
• Recebe consultas do DNS e encaminha ao mecanismo de resolução
• Alta disponibilidade• Escalável horizontalmente.
• Alto desempenho• Load Balancer via ha-proxy.
• JBOSS Netty• Abstrai a complexidade da
programação com sockets.
Protocolo de transmissão
• Google Protocol Buffers• Abstrai a complexidade da definição de um protocolo binário• Protocolo definido sob medida em arquivo texto• Compilador protoc gera implementações em Java e C++
Mecanismo de Resolução
• Traduzir chave DNS para registro correspondente• Pelo fato da resolução ser interna ao InterVoIP proporciona :
• Flexibilidade e inteligência na tomada de decisão• Políticas pré-definidas (Custo da ligação, Horário da ligação, Tráfego no link )
• Para atender a mais um requisito...• Alta vazão• Registros devem estar na memória
• Devido ao grande volume de registros um outro requisito...• Escalabilidade de dados
• Como alocar em memória uma grande quantidade de registros de forma confiante e escalável ?
Cache Distribuído• MenCached
• Standalone
• JBoss Infinispan• Standalone• Embedded
• Opção escolhida:• JBoss Infinispan Embedded• Escalabilidade da aplicação em conjunto com dados• Escalabilidade teórica infinita• Modo de configuração
• Distribuído parcialmente replicado
Modos de Configuração do Cache
Modo Replicado• Capacidade de Armazenamento
• Igual a capacidade do menor nó
• Segurança do dado• Maximizada• Cache completo em todos os nós
Modo Distribuído• Capacidade de Armazenamento
• Maximizada• Igual a soma da capacidade de
todos os nós
• Segurança do dado• O dado está presente em um único
nó• Se um nó apresentar falha, parte
dos dados deixarão de estar na memória.
Modo Distribuído parcialmente Replicado• Capacidade de Armazenamento
• > que cenário Replicado.• < que cenário Distribuído.• Depende do nível de replicação.
• Segurança do dado• > que cenário Distribuído.• < que cenário Replicado.• Depende do nível de replicação.
• Cenário Exemplo• 3 Nós - Nível de replicação = 2• Se apenas um nó apresentar falha,
o cache ainda contém todos os dados.
Cache Distribuído InterVoIP
• Consulta base de dados relacional, modelada segundo o DRINKS e aloca os registros em um cache distribuído chave-valor.
Validação da Arquitetura
• Nessa arquitetura o desempenho da aplicação passa a depender não somente do servidor DNS.
• Após a definição da arquitetura e implementação de um mínimo necessário foram efetuados testes de validação da arquitetura.
Validação da arquitetura• Para formular uma metodologia de teste, devemos considerar
aspectos não funcionais, relativos ao desempenho e a capacidade de recursos computacionais.
• Desempenho• Vazão de Requisições por minuto • Tempo de latência
• Capacidade de recursos computacionais• Disponibilidade de memória
• Manutenção da base de dados• Tempo de reload da base de dados• Desempenho durante o reload da base de dados
Testes de desempenho do DNS• Backend padrão versus backend com adaptador.
• Testes realizados para números existentes e não existente em que o DNS é autoritativo.
• Utilizamos a ferramenta opensource dnsperf.
• Para os dois cenários foi utilizada uma base com 1 milhão de números cadastrados.
• Foram considerados várias configurações de cache para o DNS, fizemos uma analise comparativa com a configuração mais coerente para o estudo dos dois cenários.
Vazão para números existentes
Latência para números existentes
Vazão para números não existentes
Latência para números não existentes
Alocação de memória com uso do Adaptador
• Quantidade de memória estimada para uma carga de 1 milhão de números telefônicos
• Tempo de carga da base de dados para RAM• Tempo aferido para carga em uma
máquina• Arquitetura Intel i7 2600 64bits - 3.4 Ghz • 8G RAM
730 MBytes
52 segundos
• Vazão• Para números existentes temos uma vazão maior para o backend padrão• Para números não existentes os valores para os dois cenários são
parecidos• Bom desempenho nos dois cenários, considerando o fluxo de chamada
Voip
• Tempo de Latência• Com adaptador torna-se maior em um cenário com grande número de
requisições simultâneas• Muito baixo nos dois cenários, comparado ao tempo total para o
estabelecimento da chamada.
• Desempenho medido durante o reload• Não foi afetado de maneira significativa em relação ao regime normal de
operação.
Análise dos Testes
• O cenário “Com Adaptador” é factível devido as seguintes constatações :
• Desempenho apresentado nos testes
• Ganhos de flexibilização que esta busca proporciona
• Portanto esse cenário deve ser considerado como solução de arquitetura a ser adotada
Conclusão da validação da arquitetura
Portal WEB
Portal WEB - Aprovisionamento de dados
Portal WEB - Menu• Cadastro Numérico
• Numero Telefônico• Prefixo• Range
• Grupo de Destino• Cadastro de Grupo de Destino
• Registros• Domínio-Protocolo• Domínio-Serviço• Domínio• Protocolo• Serviço• Servidores
• Grupo de Rota• Associação Grupo de Rota• Cadastro de Grupo de Rotas
• Carga Massiva• Persistir Carga• Visualizar Log
• Usuário• Cadastro de Usuários
• Administrar• Alterar Senha• Grupo de Recurso• Organizações• Perfis• Recursos
Portal WEB - Cadastro Número Telefônico
Portal WEB - Assoc. Grupo de Rota - Domínio
IETF / Speermint
Componentes do Speermint• Opensips
• Desenvolvido com o fim de ser um SIP Proxy• Não tem o foco em controlar mídia.• Modularizado para possibilitar acréscimo de funcionalidades e aderência
a vários protocolos.• Opensource
• Funções do Speermint• SF e LRF
• implementadas no core do Opensips• LUF
• implementadas no modulo ENUM do Opensips, adaptado para enviar o usuário do RURI e o domínio (hostname ou IP) da operadora de origem.
Estudo de caso: InterVoIP
Obrigado!
www.cpqd.com.br