Saltar al contenido

Nutanix compra PermixData

Los chic@s de Nutanix estan especialmente activos este verano, si hace poco anunciaban el soporte de Cisco UCS como plataforma para su software (con algún que otro roce con Cisco), el 28 se hacía publico el acuerdo por la compra de PermixData

Logo_NutanixPernixData_Logo_Color

sin duda es una compra muy interesante que podría permitir a Nutanix dar un salto cualitativo en el rendimiento (ya de por si muy alto) de su almacenamiento, al incorporar la tecnología de aceleración de PermixData.

 

la prensa del sector ya se hace eco del acuerdo:

http://www.eweek.com/enterprise-apps/nutanix-acquires-pernixdata-calm.io-to-boost-data-center-ip.html

http://www.theregister.co.uk/2016/08/29/nutanix_nabs_pernixdata_and_calmio/

Nutanix y Cisco UCS, aproximación distinta a DELL y Lenovo

Hace unos días se hacía publica una de las noticias más importantes del verano en el mundo de la Hyperconvergencia, concretamente el anuncio por parte de Nutanix del soporte ed CISCO UCS como plataforma HW para su software Hyperconvergente (puedes leer más aquí).

Nutanix-Cisco-UCS

 

Este anuncio venía a ampliar la gama de HW soportado por Nutanix, actualmente Cisco UCS, Dell, Lenovo y el HW Nutanix oemizado de SuperMicro (para evitar suspicacias se citan en orden alfabetico :-)) .

 

¿Qué diferencia hay con respecto a Dell o Lenovo?

Tanto con Dell como con Lenovo, Nutanix tiene un acuerdo (OEM) para llevar su software a estas plataformas de manera conjunta, con CISCO no existe tal acuerdo, es decir Nutanix se ha encargado de llevar su software a esta plataforma. Hay quien dice que las fallidas negociaciones de adquisición en 2015 de Nutanix por parte de Cisco y los planes de esta última para desarrollar su propia plataforma Hyperconvergente.

¿Por qué lo ha hecho en solitario?

Probablemente y esto es mi opinión por dos motivos, el primero que no han llegado a un acuerdo similar al que tienen con Lenovo y Cisco y segundo, que a pesar de no tener acuerdo, la plataforma CISCO UCS tiene mucha presencia en un target de cliente que interesa mucho a Nutanix.

 

En cualquier caso y sea como fuere, es una gran noticia que el soporte de Nutanix se extienda a una plataforma como UCS.

 

Huawei IDSx000 Indoor Data Center Solution

Huawei es uno de los principales fabricantes para el Datacenter. Con un portfolio realmente extenso que abarca desde el networking a los containers, pasando por UPS, cooling y servidores, muchas de sus soluciones no son especialmente conocidas (al menos en el mercado Europeo y Latam), un ejemplo de esto podría ser la solución IDSx000 para DataCenters.

A continuación os dejo un pequeño vídeo resumen de este producto:

Nuxtanix ahora en HW Cisco UCS

Ayer (18 de Agosto de 2016) Nutanix hizo publico lo que era un secreto a voces, el soporte de Cisco UCS como plataforma HW para su software de Hyperconvergencia,

Nutanix-Cisco-UCS

 

y digo secreto a veces, porque desde hace algún tiempo el software de instalación Foundation, ya de daba pistas de que se estaba probando este HW.

 

Las implicaciones de esta nueva alianza son muchas, ya que supone un acercamiento a uno de los principales fabricantes en el Datacenter y sobre todo de cara a competidores directos, que usaron o tenían previsto usar este HW.

Comunicado_Nutanix_Cisco

Podéis consultar el comunicado completo aquí.

 

VFRC en VMware, ¿qué es ?

VFRC, o vSphere Flash Read Cache es como su nombre indica una cache basada en tecnología Flash, cuyo cometido es acelerar las operaciones de I/O.

vmware-logo

Esta cache Flash la podremos configurar típicamente a partir de discos SSD o dispositivos PCIe Flash

