Administración de redes y automatización : Cisco Intelligent Automation for Cloud 4.0

Switches virtuales múltiples del nexo 1000v de Cisco que configuran IAC 4.0

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este documento proporciona las consideraciones y los pasos relacionados con configurar los switches virtuales múltiples del nexo 1000v para el uso con un solo despliegue del Cisco Intelligent Automation for Cloud.

Los siguientes ejemplos utilizan dos Datacenters que comparte un solo caso del vCenter, aunque el acercamiento y la metodología sea también Datacenters múltiple aplicable usando diversos casos del vCenter que se ejecutan en diverso UCS POD/Clusters. En todos los casos, el intento es soportar los switches virtuales múltiples Nexus1000v con un Cisco IAC y PNSC. Observe que los casos flujo de trabajo-conducidos IAC de Datacenter del vCenter de la configuración de múltiples no están soportados en la versión actual, pues el recurso Cotainer del servicio IAC no puede atravesar a través del vCenter múltiple Datacenters por el momento.

Requisitos

Cisco IAC con el nexo múltiple 1000v se soporta con las versiones del producto enumeradas abajo (no no necesariamente los mínimos). Para la matriz de compatibilidad completa de la solución, refiera a la matriz de compatibilidad de Cisco IAC.

Matriz de compatibilidad de Cisco IAC

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image1.png

Acercamiento de la configuración

El acercamiento detallado en este documento admin-se conduce contra el IAC flujo de trabajo-conducido; significar la configuración de la configuración se hace dinámico de modo que el administrador pueda decidir sobre al crear la organización a la cual Datacenter a desplegar. El cliente que realiza la administración querrá decidir donde los dispositivos de la red virtual y las máquinas virtuales serán desplegados. Más concretamente, durante el aprovisionamiento de agregue la red, agregue las vainas del cálculo y de la red, y agregue los envases del recurso del servicio, enfocan al administrador a quien Datacenter para desplegar una organización y las máquinas virtuales subsiguientes.

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image26.png

Datacenters múltiple - Casos múltiples del vCenter

Los siguientes ejemplos utilizan dos Datacenters que comparte un solo caso del vCenter, aunque el acercamiento y la metodología sea también Datacenters múltiple aplicable usando diversos casos del vCenter que se ejecutan en diverso UCS POD/Clusters. En todos los casos, el intento es soportar los switches virtuales múltiples Nexus1000v con un Cisco IAC y PNSC.

Antecedentes

Según lo mencionado previamente, este despliegue implementa Cisco IAC con dos Nexus1000v bajo dos diverso Datacenters en el mismo vCenter. El ejemplo siguiente muestra cómo todas las áreas asocian juntas.

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image2.png

Para la referencia, aunque no esté descrita específicamente en este documento, aquí es una representación visual donde dos vainas UCS, cada uno con su propio vCenter pueden tener un Cisco IAC y dos switches virtuales Nexus1000v.

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image3.png

Consideraciones de la configuración

Los pasos de la muestra proporcionados estaban para el proof-of-concept que probaba con la intención de proporcionar un Ejemplo de funcionamiento. La meta era modelar los switches virtuales del soporte dos un Nexus1000v del despliegue un caso de Cisco IAC y PNSC. El aprovisionamiento fue hecho solamente para la organización habilitada del servicio de red avanzada y los VDC bajo esas organizaciones.

Usando solo Cisco IAC y PNSC, los recursos fueron descubiertos y registrados; las redes fueron aumentadas así como las vainas y los envases de una manera dinámica con las selecciones que son específicas a cada Datacenter. El resultado final es la capacidad de desplegar una organización en un Datacenter (IT/Support) y entonces otra organización bajo otro Datacenter (IT/Support-II). Ambas organizaciones existen bajo el mismo arrendatario de Cisco IAC y de la perspectiva PNSC aunque no lo hagan tuvieran que.

El resultado final es la capacidad para que el administrador tenga una opción para desplegar los dispositivos del servicio de red avanzada a un Datacenter o a otro. Con la configuración dinámica de las redes, las vainas y los envases, el administrador ahora tienen una opción para desplegar los dispositivos del servicio de red avanzada a un Datacenter o a otro.

Sobre pedir un VDC, la VAINA apropiada del cálculo debe ser seleccionada. Hay la flexibilidad en términos de la cual datastore y cluster para desplegar los VM por al VDC (descrito más adelante). Más allá de esta punta, los VM que ordenan y usar los servicios de red virtual (IP flotante, el atascamiento del balanceador de la carga del servidor) no tienen ninguna dependencia en términos de ser en un segundo Datacenter con un segundo Nexus1000v.

