Discos de SO lentos, discos de datos rápidos

A lo largo de los años he descubierto que la gente a menudo se inclina por un almacenamiento de datos de alto rendimiento y alta fiabilidad para una partición de sistema operativo, pero elige un almacenamiento lento y “rentable” para almacenes de datos críticos. Me asombra con qué frecuencia encuentro que esto ocurre y ahora, con la llegada de los hipervisores, veo que el mismo comportamiento se repite también allí – agravando los problemas que ya existían.

En muchos sistemas hoy en día lidiamos con un único arreglo de almacenamiento compartido por todos los componentes del sistema. En estos casos no enfrentamos el problema de desequilibrar el rendimiento de nuestro sistema de almacenamiento. Esta es una de las grandes ventajas de este enfoque y una razón principal por la que se recomienda tan encarecidamente. Todo el rendimiento está en un grupo compartido y los componentes que necesitan el rendimiento tienen acceso a él.

En muchos casos, ya sea en un intento de mejorar el diseño de rendimiento o fiabilidad o por necesidad técnica, encuentro que la gente separa sus arreglos de almacenamiento y coloca los hipervisores y los sistemas operativos en un arreglo y los datos en otro. Pero lo que encuentro impactante es que los arreglos dedicados al hipervisor o al sistema operativo a menudo son asombrosamente grandes en capacidad y extremadamente altos en rendimiento – frecuentemente involucrando discos de 15.000 RPM o incluso unidades de estado sólido a un gran costo. Casi siempre en RAID 1 (según los estándares comunes de 1998).

Lo que hay que entender aquí es que los propios sistemas operativos no tienen prácticamente ningún requisito de E/S de almacenamiento. Hay una pequeña cantidad, principalmente para el registro del sistema, pero eso es más o menos todo lo que se necesita. Las particiones del sistema operativo son casi completamente estáticas. Los componentes necesarios se cargan en la memoria, principalmente en el momento del arranque, y no se vuelven a acceder. Incluso en los casos en que se necesita el registro, muchas veces estos registros se envían a un sistema de registro centralizado y no al área de almacenamiento del sistema, reduciendo o incluso eliminando también esa necesidad.

Con los hipervisores este efecto es aún más extremo. Como los hipervisores son mucho más ligeros y menos robustos que los sistemas operativos tradicionales, se comportan más como sistemas embebidos y, en muchos sentidos, en muchos casos realmente son sistemas embebidos. Los hipervisores se cargan en la memoria en el momento del arranque del sistema y casi nunca se necesita su medio de almacenamiento de nuevo mientras un sistema está en funcionamiento, excepto para el registro en algunas ocasiones. Debido a que los hipervisores son pequeños en tamaño físico, incluso el tiempo total necesario para leer por completo un hipervisor entero desde el almacenamiento es muy pequeño, incluso en medios muy lentos, porque el tamaño total es muy pequeño.

Por estas razones, el rendimiento del almacenamiento tiene poca o ninguna consecuencia para los sistemas operativos y, especialmente, para los hipervisores. La diferencia entre un almacenamiento rápido y uno lento realmente solo afecta al tiempo de arranque del sistema, donde la diferencia entre uno o treinta segundos rara vez se notaría, si es que se nota. ¿Cuándo percibiría alguien incluso varios segundos adicionales durante el inicio de un sistema y, en la mayoría de los casos, los inicios son eventos poco frecuentes que ocurren a lo sumo una vez por semana durante un reinicio automatizado y rutinario del sistema, dentro de una ventana de mantenimiento planificada o, muy rara vez, a veces solo una vez cada varios años, para sistemas que solo se desconectan en emergencias? Incluso el sistema de almacenamiento más lento concebible es mucho más rápido de lo necesario para este rol.

Incluso el almacenamiento lento es generalmente muchas veces más rápido de lo necesario para las actividades de registro del sistema. En esos raros casos en los que el registro es muy intenso, tenemos muchas opciones de cómo abordar este problema. La solución más obvia y común aquí es enviar los registros a un arreglo de discos distinto del que usa el sistema operativo o el hipervisor. Esta es una solución muy fácil y, en última instancia, muy práctica en los casos en que se justifica. La otra solución común y sumamente útil es simplemente abstenerse de mantener los registros en el dispositivo local y enviarlos a una utilidad remota de recolección de registros como Splunk, Loggly o ELK.

La otra preocupación importante que la mayoría de la gente tiene en torno a sus sistemas operativos e hipervisores es la fiabilidad. Es común concentrar más esfuerzos en proteger estos aspectos relativamente poco importantes de un sistema en lugar de los datos, que a menudo son irreemplazables. Sin embargo, los sistemas operativos y los hipervisores se reconstruyen fácilmente desde cero cuando es necesario, usando instalaciones nuevas y reconfiguración manual cuando hace falta. Los detalles que podrían perderse son, por lo general, relativamente triviales de recrear.

