Olá a todos!

No meu último artigo, escrevi sobre virtualização de servidores, e neste artigo vou apresentar uma solução que vem se consolidando no mercado, apesar de ser estudada já há algum tempo. É uma solução relativamente nova: o SDN (Software Defined Networking).

As atuais tecnologias de rede não dão conta de todas as exigências dos usuários e das empresas devido à sua complexidade e à quantidade de protocolos utilizados; geralmente são desenvolvidas e definidas de forma isolada e, para dificultar ainda mais, alguns fabricantes desenvolvem “protocolos proprietários”.

Dessa forma, quando é preciso escalar a rede e adicionar mais dispositivos, essa tarefa se torna cada vez mais complexa, pois praticamente não existe interoperabilidade entre alguns fabricantes e, quando isso se faz necessário, novos aplicativos e protocolos são desenvolvidos, o que às vezes pode ser um processo lento, o que inviabiliza a implantação de novas tecnologias em uma planta de redes já existente.

Além desse detalhe, os pesquisadores na área de redes de computadores têm problemas em testar novas ideias, uma vez que os switches/routers encontrados hoje no mercado são criados com protocolos fechados e com software pertencente às empresas. Em consequência disso, novas ideias surgem para melhorar o desempenho das redes existentes, porém essas pesquisas permanecem em ambientes de laboratório, não sendo possível testar essas ideias em diferentes escalas para avaliar se a solução tem ou não o funcionamento esperado. E, como sabemos, hoje é praticamente impossível testar soluções em redes de produção, ainda mais em grandes empresas.

Com esse problema em mente, a arquitetura Software Defined Networking (SDN) surgiu para superar os problemas de switches e routers fechados e de softwares proprietários, a fim de não comprometer os serviços de redes em produção, e para facilitar a inovação. O SDN permite uma separação útil entre os planos de controle e de dados: essa separação torna possível haver switches e routers encaminhando dados de acordo com novas regras que se encontram num servidor. O resultado é que o plano de controle da rede fica à disposição dos pesquisadores, que agora podem aplicar as suas novas ideias sem violar as regras existentes de roteamento e sem causar problemas de funcionamento das redes em produção.

A grande sacada da arquitetura SND é possibilitar a rápida configuração da rede conforme a demanda de serviços e os negócios das empresas, além de permitir a criação de features e protocolos, independentemente dos fabricantes.

Os principais fabricantes de equipamento de redes estão correndo para a oferta de produtos compatíveis com o modelo, como a compra da Nicira pela VMware, o lançamento de switches com software aberto, como os da Arista Networks, entre outros.

Outra dificuldade encontrada hoje é que um grande parque de equipamentos de diferentes fabricantes sempre exige mão de obra altamente especializada, o que nem sempre é possível. No caso de uma rede definida por software, um administrador de rede pode moldar o tráfego a partir de um controle centralizado sem precisar mexer em equipamentos de diversos fabricantes. O administrador pode alterar as regras de qualquer switch de rede, quando necessário, priorizando ou mesmo bloqueando determinados tipos de pacotes com um nível muito alto de controle. Isso é especialmente útil em redes grandes e cloud computing, pois permite que o administrador gerencie as cargas de tráfego de uma forma flexível e mais eficiente.

SDN é por vezes referido como o “assassino Cisco”, porque permite que os engenheiros de rede suportem redes de múltiplos fabricantes. Atualmente, a especificação mais popular para a criação de uma rede definida por padrão é chamada de OpenFlow .

Hoje, os clientes já estão “vendidos” para Infraestruturas de Serviços (IaaS),(PaaS) e (SaaS), que possuem diversos sistemas e softwares proprietários vindos de vários fabricantes, mas o que dizer de se utilizar a rede como um serviço? Apesar do fato de a nuvem estar ligada através da rede, ouve-se pouco ou nada sobre um novo paradigma para a nuvem. Rede como um serviço não só é real, mas é provável que se torne universal. No entanto, pode ser necessário utilizar um software de rede definida (SDN) sob a forma de OpenFlow para que isso aconteça.

Cloud computing implanta uma infinidade de recursos que podem ser provisionados sob demanda. A nuvem também envolve conexões aos seus usuários, acesso a armazenamento, comunicações unificadas e alocação de recursos ou de gestão. As tecnologias de rede Ethernet têm deficiências quando se trata de serviços em nuvem por causa de segurança, QoS, escalabilidade e custos operacionais.

Como praticamente todos os devices de rede e servidores funcionam sob IP, a presunção de conectividade universal torna mais difícil de gerenciar e ter segurança no tráfego. Uma solução proposta é centralizar uma política de conexão usando SDN. Em SDNs, os terminais não têm como se conectar, então nada na rede está ligado em primeiro lugar. Em vez disso, um controle de software decide que conexões serão permitidas, quais as premissas de segurança, engenharia de tráfego e somente então será acessada por quem tem permissão de se conectar.

Essa gestão de recursos de rede centralizada é virtualmente idêntica ao recurso de gestão por trás das IaaS, PaaS e SaaS em nuvem. Portanto, não será uma surpresa a arquitetura SDN servir de base para a rede como um serviço. Muitos dos principais fabricantes de switches e roteadores manifestaram apoio ao OpenFlow, que é a arquitetura por trás da implementação da SDN.

OpenFlow é uma combinação de software de especificação e de código aberto que funciona nos devices de rede, com controle unificado. Em uma rede OpenFlow, quando um switch ou roteador recebe um pacote, em vez de tomar a decisão sozinho, o device envia o pacote para o controlador, que, em seguida, utiliza critérios para tomar a decisão. Essas políticas, então, criam uma regra de encaminhamento, que o controlador passa de volta para o dispositivo solicitante.

Um dos maiores desafios é que uma rede OpenFlow não pode funcionar se cada pacote precisar ser enviado para um controlador central a fim de ser analisado. Para fazer um trabalho de rede com escalabilidade, o OpenFlow deve ser melhorado ou o seu uso deve ser contido dentro de rede em nuvem. Ambas as opções já estão sendo propostas. OpenFlow vai funcionar melhor quando o tráfego for composto de um número modesto de fluxos previsíveis. Dessa forma, uma vez que os switches e roteadores tiverem aprendido as regras de trânsito a partir do controlador, a interação adicional com o controlador será reduzida.

Quando usado em um datacenter para o controle de servidor para servidor ou servidor para storage, o OpenFlow serve de contribuição muito importante. Mesmo dentro de datacenters em uma nuvem (pública, privada ou híbrida) distribuída, o OpenFlow poderia ser utilizado para gerenciar o tráfego.

Felizmente, várias pesquisas estão sendo feitas para interagir OpenFlow com MPLS e gerar um novo tipo de rede IP que oferecerá uma combinação de conectividade aberta e políticas de gestão de conectividade. Existem também as formas potenciais de fazer o controle OpenFlow de forma mais hierárquica e escalável. Além disso, há iniciativas em cloud computing, em que o conceito de rede como um serviço surgiu, para gerir a forma de lidar com aplicações em nuvem. Essas iniciativas convertem aplicativos em “serviços virtuais” na nuvem. É muito cedo para dizer se eles irão criar um OpenFlow escalável, mas, se o fizerem, haverá um avanço em modelos de rede como um serviço, melhorando a forma de como os recursos são acessados.

Essas novidades podem não ser disponíveis para todos agora, porém todos os indícios apontam que essa inovação ocorrerá em um futuro breve.

Até a próxima!