configuración de 1.0 vCenter

Dos Datacenters (soporte y soporte-Ii) son funcionando dentro de un vCenter. Cada Datacenter tiene su propio VS y cada uno tiene un solo host de ESXi que actúa como el módulo VEM para cada VS.

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image4.png

1.1 Configuración Nexus1000v

El nexo 1000v necesita primero ser descubierto por Cisco IAC. Para hacer tan nos proporcionamos el nombre de usuario SNMP, el protocolo de la autenticación y de la aislamiento así como las credenciales de SSH.

Un MD5 tiene de una contraseña se puede generar de la mayoría de los sistemas Unix usando el siguiente comando.

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image5.png

El nexo 1000v debe tener la configuración siguiente relacionada con el SNMP para hacerlo discoverable por Cisco IAC.

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image6.png

De Cisco IAC, ejecute la detección y especifique su Nexus1000v.

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image7.png

1.2 Registro del nexo 1000v

Después de la detección, usted necesita registrar su N1kv de la configuración - > maneje la infraestructura. El registro da a dispositivo un nombre descriptivo, define el papel del dispositivo e identifica el acoplamiento al PNSC que se integra actualmente con.

Lo que sigue es un ejemplo de lo que pudo parecer el formulario de registro en el IAC para Nexus1000v.

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image9.png

Lo que sigue es un ejemplo de la configuración de agente de políticas en la parte inferior de la configuración nexus1000v que debe ya existir para la integración de Nexus1000v y de PNSC:

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image10.png

Lo que sigue confirma la integración con PNSC (PNSC puede ver ambos Nexus1kvs)

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image11.png

1.3 Agregar las redes al IAC

Para las implementaciones de la organización que incluyen los servicios de red avanzada, Cisco IAC se debe hacer enterado cuyo las redes para utilizar. Las redes requeridas son infraestructura, servicio y el Internet Transit será configurado en cada Nexus1kv. Esto significa que el dominio de la capa 2 (VLA N) para cada uno de las redes existe dentro de ambos datacenters.

Cada Nexus1kv tiene un uplink limitado a De esta manera, la comunicación es host-a-host, inter-cluster, o aún inter-datacenter, mientras se propague y no se aísle el dominio de la capa 2. Las redes de la empresa, del balanceador de la carga y del arrendatario no se mencionan aquí mientras que son creadas dinámicamente por Cisco IAC durante la organización y la creación VDC. El usuario y las redes de administración no son relevantes a esta conversación.

Cuando una infraestructura, mantiene o transit network se agrega del Internet, el trayecto de red determinará qué Nexus1kv a utilizar y así que Datacenter debe ser utilizado. Esto es un punto importante a observar como bastante que agregando todos los casos donde se sabe una red – es decir el vSwitch de cada host del esxi, cada Nexus1kv, estamos seleccionando específicamente que el recurso nosotros quiere utilizar para acceder esta red.

El resultado final es que cuando un vnic es asignada a un VM después por el flujo de trabajo de Cisco IAC, utilizará la red asociada al Nexus1kv en su Datacenter. Esta separación se requiere como entre Datacenters mientras que el Nexus1000v se despliega por Datacenter.

Lo que sigue es un ejemplo de la integración del vCenter de los dos switches virtuales funcionando en este documento

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image13.png

Si se asume que el puerto-perfil se ha configurado en el Nexus1000v, la misma red existirá y será a elección (después de la detección por Cisco IAC) como grupo de puertos del vCenter. Este grupo de puertos del vCenter tendrá un específico del trayecto de red al Nexus1000v. El IAC mantiene a estos grupos de puertos y las asignaciones de la red en su base de datos vía la tabla de estándares en la orden deciden más adelante a la red adecuada para utilizar en el vnic asignada al VM.

En las selecciones específicas de las secciones siguientes usadas en la prueba de concepto al realizarse agregue la red.

1.4 red de infraestructura – Agregue las redes a Cisco IAC

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image14.png

1.5 red de servicio – Agregue las redes a Cisco IAC

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image15.png

1.6 transit network de Internet – Agregue las redes a Cisco IAC

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image16.png

1.7 Crear las vainas de la red