Esto no significa que estos sistemas de archivos del sistema no deban respaldarse; por supuesto que deben hacerlo (en la mayoría de los casos). Pero, por si los respaldos también fallan, es raro que la pérdida de una partición o sistema de archivos del SO realmente signifique una tragedia y no solo un inconveniente. Hay maneras de recuperarse en casi todos los casos sin acceso a los datos originales, siempre que el sistema de archivos de “datos” esté separado. Y debido a la naturaleza de los sistemas operativos y los hipervisores, el cambio es raro, por lo que los respaldos generalmente pueden ser menos frecuentes, ¡posiblemente activados manualmente solo cuando se aplican actualizaciones!

Con muchos sistemas modernos en los espacios de DevOps y computación en la nube, se ha vuelto muy común considerar los sistemas de archivos de los sistemas operativos e hipervisores como completamente desechables, ya que se definen de forma remota mediante una imagen de sistema o un sistema de gestión de configuración. En estos casos, que son cada vez más comunes, no hay necesidad de protección de datos ni de respaldos, ya que todo el sistema está diseñado para recrearse, casi al instante, sin ninguna interacción especial. El sistema es totalmente autorreplicante. Esto trivializa aún más la necesidad de proteger el sistema de archivos del sistema.

En conjunto, la falta de necesidad en torno al rendimiento y la falta de necesidad en torno a la protección y la fiabilidad, gestionadas principalmente mediante la simple recreación, nos dejan con un sistema de archivos del sistema con necesidades muy distintas de las que comúnmente asumimos. Esto no significa que debamos ser imprudentes con nuestro almacenamiento; todavía queremos evitar el fallo del almacenamiento mientras un sistema está en funcionamiento, y reconstruir innecesariamente es una pérdida de tiempo y recursos, incluso si no resulta ser desastroso. Por lo tanto, lograr un equilibrio cuidadoso es importante.

Es, por supuesto, por estas razones que incluir el sistema operativo o el hipervisor en el mismo arreglo de almacenamiento que los datos es ahora una práctica común – porque hay poca o ninguna necesidad de acceso al almacenamiento de los archivos del sistema al mismo tiempo que hay acceso a los archivos de datos, de modo que obtenemos una gran sinergia al conseguir tiempos de arranque rápidos para el SO y ningún impacto adverso en los tiempos de acceso a los datos una vez que el sistema está en línea. Este es el medio principal por el cual los diseñadores de sistemas hoy en día abordan la necesidad de un uso eficiente del almacenamiento.

Cuando el sistema operativo o el hipervisor deben separarse de los arreglos que contienen los datos, lo cual aún puede ocurrir por innumerables razones, generalmente buscamos obtener una fiabilidad razonable a bajo costo. Al usar almacenamiento tradicional (discos locales), esto significa usar discos giratorios pequeños, lentos y de bajo costo para el almacenamiento del sistema operativo, generalmente en una configuración RAID 1 simple. Un ejemplo del mundo real es el uso de discos SATA “ecológicos” de 5400 RPM en los tamaños más pequeños posibles. Estos consumen poca energía y son muy económicos de adquirir. Se evitarían los SSD y los discos SAS de alta velocidad, ya que cuestan un sobreprecio por una protección que es irrelevante y un rendimiento que se desperdicia por completo.

En el almacenamiento menos tradicional es común usar una SAN de bajo costo y alta densidad, consolidando el almacenamiento de baja prioridad de muchos sistemas en arreglos lentos y compartidos que no están replicados. Esto solo es eficaz en entornos más grandes que puedan justificar el diseño arquitectónico adicional y que puedan lograr suficiente densidad en el proceso de consolidación del almacenamiento para crear el ahorro de costos necesario, pero en entornos más grandes esto es relativamente fácil. Los dispositivos de arranque por SAN pueden aprovechar arreglos de muy bajo costo a través de muchos servidores para ahorrar costos. En el espacio virtual, esto podría significar un almacén de datos de bajo rendimiento usado para los discos virtuales del SO y otro grupo de alto rendimiento para los discos virtuales de datos. Esto tendría el mismo efecto que la estrategia de arranque por SAN, pero en un entorno más moderno, y podría aprovechar fácilmente la arquitectura SAN por debajo para lograrlo.

