Cloud Paks de IBM. Microservicios en Multi Nube Híbrida

Parte esencial de la Tercera Plataforma. Tecnología fundamental dentro de las doce tecnologías con impacto a corto plazo de la Transformación Digital y uno de los cimientos fundamentales para la Cuarta Revolución Industrial, el Cómputo en La Nube ha sido pues de lo más revolucionario que se tiene ahora en lo referente a las Tecnologías de la Información.

Cómo recordamos y con mucho afecto esos días en los que el Cómputo, los Sistemas, la Informática se llevaba a cabo programando sobre un hardware, para poder obtener un Sistema de Cómputo que pudiese subsanar las necesidades de administración, contabilidad, producción, etc. en una empresa u organización.

El "boom" que vino de la mano de la Segunda Plataforma, o la Arquitectura Cliente-Servidor, hizo que sin darnos cuenta y sin previo aviso, fuésemos responsables de programas de cómputo monolíticos, enormes,  con millones de líneas de código y que cada que fuese necesario realizar un cambio, una actualización, arreglar un desperfecto (por más pequeño que este fuera), requeríamos abrir una ventana de mantenimiento y la operación podía durar un par de meses.

Los negocios, la gestión de empresas y/o entidades de gobierno y todas esas actividades para las que se había creado o comprado una aplicación, evolucionaron por su cuenta y ahora los cambios suceden con una frecuencia inusitada e inverosímil para aquellos tiempos en los que muchas aplicaciones se habían creado. Ahora los usuarios (no decenas ni cientos, sino miles o millones) no estaban detrás de una Terminal "tonta" (en una estación de trabajo fija). Tampoco estaban en Computadoras Personales de Escritorio (Desktops). Mínimo los usuarios están detrás de una Computadora con Monitor Abatible (LapTop), una Tableta con tecnología "touch" y servicio de red inalámbrica o con un Dispositivo Personal Móvil en su mano, y éstos pueden estar en su casa, en un ciber-café, en la calle, en un vehículo de transporte público o inclusive en la Estación Espacial Internacional. Sí. Literalmente donde quieran y utilizando el dispositivo que en ese momento pueden o quieren utilizar. Todo un reto.

Las Redes de Cómputo son ese aparato circulatorio por el cual los datos fluyen en todos los sentidos. Los riesgos de seguridad se han multiplicado y literalmente, los usuarios no pueden esperar más de tres segundos por su información. Para desgracia de muchos negocios, existen muchas opciones para los usuarios quienes no dudarán en abandonar una opción e inmediatamente tomar otra distinta que les ofrezca lo que necesitan, cuando lo necesitan, en donde quiera que estén y sin esperar tres segundos.

¿Se imaginan estar en la época de los Mainframe (Primera Plataforma), o incluso de la Arquitectura Cliente-Servidor (Segunda Plataforma), con los tiempos y procedimientos para crear, actualizar, reparar aplicaciones en estos tiempos tan vertiginosos con usuarios tan exigentes y voraces?

La Nube (pública, híbrida o privada) representó un considerable ahorro para los Costos de Capital (CapEx) y un uso más eficiente en lo que se refiere al Costo Operativo (OpEx). Pero aún así el seguir "montando" inmensas aplicaciones monolíticas (aunque fuese en modalidad Multi-Capa) seguía siendo un enorme reto.

¿Y qué pasó entonces? Nació la Arquitectura de Microservicios (en inglés, Micro Services Architecture, MSA).

Ésta es una aproximación para el Desarrollo de Software que consiste en construir una aplicación como un conjunto de pequeños servicios, los cuales se ejecutan en su propio proceso y se comunican con mecanismos ligeros (normalmente una API de recursos HTTP).

En esta Arquitectura, cada servicio se encarga de implementar una funcionalidad completa del negocio. Cada servicio es instalado, configurado y aprovisionado de forma independiente y puede estar programado en distintos lenguajes, usando diferentes tecnologías de almacenamiento de datos.

¿Cuáles son las características principales de los Microservicios?

• Los componentes son servicios: Los servicios son componentes separados que se comunican mediante mecanismos como los servicios web o los RPC en lugar de usar llamadas a funciones en memoria como hacen las bibliotecas.
  
  
• Organización en torno a las funcionalidades del negocio: El sistema se divide en distintos servicios donde cada uno está organizado en torno a una capacidad del negocio. Es muy importante limitar la responsabilidad de cada servicio. Cada servicio implementa toda la funcionalidad del negocio que agrupa desde la interfaz de usuario, la persistencia en el almacenamiento y cualquiera de las colaboraciones externas.
  
  
• Productos, no proyectos: En esta arquitectura normalmente se sigue la idea de que un equipo debe estar a cargo de un componente (servicio) durante todo el ciclo de vida del mismo, desde la etapa de diseño y construcción, la fase de producción y hasta la de mantenimiento. Esta mentalidad se acopla bien con la vinculación a una capacidad del negocio. En lugar de ver el software como un conjunto de funcionalidades terminadas se ve como una relación continua, donde la pregunta es cómo puede el software ayudar a sus usuarios a mejorar la funcionalidad del negocio que implementa. Esto es facilitado por el bajo nivel de granularidad que ofrecen los microservicios.
  
  
• Extremos inteligentes, tuberías bobas: Las aplicaciones creadas desde microservicios pretenden ser tan disociadas y cohesivas como sea posible, ellas poseen su propia lógica de dominio y actúan como filtros en el clásico sentido UNIX: recibe una solicitud, aplica la lógica apropiada y produce una respuesta. Estos pasos son coreografiados usando protocolos simples (típicamente HTTP con REST o mensajería liviana como RabbitMQ o ZeroMQ) en lugar de protocolos complejos como WS-BPEL.
  
  
• Tener gobernabilidad descentralizada: Con el sistema con múltiples servicios colaborativos, podemos decidir utilizar diferentes lenguajes de programación y tecnologías dentro de cada servicio. De esta forma podemos elegir la herramienta adecuada para cada tipo de trabajo en lugar de tener una estandarizada. Por ejemplo si una parte del sistema necesita mejorar su rendimiento es posible usar una tecnología, quizás más complicada, que permita alcanzar el nivel de rendimiento requerido.
  
  
• Gestión de datos descentralizada: Los microservicios prefieren dejar a cada servicio que gestione su propia base de datos, sean estos diferentes instancias de la misma tecnología de base de datos o sistemas de base de datos completamente diferentes.
  
  
• Diseño tolerante a fallos: Las aplicaciones necesitan ser diseñadas de modo que puedan tolerar las fallas de los distintos servicios. Cualquier llamada de servicio puede fallar y el cliente tiene que ser capaz de responder a esto con la mayor facilidad y eficacia posible, evitando los muy habituales fallos en cascada de las arquitecturas distribuidas.
  
  
• Automatización de la infraestructura: La mayoría de los productos y sistemas desarrollados con el enfoque de microservicios han sido construidos por equipo que usan entrega continua y su precursor la integración continua. Para conseguir esto es necesario:
  • Automatizar todo el proceso, desde el chequeo del código, pruebas, despliegue.
  • Control de versiones y gestión de configuración.
  • Arquitectura (hardware-software-sistema operativo) adecuada. Tiene que permitir realizar cambios sin que afecten al resto del sistema.
  
  
• Diseño evolutivo: Cuando se divide el sistema en servicios hay que tener en cuenta que cada uno tiene que poder ser reemplazado o actualizado de forma independiente.

Todo esto se lee y suena fantástico. ¿Pero cómo es posible lograr todo esto de manera concreta, completa y cabal? La respuesta a esta pregunta de llaman Contenedores de Cómputo.

Los Contenedores son elementos que contienen (valga la redundancia) están centrados en las aplicaciones, para que estas sean escalables de alto rendimiento, pudiéndose ejecutar en cualquier infraestructura que se elija. Los Contenedores son los más adecuados para ofrecer microservicios, al proporcionar entornos virtuales portátiles y aislados para que las aplicaciones se ejecuten sin interferencia de otras aplicaciones en ejecución.

Un contenedor es una unidad estándar de software que empaqueta el código y todas sus dependencias para que la aplicación se ejecute de forma rápida y confiable de un entorno informático a otro. Una imagen de contenedor en la plataforma de ejecución para contenedores Docker, es un paquete de software ligero, independiente y ejecutable que incluye todo lo necesario para ejecutar una aplicación: código, tiempo de ejecución, herramientas del sistema, bibliotecas del sistema y configuraciones.

