Princípios da infraestrutura centrada em aplicativos

Transcrição

1 White Paper Princípios da infraestrutura centrada em aplicativos Resumo Uma das principais inovações em ACI (Application Centric Infrastructure, infraestrutura centrada em aplicativos) é a introdução de uma interface altamente abstrata para expressar a conectividade dos componentes do aplicativo juntamente com políticas de alto nível que controlam essa conectividade. O modelo foi usado para que os desenvolvedores de aplicativos o utilize de forma simples ao mesmo tempo em que melhoram a automação e a segurança. Teoria da política da ACI O modelo da política da ACI é um modelo orientado por objetos baseado na "teoria da promessa". A "teoria da promessa" é baseada no controle escalável de objetos inteligentes em vez dos modelos imperativos mais tradicionais, que podem ser considerados como um sistema de gerenciamento de cima para baixo. Nesse sistema, o gerenciador central deve estar ciente dos comandos de configuração dos objetos básicos e do estado atual destes objetos. Em contrapartida, a "teoria da promessa" conta com os objetos básicos para lidar com as alterações do estado de configuração iniciadas pelo próprio sistema de controle como "alterações de estado desejadas". Os objetos são, dessa forma, responsáveis por transmitir as exceções ou falhas de volta para o sistema de controle. Esta abordagem reduz a carga e a complexidade do sistema de controle e permite maior escalabilidade. Esse sistema se expande ainda mais ainda mais ao permitir que os métodos de objetos básicos solicitem alterações de estado mutuamente e de objetos de nível inferior (Figura 1) Cisco e/ou suas afiliadas. Todos os direitos reservados. Este documento contém informações públicas da Cisco. Página 1 de 8

2 Figura 1. Abordagem da "teoria da promessa" para o controle de sistema em larga escala Neste modelo teórico, a ACI constrói um modelo de objeto para a implantação de aplicativos, com os aplicativos como o foco central. Tradicionalmente, os aplicativos são restringidos pelos recursos de rede e por requisitos para evitar o mau uso das estruturas para implementar a política. Conceitos como endereçamento, VLAN e segurança foram atrelados uns aos outros, limitando a escala e a mobilidade do aplicativo. Como os aplicativos estão sendo reprojetados para mobilidade e escala da Web, esta abordagem tradicional atrapalha a implantação rápida e uniforme. O modelo de política da ACI não determina nada em relação à estrutura de rede básica. Entretanto, como é determinado pela "teoria da promessa", ele exige algum elemento de borda da rede, chamado ileaf, para gerenciar as conexões para diversos dispositivos. Modelo de objeto No nível superior, o modelo de objeto da ACI é construído em um grupo de um ou mais usuários, permitindo que a administração da infraestrutura de rede e os fluxos de dados sejam segregados. Os usuários podem ser usados por clientes, unidades de negócios ou grupos, dependendo das necessidades organizacionais. Por exemplo, uma empresa pode usar um usuário para toda a empresa, e um provedor da nuvem pode ter clientes que usam um ou mais usuários para representar suas empresas. Os usuários podem ser ainda mais divididos em contextos, que se relacionam diretamente a instâncias de VRF (Virtual Route Forwarding) ou espaços de IP separados. Cada usuário pode ter um ou mais contextos, dependendo das necessidades comerciais de tal usuário. Os contextos oferecem uma maneira de separar ainda mais os requisitos organizacionais e de encaminhamento para um determinado usuário. Como os contextos usam instâncias de encaminhamento separadas, o endereçamento IP pode ser duplicado em contextos separados para multiusuários. Dentro do contexto, o modelo oferece uma série de objetos que definem o aplicativo. Estes objetos são EPs (Endpoints) e EPGs (Endpoint Groups, grupos de endpoints) e as políticas que definem sua relação (Figura 2). Observe que as políticas nesse caso são mais do que apenas um conjunto de listas de controle de acesso (ACLs) e incluem um conjunto de: filtros de entrada e saída, configurações de qualidade do tráfego, regras de marcação e regras de redirecionamento Cisco e/ou suas afiliadas. Todos os direitos reservados. Este documento contém informações públicas da Cisco. Página 2 de 8

