Afonso Zimmermann

Asterisk Cluster

S ao Jos e SC Mar co / 2008

Afonso Zimmermann

Asterisk Cluster
Monograa apresentada a ` Coordena ca o do Curso Superior de Tecnologia em Sistemas de Telecomunica co es do Centro Federal de Educa ca o Tecnol ogica de Santa Catarina para a obten c ao do diploma de Tecn ologo em Sistemas de Telecomunica c oes.

Orientador:

Marcelo Araujo
Co-orientador:

Prof. Eraldo Silveira e Silva

es Curso Superior de Tecnologia em Sistemas de Telecomunicac o o Tecnolo gica de Santa Catarina Centro Federal de Educac a

S ao Jos e SC Mar co / 2008

Monograa sob o t tulo Asterisk Cluster, defendida por Afonso Zimmermann e aprovada em 18 de mar co de 2008, em S ao Jos e, Santa Catarina, pela banca examinadora assim constitu da:

Marcelo Araujo Orientador

Prof. M. Eraldo Silveira e Silva Coorientador

Prof. M. Emerson Ribeiro de Mello CEFET / SC

Resumo
Neste trabalho s ao apresentadas duas t ecnicas de Cluster poss veis de se usar com sistemas baseados no Asterisk. O DNS Round-Robin e o DUNDi. O DNS Round-Robin e congurado diretamente no servidor DNS, podendo ser usado para programas compat veis com o Linux. O DUNDi est a incorporado ao Asterisk desde a vers ao 1.0. Este possui um arquivo de congura ca o pr opria, necessitando de um canal de comunica ca o entre os servidores que comp oe o Cluster. Sozinho ou aliado a outras t ecnicas, pode ser usado para prover v arias formas de Cluster. Nesse trabalho foi usado para prover balanceamento de carga com a ajuda do DNS Round-Robin. Para se chegar a essas duas t ecnicas, foi realizada uma pesquisa para ver quais t ecnicas poderiam ser usadas com o Asterisk. Ent ao passou-se para um estudo das t ecnicas para realizar a implementa c ao das mesmas. Por m foi testada a eci encia do DUNDi, de forma a permitir avaliar a necessidade ou n ao de seu uso. Palavras-Chave: Cluster, Asterisk, IAX.

Abstract
In this work are presented two techniques of Cluster possible to use with systems based on Asterisk. The DNS Round-Robin and the DUNDi. The DNS Round-Robin is congured directly on the DNS server and it can be used for programs compatible with Linux. The DUNDi is incorporated to Asterisk since version 1.0. He has a conguration le itself and require a channel of communication between the machines that make up the cluster. Alone or together with other techniques, it can be used to provide various forms of Cluster. That work was used to provide load balancing, with the help of the DNS Round-Robin. It tested its eectiveness in some situations. To achieve these two techniques, a search was carried out to see what techniques could be used with Asterisk. Then it moved to a study of techniques to achieve the implementation of them. Finally was tested the eciency of DUNDi, to allow assess the need or otherwise of their use. Keywords: Cluster, Asterisk, IAX.

Sum ario

Lista de Figuras 1 Introdu c ao 1.1 1.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organiza c ao do texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 9 p. 10 p. 10 p. 11 p. 11 p. 11 p. 11 p. 12 p. 12 p. 13 p. 15 p. 15 p. 15

2 Fundamenta c ao Te orica 2.1 2.2 Hist orico sobre Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . Deni ca o de Cluster e apresenta ca o de seus componentes . . . . . . . . 2.2.1 2.2.2 2.3 2.4 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Tipos de Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Softwares Capazes de Implementar um Cluster . . . . . . . . . . . . . .

3 Cluster Asterisk com DUNDi e DNS Round-Robin 3.1 3.2 3.3 DNS Round-Robin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DUNDi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Uso do DUNDi e do DNS Round-Robin para a forma ca o de um Cluster Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16 p. 20 p. 22 p. 33

4 Experimentos Realizados 4.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 Conclus oes

Anexo A -- Anexos A.1 Congura ca o do Bind 9 para permitir o uso do DNS Round-Robin . . . A.2 Instala c ao do DUNDi no DISC-OS . . . . . . . . . . . . . . . . . . . . A.2.1 Comandos para Testes . . . . . . . . . . . . . . . . . . . . . . . A.3 Sa da dos comandos vmstat e sipp . . . . . . . . . . . . . . . . . . . . . Refer encias

p. 34 p. 34 p. 34 p. 40 p. 41 p. 59

Lista de Figuras
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Cen ario inicial de testes . . . . . . . . . . . . . . . . . . . . . . . . . . Mensagens DPDISCOVER e DPRESPONSE . . . . . . . . . . . . . . . Cen ario de Teste sem Cluster . . . . . . . . . . . . . . . . . . . . . . . Cen ario de Teste com Cluster . . . . . . . . . . . . . . . . . . . . . . . 100 chamadas SIP em um u nico Servidor . . . . . . . . . . . . . . . . . 50 chamadas SIP sendo tratadas e 50 sendo encaminhadas via DUNDi . 50 chamadas SIP recebidas via DUNDi . . . . . . . . . . . . . . . . . . 200 chamadas SIP em um u nico Servidor . . . . . . . . . . . . . . . . . 100 chamadas SIP sendo tratadas e 100 sendo encaminhadas via DUNDi 100 chamadas SIP recebidas via DUNDi . . . . . . . . . . . . . . . . . 300 chamadas SIP em um u nico Servidor . . . . . . . . . . . . . . . . . 150 chamadas SIP sendo tratadas e 150 sendo encaminhadas via DUNDi 150 chamadas SIP recebidas via DUNDi . . . . . . . . . . . . . . . . . p. 17 p. 18 p. 20 p. 21 p. 23 p. 24 p. 25 p. 26 p. 27 p. 28 p. 29 p. 30 p. 31

Sa da do comando vmstat 5 10 para 100 chamadas SIP em um u nico PC p. 41 Sa da de status do SIPP para 100 chamadas SIP em um u nico PC . . . Sa da do comando vmstat 5 10 para 50 chamadas SIP recebidas e 50 encaminhadas via DUNDi . . . . . . . . . . . . . . . . . . . . . . . . . p. 43 p. 42

17

Sa da de status do SIPP para 50 chamadas SIP recebidas e 50 encaminhadas via DUNDi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 44

18 19 20

Sa da do commando vmstat 5 10 para 50 chamadas recebidas via DUNDi p. 45 Sa da de status do SIPP para 50 chamadas recebidas via DUNDi . . . . p. 46

Sa da do comando vmstat 5 10 para 200 chamadas SIP em um u nico PC p. 47

21 22

Sa da de status do SIPP para 200 chamadas SIP em um u nico PC . . . Sa da do comando vmstat 5 10 para 100 chamadas SIP recebidas e 100 encaminhadas via DUNDi . . . . . . . . . . . . . . . . . . . . . . . . .

p. 48

p. 49

23

Sa da de status do SIPP para 100 chamadas SIP recebidas e 100 encaminhadas via DUNDi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 50

24

Sa da do commando vmstat 5 10 para 100 chamadas recebidas via DUNDi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 51 p. 52

25 26 27 28

Sa da de status do SIPP para 100 chamadas recebidas via DUNDi . . .

Sa da do comando vmstat 5 10 para 300 chamadas SIP em um u nico PC p. 53 Sa da de status do SIPP para 300 chamadas SIP em um u nico PC . . . Sa da do comando vmstat 5 10 para 150 chamadas SIP recebidas e 150 encaminhadas via DUNDi . . . . . . . . . . . . . . . . . . . . . . . . . p. 55 p. 54

29

Sa da de status do SIPP para 150 chamadas SIP recebidas e 150 encaminhadas via DUNDi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 56

30

Sa da do commando vmstat 5 10 para 150 chamadas recebidas via DUNDi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 57 p. 58

31

Sa da de status do SIPP para 150 chamadas recebidas via DUNDi . . .

Introdu c ao

Atualmente, centrais telef onicas baseadas em VoIP (Voz sobre IP) est ao se tornando cada vez mais comuns. Entre as plataformas mais utilizadas est a o Asterisk, que se executa em sistemas UNIX compat veis. Entre as v arias vantagens que ele possui est ao fato do limite de ramais e troncos ser determinado pelo computador onde est a o PABX. Por outro lado, sistemas maiores podem demandar uma carga de processamento muito alta at e mesmo para computadores modernos. Para operar com v arios ramais SIP ou IAX2 e com troncos SIP ou IAX2, um bom volume de chamadas podem ser estabelecidas por um s o servidor. Isso usando codecs PCM alaw ou ulaw. O uso de outros codecs causa um aumento na carga do processador, pois al em de gerar o PCM ainda precisam fazer a codica c ao para o respectivo codec para aumentar a compress ao. Mas mesmo com alaw ou ulaw, ao se aumentar muito o volume de chamadas, come ca a ocorrer picos de processamento que fazem com que ocorra picotamento da voz ou at e a aus encia dela por um longo per odo no canal. Esse problema pode ser ainda agravado pelo uso de placas para a interconex ao do PABX com a PSTN, sendo tanto via entroncamento E1 como via entroncamento anal ogico. Isso porque essas placas utilizam muitas interrup co es por segundo, usando processamento e principalmente congestionando a IRQ atribu da ao barramento em que essa placa se encontra. Uma das formas para poder aumentar a capacidade do PABX e a forma ca o de arranjos computacionais. Tais sistemas, denominados de Clusters, se utilizam de t ecnicas e ferramentas espec cas para a distribui c ao de carga de processamento, redund ancia ou tanto balanceamento de carga como redund ancia. Neste projeto foi implementado um sistema que utiliza v arios servidores, balanceando carga entre elas, de forma a permitir uma maior capacidade no PABX com o Asterisk. As ferramentas escolhidas foram o DNS Round Robin e o DUNDi. Como PABX foi escolhido o DISC-OS (DISC-OS, 2007), distribui c ao baseada no Asterisk.

1.1 Objetivo

10

1.1

Objetivo

O objetivo geral deste trabalho e implementar um sistema capaz de melhorar o desempenho do DISC-OS, fazendo com que ele consiga atender uma carga maior de servi cos, com capacidade de espans ao se necess ario.

1.2

Organiza c ao do texto

O texto est a organizado da seguinte forma: No cap tulo 2 e apresentado a fundamenta c ao te orica que serviu de base para denir o rumo do projeto. No cap tulo 3 s ao apresentadas as ferramentas escolhidas para realiza ca o do Projeto. No cap tulo 4 s ao apresentados os experimentos realizados e os seus resultados. No cap tulo 5 s ao apresentadas as conclus oes sobre este projeto. Por m, no anexo A s ao apresentadas informa co es extras das instala c oes, congura co es e testes realizados.

11

Fundamenta c ao Te orica

2.1

Hist orico sobre Cluster

Em 1993 come ca-se a trabalhar em um sistema de Cluster distribu do usando computadores convencionais no lugar dos Mainframes. O projeto e batizado de Beowulf (MERKEY, 2004) . Ele obt em exito e acaba sendo usado pela Nasa entre outros. O primeiro prot otipo do Beowulf era composto de processadores DX4 e eram conectados por uma rede Ethernet 10Mbit/s. Em 1997 se usava 16 processadores P6 de 200 MHz e rede Ethernet de 100Mbiti/s (SUSIN, 2001).

2.2

Deni c ao de Cluster e apresenta c ao de seus componentes

Cluster e um sistema composto por dois ou mais computadores independentes e interligados entre si por alguma forma de rede (BAKER, 2000). Um cluster e composto tanto por hardware quanto por software, e juntos viabilizam o Cluster.

2.2.1

Hardware

Os hardwares principais associados ao Cluster s ao os n os (computadores independentes) executando algum processo e a rede de comunica ca o dedicada entre eles (BAKER, 2000). O n o possu v arios componentes que ir ao inuenciar na capacidade do Cluster. S ao eles o Processador, Mem oria, M dia de Armazenamento e Interface de Rede. Todos esses componentes j a est ao presentes tanto nas esta co es de trabalho quanto em servidores de alto desempenho, n ao sendo necess ario adquiri-los especicamente para realizar um Cluster

2.3 Tipos de Cluster

12

(BAKER, 2000). Para que os n os possam se comunicar e formar efetivamente um Cluster, e necess aria uma rede que os interligue. Clusters do tipo Beowulf usavam a tecnologia Ethernet para a interconex ao dos n os. Dependendo da necessidade de tr afego e da lat encia pode-se empregar t ecnicas de interconex ao espec cas para o Cluster (BAKER, 2000).

2.2.2

Software

Apenas possuir computadores independentes e uma interconex ao entre eles n ao forma um Cluster. O software deve ser capaz de prover a interliga c ao l ogica entre os n os e permitir o processamento paralelo (BAKER, 2000). Os softwares usados em Clusters s ao divididos em duas categorias: Ferramentas de Programa ca o e Sistema de Gest ao de Recursos (BAKER, 2000). As ferramentas de programa c ao fornecem linguagens, bibliotecas e ferramentas de debug para prover a programa c ao paralela (BAKER, 2000). Os sistemas de gest ao de recursos relacionam a instala c ao, congura c ao e administra ca o do hardware e do software existente (BAKER, 2000).

2.3

Tipos de Cluster

Os Clusters s ao classicados de Tr es formas (SILVA, 2005): Alta Disponibilidade Balanceamento de Carga Alto Desempenho Clusters de Alta Disponibilidade s ao arranjos de Failover (Redund ancia). Normalmente s ao constitu dos de servidores com a mesma fun ca o. Um servidor trabalha preferencialmente, e quando ele para de funcionar, o outro assume (SILVA, 2005). Clusters de Balanceamento de Carga s ao arranjos que tem o objetivo de dividir o processamento entre os servidores, fazendo com que cada servidor trabalhe uma requisi c ao dirente do processo. Normalmente possuem um elemento balanceador de carga, para dividir as requisi c oes (SILVA, 2005).

2.4 Softwares Capazes de Implementar um Cluster

13

Clusters de Alto Desempenho s ao arranjos que tem como objetivo dividir processamento, como no Balanceamento de Carga. Por em eles devem tratar partes de um mesmo processo, de forma a aumentar a performance do processamento. Normalmente se utilizam de processamento paralelo (SILVA, 2005).

2.4

Softwares Capazes de Implementar um Cluster

Alguns softwares que s ao capazes de implementar sistemas de Cluster est ao listados abaixo: DNS Round-Robin OpenMosix OpenMP PVM MPI O DNS Round-Robin e a capacidade que o servidor DNS tem de atribuir dois ou mais endere cos IP para um mesmo nome. Com isso pode-se realizar um balanceamento de carga simples. O OpenMosix e uma extens ao ao Kernel Linux que transforma uma rede de computadores em um super-computador. Os servidores com OpenMosix se monitoram am de saber se um servidor tem recursos dispon veis (processador e mem oria) para compartilhar. Quando encontra, o servidor com mais carga envia um ou mais processos para que o outro servidor possa auxili a-la (KNOX, 2002). O OpenMP e uma API para multiprocessamento para as linguagens C/C++ e Fortran. Pode ser usados em sistemas UNIX e no Windows NT. Ele prov e processamento paralelo (FRIEDMAN, 1997). O PVM e um programa que permite servidores UNIX e/ou Windows trabalharem em uma rede de dados distribuindo os seus processos para que esses sejam usados de forma paralela. A partir da sua terceira vers ao em 1993 adquiriu suporte a ` toler ancia a falhas (Fault-Tolerant) (PVM, 2007).

