La historia de la división de arreglos

Gran parte del conocimiento memorístico del campo de la TI, especialmente del ámbito de las pymes, surgió a finales de la década de 1990 a raíz de diversos factores. Los factores más importantes fueron que, de repente, empresas cada vez más pequeñas se apresuraban a informatizarse, que Microsoft había logrado que Windows NT 4 fuera tan estable que existía una base estándar en torno a la cual toda la TI de las pymes podía girar, que la era de Internet por fin se había afianzado y que Microsoft introdujo sus programas de certificación y formación, que remodelaron la difusión del conocimiento en el sector. En conjunto, esto creó tanto la necesidad de nueva formación y buenas prácticas como un enorme estallido de nuevas ideas, escritos, documentación, formación, buenas prácticas, reglas generales, etc.

Durante unos pocos años, casi todo el sector se formó con el mismo y reducido conjunto de conocimientos, y muchas reglas generales se convirtieron en estándares de facto; gran parte del conocimiento de la época se aprendió de memoria y se transmitió de mentor a aprendiz en un ciclo que trasladó buena parte del conocimiento técnico de 1998 a los procesos incuestionados e inamovibles de 2012. En su momento esto fue eficaz porque las prácticas eran pertinentes, pero de eso hace quince años; la tecnología, la economía, los casos de uso y el conocimiento han cambiado significativamente desde entonces.

Uno de los mejores ejemplos de esto fue la célebre recomendación de Microsoft para SQL Server de RAID 1 para el sistema operativo, RAID 5 para los archivos de la base de datos y otro RAID 1 para los registros. Esta configuración ha perdurado durante prácticamente toda la vida del producto y se promovió tan bien que se ha extendido a casi todos los aspectos del diseño de servidores en el ámbito de las pymes. El uso de RAID 1 para el sistema operativo y RAID 5 para los datos está tan extendido que a menudo se asume sin más, sin ninguna consideración sobre por qué se recomendó en su momento.