Aquí ya comenzamos a tocar un tema dentro de esto que es los Contenedores, y aquí vale la pena hacer una aclaración: Los Contenedores NO SON Máquinas Virtuales, y aunque suene a todo un "cliché" o un pleonasmo, las Máquinas Virtuales NO SON tampoco Contenedores. Lo que es más, es posible ejecutar Contenedores DENTRO de Máquinas Virtuales, pero nunca una Máquina Virtual podrá ejecutarse en un ambiente de ejecución para Contenedores, pues la máquina virtual necesita de un Hipervisor.

Vale la pena entonces también hacer un paréntesis para mencionar que, los Micro Servicios (y por ende los Contenedores), nada tienen que ver con la Arquitectura Orientada a Servicios o Service Oriented Architecture (SOA). Un ejemplo de implementación de esta Arquitectura son los Web Services.

La Arquitectura Orientada a Servicios es un estilo de arquitectura de TI que se apoya en la orientación a servicios y se deriva de la Web 2.0 en lo concerniente a relación Negocio a Negocio. La orientación a servicios es una forma de pensar en servicios, su construcción y sus resultados. Aquí un servicio es una representación lógica de una actividad de negocio que tiene un resultado de negocio específico (ejemplo: comprobar el crédito de un cliente, obtener datos de clima, consolidar reportes de perforación).

El estilo de arquitectura SOA se caracteriza por:

• Estar basado en el diseño de servicios que reflejan las actividades del negocio en el mundo real, estas actividades forman parte de los procesos de negocio de la compañía.
• Representar los servicios utilizando descripciones de negocio para asignarles un contexto de negocio.
• Tener requerimientos de infraestructura específicos y únicos para este tipo de arquitectura, en general se recomienda el uso de estándares abiertos para la interoperabilidad y transparencia en la ubicación de servicios.
• Estar implementada de acuerdo con las condiciones específicas de la arquitectura de TI en cada compañía.
• Requerir un gobierno fuerte sobre las representación e implementación de servicios.
• Requerir un conjunto de pruebas que determinen que es un buen servicio.

El desarrollo e implementación de una arquitectura SOA se rige por los principios descritos en el manifiesto SOA. Por otra parte la aplicación de la orientación a servicios se divide en 2 grandes etapas:

• Análisis orientado a servicios (Modelado de servicios)
• Diseño orientado a servicios

Volviendo ahora al tema, para hacer más simple el entendimiento de el concepto de lo que es el Contenedor, imagine por un momento que Usted necesita ejecutar, en su computadora de escritorio un par de aplicaciones. Estas aplicaciones NO es posible instalarlas sobre el mismo Sistema Operativo que actualmente se ejecuta en su equipo de cómputo, pues ambas tienen en común "bibliotecas" (libraries) y recursos informáticos que no pueden compartir. Una evita que la otra se ejecute en el mismo ambiente de ejecución (valgan las redundancias).

¿Qué hacer entonces? Si esto nos lo hubiesen preguntado hace dos años, la respuesta sería: -"...instala VMware WorkStation Player o Virtual Box sobre tu Sistema Operativo, crea dos máquinas virtuales y sobre los respectivos Sistemas Operativos, instala en cada una su aplicación correspondiente."- Hoy y si esta aplicación viene "contenerizada", no necesitas hipervisor alguno. Mientras que el "Kernel" del Sistema Operativo sea compatible a ambas aplicaciones, usando un ambiente de ejecución de contenedores (como el ya mencionado Doker), no es necesaria ninguna Máquina Virtual. Ambas aplicaciones pueden convivir en el mismo Hardware.

Queda entonces claro que, para poder ejecutar contenedores es necesario:

• Un Sistema Operativo (Linux) en el que se pueda instalar el ambiente de ejecución de contenedores
• Un ambiente de ejecución de contenedores (Doker)
• Los contenedores

Sí. Así de sencillo. Huelga decir que estos contenedores pudiesen trabajar completamente independientes uno del otro o trabajar en conjunto para conformar una Aplicación. También podemos inferir de todo esto, que con tan solo un modesto equipo de cómputo (pudiese ser incluso a nivel de escritorio) es posible comenzar con nuestra aventura con los Contenedores.

Todo esto ha estado funcionando tan bien y ha tenido tanto sentido para las empresas y organizaciones, que se disparó una tremenda proliferación de aplicaciones contenerizadas. Esto comenzó entonces a presentar sendos retos para la administración de los Contenedores.

Sólo para comenzar, éstos ya no se instalaban en equipos pequeños, sino que ahora se tenían Clusters de Servidores que proveen todo lo necesario en cuanto a ambiente de ejecución se requiere. Dichos Clusters en su mayoría son basados en plataformas de Virtualización y esto también fue lo que hizo que cada vez se tuviesen ambientes más y más complejos para controlar los Contenedores. Fue entonces que se hizo necesaria una herramienta que permitiese orquestar, administrar de manera centralizada y automatizar la operación de los Contenedores. Nace Kubernetes.

Kubernetes (referido en inglés comúnmente como “K8s”) es una herramienta de Código Abierto creada para la automatización del despliegue, escalabilidad y administración de aplicaciones en contenedores,​ que fue originalmente diseñado por Google y donado a la Cloud Native Computing Foundation (parte de la Linux Foundation). Soporta diferentes entornos para la ejecución de contenedores, incluido Docker.

Ahora los Desarrolladores y el personal de Operación de las empresas y organizaciones, encontraron un muy valioso aliado para poner bajo control desde pequeñas y hasta inmensas cantidades de contenedores.

No vamos a ahondar en el tema de Kubernetes, pues merece un tratamiento aparte. Lo que sí vale la pena mencionar es que aunque es posible ejecutar Contenedores contando tan sólo con Doker (la plataforma o ambiente de ejecución), Kubernetes ha demostrado ser indispensable.

Para muchas áreas de Tecnologías dela Información de empresas y organizaciones, ya en la práctica, poder armar todo lo referente al ambiente de ejecución, automatización, orquestación, administración, etc. para los Contenedores, no resultó tan fácil como se escuchaba o leía. ¿Qué hacer para aprovechar todas las bondades de los Contenedores y no tener que lidiar con todo lo que implica poner a punto toda esa estructura necesaria). Llegó al rescate Red Hat® OpenShift®.

OpenShift® es una familia de productos de software de contenedorización desarrollados por Red Hat®. Su producto estrella es OpenShift® Container Platform, una plataforma local como servicio construido alrededor de contenedores Docker orquestados y administrados por Kubernetes sobre la base de Red Hat® Enterprise Linux. 

La familia de productos OpenShift® proporciona la ten necesaria plataforma a través de diferentes entornos: OKD (Origin Community Distribution) que sirve como el upstream impulsado por la comunidad (similar a la forma en que Fedora está upstream de Red Hat® Enterprise Linux). OpenShift® Online, la plataforma que se ofrece como software como servicio y OpenShift® Dedicated, la plataforma que se ofrece como servicio gestionado.

Hasta el momento hemos mencionado que los Contenedores son ideales para crear un ambiente de Plataforma como un Servicio, sobre nuestra Infraestructura como un Servicio, en nuestros Centros de Datos Definidos por Software. Digamos que ahora tenemos nuestra Nube Privada ejecutando nuestros Contenedores.

¿Y qué sucede cuando queremos incorporar Servicios de Infraestructura en Nubes Públicas? Cierto. La evolución a entornos de ejecución fuera de la empresa, da soporte y es esencial para esa necesidad de proveer a nuestros Usuarios de sus aplicaciones que se puedan ejecutar donde sea, cuando sea, a través del dispositivo que sea.

Leyes, normatividades, regulaciones pusieron un freno a la migración total desde La Nube Privada (o los ambientes On Premise) hacia La Nube Pública. Por lo que las empresas y organizaciones optaron por un mitad-y-mitad naciendo con esto La Nube Híbrida. En esta modalidad se aprovecha lo mejor de La Nube Privada y La Nube Pública, dando como resultado un ambiente de ejecución homogéneo (o idealmente homogéneo) en donde los Usuarios "ni se enteran" de a dónde se están ejecutando sus Servicios. Ellos simplemente disfrutan de estos.

El nuevo reto entonces era elegir en qué proveedor de Nube Pública ejecutar nuestros Contenedores. Pues en un principio y aunque los ambientes de ejecución de Contenedores no requieren de bastos recursos informáticos, sí es indispensable el armar toda la estructura (física y/o virtual) que de sustento dicho ambiente de ejecución.

Aquí es entonces a donde entra el concepto de los Cloud Paks de IBM. Son software con tecnología de Inteligencia Artificial para La Nube (o Multi Nube) Híbrida , que nos permite implementar por completo flujos de trabajo inteligentes la empresa u organización, para acelerar el camino a la transformación digital en lo que a Contenedores se refiere.

