Casos de aplicación: La selección del Network Attached Storage adecuado

26 Sep 2005 en Storage

Henry Newman es un destacado especialista en temas de almacenamiento y protección de datos quién, además, es columnista de Datamation. Una empresa usuaria le pidió que realizara un criterio de selección para una instalación NAS capaz de soportar más de 18 TB desde el vamos y de escalar al doble de ello en el futuro. El NAS debía operar con un file system único.
Newman suele trabajar en proyectos de mayor tamaño, generalmente relacionados con el espacio HPC (High Performance Computing) y en principio pensó que podría aplicar sus conocimientos de SANs (Storage Area Networks) y file systems compartidos para un esquema NAS y usar el mismo conjunto métodos de pregunta y evaluación de requerimientos. Pero no existe un 100% de solapamiento entre un conjunto de requerimientos SAN y los de NAS.
Hecha esta aclaración, tal vez un poco superficial para algunos, Newman nos dice que los requerimientos para NAS tendrán algunas diferencias respecto a los de un file system compartido en SAN. Antes de preparar un requerimiento de información (RFI) para proveedores NAS, el autor plantea estas preguntas:
1- ¿Qué porcentaje del espacio total de datos se tenía que usar antes de que se retiren los archivos? Este es un punto importante, ya que puede tener implicancias serias en cuanto a fragmentación del file system. En la mayoría de los grandes entornos SAN con file systems compartidos se está aplicando alguna forma de HSM (Hierarchical Storage Management) lo cual reduce el impacto de esa eventual fragmentación.
2- ¿Qué tipos de sistemas serán conectados al sistema NAS? Los diferentes sistemas tienen diferentes “endians.” Los adjetivos big-endian y little-endian refieren a qué bits son los más importantes en tipos de datos (enteros, punto flotante, carácter-texto, etc.) muli-byte y describen el orden en el que una secuencia de bytes se almacena en la memoria de una computadora. Los mainframe, especialmente los de IBM, utilizan big-endian, mientras que las máquinas de más reciente generación son little-endian. Los sistemas PowerPC de IBM son bi-endian, entienden ambos sistemas.
El cambio de endians requiere de mucha potencia de CPU o de hardware especializado para mover bytes de un endian a otro. Todos los datos son casi siempre almacenados en el endian nativo de la CPU con la que funciona el NAS.
3- ¿Cómo será el backup del NAS? Algunos sistemas SAN soportan sus propios sistemas de cintas (librerías), otros soportan NDMP estándar y otros soportan software de backup estándar como el de Legato o Veritas.
4- ¿Qué tanta performance se requiere y puede el NAS base brindarla? Utilizando sencillas medidas y conteos de los bus PCI y PCI-X puede darnos esta información.
5- ¿Cuáles son los requerimientos de confiabilidad del sistema y qué performance hará falta durante una falla de disco? Muchos tenemos experiencia con reconstrucción en dispositivos RAID, pero no todos conocemos los dispositivos ajustables (tuneables, en criollo) de los dispositivos NAS.
6- Otra pregunta que no podía dejar de hacerse: ¿Realmente hace falta un file system de 18 TB creciendo hasta 35 TB? Es mucho espacio de storage para los entornos donde normalmente operan productos NAS y los actuales tipos de file systems.

Para plantearse todos estos interrogantes no hace falta ser ningún especialista en storage, pero las respuestas a los mismos no son tan directas o sencillas como se piensa en un primer momento. Con NAS, generalmente se combinan requerimientos de varios departamentos o grupos de trabajo asociados a un sistema. Es necesario hablar con cada uno de esos grupos y tener en cuenta sus requerimientos en los siguientes términos:
· Performance, incluyendo a la performance bajo carga plena;
· Escalabilidad para que un mismo file system pueda crecer hasta 35TB (siempre hablando de este caso puntual);
· Backup de los datos del NAS, incluyendo la capacidad de cargar los datos en una plataforma que no sea NAS en un lugar remoto; y
· Uptime, confiabilidad y velocidad de reparación. En este caso, MTTR (Mean Time To Repair) tenía que ser bajo para sitios remotos.

