| (2 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
| Linha 13: | Linha 13: | ||
[[Arquivo:PlanetLabMap.jpg]] | [[Arquivo:PlanetLabMap.jpg]] | ||
Esta plataforma permite a sobreposição de redes, onde o desenvolvedor consegue realizar experimentos em condições reais e em escala global | Esta plataforma permite a sobreposição de redes, onde o desenvolvedor consegue realizar experimentos em condições reais e em escala global, visto que o Planet Lab é baseado em "slices", onde cada serviço tem seu próprio "slice", que nada mais são do que um conjunto de maquinas virtuais, conforme exemplificado na figura a seguir: | ||
[[Arquivo:PlanetLabSlices.jpg]] | [[Arquivo:PlanetLabSlices.jpg]] | ||
O Planet Lab permite ao desenvolvedor ter uma visão geral de todos os processos que ocorrem em cada maquina virtual e a conexão entre elas. | |||
Ele é uma plataforma que ao invés de ser baseada em um projeto pré-concebido e validado com experimentos controlados, foi moldado e comprovado através de sua utilização em ambientes reais; ao invés de ter sido desenvolvido para funcionar dentro de uma unica perspectiva, é um sistema de larga escala que está ciente de seu lugar em um mundo com muitas possibilidades; e ao invés de ter apenas que satisfazer os objetivos quantificáveis técnicos, o seu sucesso depende de trabalhar com diversas comunidades utilizando os incentivos adequados. | |||
O | O GENI, ou Global Environment for Network Innovations, é outra plataforma que tem sido utilizada em larga escala, principalmente nos EUA, como nos mostra a imagem abaixo: | ||
GENI, ou Global Environment for Network Innovations, é outra plataforma que tem sido utilizada em larga escala nos EUA, como | |||
[[Arquivo:GENIMap.jpg]] | [[Arquivo:GENIMap.jpg]] | ||
o GENI é uma plataforma que apresenta diversas vantagens | o GENI é uma plataforma que apresenta diversas vantagens, quanto tratamos da internet atual, dentre as quais podemos citar um sistema de segurança mais abrangente, maior generalidade, melhor integração de tecnologias ópticas e sem fio, e além disso permite uma comunicação com os sensores e processadores integrados. | ||
[[Arquivo:GENISchema.jpg]] | |||
A plataforma permite experiências com arquiteturas de redes alternativas, serviços e aplicações em grande escala e em condições reais; graças ao uso de virtualização, o GENI permite múltiplos e independentes experimentos simultâneos, experimentos de longa duração; e facilita a pesquisa experimental através do uso extensivo de instrumentos de medição e coleta de dados. Resumindo, a plataforma GENI fornece suporte para a validação em propostas de larga escala, desde a concepção até a implantação. | |||
E frente a esse modelo a plataforma permite ao desenvolvedor atuar sobre todos os ambientes. | E frente a esse modelo, a plataforma ainda permite ao desenvolvedor atuar sobre todos os ambientes, tendo uma visão do processo em cada um destes ambientes. | ||
[[Arquivo:GENIManagment.jpg]] | [[Arquivo:GENIManagment.jpg]] | ||
Descrever os resultados de algumas soluções [Caio] | Descrever os resultados de algumas soluções [Caio] | ||
De posse dos resultados da pesquisa de pŕojetos em desenvolvimento no mundo, deverá ser feita uma avaliação criteriosa das soluções encontradas por meio de relatórios e requisitos de colaboração como: facilidade na instalação do software, documentação atualizada, participação da comunidade em foruns e discussões, requerimentos de hardware e possibilidades de cooperação efetiva. | |||
De posse dos resultados da pesquisa de pŕojetos em desenvolvimento no mundo, deverá ser feita uma avaliação criteriosa das soluções | |||
Estas informações subsidiarão a escolha da solução mais viável. De início, com base em alguns relatos e antecipando aos trabalhos ainda a serem feitos, foi destacada a solução AutoI que possui uma estruturação interessante que facilita a colaboração e a possibilidade de colaboração com o projeto. Como essa solução não é a única, pode ser que outra solução seja eleita para ser usada pelo grupo do projeto em questão. | Estas informações subsidiarão a escolha da solução mais viável. De início, com base em alguns relatos e antecipando aos trabalhos ainda a serem feitos, foi destacada a solução AutoI que possui uma estruturação interessante que facilita a colaboração e a possibilidade de colaboração com o projeto. Como essa solução não é a única, pode ser que outra solução seja eleita para ser usada pelo grupo do projeto em questão. | ||
| Linha 58: | Linha 42: | ||
Sendo o AutoI, a solução escolhida ou outra, será criado uma infraestrutura para abrigar o software que deverá ser "dissecado" em todo o seu código para seu conhecimento pleno e posterior procedimentos de alteração e compilação até que se chegue com sucesso a um código executável. | Sendo o AutoI, a solução escolhida ou outra, será criado uma infraestrutura para abrigar o software que deverá ser "dissecado" em todo o seu código para seu conhecimento pleno e posterior procedimentos de alteração e compilação até que se chegue com sucesso a um código executável. | ||
O procedimento de instalação, especificamente do AutoI, é similar aos inúmeros códigos-fonte espalhados pela Internet. A partir de um endereço disponível na web, é possível descarregar o código e instalá-lo num sistema operacional linux e a partir daí, compilá-lo segundo as regras do ambiente | O procedimento de instalação, especificamente do AutoI, é similar aos inúmeros códigos-fonte espalhados pela Internet. A partir de um endereço disponível na web, é possível descarregar o código e instalá-lo num sistema operacional linux e a partir daí, compilá-lo segundo as regras do ambiente, identificando os possíveis erros e posteriormente corrigindo-os até que o executável esteja disponível. | ||
Este primeiro passo na maioria dos casos é bem crítico porque o proccesso entre identificar os erros, corrigi-los e compilá-los é feito de uma maneira empírica. A cada erro corrigido, descobrem-se novos que geram um novo ciclo de correção. Isto não seria tão difícil se os programas-fonte fossem bem organizados e tivessem uma documentação efetiva, algo como um diagrama de Fluxo de Dados ou Diagramas de Classes e Estudos de Caso. Como na grande maioria, estes documentos não são encontrados fica a cargo da equipe de pesquisadores, debruçar-se sobre cada código, como faz um arqueologista decifrando um hieróglifo e se propõe a desvendar o que o programador original teria feito. | Este primeiro passo na maioria dos casos é bem crítico porque o proccesso entre identificar os erros, corrigi-los e compilá-los é feito de uma maneira empírica. A cada erro corrigido, descobrem-se novos que geram um novo ciclo de correção. Isto não seria tão difícil se os programas-fonte fossem bem organizados e tivessem uma documentação efetiva, algo como um diagrama de Fluxo de Dados ou Diagramas de Classes e Estudos de Caso. Como na grande maioria, estes documentos não são encontrados fica a cargo da equipe de pesquisadores, debruçar-se sobre cada código, como faz um arqueologista decifrando um hieróglifo e se propõe a desvendar o que o programador original teria feito. | ||
| Linha 64: | Linha 48: | ||
Apesar de ser uma tarefa árdua, tem a grande fascinação pela descoberta gradativa de cada novo cenário. A cada erro transpassado, abre-se um novo caminho que motiva o pesquisador a buscar a correção para aquele novo problema. Seria muito crítico se não houvesse a disposição algumas ferramentas como ''tracers'', pontos de teste e identificação de bibliotecas ausentes. Nesse caso, os frameworks, ferramentas CASE com as várias funcionalidades que facilitam a vida do desenvolvedor tornam-se obrigatórias. | Apesar de ser uma tarefa árdua, tem a grande fascinação pela descoberta gradativa de cada novo cenário. A cada erro transpassado, abre-se um novo caminho que motiva o pesquisador a buscar a correção para aquele novo problema. Seria muito crítico se não houvesse a disposição algumas ferramentas como ''tracers'', pontos de teste e identificação de bibliotecas ausentes. Nesse caso, os frameworks, ferramentas CASE com as várias funcionalidades que facilitam a vida do desenvolvedor tornam-se obrigatórias. | ||
Além disso, em muitos casos, a comunidade mundial pode auxiliar por meio dos fóruns | Além disso, em muitos casos, a comunidade mundial pode auxiliar por meio dos fóruns técnicos onde podemos encontrar as experiências vividas por outras pessoas. Se der sorte, o pesquisador pode achar um passo a passo para a correção e compilação total dos bugs apresentados pela solução. Deve-se ter como premissa, que encontrando ou não alguma ajuda nos foruns é condição ''sine qua non'' que o pesquisador retorne sua contribuição por meio de informações sobre as experiências vividas para que a solução open source evolua com a participação efetiva de vários colaboradores. | ||
Um fato que atrasa bastante ou inviabiliza todo o processo de conseguir um executável eficiente são as várias versões de ambientes. Para isso, é importante que o desenvolvedor avalie bem os requisitos de infraestrutura de sistema operacional, de banco de dados e de outros softwares exigidos pela solução. Feito isso, pode-se submeter os ''patches'' de correção de versão para que todos estejam alinhados quanto à ultima edição do software em avaliação. | Um fato que atrasa bastante ou inviabiliza todo o processo de conseguir um executável eficiente são as várias versões de ambientes. Para isso, é importante que o desenvolvedor avalie bem os requisitos de infraestrutura de sistema operacional, de banco de dados e de outros softwares exigidos pela solução. Feito isso, pode-se submeter os ''patches'' de correção de versão para que todos estejam alinhados quanto à ultima edição do software em avaliação. | ||
| Linha 70: | Linha 54: | ||
= Módulos do AutoI = | = Módulos do AutoI = | ||
A solução AutoI disponível | A solução AutoI disponível no site www.ist-autoi.eu, é dividida em vários módulos que completam toda o projeto e implementação de uma camada de recursos virtuais auto gerenciáveis. O modelo de arquitetura do AutoI consiste de vários sistemas de gerenciamento descritos com a ajuda de cinco abstrações: Plano de Orquestração, Plano de Serviços, Plano de Conhecimento, Plano de Virtualização e Plano de Gerenciamento. Juntos, estes sistemas distribuídos formam uma infraestrutura de controle de rede dirigida a software que pode ser executada no topo de qualquer estrutura física de rede. | ||
Uma versão do código aberto desenvolvido pelo time do AutoI foi liberado em Outubro de 2009 e outra mais recente em Junho de 2010. Como intenção do grupo criador e também da equipe deste projeto, parceiros no mundo inteiro são chamados para atualizar, manter e usar este código e dessa forma colaborar na sua evolução. | Uma versão do código aberto desenvolvido pelo time do AutoI foi liberado em Outubro de 2009 e outra mais recente em Junho de 2010. Como intenção do grupo criador e também da equipe deste projeto, parceiros no mundo inteiro são chamados para atualizar, manter e usar este código e dessa forma colaborar na sua evolução. | ||
| Linha 86: | Linha 70: | ||
O CISP (''Context & Information Service Platform'') é uma limitada funcionalidade do Plano de Conhecimento. É uma infraestrutura preparada para coleta, processamento e disseminação de informação de contexto, como suporte para a implantação, evolução e autonomia de serviços de comunicação e aplicações. | O CISP (''Context & Information Service Platform'') é uma limitada funcionalidade do Plano de Conhecimento. É uma infraestrutura preparada para coleta, processamento e disseminação de informação de contexto, como suporte para a implantação, evolução e autonomia de serviços de comunicação e aplicações. | ||
O vSPI é usado para habilitar o Plano de Orquestração para governar recursos virtuais e construir redes e serviços virtuais que encontrem serviços | O vSPI é usado para habilitar o Plano de Orquestração para governar recursos virtuais e construir redes e serviços virtuais que encontrem serviços aplicáve | ||
O vCPI é uma interface que permite o gerenciamento de recursos virtuais, por exemplo, roteadores virtuais de um componente físico. Ele fornece métodos que suportam a | O vCPI é uma interface que permite o gerenciamento de recursos virtuais, por exemplo, roteadores virtuais de um componente físico. Ele fornece métodos que suportam a configuraçãois a partir de requisitos específicos. O vSPI contém uma macro visão de recursos virtuais que um Plano de Orquestração governa e é responsável pela organização de recursos virtuais em resposta às necessidades do usuários como requisitos de negócio e condições ambientais. automática de links virtuais e roteadores virtuais. Alguns metodos incluem remover, instanciar e modificar links virtuais ou ainda registar, iniciar e desligar um roteador virtual. Ainda existem métodos permitirão autogerenciamento como avaliar o uso de CPU ou de memória RAM, verificar o estado atual do recurso, avaliar os pacotes perdidos ou ainda contar o total de memória RAM disponível. Estes métodos são invocados pelos AMSs, DOCs ou eventuamente pelos ANPIs. | ||
Um módulo ainda disponível no pacote do AutoI é o MBT (''Model-based Translator'') que traduz comandos e mensagens de determinadas linguagens de rede para comandos e configurações específicas. O MBT usa um modelo de informação detalhado de redes de comunicação em combinação com templates de tradução modelo-para-texto para carregar todas as traduções. Ele é importante quando tivermos que gerenciar equipamentos e serviços de redes heterogêneas sem precisar entender os modelos associados de dados. | Um módulo ainda disponível no pacote do AutoI é o MBT (''Model-based Translator'') que traduz comandos e mensagens de determinadas linguagens de rede para comandos e configurações específicas. O MBT usa um modelo de informação detalhado de redes de comunicação em combinação com templates de tradução modelo-para-texto para carregar todas as traduções. Ele é importante quando tivermos que gerenciar equipamentos e serviços de redes heterogêneas sem precisar entender os modelos associados de dados. | ||
| Linha 105: | Linha 89: | ||
Descrever caso da figura 3 em Manageability of Future Internet Virtual Networks from a Practical | Descrever caso da figura 3 em Manageability of Future Internet Virtual Networks from a Practical | ||
Viewpoint => João Paulo | Viewpoint => João Paulo | ||
Não achei esta figura na lista de imagens uploaded. [ Caio ] | |||
O AutoI ainda disponbiliza dois outros módulos adicionais. | O AutoI ainda disponbiliza dois outros módulos adicionais. | ||
Programmable Management Platform (XINA) | |||
XINA é uma arquitetura modular e escalonável que permite a implantação, controle e gerenciamento de sessões ativas sobre entidades virtuais (por exemplo, roteadores ou servidores virtuais). Um protótipo de prova de conceito é implementado e integra o os componentes open-source fornecidos. Ela permite a implantação de componentes de gerenciamento de diferentes funcionalidades que realizam auto-gestão. XINA consiste em um mecanismo ativo e um elemento Forwarding, ou seja, um roteador, rede local sem fio (WLAN) ponto de acesso, gateway de mídia, etc. O parte ativa consiste em três componentes principais: (1) do desviador (2), Broker da Sessão e (3) o Corretor de virtualização. Além disso, qualquer número de outros corretores podem ser executados em paralelo, e auxiliar os principais componentes através de interfaces corretoras. A comunicação entre os módulos XINA é realizado por meio de transações UDP ou conexões TCP. | |||
Reasoning and Negotiation module (ARNM) | |||
O raciocínio e o módulo de negociação do AutoI são uma implementação do DOC. Tem como objetivo demonstrar a funcionalidade básica de um DOC na mediação da negociação entre AMSs para a implantação de um usuário que solicitou o Customer Facing Service(CFS), que é basicamente um atendimento ao cliente, de acordo com o cenário do caso de uso selecionado. Ela consiste principalmente em dois componentes: O componente dinâmico Planner e o componente de Negociação. Em geral, o CFS é solicitada por um cliente através de um AMS. Se não é capaz de fornecer o SLA solicitado que inclui o CFS por conta própria, o próprio AMS delega o pedido ao DOC que o mesmo foi anexado. O papel do DOC é localizar alternativas para entregar o SLA solicitado através da cooperação de multi-AMS e orquestrar o processo de entrega. | |||
Com o todo o ambiente do AutoI instalado e funcionando, ele poderá ser submetido a uma série de situações como a descrita neste documento. São inúmeros os cenários possíveis, tanto em termos de aplicação quanto de equipamentos. Uma especificação bem clara deverá ser feita para definir quantos e quais serão implementados. Esta situações envolvem testes caso a caso com a comparação com outros modelos e ainda a documentação tão completa quanto possível. | Com o todo o ambiente do AutoI instalado e funcionando, ele poderá ser submetido a uma série de situações como a descrita neste documento. São inúmeros os cenários possíveis, tanto em termos de aplicação quanto de equipamentos. Uma especificação bem clara deverá ser feita para definir quantos e quais serão implementados. Esta situações envolvem testes caso a caso com a comparação com outros modelos e ainda a documentação tão completa quanto possível. | ||
Como fase final, existem dois objetivos: primeiro, devolver ao time do AutoI, o sistema evoluído seja com meloria do código ou com relatórios informando os resultados dos cenários testados. Um segundo, é a confecção de artigos e publicações que possam registrar todo o esforço da equipe do projeto e também dos avanços conseguidos em relação às propostas para a Internet do Futuro. | Como fase final, existem dois objetivos: primeiro, devolver ao time do AutoI, o sistema evoluído seja com meloria do código ou com relatórios informando os resultados dos cenários testados. Um segundo, é a confecção de artigos e publicações que possam registrar todo o esforço da equipe do projeto e também dos avanços conseguidos em relação às propostas para a Internet do Futuro. | ||
Edição atual tal como às 14h30min de 27 de julho de 2011
Desenvolvimento
Implementar um projeto que vise a implantação de um ambiente que permita servir de laboratório às atuais demandas da Internet é uma tarefa que requer inicialmente um estudo aprofundado das soluções em fase de desenvolvimento na comunidade global.
Os passos previstos para este projeto, pretendem como primeira etapa prospectar com bastante amplitude sobre os esforços de pesquisadores interessados em promover as mudanças para a Internet do Futuro. Um grande desafio é encontrar material atualizado porque muitas correntes de pesquisa ainda estão em fase de desenvolvimento e consequentemente não possuem muita bibliografia e se existir, os benchmarkings e estudos comparativos provavelmente serão poucos ou nulos.
Ainda assim, amparado nas publicações existentes, serão avaliados os projetos que promovem uma reformulação da arquitetura atual mas com o requisito de ser open-source para que possa existir colaboração por parte do grupo de pesquisa deste projeto.
Alguns projetos já são destaques no mundo, dentre os quais podemos citar o Planet Lab, GENI, GIGA, FIRE e ANA.
O Planet Lab é um projeto de origem americana, financiado a apoio em parte pelos governos dos Estados Unidos e de países europeus, que apresentou uma boa adesão como demonstrado na figura abaixo:
Esta plataforma permite a sobreposição de redes, onde o desenvolvedor consegue realizar experimentos em condições reais e em escala global, visto que o Planet Lab é baseado em "slices", onde cada serviço tem seu próprio "slice", que nada mais são do que um conjunto de maquinas virtuais, conforme exemplificado na figura a seguir:
O Planet Lab permite ao desenvolvedor ter uma visão geral de todos os processos que ocorrem em cada maquina virtual e a conexão entre elas. Ele é uma plataforma que ao invés de ser baseada em um projeto pré-concebido e validado com experimentos controlados, foi moldado e comprovado através de sua utilização em ambientes reais; ao invés de ter sido desenvolvido para funcionar dentro de uma unica perspectiva, é um sistema de larga escala que está ciente de seu lugar em um mundo com muitas possibilidades; e ao invés de ter apenas que satisfazer os objetivos quantificáveis técnicos, o seu sucesso depende de trabalhar com diversas comunidades utilizando os incentivos adequados.
O GENI, ou Global Environment for Network Innovations, é outra plataforma que tem sido utilizada em larga escala, principalmente nos EUA, como nos mostra a imagem abaixo:
o GENI é uma plataforma que apresenta diversas vantagens, quanto tratamos da internet atual, dentre as quais podemos citar um sistema de segurança mais abrangente, maior generalidade, melhor integração de tecnologias ópticas e sem fio, e além disso permite uma comunicação com os sensores e processadores integrados.
A plataforma permite experiências com arquiteturas de redes alternativas, serviços e aplicações em grande escala e em condições reais; graças ao uso de virtualização, o GENI permite múltiplos e independentes experimentos simultâneos, experimentos de longa duração; e facilita a pesquisa experimental através do uso extensivo de instrumentos de medição e coleta de dados. Resumindo, a plataforma GENI fornece suporte para a validação em propostas de larga escala, desde a concepção até a implantação.
E frente a esse modelo, a plataforma ainda permite ao desenvolvedor atuar sobre todos os ambientes, tendo uma visão do processo em cada um destes ambientes.
Descrever os resultados de algumas soluções [Caio]
De posse dos resultados da pesquisa de pŕojetos em desenvolvimento no mundo, deverá ser feita uma avaliação criteriosa das soluções encontradas por meio de relatórios e requisitos de colaboração como: facilidade na instalação do software, documentação atualizada, participação da comunidade em foruns e discussões, requerimentos de hardware e possibilidades de cooperação efetiva.
Estas informações subsidiarão a escolha da solução mais viável. De início, com base em alguns relatos e antecipando aos trabalhos ainda a serem feitos, foi destacada a solução AutoI que possui uma estruturação interessante que facilita a colaboração e a possibilidade de colaboração com o projeto. Como essa solução não é a única, pode ser que outra solução seja eleita para ser usada pelo grupo do projeto em questão.
Sendo o AutoI, a solução escolhida ou outra, será criado uma infraestrutura para abrigar o software que deverá ser "dissecado" em todo o seu código para seu conhecimento pleno e posterior procedimentos de alteração e compilação até que se chegue com sucesso a um código executável.
O procedimento de instalação, especificamente do AutoI, é similar aos inúmeros códigos-fonte espalhados pela Internet. A partir de um endereço disponível na web, é possível descarregar o código e instalá-lo num sistema operacional linux e a partir daí, compilá-lo segundo as regras do ambiente, identificando os possíveis erros e posteriormente corrigindo-os até que o executável esteja disponível.
Este primeiro passo na maioria dos casos é bem crítico porque o proccesso entre identificar os erros, corrigi-los e compilá-los é feito de uma maneira empírica. A cada erro corrigido, descobrem-se novos que geram um novo ciclo de correção. Isto não seria tão difícil se os programas-fonte fossem bem organizados e tivessem uma documentação efetiva, algo como um diagrama de Fluxo de Dados ou Diagramas de Classes e Estudos de Caso. Como na grande maioria, estes documentos não são encontrados fica a cargo da equipe de pesquisadores, debruçar-se sobre cada código, como faz um arqueologista decifrando um hieróglifo e se propõe a desvendar o que o programador original teria feito.
Apesar de ser uma tarefa árdua, tem a grande fascinação pela descoberta gradativa de cada novo cenário. A cada erro transpassado, abre-se um novo caminho que motiva o pesquisador a buscar a correção para aquele novo problema. Seria muito crítico se não houvesse a disposição algumas ferramentas como tracers, pontos de teste e identificação de bibliotecas ausentes. Nesse caso, os frameworks, ferramentas CASE com as várias funcionalidades que facilitam a vida do desenvolvedor tornam-se obrigatórias.
Além disso, em muitos casos, a comunidade mundial pode auxiliar por meio dos fóruns técnicos onde podemos encontrar as experiências vividas por outras pessoas. Se der sorte, o pesquisador pode achar um passo a passo para a correção e compilação total dos bugs apresentados pela solução. Deve-se ter como premissa, que encontrando ou não alguma ajuda nos foruns é condição sine qua non que o pesquisador retorne sua contribuição por meio de informações sobre as experiências vividas para que a solução open source evolua com a participação efetiva de vários colaboradores.
Um fato que atrasa bastante ou inviabiliza todo o processo de conseguir um executável eficiente são as várias versões de ambientes. Para isso, é importante que o desenvolvedor avalie bem os requisitos de infraestrutura de sistema operacional, de banco de dados e de outros softwares exigidos pela solução. Feito isso, pode-se submeter os patches de correção de versão para que todos estejam alinhados quanto à ultima edição do software em avaliação.
Módulos do AutoI
A solução AutoI disponível no site www.ist-autoi.eu, é dividida em vários módulos que completam toda o projeto e implementação de uma camada de recursos virtuais auto gerenciáveis. O modelo de arquitetura do AutoI consiste de vários sistemas de gerenciamento descritos com a ajuda de cinco abstrações: Plano de Orquestração, Plano de Serviços, Plano de Conhecimento, Plano de Virtualização e Plano de Gerenciamento. Juntos, estes sistemas distribuídos formam uma infraestrutura de controle de rede dirigida a software que pode ser executada no topo de qualquer estrutura física de rede.
Uma versão do código aberto desenvolvido pelo time do AutoI foi liberado em Outubro de 2009 e outra mais recente em Junho de 2010. Como intenção do grupo criador e também da equipe deste projeto, parceiros no mundo inteiro são chamados para atualizar, manter e usar este código e dessa forma colaborar na sua evolução.
Para efetivamente permitir uma visão e utilização do sistema, o AutoI propiciou um modelo muito interessante. Inicialmente foi desenvolvido o vCPI (Virtual Controller Programming Interface) preparado para alterar dinamicamente a infraestrutura de rede virtual e o vSPI (Virtual System Programmability Interface), hábil em executar operações de gerenciamento em larga escala que permite aos Planos de Orquestração e Gerenciamento controlarem recursos virtuais em grupo usando vCPI.
A regra e o projeto do Plano de Orquestração dentro da arquitetura do AutoI e suas interações com outros planos do AutoI tem sido definidas, junto com o módulo DOCs (Distributed Orchestration Components). Além disso, o projeto dos Planos de Gerenciamento e conhecimento foram contemplados e os protótipos do AMS (Autonomic Management Systems) também foram desenvolvidos. Com respeito à implantação de serviços, o principal foco tem sido as redes virtuais e máquinas virtuais por meio do módulo ANPI (Autonomic Network Programming Interface).
Para explicitar a visão de como estes módulos serão implementados e desenvolvidos podemos começar, por exemplo, pelo Plano de Gerenciamento que tem suas funcionalidades implementadas pelos AMSs (Autonomic Management Systems. Utilizam um conjunto dedicado de mapeamentos lógicos que conseguem armazenar dados em modelos para serem transformados em conhecimentos e combinar estes conhecimentos com ontologias para atender a demandas dependentes de contexto nas operações de um ou mais recursos virtuais.
A interface AMS com um ou mais DOCs (Distributed Orchestration Components), descritos abaixo, permitem a federação com outros AMS para fornecer serviços dependentes de contexto. Este componente reage aos eventos onde ocorre alteração de contexto, como por exemplo, requisições de serviço sob demanda, flutuações estatísticas de QoS, falhas existentes na rede e outros.
O DOC provê um conjunto de serviços de rede e parcialmente implementa a funcionalidade do Plano de Orquestração por meio de uma infraestrutura comum que habilita todos os componentes em um sistema gerenciado pelo por este Plano para ter procedimentos plug-and-play e unplug-and-play. Aplicações alinhadas com estes serviços compartilham de forma comum, serviços de segurança, metadados, administração e gerenciamento.
O CISP (Context & Information Service Platform) é uma limitada funcionalidade do Plano de Conhecimento. É uma infraestrutura preparada para coleta, processamento e disseminação de informação de contexto, como suporte para a implantação, evolução e autonomia de serviços de comunicação e aplicações.
O vSPI é usado para habilitar o Plano de Orquestração para governar recursos virtuais e construir redes e serviços virtuais que encontrem serviços aplicáve
O vCPI é uma interface que permite o gerenciamento de recursos virtuais, por exemplo, roteadores virtuais de um componente físico. Ele fornece métodos que suportam a configuraçãois a partir de requisitos específicos. O vSPI contém uma macro visão de recursos virtuais que um Plano de Orquestração governa e é responsável pela organização de recursos virtuais em resposta às necessidades do usuários como requisitos de negócio e condições ambientais. automática de links virtuais e roteadores virtuais. Alguns metodos incluem remover, instanciar e modificar links virtuais ou ainda registar, iniciar e desligar um roteador virtual. Ainda existem métodos permitirão autogerenciamento como avaliar o uso de CPU ou de memória RAM, verificar o estado atual do recurso, avaliar os pacotes perdidos ou ainda contar o total de memória RAM disponível. Estes métodos são invocados pelos AMSs, DOCs ou eventuamente pelos ANPIs.
Um módulo ainda disponível no pacote do AutoI é o MBT (Model-based Translator) que traduz comandos e mensagens de determinadas linguagens de rede para comandos e configurações específicas. O MBT usa um modelo de informação detalhado de redes de comunicação em combinação com templates de tradução modelo-para-texto para carregar todas as traduções. Ele é importante quando tivermos que gerenciar equipamentos e serviços de redes heterogêneas sem precisar entender os modelos associados de dados.
Uma visão das interações entre os módulos pode ser vista na figura abaixo.
No exemplo mostrado na figura, temos a disponibilidade de recursos sendo definidos pelo vCPI que controla os recursos físicos. Uma vez que eles estejam definidos, as entidadades e componentes de gerenciamento precisam ter referências para estes recursos. Esta informação é registrada no CISP. Os AMSs reconhecem o escopo dos recursos que eles podem controlar e o ANPI executa a varredura dos serviços básicos que residem nos recursos gerenciáveis e registram-os no CISP. Neste estágio, o CISP está atualizado com recursos e serviços básicos que estão sujeitos às tarefas de gerenciamento para uso posterior.
O próximol passo é o registro de AMSs no DOC para proposta de orquestração. Baseado no escopo dos AMSs, o DOC empurra regras prioritárias para a inicialização de tal forma que os AMSs possam definir mecanismos e políticas internas com os quais eles poderão controlar os recursos e serviços básicos durante a inicialização de suas infraestruturas de rede.
O ANPI fica responsável pela detecção do perfil do usuário a garante que o usuário final está subscrito no serviço AutoI (AAA). Invocações são atualizadas no CISP. O ANPI informa aos AMSs que um novo serviço está sendo invocado e que é necessário que ele seja provisionado com garantias específicas. O DOC pode ser requisitado para orquestrar a implantação de alguns serviços com a ajuda de outros AMSs onde ele pode estar subscrito.
Como exemplo prático de teste dos módulos do AutoI podemos citar
Descrever caso da figura 3 em Manageability of Future Internet Virtual Networks from a Practical Viewpoint => João Paulo Não achei esta figura na lista de imagens uploaded. [ Caio ]
O AutoI ainda disponbiliza dois outros módulos adicionais.
Programmable Management Platform (XINA) XINA é uma arquitetura modular e escalonável que permite a implantação, controle e gerenciamento de sessões ativas sobre entidades virtuais (por exemplo, roteadores ou servidores virtuais). Um protótipo de prova de conceito é implementado e integra o os componentes open-source fornecidos. Ela permite a implantação de componentes de gerenciamento de diferentes funcionalidades que realizam auto-gestão. XINA consiste em um mecanismo ativo e um elemento Forwarding, ou seja, um roteador, rede local sem fio (WLAN) ponto de acesso, gateway de mídia, etc. O parte ativa consiste em três componentes principais: (1) do desviador (2), Broker da Sessão e (3) o Corretor de virtualização. Além disso, qualquer número de outros corretores podem ser executados em paralelo, e auxiliar os principais componentes através de interfaces corretoras. A comunicação entre os módulos XINA é realizado por meio de transações UDP ou conexões TCP.
Reasoning and Negotiation module (ARNM) O raciocínio e o módulo de negociação do AutoI são uma implementação do DOC. Tem como objetivo demonstrar a funcionalidade básica de um DOC na mediação da negociação entre AMSs para a implantação de um usuário que solicitou o Customer Facing Service(CFS), que é basicamente um atendimento ao cliente, de acordo com o cenário do caso de uso selecionado. Ela consiste principalmente em dois componentes: O componente dinâmico Planner e o componente de Negociação. Em geral, o CFS é solicitada por um cliente através de um AMS. Se não é capaz de fornecer o SLA solicitado que inclui o CFS por conta própria, o próprio AMS delega o pedido ao DOC que o mesmo foi anexado. O papel do DOC é localizar alternativas para entregar o SLA solicitado através da cooperação de multi-AMS e orquestrar o processo de entrega.
Com o todo o ambiente do AutoI instalado e funcionando, ele poderá ser submetido a uma série de situações como a descrita neste documento. São inúmeros os cenários possíveis, tanto em termos de aplicação quanto de equipamentos. Uma especificação bem clara deverá ser feita para definir quantos e quais serão implementados. Esta situações envolvem testes caso a caso com a comparação com outros modelos e ainda a documentação tão completa quanto possível.
Como fase final, existem dois objetivos: primeiro, devolver ao time do AutoI, o sistema evoluído seja com meloria do código ou com relatórios informando os resultados dos cenários testados. Um segundo, é a confecção de artigos e publicações que possam registrar todo o esforço da equipe do projeto e também dos avanços conseguidos em relação às propostas para a Internet do Futuro.