IBM Cloud Paks aprovecha el poder de IBM Watson® para aplicar Inteligencia Artificial a su negocio, predecir y dar forma a resultados futuros, automatizar procesos complejos, optimizar el tiempo de administradores de T.I. y crear ambientes más ágiles y seguros.

Basados en Red Hat® OpenShift®, es posible desarrollar o instalar aplicaciones contenerizadas una vez, e implementarlas en cualquier lugar de cualquier Nube Pública o Privada. Además, puede integrar la seguridad y automatizar las operaciones con visibilidad de gestión. IBM Cloud Paks tiene una base común de componentes empresariales que aceleran el desarrollo, brindan una integración perfecta y ayudan a mejorar la colaboración y la eficiencia.

Los flancos en los que tenemos por el momento los Cloud Paks son:

• Datos
• Automatización del Negocio
• Operaciones con Inteligencia Artificial provista por Watson
• Integración
• Automatización de la Red
• Seguridad

En entregas posteriores abordaremos cada uno de estos Cloud Paks. Por el momento baste decir que si dentro de los requerimientos de su empresa u organización ya se está trabajando y/o se requiere implementar a corto plazo la contenerización de sus aplicaciones, Cloud Paks de IBM son la mejor alternativa Multi Nube.

¿Su empresa u organización ya está trabajando con Contenedores?

Internet de las Cosas desde abajo: Acumulación y Abstracción de Datos

En entradas anteriores hemos hablado de las primeras tres capas inferiores, en lo que respecta a una solución de Internet de las Cosas. Más concretamente:

1.- Dispositivos y Controladores Físicos
2.- Conectividad
3.- Edge Computing

Para continuar entonces, mencionaremos que para esta entrada decidimos unir la cuarta y quinta capas, pues ambas tienen una intrínseca y muy cercana relación no solo por el sufijo "de los Datos", sino porque una sin la otra no tienen sentido.

Sí. ¿De qué sirve acumular Datos generados por los sensores, actuadores y por la capa de Cómputo Perimetral, sin poder tener herramientas que permitan convertirlos en Información útil? Aunque no lo parezca, existe una diferencia abismal entro los Datos y la Información pues la segunda definitivamente no pueden vivir sin los primeros.

Lo primero que nos puede venir a la mente para poder responder a las muy posiblemente inmensas necesidades demandantes por Acumulación y Abstracción de los datos generados por Internet de las Cosas, es sin duda Big Data. ¿Es necesario entonces apuntar hacia esa y solo alternativa? Nuestra respuesta es no.

No queremos decir que Big Data no puede tener cabida. Cierto que de ella, las primeras cuatro de sus primeras cinco "Vs" pueden ayudarnos mucho:

• Velocidad
• Volumen
• Valor
• Veracidad

¿Qué hay de la Variedad? Como ya lo hemos hablado en las entradas anteriores, para poder tener éxito en una solución de Internet de las Cosas, es poder llegar a la estandarización. Sin ese proceso de ajustar o adaptar características en todas las capas y procedimiento de la solución, con el objetivo de que se apeguen a un modelo en común, simplemente el proyecto y sus objetivos parciales y totales, no puede llegar a buen termino.

Por ende, aquí la variedad no cuenta mucho, pues al final e insistimos, la estandarización manda.

La Acumulación perfectamente emparenta con el "Volumen", mientras que la "Velocidad" es muy valiosa, sobre todo en procesos en los que se requiere captar mucha información en tiempo real.

Obviamente esta información debe de pasar por un proceso que permita validar su "Veracidad" y por ende, dicha información podrá agregar "Valor al negocio.

Pensando con más detalle todo esto, tal parece entonces que más que un proyecto que involucra a Big Data, una solución de Internet de las Cosas requiere de Analíticos.

Las soluciones y Software para Analíticos no son cosa nueva. Desde inicios del siglo XXI, empresas como IBM, Oracle y otras tantas comenzaron a ofertar productos y servicios que se adaptan a necesidades de la micro, pegueña, mediana y gran empresa.

El objetivo de incorporar Analíticos es simple. Más allá de que nuestros dispositivos sensores sean tan inteligentes como para comportarse al más puro estilo del Cómputo Periférico o de Frontera, es necesario registrar esa información.

De manera similar a cuando nosotros aprendemos por la experiencia, haciendo, de manera semejante una solución de Internet de las Cosas debe de tener la capacidad y las herramientas suficientes y necesarias para lo mismo: aprender.

Esto entonces permitirá que, con algoritmos de Inteligencia Artificial, Aprendizaje de Máquina, etc. la Internet de las Cosas agregue valores agregados que redunden no solo en el éxito de la solución per se, sino el negocio en lo general.

Es precisamente con la Acumulación y Abstracción de datos, como las empresas, organizaciones o instituciones que integren la Internet de las Cosas a su "día a día", podrán integrar capas superiores como son las Aplicaciones (de cualquier índole) y esa cereza del pastel que es la Colaboración y Procesos hacia con el negocio.

¿Qué es y cuáles serían las consecuencias a corto, mediano y/o largo plazo, por no contar con Acumulación y Abstracción de Datos en una solución de Internet de las Coasas?

Es, solo para comenzar, como tener a un genio trabajando en nuestra empresa, pero que todo su trabajo se fuese por el drenaje. Estaríamos simplemente siendo reactivos (como ya de por sí lo son el 90% de las empresas en el mundo), dejando ir información y datos tan valiosos y variados, que nos permitirían ser mas proactivos, para con esto poder reaccionar más velozmente a los cambios cada vez más rápidos del ambiente productivo y de negocios.

¿Qué soluciones o productos de Analíticos son los mejores para nuestro proyecto de Internet de las Cosas? Cualquiera que permita entradas de datos de las fuentes citadas en entradas anteriores, sobre todo en lo que concierne a la capa de el Cómputo Periférico o de Frontera.

Vale la pena revisar cómo la capa arriba mencionada entrega los datos, así como también cómo "interfacear" con estos desde el punto de vista de la capa que permita realizar la Acumulación de los Datos. Será entonces que la capa de Abstracción de los Datos, permita que estos sean aprovechados por las Aplicaciones y la capa de Colaboración y Procesos, que estamos seguros que ya existe en la empresa, organización y/o institución que interesada en la solución de Internet de las Cosas.

Brevemente entonces podemos concluir que, la Acumulación y la Abstracción de Datos, son las capas que dan sustento y factibilidad a un proyecto de Internet de las Cosas, asegurando además su trascendencia y siendo la interfaz "de facto", para las capas superiores como lo son:

• Las Aplicaciones.- Todo lo relativo a Reportes, Análisis, Control.
• Colaboración y Procesos.- En donde se involucra directamente a personas y los ciclos del negocio.

En entradas posteriores hablaremos más a detalle de estas dos capas, que son (insistimos y perdón por ser tan reiterativos) lo que coronará el éxito de nuestro proyecto de Internet de las Cosas.

No todo es Contenedores

La tecnología de contenedores, como Docker, se ha vuelto cada vez más popular entre los proveedores de nube y las empresas. ¿Pero son los contenedores adecuados para su organización?

La tecnología de contenedores ha tomado el mercado de La Nube casi por la fuerza, a medida que los proveedores siguen adoptando Docker, CoreOS y otros que entran en la mezcla. Pero antes de incluir los contenedores en su estrategia de Nube, es esencial entender cómo funciona la tecnología y si se ajusta a las necesidades de su organización.

Los contenedores ofrecen un enfoque alternativo a la virtualización de servidores. Para implementar contenedores, primero es necesario instalar un sistema operativo (OS) huésped (Linux de preferencia), en vez de un hipervisor. A continuación, se debe instalar una capa de abstracción como una aplicación, que se ejecuta en el sistema operativo subyacente. Esta maquinaria o capa de abstracción crea las condiciones que aceptará los espacios para la ejecución de las aplicaciones, que no son otra cosa que los contenedores. Cada contenedor puede ejecutar su propia aplicación o copias de la misma aplicación, pero todos los contenedores comparten el mismo núcleo único o kernel de sistema operativo.

La dependencia hacia un solo sistema operativo puede hacer que los contenedores sean menos versátiles que las máquinas virtuales que se ejecutan sobre un hipervisor. Por ejemplo, como los contenedores deben moverse a los servidores con los núcleos del sistema operativo compatibles, migrar contenedores requiere más estrategia y planificación. Por otro lado, las máquinas virtuales tradicionales pueden migrar a casi cualquier lugar con un hipervisor adecuado, independientemente del sistema operativo.

Sin embargo, debido a que los contenedores comparten un solo kernel del sistema operativo, pueden reducir los costos de licencias del sistema operativo, aumentar el rendimiento y eliminar los recursos de memoria y procesador necesarios, para ejecutar múltiples versiones del sistema operativo.

