{"id":33050,"date":"2019-10-31T21:50:27","date_gmt":"2019-10-31T18:50:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/application-centric-infrastructure-arhitektura-seti-budushhego-ot-rassuzhdenij-k-delu\/"},"modified":"2019-10-31T21:50:27","modified_gmt":"2019-10-31T18:50:27","slug":"application-centric-infrastructure-arhitektura-seti-budushhego-ot-rassuzhdenij-k-delu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/application-centric-infrastructure-arhitektura-seti-budushhego-ot-rassuzhdenij-k-delu","title":{"rendered":"Infraestrutura Centrada em Aplica\u00e7\u00f5es. A arquitetura de rede do futuro \u2014 de reflex\u00f5es \u00e0 a\u00e7\u00e3o","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nos \u00faltimos anos, a Cisco tem promovido ativamente uma nova arquitetura para a constru\u00e7\u00e3o de redes de dados em datacenters \u2014 Application Centric Infrastructure (ou ACI)<\/b>. Alguns j\u00e1 est\u00e3o familiarizados com ela. E h\u00e1 quem at\u00e9 tenha implementado em suas empresas, inclusive na R\u00fassia. No entanto, para a maioria dos profissionais de TI e gestores de TI, a ACI ainda \u00e9 uma abrevia\u00e7\u00e3o incompreens\u00edvel ou apenas uma reflex\u00e3o sobre o futuro.
\nNeste artigo, buscaremos aproximar esse futuro. Para isso, falaremos sobre os principais componentes arquitet\u00f4nicos da ACI e ilustramos a forma como ela pode ser aplicada na pr\u00e1tica. Al\u00e9m disso, em breve organizaremos uma demonstra\u00e7\u00e3o pr\u00e1tica do funcionamento da ACI, na qual qualquer profissional de TI interessado poder\u00e1 se inscrever.
\n<\/a><\/noindex>
\nMais informa\u00e7\u00f5es sobre a nova arquitetura de rede poder\u00e3o ser obtidas em S\u00e3o Petersburgo em maio de 2019. Todos os detalhes est\u00e3o em link<\/a><\/noindex>. Inscreva-se!<\/p>\n

Antecedentes<\/b>
\nO modelo tradicional e mais popular de constru\u00e7\u00e3o de redes \u00e9 o modelo hier\u00e1rquico de tr\u00eas camadas: n\u00facleo \u2192 distribui\u00e7\u00e3o (agrega\u00e7\u00e3o) \u2192 acesso. Durante muitos anos, este modelo foi o padr\u00e3o, com fabricantes produzindo v\u00e1rios dispositivos de rede com funcionalidades correspondentes a ele.
\nAntigamente, quando as tecnologias da informa\u00e7\u00e3o eram uma esp\u00e9cie de anexo necess\u00e1rio (e, sejamos francos, n\u00e3o necessariamente desejado) ao neg\u00f3cio, esse modelo era conveniente, bastante est\u00e1vel e confi\u00e1vel. No entanto, agora, quando a TI \u00e9 um dos motores de desenvolvimento dos neg\u00f3cios e, em muitos casos, o pr\u00f3prio neg\u00f3cio, a rigidez desse modelo come\u00e7ou a causar grandes problemas.<\/p>\n

Os neg\u00f3cios modernos geram uma grande quantidade de requisitos complexos para a infraestrutura de rede. O sucesso do neg\u00f3cio depende diretamente da rapidez na implementa\u00e7\u00e3o desses requisitos. A procrastina\u00e7\u00e3o nessas condi\u00e7\u00f5es \u00e9 inaceit\u00e1vel, e o modelo cl\u00e1ssico de constru\u00e7\u00e3o de redes muitas vezes n\u00e3o permite atender a todas as necessidades comerciais a tempo. <\/p>\n

Por exemplo, a introdu\u00e7\u00e3o de uma nova aplica\u00e7\u00e3o empresarial complexa implica que os administradores de rede realizem um grande n\u00famero de opera\u00e7\u00f5es rotineiras semelhantes em uma ampla variedade de dispositivos de rede em diferentes n\u00edveis. Al\u00e9m de tomar muito tempo, isso tamb\u00e9m aumenta o risco de cometer um erro que pode levar a uma interrup\u00e7\u00e3o significativa dos servi\u00e7os de TI e, como resultado, a danos financeiros.<\/p>\n

A raiz do problema n\u00e3o s\u00e3o nem mesmo os prazos ou a complexidade das exig\u00eancias. O fato \u00e9 que essas exig\u00eancias precisam ser \"traduzidas\" da linguagem das aplica\u00e7\u00f5es empresariais para a linguagem da infraestrutura de rede. Como se sabe, qualquer tradu\u00e7\u00e3o \u00e9 sempre uma perda parcial de significado. Quando o propriet\u00e1rio da aplica\u00e7\u00e3o fala sobre a l\u00f3gica de funcionamento de sua aplica\u00e7\u00e3o, o administrador de rede entende um conjunto de VLANs, listas de acesso em dezenas de dispositivos que precisam ser mantidos, atualizados e documentados.<\/p>\n

A experi\u00eancia acumulada e a comunica\u00e7\u00e3o constante com os clientes permitiram \u00e0 Cisco projetar e implementar novos princ\u00edpios para a constru\u00e7\u00e3o da rede de transmiss\u00e3o de dados dos centros de dados, que atendem \u00e0s tend\u00eancias atuais e se baseiam, em primeiro lugar, na l\u00f3gica das aplica\u00e7\u00f5es empresariais. Da\u00ed o nome - Infrastructure Centrada em Aplica\u00e7\u00f5es.<\/p>\n

Arquitetura ACI.<\/b>
\nA arquitetura ACI deve ser considerada n\u00e3o sob uma perspectiva f\u00edsica, mas l\u00f3gica. Ela \u00e9 baseada em um modelo de pol\u00edticas automatizadas, cujos objetos no n\u00edvel superior podem ser divididos nos seguintes componentes:<\/p>\n

    \n
  1. Rede baseada em switches Nexus.<\/li>\n
  2. Cluster de controladores APIC;<\/li>\n
  3. Perfis de aplica\u00e7\u00e3o;<\/li>\n<\/ol>\n

    \n\"Infraestrutura
    \nVamos examinar cada n\u00edvel em mais detalhes \u2013 e faremos a transi\u00e7\u00e3o do simples para o complexo.<\/p>\n

    Rede baseada em switches Nexus<\/b>
    \nA rede na f\u00e1brica ACI se parece com um modelo hier\u00e1rquico tradicional, mas \u00e9 constru\u00edda de forma muito mais simples. Para a organiza\u00e7\u00e3o da rede, utiliza-se o modelo Leaf-Spine, que se tornou a abordagem padr\u00e3o para a implementa\u00e7\u00e3o de redes de nova gera\u00e7\u00e3o. Esse modelo consiste em dois n\u00edveis: Spine e Leaf, respectivamente.
    \n \"Infraestrutura
    \nO n\u00edvel Spine \u00e9 respons\u00e1vel apenas pelo desempenho. O desempenho total dos switches Spine \u00e9 igual ao desempenho de toda a f\u00e1brica, portanto, neste n\u00edvel, deve-se usar switches com portas de 40G ou superiores.
    \nOs comutadores Spine conectam-se a todos os comutadores de n\u00edvel superior: os comutadores Leaf, aos quais os hosts finais se conectam. O papel principal dos comutadores Leaf \u00e9 a capacidade de porta. <\/p>\n

    Dessa forma, quest\u00f5es de escalabilidade s\u00e3o facilmente resolvidas: se precisamos aumentar a capacidade de largura de banda da f\u00e1brica, adicionamos comutadores Spine, e se precisamos aumentar a capacidade de porta \u2013 comutadores Leaf.
    \nPara ambos os n\u00edveis, s\u00e3o utilizados comutadores da s\u00e9rie Cisco Nexus 9000, que representam a principal ferramenta da Cisco para a constru\u00e7\u00e3o de redes de Data Centers, independentemente da sua arquitetura. Para o n\u00edvel Spine, s\u00e3o utilizados os comutadores Nexus 9300 ou Nexus 9500, enquanto para o Leaf, apenas o Nexus 9300.
    \nA linha de modelos de comutadores Nexus, usados na f\u00e1brica ACI, \u00e9 apresentada na figura abaixo.
    \n \"Infraestrutura<\/p>\n

    Cluster de controladores APIC (Application Policy Infrastructure Controller) <\/b>
    \nOs controladores APIC s\u00e3o servidores f\u00edsicos especializados, permitindo, em implementa\u00e7\u00f5es menores, o uso de um cluster composto por um controlador APIC f\u00edsico e dois virtuais.
    \nOs controladores APIC exercem fun\u00e7\u00f5es de gerenciamento e monitoramento. \u00c9 importante ressaltar que os controladores nunca participam da transmiss\u00e3o de dados, ou seja, mesmo que todos os controladores do cluster falhem, a estabilidade da opera\u00e7\u00e3o da rede n\u00e3o ser\u00e1 afetada. Tamb\u00e9m \u00e9 necess\u00e1rio notar que, atrav\u00e9s dos APICs, o administrador gerencia todos os recursos f\u00edsicos e l\u00f3gicos da f\u00e1brica, e para fazer altera\u00e7\u00f5es, n\u00e3o \u00e9 mais necess\u00e1rio conectar-se a um dispositivo espec\u00edfico, pois a ACI utiliza um \u00fanico ponto de gerenciamento.
    \n \"Infraestrutura<\/p>\n

    Agora, vamos passar para um dos principais componentes da ACI \u2013 os perfis de aplicativos.<\/b>
    \nPerfil de aplicativo (Application Network Profile)<\/b> \u00e9 a base l\u00f3gica da ACI. Os perfis de aplicativos definem as pol\u00edticas de intera\u00e7\u00e3o entre todos os segmentos de rede e descrevem diretamente os pr\u00f3prios segmentos de rede. O ANP permite abstrair do n\u00edvel f\u00edsico e, essencialmente, visa como organizar a intera\u00e7\u00e3o entre os diferentes segmentos da rede do ponto de vista do aplicativo. <\/p>\n

    O perfil de aplicativo consiste em grupos de conex\u00f5es (End-point groups \u2013 EPG). Um grupo de conex\u00f5es \u00e9 um agrupamento l\u00f3gico de hosts (m\u00e1quinas virtuais, servidores f\u00edsicos, cont\u00eaineres, etc.) que est\u00e3o em um mesmo segmento de seguran\u00e7a (n\u00e3o rede, mas sim seguran\u00e7a). Os hosts finais que pertencem a um determinado EPG podem ser definidos por um grande n\u00famero de crit\u00e9rios. Normalmente, s\u00e3o utilizados os seguintes: <\/p>\n