Samsung950ProCar_678x452

<imagen dispositivo PCIe Flash M.2 de Samsung>

La teoría detrás de esto es muy sencilla. Si tenemos acceso a memoria Flash, que es más rápida que los discos rotacionales, la vamos a usar para establecer una cache intermedia que permita incrementar el rendimiento de nuestro acceso al almacenamiento, de tal manera que los datos más usados serán servidos por una almacenamiento local y Flash en lugar de traerlos a través de la SAN.

 

Las máquinas virtuales que configuremos para hacer uso de esta cache verán mejorado su rendimiento, estando la mejora relacionado con el tipo de acceso a almacenamiento que haga la máquina virtual.

Algunas preguntas interesantes referentes a esta tecnología son:

  • Una máquina que haga uso de VFRC ¿puede hacer vMotion?- Si, aunque le proceso puede verse ralentizado
  • ¿Qué pasa si el dispositivo SSD falla? – Nada, simplemente el rendimiento de LV, se verá degradado al perder la cache
  • ¿Solo acelera operaciones de lectura? – Básicamente. Supongo que por eso lo llaman cache de lectura ;-), aunque es cierto que de manera indirecta, al liberar a la SAN de operaciones de lectura, puede mejorar el desempeño de esta a la hora de realizar escrituras y por tanto… también acelerar las escrituras.
  • ¿Cuanto más grande mejor? – No, tiene que tener el tamaño adecuado. Definir un tamaño mayor del necesario, no solo no aporta mejora, si no que nos priva de usar ese almacenamiento Flash para otras funciones (por ejemplo para mejorar el rendimiento de la memoria swap)
  • El tamaño de bloque puede ir de 4KB a 1024K, ¿cual es el adecuado? – el que use el sistema operativo de la máquina virtual

 

 

Para más información podéis leer:

 

Performance Best Practices For VMware vSphere 6

Frequently asked questions about vSphere Flas Read Cache de DuncanEpping

 

 

 

Jumbo Frames, ¿qué son y donde usarlas?

Diseñando con uno de nuestros clientes su nueva arquitectura de servidores/virtualización y almacenamiento, le han surgido una serie de dudas sobre el uso de Jumbo frames. En realidad es un tema, que aunque sencillo, no es muy conocido y es habitual ejemplos de uso (o no) inadecuado.

Un poco de teoría:

La mayoría de nuestras redes a nivel de CPD se construyen sobre los protocolos ethernet para L2 e IP para L3.

modelo OSI

 

el tamaño de trama por defecto para ethernet es de 1500bytes (fijaos que digo trama y no paquete. En ethernet lo que se transmiten son tramas de datos y en IP paquetes que a su vez se alojaran en las tramas ethernet). Este valor, que es modificable, es lo que convierte una trama ethernet normal en un Jumbo Frame cuando ampliamos su tamaño.

 

Es importante remarcar que las Jumbo Frames, están fuera del estándar 802.3 que define ethernet. El tamaño máximo es de 9.000Bytes

 

¿Debo usar Jumbo Frames en mi red?

Pues depende… activar el uso de Jumbo Frames reduce la carga de gestión de las tramas y paquetes (si paquetes ip también, luego veremos la razón) y puede mejorar el rendimiento a la hora de transferir grandes volúmenes de información, (por eso las SAN son escenarios donde usar Jumbo Frames), por contra aumentan la latencia de la red (especialmente en redes lentas).

En general se puede decir que el uso de Jumbo Frames mejora la eficiencia de nuestra red.

Eficiencia_Jumbo_Frames

<Fuente Wikipedia>

Lo que no debes hacer bajo ningún concepto es mezclar dispositivos con Jumbo Frames activos y otros desactivos, eso es una fuente potencial de problemas.

 

¿Entonces por qué no las usa todo el mundo?