La tecnología de contenedores puede beneficiar a los entornos de nube en una variedad de maneras. En comparación con las pesadas máquinas virtuales, los contenedores son ambientes de componentes ligeros que permiten a las aplicaciones moverse entre las ya distintas nubes, sin necesidad de un gran trabajo por rehacerlas. Los contenedores acomodan diferencias de plataformas, en lugar de las aplicaciones que se ejecutan en ellas. Esto ha creado un diferenciador y es lo que beneficia a DevOps y a los desarrolladores de software.

Además, los contenedores reducen los recursos redundantes que cada instancia virtual necesita, permitiendo al mismo servidor alojar más contenedores que VMs comparables, lo que mejora significativamente la escalabilidad y el rendimiento de la nube.

Por lo tanto, ¿son los contenedores adecuados para su organización y estrategia de nube? Los contenedores son ideales para entornos que exigen escala y comparten componentes clave. Por ejemplo, si tiene que girar y desplegar 100 copias de la misma carga de trabajo y sistema operativo, es mucho más eficiente y rentable utilizar contenedores que las máquinas virtuales tradicionales basadas en hipervisor.

Los centros de datos que exigen versatilidad e independencia óptima de las cargas de trabajo  permanecerán con Máquinas Virtuales basadas en hipervisor. Sin embargo, los dos enfoques no son mutuamente excluyentes. Ambos enfoques pueden coexistir para satisfacer las necesidades de computación de negocios específicas. La tecnología de contenedores, sin duda, vale la pena ser considerada por la empresa.

¿Cuál estrategia le parece mejor para su Organización?

Juego de Nubes: Se acerca un desenlace

Las cargas de trabajo "Nacido en La Nube" pudieron haber sido diseñadas para ser agnósticas de la plataforma, pero eso no significa que siempre será así ya que los "hiperescaladores" como Amazon Web Services y Microsoft Azure continúan agregando funcionalidades específicas y únicas a sus respectivos servicios.

En 2013 y 2014 discutíamos acerca del "Juego de servicios" y cómo, al igual que en la serie de fantasía épica de HBO "Juego de Tronos" que se ha desarrollado durante varias temporadas, han habido distintos capítulos en la evolución de La Nube del consumidor.

Para resumir: la evolución de La Nube del consumidor ha ido de la mano y se ha vinculado a los servicios que los principales actores de la industria (Apple, Google, Microsoft y Amazon) ofrecen para quien deciden alojar sus cargas de trabajo en ellos, creando diferenciadores entre sí.

El Primer  Capítulo de "Game of Services" fue sobre las plataformas de sistemas operativos móviles y que quedaría en pie. Ahora sabemos quienes ganaron: Apple y Google.

El Segundo Capítulo versaba sobre los servicios en sí mismos, lo que "Las Casas" tenían que ofrecer en términos de almacenamiento en La Nube, aplicaciones, mensajería, contenido (música/video/libros) y cómo estos continuarían evolucionando.

El Tercer Capítulo trata acerca de la contienda de las Interfaces de Programación para las Aplicaciones (API), hacia los servicios en La Nube pública de los consumidores. Google y Facebook en su mayor parte, siguen siendo Las Nubes para consumidores más importantes y el acceso a esas API, sigue siendo un objetivo en constante movimiento.

¿Cuál es el cuarto capítulo? La evolución de la empresa/nube comercial. Estamos hablando de "hiperscaladores" de La Nube pública como Amazon Web Services, Microsoft Azure, Google Cloud Platform y en menor medida, IBM Cloud.

Hasta ahora, las cargas de trabajo de La Nube empresarial se clasifican como IaaS (Infraestructura como servicio), PaaS (Plataforma como servicio), SaaS (Software como servicio) o una mezcla de los tres. Las cargas de trabajo que están diseñadas para ejecutarse en La Nube desde el primer día a menudo se denominan cargas de trabajo "Nacidas en La Nube", mientras que las cargas de trabajo cliente-servidor tradicionales (segunda plataforma) que se originan en los centros de datos locales que se trasladan a La Nube, son cargas de trabajo migradas a La Nube.

Mientras que cuando combinamos La Nube Pública y la Privada, dividiendo así entre La Nube y las instalaciones locales, tenemos lo que se llama una Arquitectura de Nube Híbrida.

En su mayor parte, Las Nubes empresariales/comerciales han alojado servicios que podrían considerarse productos básicos o intercambiables. Las máquinas virtuales, el almacenamiento y las redes son servicios fundamentales de IaaS que en esencia son efectivamente los mismos entre los principales "hiperescaladores", así como entre los principales actores a los que se ha valorado igual, y que ahora van en carrera descendente.

Los contenedores que se ejecutan en estándares de empaquetado de aplicaciones de código abierto como Docker, y que usan sistemas de orquestación como Kubernetes, son la próxima generación de cómputo y eso también se está convirtiendo en un producto básico, además de que han resultado ser más baratos y mucho más fáciles de escalar que las máquinas virtuales. Si tiene una aplicación basada en Docker en una Nube Pública, es bastante trivial portarla a otra Nube Pública con servicios de hosting de "contenedorización" similares.

Los "hiperscaladores" pueden intentar diferenciarse en rendimiento y algunas otras cosas, pero a un nivel fundamental, IaaS es IaaS y los Contenedores son Contenedores. Ya sea que lo ejecute en AWS, Azure o Google Cloud.

SaaS y PaaS es donde realmente ocurre la diferenciación en La Nube comercial. Para una empresa como Microsoft, sus SaaS como Office 365, PowerBI, Dynamics, SharePoint, Teams y Skype for Business son cosas que lo diferencian del resto de la industria. Estas son plataformas de aplicaciones que ya tienen una importante cuota de mercado con las instalaciones locales, por lo que mover a los clientes a versiones alojadas de estas basadas en La Nube no representa un gran reto. Podemos decir pues que SaaS es un negocio natural para la transición desde sus instalaciones heredadas.

Estas cargas de trabajo ya son muy rígidas porque están vinculadas al mecanismo de autenticación de Active Directory de Microsoft, que es una tecnología fundamental para los entornos basados ​​en Microsoft. Estos clientes ya están bloqueados, pero no es como si estuvieran tratando de salir de estas plataformas de aplicaciones de todos modos, porque realmente no hay muchas alternativas buenas para ellos.

Platform as a Service tiene todo tipo de servicios de aplicaciones terminadas, como bases de datos alojadas y sistemas de aprendizaje automático que se facturan de forma transaccional. Estos sistemas, cuando se combinan con PaaS basado en contenedores, permiten a los clientes empresariales construir sistemas altamente escalables que de otro modo serían de costo prohibitivo implementar en IaaS y se pueden aprovisionar a pedido.

Hasta ahora, muchos de estos sistemas se han construido en plataformas de código abierto como Hadoop o MongoDB. Pero ahora estamos empezando a ver a los proveedores de Nube de hiperescala, construir sus propios servicios back-end altamente escalables que son compatibles pero que no son lo mismo que sus homólogos de código abierto.

Un ejemplo de ello es DocumentDB, un servicio de base de datos alojado que es compatible con la API de MongoDB pero que no utiliza ningún código real de MongoDB, que Amazon lanzó esta semana en AWS.

Por ahora uno puede crear aplicaciones en AWS, utilizando IaaS y sistemas basados ​​en contenedor y respaldarlas en DocumentDB, para que en una fecha posterior devolverlas a las instalaciones locales o incluso a otra Nube de hiperescala que compita, como Microsoft Azure o Google. Esto es Plataforma en la Nube, pero este puede no ser el caso por tiempo indefinido.

Hoy en día muchos de estos servicios alojados usan APIs que son compatibles con sus contrapartes de código abierto. Por lo tanto, el código es portátil; no está atascado en ese proveedor de Nube.

Esto no es completamente diferente de, por ejemplo, el problema clásico de la transferencia de una base de datos basada en SQL a otra, siempre que estén codificadas según las especificaciones ANSI SQL. En ese nivel de compatibilidad, no importa si una base de datos comenzó en Oracle, luego puede moverla a IBM DB2 o incluso a Microsoft SQL Server.

Pero a medida que estos servicios se convierten en productos básicos, como lo hicieron IaaS para el cómputo y el almacenamiento. Los proveedores de La Nube agregarán sus propias mejoras de características que inevitablemente, se diferenciarán de las contrapartes de código abierto. Es bien sabido que a los desarrolladores de software les encanta aprovechar las nuevas funciones, especialmente si pueden aumentar el rendimiento, mejorar la escalabilidad y ahorrar dinero en costos transaccionales o computacionales.