2.4 Softwares Capazes de Implementar um Cluster

14

O MPI e uma biblioteca para processamento paralelo. Ele prov e uma comunica ca o b asica entre os processadores. Como o OpenMP, e implementado em C/C++ e Fortran, al em de prover uma API para o processamento paralelo (GROPP; LUSK, 2005). Al em desses softwares, pode ser usado o OpenSER integrado ao Asterisk se o Cluster for uma central Telef onica VoIP. O OpenSER e um servidor SIP. Ele e bem mais leve que usado como servidor de registro e interligado ao o Asterisk como servidor de registro. E Asterisk que cuida dos servi cos. Existem tamb em softwares capazes de implementar Clusters em aplica co es espec cas. Um deles e o DUNDi. O DUNDi e um sistema para interliga c ao de PABX Asterisk. Possui uma rede pr opria para a pesquisa de n umeros de ramais, e usa os protocolos SIP/RTP, IAX2 ou H323 para a transmiss ao de voz. Os pacotes DUNDi usam o protocolo de transporte UDP. O DUNDi pode ser usado para balanceamento de carga.

15

Cluster Asterisk com DUNDi e DNS Round-Robin

Para a escolha dos softwares a serem utilizados no projeto foi feita uma pesquisa sobre os softwares citados no item anterior. Como o projeto tem como objetivo implementar um sistema de Cluster no Asterisk, mais precisamente usando o sistema DISC-OS, que usa o Asterisk 1.2, considerou-se o DUNDi a melhor op c ao, por ser um programa feito pelo pr oprio criador do Asterisk e imcorporado ao mesmo. Tamb em optou-se por implementar o DNS Round-Robin por se tratar de uma solu c ao muito simples e que poderia usada junto com outras solu c oes.