Las vainas de la red se requieren para agrupar lógicamente los dispositivos de la comprobación y de la red virtual. En este caso, estamos identificando cada uno del Nexus1kv en cada VAINA de la red y estamos proporcionando al rango de los VLA N para utilizar. Aquí tenemos coincidencia mientras que el IAC puede manejar las redes asignadas y los VLA N por consiguiente pero queremos tener vainas de la red separada como cada uno especifica uno de los switches virtuales Nexus1000v y también para asociar a las vainas individuales del cálculo y a los envases de un recurso; uno específicamente para cada Datacenter.

Un aspecto importante a considerar es que cuando Cisco IAC necesita crear las redes para los arrendatarios, la empresa transita y un balanceador de la carga, él querrá crear estas redes dentro del Nexus1kv que tiene puerto-perfiles (grupos de puertos del vCenter) conectados con los dispositivos virtuales (CSR) de esa organización. Por ejemplo, si el CSR en Datacenter A ha sido aprovisionado con una red de infraestructura para la Administración, y un transit network del Internet en Nexus1kv A, Cisco IAC querrá crear las redes del arrendatario así como la empresa transita y carga la red del balanceador en este mismo Nexus1kv.

Abajo están las configuraciones de la VAINA de la red usadas:

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image17.png

1.8 Crear las vainas del cálculo

La VAINA del cálculo identifica el tipo subyacente de la infraestructura, en este caso vCenter contra OpenStack o EC2. La VAINA también identifica el datacenter del vCenter y al administrador UCS (que representan las B-series h/w que soportan este cluster/POD).

Debe ser observado que aunque ambas vainas del cálculo estén utilizando al mismo administrador UCS y el mismo vCenter (diverso Datacenters), cualquier administrador UCS y vCenter que Cisco IAC haya descubierto esté disponible para la selección. De esta manera, un Nexus1kv en otro Cluster/POD podía ser referido y ser utilizado.

Abajo están los ejemplos de las configuraciones usadas durante esta prueba de concepto. (Observe esto es modifican la vista de las vainas ya creadas del cálculo):

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image18.png

1.9 Mantenga el envase del recurso

El envase del recurso del servicio es el último paso en la identificación y ensamblar de las asociaciones del cálculo, del almacenamiento y de los recursos de red. Vale el tomar del aviso que cada envase del recurso del servicio se ha hecho de selecciones totalmente diversas para todos los elementos; esto es intencional.

Puesto que la VAINA del cálculo se refiere a la VAINA de la red, ésta hace el rango del VLA N del switch virtual y del arrendatario sabido al envase del recurso del servicio. El Datacenter se identifica con la selección de la VAINA previamente configurada del cálculo.

Puesto que el Datacenter podría tener clusteres múltiples de VMware y los datastores, la opción se presenta para hacer una selección para cada uno. Éstos serán utilizados durante el despliegue para determinar la ubicación de los dispositivos de la red virtual.

Las redes definidas están previamente también disponibles para la selección. Esto es un paso importante; recuerde que las redes fueron agregadas y solamente las selecciones singulares fueron hechas basado en el trayecto de red incluyendo el Nexus1000v que es parte del Datacenter.

Por ejemplo:

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image25.png

Es importante seleccionar las redes correspondiente al trayecto de red incluyendo el Nexus1000v para el Datacenter deseado puesto que las máquinas virtuales en este Datacenter tendrán solamente acceso al trayecto de red de su Nexus1000v.

Abajo están los envases del recurso del servicio ensamblados para cada Datacenter; observe por favor que es también posible especificar las reservas del agrupamiento de recursos CPU y de la memoria, el tamaño de la parte (CPU solamente) y los límites.

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image19.png

1.10 Agregue la subred pública a la VAINA de la red

Un aspecto final del aprovisionamiento a considerar es la adición de subredes públicas. Durante Day0 de la configuración de Cisco IAC, se agrega la VAINA inicial de la red así como un pool de las direcciones públicas. Utilizan a las direcciones públicas para el accesibilidad de Internet a las máquinas virtuales en las zonas públicas desprotegidas, las máquinas virtuales en las zonas protegidas vía la flotación de IP (NAT estático) y cargar el IP virtual del balanceador (VIP).

Puesto que una segunda VAINA de la red fue agregada correspondiente al segundo Nexus1000v, es importante recordar agregar un rango de las direcciones públicas para esta VAINA de la red antes de realizar crea la organización.

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image20.png

1.11 Cree la organización

Al crear una organización, uno de los elementos en la forma hará una selección para la cual envase del recurso del servicio. Las opciones de la selección son las opciones intencionales que permiten que el administrador seleccione donde y cómo desplegar los dispositivos virtuales de los servicios de red avanzada (CSR, VSG, VPX); así como con qué redes para conectarlas.

