Get best of the week

Cisco UCS a través de los ojos de un proveedor de la nube

Hola Habr!

Ser un proveedor de la nube significa acumular constantemente nuevos conocimientos y experiencia. A lo largo de los años, hemos formado un número bastante grande de prácticas que intentamos cumplir para garantizar el mejor nivel de servicio. Uno de ellos es el uso de soluciones de Cisco Unified Computing System. Debajo del corte, quiero decirles por qué, en nuestra opinión, UCS es una de las mejores soluciones para proveedores, y discutir algunas características del trabajo y los casos de uso del sistema.

Han pasado casi 8 años desde que Cisco UCS apareció en el mercado. Este es un período suficiente para que la audiencia tenga una imagen completa de la tecnología, y de los manuales, reseñas y artículos de capacitación, se puede compilar un volumen voluminoso de libros. Sin embargo, de los artículos de marketing sobre este tema, obtienes dos volúmenes. Intentaremos hablar sobre Cisco UCS de la manera más objetiva posible: destacaremos las características clave de la solución, en base a ellas discutiremos los beneficios para los proveedores de servicios en la nube y compartiremos casos.

En el principio era la palabra


El término "convergencia" fue utilizado por los ingenieros de HP hace unos 10 años. En realidad, HP fue el primero en lanzar los llamados módulos convergentes para su instalación en el chasis HP BladeSystem c7000. Permitieron, por ejemplo, asignar un cierto ancho de banda a un servidor Blade específico. Este fue el primer paso hacia la convergencia, pero esta solución no poseía todas las características necesarias de los sistemas convergentes.

Por si acaso, expliquemos: la infraestructura convergente es un complejo único de equipos y software con un único punto de entrada para administrar todos los equipos incluidos en el complejo, más una orquesta.

En cuanto a Cisco UCS, esta solución ya es totalmente coherente con la definición de convergencia en términos de equipos y parte del paquete de software.

Arquitectura de soluciones


Estudiamos cuidadosamente el esquema anterior y damos una breve descripción de los elementos del complejo "de arriba hacia abajo".



Software Cisco UCS Manager Un

único punto de entrada para administrar todos los componentes de hardware que se muestran en el diagrama, y ​​un orquestador que le permite administrar componentes manualmente o a través de la API REST. Este es un tipo de "cerebro" del complejo. Se instala dentro de Fabric Interconnect. Sin excepción, todos los ajustes del equipo se realizan a través de la interfaz de administración (GUI o CLI) o la API de UCS Manager.

Interconexión de tela

Un conmutador unificado de hardware basado en Cisco Nexus. Proporciona conectividad de red de todos los componentes del complejo, así como conectividad de servidores blade con redes externas. El complejo incluye dos interconexiones de tela. En las últimas versiones, FI6332 y FI6454, es posible conectar hasta 20 chasis 5108, y el número total de servidores blade en este caso alcanza:

  • b480 M5: hasta 80 servidores;
  • b200 M5: hasta 160 servidores.

Actualmente, esta es casi la única solución que brinda oportunidades de integración dentro de un único punto de entrada y admite una conectividad de red sin interrupciones sin el uso de conmutadores ToR adicionales u otros módulos instalados en el chasis junto con los servidores Blade.

Chasis c5108

En comparación con FI, estos son dispositivos bastante simples. Su diseño es estándar para sistemas Blade: PSU, ventiladores, así como un componente clave del chasis: módulos FEX, que proporcionan conectividad entre los servidores Blade y FI. En el momento de la escritura, se admiten los módulos de 4 puertos 40GbE 2304 y los módulos de 8 o 4 puertos 10GbE 2204. Su característica distintiva es la capacidad de agrupar puertos, lo que permite aumentar el ancho de banda general.

VIC (tarjeta de interfaz virtual)

Adaptador inteligente instalado en el servidor Blade. Le permite asignar recursos de red virtual para servidores de hardware y máquinas virtuales. Admite protocolos de transferencia de datos Eth y FC / FCoE.

Ahora que el dispositivo de solución es más o menos claro, hablemos de por qué, en nuestra opinión subjetiva, Cisco UCS es una de las soluciones más convenientes en el mercado.

Por qué Cisco UCS


Ahora que tenemos una idea clara de en qué consiste la solución, hablemos de sus ventajas. ¿Cómo es la solución de Cisco mejor que sus "familiares", por ejemplo, la misma HP Synergy? Nuestros colegas a menudo hacen esta pregunta, aunque la respuesta (como nos parece) yace en la superficie. El punto es este:

  • solución universal, cumplimiento del término "unificado" ⇒ disminución de OPEX;
  • la cantidad mínima de equipo le permite cerrar el número máximo de casos (más sobre ellos a continuación), así como la facilidad de escalado ⇒ CAPEX más bajo;
  • Excelente rendimiento y equilibrio de carga, disponibilidad de nivel empresarial.

