sábado, marzo 24, 2007, 08:24 PM - Tecnología, Opinión
Llevo ya unos pocos de años recorriendo CPDs de grandes empresas, organismos públicos (incluyendo a algún hospital) y me he encontrado con que raro es el sitio donde hay una política de gestión del almacenamiento
Muchas veces se confunde un producto con una política. Tener una SAN (Storage Area Network) no significa que se disponga de una una política de gestión del almacenamiento; es más, muchas veces las SAN se usan como su fueran "un gigantesco pendrive", un despilfarro inmenso.
Pero volvamos al tema de la gestión del almacenamiento. No quiero contar un rollo teórico de quince páginas, ni hablar de productos que ayudan a definir una política de gestión del almacenamiento. Empecemos por lo básico: lo más crítico de la informática son los datos. Y los datos se almacenan (tras unas pocas capas de abstracción) en dispositivos. ¿Pero son todos los datos iguales?
Y es esa la primera pregunta que nos tenemos que hacer. No tienen las mismas necesidades de almacenamiento una base de datos que un buzón de correo electrónico que un servidor de ficheros cargado de .doc y .xls. Vamos a intentar formalizarlo un poco haciéndonos unas preguntas:
¿Qué rendimiento de acceso necesito para acceder a estos datos?
¿Qué disponibilidad requieren estos datos?
¿Qué accesibilidad requieren estos datos? ¿Deben estar siempre disponibles? ¿De qué forma?
¿Cómo "envejecen" estos datos? Es decir, ¿varian las respuestas a las preguntas anteriores con el paso del tiempo? ¿Y dentro de una semana? ¿Y dentro de un mes? ¿Y dentro un año? ¿Y dentro de 5 años?
Todas las preguntas anteriores evaluan distintos aspectos de la información: cómo debe protegerse, como y cuánto se accede, y como varían los parámetros anteriores a lo largo del tiempo. Por poner un par de ejemplos tontos, tal vez no deba almacenarse igual un correo electrónico de ayer que uno de hace 2 años. O quizás no tengan las mismas necesidades de almacenamiento el log de un servicio de ayer que el log generado hace unos meses.
Los párrafos anteriores dan una visión centrada en los datos. También es necesario tener un ojo puesto en la infraestructura actual (y futura) del CPD en el que nos movemos: ¿a quién no le ha pasado que tiene una máquina corta de espacio y luego tiene espacio de sobra en otras?
La gestión del almacenamiento es una disciplina que pretende poner un poco de rigor en todo esto. Así, estudiando detenidamente las necesidades de almacenamiento es posible decidir una política de gestión del espacio así como realizar compras de material con la seguridad de que se le va a dar un buen aprovechamiento.
Todo este tema (que a mi particularmente me apasiona), simplificándolo un poco, se basa en dos pilares fundamentales: jerarquización del almacenamiento y ciclo de vida de la información
La jerarquización del almacenamiento se suele conocer por sus siglas en inglés, HSM (Hierarchy Storage Management). Como casi todo en informática, la primera implementación fue en sistemas Mainframe. Se trata del conjunto de estrategias de administración del almacenamiento según las cuáles es posible identificar y definir la mejor utilización de los recursos hardware a través del movimiento de los mismos de un medio de almacenamiento disponible a otro, basándonos en un juego de políticas predefinididas y estando soportadas dichas políticas por el hardware y software adecuados.
Hablando en plata: mientras más rápido es un soporte de almacenamiento , más caro suele ser. Mientras más queramos proteger una información (raid, backup, etc), más caro nos costará. Y es por eso que hay que buscar un equilibrio entre rendimiento, disponibilidad y accesibilidad. Y nada mejor que aclararlo con ejemplos:
Para una base de datos crítica quizás sea necesario poner toda la carne en el asador y elegir almacenamiento SAN, con conexiones de fibra, y almacenado sobre un nivel de raid de alto rendimiento y con buena tolerancia a fallos (ej: un raid 10), con una buena política de respaldo. Se trata por tanto, de una situación donde prima el rendimiento de acceso, y que requiere que los datos estén bien protegidos. El coste por gigabyte es alto.
En cambio, tal vez para un servidor de ficheros departamentel baste con una NAS basada en discos SATA usando protocolos como NFS/CIFS, estando los datos almacenados en un raid5, con una política de respaldo estándar. Se trata de un caso intermedio, donde se tienen unas necesidades de acceso, rendimiento y protección de la información que no son tan elevadas como el caso anterior. El coste por gigabyte es medio.
Y por último, los logs de acceso de los proxy-caché squid pueden almacenarse a largo plazo en dispositivos ópticos como dvd y/o magnéticos como cinta, pues rara será la vez que tengamos que acceder a esa. En este caso, prima más el espacio neto total, siendo el coste por gigabyte relativamente bajo.
Por tanto, la jerarquización de la información nos ayudará a elegir entre tecnologías SAN, NAS, DAS, librerias de cintas y almacenamiento óptico, nos ayudará a decidir entre los niveles de raid a emplear, qué política de backup hacer y nos permitirá tener criterio a la hora de elegir dispositivos de almacenamiento para nuestra información.
El almacenamiento de la información se convertirá por tanto en una pirámide, estando en la base aquel almacenamiento cuyas necesidades de rendimiento y disponibilidad sean más bajas (siendo éste el almacenamiento más barato) y mientras más subamos en la pirámide mayor será el precio, el rendimiento y/o la disponibilidad de la información.
La jerarquización de la información nos permite responder a las preguntas de cómo debe protegerse la información, como y cuánto se accede. Pero nos falta la otra mitad del puzzle: ¿cómo varía esto con el tiempo?
La respuesta a esta última pregunta es el uso de técnicas de Ciclo de Vida de la información. Podríamos definirlo como el conjunto de políticas que permiten una adecuada jerarquización del almacenamiento basando la decisión en un conjunto de reglas que se ajustan a la realidad del negocio.
Así, es posible definir una política para que ciertos datos suban o bajen en la estructura jerárquica piramidal comentada hacer un par de párrafos, consiguiendo un equilibrio entre coste, rendimiento, disponibilidad y acceso.
El ciclo de vida es más importante de lo que parece: se está produciendo una explosión de uso del almacenamiento, y elegir el soporte adecuado para la información nos puede hacer ahorrarnos mucho dinero y lograr una mejor eficiencia en nuestro CPD.
Analicemos un ejemplo práctico: un cliente nos plantea la necesidad de servir ficheros a una red de varios miles de usuarios en una inmobiliaria. Este servidor de ficheros va a almacenar documentos .doc y .xls, pero también almacena complejas y pesadas imágenes para el uso de 10-12 arquitectos. Se estima que el espacio útil total ha de ser de 4 terabytes, y el cliente no quiere hacer un desembolso elevado.
Para resolver este problema nos debemos plantear las siguientes preguntas:
* ¿Qué necesidades de acceso tiene la información?
* ¿Qué criticidad tiene la información almacenada?
* ¿Cómo varía lo anterior con el tiempo?
Para responder a la pregunta ¿Qué necesidades de acceso tiene la información? Por la descripción del problema, entiendo que lo que nos requieren es un servidor de ficheros NAS que prestará servicio servicio a los usuarios mediante protocolos como CIFS o NFS. Puesto que la información se va a servir mediante una red ethernet, podemos aventurarnos a decir que el caudal máximo va a ser de 1 gigabit por segundo.
Por tanto, tenemos claro que poco beneficio vamos a obtener empleando un sistema de entrada/salida con un rendmiento mucho mayor que ese gigabit por segundo, pues el cuello de botella va a estar en la red ethernet.
Tenemos que averiguar también qué porcentaje del espacio total en disco va a ser usado por los usuarios "normales" y cuánto va ser empleado por los arquitectos, así como una estimación del tamaño medio de los ficheros de cada uno de estos tipos de usuarios. Así, los ficheros .doc tendrán un tamaño medio de 1 megabyte, los .xls un tamaño de 200 kilobyes mientras que los ficheros de los arquitectos tienen tamaños de varias decenas de megabytes.
También es necesario analizar como se accede a los ficheros. Normalmente los usuarios crean y modifican a diario unos cientos de ficheros .doc y .xls, mientras que los arquitectos solo suelen trabajar con apenas una docena de ficheros. Esto nos dará una idea de la concurrencia de acceso a la información.
Para responder a la pregunta ¿Qué criticidad tiene la información almacenada? es necesario analizar el ritmo de modificación de los contenidos, para poder elegir una política de backup adecuada, así como los niveles de raid a elegir. El cliente considera razonable una parada de 4-5 horas en caso de fallo catastrófico, pero por lo general el sistema ha de funcionar al menos el 95% del año laboral. Esto nos da una idea de que no parece crítico emplear técnicas de alta disponibilida/clustering, por lo que con un solo servidor parece bastar, con unos niveles de garantía con el fabricante de hardware para que en menos de 4-6 horas podamos tener un recambio de la pieza en caso de fallo hardware.
Mi solución para este problema (ojo, la mía, invito al lector a que dé la suya, esto es un ejemplo didáctico, no un ejemplo exhaustivo) sería el uso de un servidor x86 tipo rack con 4 gigabytes de ram, electrónica de red gigabit, fuentes de alimentación redundantes y con sistema operativo RedHat Enterprise Linux. Este servidor contará con dos sistemas de almacenamiento externos tipo DAS: una bandeja de discos SAS con 8 discos de 146 gigabytes y 10.000 rpm y con otra bandeja de 14 discos SATA de 750 gigabytes y 7.200 rpm.
Sobre este almacenamiento antes descrito, definiría dos raids: El primer raid estaría formado por 7 discos SAS, estando uno de los discos en spare. Eligiría un nivel de raid5, implementado por hardware, respaldado por una batería de caché. El espacio util sería de aproximadamente 1 terabyte.
El segundo raid estaría formado por 13 discos sata, quedando el número 14 como spare. Eligiría un raid6 por software, empleando mdadm . El espacio útil es de casi 9 gigabytes y medio. Elijo hacer un raid6 porque tengo muchos discos en el mismo raid, no porque la criticidad sea mayor que en el raid SAS.
De esta forma tengo un almacenamiento caro de alto rendimiento de discos SAS (más caro), que es donde va a estar la información que se esté usando más habitualmente y otro volumen de discos SATA donde estarán los ficheros que menos se usen, así como backups de los últimos ficheros que se hayan modificado. Haciendo uso del software LVM integrado en RedHat Enterprise Linux puedo incrementar el tamaño de cualquiera de los raids de manera sencilla. Éste mismo software me permitirá hacer "snapshots" periódicos de la información y almacenarlos en el raid SATA para poder tener así un backup "near line" sin tener que hacer uso de la libreria de cintas. El comando rsync también nos puede ser de utilidad para mantener copias de ficheros individuales.
Dicha librería de cintas se usaría para copias de seguridad "off-line" a almacenar en un armario ignifugo. Se harán copias diferenciales de los snapshots cada día, una copia incremental del volúmen completo cada fin de semana y copias totales cada mes.
Por otra parte, emplearía bonding en las dos tarjetas gigabit integradas en la máquina para tener un caudal efectivo de 2 gigabits por segundo, y con la electrónica de red adecuada podría tener redundacia de acceso a la red de datos, para que el fallo de un conmutador o un cable o de una de las tarjetas de red no impida el acceso al servicio.
El sistema de almacenamiento funcionará de la siguiente manera: se configurará el software samba para integrarse en el directorio activo actualmente existente en el cliente y emplear el protocolo CIFS para servir los ficheros.
Por último, definiría una política de ciclo de vida de la información según la cual si un documento .doc o .xls no ha sido accedido en 7 días se mueva del almacenamiento SAS al SATA (basta con un enlace simbólico). Los ficheros de los arquitectos tendrán una política similar, pero con una persistencia de 15 días.
A su vez, si un fichero .doc o .xls que está en SATA es accedido por más de 5 usuarios en menos de 8 horas, se ha de mover al almacenamiento SAS, ajustando el enlace simbólico.
Esta política es fácilmente configurable con un par de scripts en el cron, pero se podría emplear un software específico si la complejidad creciese.
De esta forma, con la política definida, los ficheros que se usen con poca frecuencia y los backups estarán en el almacenamiento SATA, que es más barato y con mayor capacidad, mientras que los ficheros con mayor uso/concurrencia estarán en el almacenamiento SAS, más pequeño pero con mayor rendimiento.
Una vez visto el ejemplo (que repito, es un ejemplo didáctico y simplificado), mi recomendación respecto a la gestión del almacenamiento es que hay que dejarse asesorar. Que alguien con experiencia nos ayude a la definición e implantación de una política adecuada nos puede hacer ahorar una importante cantidad de dinero, y hará que nuestros datos estén accesibles y protegidos.
[ 4 comentarios ] ( 3519 visualizaciones ) | [ 0 trackbacks ] | enlace permanente |
( 3 / 564 )