Investiguemos la historia y veamos por qué R1/5/1 era bueno en 1998 y por qué no debería existir hoy. Tenga presente cierta perspectiva: la brecha entre el momento en que aparecieron por primera vez estas recomendaciones (ya en 1995) en comparación con la actualidad es inmensa. Retroceda, mentalmente, a 1995 y piense en la brecha equivalente de aquel entonces. Habría sido como utilizar recomendaciones de los albores de la era de Internet basadas en las necesidades de informática doméstica de la primera hornada de propietarios del Apple ][. La era de los ordenadores domésticos de 8 bits apenas estaba comenzando en 1978. A Commodore aún le faltaban dos años para lanzar su primer ordenador doméstico (el VIC=20) y atravesaría por completo las eras de Commodore y Commodore Amiga, quebraría y desaparecería todo ello antes de 1995. Al Apple ][+ aún le faltaba un año. La gente estaba a punto de empezar a usar unidades de casete analógicas como almacenamiento. COBOL y Fortran eran los únicos lenguajes empresariales de uso serio. Básicamente, la brecha es increíble. Las cosas cambian.

Primero, necesitamos examinar los factores que existían a finales de la década de 1990 y que crearon la necesidad de nuestra configuración histórica.

1. Las unidades eran pequeñas, muy pequeñas. Un arreglo de base de datos grande podía estar compuesto por cuatro unidades SCSI de 2,1 GB en un arreglo R5 para apenas ~6 GB de espacio de almacenamiento utilizable en un único arreglo. El dominio de fallo para el fallo de un RAID por paridad era diminuto (en comparación con cosas como las tasas de fallo por URE).
2. Las tecnologías de conexión de las unidades eran paralelas y lentas. Los discos duros de la época eran solo ligeramente más lentos que las unidades actuales, pero las tecnologías de conexión representaban un cuello de botella considerable. Era habitual repartir el tráfico para reducir los cuellos de botella del bus.
3. La tecnología de unidades SCSI era la única que se utilizaba en servidores. El uso de un PATA (en aquel momento se llamaba IDE) en un servidor era impensable.
4. Las unidades eran caras por gigabyte, por lo que el ahorro de costes era la cuestión clave, manteniendo a la vez la capacidad, prácticamente para todas las empresas.
5. Los sistemas de archivos eran frágiles y fallaban con más frecuencia que las unidades.
6. El RAID por hardware era obligatorio y solo había disponibles habitualmente los niveles básicos de RAID 1 y 5. Al RAID 6 y al RAID 10 aún les faltaban años para estar al alcance de la mayoría de las empresas. El RAID 0 queda descartado, ya que no tiene redundancia.
7. Los sistemas de almacenamiento rara vez, o nunca, se compartían entre servidores, por lo que el acceso casi siempre estaba dedicado a una única cola de solicitudes.
8. Las cachés de almacenamiento eran diminutas o no existían, lo que hacía que las limitaciones de acceso a las unidades se trasladaran directamente al sistema operativo. Esto significaba tener diferentes arreglos con distintas características para gestionar diferentes combinaciones de acceso de lectura/escritura o aleatorio/secuencial.
9. El fallo de las unidades era común y la principal preocupación del diseño de sistemas de almacenamiento.
10. A menudo el tamaño del arreglo de unidades estaba limitado por restricciones físicas, por lo que con frecuencia las decisiones de división de arreglos se tomaban por necesidad, no por elección.
11. La combinación de los factores anteriores significaba que RAID 1 era mejor para algunas partes del sistema donde un tamaño pequeño era aceptable y el acceso era altamente secuencial o intensivo en escritura, y RAID 5 era mejor para otras donde la capacidad pesaba más que la fiabilidad y donde el acceso era altamente aleatorio e intensivo en lectura.

En las casi dos décadas transcurridas desde que se publicaron las recomendaciones originales, todos estos factores han cambiado. En algunos casos los cambios son en cascada, en los que el paso del uso general de RAID 5 al uso general de RAID 10 provoca entonces que lo que habrían sido los dos tipos de arreglo comunes, RAID 1 y RAID 10, compartan características de acceso, de modo que la necesidad o el deseo de usar uno u otro según el tipo de carga desaparece.

1. Las unidades son ahora enormes. En lugar de esforzarnos por encajar lo que necesitamos en ellas, generalmente disponemos de capacidad de sobra. Las unidades individuales de más de un terabyte son comunes, incluso en servidores. Los dominios de fallo para la paridad son enormes (en comparación con cosas como las tasas de fallo por URE).
2. Las conexiones de las unidades son seriales y rápidas. Las conexiones de las unidades ya no son un cuello de botella.
3. SATA es ahora común en los servidores, lo que sesga los posibles riesgos de URE de una manera que no existía anteriormente.
4. La capacidad es ahora barata, pero el rendimiento y la fiabilidad son ahora las preocupaciones clave del dinero invertido.
5. Los sistemas de archivos son hoy altamente robustos y los fallos de los sistemas de archivos son “ruido de fondo” en el panorama general de la fiabilidad de los arreglos.
6. El RAID por hardware y el RAID por software son hoy ambas opciones, y los niveles de RAID disponibles incluyen muchas alternativas pero, lo más importante, RAID 10 está disponible de forma ubicua.
7. Los sistemas de almacenamiento se comparten habitualmente, lo que hace que el acceso secuencial sea aún menos común.
8. Las cachés de almacenamiento son comunes y a menudo muy grandes. Las cachés de 512 MB y 1 GB se consideran normales hoy en día, lo que hace que muchos arreglos de 1995 quepan hoy por completo en la memoria de la controladora RAID. Con las cachés creciendo rápidamente en comparación con la capacidad de almacenamiento y la reciente incorporación de las unidades de estado sólido como caché L2 en el almacenamiento en los últimos dos años, no es descabellado que incluso una pequeña empresa tenga bases de datos y otras aplicaciones sensibles al rendimiento ejecutándose por completo desde la caché.
9. El fallo de las unidades es poco común y de preocupación trivial para el diseño de sistemas de almacenamiento (en comparación con otros tipos de fallo).
10. El tamaño del arreglo de unidades rara vez está limitado por restricciones físicas.
11. El uso de RAID 1 y RAID 10 como los tipos de arreglo principales hoy en día significa que no hay ningún beneficio en usar diferentes niveles de arreglo para el ajuste del rendimiento.

Estos factores ponen de relieve por qué el sistema de arreglos divididos de 1995 tenía todo el sentido del mundo en su momento y por qué no tiene sentido hoy. OBR10, el estándar actual, no estaba disponible en aquel entonces y resultaba prohibitivo por su coste. El RAID 5 era relativamente seguro en 1995, pero no hoy. Prácticamente todos los factores implicados en el proceso de decisión han cambiado drásticamente en los últimos diecisiete años y van a seguir cambiando a medida que los SSD se vuelvan más comunes junto con la organización automática por niveles, cachés aún mayores y sistemas de almacenamiento de SSD puros.

El cambio en el diseño del almacenamiento a lo largo de las últimas dos décadas también pone de relieve los peligros a los que se enfrenta la TI, ya que una gran parte del sector aprende, como es habitual en ingeniería, “reglas generales” o “buenas prácticas” básicas sin comprender necesariamente los principios subyacentes que impulsan esas decisiones, lo que dificulta saber cuándo no aplicar esas buenas prácticas o, lo que es aún más importante, reconocer cuándo la regla ya no es válida. A diferencia de la ingeniería mecánica o civil tradicional, donde nuevos avances y cambios significativos de factores pueden producirse una vez o posiblemente nunca a lo largo de una carrera, la TI todavía cambia con la suficiente rapidez como para que sea necesario un “replanteamiento” completo de las reglas generales básicas varias veces a lo largo de una carrera. Quizás no anualmente, pero una vez por década o más es casi siempre necesario.

El cambio actual del monoprocesamiento a las arquitecturas multihilo es otro cambio similar y significativo que exige que el campo de la TI cambie por completo la manera en que se aborda el diseño de sistemas.