Esa es una de las razones por las que se están moviendo a PaaS, en "contenedorización" y microservicios en La Nube. En primer lugar, para crear verdaderas aplicaciones "Nacido en La Nube". Además pueden centrarse en ejecutar una plataforma de aplicaciones y su código en lugar de preocuparse por la infraestructura subyacente. IaaS es realmente solo un paso intermedio hacia La Nube para transformar las cargas de trabajo, ya que aún debe preocuparse por mantener al sistema operativo.

Pero como hemos observado a menudo con los clientes, si se termina poniendo lógica empresarial en procedimientos almacenados y activadores en una plataforma de base de datos, en particular para aprovechar las optimizaciones de rendimiento, puede terminar teniendo verdaderos dolores de cabeza de compatibilidad.

En esos casos ya no es tan fácil pasar, por ejemplo, de Oracle a IBM DB2. Podría terminar costándonos una gran cantidad de tiempo de desarrollo de software (y dinero) para mover esa lógica de negocios fuera de la base de datos, de modo que pueda trasladarse de una plataforma a otra.

A modo de ejemplo, nos viene a la mente un cliente bancario de IBM tenía 800 procedimientos almacenados y activadores en Oracle, lo que les habría costado millones eliminarlos y mover la lógica a middleware en J2EE. Aunque DB2 hubiera sido más barato que Oracle en términos de licencias, los costos de desarrollo de software hubieran sido mucho más caros. Terminaron simplemente apegándose a Oracle, pero cambiándolo a un sistema operativo y plataforma de hardware diferentes (IBM AIX y POWER) para obtener el rendimiento que necesitaban. Al final se vieron atados y encerrados a esa base de datos.

Podríamos ver muy bien que esto suceda con Nubes de "hiperescala". Claro que DocumentDB es compatible con MongoDB ahora. Pero, ¿quién puede decir que dentro de cinco años las API serán idénticas? Y DocumentDB es solo un servicio en La Nube. Una aplicación altamente escalable, nacida en La Nube podría estar diseñada para aprovechar una docena o más de servicios de Nube que son específicos de ese proveedor de Nube. Todo lo cual está en constante evolución y obteniendo nuevos conjuntos de características.

¿Cuántos servicios tiene, digamos, Microsoft Azure en su cartera? Dejamos de contar hace mucho tiempo. Claro, muchos de ellos utilizan estándares de código abierto, pero ¿cuántos de ellos no lo hacen? ¿Por cuánto tiempo estos servicios compatibles con Open Source permanecerán completamente de esa manera? A medida que AWS, Microsoft y Google Cloud e IBM se vuelven mucho más competitivos entre sí, es probable que no lo sean.

Cuanto más se pierda el control de la infraestructura, mueva su enfoque en ejecutar estrictamente el código de su aplicación y tenga que depender de una plataforma de alojamiento, mayor será la posibilidad de que esa plataforma se vuelva pegajosa, que es precisamente lo que desean los proveedores de "hiperescala" como AWS y Microsoft.

Ellos quieren que te quedes. Quieren que continúes comprando ciclos y transacciones. No quieren que te muevas de sus Nubes. Los sistemas SaaS como Office 365, Workday y Salesforce son, obviamente, de lo mas pegajosos.

Esto realmente no es diferente de tener plataformas de software locales, que son propietarias y utilizan código que no se puede trasladar fácilmente a otra plataforma. La diferencia es que, en lugar de otorgar licencias a estas plataformas, usted está alquilando tiempo en ellas, lo que prefieren los contadores en su organización, porque es un gasto operativo (OPEX) y no un gasto de capital (CAPEX).

Por lo tanto, ciertamente puede diseñar sistemas basados ​​en La Nube que sean bastante autónomos y portátiles. Pero puede que no sea financieramente viable hacerlo a largo plazo. Los servicios en La Nube terminados serán más económicos de lo que puede alojar en máquinas virtuales de IaaS o incluso en contenedores. Con PaaS, la compensación será en última instancia el rendimiento, las características y el costo en comparación con la portabilidad.

¿Es inevitable el bloqueo de La Nube, a medida que dependemos más de los servicios en La Nube terminados? Usted tiene la respuesta y la última palabra.

Hiperconvergencia holística con Nutanix (Parte III)

Como mencionamos en la entradas anteriores como: "Hiperconvergencia holística con Nutanix (Parte I)" e Hiperconvergencia holística con Nutanix (Parte II), Nutanix ofrece la solución hiperconvergente más popular de la industria. Convergencia nativa de cómputo y almacenamiento en un dispositivo listo para usar, que se puede implementar en minutos para ejecutar cualquier aplicación de forma inmediata.

También dijimos que la solución Nutanix ofrece potentes capacidades de virtualización, incluidas las operaciones centrales de Máquinas Virtuales (VMs por sus siglas en inglés), migración en vivo, alta disponibilidad de Máquinas Virtuales y administración de redes virtuales, como características totalmente integradas de la infraestructura en lugar de productos independientes que requieren una implementación y administración separadas.

Ahora abordaremos temas como:

• Respaldo convergente y Recuperación de desastres
• APIs para Respaldo y Recuperación
• Anaíticos
• Desempeño
• Soporte para Unidades de Procesamiento Gráfico (GPU)
• Seguridad.

Copia de seguridad convergente y recuperación de desastres

Los servicios convergentes de copia de seguridad y recuperación de desastres de Acropolis App Mobility Fabric (AMF) protegen sus clústers. Los clústeres de Nutanix que ejecutan cualquier hipervisor tienen acceso a estas funciones para ofrecer protección a las Máquinas Virtuales, tanto de forma local como remota para casos de uso que van desde la protección básica de archivos (Respaldo y Recuperación), hasta la recuperación de una interrupción completa del sitio (Recuperación de Desastres).

API de respaldo

Para complementar la copia de seguridad integrada que proporciona Enterprise Cloud Platform, AHV también publica un amplio conjunto de APIs para admitir proveedores externos de copias de seguridad. Las APIs de copia de seguridad de Acropolis Hypervisor utilizan el seguimiento de región modificado, para permitir que los proveedores de copia de seguridad hagan una copia de seguridad solo de los datos que han cambiado, desde la última tarea de copia de seguridad para cada Máquina Virtual en lo individual. La tecnología de Seguimiento de Regiones Modificadas (Changed Region Tracking) también permite que las tareas de copia de seguridad omitan ceros de lectura, reduciendo aún más los tiempos de copia de seguridad y el ancho de banda consumido.

Las APIs de respaldo de Nutanix permiten a los proveedores de respaldo, que implementen integración para realizar copias de seguridad completas, incrementales y diferenciales. El Seguimiento de Regiones Modificadas (Changed Region Tracking) siempre está activo en los clústeres de Acropolis Hipervisor, no requiriendo habilitación para cada Máquina Virtual. Las copias de seguridad pueden ser coherentes o consistentes con la aplicación.

Analítica

Nutanix Prism ofrece análisis en profundidad para cada elemento en la pila de infraestructura incluido Hardware, Almacenamiento y Máquinas Virtuales. Los administradores pueden usar Vistas por Elemento, para monitorear estos componentes de la pila de infraestructura, pudiendo usar la vista de Análisis para obtener una evaluación integrada de los recursos del clúster o profundizar en métricas específicas en un elemento dado.

Prism pone a disposición datos detallados de VM, agrupándolos en las siguientes categorías:

• Rendimiento de Máquinas Virtuales: varios gráficos con informes de CPU y de almacenamiento sobre el uso y el rendimiento de los recursos.
  
• Discos virtuales: puntos de datos detallados que se centran en tipos de E/S, medidas de E/S, origen de lectura, aciertos de caché, tamaños de "conjuntos de trabajo" y latencia en un nivel de disco virtual.
  
• VM NIC: resumen de configuración de tarjetas de red virtuales (vNIC) para una Máquina Virtual.
  
• Instantáneas de Máquina Virtual: una lista de todas las instantáneas de una Máquina Virtual con la capacidad de clonar o restaurar desde la instantánea o eliminar la instantánea.
  
• Tareas de Máquina Virtual: una lista basada en el tiempo de todas las acciones operacionales realizadas contra la máquina virtual seleccionada. Los detalles incluyen resumen de tareas, porcentaje completado, hora de inicio, duración y estado.
  
• Consola: los administradores pueden abrir una sesión de consola emergente o una sesión de consola en línea para una Máquina Virtual.

La pestaña Almacenamiento proporciona una vista directa de Acropolis Distributed File System (DSF) que se ejecuta en un clúster de Acropolis Hypervisor. Los administradores pueden ver las configuraciones de almacenamiento detalladas, el uso de la capacidad a lo largo del tiempo, la eficiencia del espacio y el rendimiento, así como una lista de alertas y eventos relacionados con el almacenamiento.