3.1

DNS Round-Robin

O DNS Round-Robin e uma forma de realizar um balanceamento de carga pelo pr oprio servidor DNS. Seu funcionamento consiste em dividir as conex oes entre os servidores. Essa divis ao e feita a partir do primeiro endere co cadastrado no arquivo at eou ltimo. Algo importante sobre o DNS Round-Robin e que ele n ao e uma solu c ao de redund ancia. Se um dos servidores parar de funcionar, o DNS Round-Robin continuar a mandando requisi co es para esse servidor.

3.2

DUNDi

Segundo J.R.Richardson (RICHARDSON, 2006a), DUNDi e um sistema peer-to-peer para localiza c ao de gateways Internet para servi cos de telefonia em um Cluster Asterisk. Diferente dos servi cos centralizados tradicionais (como o padr ao ENUM consideravelmente simples

3.3 Uso do DUNDi e do DNS Round-Robin para a forma c ao de um Cluster Asterisk

16

e conciso), o DUNDi e completamente distribu do sem nenhuma hierarquia centralizada.. Com o DUNDi e poss vel localizar uma extens ao em qualquer um dos servidores do Cluster. Para isso pode-se usar um servidor de consultas, que ser a respons avel por fazer todas as consultas, ou ligar os servidores do Cluster diretamente. O servidor de consultas ser a respons avel por procurar a extens ao nos servidores de registro. Se um dos servidores de registro falhar, ele continuar a procurando em outros servidores pela extens ao (MEGGELEN; SMITH; MADSEN, 2005) (RICHARDSON, 2006b). O DUNDi tamb em pode ser integrado ao Asterisk Realtime. Este e um sistema que permite ter a congura c ao do Asterisk num Banco de dados SQL. Com isso e poss vel realizar altera co es no plano de discagem sem ter de reiniciar o Asterisk (e perder as chamadas correntes). Outra utilidade e que se um dos servidores do Cluster DUNDi parar de funcionar, o Asterisk Realtime pode localizar e ligar essa extens ao mesmo que ela n ao esteja registrada (se ela for um ramal ou servi co que apenas se registrava no servidor). Existe tamb em a Rede DUNDi, ao qual participam algumas empresas do Brasil e do mundo. O seu objetivo facilitar a interliga c ao dos sistemas Asterisk, al em de facilitar a interconex ao com a PSTN.

