La E/S en Flash (parte 2)

La tecnología de almacenamiento en estado sólido ya está presente de alguna u otra manera en todos los datacenters. No obstante, cuando acabes de leer este post y pongas en balance lo bueno, lo feo y lo malo de la tecnología en sí, te darás cuenta enseguida de que para poder extraer todo el potencial que ofrece la tecnología se hacen necesarios un conjuntos de mecanismos específicos para la gestión y el control de la misma.

Lo bueno: tiempo de respuesta (latencia) muy corto, bajo consumo eléctrico, elevada densidad con relación al tamaño, excelente bajo patrones de E/S aleatorios (especialmente en lecturas).

Lo feo: Las operaciones de borrado son lentas (unos 5 mili-segundos), se produce un desgaste con el tiempo que limita la vida de las páginas, las tecnologías utilizadas para aumentar la densidad a la vez que garantizan la fiabilidad parecen hacer a la tecnología mas lenta (generación SLC vs MLC).

Lo malo: Las operaciones de escritura bloquean a las de lectura, las operaciones de borrado bloquean a las de lectura y a las de escritura, y además no es posible sobre-escribir directamente las páginas.

Además:

• Las operaciones de escritura en flash son entre 5 y 10 veces mas lentas que las de lectura (ejemplo para SLC: 60μs en lecturas frente a 250μs en escrituras; ejemplo para MLC: 100μs en lecturas frente a 500μs en escrituras; ejemplo para eMLC: 100μs en lecturas frente a 1200μs en escrituras).

• Las operaciones de borrado en flash son entre 30 y 50 veces mas lentas que las de lectura (ejemplo para SLC: 60μs en lecturas frente a 1.000μs en borrado; ejemplo para MLC: 100μs en lecturas frente a 3.000μs en borrado; ejemplo para eMLC: 100μs en lecturas frente a 5.500μs en borrado).

• Por defecto, el desgaste no ocurre de manera uniforme debido al modo de acceso, de hecho en flash existe una capa denominada FTL (Flash Translation Layer) que se encarga de mapear los bloques lógicos presentados por el dispositivo a la capa software (sistema operativo) con los bloques físicos en el propio dispositivo flash. Suele ocurrir también sobre todo con datos estáticos que no cambian o se re-ubican (por ejemplo, los binarios de un sistema operativo o una aplicación suelen mantener el mismo LBA). La capa control del dispositivo flash ha de implementar una serie de algoritmos y mecanismos que no solo distribuyan las escrituras provenientes de la capa software a través de todas las celdas para aprovechar la durabilidad máxima de cada una de éstas y prolongar la vida del dispositivo, sino que además traten casos como el del dato estático y sean capaces de mover estos LBAs estáticos hacia otros PBAs en función del nivelado de escrituras óptimo. Esto se suele conocer como wear leveling.

• El modo de acceso y escritura del dato en flash provoca otra necesidad sustancial: la gestión y reciclado de páginas inválidas dentro de un bloque físico, esto se suele conocer como garbage collection (GC a partir de ahora), y me imagino que de algún u otro modo sonará bastante ya que no es nada nuevo, se lleva utilizando desde hace décadas para la gestión de la memoria física (evitaba procesos manuales que había que lanzar tras la ejecución de pesados programas en super y mini computadores en las décadas de los 60/70) y lógica (que le pregunten a cualquier programador de Java o .Net). Según lo expuesto en mis anteriores entradas del blog (la tecnología NAND requiere el borrado previo a la escritura), este mecanismo se encarga de reclamar de manera automática y transparente aquellas páginas que contienen datos inválidos como consecuencia de sobre-escrituras lógicas fundamentalmente para que éstas puedan volverse a utilizar (por ejemplo, se ha producido una sobre-escritura de un LBA y los nuevos datos pasan a otro PBA quedando el PBA anterior marcado como inválido). Al igual que con Java (algunos lo habremos sufrido alguna vez), los mecanismos de GC tienen un papel fundamental en tecnología flash ya que de ellos va a depender en buen manera el desempeño y rendimiento del dispositivo flash.

• El diseño de los algoritmos de GC junto con los mecanismos de protección de la información en sistemas de almacenamiento centralizado tienen también una relación directa con la aparición de efectos colaterales (a parte de sobre-consumo de recursos de CPU y aumento de interrupciones) donde quizá uno de los más importantes sea la amplificación de escrituras: se borra a nivel de bloque pero suele ocurrir que en el mismo bloque tengo páginas válidas y páginas que puedo reclamar, por lo que ello me obliga a leer las páginas válidas y escribirlas a un bloque nuevo disponible (borrado previamente) para poder borrar el anterior…si el algoritmo de GC no es muy eficiente puede acabar con la vida y el rendimiento del dispositivo flash sobre el que actúa (lo mismo puede ocurrirte en una VM de Java). Además, si pensamos en almacenamiento empresarial centralizado, es decir, el típico array o cabina de discos donde los discos rotacionales se han sustituído por SSDs, el uso de niveles RAID convencionales (RAID-1, RAID-5, RAID-6, etc.) no hace sino aumentar el problema de la amplificación de las escrituras: solo basta pensar en una sobre-escritura de un stripe en un RAID-5 donde llega un dato nuevo (segmento, bloque, etc.) y tengo que leer el resto de la banda para re-calcular la nueva paridad, escribir en nuevo dato y la nueva paridad; es decir, una única modificación o sobre-escritura me provoca una lectura del stripe completa y dos escrituras (algo no muy deseable para la tecnología flash).