08 Jun 2020

Artículos

SAP HANA Certificado para Producción on Hyperconverged Infrastructure (HCI): Otro “Primero” para Nutanix AHV

( https://www.nutanix.com/blog/hypervisor-certified-production-sap-hana-hyperconverged-infrastructure-hci-another-first-nutanix-ahv )

La solución de SAP HANA nos propone el uso de servidores con capacidades de memoria tales que puedan albergar todos sus datos en Memoria. Esto es porque SAP HANA DB es una base diseñada para trabajar en memoria y gracias a esto poder responder en tiempos inigualables e incluir el uso concurrente de OLAP y OLTP. Es un salto enorme en el tipo de solución que puede ofrecer, sabiendo que la memoria puede ser accedida en tiempos del orden de los 100ns, y aún la más desafiante solución de almacenamiento puede responder en 100.000ns.

Las primeras implementaciones se realizaban en servidores físicos con sus discos internos en un ambiente denominado Appliance. Al tiempo apareció la opción de algo que SAP denominó TDI. El Appliance es una caja que ofrecer el fabricante con el soft precargado y que fue validado con SAP para cumplir cierta capacidad. Es la marca (Lenovo, Dell EMC, HPE, etc) quien configura y trabaja en conjunto con SAP y se conforma como una “caja” cerrada.

El ambiente TDI es aquel que se conforma con piezas soportadas, pero ahora no cerradas como el Appliance.

En la vida práctica, el Appliance resultaba técnicamente una forma simple y segura de iniciar un proyecto de SAP HANA, sin embargo, muchas veces inviable en costo.

Esto era porque los Appliance se armaban de Servidores High end, para poder cumplir con los requerimientos de memoria, y dado que la memoria acompaña al procesador (se requiere socket para poner Dimms de memoria) y en general en los SAPS resultantes eran varias veces mayor que el requerimiento.

La Arquitectura TDI nos da la posibilidad de modificar los procesadores, y diseñar la solución más acorde al requerimiento, y de ahí hacer viable un proyecto de SAP HANA.

Adicionalmente, todo cliente SAP requiere la existencia de un ambiente productivo, y al menos un ambiente de Desarrollo, de QA y de Test.

Ahí donde entra el beneficio de contar con la virtualización, y en especial la Hiperconvergencia.

A medida que necesitamos generar más ambientes, más beneficio de contar con el acceso del dato productivo para producir copias instantáneas.

Nosotros además vemos la oportunidad de hacer uso de Docker. De esta manera poder separar la instalación del dato e incluso integrarse en metodologías de DevOps en sintonía con otra aplicaciones de la empresa.

(ver: https://hub.docker.com/_/sap-hana-express-edition-incl-application-services )

En estos días estaremos dando una charla de SAP HANA sobre Nutanix.

De ser de interés puede ir a este link: https://shrinkit-it.com/eventos/

Read more

02 Jun 2020

Shrinkit IT

Como sabrán, en noviembre pasado Mirantis adquirió el negocio Docker Enterprise de Docker, Inc., y , como imaginarán desde entonces han estado, bastante ocupados! Los equipos de Mirantis y Docker han estado integrando sus esfuerzos y combinando lo mejor de ambos mundos para resultar en los mejores productos, servicios y soporte que se puede brindar a los clientes.

Seis meses después, Mirantis se enorgullece de anunciar el “General Avalaibility” de Docker Enterprise 3.1, con nuevas características que te permiten mejorar aún más tu juego de Kubernetes. Esta nueva versión incluye muchas características nuevas, entre las cuales:

  • K8s en Windows
  • Soporte de GPU
  • Istio Ingress
  • Nuevo “UCP Installer”
  • Upgrade a K8s 1.17

Hagamos un repaso de que significa todo esto.

(ver el anuncio en: https://www.mirantis.com/blog/announcing-docker-enterprise-3-1-general-availability/ )

Kubernetes on Windows

Desde el principio, Kubernetes ha sido un proyecto extremadamente centrado en Linux, lo cual es comprensible, ya que los contenedores evolucionaron a partir de desarrolladores de la comunidad Linux como cgroups. Pero, ¿en qué difiere esto para los desarrolladores de Windows, siendo que después de todo, Docker se ejecuta en Windows y hace posible ejecutar contenedores de Linux también (aunque usando virtualización).

En las últimas versiones de Kubernetes, la comunidad ha estado trabajando en la capacidad de ejecutar en Windows, y con Docker Enterprise 3.1, ahora se suma la capacidad de unir fácilmente Workers Windows a un clúster de Kubernetes y administrarlos como lo haría con la administración tradicional Nodos de Linux desde la UCP (Universal Control Plane).

La capacidad de orquestar “Containers” basados en Windows permite a las organizaciones aprovechar la amplia disponibilidad de imágenes existentes con formatos Windows (docker hub), tanto para el desarrollo de nuevas aplicaciones como para la modernización de las existentes. Este Proporciona un camino relativamente fácil para “contenerizar” y operar aplicaciones de Windows de misión crítica (incluso heredadas) en un entorno que mejora la disponibilidad y facilita el “scale”, manteniendo la administración de la infraestructura subyacente a través de políticas, herramientas y opciones familiares orientadas a Windows. Por supuesto, también libera a los usuarios para explotar Azure Stack y / u otras plataformas en la nube que ofrecen infraestructura virtual y básica de Windows Server, el entorno Multi Cloud para la aplicación.

Soporte de GPU

Hubo un tiempo en que las “Graphic Processing Units” (GPU) eran solo para juegos, pero ese tiempo ya pasó; ahora son una parte esencial para realizar eficientemente los pesados cálculos que se están convirtiendo cada vez más en parte de la vida empresarial. Incluso antes de que el Machine Learning y la Inteligencia Artificial aparecieran en el radar empresarial, las grandes corporaciones tenían operaciones de “Data Mining” que los habían preparado para la próxima batalla.

Docker Enterprise 3.1 con Kubernetes 1.17 hace fácil el agregar un “Worker Node” con capacidades de GPU de manera estándar a los clústeres de Kubernetes. Con unos pocos pasos y fácilmente automatizados se puede configurar el nodo (Linux), ya sea antes o después de unirlo a Docker Enterprise, y luego, el Servicio Docker Kubernetes reconoce automáticamente al nodo como habilitado para GPU, y los Deploys que lo necesiten o puedan llegar a usar esta capacidad pueden ser “taggeados” y configurados para detectarlo.

Esta capacidad complementa la alta variedad cada vez mayor de placas de GPU NVIDIA para el Datacenter (y escritorio), así como la rápida expansión de las opciones de máquinas virtuales equipadas con hardware de GPU de los proveedores de la nube pública. La disponibilidad de la adquisición de GPU y el soporte sólido para GPU estándar a nivel de Container (por ejemplo, en TensorFlow containerizado) está transformando la explotación de nuevas aplicaciones y modelos comerciales, desde AI hasta bioinformática y juegos. Mientras tanto, Kubernetes y los contenedores están haciendo que sea más fácil compartir una GPU relativamente costosa aún, o configurar e implementar en nodos con GPU de la nube según sea necesario, lo que posiblemente permita ahorros, ya que el costo de los nodos de GPU tiende a ser elevado.

Istio Ingress

Cuando se usa Kubernetes, no se quiere exponer todo el clúster al mundo exterior. Lo más seguro es exponer solo la porción del clúster que sea necesario para manejar el tráfico entrante. Idealmente, se desearía poder configurar esta porción y tener una lógica de manejo adicional basada en rutas, encabezados, etc.

Es posible que haya oído hablar de Istio, la aplicación “service mesh” que le brinda un control extremadamente potente y granular del tráfico dentro de las partes de una aplicación descentralizada. Parte de Istio es Istio Ingress, un reemplazo directo para Kubernetes Ingress, que controla el tráfico que ingresa a su clúster. Docker Enterprise 3.1 incluye Istio Ingress, que se puede controlar y configurar directamente desde UCP 3.3.0. Eso significa que puede habilitar o deshabilitar fácilmente el servicio directamente desde la interfaz de usuario o la CLI.

Ver mas..

Read more

06 May 2020

Artículos

Cuando transitamos el camino de la Transformación, cada vez más buscamos que nuestro ambiente se comporte con la libertad que nos da la Cloud, y en esa dirección la Hiperconvergencia es el discurso más atractivo. Yo digo discurso, porque no necesariamente es un camino absoluto y único. Encontré este link que me parece interesante. Lo publica PureStorage, y obviamente se inclina hacia la convergencia. Pero bueno, el un lujo que Pure se puede dar ya que ellos tienen resueltos aspectos que no se encuentran en cualquier tecnología. Pero lo mismo pasa con Nutanix. Tranquilos, podemos ofrecer cualquiera de las dos, je.

El análisis entonces es entre Nutanix y Purestorage, ambas soluciones líderes en lo que hacen. Creo válido los temas tratados en el análisis y uds podrán revisar los puntos y sacar sus propias conclusiones. En algún punto es una cuestión de gusto, y de en donde se quiere poner énfasis en lo que se busca como solución. Desde lo personal pienso que ambas soluciones tienen elementos de altísimo valor.. y hasta me gustaría combinarlas, sobre todo en nuestra visión de un mundo de solo Containers, algo que debe tomar más vuelo en nuestra región. Nosotros ofrecemos Docker como la plataforma ideal y tanto Nutanix como Purestorage cuentan con integraciones poderosas.

https://www.purestorage.com/content/dam/pdf/en/white-papers/protected/wp-deepstorage-exploring-true-cost-of-hci.pdf

Read more

04 May 2020

Artículos

Ninguna plataforma puede ser un todo ni para todos. Si bien hay muchas organizaciones que operan a escala creando sus propias plataformas, a menudo utilizando los mejores componentes, hay algunas otras que debido a la experiencia de combinar constantemente distintas plataformas, simplemente no quieren experimentar y buscan comprar una única plataforma.

Así es como Windows Server y Enterprise Linux crecieron de sistemas operativos a plataformas por derecho propio para sus respectivos propietarios, Microsoft y Red Hat, y este es también el camino que el pionero del almacenamiento hiperconvergente Nutanix terminó cuando trató de “conectar la SAN” del Data Center con su plataforma híbrida de cómputo virtual y almacenamiento virtual, que comenzó a construir en 2009 y se entregó por primera vez en 2011. Hace unos años, Nutanix agregó su propia implementación Acropolis del hipervisor KVM, que permitió a sus clientes dejar de pagar VMware por ESXi y sus muchos complementos y reinvierten esos ahorros en el software Nutanix. El stack de Nutanix ha tenido muchos nombres a lo largo de los años pero la compañía finalmente se ha decidido por la marca Acropolis y le ha agregado un número de servicios en los últimos cinco años, especialmente una implementación del entorno de orquestación de contenedores de Kubernetes llamado Karbon (un homenaje a la idea de los contenedores de copia de carbón) que surgió el año pasado y que se actualizó recientemente.

Todas estas fuerzas competitivas han estado allí durante muchos años, pero realmente llegaron a un punto crítico en los últimos tres años, y los ingresos provenientes de Nutanix reflejan esto, así como los cambios muy difíciles de licencias a ventas por suscripción y de electrodomésticos a ventas de software que la compañía ha emprendido para transformarla a largo plazo y ser amigable tanto con los modelos de implementación en la nube como en las instalaciones.

Hablando de dinero sabemos que en muchas métricas, a Nutanix le está yendo bastante bien, especialmente teniendo en cuenta cómo VMware se hizo realmente fuerte a partir de 2015 con su almacenamiento virtual vSAN para competir contra Nutanix y cómo esta última compañía está cambiando su modelo de negocio de vender Appliances que se agrupan en su Stack de Acropolis u otorgar licencias de suscripciones del soft que se ejecutan en hw de terceros bajo el modelo OEM. Hay una cierta competencia de Hewlett Packard Enterprise con Simplivity y Cisco Systems con HyperFlex y Microsoft que se fortalecen con su Azure Stack HCI (que ejecuta el almacenamiento virtual de Storage Spaces Direct sobre Windows Server e Hyper-V), y mientras Red Hat de IBM la unidad llega tarde con su Infraestructura hiperconvergente para virtualización, esto puede deslizarse debajo de su implementación OpenShift de Kubernetes y darle a Red Hat una pila que es análoga a la que Nutanix ha construido con Acropolis con Karbon.

La buena noticia para los clientes de Acropolis es que Nutanix está lanzando Karbon de forma gratuita, y pueden activarlo en cualquier momento que lo deseen sin tener que pagar un centavo.

Read more

16 Mar 2020

Shrinkit IT

Al iniciar en el terreno de Containers lo primero que buscamos es utilizar esta herramienta para ejecutar todo lo referente a Stateless, o en síntesis el/los cliente de la base.

Tuvimos un tiempo donde la base era una gran caja en algún lugar. A medida que confiamos en la virtualización trasladamos algunas bases dentro de VMs. Dependiendo la magnitud de las aplicaciones es probable que siga habiendo una gran caja con una base de datos y varias bases más pequeñas en VMs dentro de mi ambiente. Esto es lo que vemos hoy como normal con la virtualización.

Podemos pensar en que en lugar de una VM, la Base sea un Container. Nada nos impide pensar eso. El Container puede vivir en una VM o en un server físico por igual. Dejando por un rato de lado que pasa con el licenciamiento (digamos, no sea que venga Oracle y nos diga.. ah, un container en un nodo de 4 vCPUs en Azure??.. tenés que pagar por todos los cores que tiene Azure en ese Datacenter) ejecutar base de datos en un Container pasa a ser una ejecución casi nativa, es decir si el servidor es físico funcionará como si hubiera instalado localmente en dicho servidor. (ej: SAP HANA TDI, Oracle DB Enterprise, SQL Server for Linux).

Como fuera, creemos que el mayor beneficio lo encontraremos en soluciones modernas como MongoDB o Cassandra, incluso en “sharding” de MySql con Vitess, MariaDB…o Confluent/Kafka, del cual somos parnters. Desde el punto de vista de arquitectura estas soluciones nos darán la libertad de brindar datos en Microservicios con verdadero Scale Out, pero esto requerirá un cambio mayor en nuestras aplicaciones.

Ahora bien, los datos ubicados dentro de la imagen, los filesystems montados desde ahí durante el inicio del container trabajarán en una modalidad que se llama “copy on write”, donde las modificaciones sobre esos filesystem desaparecen al eliminarse el Container. Para que los datos perduren aún cuando el Container se elimine o se re-instancie en otro nodo por decisión de Kubernetes, necesito crear volúmenes persistentes.

De la misma manera que en un Cluster tradicional de Unix/Linux/Windows en el que dos Servers comparten una LUN, deberíamos trasladar esta problemática al Container (Docker) o al Orquestrator (Kubernetes). Para facilitar esta tarea existen los plugins.

Inicialmente estos plugins residían en la herramienta de container (Docker), pero hoy la tendencia es que residan en el orquestador (Kubernetes). VMware, Nutanix, etc.. tienen plugins, pero si este plugin lo ofrece la solución de almacenamiento, nos independizamos de Hypervisor y podemos pensar en ambientes físicos o virtuales por igual.

Hay un estándar emergente y en desarrollo que se llama CSI (Container Storage Interface (CSI) for Kubernetes). Purestorage tiene un esquema de solución para integrarse con Kubernetes mediante este estándar que se denomina Pure Service Orquestrator o PSO. En un ambiente muy grande, con varios racks, varios Storage y Servers por rack, PSO ofrece la funcionalidad mediante políticas de ubicar los datos y workloads acorde a la ubicación en el datacenter. (Pure Service Orchestrator).

En nuestra búsqueda de productos para entornos de microservicios en containers, vimos a Purestorage como un aliado de valor.

Read more