HPE busca consolidarse en almacenamiento flash con la compra de Nimble Storage

Categorías relacionadas:

HPE-Nimble-storage

Hewlett Packard Enterprise (HPE) anunció que ha completado su adquisición de Nimble Storage, proveedor de soluciones de almacenamiento predictivo all- flash y flash híbrido con sede en San José, California.

Informó que pagó 12.50 dólares por acción en efectivo, lo que significó un precio neto de compra en efectivo al cierre por 1,000 millones de dólares.

Además del precio de compra, HPE asumió el pago de la indemnización por las acciones no adjudicadas de Nimble, con un valor de aproximadamente 200 millones de dólares al cierre.

Además de fortalecer el liderazgo de HPE en TI híbrida, la compra busca consolidar la posición de la empresa en el creciente mercado de almacenamiento flash; crea un amplio y vanguardista portafolio de almacenamiento que reúne las ofertas de flash predictivo de Nimble para los segmentos de rango bajo y medio; y acelera la fuerza de crecimiento de Nimble al reunir un portfolio de productos complementarios y aprovechar la capacidad expansiva de comercialización de HPE, el ecosistema de socios y la plataforma líder de servidores.

“Este acuerdo, junto a nuestras adquisiciones recientes, ayuda a cumplir con nuestra visión de hacer la TI Híbrida simple para nuestros clientes,” afirmó Antonio Neri, Vicepresidente Ejecutivo y Gerente General de Enterprise Group de HPE. “A través de estas inversiones estratégicas, continuamos fortaleciendo y profundizando nuestro portfolio de soluciones de próxima generación, definidas por software y diferenciadas, que responden a los nuevos desafíos a los que se enfrentan nuestros clientes”.

Tras la fusión, Nimble se convierte en propiedad completa de la subsidiaria de HPE.

Como resultado de dicha fusión, todas las acciones de Nimble fueron retiradas de la bolsa de Nueva York el pasado lunes. Se espera que la adquisición incremente las ganancias de HPE en el primer año fiscal completo después del cierre.

Leer más...



Nueva línea de tarjetas Quadro “transforma workstations en supercomputadoras”

Categorías relacionadas:

Nvidia-Quadro-GPU100

NVIDIA presentó la nueva línea de tarjetas GPU Quadro, basadas en la arquitectura Pascal, las cuales proporcionan una plataforma de computación visual de nivel empresarial que aporta hasta el doble de rendimiento en comparación con la generación anterior, de acuerdo con la compañía.

La nueva generación de GPU Quadro –que incluye los modelos GP100, P4000, P2000, P1000, P600 y P400– permite que los ingenieros, diseñadores, investigadores y artistas logren incorporar la realidad virtual a los flujos de trabajo de simulación y diseño. En este sentido, los modelos Quadro GP100 y P4000 “VR Ready” ofrecen la capacidad para crear diseños más grandes y complejos que se pueden experimentar a escala.

La GP100 combina un rendimiento de doble precisión con 16 GB de memoria de alto ancho de banda (HBM2) para que los usuarios realicen simulaciones durante el proceso de diseño. Los clientes pueden combinar dos GPU GP100 con la tecnologia NVLink y escalar a 32 GB de HBM2 para crear una solución de computación visual masiva en una única estación de trabajo.

Asimismo, el modelo GP100 proporciona más de 20 TFLOPS de computación con precisión de punto flotante de 16 bits por lo que es ideal para aplicar el aprendizaje profundo en ambientes de Windows y Linux.

“Al unificar la computación y el diseño, la Quadro GP100 transforma la estación de trabajo de escritorio promedio en una supercomputadora”, aseveró Bob Pette, vicepresidente de Visualización profesional en NVIDIA. Las nuevas tarjetas completan la gama de modelos Quadro Pascal que incluye las GPU P6000, P5000 y móviles.

Leer más...



Seis omisiones comunes en la continuidad de los negocios

Categorías relacionadas:

continuidad-TI