La pestaña Hardware le brinda una vista directa de los bloques y nodos de Nutanix que conforman un clúster de Acropolis. Estos informes están disponibles tanto en un diagrama como en un formato de tabla para un fácil consumo.

La pestaña Análisis de Prism les brinda a los administradores las herramientas que necesitan para explorar y comprender lo que está sucediendo en sus clústers rápidamente, e identificar los pasos para la corrección según sea necesario. Puede crear diagramas interactivos personalizados usando cientos de métricas disponibles para elementos como hosts, discos, pools de almacenamiento, contenedores, Máquinas Virtuales, dominios de protección, sitios remotos, enlaces de replicación, clusters y discos virtuales, para correlacionar tendencias en los gráficos con alertas y eventos en el sistema.

También puede elegir medidas y elementos específicos y establecer un marco de tiempo deseado al generar informes, para que pueda centrarse con precisión en los datos que está buscando.

Desempeño

La plataforma Nutanix optimiza el rendimiento en los niveles de Acropolis Operating System (AOS) y el hipervisor. Los CVM que representan los planos de control y datos contienen las optimizaciones de AOS que benefician a todos los hipervisores admitidos. Construido sobre una base de KVM de fuente abierta, una cantidad significativa de innovación añadida hace que AHV sea únicamente una oferta de Nutanix. Las siguientes secciones describen algunas de las innovaciones en AHV que se centran en el rendimiento.

AHV Turbo

AHV Turbo representa avances significativos en la ruta de datos dentro de Acropolis Hypervisor, sobre la base del código fuente de Kernel-based Virtual Machine (KVM). Acropolis Hypervisor Turbo no es una función que requiera que lo habilite o gire perillas, sino que produce beneficios inmediatos e instantáneos.

En el código Kernel-based Virtual Machine central, todas las Entradas/Salidas de una Máquina Virtual específica, fluyen a través del monitor de Máquinas Virtuales alojado, Quick Emulator (QEMU). Si bien esta arquitectura puede lograr un rendimiento impresionante, algunas cargas de trabajo de aplicaciones requieren capacidades aún mayores. AHV Turbo proporciona una nueva ruta de Entrada/Salida que elude el Quick Emulator (QEMU) y las solicitudes de Entrada/Salida de almacenamiento de servicios. Este enfoque reduce el uso del CPU y aumenta la cantidad de Entradas/Salidas de almacenamiento disponible para las Máquinas Virtuales.

Al usar el Quick Emulator (QEMU), todas las Entradas/Salidas viajan a través de una única fila o cola, que es otro problema que puede afectar el rendimiento. El nuevo diseño de AHV Turbo presenta un enfoque multi-cola para permitir que los datos fluyan desde una máquina virtual hasta el almacenamiento, lo que da como resultado una capacidad de Entrada/Salida mucho mayor. Las colas de almacenamiento se escalan automáticamente para coincidir con el número de vCPU configuradas para una máquina virtual determinada, lo que hace posible un rendimiento aún mayor a medida que aumenta la carga de trabajo.

Si bien estas mejoras demuestran beneficios inmediatos, también preparan a Acropolis Hypervisor para tecnologías futuras como Non Volatile Memory Express (NVMe) y avances de memoria persistente que ofrecen capacidades de Entrada/Salida dramáticamente aumentadas con latencias más bajas.

vNUMA

Las arquitecturas de servidor Intel modernas asignan bancos de memoria a zócalos de CPU específicos. En este diseño, uno de los bancos de memoria en un servidor es local para cada CPU, por lo que se obtiene un nivel más alto del rendimiento, al acceder a la memoria localmente en lugar de acceder a ésta remotamente en un banco de memoria diferente. 

Cada CPU su memoria correspondiente son lo que se llama un nodo de "Acceso No Uniforme a la Memoria" (Non-Uniform Memory Access o NUMA). vNUMA es una función que permite que la arquitectura de una Máquina Virtual refleje la arquitectura NUMA del host físico subyacente.

vNUMA no es aplicable a la mayoría de las cargas de trabajo, pero puede ser muy conveniente para Máquinas Virtuales muy grandes, que están configuradas con más Procesadores Virtuales en comparación con los núcleos físicos disponibles en un solo "socket" de CPU.

En estos escenarios, es muy recomendable definir nodos vNUMA para usar el acceso a la memoria local de manera eficiente, para que cada CPU logre los mejores resultados de rendimiento.

RDMA

El Acceso Remoto Directo a Memoria (Remote Direct Memory Access o RDMA) permite que un nodo "escriba" directamente y de forma remota, en la memoria de un nodo remoto, permitiendo que una Máquina Virtual que se ejecuta en el espacio de usuario, acceda directamente a una Tarjeta de Red (Network Interface Card o NIC). 

Este enfoque evita que tanto al prodocolo TCP como al Kernel, que puedan tener una sobrecarga (overhead), lo que resulta en ahorro de CPU y mejoras de rendimiento. En este momento, la compatibilidad con Acropolis Operating System (AOS) y RDMA, está reservada para comunicaciones entre Máquinas Virtuales de Control (CVM) y utiliza el protocolo estándar RDMA sobre Ethernet Convergente Versión 2 (RDMA over Converged Ethernet Version 2 o RoCEv2) en sistemas configurados con NIC compatibles con RoCE conectadas a switches configurados correctamente, con compatibilidad de Puente de Centro de Datos (Datacenter Bridge o DCB).

El soporte de RDMA, la ubicación de datos y Acropolis Hypervisor Turbo, no solo son innovaciones de rendimiento importantes para las generaciones actuales, sino que posicionan al Acropolis Hypervisor y la plataforma Nutanix de forma única, para aprovechar al máximo las tecnologías flash y de memoria, que avanzan rápidamente sin requerir actualizaciones de red.

Soporte para Unidades de Procesamiento Gráfico o GPU

Una Unidad de Procesamiento Gráficos (GPU), es el hardware o software que muestra el contenido gráfico a los usuarios finales. En computadoras portátiles y de escritorio, las GPU son una tarjeta física o se integran directamente en el hardware de la CPU, mientras que las funciones de la GPU en el mundo virtualizado han sido históricamente impulsadas por software y han consumido ciclos de CPU adicionales. Con los sistemas operativos y las aplicaciones modernas, así como con las herramientas 3D, cada vez más organizaciones se necesitan GPU de hardware en el mundo virtualizado.

Puede instalar tarjetas de GPU físicas en nodos calificados y presentarlas a Máquinas Virtuales alojadas en estos, a través del modo Passthrough o vGPU.

Modo Passthrough

Las tarjetas GPU instaladas en los nodos del servidor para casos de uso virtualizado, suelen combinar varias GPU en una sola tarjeta física con conexión PCI a la tarjeta madre del nodo físico. Con el "paso a través" (Passthrough) hacia la o las GPU, Acropolis Hypervisor puede conectar una GPU a una Máquina Virtual, permitiendo que ésta posea ese dispositivo físico en una relación 1:1. 

La configuración de nodos con una o más tarjetas GPU que conectan múltiples GPU a un número mayor de Máquinas Virtuales, le permite consolidar aplicaciones y usuarios en cada nodo. Actualmente AHV es compatible con NVIDIA Grid Cards para el paso a través de GPU; consulte la documentación del producto para la lista actual de dispositivos compatibles.

Con el paso a través, también puede usar GPU para delgar o reasignar cargas de trabajo computacionales. Esto es un escenario más especializada que los casos típicos de uso gráfico. 

Hay escenarios en donde se asignan una o más GPU para que una Máquina Virtual para el procesamiento. Acropolis Hypervisor le permite asignar hasta 16 GPU a una sola Máquina Virtual, mientras que los hipervisores de la competencia permiten asignar un solo GPU por Máquina Virtual.

vGPU

Si bien el método Passthrough funciona bien para un número menor de máquinas virtuales que requieren grandes cantidades de recursos GPU, las cargas de trabajo como Virtual Desktop Infrastructure (VDI) a menudo tienen requisitos diferentes. Las cargas de trabajo de VDI suelen tener un número mucho mayor de máquinas virtuales, que necesitan cantidades variables de recursos de GPU según el uso y el tipo de aplicación.

Las tarjetas GPU NVIDIA Grid de hoy en día contienen de 1 a 4 GPU en cada tarjeta PCI física, y cada host físico puede admitir la instalación de una o dos tarjetas. Esta capacidad permite que hasta 8 GPU en cada nodo cumplan con los requisitos de densidad, generados por las cargas de trabajo de VDI. Para una flexibilidad máxima, el modo vGPU le permite dividir cada GPU en segmentos más pequeños que puede asignar virtualmente a las máquinas virtuales.