Fundamentalmente porque no toda la electrónica de red (sobre todo la antigua) la soporta. El aumento de tamaño de trama reduce el nº de tramas a transmitir, pero al ser estas de mayor tamaño también se incrementa el esfuerzo necesario para calcular los CRC y esto puede tener un impacto importante en el rendimiento de nuestra red. También es necesario ampliar la cantidad de memoria asiganada a los buffers de los dispositivos de red.

Como comentaba unas lineas más arriba, no debemos mezclar dispositivos con y sin Jumbo Frame activo, esto limita su uso a redes donde nos podemos permitir que todos los dispositivos lo tengan activo. Un ejemplo de este tipo de redes serían las redes de almacenamiento SAN (iSCSI). Para otro tipo de redes el estándar sigue siendo 1500, después de todo no es casualidad que todos los S.O. vengan configurados con una MTU de 1500 (El que la MTU de S.O. y el tamaño de trama coincidan, aumentan la eficiencia del uso de la red).

 

¿Hay alguien pensando en tamaños distintos a las Jumbo Frames?

La respuesta es sí. Ya podemos encontrar al menos:

  • Baby Jumbo Frames: son más pequeñas que las Jumbo (en realidad solo un poco más grandes que las ethernet) y se usan en entornos de carrier encapsuladas en protocolos como MPLS.
  • Super Jumbo Frames: esto como imagináis va de grande, porque grande es mejor. 64.000Bytes

 

¿Tiene aplicación a la virtualización?

Por supuesto, ya os comentaba antes que las redes SAN basadas en iSCSI son un escenario claro para el uso de Jumbo Frames.

¿VMware soporta Jumbo Frames?

Si, os enseñare a configurarlo en un próximo artículo.

 

Q1 informe de fiabilidad de H.D. de BackBlaze

BackBlaze es uno de los principales operadores de cloud a nivel mundial y como tal tienen una gran cantidad de almacenamiento. Periódicamente (y es de agradecer) comparten con nosotros su informe de fiabilidad en lo referente a los H.D., lo cual puede sernos de gran utilidad a la hora de decantarnos por uno u otro fabricante. El informe completo podéis consultarlo aquí y para los perezos@s aquí tenéis la tabla resumen:

blog-table-q1-2016-only

tabla acumulativa desde 4/10/2013

blog-table-q1-2016-cumulative-2

 

Compartiva de tasa de fallo por fabricante

 

drive-stats-2016-q1-failure-by-mfg

Sunway TaihuLight, el nuevo número 1 del Top 500

Recientemente se ha publicado la lista TOP500 del mes de Junio de 2016 y en ella aparece el nuevo Supercomputador del Gigante asiático, que viene a s sustituir al también chino Tianhe-2 (MilkyWay-2).

Esta nueva “bestia” de la computación HPC se llama Sunway TaihuLight y he aquí uno de los principales puntos de interés, NO esta basado en procesadores Xeon de Intel como los Tianhe-X.

sunway-taihulight

 

Si recordáis, hace un tiempo (Abril de 2015 más o menos) EEUU , en un intento de frenar la evolución en HPC de su competidor, prohibió a Intel y AMD vender sus procesadores de última generación. La respuesta de China a esta situación fue adquirir una licencia de desarrollo de procesadores Power a IBM, por lo que parecía que la evolución de sus nuevos sistemas iría en este sentido. La sorpresa ha sido mayúscula cuando el nuevo sistema esta basado no en un derivado de Power, sino en un derivado de la arquitectura DEC Alpha (si habéis leido bien).

No se sabe mucho de este nuevo procesador, solo que que opera a una frecuencia modesta como corresponde a un chip multicore (1.45 GHz), que es muy eficiente energéticamente (lo que lo hace además aparecer en el Green500)  y que son fabricados por la National High Performance Integrated Circuit Design Center de Shanghai.

Algunos datos más de la bestia:

  • 40.960 nodos
  • 32GB de RAM por nodo para sumar 1.3 PB en total
  • 15.3 megawatts corriendo Linpack
  • 93 petaflop/s corriendo Linpack
  • Sunway Raise OS (basado en Linux)

TOP500-June16

<Lista Top500 de Junio de 2016>