Cuando se trata de asegurar la disponibilidad del centro de datos para la continuidad de la operación de la empresa, se abre una brecha entre los requisitos del Always-On Enterprise y la capacidad del área de TI para satisfacer de forma efectiva dichos requisitos en la recuperación ante desastres.

Suelen haber brechas en las capacidades de la infraestructura tecnológica, pero también en la manera en que se abordan las situaciones de crisis. En este artículo identificaremos algunas omisiones comunes que pueden crear esas brechas en la estrategia de disponibilidad de los negocios.

1. Las aplicaciones son más de lo que aparentan. Por ejemplo, un servidor de correo electrónico por sí solo no es una aplicación. Un sistema de correo electrónico como Microsoft Exchange es un conjunto de muchas cosas en el centro de datos, esto incluye servicios de red (DNS y otra infraestructura), Active Directory (mecanismo de autenticación) y usuarios con terminales que se conectan al servicio. La omisión común es tener datos fuera del sitio en una situación de recuperación ante desastres, aunque las compañías pueden determinar que no son completamente utilizables cuando se consideran todos los requisitos.

2. La comunicación es necesaria. Cuando las compañías necesitan recuperarse después de un incidente, contar con comunicaciones disponibles es lo primero. Los empleados tendrán dificultades para operar en caso de fallas sin su principal medio de comunicación (los sistemas de correo electrónico de la compañía). Esta situación empeora si se desarrollaron otras aplicaciones sobre el correo electrónico para mejorar su flujo de trabajo. Aquí la omisión común es no asegurar una completa experiencia de disponibilidad en una situación de falla de los sistemas de comunicación.

3. La práctica es crítica. Muchas empresas practican la recuperación ante desastres, pero no aprovechan esa oportunidad para involucrar por completo a los equipos de aplicaciones. Los simulacros de desastre benefician tanto a los equipos de aplicaciones como a los equipos de infraestructura. Los equipos de aplicaciones pueden estar más conscientes de cuánto dependen de sus aplicaciones en una situación de falla, lo cual puede ayudarles a mejorar los diseños y los cambios a las aplicaciones en el futuro. En este caso, la omisión común consiste en realizar ejercicios de recuperación ante desastres únicamente con los equipos de infraestructura.

4. Dar prioridad a la red. Algo que las compañías descubren sobre la recuperación ante desastres es que redes diferentes pueden interferir en la recuperación exitosa en caso de fallas. Existen tecnologías modernas para llevar una red de un sitio al otro, así como tecnología que permiten a los sistemas y las aplicaciones cambiar la configuración de la red de sitio a sitio. La omisión común es no asegurar que la experiencia de red sea fluida para las aplicaciones en una situación de recuperación ante desastres.  

5. Determinar cómo las decisiones serán tomadas. Decidir practicar un plan de recuperación ante desastres es una cosa, pero tomar la decisión de aplicarlo en una situación real de desastre puede ser difícil. Por lo general, las empresas pueden dudar ante la idea de utilizar una tecnología de recuperación ante desastres debido a la falta de una toma de decisiones adecuada, lo cual afecta todo, desde el árbol de decisión hasta el tiempo de respuesta. La omisión común es no contar con una autoridad en el lugar para manejar las decisiones en situaciones de desastre.

6. Se necesitan soluciones adecuadas de recuperación de desastres y una buena orquestación para hacerlo correctamente. Hubo una época en que bastaba contar con guiones personalizados, listas de control y herramientas a la medida para una recuperación ante desastres. La expectativa del centro de datos es alta actualmente y una estrategia anticuada no producirá un buen resultado. La omisión común es depender demasiado de una estrategia manual para la recuperación ante desastres.

Habrá otras oportunidades de aprender más sobre la recuperación ante desastres, sin embargo, esta lista muestra el camino hacia una continuidad exitosa de los negocios en caso de un incidente.

____________

Vanover-Veeam-CIO-MexicoEl autor de este artículo, Rick Vanover, es Director Ejecutivo de Estrategia de Producto en Veeam Software. Puede contactarle en Twitter @RickVanover.

Leer más...



