DAS, NAS y SAN

Un servidor puede tener el disco dentro, colgado de la red normal o colgado de una red dedicada solo a almacenamiento. Esas tres respuestas son las tres arquitecturas que se preguntan, y la diferencia entre ellas no es de capacidad sino de quién manda sobre el sistema de ficheros y por dónde circulan los datos.

La consecuencia práctica se ve en el uso. El DAS es sencillo y barato, pero su capacidad solo la aprovecha ese servidor y no se puede reasignar: si sobran dos teras en una máquina y faltan en la de al lado, no hay nada que hacer. El NAS es la forma natural de compartir documentos entre muchos equipos y personas. La SAN es lo que se monta cuando varios servidores necesitan acceder a un almacenamiento común y rápido, que es exactamente el requisito de una base de datos en clúster como Oracle RAC.

En DAS y SAN el servidor recibe discos y pone él el sistema de ficheros. En NAS recibe carpetas ya formateadas y el sistema de ficheros lo lleva el propio NAS.

La distinción anterior se puede formular con una sola pregunta, que es la que hay que llevar aprendida: ¿qué unidad se pide por la red, un bloque o un fichero?

• Acceso a bloque: el cliente pide «dame el bloque número tal» y el almacenamiento se lo da sin saber qué contiene. Es lo que hacen DAS y SAN. Como el sistema de ficheros lo pone el servidor, cualquier cosa que necesite control fino sobre la escritura (una base de datos, una máquina virtual, un sistema de arranque) funciona bien aquí.
• Acceso a fichero: el cliente pide «dame el fichero tal de la carpeta cual» y el almacenamiento, que sí entiende de ficheros, se lo entrega. Es lo que hace un NAS. Es cómodo para compartir entre muchos usuarios y añade una capa de proceso que no siempre conviene a una base de datos.

Hay una tercera forma que aparece en las plataformas de nube y conviene reconocer: el almacenamiento en modo objeto, donde no hay ni bloques ni jerarquía de carpetas, sino objetos identificados por una clave y consultados por una interfaz web. Se usa para archivo, copias y contenido estático, no para el disco de trabajo de un servidor.

Bloque para lo que necesita controlar la escritura, como una base de datos o una máquina virtual. Fichero para lo que hay que compartir entre personas y equipos.

Cada tipo de acceso tiene su familia de protocolos, y saber cuál va con cuál es la manera rápida de resolver una pregunta que mezcle los nombres.

Con CIFS conviene precisar, porque los apuntes lo ponen al lado de NFS como si fuera un protocolo distinto y vigente. CIFS es el nombre que recibió una versión antigua del protocolo de compartición de Windows; hoy se llama SMB y las versiones en uso son SMB2 y SMB3. En una pregunta, CIFS y SMB apuntan al mismo sitio: compartición de ficheros de Windows.

La otra sigla imprescindible es LUN, unidad lógica. Una cabina no entrega discos físicos: entrega unidades lógicas talladas sobre el conjunto de discos que tiene por dentro, y cada servidor ve las LUN que se le hayan asignado como si fueran discos suyos. Quién ve qué LUN no es automático: se decide, y de eso trata un punto más adelante de este mismo subtema.

Por debajo de todos los protocolos de bloque hay un solo lenguaje, y saberlo evita muchos líos. Las órdenes que se le dan a un disco (lee este bloque, escribe este otro) son de la familia SCSI, y lo único que cambia entre tecnologías es cómo se empaquetan para viajar. En una SAN de fibra las transporta FCP, el protocolo de canal de fibra; en iSCSI viajan dentro de TCP/IP; y en FCoE, dentro de tramas Ethernet. Cambia el sobre, no la carta.

iSCSI y Fibre Channel transportan bloques; NFS y SMB transportan ficheros. Debajo de todos los de bloque van órdenes SCSI: solo cambia el encapsulado.

El equipo que guarda los datos en una SAN se llama cabina de discos, y también matriz de almacenamiento por su nombre inglés. Por dentro tiene bandejas de discos, una o varias controladoras redundantes, memoria caché y la lógica que talla las unidades lógicas; por fuera solo ofrece puertos. Ninguno de los servidores que la usan sabe cuántos discos hay dentro ni cómo están agrupados.

La consecuencia de montar una red dedicada solo al almacenamiento es que el servidor pasa a estar en DOS redes distintas, y por tanto necesita DOS tipos de tarjeta. Es una de las cosas que más se preguntan y también de las que más sorprenden a quien viene de servidores sencillos.

Sobre la tarjeta de fibra circula una afirmación falsa que conviene desmontar: que cada adaptador tiene un solo puerto. Los hay de uno, de dos y de cuatro puertos, y de hecho lo normal en producción es poner dos tarjetas de dos puertos precisamente para que no haya ningún camino único que pueda fallar. Cada puerto tiene identidad propia, como se ve en el punto siguiente.

El elemento que une servidores y cabinas es el conmutador, y ahí hay una decisión de coste. El conmutador de fibra es un equipo especializado, caro, con latencias muy bajas y prácticamente sin pérdida de tramas, que es lo que exige un protocolo de disco. El conmutador IP corriente es mucho más barato y es el que se aprovecha cuando se monta la SAN sobre iSCSI, a costa de una latencia mayor y de tener que separar el tráfico con esmero para que la red de almacenamiento no compita con la de usuarios. La regla práctica: fibra cuando manda el rendimiento, iSCSI sobre Ethernet cuando manda el presupuesto.

