Consideraciones de Conectividad y de Capacidad

Hace unos días escribí unas breves notas con consideraciones que, desde el punto de vista de preventa, sugiero tener en cuenta al momento de dimensionar una solución de almacenamiento.

Ahora voy a detallar mejor las consideraciones a tener en cuenta respecto de la conectividad y la capacidad.

Consideraciones de conectividad

La conectividad en ocasiones es una variable que no se puede elegir, porque el cliente ya posee infraestructura para este propósito. Sin embargo, hay que tener en cuenta las diferencias para hacer las sugerencias técnicas para el correcto dimensionamiento de la solución. En general, los entornos que se analizan están basado en protocolo Fibra Canal y protocolo Ethernet.

Fibra Canal (FC)

Si la conectividad es por Fibra Canal, es importante validar la compatibilidad de velocidad, en especial cuando ya existe alguna solución de almacenamiento. Los sistemas vigentes soportan velocidades de hasta 16 Gbps, con capacidad de auto negociación a 8 Gbps y hasta 4 Gbps, pero eso dependerá también de la infraestructura de los switches SAN disponibles. Acá es importante tener en cuenta que es probable requerir actualizaciones de firmware, y es mandatorio que exista soporte con el fabricante de los mismos para este propósito.

En el caso de los cables usados, se recomienda el uso de cables OM3 y OM4: la principal diferencia entre estos cables es la distancia que se soportan dependiendo de la velocidad a usar. Por ejemplo, en una red SAN a 16Gbps, usar cables OM3 permiten hasta 100 metros, en cambio con cables OM4 se consiguen hasta 125 metros.

Ethernet

En conectividad Ethernet, las velocidades usadas son 1GbE y 10GbE, con auto-negociación. Es importante definir la infraestructura de red existente, porque aunque al estar basado en IP se puede usar los mismo componentes de red LAN, se debe buscar separar las redes (LAN y SAN-IP) de forma física o lógica (VLANs) y evitar problemas de rendimiento (como sobre-suscripción) o de seguridad.

Para Ethernet existe conectividad en cobre o fibra, de modo que es necesaro validar que los switches tengan disponibilidad de puertos. Es recomendable usar fibra si la velocidad es 10GbE, especialmente por mayores distancias soportadas, y deben seguirse las recomendaciones de los fabricantes en las configuraciones de los switches, como por ejemplo el uso de Jumbo Frames (MTU 9000) o control de flujo (Flow Control).

Consideraciones de Capacidad

La capacidad requerida es uno de los factores más "sencillos" de determinar cuando se dimensiona una solución de almacenamiento, y esto hace que sea una de las variables en que más se pueden cometer errores.

Por eso es importante tener en cuenta ciertas variables, como por ejemplo:

Capacidad de los discos y unidades SSD

El sistema binario normalmente es usado para determinar capacidad y velocidad de los diferentes componentes de TI, pero la nomenclatura usada describe el sistema decimal. Es así que un Megabyte (MB) se considera 2^20 bytes, pero realmente un Megabyte es igual a 10^6 bytes. Como aclaración 2^20 bytes es igual a 1 MiB (1 Mebibyte).

Esta diferencia puede generar confusiones y problemas con el dimensionamiento, porque mientras los fabricantes de discos usan el sistema decimal, algunos sistemas operativos usan el sistema binario, y genera diferencias en su capacidad real. En este blog hay una entrada que detalla este tema con mayor profundidad.


La sugerencia acá es utilizar las herramientas de los mismo fabricantes para conocer la capacidad real de un sistema de almacenaiento (por ejemplo Dell EMC ofrece el Unity Sizer); si eso no existe, es mejor considerar aproximaciones conservadoras.

Arreglos de discos

Los arreglos de discos (conocidos como RAID) permiten protegerse contra fallas individuales de discos y/o además obtener mejoras de rendimiento. Existen diferentes tipos o niveles de arreglos, cada uno con ventajas y desventajas, así como implicaciones de capacidad usable.

Discos de reemplazo (Hot Spare)