¿Contenedores o máquinas virtuales? Tips para tomar la mejor decisión

Categorías relacionadas:

contenedores

Mencione el nombre una compañía tecnológica, cualquier compañía, y seguro que está invirtiendo en contenedores. Google, por supuesto. Microsoft, claro. IBM, compruébelo. Pero, sólo porque los contenedores son extremadamente populares no significa que las máquinas virtuales hayan pasado de moda.

Sí, los contenedores pueden ayudar a su empresa a empaquetar un montón de aplicaciones en un único servidor físico, igual que una máquina virtual (VM). La tecnología de contenedores, como Docker, supera a las máquinas virtuales en lo que se refiere a la nube o los centros de datos. Las máquinas virtuales ocupan gran cantidad de recursos del sistema. Cada VM no sólo necesita una copia completa del sistema operativo, sino también una copia virtual de todo el hardware que el sistema operativo necesita para ejecutarse. Esto se suma rápidamente a una gran cantidad de RAM y de ciclos CPU. En contraste, todo lo que requiere un contenedor es un sistema operativo, programas y bibliotecas de soporte y los recursos del sistema para ejecutar un programa específico.

En la práctica, esto significa que se pueden poner dos o tres veces más aplicaciones en un único servidor con los contenedores que con las máquinas virtuales. Además, con los contenedores se puede crear un ambiente operativo consistente y portátil para el desarrollo, la prueba y el despliegue.

Si esto fuera todo lo que tienen que ofrecer los contenedores frente a las máquinas virtuales, estaríamos escribiendo un obituario de éstas. Pero hay mucho más que cuántas apps se pueden poner en una caja.

Problema número 1 de los contenedores: La seguridad

El principal problema, que a menudo se pasa por alto, es la seguridad. Como comentó Daniel Walsh, ingeniero de seguridad en RedHat, que trabaja principalmente en Docker: los contenedores “no contienen”. Tomemos a Docker, por ejemplo, que utiliza libcontainers como su tecnología de contenedores. Los libcontainers dan acceso a cinco espacios de nombres –procesos, red, montaje, nombre de equipo y memoria compartida– para trabajar con Linux. Esto, dentro de lo que cabe, está bien, pero hay un número importante de subsistemas del núcleo de Linux fuera del contenedor.

Esto incluye dispositivos, SELinux, Cgroups y todos los sistemas de archivos /sys. Lo que significa que si un usuario o aplicación tiene privilegios de superusuario dentro del contenedor, el sistema operativo subyacente podría, en teoría, ser crackeado.

Ahora, existen muchas maneras de proteger Docker y otras tecnologías de contenedores. Por ejemplo, usted puede montar un sistema de archivos sys como de sólo-lectura, forzando a los procesos del contendor a escribir sólo en algunos sistemas de archivos del contenedor específicos, y configurar el espacio de nombres de red sólo si se conecta con una intranet privada especificada y así sucesivamente. Sin embargo, este proceso no se construye de forma predeterminada, se necesita sudar para proteger los contenedores.

La regla básica es que ha de tratar a los contenedores como lo haría con cualquier otra aplicación de servidor, tal y como explica Walsh: reducir los privilegios lo más rápidamente posible; ejecutar sus servicios como no-root siempre que sea posible; y tratar los root de dentro del contenedor como si fuera un root de fuera de éste.

Otro problema de seguridad es que mucha gente está lanzando aplicaciones en contenedores, algunas peores que otras. Si, por ejemplo, se es perezoso y se instala el primer contenedor que le cae en las manos, es posible que traigan un Troyano a sus servidores. Es necesario que el equipo entienda que no pueden descargar aplicaciones de Internet como si se estuvieran descargando juegos en su smartphone.

Otras preocupaciones sobre los contenedores
Si podemos solucionar el problema de la seguridad, ¿los contenedores lo dominarán todo? Pues no. Hay que considerar otros aspectos sobre los contenedores. Rob Hirschfeld, CEO de RackN y miembro fundador de la OpenStack Foundation, observó que: “El empaquetado es difícil todavía: crear una caja cerrada ayuda a resolver parte de los problemas de la superficie (los que sabemos que tenemos), pero no resuelve los problemas más profundos (los que no sabemos de qué dependen)”.