De hecho, en estos tres puntos se concentran todos los requisitos principales para la solución, tanto del negocio como del lado de TI. Sin embargo, sin casos, estas ventajas parecen algo infundadas, por lo tanto, las "descifraremos" aún más, dando ejemplos reales.

Aplicación práctica


Como se prometió al comienzo de este artículo, en esta sección veremos los estudios de caso de Cisco UCS. Comenzamos con una revisión de nuestra experiencia y pasamos sin problemas a situaciones específicas.

Puesta en marcha de equipos


Durante el tiempo que usamos las soluciones Cisco UCS, tuvimos que poner en marcha y expandir 8 sistemas en línea (un complejo significa un par de Fabric Interconnect y al menos un chasis blade), en total, 16 FI o más. El primer complejo que pusimos en funcionamiento en 2014, que en ese momento tenía una experiencia práctica mínima. Este proceso nos llevó tres días, dos de los cuales se dedicaron a estudiar la documentación y comprender la lógica del equipo. Tenga en cuenta que la documentación de Cisco está enmarcada al nivel de los mejores libros rojos de IBM: aquellos que estén familiarizados entenderán la comparación.

Habiendo tratado con la lógica y los principios básicos de configuración, ensamblamos y lanzamos fácilmente el equipo. Luego, actualizamos el firmware de todos los componentes, configuramos plantillas de perfil de servidor y creamos perfiles. En solo un día hábil.

La implementación adicional se llevó a cabo como parte de los procedimientos estándar de administración de cambios de ITIL y no llevó más de cuatro horas implementar cada par de IF y uno o dos chasis desde el momento del encendido hasta que el chasis estuvo completamente listo para su uso, incluida la creación y configuración de todas las plantillas y políticas necesarias.

El uso de los módulos REST API y PowerTools puede acelerar el proceso de instalación. Por ejemplo, copiar una VLAN de más de 500 en una nueva instalación se realiza en solo dos simples pasos con PowerTools:

  • Obteniendo la lista de VLAN de la infraestructura de producción
  • cargando la lista de VLAN al nuevo complejo.

El escalado de la infraestructura se realiza conectando un nuevo chasis con servidores Blade al par FI instalado (si hay el número requerido de puertos libres). El procedimiento es 100% en línea y se puede realizar desde la interfaz de Cisco UCS Manager. Con la configuración global correcta, inmediatamente después de que los puertos FI a los que está conectado el chasis se cambien al modo de funcionamiento deseado, estos puertos se recopilan automáticamente en el canal del puerto. A continuación, se inicia un procedimiento de reconocimiento automatizado, en cuyo marco:

  • actualizar todos los componentes del chasis a la versión actual de FW;
  • Ajuste de la tapa de alimentación;
  • mapeo de puertos de plano posterior en FEX a las fábricas y ensambles de canal de puerto necesarios para estos mismos puertos.

Una vez más, recordamos que todo esto se hace sin la intervención de ingenieros, con base en las políticas globales establecidas durante la puesta en marcha del complejo.

Con el tiempo, tal procedimiento lleva aproximadamente una hora y media. La conexión física del nuevo chasis a FI consiste en cambiar FEX a puertos en FI, mientras se utilizan de manera óptima los cables DAC. Y no es necesario tomar cables originales de Cisco.

Explotación


Cuánto de este sonido ... Puedes hablar mucho al respecto, y no solo es bueno. Como dicen, sin un barril de alquitrán, una cucharada de miel no será tan sabrosa. Pero en serio, todos los procedimientos de rutina que tardan muchos minutos u horas en una infraestructura típica se realizan automáticamente desde la GUI. Por ejemplo, para derramar una nueva VLAN en todos los servidores Blade del complejo (y recuerdo que se admiten de 80 a 160 piezas), simplemente agréguelo a la plantilla de vNIC en la sección Política de LAN: la nueva VLAN se derramará automáticamente en todos los servidores Blade, en cuyos perfiles Esta plantilla de vNIC está presente.

Dado que estamos hablando de políticas, vale la pena decir que, literalmente, todas las configuraciones se establecen a través de políticas. Puede, por supuesto, no usarlos, pero será ... ejem, demasiado difícil. Todas las configuraciones de red para servidores Blade, incluidas las direcciones MAC e IP para KVM, Flow Control, LACP, CDP, VMQ, se configuran a través de políticas. La configuración del BIOS, la versión de FW que se cargará en el servidor Blade, el Control de energía, la configuración de acceso IPMI y mucho más se determinan de la misma manera.
Aquí hay otro ejemplo que presenta la capacidad de UCS para automatizar operaciones de rutina, como la configuración de zonificación FC.

En la configuración de la Política de conexión de almacenamiento, es suficiente seleccionar el tipo de zonificación deseado y establecerlo, por ejemplo, como "objetivo único de iniciador único". En este caso, al vincular el servidor Blade a la plantilla de perfil, se creará una zona separada. Esta zona incluirá automáticamente el objetivo WWN especificado y WWPN del HBA virtual desde el puerto deseado que pertenece a la fábrica deseada.