Para aumentar la disponibilidad en la soluciones de almacenamiento es recomendable el uso de discos de reemplazo (Hot Spare ó HS). Los discos HS tiene la función de reemplazar cualquier disco averiado dentro de un arreglo de discos, y por esta razón no se debe considerar dentro de la capacidad total del almacenamiento.

Caché de almacenamiento

Existen soluciones que soportan capas de caché de almacenamiento basadas en unidades de estado sólido (SSD). En general, esta capa de SSD no se considera en la capacidad total del almacenamiento, sino que se utiliza para obtener altos rendimientos en especial para las operaciones de lectura.

Espacio para snapshot y clones

Los snapshots (imágen instantáneas) y clones en los sistemas de almacenamientos son usados para respaldos, escenarios de pruebas, replicación, etcétera. En el dimensionamiento deben considerarse el espacio que se dedicará para estos propósitos, y puede ser muy variable dependiendo de las tecnologías a usar.

Por ejemplo, la replicación de Zerto estima entre un 7% y 10% adicional de la capacidad de las máquinas virtuales para su CDP (journaling).

Provisionamiento por demanda

Una de las tecnologías más útiles y usadas en la actualidad es el aprovisionamiento por demanda o Thin Provisioning. La principal ventaja es que posibilidad de sobre-aprovisionar el espacio requerido para una máquina virtual o física, pero se debe tener cuidado con los límites reales del espacio disponible, así como el impacto en rendimiento que puede tener en la plataforma (especialmente si se hace del lado de los servidores y no del almacenamiento).

Crecimiento de la capacidad

La capacidad de almacenamiento de un cliente suele estar afectada por 2 tipos de crecimiento: el crecimiento de datos por la información generada por los sistemas actuales, y el crecimiento generada por el aumento de usuarios y/o nuevos servicios.

Esta información es normalmente proveída por el cliente, y lo que se debe buscar es cotejar esa información con los datos recabados durante el levantamiento de información, porque el cliente tiende a sobre-dimensionar el requerimiento de espacio requerido.

Personalmente suelo utilizar la herramienta DPACK (Dell Perfomance Analysis Collection Kit) porque se cero invasiva (no requiere instalación ni agentes) y permite conocer en línea el comportamiento de la infraestructura (capacidad de almacenamiento, rendimiento por IOps, uso de CPU, memoria RAM entre otros) de forma gráfica sencilla.

Espero sean de utilidad estas breves notas, quizá sea de interés también:

• Algunas breves notas con consideraciones preventa para almacenamiento
• Consideraciones de Rendimiento (Pronto)

Follow @robertourgiles

Algunas consideraciones (preventa) para almacenamiento

El almacenamiento es uno de los componentes claves dentro de la arquitectura de TI, más aún que en la actualidad tecnologías ya maduras como la virtualización de infraestructura, aplicaciones de audio/vídeo, volúmenes de datos no estructurados (Big Data), vídeo vigilancia y otras, son generadores de gran cantidad de nuevos datos de forma constante.

Es por esto que al evaluar  una solución de almaceamiento para TI es muy importante elegir la opción que se ajuste más a los requerimientos actuales y futuros del negocio.

Estas breves notas buscan repasar algunos de los tipos de almacenamiento más frecuentes y algunas guías para su elección y configuración, desde el punto de vista de preventa, y por ende no pretende ser una fuente en profundidad de tecnologías de almacenamiento.

Generalidades

Por su forma de acceso a los datos, podemos dividir los almacenamientos en 3 grandes grupos: acceso por bloques, acceso por sistema de archivo, y almacenamiento de objetos.

A los sistemas de almacenamiento basados en bloques se los conoce como SAN (Storage Area Network, aunque no es preciso llamarlo así) y a los basados en archivos se conoce como NAS (Network Attached Storage).

Acceso por bloques

Los datos se almacenan en unidades, que se conocen como bloques y que en su conjunto forman unidades de mayor capacidad conocidas como Unidades Lógicas (LUN) y/o almacenes de datos (datastores).

El acceso por bloques utilizar, entre otros, uno de los siguientes protocolos: SAS, FC, iSCSI, FCoE e Infiniband.

SAS (Serial Attached SCSI)