Ponerse a buscar en la Web y leer el marketing de cada proveedor no ayuda demasiado. En este caso, Newman creó un cuestionario para cada proveedor con conjuntos de preguntas y criterios que permitieran su evaluación.
“No crea que establecer un criterio antes de enviar la lista de preguntas a los proveedores no es algo importante. Es una de las más importantes decisiones que se tomarán durante el proceso de adquisición. Todos tenemos a nuestros proveedores favoritos por razones que pueden ser buenas o malas y por eso es necesario poner el favoritismo de lado y elegir al mejor proveedor para el proyecto y para la compañía. Puede ser o no el proveedor favorito propio o de otro en la empresa y por eso una lista de requerimientos y el modo de evaluación de los proveedores son clave para el éxito y la armonía futura del entorno.

Evaluación de proveedores
Antes de escribir lo que se dará a los proveedores, conviene crear una documentación interna sobre lo que resulta importante y porqué.
Veamos algunas partes de algo que Newman hizo para un cliente. Allí, los requerimientos críticos están listados y también una serie de oros requerimientos que se dieron a los proveedores en áreas tales como consumo de potencia eléctrica y refrigeración, repuestos y sitios en los que se realizarían las reparaciones y funcionalidad del sistema.
Requerimientos funcionales básicos:
Cada uno de estos requerimientos es un requerimiento funcional básico y no será considerado ningún proveedor que no provea su soporte.
Tamaño del file system: En este caso, el proveedor soportará 18 TB hoy y 35 TB a mediados de 2006.  Este es un requerimiento Si o No. No existen sustituciones ni explicaciones válidas fuera del rango positivo-negativo.
Backup: El NAS debe ser capaz de realizar su backup en un drive de cinta corriendo a todo régimen de compresión y debe ser posible la restauración de los datos en otro sistema UNIX. La calidad del bobinado de las cintas es importante, pero igualmente importante es la capacidad de restaurar a un sistema diferente en una ubicación alternativa. El autor recuerda la importancia que tiene la calidad del bobinado de las cintas.
Hot Swap: todos los componentes del sistema deben ser capaces de reemplazo sin detención (en caliente). Todos los componentes que no pueden ser reemplazados en caliente deben ser listados y el proveedor debe darnos estadísticas detalladas de confiabilidad, incluyendo al número conocido como Bellcore. Para una mejor comprensión de los cálculos de falla Bellcore, pueden visitar el sitio:
www.evaluationengineering.com/archive/articles/0500analyz.htm

En este caso, se deseaba que el sistema tuviera hot swapping o reemplazo en caliente para los componentes más comunes, tales como el hardware de comunicación host-to-disk. En casos como ese, nos dimos cuenta que algunas partes no podían ser reemplazadas en caliente y queríamos saber la tasa de falla para las mismas.

Performance: Se requirió rendimiento full duplex a aproximadamente 35 MB/seg y que la performance de lectura no degradara al requerimiento de performance de escritura. Tenían un requerimiento adicional de performance dado el tamaño del file system. Al respecto, dado el tamaño del file system, se exigía que la performance no podía degradarse por su fragmentación. Recordemos que la fragmentación afecta tanto a los datos como a los metadatos.
En este caso, el cliente necesitaba una gran performance debido a que se capturaban streams de video. La captura de estos datos de video era de extrema importancia, no así su lectura y querían asegurarse de que los proveedores ofrecieran un sistema capaz de dar el ancho de banda necesario para esos streams. Por esa razón, había que dejar bien claro que si la fragmentación era un problema en sus file systems (y lo es para la mayoría), tendrían que ofrecer el ancho de banda capaz de capturar datos aun si esa fragmentación ocurría. Seguramente algunos proveedores se enfurecieron cuando vieron que no podían cubrir ese requerimiento.

Conclusiones:
Al desarrollar los criterios de evaluación de proveedores, es importante entender y describir lo que resulta realmente importante en la empresa en cuanto a uso de un sistema NAS. Lo mismo podría decirse de cualquier otra adquisición de hardware, ya que la colección de requerimientos es muy parecida.
Una vez que se establecen los hitos de importancia, hará falta ponerse de acuerdo en cómo evaluar a la respuesta de los proveedores basándose en los requerimientos aceptados. El principio rector debe ser la evaluación objetiva, limpia y basada en esos requerimientos, sin desvíos.
Se pueden usar recursos como colores (rojo igual a muy riegoso, amarillo riesgoso pero menos, azul cuando alcanza el criterio con bajo riesgo, verde cuando lo alcanza casi idealmente con riesgo bajísimo, etc.) u otros a gusto, como scores de puntajes. Lo importante es no alejarse de la objetividad y no esconder la importancia de algún requerimiento a causa de otros aspectos fascinantes que suelen aparecer en el marketing de los proveedores.