Los "Perfiles vGPU" le permiten asignar diferentes niveles de recursos a las máquinas virtuales, por lo que cada uno de ellas puede utilizar un número máximo definido de pantallas y distinta calidad de resolución. Trabajar dentro de estos parámetros le permite elegir el "Perfil GPU" correcto, para cumplir con los requisitos de su aplicación, conociendo el tipo y número de tarjetas GPU en su implementación, podrá describir con precisión la densidad máxima posible por nodo.

Acropolis Hypervisor actualmente admite tarjetas NVIDIA Grid para vGPU. Recomendamos nuevamente consular la documentación del producto para la lista actual de dispositivos compatibles.

Seguridad

Nutanix ha adoptado un enfoque holístico para la seguridad de la infraestructura. La pila de infraestructura totalmente integrada, elimina los riesgos de seguridad asociados con las soluciones heredadas que involucran a muchos proveedores, que vienen con una visión estrecha y fragmentada de la seguridad.

Por ejemplo, Nutanix diseñó Acropolis Hypervisor para que sea un componente integral de la pila de infraestructura convergente, en lugar de un hipervisor de propósito general. En consecuencia, muchos de los servicios que la solución de Acropolis hace innecesarios sean desactivados para reducir el área de superficie de seguridad.

Ciclo de vida en el desarrollo de la seguridad

Para mantener una seguridad ágil y completa, Nutanix ha desarrollado su propio Ciclo de vida de desarrollo de seguridad (SecDL), que aborda la seguridad en cada paso del proceso de desarrollo en lugar de aplicarlo al final como una idea de último momento.

SecDL integra las funciones de seguridad en el proceso de desarrollo de software, incluidas las pruebas de seguridad automatizadas durante el desarrollo y el modelado de amenazas para evaluar y mitigar el riesgo del cliente a partir de los cambios de código.

SecDL convierte a la seguridad en un ciudadano de primera clase que impulsa las mejores prácticas dentro de Nutanix y para nuestros clientes, brindando tanto defensa en profundidad como una postura "endurecida por defecto" para las versiones.

Tras haber tocado todos y cada uno de los temes referentes a la Plataforma de Nube Empresarial NUTANIX, estamos seguros que queda claro los inmensos alcances de esta que es en nuestra opinión, la Plataforma para Hiperconvergencia número UNO.

¿Su organización ya cuenta con alguna Plataforma de Nube Empresarial? ¿Ya tiene una Plataforma para Hiperconvergencia?

Hiperconvergencia holística con Nutanix (Parte II)

Como mencionamos en la entrada anterior: "Hiperconvergencia holística con Nutanix (Parte I)", Nutanix ofrece la solución hiperconvergente más popular de la industria. Convergencia nativa de cómputo y almacenamiento en un dispositivo listo para usar, que se puede implementar en minutos para ejecutar cualquier aplicación de forma inmediata.

También mencionamos que la solución Nutanix ofrece potentes capacidades de virtualización, incluidas las operaciones centrales de Máquinas Virtuales (VMs por sus siglas en inglés), migración en vivo, alta disponibilidad de Máquinas Virtuales y administración de redes virtuales, como características totalmente integradas de la infraestructura en lugar de productos independientes que requieren una implementación y administración separadas.


En esta entrada abordaremos el tema: 

Capacidades de gestión integrada

Nutanix prioriza la simplificación de la administración y las operaciones de la infraestructura. La plataforma Nutanix converge de forma nativa en lo que respecta a cómputo (procesador, memoria y redes), almacenamiento y virtualización en un producto listo para usar que se puede administrar desde un solo Panel de Control (Dashboard): Nutanix Prism. 

Prism ofrece capacidades integradas para la gestión de clústeres y la gestión de Máquinas Virtuales que están disponibles a través de la Interfaz Gráfica de Usuario (GUI) Prism, la Interfaz de Línea de Comando (CLI), Windows PowerShell y la REpresentational State Transfer-Application Programable Interface (REST-API) de Acropolis.

Administración del Cluster Nutanix

La administración de clusters en Acropolis Hypervisor se enfoca en la creación, actualización, eliminación y monitoreo de los recursos del clúster. Estos recursos incluyen nodos (que aportan procesador y memoria), almacenamiento y redes.

Perfiles de nodos (host)

Prism proporciona una ubicación central para que los administradores actualicen la configuración de sus nodos, en lo que respecta a las redes virtuales y la alta disponibilidad en todos los nodos de un clúster con Acropolis Hypervisor. Controlar la configuración en a nivel de clúster elimina la necesidad de verificaciones manuales de cumplimiento, reduciendo el riesgo de tener un clúster que no está configurado de manera uniforme.

Configuración de almacenamiento


Nutanix Acropolis se basa en la Capa de Almacenamiento Distribuido (Distributed Storage Fabric o DSF) independiente del hipervisor, para entregar servicios de datos como el aprovisionamiento de almacenamiento, instantáneas para respaldo y recuperación, clones y protección de datos para Máquinas Virtuales directamente, en lugar de usar la pila de almacenamiento del hipervisor. En cada nodo de Acropolis Hypervisor, un servicio de redireccionamiento de almacenamiento con es estándar iSCSI establece una ruta de almacenamiento altamente flexible, desde cada Máquina Virtual hasta el almacenamiento en el clúster de Nutanix.

Redes virtuales

Acropolis Hypervisor aprovecha a Open vSwitch (OVS), para todo lo que respecta a las redes de Máquinas Virtuales. Al crear un nuevo clúster con AHV, las rutas de acceso a la red de la Máquina Virtual de Control (CVM por sus siglas en inglés) son creadas automáticamente.


Los administradores pueden crear fácilmente nuevas redes Capa 2 (L2) respaldadas por Redes Virtuales (VLANs) a través de Prism. Una vez que haya creado una red, puede asignar la red para las Máquinas Virtuales ya existentes y de nueva creación.

Junto con la optimización de la creación de la red para Máquinas Virtuales, Acropolis puede proporcionar administración de direcciones mediante Direct Host Connection Protocol (DHCP), independientes para cada red que se crea. Esta funcionalidad permite a los administradores configurar grupos de direcciones para cada red que pueden asignar automáticamente a las máquinas virtuales.

Actualizaciones continuas

Nutanix ofrece un proceso de actualización "a un clic" increíblemente simple y confiable, para todo el software dentro de la plataforma Nutanix. Esta característica incluye actualizaciones para el Sistema Operativo Acropolis (AOS), el hipervisor Acropolis Hypervisor (AHV), firmware y la herramienta Nutanix Cluster Check (NCC).


Las actualizaciones no son disruptivas y permiten que el clúster se ejecute continuamente mientras que los nodos se actualizan de forma continua en segundo plano, garantizando así el funcionamiento del clúster siempre activo, durante el mantenimiento del software. Nutanix califica las actualizaciones de firmware de los fabricantes de unidades de disco duro (HDD) o de estado sólido (SSD) en el clúster, poniéndolas a disposición mediante el mismo proceso de actualización.

Modo de mantenimiento de los nodos


Los administradores pueden colocar nodos Acropolis Hypervisor en modo de mantenimiento, durante las actualizaciones y las operaciones relacionadas con el mantenimiento físico de los nodos. El modo de mantenimiento en vivo, migra todas las máquinas virtuales que se ejecutan en el nodo a intervenir a otros nodos dentro del clúster del Acropolis Hypervisor, pudiéndose cerrar de manera segura la Máquina Virtual de Control (CVM) si esto fuera necesario. Una vez que el proceso de mantenimiento ha completado todos los pasos para el nodo, devuelve el CVM al servicio y se sincroniza con otros CVM en el clúster. El modo de mantenimiento permite una suspensión elegante de los nodos para el mantenimiento rutinario del clúster.

Escalabilidad

La arquitectura de escalabilidad horizontal de la solución Nutanix, permite escalar de forma incremental y predecible la capacidad y el rendimiento en un clúster de Nutanix que ejecuta cualquier hipervisor, incluido Acropolis Hypervisor. Los administradores pueden comenzar con tan solo tres nodos y escalar sin límites.


El sistema descubre automáticamente nuevos nodos y los pone a disposición para su uso. La expansión de clusters es tan simple como seleccionar los nodos descubiertos que desea agregar y proporcionar detalles de configuración de red. A través de Prism, los administradores pueden crear imágenes o actualizar nuevos nodos para que coincidan con la versión de Acropolis Hypervisor de sus nodos preexistentes, permitiendo así la integración perfecta de nodos, sin importar qué versión se instaló originalmente.

Gestión de las Máquinas Virtuales