SAS y SATA son los protocolos que de los discos usan para comunicarse con los sistemas de almacenamiento. En general para entornos de almacenamiento corporativo se usas SAS 3ra Gen (SAS-3 @ 12Gbps).

Pero el protocolo SAS-3 se usa también para la comunicación entre los sistemas de almacenamiento y los servidores. Estos sistemas se denominan DAS (Direct Attached Storage), y anteriormente implicaban la no compartición, pero hoy existen sistemas SAS que permiten compartir su almacenamiento entre varios servidores, aunque normalmente con un número muy limitado de conexiones.

Fibre Channel (FC)

El protocolo de fibra canal (FC) ha sido por mucho tiempo casi un estándar para la implementación de redes de almacenamiento (SAN) de alto desempeño, principalmente a su excelente velocidad de comunicación, tecnología non-blocking, muy baja latencia y soporta largas distancias (comparado con SCSI). Actualmente tenemos, comercialmente disponible, FC a 16 Gbps, y generalmente hay compatibilidad con 2 generaciones previas al menos (4 Gbps, 8 Gbps), que se comunican con los servidores (hosts) por medio de tarjetas HBA.

Internet SCSI (iSCSI)

iSCSI es un protocolo de comunicaciones para almacenamiento que utiliza el protocolo Ethernet (TCP) para encapsular paquetes SCSI, de modo que "cualquier" red LAN se puede utilizar para implementar una red de almacenamiento utilizando los mismos componentes (tarjetas de red (NIC), switches, cables, etc.). Al usar redes Ethernet, se obtienen algunas ventajas como la capacidad nativa de enrutamiento, distancia casi ilimitada, velocidad de 10/40 Gbps, y menores costos de implementación. Su principal desventaja puede ser la velocidad (no hay priorización), si no se usa una red dedicada para iSCSI.

Es común intentar comparar iSCSI a 10GbE con FC 8Gbps, y la realidad es que aunque la velocidad de iSCSI 10GbE es mayor a FC 8Gbps, el ancho de banda es comparable porque el protocolo FC es más eficiente que el protocolo Ethernet.

Fibre Channel over Ethernet (FCoE)

FCoE es un protocolo que canal de fibra vía redes Ethernet, pero no es IP enrutable. Para superar la falta de priorización de Ethernet, para FCoE al estándar Ethernet debe añadirse capacidades de Data Center Brinding. Al estar sobre redes Ethernet, se pueden implementar sobre redes de 10/40Gbps.

Su uso principal es en entornos convergentes, en donde se dispone de una red  de alta velocidad para uso de LAN y SAN, ahorrando componente activos (como switches) y pasivos (cableado, paneles, etcétera), en especial en configuraciones ToR (Top-of-the-Rack).

InfiniBand

InfiniBand es un protocolo maduro, con latencias muy bajas y alto ancho de banda, que se usa principalmente en soluciones que requieren conectividad de muy alta velocidad, como redes de cómputo de alto desempeño (HPC), y como red de interconexión BackEnd entre nodos en sistemas de almacenamiento, como por ejemplo sistemas Dell EMC Isilon.

Actualmente se tienen velocidades de 40 y 100 Gbps. En general son soluciones más costosas que FC y redes Ethernet, tanto en términos de costos administrativos como operativos, y además existen muy pocos proveedores de hardware para esta tecnología.

Acceso por archivos

Los datos se almacenan como archivos o ficheros en una estructura previamente definidas en un formato con estructura, denominado Sistema de Archivos (File System). Para este acceso se utilizan principalmente los protocolos NFS y SMB (CIFS).

NFS (Network File System)

NFS (Network File System, Sistema de archivos de red) es un protocolo cliente/servidor que permite compartir archivos, originalmente desarrollado por Sun Microsystems para entornos Unix usando protocolo Ethernet, y por tanto su velocidad depende de la infraestructura Ethernet sobre la que esté implementado. Hay 3 versiones actualmente NFSv2, NFSv3, NFSv4 y, aunque originalmente fue diseñado para compartir archivos, actualmente existen implementaciones que permiten su uso en entornos de bloques (como por ejemplo Nutanix DFS).

SMB (Server Message Block)