3.3

Uso do DUNDi e do DNS Round-Robin para a forma c ao de um Cluster Asterisk

Ap os realizar a congura ca o do DNS Round-Robin e do DUNDi, foi vericado o seu comportamento:

3.3 Uso do DUNDi e do DNS Round-Robin para a forma c ao de um Cluster Asterisk

17

Figura 1: Cen ario inicial de testes Nesse caso, o DNS Round-Robin atua como se fosse um servidor proxy. Ele receber a a requisi ca o dos ramais para registro e enviar a para um dos PABX , balanceando as requisi c oes dos mesmos. O DUNDi permitir a a esses ramais se localizarem como se estivessem todos na mesma central. Supondo que o usu ario do ramal 9901, que est a registrado no PABX1 deseja falar com o usu ario do ramal 2010, que est a no PABX2, o usu ario do ramal 9901 discar a: 2010. O PABX1 vericar a se o ramal 2010 est a registrado nele para realizar a chamada. Ao vericar que ele n ao se encontra registrado, far a uma consulta DUNDi ao PABX2 para saber se o ramal est a registrado nele. Nesse caso receber a uma resposta armativa do PABX2. A partir desse ponto os dois PABX estabelecem um canal IAX para a chamada. Ent ao ela transcorre no PABX2 normalmente. Abaixo segue uma troca de sinaliza c ao DUNDi, para o exemplo anterior. Foi retirado do PABX onde estava o ramal 2010, logo a sinaliza ca o come ca com um pacote recebido. Foi gerado pelo console do Asterisk:

3.3 Uso do DUNDi e do DNS Round-Robin para a forma c ao de um Cluster Asterisk

18