Finalmente, y de la manera más drástica, es una regla general con los hipervisores instalarlos en tarjetas SD o memorias USB en lugar de en almacenamiento tradicional, ya que sus necesidades de rendimiento y fiabilidad son mucho menores incluso que las de los sistemas operativos tradicionales. Normalmente, si un disco de esta naturaleza fallara mientras un sistema estuviera en funcionamiento, en realidad seguiría funcionando sin ningún problema, ya que el disco nunca se usa una vez que el sistema ha arrancado inicialmente. Solo sería durante un reinicio cuando se encontraría un problema y, en ese momento, podría usarse un dispositivo de arranque de respaldo, como una tarjeta SD o una memoria USB secundaria. Esta es la recomendación oficial para VMware vSphere, a menudo es recomendada por representantes de Microsoft para HyperV y está oficialmente soportada a través de los proveedores OEM de HyperV, y a menudo es recomendada, aunque no tan ampliamente soportada, para sistemas Xen, XenServer y KVM. Usar tarjetas SD o memorias USB para el almacenamiento del hipervisor convierte efectivamente un servidor de virtualización en un sistema embebido. Aunque esto pueda resultar antinatural para los administradores de sistemas que están acostumbrados a pensar en los discos tradicionales como una necesidad para los servidores, es importante recordar que los sistemas de clase empresarial y sumamente críticos, como los enrutadores y conmutadores, duran décadas y usan exactamente esta misma estrategia exactamente por las mismas razones.

Una estrategia común para los hipervisores en este modo de estilo embebido con tarjetas SD o memorias USB es tener dos de estos dispositivos, que en realidad pueden ser una tarjeta SD y una memoria USB, cada uno con una copia del hipervisor. Si un dispositivo falla, arrancar desde el segundo dispositivo es casi tan eficaz como un sistema RAID 1 tradicional. Pero a diferencia de la mayoría de las configuraciones RAID 1 tradicionales, también tenemos un medio relativamente fácil de probar las actualizaciones del sistema, actualizando solo un dispositivo de arranque a la vez y probando el proceso antes de actualizar el segundo dispositivo de arranque, lo que nos deja con un respaldo fiable y bien probado en caso de que una actualización de versión salga mal. Este proceso era en realidad común en los grandes sistemas UNIX RISC, donde los dispositivos de arranque solían ser conjuntos RAID 1 por software locales que soportaban una práctica similar, especialmente común en los círculos de AIX y Solaris.

También cabe señalar que, si bien este enfoque es la mejor práctica para la mayoría de los escenarios de hipervisor, en realidad no hay ninguna razón por la que no pueda aplicarse también a sistemas de archivos de sistemas operativos completos, salvo que a menudo es más trabajo. Algunos sistemas operativos, especialmente Linux y BSD, son muy hábiles para ser instalados de forma embebida y pueden adaptarse fácilmente para su instalación en tarjeta SD o memoria USB con un poco de planificación. Este enfoque no es para nada común, pero no hay ninguna razón técnica por la que, en las circunstancias adecuadas, no fuera un enfoque excelente, salvo por el hecho de que casi nunca debería instalarse un SO en hardware físico en lugar de sobre un hipervisor. En aquellos casos en que las instalaciones físicas son necesarias, este enfoque es sumamente válido.

Al diseñar y planificar sistemas de almacenamiento, recuerde estar atento a cómo se verán realmente los patrones de lectura y escritura cuando un sistema esté en funcionamiento. Y recuerde que el almacenamiento ha cambiado de manera bastante drástica desde que se desarrollaron muchas directrices tradicionales y que no todo el conocimiento utilizado para desarrollarlas todavía se aplica hoy o se aplica por igual. Piense no solo en qué subsistemas de almacenamiento intentarán usar el rendimiento del almacenamiento, sino también en cómo interactuarán entre sí (por ejemplo, ¿dos sistemas nunca solicitan acceso al almacenamiento al mismo tiempo o entrarán en conflicto con regularidad?) y en si el rendimiento de su acceso es importante o no. Las funciones generales del sistema operativo pueden ser extremadamente lentas en un servidor de base de datos sin impacto negativo; todo lo que importa es la velocidad a la que se puede acceder a una base de datos. Incluso el acceso a los binarios de las aplicaciones suele ser irrelevante ya que estos, también, una vez cargados en la memoria, permanecen allí y solo la velocidad de la memoria afecta el rendimiento continuo.

Nada de esto pretende sugerir que separar los subsistemas de almacenamiento del SO y de los datos entre sí sea recomendable; a menudo no lo es. He escrito en el pasado sobre cómo consolidar estos subsistemas es con bastante frecuencia el mejor curso de acción y eso sigue siendo cierto ahora. Pero también hay muchos casos razonables en los que separar ciertas necesidades de almacenamiento entre sí tiene sentido, a menudo cuando se trata de sistemas a gran escala donde podemos reducir el costo dedicando almacenamiento de alto costo a ciertas necesidades y almacenamiento de bajo costo a otras necesidades, y es en esos casos donde quiero demostrar que los sistemas operativos y los hipervisores deben considerarse la prioridad más baja en términos tanto de rendimiento como de fiabilidad, salvo en los casos más extremos.