3 Figura 2. Modelo do objeto lógico A Figura 2 mostra um usuário com dois contextos e os aplicativos que compõem esses contextos. Os EPGs mostrados são grupos de endpoints que criam uma camada de aplicativo ou outro agrupamento de aplicativo lógico. Por exemplo, o Aplicativo B, mostrado no lado direito da figura, pode ser composto de uma camada da Web (azul), uma camada do aplicativo (vermelho) e uma camada do banco de dados (laranja). A combinação dos EPGs e as políticas que definem suas interações é um perfil de rede de aplicativo no modelo da ACI. Grupos de endpoint Os EPGs são um conjunto de endpoints semelhantes representando uma camada do aplicativo ou um conjunto de serviços. Eles oferecem um agrupamento lógico dos objetos que exigem uma política semelhante. Por exemplo, um EPG poderia ser o grupo de componentes que formam uma camada da Web do aplicativo. Os endpoints são definidos usando a NIC (network interface card, placa de interface de rede), a vnic (virtual NIC, NIC virtual), o endereço IP ou o nome do DNS (Domain Name System), com capacidade de extensão para comportar os futuros métodos de identificação dos componentes dos aplicativos. Os EPGs também são usados para representar entidades como redes externas, serviços de rede, dispositivos de segurança e armazenamento de rede. Os EPGs são conjuntos de um ou mais endpoints que oferecem uma função semelhante. Eles são um agrupamento lógico com uma variedade de opções de uso, dependendo do modelo de implantação do aplicativo em uso (Figura 3) Cisco e/ou suas afiliadas. Todos os direitos reservados. Este documento contém informações públicas da Cisco. Página 3 de 8

4 Figura 3. Relações do grupo de endpoints Os EPGs são projetados para proporcionar flexibilidade, permitindo que seu uso seja adaptado a um ou mais modelos de implantação que o cliente possa escolher. Dessa forma, os EPGs são usados para definir os elementos aos quais a política é aplicada. Dentro da estrutura de rede, a política é aplicada entre os EPGs, definindo, portanto, a maneira como os EPGs se comunicam entre si. Essa abordagem foi projetada para ser extensível no futuro para a aplicação da política nos EPGs. Aqui estão alguns exemplos de uso de EPG: EPG definido pelas redes VLANs tradicionais: todos os endpoints conectados a uma determinada VLAN colocada em um EPG EPG definido pela VXLAN (Virtual Extensible LAN): o mesmo que para VLANs, exceto pelo uso da VXLAN EPG mapeado para um grupo de portas do VMware EPG definido por IP ou sub-rede: por exemplo, ou EPG definido pelos nomes de DNS ou faixas de DNS: por exemplo, example.foo.com ou *.web.foo.com O uso de EPGs é flexível e extensível. O modelo tem o objetivo de oferecer ferramentas para criar um modelo de rede de aplicativos que realiza o mapeamento para o modelo de implantação do ambiente real. A definição de endpoints também é extensível, oferecendo suporte para melhorias futuras do produto e requisitos do setor. O modelo de EPG oferece uma grande variedade de vantagens de gerenciamento. Ele oferece um único objeto com política uniforme para ferramentas de orquestração e automação de nível superior. As ferramentas precisam ser operadas em endpoints individuais para modificar as políticas. Além disso, ele ajuda a assegurar a estabilidade entre os endpoints no mesmo grupo, independentemente de seu posicionamento na rede. Fiscalização de políticas A relação entre os EPGs e as políticas pode ser considerada como uma matriz com um eixo representando o sepg (source EPG, EPG de origem) e outro representando o depg (destination EPG, EPG de destino). Uma ou mais políticas serão posicionadas na intersecção dos sepgs e depgs apropriados. A matriz será escassamente povoada na maioria dos casos, porque muitos EPGs não têm necessidade de se comunicar entre si (Figura 4) Cisco e/ou suas afiliadas. Todos os direitos reservados. Este documento contém informações públicas da Cisco. Página 4 de 8

