En tiempos de crisis describimos los puntos clave para diseñar una SAN de bajo coste.
iSCSI es una alternativa a la clásica SAN de fibra óptica, siendo económica su implementación ya que no requiere de una infraestructura y tecnología adiccional Hardware de costosas HBAs y Switches de Fibra. Con sólo un switch ethernet ( o dos que aporten redundancia de acceso) y con un servidor con tarjetas Ethernet de Gigabit junto con unos discos ya tendrías una SAN. Los initiators y targets iSCSI en muchos sistemas vienen con la distribución, al igual que las soluciones de multicamino (multipath).
Existen otras alternativas a iSCSI también basadas en Ethernet como AoE (ATA over Ethernet) que al eliminar una capa de encapsulación de frames (IP) da mayor rendimiento.
Esquema de SAN iSCSI
En la actualidad se diponen discos de buen precio y alta capacidad para una solución de bajo TIER. Un ejemplo podría ser 4 discos SATA de 3Gb/s , capacidad 2 TB, 64 MB de Caché y 7200 rpm con un total aproximado de 500€. Proporcionando aproximadamente unos 6 TB en RAID software con MDADM (solución de servidores Linux de RAID software) , que nos da una media de 111 euros por Tera tolerante a fallo (RAID).
Preguntadle a vuestro proveedor de SAN cuanto saldría una amplación de los TB en fibra … 
Aunque no es comparable una cabina de discos en fibra en cuanto a rendimiento debido a sus fenomenales características Hardware (tarjetas de fibra operando en modo target y procesadores dedicados, memoria caché del frontend y backend de los discos, …). Además sus discos tienen un rendimiento mayor, 15.000 rpm frente a los 7200 rpm que tienen los discos SATA, comparativamente pueden duplicar las I/Os y mejoras como gestión de colas o DIF T10. Según la necesidad de las aplicaciones del uso intensivo de disco podría ser adecuada una solución de bajo TIER.
La tecnología RAID Hardware dejó de ser hace años exclusiva de entornos enterprise y cualquier placa de PC lleva integrado una controladora de discos SATA con soporte de RAID 0,1,5. Por otro lado los resultados del RAID por software (MDADM, ZFS, …) y los gestores de volúmenes (Logical Volumen Manager – LVM ,Solaris Volumen Manager – SVM ,Veritas Volume Manager – VxVM, ZFS, …) demuestran ser alternativa eficaz que complementan de forma segura y hacen flexible cualquier cambio posterior en el almacenamiento.
Una solución SAN en iSCSI necesitaría de un switch ethernet para conectar los Initiator/s con los Target/s. Un diseño en SAN de fibra típico sería redundar HBAs y Switches de fibra proporcionando multicamino (multipah) al sistema eliminando puntos de fallo, se conseguiría de esta forma prevenir de cualquier fallo Hardware la continuidad de acceso a los discos. Esta tolerancia a fallos también es posible realizarse por analogía en iSCSI, redundando tarjetas y switches ethernet, acompañado de un software multipath propio de la distribución o usando nativamente el multipath iSCSI.
Cualquier sistema UNIX/Linux dispone de soporte para protocolos fibra e iSCSI y combinar con cualquier protocolo de compartición de ficheros como SMB o NFS. Ésto nos permitiría crear un servidor que centraliza el almacenamiento en el CPD redireccionándolo a ethernet sobre protocolos de bloques (iSCSI) o de ficheros (SMB,NFS).
También existen soluciones enterprise con esta funcionalidad basadas en software abierto tales como NexentaStor, OpenFiler o FreeNAS.
- Sistemas de Ficheros con reservas
El acceso de diferentes servidores a los mismos volúmes (típico en clústeres) necesitan tener un control de acceso y reservas de forma que haya coherencia en las modificaciones en el sistema de ficheros. Ésto se puede conseguir eligiendo un sistema de ficheros de tipo disco compartido (Share Disk File System) como GFS (REDHAT) o VMFS (VMWARE).
- Controladoras Activo/Activo Activo/Pasivo
Soluciones software tipo IET en servidores linux sobre las tarjetas ethernet del servidor como Enterprise Target iSCSI proporcionará un comportamiento análogo al típico de las controladoras de cabinas de discos en fibra.
El tema más delicado ya que el soporte SAN va en función de la interoperabilidad entre fabricantes destacando los elementos siguientes:
Sistema Operativo – Multipath – HBA-Drivers – Switch – Almacenamiento – Modos del multipath
Y debido a que el diseño de cada elemento en su totalidad no se ajusta a los mismos estándares se necesita una certificación previa entre diferentes fabricantes.
Esta situación cambia bastante en un entorno iSCSI siendo un protocolo/estandar bien definido con una implementación precisa, que crea un marco de interoperatibidad mucho mayor.
Aún así, hablamos de la infrestructura que contiene los datos de una empresa, y si algo en su CPD debe de tener soporte es este almacén de datos. Por lo que el final de este diseño propuesto puede variar bastante si no se quiere contratar soporte … incluyento por ejemplo soluciones de backup, Alta disponibilidad (HA) con replicación síncrona entre dos cabinas de discos, … todo un tema a desarrollar y cuya implementación en producción es aconsejable que deba superar toda una fase de testeo intensivo y planes robustos de contingencia.
Lo aconsejable es buscar soporte en alguna solución tipo Openfiler, siendo una de las soluciones más flexibles que cumple los puntos propuestod … aunque no olvidar que hay que mirar la interoperabilidad con lupa y como ejemplo VMWARE no la certifica para sus servidores ESX.
Por otro lado si se elige una implementación de un target iSCSI sobre un sistema operativo, ésta solución no tiene porqué dejar de ser soportada por la distribución, ejemplo de ellos son: RHEL que incluye desde la versión 5.3 soporte para esta característica integrando SCSI Target Framework proyecto integrado en la linea principal de desarrollo del Kernel y mantenido por el creador de IET u OpenSolaris/Solaris Express 11 con el proyecto COMSTAR.
En Almacenamiento Abierto hemos diseñado cabinas de discos para entornos de producción con las siguientes características:
Ubuntu Server / SCST / LVM2 / MDADM (RAID 5) / HOT SPARE / ESX/ESXi 4/ MULTIPATH Nativo iSCSI/ SATA
Su aplicación para entornos de producción es un punto de interés fuerte por eso le hemos dedicado una serie de artículos sobre el proyecto SCST.
Si estás interesado en una implementación de targets SCST de bajo Tier certificado para VMWARE u otro entorno quizás te podamos ayudar, o si ya has implementado una o estás en en el proceso, nos gustaría conocer tu experiencia.
Ingeniero Superior en Electrónica que trabaja en la actualidad como Analista de Sistemas. Se especializa en Sistemas SAN, Almacenamiento y Backup en base a su experiencia en los sistemas informáticos de grandes cuentas.
Escribe en la actualidad en web especializada de almacenamiento sobre soluciones de código abierto.
cintas del fabricante Oracle en sus modelos Storagetek SL8500, SL3000 y SL500 Modular Library System pueden ser monitorizados vía SNMP. A través de su agente SNMP está certificada su integración con la herramienta de monitorización HP OpenView y mediante checks de consultas podría integrarse en Nagios.
tendida. La calidad del software de gestión automática de backup y recuperación de desastres se ha convertido en un amortiguador de migración de soportes. Con la reciente aparición de soluciones tipo 
d de la copia y restauración. Éste modelo híbrido en una solución ideal, implementándose desde hace tiempo con éxito en muchos centros de datos, ejemplo de ello son las 