SMB es un protocolo de red tipo cliente/servidor, para compartir archivos u otro recursos en una red de equipos Windows. Originalmente desarrollador por IBM, tiene sus variantes como el CIFS (Microsoft) y Samba (Linux). Al igual que NFS, se rendimiento depende de la infraestructura de red Ethernet sobre la que está implementada. Las versiones más recientes son SMB 3.0, SMB 3.1.1, y su uso está principalmente enfocado en compartir archivos, aunque desde la versi;on SMB 3.0 Microsoft soporta ejecución de máquinas virtuales de Hyper-V desde repositorios basados en SMB.

Espero sean de utilidad estas breves notas, y pronto extenderé este blog con:

• Consideraciones de Conectividad
• Consideraciones de Capacidad
• Consideraciones de Rendimiento.

Follow @robertourgiles

¿Porqué los soportes de hardware 24x7 con atención en 4 horas ya no son requeridos?

Artículo original en inglés: http://bit.ly/1E8zszR
Publicado por: Josh Odgers

Disclaimer: Lo siguiente es mi interpretación personal, no es una traducción exhaustiva del texto original. Algunas palabras o frases pueden no ser exactas, pero el mensaje final se ha pretendido mantener intacto.

En semanas recientes, he visto numeros RFQ/TDR que tienen requerimientos de soporte 24x7x2 o 24x7x4 con reemplazo de partes en sitio, y aunque esto no es raro, he estado pensando ¿porqué se hace esto?


A lo largo de mi carrera de TI, que abarca mas de 15 años, en la mayoría de los casos yo mismo he recomendado en mis diseños, que el cliente adquiera contratos de soporte de tipo 7x24 con atención de 4 horas en sitio, para equipos de cómputo, almacenamiento, SAN y dispositivos de red en general.


Nunca he encontrado dificultad para justificar esta recomendación, porque tradicionalmente si un componente en el Centro de Datos falla, como por ejemplo una controladora del almacenamiento, esto generalmente tiene un alto impacto en el negocio del cliente, y cuesta decenas o centenas de miles de dólares o incluso millones, dependiendo del tamaño del cliente.


La avería de una controladora de arreglos no solo genera un alto impacto, sino también un alto riesgo para el entorno, ya que no tendrá redundancia y una falla posterior podría (con mucha posibilidad) resultar en una caída completa


Así en este ejemplo, en donde una típica solución de almacenamiento que tiene una falla en una de sus controladoras, resulta en una degradación del rendimiento (pierde el 50% de su capacidad de procesamiento) y un alto impacto/riesgo en el cliente, el poseer el soporte 24x7x4 o 24x7x2 tiene sentido!


La pregunta es, porqué elegir una solución de HW en donde la falla de uno de sus componentes lo pone en alto riesgo?


Con lo rápido que cambia la tecnología cada año, he estado envuelto en muchas reuniones con clientes qué me han preguntado qué recomiendo en términos de soporte para el HW (para clientes Nutanix).


Normalmente estas preguntas/conversaciones ocurren después de la discusión sobre la tecnología, en donde explico varios escenarios de falla y cuán resielente es un cluster de Nutanix.


Mi recomendación será algo como esto:

Si usted arquitecta su solución para el nivel de disponibilidad deseado (p.e. N+2) no hay necesidad de contratar un contrato de soporte de hardware 24x7x4h, la opción de soporte tipo Siguiente Día Hábil (8x5xNBD) aplica perfectamente bien.

Justificación:


1. En el evento de incluso la falla de un nodo completo, el cluster Nutanix va automáticamente a "auto-repararse" con el factor de resiliencia (2 o 3) configurado, incluso antes de que un contrato con atención de 2 horas pueda proveer un técnico en sitio, diagnosticar y reemplazar el componente.


2. Asumiendo que el componente de HW se reemplaza en el plazo de 2 horas (lo cual no es usual en mi experiencia), Y ADEMÁS asumiendo que Nutanix no se "auto curó" automáticamente previo al reemplazo del disco/nodo, el disco/nodo reemplazado empezará en ese momento el proceso de "auto-curado". Es así que el tiempo de recuperación o regeneración va a ser superior a 2 horas. En el caso de Nutanix, el "auto-curado" inicia casi inmediatamente.