Un servidor de una SAN vive en dos redes: la Ethernet de datos con su tarjeta de red, y la de almacenamiento con su HBA de fibra.

En una red de almacenamiento no hay direcciones IP con las que identificar a nadie. Lo que hay es el nombre mundial, WWN, un identificador de 64 bits que el fabricante graba de origen y que es único en el mundo entero, igual que una dirección física de tarjeta de red lo es en Ethernet. De ahí salen dos siglas que se preguntan enfrentadas.

La consecuencia práctica es que todas las reglas de acceso de una SAN se escriben sobre estos identificadores, no sobre direcciones IP. Y como el nombre va grabado en la tarjeta y no en el servidor, cambiar un adaptador averiado obliga a repasar esas reglas: la máquina es la misma pero su identidad en la red de almacenamiento ha cambiado.

Con esos identificadores se aplican dos controles distintos, y separarlos bien es exactamente lo que suele decidir una pregunta de examen.

No son alternativas: son complementarios y se usan juntos. La zona aísla el tráfico en la red y reduce lo que cada equipo puede alcanzar; el enmascaramiento afina dentro de eso y evita el desastre clásico, que es que dos servidores no preparados para compartir escriban a la vez sobre la misma unidad y corrompan el sistema de ficheros. Un fallo de cualquiera de los dos deja al servidor sin disco o, peor, con un disco que no es suyo.

Las zonas se pueden definir de dos maneras: por nombre mundial, de modo que el equipo conserva su acceso aunque lo cambien de boca del conmutador, o por puerto del conmutador, de modo que el acceso lo hereda quien se conecte ahí. La primera es la habitual porque sigue al equipo; la segunda es más sencilla de mantener cuando lo que se quiere es que el cableado mande.

El zoning se configura en el conmutador y decide quién ve a quién en la red; el enmascaramiento se configura en la cabina y decide qué LUN ve cada servidor. Complementarios, no equivalentes.

Los discos de las máquinas virtuales de un entorno de virtualización no suelen estar dentro de los servidores anfitriones: están en la cabina y se sirven por la SAN. La razón es exactamente la que se ha ido construyendo en este subtema, y conviene tenerla clara porque une las dos mitades del enunciado oficial.

• El fichero de disco de una máquina virtual necesita acceso a bloque, no a fichero compartido, porque por encima va un sistema de ficheros completo que el invitado gestiona él mismo.
• Ese acceso lo tienen que tener VARIOS anfitriones a la vez sobre el mismo almacenamiento. Si el disco estuviera dentro de un servidor, solo ese servidor podría arrancar esa máquina.
• Cumplidas las dos condiciones, mover una máquina virtual de un anfitrión a otro deja de implicar copiar gigabytes: el disco no se mueve, solo se traslada la ejecución. Eso es lo que hace posible la migración en caliente y el reparto automático de carga.
• Y por el mismo motivo, si un anfitrión se avería, otro puede arrancar sus máquinas en cuestión de minutos, porque el disco sigue accesible desde la cabina.

El precio es que el almacenamiento se convierte en el punto único de fallo de todo el entorno virtual, y de ahí que las cabinas se monten con controladoras y caminos redundantes, y que se replique a un segundo emplazamiento cuando el servicio lo exige.

Un entorno virtualizado necesita acceso a bloque compartido entre anfitriones. Esa es la razón de que la SAN y la virtualización vayan casi siempre juntas.

Los niveles de RAID, cómo reparte cada uno los datos y la paridad y cómo se calcula la capacidad neta se estudian en el tema de periféricos. Lo que corresponde aquí es lo que un administrador decide y vigila, que es otra cosa.

La primera decisión es dónde se implementa. Un RAID por hardware lo hace una controladora dedicada, que presenta al sistema operativo un único volumen y se encarga de todo, incluida la memoria caché con batería que evita perder escrituras en un apagón. Un RAID por software lo hace el propio sistema operativo, sin hardware específico: sale gratis y es portable entre máquinas, pero consume procesador y no siempre puede arrancar desde el propio conjunto.

La segunda es qué pasa cuando un disco falla, que es el momento para el que existe todo lo anterior. El conjunto sigue funcionando pero queda degradado, y desde ese instante no tolera otro fallo. La reconstrucción sobre el disco de repuesto es una operación larga, que exige leer todos los demás discos enteros y que por tanto es justo cuando más probable resulta que aparezca un segundo fallo. De ahí dos prácticas de administración: tener un disco de reserva ya montado, que entra solo sin esperar a que alguien vaya al centro de datos, y vigilar activamente el estado del conjunto en lugar de enterarse cuando ya han caído dos.

Y la tercera es la advertencia que hay que tener siempre presente: un RAID no es una copia de seguridad. Protege del fallo físico de un disco y de nada más. Un borrado por error, una corrupción lógica, un cifrado por un ataque o un incendio afectan por igual a todos los discos del conjunto, porque el conjunto está escribiendo lo mismo en todos.

El RAID cubre el fallo de un disco. El borrado accidental, la corrupción y el desastre del edificio los cubre la política de copias, y ninguno de los dos sustituye al otro.