A todo esto me gustaría añadir que, si bien éste es un problema de seguridad, también es un problema de control de calidad. Es verdad que el contenedor X puede ejecutar el servidor web NGINX, pero, ¿acaso es la versión que usted quiere? ¿Incluye la actualización TCP Load Balancing? Es fácil implementar una app en un contenedor, pero si la instala en el equivocado, habrá perdido mucho tiempo.

Hay que recordar que el punto central de un contenedor es ejecutar una única aplicación. Cuantas más funcionalidades se coloquen en el contendor, más seguro es que debería estar utilizando en primer lugar una máquina virtual.

Es cierto que muchas tecnologías de contenedores, como  Linux Containers (LXC) se pueden usar en lugar de las máquinas virtuales. Por ejemplo, podría usar LXC para ejecutar aplicaciones específicas para Red Hat Enterprise Linux (RHEL) 6 en lugar de RHEL 7. En general, se debería utilizar contenedores para ejecutar una sola aplicación y máquinas virtuales para ejecutar múltiples aplicaciones.

Decidir entre contenedores y máquinas virtuales
Entonces, ¿cómo decidirnos entre contenedores y máquinas virtuales? Scott S. Lowe, arquitecto de Ingeniería de VMware, sugiere que nos fijemos en el alcance de nuestro trabajo. En otras palabras, si queremos ejecutar múltiples copias de una misma app, debemos usar un contenedor. Si queremos flexibilidad o ejecutar múltiples aplicaciones debemos utilizar máquinas virtuales.

Además, los contenedores suelen “encerrarnos” en una versión particular del sistema operativo. Esto puede ser bueno: usted no debe preocuparse por las dependencias una vez las aplicaciones se estén ejecutando adecuadamente en un contenedor. Pero esto también le limita.

Con las máquinas virtuales no importa qué hipervisor esté utilizando –KVM, Hyper-V, Xen o cualquier otro–, usted puede utilizar cualquier sistema operativo. ¿Qué se necesita para ejecutar una aplicación oscura que sólo se ejecuta en QNX? Es fácil con una máquina virtual, pero no es tan simple con la actual generación de contenedores. Así que permítanme explicárselo.

¿Necesita ejecutar la máxima cantidad de aplicaciones particulares con el mínimo número de servidores? Si ese es su caso, entonces use contenedores –recuerde que deberá vigilar sus sistemas ejecutados en contenedores antes hasta que asegure la seguridad de su contenedor. En cambio, si lo que hace falta es ejecutar múltiples aplicaciones en servidores y tiene gran variedad de sistemas operativos, debería usar máquinas virtuales. Y si la seguridad es importante para su compañía, usted debería utilizar máquinas virtuales desde este momento.

En el mundo real, supongo que la mayoría de nosotros utilizaremos tanto contenedores como máquinas virtuales en nuestras nubes y centros de datos.

La economía de los contenedores a escala tiene demasiado sentido financiero para ser ignorada. Al mismo tiempo, las máquinas virtuales también tienen sus virtudes.

A medida que la tecnología de los contenedores madure –algo que espero realmente suceda,– los contenedores y las máquinas virtuales se unirán para crear un nirvana de portabilidad en la nube. Aún no estamos en ese punto, pero llegaremos.

-Steven J. Vaughan-Nichols, CIO

Leer más...



La plataforma de virtualización de redes de VMware NSX

Categorías relacionadas:

Los centros de datos definidos por software (SDDC) aportan un sinnúmero de beneficios para el negocio, sin embargo, la red de estas infraestructuras aún no ha evolucionado al mismo paso, siendo un obstáculo para aprovechar todo el potencial del SDDC. La plataforma de virtualización de redes de VMware NSX ofrece infraestructura de red física que necesita para suministrar un centro de datos definido por el software.

Descarga el documento

Leer más...