DÊNIO ROBSON VAL SILVA FELIPE BARATOJO FLORES
NEIDE SOARES SALES
LINGUAGEM DE PROGRAMAÇÃO INTERPRETADA UTILIZADA
NA CONFIGURAÇÃO DE APLICATIVOS VOLTADOS PARA
SISTEMAS MULTI-PLATAFORMA COM IMPLEMENTAÇÃO EM
AMBIENTE PARAVIRTUALIZADO
São Paulo 2010
NEIDE SOARES SALES
LINGUAGEM DE PROGRAMAÇÃO INTERPRETADA
UTILIZADA NA CONFIGURAÇÃO DE APLICATIVOS
VOLTADOS PARA SISTEMAS MULTI-PLATAFORMA COM
IMPLEMENTAÇÃO EM AMBIENTE PARAVIRTUALIZADO
Orientador: Professor Msc. Luciano Freire
São Paulo 2010
Monografia apresentada como exigência parcial para a obtenção do título de bacharel em Ciência da Computação pela Universidade Anhembi Morumbi
DÊNIO ROBSON VAL SILVA FELIPE BARATOJO FLORES
NEIDE SOARES SALES
LINGUAGEM DE PROGRAMAÇÃO INTERPRETADA
UTILIZADA NA CONFIGURAÇÃO DE APLICATIVOS
VOLTADOS PARA SISTEMAS MULTI-PLATAFORMA COM
IMPLEMENTAÇÃO EM AMBIENTE PARAVIRTUALIZADO
Aprovado
______________________________________________________________________ Prof. Msc. Luciano Freire
Universidade Anhembi Morumbi
______________________________________________________________________ Prof...
Universidade Anhembi Morumbi
______________________________________________________________________ Prof. ...
Universidade Anhembi Morumbi
Monografia apresentada como exigência parcial para a obtenção do título de bacharel em Ciência da Computação pela Universidade Anhembi Morumbi
Dedicamos este trabalho de conclusão de curso a todos os nossos familiares que nos apoiaram, à Anhembi Morumbi por ter acreditado no Curso Superior em Ciência da Computação e ao orientador, Professor que, com dedicação e conhecimento, orientou-nos no decorrer deste trabalho.
Agradecemos aos colegas que contribuíram e incentivaram para a realização deste trabalho e também aos professores que com sabedoria nos acompanharam nestes anos em que decorreu o curso e, em especial, ao nosso orientador que nos acompanhou em todas as etapas deste trabalho. Também aos amigos e à família pela compreensão de nossa ausência para a elaboração do mesmo.
“Nossas dúvidas são traidoras e nos fazem perder o que, com freqüência, poderíamos ganhar, por simples medo de arriscar.” (William Shakespeare)
Esta monografia apresenta um breve estudo sobre a tecnologia da virtualização explorando os benefícios dos tipos de virtualização existentes, e principalmente da paravirtualização, com o objetivo de desenvolver uma linguagem interpretada para ser utilizada em aplicativos hospedeiros.
São praticamente inexistentes as linguagens de programação voltadas à configuração e, embora a linguagem seja voltada a qualquer plataforma, a implementação foi realizada em um ambiente paravirtualizado por facilitar a criação de ambientes diversificados sem necessidade de hardware adicional, apresentando um desempenho razoável.
Este trabalho não envolve a criação de um compilador, mas de uma linguagem, na condição de linguagem de extensão aplicada ao software hospedeiro Asterisk e às etapas para a implementação da mesma em um ambiente paravirtualizado.
Para o desenvolvimento deste trabalho, foi necessária a realização de um estudo a respeito dos tipos de virtualização, através da análise de documentos da IBM, Xen, VmWare e outros fabricantes importantes, para que então optássemos pela utilização do Xen como software de virtualização.
Quatro etapas principais foram necessárias para a conclusão do trabalho: a pesquisa a respeito das tecnologias existentes, tanto para virtualização como para utilização da linguagem interpretada; a criação do ambiente paravirtualizado; a criação da linguagem interpretada utilizada no aplicativo hospedeiro Asterisk e a junção do ambiente virtualizado criado com a linguagem desenvolvida.
This monograph presents a brief study about virtualization technology by exploring the benefits of existing virtualization types, and mainly the paravirtualization with the goal of developing an interpreted language to be used in host applications.
Practically it doesn’t exist programming languages directed to configuration and although the language is geared to any platform, the implementation was done in a paravirtualized environment by facilitating the creation of diversified environments without requiring additional hardware and showing reasonable performance.
The work does not involve the creation of a compiler, but a language, as an extension language applied to the host software Asterisk, and the steps to implement it in a paravirtualized environment.
To develop the work was necessary to carry out a study about the types of virtualization through documents from IBM, Xen, VmWare and other major manufacturers to take back the conclusion that we should use the Xen virtualization software.
Four main steps were necessary for completion of the work: research on existing technologies, for both to use virtualization as the interpreted language; the creation of paravirtualized environment; the creation of the interpreted language used in the host application Asterisk, and the join of the virtualized environment created with the language developed.
Figura 1 - Várias máquinas virtuais em um único hardware ... 17
Figura 2 – Tecnologia com mais impacto na transformação dos processos de negócio 20 Figura 3 - Emulação de hardware ... 21
Figura 4 - Virtualização completa ... 22
Figura 5 - Paravirtualização ... 23
Figura 6 - Virtualização de sistema operacional ... 24
Figura 7 – VmWare ESX ... 28
Figura 8 – Componentes do Xen ... 32
Figura 9 – User mode Linux ... 33
Figura 10 - Linguagem interpretada ... 38
Figura 11 - Linguagem compilada... 40
Figura 12 – Instalação Xen ... 44
Figura 13 – Instalando o Hypervisor e Ferramentas 1 ... 45
Figura 14 – Domínio 0 configurado ... 45
Figura 15 – Processo de inicialização... 47
Figura 16 – Tratamento de chamada ... 47
Figura 17 – Compilação do módulo ... 48
Figura 18 – Diretório de módulos do Asterisk ... 48
Figura 19 – Arquivo sip.conf ... 51
Figura 20 – Topologia final ... 59
Figura 21 – Módulo carregado com sucesso ... 60
Figura 22 – Módulo não carrega sem extensions.dfn ... 60
Figura 23 – CDR ... 61
Tabela 1 – Ferramentas de virtualização...26
Tabela 2 – Suporte Xen 3.0...30
Tabela 3 – Suporte Xen 2.0...31
AMD – Advanced Micro Devices
AMD-V – Advanced Micro Devices Virtualization
API (Application Programming Interface): Interface de Programação de Aplicações BIOS (Basic Input/Output System): Sistema básico de entrada/saída
CD-ROM (Compact Disk Read Only Memory): Disco Compacto com Memória somente leitura
CMS – Conversational Monitor System
CPU (Central Processing Unit): Unidade de Processamento Central GHz – Gigahertz
HD (Hard Disk): Disco Rígido IAX – Inter Asterisk Exchange
IBM – International Business Machines IDC – International Data Corporation
IDE (Integrated Development Environment): Ambiente de Desenvolvimento Integrado IETF – Internet Engineering Task Force
Intel-VT (Intel Virtualization Technology): Tecnologia de Virtualização da Intel KVM – Kernel-based Virtual Machine
MGCP – Media Gateway Control Protocol MIT – Massachusetts Institute of Technology PBX – Private Branch Exchanges
PSTN – Public Switched Telephone Network
SLA (Service Level Agreement): Acordo de Nível de Serviço TCP – Transmission Control Protocol
TI – Tecnologia da Informação UDP – User Datagram Protocol UML – User Mode Linux USB – Universal Serial Bus VBS – Visual Basic Script VGA – Video Graphics Array
VM (Virtual Machine): Máquina Virtual
VMM (Virtual Machine Monitor): Monitor de Máquina Virtual VoIP (Voice over IP): Voz Sobre IP
1.1 OBJETIVOS ... 15
1.2 JUSTIFICATIVA ... 15
1.3 ABRANGÊNCIA ... 16
1.4 ESTRUTURA DO TRABALHO ... 16
2 VIRTUALIZAÇÃO ... 17
2.1 INTRODUÇÃO SOBRE VIRTUALIZAÇÃO ... 17
2.2 HISTÓRIA DA VIRTUALIZAÇÃO ... 18
2.3 NECESSIDADE DA VIRTUALIZAÇÃO ... 19
2.4 EMULAÇÃO DE HARDWARE ... 21
2.5 VIRTUALIZAÇÃO COMPLETA ... 22
2.6 PARAVIRTUALIZAÇÃO ... 23
2.7 VIRTUALIZAÇÃO DE SISTEMA OPERACIONAL ... 24
2.8 HARDWARE COM SUPORTE À VIRTUALIZAÇÃO ... 24
3 FERRAMENTAS PARA VIRTUALIZAÇÃO... 26
3.1 BOCHS ... 26 3.2 QEMU ... 27 3.3 VMWARE ... 27 3.4 LINUX KVM ... 29 3.5 HYPER-V ... 29 3.6 XEN... 29 3.7 UML ... 33 4 ASTERISK ... 35 4.1 SIP ... 35 4.2 MGCP ... 36 4.3 IAX ... 36 5. LINGUAGENS DE PROGRAMAÇÃO ... 37 5.1 LINGUAGENS INTERPRETADAS ... 38
5.1.1 LINGUAGEM DE EXTENSÃO OU SCRIPT ... 39
5.2 LINGUAGENS COMPILADAS ... 40 6 METODOLOGIA ... 41 6.1 VIRTUALIZAÇÃO ... 41 6.2 LINGUAGEM INTERPRETADA ... 42 6.3 TESTES FINAIS ... 42 7 DESENVOLVIMENTO ... 44
7.3 INSTALAÇÃO ASTERISK ... 46
7.3.1 INTERAÇÃO ENTRE O ASTERISK E O MÓDULO DA LINGUAGEM DFN ... 47
7.4 DESENVOLVIMENTO DA LINGUAGEM INTERPRETADA PARA SISTEMA MULTI-PLATAFORMA ... 51
7.4.1 VARIÁVEIS E TIPOS ... 52
7.4.2 ATRIBUIÇÕES ... 53
7.4.3 OPERADORES ARITMÉTICOS E RELACIONAIS ... 53
7.4.4 ORDEM DE PRECEDÊNCIA DOS OPERADORES... 54
7.4.5 COMENTÁRIOS ... 54
7.4.6 FUNÇÕES DA LINGUAGEM ... 54
7.4.6.1 FUNÇÕES DE MANIPULAÇÃO DE STRING ... 54
7.4.7 CONTROLE DE FLUXO E LAÇOS ITERATIVOS ... 56
7.4.7.1 TOMADAS DE DECISÃO COM IF ... 56
7.4.7.2 LAÇOS ITERATIVOS COM TOMADA DE DECISÃO NO INÍCIO (WHILE) 57 7.4.7.3 LAÇOS ITERATIVOS COM TOMADA DE DECISÃO NO FIM (REPEAT/UNTIL) ... 57
7.4.8 ANALISADOR DE EXPRESSÃO ... 58
7.5 IMPLEMENTAÇÃO DA LINGUAGEM INTERPRETADA NO SISTEMA PARAVIRTUALIZADO ... 59
8 CONCLUSÃO ... 63
REFERÊNCIAS BIBLIOGRÁFICAS ... 64
APÊNDICE A – CÓDIGO FONTE DA LINGUAGEM ... 68
APÊNDICE B – ARQUIVOS DE CONFIGURAÇÃO DO ASTERISK E MÓDULO DE CARGA ... 143
1 INTRODUÇÃO
A virtualização possibilita a definição de diversas máquinas lógicas em apenas um único hardware, fazendo com que a utilização de recursos aumente, além de facilitar a consolidação e segurança de ambientes computacionais.
Segundo Bernard Golden e Clark Scheffy (2008, p.06 e 07), muitos data centers possuem máquinas sendo utilizadas com apenas 10% a 15% de sua capacidade total de processamento e, além disso, a necessidade de máquinas distintas para aplicações diferentes aumenta ainda mais a infra-estrutura, dificultando a administração, aumentando os gastos com manutenção, gerenciamento e energia.
Uma linguagem de programação interpretada como linguagem de extensão permite a utilização de aplicativos hospedeiros em ambiente multi-plataforma, pois esta não está vinculada à linguagem de máquina do ambiente e sim ao interpretador.
A razão para o desenvolvimento deste trabalho baseia-se no fato de que hoje em dia são praticamente inexistentes linguagens de programação voltadas à configuração de aplicativos que exijam agilidade na administração, alta disponibilidade e resiliência.
Alguns aplicativos já possuem essa tecnologia, como por exemplo, o software de PBX VoIP Asterisk, que pode fazer uso de linguagens de extensão como alternativa à utilização de arquivos de configuração para facilitar seu uso e administração.
1.1 OBJETIVOS
O objetivo deste trabalho é desenvolver uma linguagem de programação interpretada (extensível) para permitir maior flexibilidade na parametrização de aplicativos que necessitem do uso de configuração para o seu funcionamento. Como exemplo, esta linguagem será voltada para o software Asterisk. Será utilizada a paravirtualização como ambiente de implementação do Asterisk e da linguagem desenvolvida facilitando a administração e possibilitando um SLA (Service Level
Agreement) elevado.
1.2 JUSTIFICATIVA
A justificativa deste trabalho consiste nas dificuldades práticas em criar ambientes configuráveis de forma flexível. São praticamente inexistentes as linguagens de programação voltadas à configuração, principalmente no âmbito dos sistemas embarcados. Esta linguagem, ou mais precisamente, interpretador, é direcionado a qualquer plataforma. Entretanto, neste trabalho a implementação será realizada em um
ambiente paravirtualizado, visto que a paravirtualização é uma tecnologia que facilita a criação de ambientes diversificados, sem a necessidade de adquirir hardwares com suporte a virtualização, além de facilitar a implementação de máquinas adicionais com sistemas que podem ou não estar integrados uns com os outros e com confiabilidade. 1.3 ABRANGÊNCIA
Este trabalho abrange o desenvolvimento da linguagem na forma de interpretador na condição de linguagem de extensão, que será implementada em um ambiente paravirtualizado. Não faz parte do escopo deste trabalho o desenvolvimento de um compilador, mas sim de uma linguagem que possa ser embutida em outros aplicativos, que neste caso será no software Asterisk. O próprio software Asterisk é quem agirá como interpretador. Embora a virtualização não seja uma condição obrigatória para o uso da linguagem, ela será utilizada na implementação da solução, dada sua flexibilidade.
1.4 ESTRUTURA DO TRABALHO
A estrutura do trabalho está dividida nos seguintes capítulos:
O capítulo 2 aborda a definição de virtualização e as técnicas existentes.
O capítulo 3 aborda a explicação das ferramentas de virtualização mais conhecidas no mercado, tanto as livres quanto as pagas.
O capítulo 4 mostra o que é o Asterisk e suas principais características.
O capítulo 5 trata do conceito de linguagem interpretada com exemplos de aplicação.
O capítulo 6 aborda a metodologia do trabalho.
O capítulo 7 mostra a criação do ambiente paravirtualizado em preparação para implementação da linguagem interpretada, assim como os detalhes da criação da linguagem e utilização da API do Asterisk para que este entenda e interprete a linguagem desenvolvida. Além disso, haverá detalhes da implementação da linguagem no ambiente paravirtualizado, com considerações e resultados finais.
2 VIRTUALIZAÇÃO
Em meio às muitas tecnologias que surgiram nos últimos anos, a virtualização é um conceito que está sendo cada vez mais utilizado na área de tecnologia da informação. De acordo com a IBM (2005), a virtualização simplifica a infra-estrutura, reduz a complexidade e os custos otimizando os recursos. Para qualquer área dentro de uma empresa, a virtualização pode ser útil, pois muitos sistemas podem estar baseados e implementados em sistemas virtualizados, aumentando a disponibilidade, resiliência e facilitando a administração.
Sempre há prós e contras a respeito de qualquer conceito, inclusive a virtualização. Neste capítulo serão apresentados os conceitos, os tipos de virtualização mais conhecidos, os benefícios de se utilizar a tecnologia citada e a diversidade de ferramentas existentes.
2.1 INTRODUÇÃO SOBRE VIRTUALIZAÇÃO
De acordo com Bernard Golden e Clark Scheffy (2008, p.06 e 07), hoje muitos
data centers possuem máquinas sendo utilizadas com apenas 10% a 15% da capacidade
total de processamento. Em outras palavras, 85% a 90% da capacidade das máquinas não são utilizadas. Além disso, a necessidade de novas aplicações e sistemas faz com que novos servidores e máquinas de todos os tipos sejam adquiridos e que os data
centers precisem de cada vez mais espaço para disposição de servidores.
Figura 1 - Várias máquinas virtuais em um único hardware Fonte: VmWare (2008)
De maneira simples, a virtualização é uma técnica para se utilizar diversos sistemas operacionais distintos, mas em um único hardware, conforme ilustra a Figura 1.
De acordo com Jones (2006), virtualizar significa pegar algo que está em uma forma e fazê-la parecer de outra forma. Virtualizar um computador significa fazê-lo parecer múltiplos computadores ou um computador completamente diferente. Dependendo do ponto de vista, também pode significar fazer com que muitos computadores pareçam um único computador. Isto pode ser chamado de Server Agregation (agregação de servidores) ou Grid Computing (grid de computadores).
A virtualização emula componentes de hardware para o sistema operacional através de técnicas, hardwares e softwares de virtualização. Essas técnicas são hoje utilizadas tanto para desktops quanto para servidores.
O conceito de virtualização não é algo recente, mas após uma longa jornada passou a evoluir de maneira considerável nos últimos anos. Surgiram então diversas abordagens, mostrando varias vantagens e desvantagens dependendo da técnica a ser utilizada.
[...] Uma máquina virtual não pode ser comprometida pela operação de qualquer outra máquina virtual. Ela fornece um ambiente computacional privado, seguro e confiável para seus usuários. [...] Novas facilidades, como sistemas de banco de dados ou suporte a dispositivos especializados podem ser adicionados sem modificação ou corrompimento das atuais capacidades. [...] (CREASY, 1981, p.487)
2.2 HISTÓRIA DA VIRTUALIZAÇÃO
De acordo com a IBM (2006), a virtualização não é um tópico novo, pois o conceito de virtualização surgiu por volta do ano de 1960, quando a IBM, em conjunto com o MIT (Massachusetts Institute of Technology), tratava de um projeto chamado M44/44X. A meta era avaliar os conceitos de sistema de compartilhamento de tempo (Compatible Time-Share System, como era chamado). A máquina principal era um IBM 704 (M44) e cada máquina virtual era uma imagem experimental da máquina principal (44X). O espaço de endereçamento do 44X residia na hierarquia de memória do M44 e, além disso, era utilizado um sistema de memória virtual e multiprogramação.
Este Mainframe executava duas máquinas virtuais, uma para executar programas e outra para o sistema. O sistema operacional do Mainframe era chamado de Supervisor. Alguns anos depois a IBM desenvolveu os computadores da família 360. Foi lançado o Mainframe System/360. Nesse Mainframe o hardware era acessado pela interface chamada VMM (Virtual Machine Monitor). O VMM permitia a execução das máquinas virtuais onde cada máquina executava uma instância do sistema operacional principal.
O VMM executava diretamente na camada de hardware, permitindo múltiplas máquinas virtuais (VMs). Cada VM podia executar uma instância do sistema operacional – nos dias mais antigos isto era o CMS, ou Conversational Monitor System. A VM continuou a avançar, e hoje podemos encontrá-la sendo executada no mainframe System z9. Isto fornece compatibilidade antiga até mesmo com a linha System/360. (JONES, 2006)
De acordo com Manfrin (2010), na época, os Mainframes eram máquinas X86 com um grande poder de processamento, mas que não eram completamente aproveitadas, utilizando somente de 10 a 15% de sua capacidade, pois normalmente eram implementadas para aplicações específicas, diminuindo os riscos de ficarem fora de produção.
2.3 NECESSIDADE DA VIRTUALIZAÇÃO
De acordo com a VmWare (2010), a virtualização foi praticamente abandonada durante os anos 80 e 90, quando aplicações cliente-servidor, servidores e desktops X86 começaram a ser distribuídos. A adoção de sistemas operacionais Linux e Windows como sistemas para servidores começaram a ser o padrão da indústria. Com esse crescimento de servidores e desktops X86, passou a surgir uma nova infra-estrutura de TI e novos desafios operacionais. A VmWare, uma das empresas que fornecem tecnologia de virtualização, informa que alguns desses desafios são:
- Baixa utilização de infraestrutura. De acordo com a IDC (International Data Corporation), a distribuição de servidores x86 atinge uma média de utilização de 10% a 15% da capacidade total. As organizações geralmente executam uma aplicação por servidor para evitar riscos de vulnerabilidade, ou seja, para que problemas afetando uma aplicação, não afetem a disponibilidade de outra que esteja no mesmo servidor;
- Aumento do custo da infraestrutura física. É necessário suprir os custos operacionais do crescimento da infraestrutura. A maioria dos ambientes computacionais precisa estar disponível em quase 100% do tempo, resultando em consumo de energia, resfriamento, e custos que não variam;
- Aumento do custo de gerenciamento de TI. Devido aos ambientes computacionais se tornarem mais complexos, os custos associados ao nível de educação especializada e experiência requerida para o gerenciamento da infraestrutura aumentam consideravelmente;
- Proteção insuficiente contra desastres e falhas. Organizações são afetadas devido à inacessibilidade a aplicações críticas. Ameaças a segurança por meio de ataques, desastres naturais e terrorismos aumentaram a importância do planejamento continuo dos negócios, tanto para desktops como para servidores; - Alta manutenção de desktops de usuários finais. Diversos desafios são apresentados às empresas quando gerenciam e fornecem segurança para desktops. Controlar e gerenciar um ambiente de desktop distribuído, com diretivas de acesso e segurança sem impactar na habilidade do usuário de trabalhar efetivamente, é complexo e caro.
De acordo com uma pesquisa realizada com empresas de IT (Information Technology) e com LOB (Line Of Business – outras áreas de negócio) pela IDC (2008), a tecnologia que tem mais impacto na transformação dos processos de negócio na área de TI, conforme Gráfico 1, é a virtualização.
Figura 2 – Tecnologia com mais impacto na transformação dos processos de negócio
Devido a essas e outras necessidades, as técnicas de virtualização foram surgindo e evoluindo em grande escala. Segundo a Gartner (2008), é esperado que o número de computadores virtualizados cresça de menos de 5 milhões em 2007 para 660 milhões em 2011, e Pettey (2008) diz que a virtualização é o problema que terá maior impacto até 2012, modificando infraestruturas e operações e modificando também a maneira de comprar e de gerenciar.
2.4 EMULAÇÃO DE HARDWARE
De acordo com Jones (2007), a emulação de hardware nada mais é do que a virtualização do hardware. Provavelmente quando se fala em virtualização, a emulação de hardware é indicada como a mais complexa. Através das camadas virtuais de hardware é possível criar diferentes ambientes utilizando a mesma máquina física, conforme ilustra a Figura 2.
Com a emulação de hardware alguns benefícios são apresentados, como por exemplo: É possível simular diversos processadores, mesmo que o hardware real possua apenas um processador físico. Pode-se também executar diversas máquinas virtuais, cada uma simulando um processador diferente.
Uma das utilizações mais importantes da emulação de hardware é no desenvolvimento de firmware e hardware. Ao invés de esperar até que o hardware esteja disponível, os desenvolvedores de firmware podem utilizar o hardware VM alvo para validar muitos aspectos de seus códigos atuais em simulação. (JONES, 2006)
Este tipo de virtualização precisa de um software que entenda as instruções da arquitetura que se deseja emular. Esta é a técnica utilizada pelos desenvolvedores de emuladores de vídeo-game, na qual o software irá converter as instruções recebidas da
Figura 3 - Emulação de hardware Fonte: IBM (2006)
arquitetura em que se está emulando, para que o sistema operacional convidado (também conhecido por GuestOS) possa entender as instruções.
2.5 VIRTUALIZAÇÃO COMPLETA
De acordo com a VmWare (2007) a virtualização completa é uma técnica utilizada para fornecer um ambiente de máquina virtual, que simula de maneira completa o hardware como réplica do hardware real.
Segundo Menascé (2005), o sistema operacional executado através de virtualização completa, que pode ser chamado de sistema operacional convidado, não necessita de modificações, visto que é executado através do VMM, o monitor de máquina virtual. O VMM é uma camada de software mais próxima ao hardware. Esta camada, que está entre o hardware e o sistema operacional convidado concede uma abstração da máquina virtual, conforme ilustra a Figura 3. O VMM suporta um número muito grande de dispositivos. Por isso a Virtualização completa utiliza dispositivos genéricos para fazer com que a máquina virtual execute. O fato destes dispositivos não serem específicos faz com que o desempenho da máquina virtual não seja atingido em sua totalidade. A máquina virtual acredita ser executada em um hardware real. Logo, o VMM precisa testar as instruções passadas pela máquina virtual para que em seguida as execute diretamente no hardware. Isso também acontece quando o hardware fornece alguma instrução, pois o VMM primeiro interpreta e testa a instrução antes de passar para a máquina virtual. Além dos aspectos citados, o VMM ainda precisa controlar alguns aspectos relacionados à disputa de recursos, o que causa certa queda de desempenho, visto que os sistemas operacionais foram desenvolvidos para não coexistirem com outros tentando utilizar os mesmos recursos.
Figura 4 - Virtualização completa IBM (2006)
2.6 PARAVIRTUALIZAÇÃO
Segundo Origuela (2006), a técnica de paravirtualização utiliza um conceito parecido com o da virtualização completa. Nesta, o sistema operacional convidado é alterado para interagir com o VMM, para então decidir quais instruções devem ser interpretadas nele ou diretamente no hardware. Os drivers de dispositivos de sistemas paravirtualizados entendem que estão sendo executados como um sistema virtualizado, por isso, durante as requisições, os drivers dos dispositivos da máquina convidada conversam com os drivers reais do sistema operacional principal.
De acordo com Jones (2007) a técnica de paravirtualização não simula recursos de hardware, mas ao invés disso oferece uma interface de programação de aplicação (API) para as máquinas virtuais hospedadas, e para isso, o sistema operacional precisará ter sido modificado para suportar tal interface. A paravirtualização é suportada em sistemas que foram modificados para entender que certas requisições, que seriam feitas diretamente ao hardware físico, deverão na verdade ser realizadas primeiramente ao VMM ou Hypervisor, como é chamado muitas vezes, para que o VMM se comunique com o host e aja diretamente no hardware, para então devolver as respostas das requisições.
A paravirtualização utiliza o conceito de domínios. Existe um domínio chamado domínio zero, onde reside o sistema operacional que tem acesso direto ao hardware. Este domínio precisa possuir um sistema que foi modificado para suportar paravirtualização como domínio zero, e é através dele que é realizado o gerenciamento das máquinas virtuais.
Figura 5 - Paravirtualização Fonte: Uberhip (2007)
Além do domínio zero, existe o domínioU, onde residem as máquinas virtuais. Cada máquina virtual que reside em um domínioU também precisa ter sido modificada. Cada domínioU executa uma instância completa de um sistema operacional.
Para utilizar a paravirtualização, não é necessária a utilização de hardware com suporte à virtualização, pois os sistemas operacionais já são modificados para suportar esta técnica, conforme ilustra a Figura 4.
De acordo com a IBM (2006), a paravirtualização oferece um desempenho muito próximo ao de sistemas não virtualizados.
2.7 VIRTUALIZAÇÃO DE SISTEMA OPERACIONAL
De acordo com o arquiteto da Microsoft Chantry (2009), a técnica da Virtualização de sistema operacional utiliza um sistema operacional como sistema base. Os sistemas convidados compartilham os mesmos recursos e drivers do sistema operacional base, mesmo que pareçam computadores totalmente separados, conforme ilustra a Figura 5. Cada sistema operacional convidado terá o seu próprio sistema de arquivos, endereço IP, configurações de servidor e executarão aplicativos totalmente diferentes.
Figura 6 - Virtualização de sistema operacional Fonte: Chantry (2009)
2.8 HARDWARE COM SUPORTE À VIRTUALIZAÇÃO
Diversas técnicas de virtualização existem hoje e, além disso, muitos softwares são construídos com base em uma técnica. Além da construção de softwares com suporte à virtualização, existem hardwares que são produzidos para auxiliar tais softwares na execução de tarefas essenciais, de acordo com a Intel (2010).
A Intel lançou a tecnologia Intel VT (Intel Virtualization Techonlogy) que está presente em diversos processadores para auxiliar softwares de virtualização e, de acordo com a Intel (2010), proporcionar a utilização máxima do sistema por meio de consolidação de ambientes em um único servidor ou PC.
Além da Intel VT a empresa AMD possui a tecnologia chamada AMD-V. De acordo com a AMD (2009) a tecnologia foi desenvolvida para aumentar drasticamente o desempenho da aplicação virtualizada, possibilitando também a alternância mais rápida entre máquinas virtuais, para que mais máquinas virtuais possam ser hospedadas por servidor, maximizando os benefícios da virtualização.
Os hardwares com suporte à virtualização auxiliam os softwares de virtualização para que os sistemas operacionais não precisem ser modificados para poderem ter um melhor desempenho durante sua execução.
Alguns softwares de virtualização funcionam com um bom desempenho apenas quando o hardware possui suporte à virtualização. Entretanto, há softwares que não necessitam de hardware com suporte à virtualização, mas que conseguem um ótimo desempenho durante a execução de máquinas virtuais devido ao fato de os sistemas operacionais terem sido modificados para tal.
3 FERRAMENTAS PARA VIRTUALIZAÇÃO
Diferentes ferramentas estão disponíveis hoje e cada uma utiliza uma técnica de virtualização diferente. Na Tabela 1, pode-se visualizar as principais ferramentas disponíveis e os tipos de virtualização que utilizam. Cada ferramenta possui seus pontos fortes e fracos, incluindo ferramentas livres e pagas.
Tabela 1 – Ferramentas de virtualização Fonte - O autor
Ferramenta Tipo
Bochs Emulação
QEMU Emulação
VMWare Virtualização completa
Linux KVM Virtualização completa
Hyper-V Virtualização completa – Paravirtualização Xen Paravirtualização – Virtualização completa UML Paravirtualização
Linux V-server Virtualização de sistema operacional Open VZ Virtualização de sistema operacional
3.1 BOCHS
A ferramenta Bochs (que se pronuncia Box) é um emulador de software que não possui interface gráfica. A ferramenta é livre e emula computadores Intel x86. De acordo com a Bochs (2009), o Bochs emula apenas máquinas i386, i486, Pentium, Pentium Pro da Intel e CPUs AMD64, além de periféricos comuns como discos, memória, monitor e dispositivos de rede. A ferramenta foi desenvolvida em C++ e seu código pode ser compilado em basicamente qualquer plataforma, seja em Windows, MacOS X ou em várias versões de Unix. O software foi escrito por Kevin Lawton que ainda o mantém.
O Bochs foi criado para emular sistemas operacionais Linux, DOS e Windows 95/98/XP/2000/NT.
O fato de ser compatível com diversas plataformas é um ponto forte e ao mesmo tempo fraco em relação a outras máquinas virtuais, visto que os equipamentos como BIOS, placas de vídeo, som e basicamente todos os componentes são emulados através
do software, o que faz com que a portabilidade seja maior, mas a velocidade passa a ser menor.
3.2 QEMU
De acordo com Bellard (2005), o próprio desenvolvedor do Qemu, o software suporta dois modos operacionais: a emulação em modo de usuário e a emulação em modo de sistema. A emulação em modo de usuário permite que um processo construído para executar em certa CPU possa ser executado em outra, utilizando um conversor dinâmico como técnica para emulação, para que as partes do código sejam convertidas de maneira que o processador execute o conjunto de instruções. A emulação em modo de sistema permite a emulação de um sistema integral, incluindo processador e periféricos de diferentes tipos.
[...] o QEMU como um emulador do sistema PC fornece uma extensa variedade de periféricos.[...] Um emulador Vídeo Graphics Array (VGA) de hardware, mouse e teclado PS/2, disco rígido e interface de CD-ROM do Ambiente de Desenvolvimento embarcado (IDE) e emulação de disco flexível. [...] Inclui a emulação para um adaptador de rede NE2000, portas seriais, numerosas placas de som e um controlador Universal Serial Bus (USB).[...] (Jones, 2007)
Bellard (2005) também informa que para otimizar a emulação alguns módulos, aceleradores Qemu podem ser instalados fazendo com que o desempenho quase nativo possa ser obtido, permitindo que o código emulado seja executado diretamente na CPU real (do host).
A princípio, o Qemu foi desenvolvido para executar um sistema operacional em outro, como um Windows em um Linux ou um Linux em um Windows. Ele pode executar em diversos sistemas operacionais como Linux, Windows e MacOs X.
O ponto forte do Qemu é o fato de possuir um conversor dinâmico, rápido e portátil, que traduz as instruções para a CPU convidada vindas da CPU host, fornecendo assim a emulação. O conversor pode fazer cache de trechos de código para minimizar a sobrecarga, tornando-o mais rápido.
3.3 VMWARE
A empresa VmWare (2010) fornece uma variedade de ferramentas para virtualização, desde softwares gratuitos para virtualização de desktops e servidores, até
plataformas abrangentes de nível empresarial para otimização de data centers e da infraestrutura de TI. As ferramentas gratuitas são limitadas, enquanto as pagas fornecem recursos bem mais avançados.
Diversos produtos são disponibilizados pela VmWare (2010), como por exemplo o VmWare Workstation, VmWare Server, VmWare Player, que são ferramentas de virtualização que executam em um sistema hospedeiro. Existe outra plataforma chamada VmWare ESX, ilustrada na Figura 6, que por si mesma é um sistema operacional hospedeiro baseado em Linux.
Figura 7 – VmWare ESX Fonte: VmWare (2010)
Pelo fato de utilizar virtualização completa, todos os componentes de hardware são virtualizados, e o suporte para todos os dispositivos são fornecidos pelo próprio sistema operacional hospedeiro. O VmWare utiliza drivers genéricos para os dispositivos, chamado de VMDriver. Pelo fato de utilizar dispositivos genéricos, o desempenho das máquinas diminui.
De acordo com a VmWare (2010), o desempenho do VmWare ESX chega a ser melhor do que as ferramentas que precisam de um sistema hospedeiro, mas a portabilidade diminui devido a limitações do próprio sistema. O VmWare possui ferramentas com interface gráfica que facilitam a administração das máquinas virtuais existentes. O VmWare faz uso do VMM, que intercepta e testa as instruções passadas pela máquina virtual para poder então executá-las diretamente no hardware. O mesmo acontece quando o hardware fornece alguma instrução, pois o VMM a interpreta e passa para a máquina virtual. Além disso, os recursos da máquina hospedeira são disputados
pelas máquinas virtuais, e por isso o VMM também realiza o controle desses recursos, o que causa mais queda no desempenho.
3.4 LINUX KVM
De acordo com os desenvolvedores do KVM (2010), KVM significa Kernel-based Virtual Machine. O Linux KVM é um framework de virtualização completa que utiliza as tecnologias de virtualização Intel-VT e AMD-V, que estão nos processadores mais recentes. O KVM é uma ferramenta livre e está presente no Kernel Linux 2.6.20, e é possível executar qualquer sistema operacional sem que nenhuma modificação seja realizada, desde que haja tecnologia de virtualização embutida no processador. Cada máquina virtual é tratada como um processo Linux, por isso pode-se manipular as máquinas com comandos de manipulação de processos.
3.5 HYPER-V
Hyper-V é a solução de Virtualização completa Microsoft parecido com as ferramentas VmWare. Além disso, de acordo com a Microsoft (2010), a ferramenta suporta paravirtualização para sistemas operacionais que são modificados para tal. A Microsoft possui o Hyper-V Standalone como sendo o próprio sistema hospedeiro além de possuir a opção de ser executado em um host Windows Server 2008. Quando adquirido o Windows Server 2008 R2, o Hyper-V faz parte do sistema, não sendo necessário adquirir licenças. Para a utilização de alguns recursos, o Hyper-V necessita do System Center Virtual Machine Manager, que necessita de licenças para funcionar.
A Microsoft (2010) informa que para o funcionamento do Hyper-V é necessário possuir as tecnologias de aceleração de virtualização nos processadores como Intel VT ou AMD-V. O Hyper-V é uma ferramenta que ainda está em aperfeiçoamento, mas possui alguns benefícios por ser desenvolvido pelo próprio fabricante do Windows, o que traz algumas compatibilidades e facilidades na administração.
3.6 XEN
O Xen (2010) é uma ferramenta de paravirtualização que também suporta virtualização completa quando o hardware possui suporte a tecnologia Intel VT ou AMD-V, que foi desenvolvido em um projeto na Universidade de Cambridge, que mais tarde tornou-se a empresa XenSource Inc, e então foi adquirida pela Citrix System em outubro de 2007. O Xen possui um desempenho melhor do que os produtos que utilizam virtualização completa quando o hardware da máquina física não possui suporte a
virtualização. Na virtualização completa, algumas tarefas que precisam ser executadas pelas máquinas virtuais não podem ser executadas diretamente no processador, pois são tratadas como um processo na camada de aplicação da máquina hospedeira. Com isso, o VMM intercepta as tarefas, e as executa. Isto causa certa perda de desempenho em hardwares sem suporte à virtualização. Já na paravirtualização, os sistemas operacionais a serem executados, precisam ser modificados para que estas tarefas específicas, que precisariam ser executadas na CPU, possam ser diretamente executadas no VMM, sem haver a tentativa de acesso direto a CPU e sem que o VMM as intercepte, trazendo ganho de desempenho.
Uma grande vantagem do Xen é que ele pode executar máquinas virtuais em hardwares que não possuem suporte à virtualização, com um desempenho muito próximo ao da máquina nativa. Apesar disso, os sistemas operacionais precisam ser modificados para funcionarem.
Hoje já existem diversos sistemas com suporte ao Xen, como o Linux, FreeBSD e Windows, mas alguns necessitam de tecnologia de hardware Intel VT ou AMD-V para utilizar a virtualização completa, e outros já possuem o código modificado para utilizar paravirtualização.
Nas Tabelas 2 e 3 são citados os sistemas operacionais que suportam o Xen como servidor e como máquina convidada.
Tabela 2 – Suporte Xen 3.0 Fonte: O autor
OS Executar como
Dom0 (host)
Executar como domU (convidado)
Linux 2.6 Sim Sim
NetBSD 3.1 Não Sim
NetBSD 4.0_Beta2 e atual Sim Sim
FreeBSD 5.3 Não Sim
FreeBSD 7 Não Sim
Solaris 10 Não Sim
Sistemas Operacionais não Modificados
Não Sim, somente quando o hardware possui suporte Intel VT ou AMD-V
Tabela 3 – Suporte Xen 2.0 Fonte: O autor Sistema operacional Executar como
Dom0 (host)
Executar como domU (convidado)
Linux 2.4 Sim Sim
Linux 2.6 Sim Sim
NetBSD 2.0 Não Sim
NetBSD 3.0 Sim Sim
Plan 9 Não Sim
FreeBSD 5 Não Sim
De acordo com a Xen (2008), cada máquina virtual é chamada de domínio. Existem dois tipos de domínio: o domínio 0 (chamado de domain0 ou dom0), que é o domínio de controle, e o domínio U (chamado domainU ou domU), que é o domínio sem privilégios, ou seja, o sistema operacional convidado. Cada domínio executa uma instância completa do sistema operacional.
Figura 8 – Componentes do Xen Fonte: Carissimi (2008)
Para que o Xen ofereça suporte tanto à virtualização completa quanto à paravirtualização, é utilizado o conceito dos domínios explicado anteriormente, com algumas modificações. O Xen reconhece os domínios U-PV, como domínios paravirtualizados e U-HVM (hosted virtual machines) como domínios virtualizados. Os domínios U-PV são os domínios que possuem os sistemas operacionais modificados, que sabem que existem outras máquinas virtuais e possuem drivers específicos para acesso à rede e disco e, além disso, sabem como interagir com o domínio 0. Os domínios U-HVM não são modificados, ou seja, não sabem que existem outras máquinas virtuais e por isso não possuem drivers específicos para o acesso a recursos, necessitando do hardware com suporte à virtualização para que o desempenho não caia, conforme ilustra a Figura 7.
De acordo com a Xen (2008), para que o domínio U-HVM funcione, ele faz o uso do Qemu (o emulador de software), e os recursos de hardware que são disponíveis para o domínio são os mesmos oferecidos pelo Qemu.
3.7 UML
UML (User mode Linux) permite que um sistema operacional Linux execute outro sistema operacional Linux como convidado através da paravirtualização. De acordo com Dike (2010), cada sistema operacional Linux convidado existe como um processo no host Linux. Isto permite que vários Kernels de versões diferentes possam ser executados em uma única versão de Kernel Linux, conforme ilustra a Figura 8.
Figura 9 – User mode Linux Fonte: IBM (2006)
Um dos grandes benefícios e foco do UML é poder realizar testes em versões de Kernels Linux diferentes sem prejudicar o host Linux principal. O UML também fornece mais recursos de hardware e software do que os da máquina física (host).
Jones (2007) explica que os Kernels convidados executam no espaço de aplicação, e para funcionarem precisam ter sido compilados para tal, enquanto o Kernel Host reside diretamente no hardware.
4 ASTERISK
O Asterisk é um software livre que implementa recursos de PBX completo e muitas outras funções através da tecnologia de VoIP. Mark Spencer da Digium Inc. foi quem iniciou o projeto por volta do ano de 1999. Inicialmente o Asterisk foi desenvolvido para implementar apenas recursos em software como um PBX de código aberto, mas de acordo com Davenport (2010), hoje o Asterisk implementa não apenas recursos de sistemas PBX, mas também gateways VoIP, sistemas de Call Center, pontes de conferência, servidores voicemail e todos os tipos de aplicativos que envolvam comunicação em tempo real.
O sistema roda em servidores Linux e faz VoIP através de três diferentes protocolos. De acordo com a Asterisk Brasil (2010), o Asterisk pode se integrar a praticamente todos os padrões de telefonia utilizando hardware de baixo custo. Ele é um servidor de comunicação que detém todos os níveis baixos de detalhes para envio e recebimento de dados utilizando alguns diferentes tipos de protocolos. Os protocolos utilizados pelo Asterisk são protocolos abertos como o SIP, MGCP e IAX, os quais realizam a sinalização das chamadas telefônicas na rede IP.
Após a instalação do Asterisk, um servidor de comunicação passa a existir, mas para que ele realmente se comunique, é preciso criar aplicativos de comunicação realizando e alterando configurações, que o fará funcionar da maneira planejada. Estes aplicativos de comunicação são construídos através de scripts, arquivos de configuração, gravações de áudio, banco de dados, serviços web, etc. Para que um aplicativo de comunicação funcione, é preciso que o servidor de comunicação esteja conectado a serviços de comunicação como VoIP ou PSTN. Para que as pessoas acessem o sistema de comunicação, é preciso ter números de telefones ou URLs VoIP que enviem chamadas ao servidor.
4.1 SIP
De acordo com a IETF (2010), o SIP é um protocolo IETF (RFC 2543, 1999) de aplicação parecido com o HTTP ou SMTP, que segue o modelo requisição-resposta para iniciar sessões de comunicação VoIP e outras sessões de texto e multimídia, como mensagens instantâneas, vídeo, jogos online e outros serviços. Para comunicação, ele utiliza a porta 5060 tanto UDP como TCP. Alguns recursos que o protocolo oferece na parte de telefonia são: transferências de chamada, conferências telefônicas e chamadas em espera. Por ser um protocolo flexível, é possível adicionar mais recursos ao SIP.
4.2 MGCP
De acordo com a Arango (1999), o MGCP também é um protocolo do grupo IETF que integra a arquitetura SS7 em redes VoIP. A arquitetura SS7 é uma rede de pacotes que se agrega à rede de telecomunicação, adicionando novas funcionalidades e serviços que estão presentes em centrais telefônicas. O SS7 é quem possibilita a comunicação de centrais telefônicas de maneira confiável e rápida. O MGCP possuiu um agente de chamada, um MG (Media Gateway), que é o responsável pela conversão de sinais entre circuitos, e pelo menos um SG (Signaling Gateway) conectado a um PSTN.
4.3 IAX
De acordo com Guy (2009), o IAX é um protocolo desenvolvido para estabelecer conexão entre servidores Asterisk, que também já está presente em telefones VoIP. Ele foi desenvolvido pela Digium Inc., que é a empresa desenvolvedora do Asterisk. O IAX é parecido com o protocolo SIP citado anteriormente, com a diferença de que faz uso de uma única porta UDP de número 4569. O IAX já está na versão 2, mais conhecido por IAX2. Um dos grandes benefícios do IAX é que ele suporta entroncamento de chamadas, ou seja, é possível unir chamadas que se entroncaram em um único conjunto de pacotes e entregar informações para mais de uma chamada ao mesmo tempo.
5. LINGUAGENS DE PROGRAMAÇÃO
Linguagem de programação é um conjunto de regras que são utilizadas para definir um programa para ser utilizado no computador. Existem alguns tipos de linguagens: alto nível, nível intermediário ou baixo nível.
De acordo com Carter (2002, p.46), a linguagem de baixo nível é uma linguagem em que o código é executado diretamente pelo processador. É formada por zeros (0) e uns (1). Por isso também é chamada de linguagem binária ou de máquina. A linguagem de nível intermediário é uma linguagem em que os códigos fonte são chamados de mnemônicos (assembly) onde cada instrução de máquina tem uma representação em texto (como ADD, SUB, ou LOAD). A linguagem de nível intermediário precisa ser transformada em linguagem de baixo nível, por isso era necessário um montador que realizasse a conversão.
Tabela 4 – Tipos de linguagens Fonte: O autor Linguagem Compilada/Interpretada ADA Compilada BASIC Interpretada C Compilada C++ Compilada Cobol Compilada Fortran Compilada
Java Intermediária (híbrida)
MATLAB Interpretada (híbrida)
LISP Intermediária (híbrida)
Pascal Compilada PHP Interpretada Prolog Interpretada Prolog Interpretada Perl Interpretada Lua Interpretada
A linguagem de alto nível é uma linguagem que é mais facilmente entendida pelo ser humano. Antigamente a programação era bem tediosa, pois para executar operações um pouco mais complexas eram necessárias muitas instruções e, além disso, as instruções disponíveis eram diferentes de máquina para máquina. Com isso surgiram as primeiras linguagens de alto nível como Pascal, COBOL e C. Através da linguagem de alto nível é possível desenvolver programas em muito menos instruções, ou seja, seu desenvolvimento é muito mais rápido do que era antigamente. Para que a linguagem de alto nível seja entendida pela máquina é preciso de alguém que a traduza. Existem algumas maneiras para realizar a tradução, seja através de um compilador ou interpretador. Na tabela 4, estão listadas algumas linguagens importantes e seus respectivos tipos.
5.1 LINGUAGENS INTERPRETADAS
Linguagem interpretada é uma linguagem de programação que necessita de um interpretador para ser executada. O código-fonte de uma linguagem interpretada só será entendido pela máquina se houver o interpretador para traduzir a respectiva linguagem.
De acordo com Louden (2004, p.04), um interpretador é um tradutor de linguagens, assim como o compilador. A diferença é que o interpretador executa o programa-fonte de imediato, traduzindo as instruções de programação conforme são lidas pelo programa, em vez de gerar um código-objeto que seja executado após o término da tradução.
Figura 10 - Linguagem interpretada Fonte: Caldas (Slide 14)
De acordo com Sebesta (2002, p. 154), algumas linguagens são tipicamente interpretadas, outras utilizam os dois métodos (compilação e interpretação) para serem executadas. Um interpretador compartilha muitas de suas operações com os compiladores, podendo existir compiladores híbridos que ficam entre os interpretadores e compiladores. Se uma linguagem for compilada e o código gerado não for entendido
pelo sistema operacional e processador, necessitando de que algum mecanismo a interprete, esta linguagem também será uma linguagem interpretada.
5.1.1 LINGUAGEM DE EXTENSÃO OU SCRIPT
Linguagem de extensão também pode ser chamada de linguagem de script. Essas linguagens normalmente controlam programas, pois são executadas dentro deles. De acordo com a Stanford University (2004), as linguagens de extensão são muito utilizadas em sistemas operacionais e também em muitos jogos. O Linux é um sistema operacional que utiliza bastante a linguagem de extensão para controlar aplicativos e rotinas do próprio sistema operacional. O Windows também utiliza linguagem de extensão. Um exemplo disso são os scripts VBS. Alguns jogos utilizam a linguagem de extensão para poder controlar ações de personagens.
Pode-se dizer que toda linguagem de extensão é uma linguagem interpretada, mas que nem toda linguagem interpretada é uma linguagem de extensão.
As linguagens de extensão são classificadas segundo sua complexidade: - Linguagem de Macro:
São utilizadas para tarefas de automação com abrangência mais limitada. - Linguagens Embutidas:
Permitem o acesso programável aos serviços da aplicação hospedeira (ou principal). São linguagens mais completas e mais complexas que a anterior. Figueiredo (2002) informa que a adoção de uma linguagem de extensão é um poderoso recurso no desenvolvimento de softwares, pois permite que muitos aspectos da aplicação hospedeira sejam controlados externamente. Esse controle consiste na edição de arquivos textos facilmente modificados pelo desenvolvedor sem a necessidade de recompilar a aplicação, tornando o desenvolvimento mais rápido e muito mais flexível.
Uma linguagem de extensão deve ter como foco a produtividade do programador. Segundo Proebsting (2002), um dos problemas mais sérios no desenvolvimento de uma linguagem de programação é em como melhorar a produtividade do programador. Os hardwares atualmente possuem um poder de processamento suficientemente grande para não precisar de otimização massiva da linguagem internamente.
5.2 LINGUAGENS COMPILADAS
Linguagem compilada é uma linguagem onde o código fonte é executado diretamente pelo sistema operacional ou pelo processador. O código é traduzido para executar um conjunto de regras ou instruções, e esse processo chama-se compilação. Para isso, é utilizado um software próprio, chamado compilador, que efetua a tradução para linguagem de baixo nível, como linguagem de montagem ou código de máquina.
De acordo com Louden (2004, p. 13), a geração do código é muito complexa, pois depende das informações da estrutura do ambiente de execução, através de tentativas de otimizar ou aperfeiçoar a velocidade ou tamanho do código fonte. A linguagem compilada elimina essa fase em vários passos, utilizando estruturas de dados intermediários.
Após a compilação, cria-se um programa executável, armazenando as informações e não é necessário a recompilação.
Figura 11 - Linguagem compilada Fonte: Caldas (Slide 14)
A vantagem é que o usuário nunca terá acesso ao código fonte, evitando assim a alteração e danificação do programa.
6 METODOLOGIA
Neste capítulo serão apresentados a metodologia adotada e informações necessárias para atingir o objetivo proposto no trabalho, além de justificar a escolha das tecnologias utilizadas.
Esta parte do trabalho foi dividida em etapas que ajudarão a construir um ambiente com suporte à paravirtualização, instalar e configurar o Asterisk em máquina virtual, desenvolver uma linguagem que possa ser interpretada pelo Asterisk, utilizar a API do Asterisk para que entenda a linguagem criada, e a execução de testes com VoIP utilizando o ambiente e linguagem criados.
As etapas necessárias estão divididas da seguinte forma: 1. Ambiente virtualizado:
- Escolha da tecnologia de virtualização que será utilizada; - Criação e configuração do ambiente virtualizado;
- Instalação e configuração do Asterisk. 2. Linguagem interpretada:
- Desenvolvimento da linguagem interpretada;
- Fazer a integração da linguagem com o Asterisk através da API do próprio Asterisk.
3. Testes finais:
- Realizar testes com VoIP utilizando a linguagem interpretada no Asterisk paravirtualizado.
6.1 VIRTUALIZAÇÃO
A paravirtualização foi escolhida como técnica a ser utilizada para a implementação do ambiente devido aos benefícios que ela apresenta. Como principais benefícios pode-se citar que a paravirtualização pode ser implementada em qualquer máquina da plataforma x86 sem necessitar de hardware com suporte à virtualização (como Intel-VT ou AMD-V), por isso mais tipos de máquinas, inclusive máquinas mais antigas, poderão ser utilizadas para a aplicação da técnica.
A ferramenta a ser utilizada para aplicação da técnica de paravirtualização será o Xen com o sistema operacional Linux distribuição Open Suse, pois apresenta algumas características que facilitarão a criação do ambiente como: um ótimo desempenho mesmo utilizando máquinas sem hardware com suporte à virtualização e máquinas de hardware comuns, software de código aberto, o que facilita ainda mais o acesso ao
software, além disso, já existem diversos sistemas operacionais com suporte a paravirtualização e ao Xen.
O Xen será instalado e configurado no sistema operacional Linux Open Suse como domínio 0. Uma máquina virtual será criada dentro do Xen. A máquina virtual também possuirá o sistema operacional Linux Open Suse. Nesta nova máquina virtual será instalado o software Asterisk em preparação para os próximos passos.
6.2 LINGUAGEM INTERPRETADA
O desenvolvimento do Interpretador, aqui chamado de dfn, consistirá em uma linguagem feita em “C” para aplicações em “C/C++” que funcionará como extensão da aplicação hospedeira que no caso será o Asterisk. Essa abordagem permite que a aplicação seja expandida sem a necessidade de alteração de linha de código. Toda a nova lógica, portanto, será implementada na linguagem aqui proposta.
A integração entre o interpretador e o Asterisk ocorrerá mediante o uso de funções específicas, previamente definidas, conforme o documento "Asterisk Coding Guideline" disponível no site do fabricante Asterisk (2010).
6.3 TESTES FINAIS
Após a criação do ambiente paravirtualizado, o desenvolvimento da linguagem interpretada e configuração do Asterisk para entender a linguagem, será necessário juntar os dois primeiros passos citados na introdução do capítulo 6 e realizar testes no ambiente criado utilizando a linguagem desenvolvida. Estes testes envolverão o desenvolvimento de um código utilizando a linguagem criada que substituirá arquivos de configuração do Asterisk. Estes arquivos de configuração contêm instruções sobre tomada de decisão relacionados ao VoIP. Em vez de o Asterisk ler o arquivo de configuração padrão (extensions.conf), ele lerá o arquivo .dfn que será o motor da linguagem aqui proposta. Para isso o Asterisk precisará entender a linguagem, ou seja, interpretá-la. O Asterisk já deverá ter sido configurado para interpretá-la de acordo com o que foi mencionado no item 6.2.
Ao final deste trabalho se chegará ao resultado da viabilidade do uso ou desenvolvimento de uma linguagem interpretada (extensível) para permitir maior flexibilidade na parametrização de aplicativos que necessitem do uso de configuração para o seu funcionamento e de que a paravirtualização garante um SLA elevado uma vez que na indisponibilidade de um hardware, outro poderá assumir como hospedeiro
mantendo o funcionamento dos serviços sem a necessidade de reinstalação de uma nova máquina.
7 DESENVOLVIMENTO
A partir deste capítulo será abordada toda a estrutura de criação do ambiente paravirtualizado, assim como os detalhes do desenvolvimento da linguagem interpretada para sistema multi-plataforma. Para isso, foram necessários o estudo de tecnologias necessárias para implementação do Asterisk, para a criação de uma linguagem interpretada e de um ambiente virtualizado estável.
7.1 CONFIGURAÇÃO DO AMBIENTE
Para a implementação do Xen e Asterisk em preparação para os testes com a linguagem criada será utilizada uma máquina Intel QuadCore Q9400 2.66GHz, 4GB de memória RAM, 2 HDs de 1TB em RAID-1, com sistema operacional Linux distribuição Open Suse 11.3.
7.2 DETALHES DE IMPLEMENTAÇÃO DA PARAVIRTUALIZAÇÃO
Para implementação das máquinas virtuais foi criada uma máquina real com o sistema operacional Linux distribuição Open Suse 11.3 Português e interface KDE. Este sistema é o sistema que chamamos de domínio 0 (domain0 ou dom0), que é o domínio de controle, conforme explicado no item 3.6. É o domínio que possui o sistema Xen para o controle e alocação das máquinas virtuais.
O OpenSuse 11.3 possui o Xen pré-instalado em um pacote que contém o Xen Hypervisor. Para instalar o Xen Virtualization é preciso selecionar no menu de seleção de Software e tarefas de sistema a opção Servidor hospedeiro de máquina virtual Xen, conforme mostra a figura 11.
Figura 12 – Instalação Xen Fonte: O autor O particionamento foi dividido da seguinte forma: -Volume de Swap /dev/sda1
- Volume Raíz /dev/sda2 com ext4 - Volume /dev/sda3 para /home com ext4
Para instalar o Hypervisor e Ferramentas foi necessário selecionar a opção “instalar o Hypervisor e suas ferramentas” após a instalação do sistema operacional conforme Figura 12.
Figura 13 – Instalando o Hypervisor e Ferramentas 1 Fonte: O autor
Ao instalar o Hypervisor e suas ferramentas é retornada a mensagem informando que o servidor VM (domínio 0) foi configurado com sucesso e que estará pronto para a criação de máquinas virtuais. Domínio 0 configurado e pronto para iniciar (ver figura 13):
Figura 14 – Domínio 0 configurado Fonte: O autor
Após a instalação foi realizada a criação da máquina virtual no domínio U-PV, que possui o sistema operacional modificado para executar a paravirtualização.
Abaixo está o exemplo do arquivo de configuração utilizado e modificado para a manipulação da máquina virtual chamado vm_xen_tcc.conf localizado em /images/config/:
#
# Arquivo de configuração da máquina virtual a ser usada no trabalho # kernel = "/images/TCC/boot/vmlinuz-xen" ramdisk = "/images/TCC/boot/initrd-xen" builder='linux' memory = 512 name = "TCC_VM_DFN" #uuid = "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9" # Number of Virtual CPUS to use, default is 1 vcpus = 1
vif = [ 'mac=00:16:3e:00:00:11, bridge=br0' ]
disk = [ 'file:/images/TCC/vdisks/sda_vdisk_12GB.img,xvda,w', 'file:/images/TCC/vdisks/sdb_vdisk_16GB.img,xvdb,w' ] root = "/dev/xvda2"
vfb = [ 'vnc=1,vnclisten=0.0.0.0,vncunused=1,vncpasswd=reurbanisatus' ] # Set root device.
#root = "/dev/hda1"
# Extra arguments to pass to the kernel.
extra = "xencons=xvc console=xvc0 video=tty" #on_poweroff = 'destroy'
7.3 INSTALAÇÃO ASTERISK
O Asterisk lê as regras de chamadas e discagem a partir do arquivo "extensions.conf". A linguagem dfn substituirá a configuração do "extensions.conf". Na prática, o mecanismo do Asterisk será instruído a ler o arquivo "extensions.dfn" que conterá toda a lógica de atendimento e regras de discagem.
As contas dos usuários continuarão a ser configuradas no arquivo sip.conf no caso de uso do protocolo SIP. Para o IAX2, o arquivo deverá ser o iax2.conf.
Esse mecanismo não será alterado e não terá interação com a linguagem propriamente dita, uma vez que esse faz parte do processo de autenticação do Asterisk, uma camada anterior à execução do script de atendimento em dfn.
7.3.1 INTERAÇÃO ENTRE O ASTERISK E O MÓDULO DA LINGUAGEM DFN A implementação ou interface entre a linguagem dfn e o asterisk será feita no código pbx_dfn.c. O módulo final é o pbx_dfn.so e o mecanismo obedece o fluxo conforme as figuras 14 e 15.
Figura 15 – Processo de inicialização Fonte: O autor
Figura 16 – Tratamento de chamada Fonte: O autor
Figura 17 – Compilação do módulo Fonte: O autor
A figura 17 mostra a compilação do módulo do Asterisk utilizando o arquivo pbx_dfn e a Figura 18 exibe o diretório de módulos com o arquivo pbx_dfn.so.
Figura 18 – Diretório de módulos do Asterisk Fonte: O autor
O Asterisk lerá o arquivo extensions.dfn onde todas as regras de atendimento estarão declaradas. Como as regras de atendimento do Asterisk são baseadas em contexto, a linguagem dfn tratará essa regra como regra de entrada e executará as funções internas do Asterisk responsáveis pelo controle de chamadas, geração de CDRs, desligamento de chamadas, etc.
Abaixo segue o trecho do código do pbx_dfn.c das partes mais importantes responsáveis pela integração entre o Asterisk e a linguagem dfn.
A API do Asterisk trabalha com as funções load_module, unload_module, reload e AST_MODULE_INFO. Essas quatro funções são o coração da integração entre qualquer modulo e o Asterisk. Quando o modulo é carregado, o asterisk lê os parâmetros passados à macro AST_MODULE_INFO. A partir deste instante cada função é executada conforme a ação do Asterisk. Deve-se, obrigatoriamente, declarar o nome o arquivo padrão na variável config, o nome do módulo na variável registrar, todas como static para ponteiro do tipo char.
static char *config = "extensions.dfn"; static char *registrar = "pbx_dfn";
A função load_module é a responsável pela carga do módulo da linguagem. Quando o módulo é carregado, a função deverá retornar 2 possíveis valores declarados como constantes (#define): AST_MODULE_LOAD_SUCCESS no caso de sucesso na carga ou AST_MODULE_LOAD_DECLINE para a situação de exceção ou erro no módulo.
static int load_module(void) {
int res;
if ((res = load_or_reload_dfn_stuff())) return res;
if (ast_register_switch(&dfn_switch)) {
ast_log(LOG_ERROR, "Unable to register DFN Language Extension Module\n");
return AST_MODULE_LOAD_DECLINE; }
return AST_MODULE_LOAD_SUCCESS; }
A função unload_module tem como objetivo a remoção do módulo da memória quando solicitado pelo usuário via console ou por situação de exceção interna do Asterisk. Duas outras funções internas devem ser chamadas: ast_context_destroy, que informa ao asterisk qual modulo será removido ou desregistrado e a função ast_unregister_switch que receberá o ponteiro da função do motor da linguagem propriamente dita.
static int unload_module(void) { ast_context_destroy(NULL, registrar); ast_unregister_switch(&dfn_switch); dfn_free_extensions(); return 0; }
A função reload tem como objetivo chamar a função load_or_reload_dfn_stuff que apenas remove e recarrega a linguagem dfn.
static int reload(void) {
return load_or_reload_dfn_stuff(); }
AST_MODULE_INFO(ASTERISK_GPL_KEY, AST_MODFLAG_DEFAULT, "DFN Language Extension Module",
.load = load_module, .unload = unload_module, .reload = reload,
Abaixo segue exemplo do arquivo de configuração dos módulos do Asterisk juntamente com os comentários explicativos de cada parte do arquivo e o arquivo sip.conf:
[modules]
; autoload habilitado, instrui o Asterisk a carregar todos os arquivos *.so que encontrar em /var/lib/asterisk/modules
autoload=yes
; Cada módulo precisa ser carregado antes do núcleo do Asterisk ser inicializado. ;
; A linha abaixo só deverá ser descomentada se o autoload for igual a "no". ;load => pbx_dfn.so
; Como o autoload está habilitado, caso não se pretenda carregar o módulo da linguagem dfn,
; deve-se remover o comentário da linha abaixo ;noload => pbx_dfn.so
Figura 19 – Arquivo sip.conf Fonte: O autor
7.4 DESENVOLVIMENTO DA LINGUAGEM INTERPRETADA PARA SISTEMA MULTI-PLATAFORMA
A linguagem aqui proposta, chamada de dfn, implementa as construções fundamentais para definição de controle de fluxo como if, elseif, else, endif, while, do, endwhile, repeat, until, funções, e tipos definidos de dados. Trata-se ainda de uma linguagem com tipagem dinâmica.