3. Si un cluster está dimensionado con el nivel de disponibilidad requerido en función de la necesidad del negocio, p.e. N+2, un nodo puede fallar, Nutanix automáticamente va al auto-curarse y entonces tolerar una falla subsecuente con la habilidad de nuevamente "auto- curarse" con el factor de resiliencia configurado nuevamente (2 o 3).


4. Si un cluster está dimensionado para un cliente solo con N+1, un Nodo puede fallar, y Nutanix automáticamente a auto-curarse; Entonces si, en el poco probable (pero no imposible) evento de una fallo subsecuente (p.e. el fallo del 2do nodo antes del reemplazo del HW con problemas), el Cluster Nutanix se va a mantener operando.


5. El impacto en el rendimiento de la falla de un nodo, en un entorno Nutanix N+1, es en el peor de los casos (cluster de 3 nodos), sería del 33%, que comparado con un entorno SAN/NAS de 2 contraladoras, en donde el impacto de la falla de una de ellas representa el 50%; en un cluser de 4 nodos, el impacto es solo del 25%, y en clientes con 8 nodos es del 12,5%. Mientras mas grande el cluster es menor el impacto.


Nutanix recomienda N+1 con hasta 16 nodos, y N+2 con hasta 32 nodos.Mas allá de 32 nodos mayores niveles de disponibilidad pueden se requeridos, basado en las necesidades del cliente.


El riesgo e impacto de los escenarios de fallas es clave, el caso de Nutanix, por su capacidad de auto-reparado, y el hecho de que todas las controladoras y SSDs/HDDs en el cluster participan en este proceso, y hace que pueda ser realizado rápidamente y con bajo impacto. Es así que el impacto de una falla es bajo (N-1) y la recuperación es hecha rápidamente y el riesgo para el negocio es bajo, por tanto se reduce drásticamente (e incluso es prescindible, en mi opinión) la necesidad de un soporte tipo 24x7x2hr para los clientes Nutanix.


En resumen:

1. La decisión de qué tipo de contrato de soporte de HW es el más apropiado es una decisión que depende del negocio, y debe estar basada en parte en un sesudo análisis de riesgos realizado por un experimentado arquitecto, que debe estar muy familiarizado con toda la tecnología que se va a utilizar.


2. Si la recomendación del arquitecto es que el riesgo de una falla en el HW puede causar un alto impacto o incluso una pérdida de operación para el negocio, tal que se requiera un contrato 24x7x2hr, entonces mi consejo es que se re-considere si la "solución" propuesta cumple con los requerimiento del negocio. Solo si no tiene otra opción, compre el soporte 24x7x4hr ó 24x7x2hr.


3. Tener una alta dependencia de que el HW sea reemplazado para restaurar la resiliencia y/o rendimiento de una solución, es por si mismo un alto riesgo para el negocio.


Y además,

4. En mi experiencia, no es poco común tener problemas obteniendo el soporte de HW en sitio dentro del término del contrato o SLA. A veces esto escapa del control del fabricante, pero la mayoría de fabricantes experimentan uno o mas de estos problemas que personalmente he experimentado en numerosas ocasiones en otros roles, como:

a) Vendor falla en complir el SLA por soporte en sitio

b) Vendor falla el tener la parte requerida disponible dentro del SLA

c) El reemplazo de HW es con parte re-acondicionadas (práctica común) y que han fallado antes


Nota: los contratos de soporte no prometen una resolución dentro del período de 2 o 4 horas, simplemente prometen que alguien va a ir al sitio, y en algunos casos será después de haber llevado un proceso telefónico de detección de problemas con el fabricante, envío de logs para análisis, etc. Por eso es que, las 2 o 4 horas de atención no agregan mucho valor.


Así que en su próxima compra de infraestructura (o cuando hagan recomendaciones, si usted es un arquitecto), considere cuidadosamente qué tipo de solución elije (o propone), y su siente que es mandatorio un contrato de soporte en HW tipo 2hr/4hr, le recomiendo re-evaluar el requerimiento de lo que usted esta adquiriendo (o recomendando), porque puede que no sea lo suficientemente confiable para cumplir la exigencia requerida.


Food for thought