{"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\/es\/blog\/administrirovanie\/application-centric-infrastructure-arhitektura-seti-budushhego-ot-rassuzhdenij-k-delu","title":{"rendered":"Infraestructura Centrada en Aplicaciones. La arquitectura de red del futuro: de la reflexi\u00f3n a la acci\u00f3n","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

En los \u00faltimos a\u00f1os, Cisco ha estado promoviendo activamente una nueva arquitectura para la construcci\u00f3n de redes de datos en los centros de datos \u2014 Infrastructure Centric Application (o ACI)<\/b>. Algunos ya est\u00e1n familiarizados con ella. Otros incluso han logrado implementarla en sus empresas, incluida Rusia. Sin embargo, para la mayor\u00eda de los profesionales de TI y l\u00edderes de TI, ACI sigue siendo o bien una abreviatura incomprensible, o simplemente una reflexi\u00f3n sobre el futuro.
\nEn este art\u00edculo, intentaremos acercar ese futuro. Para ello, hablaremos de los principales componentes arquitect\u00f3nicos de ACI y tambi\u00e9n ilustraremos c\u00f3mo aplicarla en la pr\u00e1ctica. Adem\u00e1s, en un futuro cercano organizaremos una demostraci\u00f3n visual del funcionamiento de ACI, a la que podr\u00e1 inscribirse cualquier profesional de TI interesado.
\n<\/a><\/noindex>
\nPodr\u00e1 conocer m\u00e1s sobre la nueva arquitectura de redes en San Petersburgo en mayo de 2019. Todos los detalles est\u00e1n en el enlace<\/a><\/noindex>. \u00a1Inscr\u00edbase!<\/p>\n

Antecedentes<\/b>
\nEl modelo tradicional y m\u00e1s popular para construir redes es el modelo jer\u00e1rquico de tres niveles: n\u00facleo -> distribuci\u00f3n (agregaci\u00f3n) -> acceso. Durante muchos a\u00f1os, este modelo ha sido el est\u00e1ndar, para el cual los fabricantes han lanzado diferentes dispositivos de red con las funciones correspondientes.
\nAntes, cuando las tecnolog\u00edas de la informaci\u00f3n eran una especie de accesorio necesario (y, para ser honestos, no siempre deseado) para el negocio, este modelo era conveniente, bastante est\u00e1tico y fiable. Sin embargo, ahora, cuando TI son uno de los motores de desarrollo del negocio, y en muchos casos el propio negocio, la rigidez de este modelo ha comenzado a causar grandes problemas.<\/p>\n

El negocio moderno genera una gran cantidad de diversos y complejos requisitos para la infraestructura de red. La capacidad de respuesta ante esos requisitos depende directamente del \u00e9xito del negocio. La demora en tales condiciones es inaceptable, y el modelo cl\u00e1sico de construcci\u00f3n de redes a menudo no permite satisfacer todas las necesidades comerciales a tiempo. <\/p>\n

Por ejemplo, la aparici\u00f3n de una nueva aplicaci\u00f3n empresarial compleja implica que los administradores de red realicen una gran cantidad de operaciones rutinarias similares en una gran variedad de dispositivos de red a diferentes niveles. Adem\u00e1s de que esto consume mucho tiempo, tambi\u00e9n aumenta el riesgo de cometer un error, que puede llevar a un par\u00f3n grave en los servicios de TI y, como resultado, a p\u00e9rdidas financieras.<\/p>\n

La ra\u00edz del problema no son ni los plazos ni la complejidad de los requisitos. Lo que sucede es que estos requisitos deben \"traducirse\" del lenguaje de las aplicaciones empresariales al lenguaje de la infraestructura de red. Como es bien sabido, cualquier traducci\u00f3n siempre implica una p\u00e9rdida parcial de significado. Cuando el propietario de la aplicaci\u00f3n habla sobre la l\u00f3gica de funcionamiento de su aplicaci\u00f3n, el administrador de red comprende un conjunto de VLAN y listas de acceso en decenas de dispositivos que deben ser mantenidos, actualizados y documentados.<\/p>\n

La experiencia acumulada y la comunicaci\u00f3n constante con los clientes han permitido a Cisco dise\u00f1ar e implementar nuevos principios para la construcci\u00f3n de redes de datos en centros de procesamiento que responden a las tendencias modernas y se basan, en primer lugar, en la l\u00f3gica de las aplicaciones empresariales. De ah\u00ed el nombre: Infraestructura Centrada en Aplicaciones.<\/p>\n

Arquitectura ACI.<\/b>
\nEs m\u00e1s correcto considerar la arquitectura ACI no desde una perspectiva f\u00edsica, sino l\u00f3gica. Se basa en un modelo de pol\u00edticas automatizadas, cuyos objetos en el nivel superior se pueden dividir en los siguientes componentes:<\/p>\n

    \n
  1. Red basada en conmutadores Nexus.<\/li>\n
  2. Cl\u00faster de controladores APIC;<\/li>\n
  3. Perfiles de aplicaci\u00f3n;<\/li>\n<\/ol>\n

    \n\"Infraestructura
    \nExaminemos cada nivel con m\u00e1s detalle, pasando de lo simple a lo complejo.<\/p>\n

    Red basada en conmutadores Nexus<\/b>
    \nLa red en una f\u00e1brica ACI se asemeja a un modelo jer\u00e1rquico tradicional, pero se construye de manera significativamente m\u00e1s sencilla. Para la organizaci\u00f3n de la red se utiliza el modelo Leaf-Spine, que se ha convertido en el enfoque com\u00fan para la implementaci\u00f3n de redes de nueva generaci\u00f3n. Este modelo consta de dos niveles: Spine y Leaf, respectivamente.
    \n \"Infraestructura
    \nEl nivel Spine se encarga \u00fanicamente del rendimiento. El rendimiento total de los conmutadores Spine es igual al rendimiento de toda la f\u00e1brica, por lo que en este nivel se deben utilizar conmutadores con puertos de 40G o m\u00e1s.
    \nLos conmutadores Spine se conectan a todos los conmutadores de nivel superior: los conmutadores Leaf, a los que se conectan los hosts finales. La funci\u00f3n principal de los conmutadores Leaf es la capacidad de puerto. <\/p>\n

    De este modo, se resuelven f\u00e1cilmente los problemas de escalabilidad: si se requiere aumentar el ancho de banda de la f\u00e1brica, agregamos conmutadores Spine, y si necesitamos aumentar la capacidad de puerto, a\u00f1adimos Leaf.
    \nPara ambos niveles, se utilizan los conmutadores de la serie Cisco Nexus 9000, que para Cisco son la herramienta principal para construir redes de centros de datos independientemente de su arquitectura. Para el nivel Spine se utilizan conmutadores Nexus 9300 o Nexus 9500, y para Leaf solamente Nexus 9300.
    \nLa gama de conmutadores Nexus utilizados en la f\u00e1brica ACI se muestra en la imagen a continuaci\u00f3n.
    \n \"Infraestructura<\/p>\n

    El cl\u00faster de controladores APIC (Controlador de Infraestructura de Pol\u00edticas de Aplicaci\u00f3n) <\/b>
    \nLos controladores APIC son servidores f\u00edsicos especializados; para peque\u00f1as implementaciones, se permite utilizar un cl\u00faster de un controlador APIC f\u00edsico y dos virtuales.
    \nLos controladores APIC realizan funciones de gesti\u00f3n y monitoreo. Es importante se\u00f1alar que los controladores nunca participan en la transmisi\u00f3n de datos, es decir, incluso si todos los controladores del cl\u00faster fallan, esto no afecta en absoluto a la estabilidad de la red. Tambi\u00e9n es importante destacar que, a trav\u00e9s de los APIC, el administrador gestiona todos los recursos f\u00edsicos y l\u00f3gicos de la f\u00e1brica, y para realizar cualquier cambio, no es necesario conectarse a un dispositivo espec\u00edfico, ya que en ACI se utiliza un \u00fanico punto de control.
    \n \"Infraestructura<\/p>\n

    Ahora pasemos a uno de los componentes principales de ACI: los perfiles de aplicaciones.<\/b>
    \nPerfil de Aplicaci\u00f3n (Application Network Profile)<\/b> es la base l\u00f3gica de ACI. Los perfiles de aplicaciones determinan las pol\u00edticas de interacci\u00f3n entre todos los segmentos de red y describen directamente los segmentos de red. ANP permite abstraerse del nivel f\u00edsico y, en esencia, visualizar c\u00f3mo se debe organizar la interacci\u00f3n entre los diferentes segmentos de la red desde la perspectiva de la aplicaci\u00f3n. <\/p>\n

    El perfil de la aplicaci\u00f3n consiste en grupos de conexiones (End-point groups \u2013 EPG). Un grupo de conexiones es un conjunto l\u00f3gico de hosts (m\u00e1quinas virtuales, servidores f\u00edsicos, contenedores, etc.) que se encuentran en un mismo segmento de seguridad (no de red, sino espec\u00edficamente de seguridad). Los hosts finales que pertenecen a un EPG espec\u00edfico pueden definirse mediante una gran cantidad de criterios. Normalmente se utilizan los siguientes: <\/p>\n