Los detalles del envase previamente ensamblado se presentan convenientemente que la hacen fácil para que el administrador entienda las asignaciones totales ensambladas anterior. Abajo están las selecciones hechas durante la organización de la creación.

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image21.png

Los dispositivos de la red virtual serán desplegados en un agrupamiento de recursos con el mismo nombre que el envase del recurso del servicio como se muestra aquí:

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image22.png

1.12 Cree Datacenter virtual

Una vez que la organización se ha desplegado con éxito, el siguiente paso es crear un centro de datos virtuales. Las selecciones en la forma virtual de Datacenter del crear incluyen la selección de una VAINA, de un cluster y de un Datastore del cálculo. El envase del recurso del servicio también tiene estas selecciones para definir donde estarán creación los dispositivos de la red virtual desplegada de la organización. Con cree el centro de datos virtuales, las selecciones determinará donde desplegarán al arrendatario VM en el vCenter. Estos VM están conectados con las nuevas redes del “arrendatario” agregadas en las zonas públicas y/o privadas, según el VDC.

Tomando el segundo Datacenter (soporte-Ii) como un ejemplo, 2-Zone se ha creado un oro VDC. En este ejemplo, este VDC sostendrá los VM en el mismo cluster y Datastore que los dispositivos de la red virtual. Un nuevo agrupamiento de recursos con la convención para nombres del “arrendatario” - se crea el “VDC”.

La VAINA del cálculo seleccionada debe corresponder a una que tenga la VAINA de la red del Nexus1kv para el Datacenter que usted se prepone utilizar. Esto significa que el administrador debe entender/que recuerda qué VAINA de la red han asociado a la VAINA elegida del cálculo. En nuestros casos, la selección de la VAINA del cálculo que también fue utilizada en el envase del recurso del servicio tiene sentido. Lo mismo agrupan y Datastore también fue elegido para la simplicidad aunque cualquier cluster y Datastore bajo este Datacenter fueran suficiente.

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image23.png

1.13 Consideraciones adicionales

El data-uplink en los VLA N de los trunks Nexus1kv hacia fuera a la tela (vía el vmnic físico) en cada uno de los host de ESXi. Esto necesita ser configurada manualmente para pasar los VLA N específicos de la infraestructura, servicio, Internet transita y rango del VLA N de la VAINA de la red (su arrendatario, balanceador de la carga y redes para empresas subsiguientes).

Un ejemplo del uplink es como sigue:

http://www.cisco.com/c/dam/en/us/support/docs/cloud-systems-management/intelligent-automation-cloud-40/117687-image24.png

1.13 Registro local de la plantilla requerido

El data-uplink en los VLA N de los trunks Nexus1kv hacia fuera a la tela (vía el vmnic físico) en cada uno de los host de ESXi. Esto necesita ser configurada manualmente para pasar los VLA N específicos de la infraestructura, servicio, Internet transita y rango del VLA N de la VAINA de la red (su arrendatario, balanceador de la carga y redes para empresas subsiguientes).

1.14 Consideraciones de la VAINA del cálculo

La VAINA del cálculo seleccionada durante la creación VDC debe tener una asociación de la VAINA de la red que contiene el switch virtual Nexus1000v que usted se prepone utilizar. A la hora de este ser autor, hay la VAINA del cálculo de la capacidad para seleccionar que sigue con CSCuo41679 crea las opciones del descenso-abajo de la vaina del cálculo VDC necesita ser más restrictivo

Resumen Se han definido las vainas múltiples del cálculo. Por ejemplo, VAINA del cálculo de la vaina 'stress2 la “se asocia a una VAINA de la red que tenga Nexus1kv A y otra VAINA del cálculo. el soporte II de la VAINA del cálculo 'Stress2 se asocia a otra VAINA de la red que tenga Nexus1kv B.

Puesto que el org subyacente fue creado con un envase del recurso del servicio que se refería al soporte II de la VAINA del cálculo "Stress2”, el CSR se despliega ya que se refiere al trayecto de red de Nexus1kv A. Si intentamos crear un VDC en este CSR y las redes del arrendatario de la disposición para el VDC en Nexus1kv B, no serán accesibles al CSR. La razón está porque el CSR está en Datacenter A, correspondiente al cálculo y la VAINA de la red que tenía Nexus1kvA y ahora las redes VDC fue creada en Nexus1kv B que no es accesible en Datacenter A.


Información Relacionada


Document ID: 117687