O plugin é o principal componente do módulo de Rede (Networking). É ele que se comunica com os equipamentos e traduz as mensagens de rede. Devido a modularidade e variabilidade do OpenStack, é comum que cada plugin siga uma implementação diferente. A repetição de alguns trechos de código faz com que novos módulos, classes e métodos sejam criados, facilitando o desenvolvimento. Um exemplo é a criação da classe NeutronDbPluginV2, derivada do fato de que muitos plugins utilizam um banco de dados externo. Outros exemplos de adições que facilitam são os diversos agentes e serviços que o Neutron provê. Esta facilidade para o desenvolvedor é fundamental para o crescimento do projeto, já que cada fabricante deve desenvolver seu próprio
4.1 Plugin do Neutron 32 plugin.
Exemplos de plugins existentes são o Open vSwitch, o qual é simples e possui apenas as operações básicas de CRUD, e pode ser utilizado até mesmo dentro de outros plugins. Tem-se também o Linux bridge, controladores OpenFlow, e plugins de fabricantes como a Cisco e Brocade, entre diversos outros. Para este estudo foram avaliadas a proposta de vários deles de modo a auxiliar na implementação e projeção deste trabalho.
Foi realizado o estudo de dois casos de uso presentes em outros plugins, o caso de uso do método de criação de uma rede (Create Network) e o caso de uso do método de remover uma rede (Delete Network). O estudo desses casos de uso resultou em dois diagramas de sequência, um para cada caso de uso. Esses diagramas serão detalhados nos tópicos a seguir. É importante deixar claro que o ator nestes casos pode ser o próprio OpenStack, e que, como este utiliza Network as a servicecomo provedor de serviços, uma requisição da API dos plugins (create, delete, update, etc)é atendida apenas quando for possível responder tal requisição. Portanto, requisições não são necessariamente executadas no momento que a chamada é repassada.
4.1.1 Caso de Uso Create Network
O ato de criar uma rede no OpenStack é equivalente a relacionar um usuário com uma VLAN. Deste modo, este usuário possui acesso a uma determinada rede, podendo então configurar a mesma.
Seguindo o fluxo do caso de uso da Figura 4.1, há uma requisição do usuário para criação de uma rede, esta requisição primeiramente é tratada pela classe BrocadePluginV2. Esta é a classe principal da requisição, a qual envia uma requisição para a classe NeutronDbPluginV2 (classe pai da mesma). O banco de dados interno do OpenStack será atualizado contendo dados da rede que sejam relativos ao próprio OpenStack. Após o retorno do banco de dados, o BrocadePluginV2 envia uma requisição para a classe nosdriver, que é responsável por se comunicar com os comutadores. Portanto, serão enviadas chamadas para os comutadores no formato que estes esperam (Netconf), para que então possam configurar a nova rede. Após configuradas, a operação retorna para a classe BrocadePluginV2. No último passo, esta classe fará uma chamada a classe models, para que então seja atualizado o banco de dados interno do plugin, contendo informações internas da criação de rede. A operação então retorna sucesso ao usuário.
4.1 Plugin do Neutron 33
Figura 4.1: Caso de uso create network abstraido com base no plugin da Brocade
4.1.2 Caso de Uso Delete Network
Remover uma rede é um processo similar à criação de uma rede. Notar que no caso dos pluginsanalisados a atualização no banco de dados do OpenStack ocorre antes da deleção de fato ocorrer. Outra abordagem possível seria aguardar que o processo ocorra nos comutadores, e só então atualizar o banco de dados, o que neste caso é realizado com o banco de dados interno.
Seguindo o caso de uso da Figura 4.2, primeiro o usuário envia a requisição para remoção da rede. A classe BrocadePluginV2 novamente é a classe principal. Esta envia uma requisição para a classe NeutronDbPluginV2 que atualizará o banco de dados do OpenStack. A classe BrocadePluginV2, por sua vez, interage com a classe models para descobrir quais as portas do comutador fazem parte da rede que será removida. Isso é feito uma a uma por meio de uma repetição. Tendo todas as portas associadas a rede, é enviado para a classe nosdriver, o comando para deletar a rede, juntamente com os dados coletados, inclusive a VLAN. A nosdriver então
4.1 Plugin do Neutron 34
Figura 4.2: Caso de uso delete network utilizado no plugin da Brocade
exclui de fato a rede dos comutadores. Por fim, esta classe atualiza o banco de dados interno e a operação termina.
4.1.3 Arquitetura proposta do Plugin
Estudando principalmente os casos de uso apresentados, foi derivada uma arquitetura, a qual pode ser encontrada na figura 4.3 e possui 5 módulos, sendo estes descritos a seguir.
1. main: Classe principal do plugin, esta será a classe que implementa as operações básicas de CRUD (Create, Read, Update e Delete). Faz a interface com o OpenStack, e age como centro das operações.
4.1 Plugin do Neutron 35
Figura 4.3: Arquitetura proposta para o plugin da classe main para a linguagem que os comutadores processam.
3. NeutronDbPluginV2: Classe que se comunica com o banco de dados do OpenStack. 4. Model: Classe que se comunica com o banco de dados interno do plugin, possuindo dados
específicos do plugin.
5. Common: Este módulo guarda atributos e configurações globais, e pode ser acessado pelos outros módulos.
4.1.4 Mudança para driver
A arquitetura descrita até agora expõe a implementação baseada em plugin, considerada promissora no escopo do projeto. Porém após um estudo mais aprofundado do Neutron, e de diversas sessões com os desenvolvedores foram expostas algumas desvantagens dessa abordagem. Uma delas é que o uso de plugins já está caindo em desuso na comunidade, mas principalmente expôs a impossibilidade de uma nuvem heterogênea, pois utilizando um plugin pode-se apenas usar comutadores de fabricantes que suportem uma tecnologia idêntica (normalmente apenas dentre os mesmos fabricantes). Desse modo, foi proposta uma nova arquitetura que pudesse solucionar as limitações quanto a heterogeneidade de fabricantes de comutadores em uma rede para a qual os próprios desenvolvedores aconselharam sobre o uso de drivers oposto ao uso de plugins. Esta nova arquitetura, que será apresentada a seguir, utiliza o já mencionado plugin ML2, focando no entanto na construção de um driver para este.