Figura 2: Mensagens DPDISCOVER e DPRESPONSE Alguns par ametros dessas mensagens s ao (SPENCER, 2004): DIRECT EID = Identica ca o do outro n o do Cluster. Normalmente e usado o endere co MAC da interface de rede. CALLED NUMBER = N umero procurado. CALLED CONTEXT = Contexto onde a extens ao deve ser procurada. Na verdade o seu valor refere-se ao tronco que o DUNDi usar a para fazer a pesquisa. Na congura ca o do DUNDi se associa esse tronco ao contexto local onde deve existir o n umero procurado. Para mais detalhes sobre a congura ca o do DUNDi, olhar a se ca o 7.2. TTL = N umero de poss veis encaminhamentos desse pacote. N ao e igual ao TTL do IP. Para mais detalhes sobre o que e o TTL, olhar a se c ao 7.2. ANSWER = A resposta enviada pela mensagem DPRESPONSE. No caso de uma resposta armativa, usa-se o formato denido na congura c ao do DUNDi. Este pode ser consultado na se c ao 7.2. O objetivo da mensagem DPDISCOVER e dar in cio a procura de um n umero DUNDi dentro do Cluster. O DPDISCOVER inicia com uma opera c ao e e respondida inicialmente com um ACK (mensagem de conrma ca o de recebimento) e ent ao e seguida da mensagem DPRESPONSE. O objetivo da mensagem DPRESPONSE e responder uma DPDISCOVER. Existem mais mensagens, por em essas s ao as mensagens principais. O console do Asterisk tamb em exibe algumas mensagens relacionadas ` a criptograa, mas para uma an alise

3.3 Uso do DUNDi e do DNS Round-Robin para a forma c ao de um Cluster Asterisk

19

completa com todas as mensagens, e necess ario usar um programa para captura de pacotes. O comando dundi debug, e usado para ajudar a resolver problemas relacionados ao DUNDi. Mas supondo agora que o usu ario do ramal 9901, que est a registrado no PABX1 deseja falar com o usu ario do ramal 2015, que n ao est a registrado em nenhum PABX, o usu ario do ramal 9901 discar a: 2015. O PABX1 vericar a se o ramal 2015 est a registrado nele para realizar a chamada. Ao vericar que ele n ao se encontra registrado, far a uma consulta DUNDi ao PABX2 para saber se o ramal est a registrado nele. Nesse caso receber a uma resposta negativa do PABX2. Como n ao h a outro PABX para ser consultado, o PABX1 enviar a a mensagem not found que ser a convertida pelo softphone, ata ou telefone IP em tom de ocupado.

20

Experimentos Realizados

Para a realiza c ao dos testes de desempenho do DUNDi foram congurados dois cen arios. O primeiro cen ario congurado foi:

Figura 3: Cen ario de Teste sem Cluster Nesse caso, n ao h a cluster envolvido. Esse cen ario serve apenas para comparar o desempenho de um servidor rodando o DUNDi e um servidor sozinho. Para gerar o tr afego telef onico, foi usado o programa SIPp (SIPP, 2004). Foram gerados diferentes volumes de chamadas para a URA congurada no DISC-OS do servidor PABX1. O segundo cen ario congurado foi:

4 Experimentos Realizados

21

Figura 4: Cen ario de Teste com Cluster Cada um dos dois servidores do Cluster possui os mesmos ramais congurados (2002, 2010, 9001), o mesmo plano de discagem e os mesmos servi cos. Num primeiro momento esses ramais foram usados para testar o funcionamento correto do DUNDi. O DNS RoundRobin foi usado para distribuir os ramais nos servidores de forma transparente. Foi congurada uma URA (Atendimento Autom atico) com uma m usica de aproximadamente 7 minutos, para que todas as liga co es cassem estacionadas nessa URA (como se fossem liga c oes telef onicas). Para gerar o tr afego telef onico, foi usado o programa SIPp. Foram gerados diferentes volumes de chamadas para a URA congurada no DISC-OS do PABX1. Para que o DUNDi operasse nessa situa c ao, parte das chamadas foram geradas para o ramal 2010 (que estava cadastrado no PABX2). No PABX2, foi alterado o dialplan do ramal 2010 para que tudo o que viesse para esse ramal fosse encaminhado para a URA do mesmo servidor. Dessa forma, o PABX1 teve de fazer a consulta DUNDi para saber se o ramal 2010 estava presente no PABX2, e depois encaminhar a chamada via tronco IAX para o mesmo. A linha original:

exten => 2010,1,ChanIsAvail(IAX2/2010|sj) Foi mudado para:

exten => 2010,1, Goto(disc-ivr-7000,s,1)

4.1 Resultados

22

Sendo 7000 o n umero correspondente a URA congurada no PABX2.

4.1

Resultados

O PABX1 e composto de um processador Intel Pentium D 2.8GHz, com 4MB de mem oria cache L2, 512MB de mem oria RAM, Kernel 2.6.9 (CentOS 4). O PABX2 e composto de um processador Pentuim 4 3.0GHz, com 1MB de mem oria cache L2, 512MB de mem oria RAM, Kernel 2.6.9 (CentOS 4). Para gerar os dados, foi usado o comando vmstat. Ele mede n veis de processamento, mem orias e outros par ametros do sistema. As sa das do comando vmstat e sipp usadas na gera ca o desses gr acos est ao na se c ao 7.3. Nesse caso, foi aproveitado somente o n vel de processamento. O comando vmstat 5 10 indica que que est ao sendo feitas 10 amostras de 5 em 5 segundos. O u nico problema do comando vmstat e que a sua primeira amostra e imprecisa. Por isso aparecer ao valores na primeira amostra as vezes muito diferentes do resto das amostras. A primeira amostra deve ser sempre desconsiderada. Para gerar os gr acos, foi usado o software GNUPlot (GNUPLOT, 1999). Ele l e valores inscritos em arquivos de texto, linha a linha, separados por espa co. Como a sa da do comando vmstat na sua primeira possui os nomes dos campos do comando, o GNUPlot come cou a fazer os gr acos a partir da segunda linha. Logo, todos eles come cam a partir do valor 2 no eixo X. No eixo Y, os valores est ao referenciados em porcentagem, como na sa da do comando vmstat. Ap os os testes realizados, foram gerados os seguintes dados:

4.1 Resultados

23

Figura 5: 100 chamadas SIP em um u nico Servidor O par ametro IDLE e o percentual livre do processador. O par ametro US e o percentual de uso do processador com processos de usu arios. O par ametro SYS e o percentual de uso do processador com processos do sistema. Ao analisar esse gr aco, percebe-se que o PABX1 foi capaz de suportar a carga imposta sem diculdades, com um n vel de processamento livre acima de 80%. Nessa condi ca o, e poss vel ouvir nitidamente o som da URA, e ainda e poss vel ter outros servi cos rodando sem comprometer a qualidade do sistema.

4.1 Resultados

24

Figura 6: 50 chamadas SIP sendo tratadas e 50 sendo encaminhadas via DUNDi Ao analisar esse gr aco, percebe-se que o PABX1 foi capaz de suportar a carga imposta sem diculdades, com um n vel de processamento livre acima de 80%. Nessa condi ca o, e poss vel ouvir nitidamente o som da URA, e ainda e poss vel ter outros servi cos rodando sem comprometer a qualidade do sistema. Houve um aumento no n vel de processamento livre de aproximadamente 2% nesse servidor, o que de forma alguma justicaria o uso de uma solu c ao assim.

4.1 Resultados

25

Figura 7: 50 chamadas SIP recebidas via DUNDi Ao analisar esse gr aco, percebe-se que o PABX2 foi capaz de suportar a carga imposta sem diculdades, com um n vel de processamento livre acima de 90%. Nessa condi ca o, e poss vel ouvir nitidamente o som da URA, e ainda e poss vel ter outros servi cos rodando sem comprometer a qualidade do sistema.

4.1 Resultados

26

Figura 8: 200 chamadas SIP em um u nico Servidor Ao analisar esse gr aco, percebe-se que o PABX1 foi capaz de suportar a carga imposta sem diculdades, com um n vel de processamento livre acima de 60%. Nessa condi ca o, e poss vel ouvir nitidamente o som da URA, e ainda e poss vel ter outros servi cos rodando sem comprometer a qualidade do sistema.

4.1 Resultados

27

Figura 9: 100 chamadas SIP sendo tratadas e 100 sendo encaminhadas via DUNDi Ao analisar esse gr aco, percebe-se que o PABX1 foi capaz de suportar a carga imposta sem diculdades, com um n vel de processamento livre acima de 70%. Nessa condi ca o, e poss vel ouvir nitidamente o som da URA, e ainda e poss vel ter outros servi cos rodando sem comprometer a qualidade do sistema. Houve um aumento no n vel de processamento livre de aproximadamente 6% nesse servidor, o que n ao justicaria o uso de uma solu ca o assim.

4.1 Resultados

28

Figura 10: 100 chamadas SIP recebidas via DUNDi Ao analisar esse gr aco, percebe-se que o PABX2 foi capaz de suportar a carga imposta sem diculdades, com um n vel de processamento livre acima de 90%. Nessa condi ca o, e poss vel ouvir nitidamente o som da URA, e ainda e poss vel ter outros servi cos rodando sem comprometer a qualidade do sistema.

4.1 Resultados

29

Figura 11: 300 chamadas SIP em um u nico Servidor Ao analisar esse gr aco, percebe-se que o PABX1 foi capaz de suportar a carga imposta com grandes diculdades, com um n vel de processamento livre em torno de 25%. Nessa condi ca o, n ao e poss vel ouvir nitidamente o som da URA, j a que apesar de ter em m edia 25% de processamento livre, ocorrem alguns picos de processamento. Como o processador nesse caso n ao tem condi co es de processar tudo no instante do pico, acaba por fazer o a udio da URA sair com algumas falhas (picotamento). Para o tr afego em quest ao, n ao e aconselh avel usar esse servidor sozinho de forma alguma.

4.1 Resultados

30

Figura 12: 150 chamadas SIP sendo tratadas e 150 sendo encaminhadas via DUNDi Ao analisar esse gr aco, percebe-se que o PABX1 foi capaz de suportar a carga imposta sem diculdades, com um n vel de processamento livre em torno de 60%. Nessa condi ca o, e poss vel ouvir nitidamente o som da URA, e ainda e poss vel ter outros servi cos rodando sem comprometer a qualidade do sistema, desde que os outros servi cos n ao consumissem muito processamento. Houve um aumento no n vel de processamento livre de aproximadamente 35% nesse servidor, al em do fato de ser poss vel ouvir sem falhas o audio da URA. Isso justicaria o uso de uma solu c ao assim.

4.1 Resultados

31

Figura 13: 150 chamadas SIP recebidas via DUNDi Ao analisar esse gr aco, percebe-se que o PABX2 foi capaz de suportar a carga imposta sem diculdades, com um n vel de processamento livre pr oximo de 90%. Nessa condi c ao, e poss vel ouvir nitidamente o som da URA, e ainda e poss vel ter outros servi cos rodando sem comprometer a qualidade do sistema. Observando os gr acos, percebe-se que quanto maior o volume de tr afego, maior o ganho de processamento com o DUNDi. Mas apesar dos servidores com o DUNDi estarem relativamente folgadas com 150 chamadas cada, um fator fez com que n ao se avan casse sobre os testes. O m odulo chan iax, que implementa o IAX, limita o buer de dados com tamanho suciente de dados para 200 chamadas. Isso fez com que, ao testar com 200 liga co es via DUNDi e usar mais um ramal somente para escutar a URA como forma de vericar a qualidade do audio, o Asterisk exibisse um warninge o a udio n ao sa sse de forma adequada. Abaixo segue o aviso:

Feb 18 16:14:25 WARNING[5430]: chan\_iax2.c:3806 iax2\_trunk\_queue: Maximum trunk data space exceeded to 192.168.130.10:4569 Para contornar o problema, podem-se seguir as solu co es apresentadas no link abaixo: http://bugs.digium.com/view.php?id=8267

4.1 Resultados

32

Outra solu c ao para o caso seja necess ario mais de 200 chamadas via DUNDi e conguralo com o SIP. Perde-se o suporte a criptograa, mas se ganha na capacidade de liga co es sem congura co es adicionais.

33

Conclus oes

As t ecnicas de Cluster estudadas nesse trabalho mostraram cada uma a sua eci encia. O DNS Round-Robin foi capaz de distribuir os ramais entre os dois servidores congurados para responder ao dom nio usado no teste. Como j a e conhecido pelos seus adeptos, ele n ao faz por si s o o failover, por em e uma solu ca o muito simples de ser implementada. O DUNDi tem um ganho m nimo quando o volume de liga co es simult aneas e baixo (100 liga co es). Por em com o aumento do volume de tr afego (200 a 300 chamadas), o DUNDi se mostrou bastante eciente, pois conseguiu melhorar signicativamente o processamento. Nas refer encias usadas para auxiliar a congura c ao do DUNDi, normalmente ele vem associado ao Asterisk Realtime, por em por ser uma solu ca o muito complexa de implementar e n ao implementar sozinho nenhuma forma de Cluster, n ao foi integrada ao DUNDi. Apesar de poucos, os materiais que ensinam a congurar o DUNDi s ao sucientes para realizar a sua implementa c ao. Quando e feita uma nova instala ca o do Asterisk para congurar o DUNDi, a tarefa se torna um pouco simples. Por em quando se tem um sistema pronto que n ao foi concebido com o DUNDi, nesse caso o DISC-OS, a tarefa de implementar se torna mais complexa. Isso porque adaptar o DUNDi a um PABX j a congurado exige o conhecimento do sistema, al em de necessitar de cuidado para que n ao se percam as funcionalidades do PABX em fun ca o do uso do DUNDi.

34

ANEXO A -- Anexos

A.1

Congura c ao do Bind 9 para permitir o uso do DNS Round-Robin

Para habilitar o DNS Round-Robin no Bind 9 (BIND, 2000), deve-se apenas colocar os endere cos dos servidores e relaciona-los com o mesmo nome de servidor:

registro IN registro IN

A A

192.168.130.102 192.168.65.100

A.2

Instala c ao do DUNDi no DISC-OS

O DISC-OS n ao foi planejado para usar o DUNDi por padr ao. Por em n ao h a nada que impessa o DISC-OS de usar o DUNDi. Para usar o DUNDi no DISC-OS deve-se carregar o seu m odulo no arquivo /etc/asterisk/modules.conf:

load => pbx_dundi.so Al em dele, usaremos mais dois m odulos no sistema:

load => res_crypto.so load => app_chanisavail.so e o respons avel pelo suporte a criptograa no Asterisk. J a O m odulo res crypto.so o m odulo app chanisavail.so permite o uso da aplica ca o ChanIsAvail do dialplain do Asterisk.

A.2 Instala ca o do DUNDi no DISC-OS

35

Ap os colocar os m odulos no arquivo, reinicia-se o Asterisk para carregar os m odulos. Opcionalmente, pode-se carregar os m odulos usando o comando load no CLI do Asterisk. Por em ao reiniciar o asterisk, esta congura ca o ser a perdida. Depois de carregados os m odulos, e necess ario criar o arquivo /etc/asterisk/dundi.conf, pois o mesmo n ao vem por padr ao no DISC-OS. O arquivo pode ser encontrado em: http://www.voip-info.org/wiki/index.php?page=Asterisk+cong+dundi.conf O arquivo deve ter o dono asterisk e o grupo asterisk. Pode-se ent ao congurar o entroncamento entre as centrais via interface do DISC. Neste caso, foi feito usando IAX. Depois, edita-se o /etc/asterisk/iax.conf e adicionamos o seguinte par ametro no tronco:

dbsecret=dundi/secret O par ametro dbsecret dene a senha que ser a usada nas requisi co es para localiza ca o do ramal. Ent ao congura-se uma rota de entrada, uma rota de sa da para o tronco e os ramais: Depois de terminado o trabalho com a interface do DISC-OS, passa-se ent ao para a congura ca o do DUNDi e congura co es adicionais. Deve ser adicionado tanto no sip.conf como no iax.conf o seguinte par ametro dentro do contexto general:

regcontext=dundiextens regcontext: contexto que ser a dinamicamente criado (se o mesmo n ao existir) e ser a incluso uma extens ao com o comando NoOp quando um ramal se registrar no DISC-OS.

dundi.conf [general] entityid=00:13:72:02:F5:F6 cachetime=5 ttl=1

A.2 Instala ca o do DUNDi no DISC-OS

36

autokill=yes secretpath=dundi [mappings] dundi => dundiextens,0,IAX2,dundi:${SECRET}@192.168.65.100/${NUMBER},nopartial [00:13:72:02:F5:E3] model = symmetric host = 192.168.130.102 inkey = priv outkey = priv include = all permit = all qualify = yes order = primary Par ametros: entityid: Dene o identicador do peer na rede DUNDi. O padr ao e o endere co MAC da primeira interface de rede, mas e recomend avel especicar esse valor manualmente. cachetime: Dene o tempo de validade de uma consulta DUNDi. ttl: dene o n umero de saltos que o pedido DUNDi pode ter antes de ser descartado. autokill: Dene o que acontece quando um ACK n ao e recebido depois de 2 segundos. Quando setado em yes, ele cancela a requisi ca o. secretpath: Dene a fam lia da chave criada. O padr ao e dundi sendo que a chave ser a mantida em secret/dundi. A linha de mapeamento segue a seguinte sintaxe: dundi_context => local_context,weight,tech,dest[,options] Par ametros: dundi context: e o nome do contexto que ser a usado nas consultas DUNDi. local context: e o nome do contexto onde o servidor local buscar a o n umero para responder sobre a exist encia ou n ao desse n umero.

A.2 Instala ca o do DUNDi no DISC-OS

37

weight: e o peso para a resposta da requisi c ao. Quanto menor o n umero, maior a prioridade da sua resposta. Podem ser usados valores de 0 a 60000. tech: indica a tecnologia do ramal a ser buscado. Pode ser SIP, IAX2 ou H323. dest: dene os valores para que o destino encontre o n umero desejado. Tr es valores s ao repassados: $NUMBER: O n umero requisitado $IPADDR: O endere co IP a se conectar $SECRET: A senha que est a sendo usada no momento. Algumas op co es tamb em podem ser selecionadas. No nosso caso, foi usada a op c ao nopartial, que faz com que as respostas indiquem somente o valor exato que foi pedido, sem pesquisas parciais. Por u ltimo, vem a identica c ao do outro peer. O primeiro valor e o entityid do outro peer. Os outros par ametros s ao: model: Indica se a conex ao DUNDi ser a s o de envio, recebimento ou de envio e recebimento. o endere host: E co IP do outro peer. a chave que o outro peer usar inkey: E a para autenticar com este peer. a chave que ser outkey: E a usada por este peer para autenticar com o outro peer. include: Dene a permiss ao que o outro peer ter a de fazer consultas em um contexto particular deste peer. O valor all permite que o outro peer fa ca consultas em todos os contextos. permit: Dene a permiss ao que o outro peer ter a de fazer consultas no contexto DUNDi deste peer. O valor all permite que o outro peer fa ca consultas em todos os contextos. qualify: Tem a mesma fun ca o do autokill, por em e especicado na pr pria identica ca o do peer. order: Dene a ordem da pesquisa. Pode ser prim ario, secund ario, terce ario e quatern ario. Ap os congurar o DUNDi, passa-se para as congura c oes do plano de discagem:

A.2 Instala ca o do DUNDi no DISC-OS

38

extensions_disc.conf: [disc-ext-local] exten => 2002,1,ChanIsAvail(SIP/2002|sj) exten => 2002,2,Goto(disc-ext-local,2002,4) exten => 2002,3,Hangup exten => 2002,102,Goto(lookupdundi,2002,1) exten => 2002,103,Hangup exten => 2002,4,Macro(disc-exten-vm,novm,2002) exten => 2002,5,Hangup [disc-inrt-from_taho] exten => _[*#0-9].,1,Set(FROM_DID=${EXTEN}) exten => _[*#0-9].,2,Set(CDR(userfield)=from_taho) exten => _[*#0-9].,3,Macro(disc-blacklist,,${CALLERID(NUM)},in) exten => _[*#0-9].,4,Goto(disc-ext-local,${FROM_DID},1) extensions_local.conf: [lookupdundi] switch => DUNDi/dundi No contexto local do DISC-OS e usada a aplica c ao ChanIsAvail para vericar se o ramal est a registrado neste servidor ou n ao. Se estiver, ele e direcionado para o dialplain do DISC-OS para que seja realizada a chamada. Caso o ramal n ao esteja registrado, ele e enviado para o contexto lookupdundi, que ser a respons avel por fazer a consulta DUNDi. Na rota entrante, foi feita uma altera c ao para que as chamadas vindas do tronco usado para o DUNDi sejam direcionadas para o contexto local do DISC-OS. L ogica do plano de discagem: [disc-ext-local] exten => 2002,1,ChanIsAvail(SIP/2002|sj) Testa se o ramal (2002 SIP) est a registrado e dispon vel para receber uma chamada. Caso esteja ativo, ir a para a extens ao n+1 (2). Se n ao estiver, ir a para a extens ao n+101 (102).

A.2 Instala ca o do DUNDi no DISC-OS

39

exten => 2002,2,Goto(disc-ext-local,2002,4) A chamada e redirecionada para a prioridade 4 desse mesmo contexto.

exten => 2002,3,Hangup Desliga a chamada.

exten => 2002,102,Goto(lookupdundi,2002,1) A chamada e redirecionada para o contexto lookupdundi procurando pelo ramal 2002 na prioridade 1 desse contexto. exten => 2002,103,Hangup Desliga a chamada. exten => 2002,4,Macro(disc-exten-vm,novm,2002) chamada a macro disc-exten-vm informando que o mesmo n E ao possu voicemail habilitado e que se trata da extens ao 2002. Essa e a primeira sequ encia original do DISC-OS. exten => 2002,5,Hangup Desliga a chamada. [disc-inrt-from_taho] exten => _[*#0-9].,1,Set(FROM_DID=${EXTEN}) Seta a vari avel FROM DID com o valor da vari avel EXTEN. exten => _[*#0-9].,2,Set(CDR(userfield)=from_taho) Seta a vari avel CDR(usereld) com o nome da rota de entrada. exten => _[*#0-9].,3,Macro(disc-blacklist,,${CALLERID(NUM)},in)

A.2 Instala ca o do DUNDi no DISC-OS

40

Chama a macro disc-blacklist para testar se essa liga ca o n ao deve ser bloqueada. exten => _[*#0-9].,4,Goto(disc-ext-local,${FROM_DID},1) Envia a chamada para o contexto local, no n umero discado na prioridade 1. [lookupdundi] switch => DUNDi/dundi A partir daqui o DUNDi se encarrega de fazer a consulta no contexto de consultas. Ap os essas congura co es, reiniciamos o Asterisk, de forma a faze-lo reconhecer as altera co es realizadas.

A.2.1

Comandos para Testes

Alguns comandos do CLI do Asterisk podem ser usados para vericar o funcionamento das congura co es realizadas: dundi show peers: Mostra o estado das conex oes com os peers. Ex:

discOS2*CLI> dundi show peers EID 00:13:72:02:f5:e3 discOS2*CLI> Host 192.168.130.102 (S) Symmetric Model Unavail AvgTime OK (1 ms)

Sta

1 dundi peers [1 online, 0 offline, 0 unmonitored]

dundi lookup extens ao (Consulta o outro peer se a extens ao extens ao est a registrada nele) Ex:

discOS2*CLI> dundi lookup 2010@dundi 1. 0 IAX2/dundi:SGUBCZR+0GPV9MkTuQwsHA@192.168.130.102/2010 (EXISTS)

A.3 Sa da dos comandos vmstat e sipp

41

from 00:13:72:02:f5:e3, expires in 5 s DUNDi lookup completed in 15 ms discOS2*CLI>

A.3

Sa da dos comandos vmstat e sipp

Figura 14: Sa da do comando vmstat 5 10 para 100 chamadas SIP em um u nico PC

A.3 Sa da dos comandos vmstat e sipp

42

Figura 15: Sa da de status do SIPP para 100 chamadas SIP em um u nico PC

A.3 Sa da dos comandos vmstat e sipp

43

Figura 16: Sa da do comando vmstat 5 10 para 50 chamadas SIP recebidas e 50 encaminhadas via DUNDi

A.3 Sa da dos comandos vmstat e sipp

44

Figura 17: Sa da de status do SIPP para 50 chamadas SIP recebidas e 50 encaminhadas via DUNDi

A.3 Sa da dos comandos vmstat e sipp

45

Figura 18: Sa da do commando vmstat 5 10 para 50 chamadas recebidas via DUNDi

A.3 Sa da dos comandos vmstat e sipp

46

Figura 19: Sa da de status do SIPP para 50 chamadas recebidas via DUNDi

A.3 Sa da dos comandos vmstat e sipp

47

Figura 20: Sa da do comando vmstat 5 10 para 200 chamadas SIP em um u nico PC

A.3 Sa da dos comandos vmstat e sipp

48

Figura 21: Sa da de status do SIPP para 200 chamadas SIP em um u nico PC

A.3 Sa da dos comandos vmstat e sipp

49

Figura 22: Sa da do comando vmstat 5 10 para 100 chamadas SIP recebidas e 100 encaminhadas via DUNDi

A.3 Sa da dos comandos vmstat e sipp

50

Figura 23: Sa da de status do SIPP para 100 chamadas SIP recebidas e 100 encaminhadas via DUNDi

A.3 Sa da dos comandos vmstat e sipp

51

Figura 24: Sa da do commando vmstat 5 10 para 100 chamadas recebidas via DUNDi

A.3 Sa da dos comandos vmstat e sipp

52

Figura 25: Sa da de status do SIPP para 100 chamadas recebidas via DUNDi

A.3 Sa da dos comandos vmstat e sipp

53

Figura 26: Sa da do comando vmstat 5 10 para 300 chamadas SIP em um u nico PC

A.3 Sa da dos comandos vmstat e sipp

54

Figura 27: Sa da de status do SIPP para 300 chamadas SIP em um u nico PC

A.3 Sa da dos comandos vmstat e sipp

55

Figura 28: Sa da do comando vmstat 5 10 para 150 chamadas SIP recebidas e 150 encaminhadas via DUNDi

A.3 Sa da dos comandos vmstat e sipp

56

Figura 29: Sa da de status do SIPP para 150 chamadas SIP recebidas e 150 encaminhadas via DUNDi

A.3 Sa da dos comandos vmstat e sipp

57

Figura 30: Sa da do commando vmstat 5 10 para 150 chamadas recebidas via DUNDi

A.3 Sa da dos comandos vmstat e sipp

58

Figura 31: Sa da de status do SIPP para 150 chamadas recebidas via DUNDi

59

Refer encias
BAKER, M. Cluster computing white paper. In: PORTSMOUTH University of Portsmouth. 2000. Dispon vel em: <http://arxiv.org/ftp/cs/papers/0004/0004014.pdf>. Acesso em: 4 mar. 2008. BIND. [s.n.], 2000. Dispon vel em: <http://www.isc.org/index.pl?/sw/bind/index.php>. Acesso em: 4 mar. 2008. DISC-OS. [s.n.], 2007. Dispon vel em: <http://www.disc-os.org>. Acesso em: 4 mar. 2008. FRIEDMAN, R. OpenMP Architecture Review Board. [s.n.], 1997. Dispon vel em: <http://www.openmp.org/blog/about>. Acesso em: 27 nov. 2007. GNUPLOT. [s.n.], 1999. Dispon vel em: <http://www.gnuplot.info>. Acesso em: 4 mar. 2008. GROPP, W. D.; LUSK, E. The Message Passing Interface (MPI) standard. [s.n.], 2005. Dispon vel em: <http://www-unix.mcs.anl.gov/mpi>. Acesso em: 27 nov. 2007. KNOX, B. The OpenMosix Project. [s.n.], 2002. Dispon vel em: <http://openmosix.sourceforge.net>. Acesso em: 27 nov. 2007. MEGGELEN, J. V.; SMITH, J.; MADSEN, L. Asterisk: O futuro da Telefonia. In: . Tradu c ao de Armando Figueiredo e Betina Macedo. [S.l.]: Alta Books, Rio de Janeiro, RJ, 2005. MERKEY, P. Beowulf History. [s.n.], 2004. Dispon vel em: <http://www.beowulf.org/overview/history.html>. Acesso em: 8 fev. 2008. PVM. PVM Paralelal Virtual Machine. [s.n.], 2007. Dispon vel em: <http://www.csm.ornl.gov/pvm>. Acesso em: 27 nov. 2007. RICHARDSON, J. DUNDi, So Easy a Caverman Could Do It. [s.n.], 2006. Dispon vel em: <http://www.voip-info.org/wiki-DUNDi>. Acesso em: 16 jan. 2008. RICHARDSON, J. JR Richardson Writepaper. [s.n.], 2006. Dispon vel em: <http://www.voip-info.org/wiki-Asterisk+DUNDi+Call+Routing>. Acesso em: 11 nov. 2007. SILVA, G. P. Clusters. In: RIO DE JANEIRO,Universidade Federal do Rio de Janeiro. 2005. Dispon vel em: <http://equipe.nce.ufrj.br/gabriel/sispar/ArqPar6.pdf>. Acesso em: 25 fev. 2008. SIPP. [s.n.], 2004. Dispon vel em: <http://sipp.sourceforge.net>. Acesso em: 4 mar. 2008.

Refer encias

60

SPENCER, M. Universal number discovery (dundi) draft-mspencer-dundi-01. In: DIGIUM. 2004. Dispon vel em: <http://www.dundi.com/dundi.txt>. Acesso em: 25 fev. 2008. SUSIN, G. An alise de desempenho de um cluster para execu c ao do modelo de previs ao do tempo arps. In: FLORIAOPOLIS Universidade Federal de Santa Catarina. 2001. Dispon vel em: <http://www.tede.ufsc.br/teses/PGCC0470.pdf>. Acesso em: 22 jan. 2008.