Las políticas están vinculadas a los perfiles de plantilla para servidores. Entonces todo es simple: vincular la plantilla al servidor Blade deseado e inicialización. La salida es un servidor listo para la instalación del sistema operativo. La inicialización del servidor no lleva más de 10-20 minutos, y se puede realizar simultáneamente para la cantidad deseada de servidores. En total, en solo 25-35 minutos obtenemos de 80 a 160 servidores que están completamente listos para la instalación del sistema operativo. Por supuesto, el proceso de instalación también puede automatizarse, y la API de Cisco UCS puede ayudarlo en esta tarea, pero este es un tema para otro artículo.

Total:Para implementar un complejo de un par de FI, chasis de 20 blades y 160 servidores blade M5 de b200 desde cero hasta que esté listo para instalar el sistema operativo, un ingeniero no dedicará más de 8 horas y la mayor parte del tiempo, aproximadamente 3 horas, se dedicará a la creación de políticas y plantillas de perfil . El tiempo restante se puede dedicar a asuntos mucho más importantes, esperando la inicialización del chasis y los servidores blade después de vincular las plantillas a este último. El tiempo de implementación indicado encaja perfectamente en el paradigma de reducción de costos OPEX mencionado anteriormente.

Sistema unificado


Versatilidad, versatilidad y, una vez más, universalidad, probablemente así es como se puede expresar el lema del complejo. Ilustramos esta tesis con una lista de características de Cisco UCS que la hacen única en el mercado incluso después de 8 años. Según los estándares actuales, esto es mucho tiempo.

  • unified 10GbE/16Gbit FC, 40 GbE ( 4x10 GbE breakout);
  • Fibre Channel, Ethernet FCoE FI;
  • FC Fabric FI, FC Brocade NPV;
  • FI rack- Cisco extender', UCS Manager;
  • FI rack- , L2 ;
  • FI Eth FC.

Por supuesto, las capacidades de administración de equipos de terceros no están incluidas en el Administrador de UCS (Cisco tiene otras herramientas para esto), pero las enumeradas anteriormente ya son impresionantes. Aquí hay algunos ejemplos en los que las características unificadas nos han servido bien:

Reemplazo temporal de los switches Cisco Nexus La

entrega de los nuevos switches Cisco Nexus se ha retrasado significativamente. El nuevo almacenamiento de NetApp llegó antes que ellos y podría haber estado inactivo durante varios meses: no había suficientes puertos de 10 GbE para una conexión completa a prueba de fallas. Solución: conecte el almacenamiento a través de puertos FI configurados en modo de dispositivo, configure el canal de puertos con soporte LACP, ponga el almacenamiento en funcionamiento unos meses antes de que lleguen los conmutadores. El equipo está funcionando, generando ingresos, CAPEX está disminuyendo.

Migración a un nuevo sistema de almacenamiento

Nuestro cliente necesitaba migrar datos del antiguo sistema de almacenamiento de EMC al almacenamiento de NetApp con pérdidas mínimas. No hay puertos libres en su antigua fábrica de FC; no hay forma de conectar FI a una fábrica común. Pero había puertos libres en el almacenamiento del cliente. Los conectamos a FI, los levantamos en FC vSAN. Comenzamos la migración de máquinas virtuales a través de Storage vMotion a NetApp conectado a través de NFS. Todo está en orden, todos están felices. La migración se completó con éxito.

Cisco UCS y virtualización


No se puede dejar de mencionar una serie de ventajas proporcionadas por la arquitectura UCS, por ejemplo, para una infraestructura virtual que ejecuta VMware. Los adaptadores VIC, de los que ya hablamos cuando describimos los componentes, se cambian físicamente a través del chasis Midplane con módulos IO a través de los puertos Backplane. De 2 a 4 puertos pueden llegar a un VIC, que se configura automáticamente en los puertos EtherChannel en el nivel de UCS Manager. Esto le permite obtener los siguientes beneficios de las conexiones de red:

  • a nivel físico, obtenemos una conexión a prueba de fallas entre el servidor Blade y el módulo IO a nivel FI. Se proporciona al menos un puerto de plano posterior de Fabric A y uno de Fabric B.
  • FI . EtherChannel Backplane NIC Teaming , , FI. active-active .
  • 256 PCIe virtual devices (vNIC vHBA) VIC. VIC « » Service Profile Template, . vNIC vHBA .
  • Compatibilidad con VM-FEX, con la que puede organizar el paso a través de la conmutación entre VM y FI utilizando la tecnología VMWare Direct Path IO.

Como puede ver, el complejo Cisco UCS realmente se ha probado en una serie de tareas y casos. Por un lado, es una solución bien documentada y probada. Por otro lado, no pierde su relevancia e idealmente cierra en su parte todas las tareas de un proveedor de la nube. Si tiene adiciones al artículo o desea compartir su propia experiencia, los esperamos en los comentarios.

More articles:


All Articles