5 Figura 4. Matriz de aplicação da política As políticas são divididas por filtros para a Qualidade do serviço (QoS), o controle de acesso, a inserção de serviços, etc. Os filtros são regras específicas para a política entre dois EPGs. Os filtros são compostos por regras de entrada e de saída: permitir, recusar, redirecionar, registrar, copiar e marcar. As políticas permitem funções curingas nas definições (Figura 5). Normalmente, a aplicação da política usa uma abordagem de primeira correspondência mais específica Figura 5. Regras de aplicação de curingas Perfis de rede do aplicativo Um perfil de rede de aplicativo é um conjunto de EPGs, suas conexões e as políticas que definem estas conexões. Os perfis de rede de aplicativo são a representação lógica de um aplicativo e suas interdependências na estrutura de rede. Os perfis de rede de aplicativo são projetados para serem modelados de maneira lógica que corresponda à forma como os aplicativos são projetados e implantados. A configuração e a aplicação das políticas e da conectividade são tratadas pelo sistema, em vez de serem tratadas manualmente por um administrador. A Figura 6 mostra um exemplo de um perfil de acesso Cisco e/ou suas afiliadas. Todos os direitos reservados. Este documento contém informações públicas da Cisco. Página 5 de 8

6 Figura 6. Perfis de rede do aplicativo Estes passos gerais são necessários para a criação de um perfil de rede de aplicativo: 1. Criar EPGs (como discutido anteriormente). 2. Criar políticas que definam a conectividade com estas regras: Permitir Recusar Registrar Marcar Redirecionar Cópia 3. Criar pontos de conexão entre os EPGs usando estruturas de política conhecidas como contratos. Contratos Os contratos definem a permissão, recusa e regras de QoS para entrada e saída, bem como políticas como o redirecionamento. Os contratos permitem definições simples e complexas da maneira como um EPG se comunica com outros EPGs, dependendo dos requisitos do ambiente. Embora os contratos sejam aplicados entre os EPGs, eles são conectados aos EPGs usando relações entre provedor e consumidor. Essencialmente, um EPG oferece um contrato e outros EPGs consomem aquele contrato. O modelo provedor-consumidor é útil para diversas finalidades. Ele oferece uma maneira natural de fixar um "escudo" ou "membrana" a uma camada de aplicativo que determina a forma como a camada interage com outras partes de um aplicativo. Por exemplo, um servidor da Web pode oferecer HTTP e HTTPS, de forma que o servidor Web pode ser englobado em um contrato que permite somente estes serviços. Além disso, o modelo de contrato provedor-consumidor promove a segurança ao permitir atualizações de política simples e uniformes para um único objeto de política, em vez de permitir para vários links que um contrato pode representar. Os contratos também oferecem simplicidade ao permitir que políticas sejam definidas uma vez e reutilizadas muitas vezes (Figura 7) Cisco e/ou suas afiliadas. Todos os direitos reservados. Este documento contém informações públicas da Cisco. Página 6 de 8

7 Figura 7. Contratos A Figura 8 mostra a relação entre as três camadas de um aplicativo da Web definido pela conectividade do EPG e os contratos que definem sua comunicação. A soma dessas partes constitui um perfil de rede de aplicativo. Os contratos também oferecem a reutilização e estabilidade da política para serviços que normalmente se comunicam com vários EPGs. Figura 8. Perfil de rede de aplicativo completo Conclusão Este documento oferece apenas uma introdução ao modelo de política da ACI: discutindo o que é a ACI e como seu modelo de política pode ser usado. Esse modelo inclui várias outras estruturas e objetos mas, para simplificar, não são abordados aqui. Para mais informações Consulte Cisco e/ou suas afiliadas. Todos os direitos reservados. Este documento contém informações públicas da Cisco. Página 7 de 8