La gestión de Máquinas Virtuales en AHV se centra en la creación, las actualizaciones, la eliminación, la protección de datos, la supervisión de máquinas virtuales y sus recursos. Estos servicios y características del clúster están disponibles a través de la interfaz Prism, una capa de administración distribuida que está disponible en a través de la Máquina Virtual de Control (CVM) en cada host de AHV.

Gestión de imágenes

El servicio de administración de imágenes dentro de Acropolis Hypervisor es un repositorio centralizado que brinda acceso a medios virtuales e imágenes de disco, así como la capacidad de importar estos elementos desde fuentes externas. Permite almacenar máquinas virtuales como templates, plantillas o imágenes maestras, que luego puede usar para crear nuevas máquinas virtuales rápidamente a partir de una buena imagen base conocida.

El servicio de administración de imágenes puede almacenar los archivos del disco virtual, que se utilizan para crear máquinas virtuales o medios de instalación del sistema operativo en pleno funcionamiento como un archivo ".iso", que puede montar para proporcionar una fuente para la instalación del sistema operativo.


Incorporado en Prism, el servicio de imágenes puede importar y convertir formatos de discos virtuales existentes, incluyendo archivos ".raw", ".vhd", ".vmdk", ".vdi" y ".qcow2". La configuración de hardware virtual anterior no restringe un disco virtual importado, lo que permite a los administradores la flexibilidad de configurar por completo la CPU, la memoria, los discos virtuales y la configuración de red en el momento del aprovisionamiento de las Máquinas Virtuales.

Acropolis Dynamic Scheduling

Acropolis Dynamic Scheduling (ADS) es una función automática habilitada en cada grupo de Acropolis Hypervisor para evitar alta contención entre de los nodos del clúster. Acropolis Dynamic Scheduling supervisa continuamente el puntaje de datos de almacenamiento, memoria y CPU, para tomar decisiones de migración y colocación inicial para Máquinas Virtuales y volúmenes de los Acropolis Block Services (ABS). 

Comenzando con los datos estadísticos existentes generados por el clúster, Acropolis Dynamic Scheduling vigila las anomalías, respeta los controles de afinidad y solo toma decisiones de movimiento para evitar los puntos conflictivos. Mediante el aprendizaje automático, Acropolis Dynamic Scheduling puede ajustar los umbrales de movimiento a lo largo del tiempo desde sus valores fijos iniciales, para lograr la mayor eficiencia sin sacrificar el rendimiento.

Acropolis Dynamic Scheduling rastrea la utilización de memoria y CPU de cada nodo individual. Cuando la asignación de CPU de un nodo supera su umbral (85% del CPU de la Máquina Virtual de Control), Nutanix migrará las Máquinas Virtuales o los volúmenes de Acropolis Block Services según sea necesario, para reequilibrar las cargas de trabajo.

Ubicación inteligente de Máquinas Virtuales

Cuando crea, restaura o recupera máquinas virtuales, Acropolis las asigna a un host Acropolis Hypervisor dentro del clúster según la recomendación del Acropolis Dynamic Scheduling. Este proceso de ubicación de Máquinas Virtuales también tiene en cuenta la configuración de Alta Disponibilidad (High Availability o HA) del clúster de Acropolis Hypervisor, por lo que no infringe ningúna conmutación por error (failover) o reservas de segmentos del host. Explicamos estos constructos de Alta Disponibilidad más adelante en la sección de alta disponibilidad a continuación.

Afinidad y Antiafinidad

Los controles de afinidad proporcionan la capacidad de gobernar el dónde se ejecutan las Máquinas Virtuales. AHV tiene dos tipos de controles de afinidad:

1. La afinidad Máquina Virtual-Nodo que vincula estrictamente una Máquina Virtual un nodo o grupo de nodos, por lo que la Máquina Virtual solo se ejecuta en ese nodo individual o grupo de éstos. Afinidad es particularmente aplicable para casos de uso que involucran licencias de software o dispositivos virtuales. En tales casos, a menudo necesitaremos limitar el número de nodos en los que se puede ejecutar una aplicación o vincular un dispositivo virtual a un solo nodo.

2. Anti-afinidad le permite declarar que una lista determinada de Máquinas Virtuales, no debe ejecutarse en los mismos nodos. Anti-afinidad le brinda un mecanismo para permitir que las Máquinas Virtuales que ejecutan una aplicación distribuida o las Máquinas Virtuales en clúster, se ejecuten en diferentes nodos, lo que aumenta la disponibilidad y la flexibilidad de la aplicación. Para preferir la disponibilidad de Máquinas Virtuales sobre la separación de éstas en el sistema, se anulará este tipo de regla cuando un clúster se vuelve limitado.

Migración en vivo

La migración en vivo permite que el sistema mueva Máquinas Virtuales de un nodo Acropolis a otro, mientras la Máquina Virtual está encendida. Ya sea que el movimiento se inicie manualmente o mediante un proceso automático. La migración en vivo también puede ocurrir cuando un nodo se coloca en modo de mantenimiento, evacuando todas las máquinas virtuales que se ejecutan en el nodo.





Migración entre Hipervisores

Acropolis Application Mobility Fabric (AMF) simplifica el proceso de migración de máquinas virtuales existentes, entre un clúster con hipervisor ESXi y un clúster con hipervisor Acropolis Hypervisor, con capacidades de protección de datos incorporadas. Puede crear uno o más dominios de protección en el clúster de origen y establecer el clúster de Acropolis Hypervisor como el clúster remoto de destino. A continuación, se crea una instantánea de las máquinas virtuales en el clúster origen ESXi repitiéndolas en el clúster destino Acropolis Hypervisor, donde puede restaurarlas y ponerlas en línea como cualquier máquinas virtual Acropolis Hypervisor.

Alta disponibilidad automatizada

Acropolis ofrece Alta Disponibilidad de Máquinas Virtuales (VMHA) para garantizar la disponibilidad de éstas en caso de interrupción de sólo un nodo o de todo un bloque. Si un nodo falla, las máquinas virtuales que se ejecutan previamente en ese nodo reinician en nodos saludables en todo el clúster. Hay múltiples opciones de configuración de HA disponibles para tener en cuenta diferentes escenarios de clúster.

1. De forma predeterminada, todos los clusters de Acropolis proporcionan Alta Disponibilidad basada en el mejor esfuerzo, incluso cuando el clúster no está configurado para Alta Disponibilidad. La estrategia del mejor esfuerzo funciona sin reservar ningún recurso. El control de admisión no se aplica, por lo que es posible que no haya suficiente capacidad disponible para iniciar todas las máquinas virtuales desde el nodo fallido.

2. También puede configurar un clúster de Acropolis para Alta Disponibilidad con la reserva de recursos, para garantizar que los recursos necesarios para reiniciar las máquinas virtuales siempre estén disponibles. Acropolis ofrece dos modos de reserva de recursos: reservas por nodo y reservas por segmentos. Los clústeres con configuraciones de nodos uniformes (por ejemplo, la misma cantidad de RAM en cada nodo) utilizan la reserva por nodo, mientras que los clústeres con configuraciones heterogéneas usan la reserva por segmentos.

Reserva por nodo

Este método reserva un nodo completo para la protección contra fallas. Acropolis selecciona el nodo menos utilizado en el clúster como nodo de reserva, y todas las máquinas virtuales de ese nodo se migran a otros nodos en el clúster para que la capacidad total del nodo de reserva esté disponible para la migración. Prism determina la cantidad de nodos de conmutación por falla necesarios, para que coincida con el número de fallas que el clúster tolerará para el factor de replicación configurado.

Reserva por segmentos

Este método divide el clúster en segmentos de tamaño fijo de CPU y memoria. Cada segmento corresponde a la Máquina Virtual más grande que se garantiza que se reiniciará después de una falla en el nodo. El programador de actividades del clúster, también teniendo en cuenta la cantidad de fallas del nodo que se pueden tolerar, implementa el control de admisión para garantizar que haya suficientes recursos reservados, para reiniciar las máquinas virtuales ante la falla de cualquier nodo en el clúster.

La Máquina Virtual de Control Principal o Master del Clúster Acropolis, reiniciará las Máquinas Virtuales en los nodos saludables. La Acropolis Master realiza entonces un seguimiento del estado del nodo supervisando las conexiones a la Biblioteca de la API para Virtualización "libvirt", en todos los nodos del clúster. Si el Acropolis Master se particiona, se aísla o falla, la parte saludable del clúster elige un nuevo Acropolis Master. 

En posteriores entregas, hablaremos de Respaldo convergente y Recuperación de desastres, APIs para Respaldo y Recuperación, Anaíticos, Desempeño, Soporte para Unidades de Procesamiento Gráfico (GPU) y Seguridad.

Nuevamente entonces: ¿Cuál es la solución de Hiperconvergencia que ya está instalada y en ejecución, en su empresa u organización?