Questo post è anche disponibile in italiano
En este post veremos uno de los temas más interesantes de la tecnología flash; como funciona un “disco” flash. Es importante conocer estos aspectos ya que esto nos dará inmediatamente una idea clara de porqué la tecnología flash es completamente distinta de la tecnología “tradicional”, que llamaremos discos mecánicos, y sobre todo será útil para entender porqué utilizar un disco flash en una arquitectura tradicional, o sea en un storage que NO ha sido pensado para usar discos flash no es la mejor solución.
Comencemos entonces con el primer punto; como funciona un disco flash.
Podemos imaginar un disco flash como un conjunto de celdas, donde hay filas y columnas, más o menos como una hoja de cálculo Excel.
En este esquema, cada celda es cargada electrónicamente y dependiendo del tipo, SLC (Single Level Cell) o MLC (Multi Level Cell) es posible memorizar respectivamente 2 valores (0,1) para el tipo SLC o 4 valores (0,1,2,3) para el tipo MLC.
Como los valores son memorizados en un estructura parecida a una planilla de cálculo, el acceso di tipo random es perfecto para esta tecnología. Es posible acceder a cualquier celda con la misma latencia.
Ahora un punto importante; mientras acceder en lectura no es problema y puede hacerse siempre con la misma latencia, el proceso de escritura es algo completamente distinto porque: 1) No es posible escribir directamente en una celda, mejor dicho, no es posible escribir un dato si la celda contiene ya un valor y 2) no es posible escribir una sola celda a la vez, es necesario escribir grupos de celdas, normalmente 64K o 128K por vez. Llamaremos a este grupo de celdas una página.
Las dificultades de reescribir (“overwriting”): imaginemos que deseamos escribir un dato sobre una página que está vacía, ahora no hay ningún problema, los datos llegarán al disco y podremos escribir esta página en una sola operación.
Imaginemos en vez que no hay espacio “contiguo” para escribir el dato, en este caso será necesario leer y mover a “alguna otra parte» (memoria) los datos existentes de la página que se va a reescribir, borrar los datos de la página, disponer los datos en la memoria interna del storage y finalmente escribir la página entera.
El siguiente grafico muestra como seria este proceso, llamado P/E (Program/Erasure)
El proceso de P/E puede ser considerado una parte integrante de la actividad de Garbage Collection (GC), o sea, la actividad que todos los discos flash deben hacer para crear espacio antes de poder escribir. La GC es un aspecto fundamental de la tecnología flash porque influencia directamente el RT, durante la GC el RT normalmente disminuye porque el sistema debe dedicar recursos para crear espacio.
Siendo la GC un proceso que impacta el rendimiento del array, que es posible hacer para minimizar este impacto? Veamos algunas posibles soluciones.
GC a nivel del sistema operativo del array: Casi todos los array de tipo Flash (AFA – All Flash-Array) utilizan esta metodología. Hacer la GC a nivel del SO del array presenta algunas desventajas. Por ejemplo, puede suceder que el array este trabajando con un cierto RT y a un cierto punto comienza la actividad de GC. Dado que hacer la GC es la prioridad número 1 (no sería posible escribir nuevos datos y el sistema no podría continuar a funcionar), durante la GC el RT inevitablemente disminuye.
GC a nivel de los controllers de los discos flash: En general los discos flash pueden hacer una GC más efectiva a nivel de los controllers de los mismos discos, es decir, es posible demandar a los discos flash el proceso de GC. Nadie conoce mejor como hacerlo que el propio fabricante de los discos. Es más, la arquitectura de muchos array AFA tienen solo dos controllers de Front-end (la parte dedicada a hacer I/O hacia los servidores), con un número limitado de potencia computacional que es mejor no tener que dedicar para hacer el trabajo de la GC.
Comparemos esto con la potencia computacional presente de todos los controllers de todos los discos flash del sistema. Consideremos también que los controllers de front-end deben además hacerse cargo de toda una serie de funciones, copia de los datos, monitoring del sistema, etc. Es claro que una técnica basada en el manejo de la GC a nivel de los controllers de los discos es más eficiente. Este es el método utilizado por XtremIO.
El punto principal de tener siempre en mente es el siguiente: todos los discos flash son veloces, cuando pensamos a un array con discos flash asumimos que tendrá un alto rendimiento (performance). Sin embargo, la característica principal de un array AFA no es el rendimiento, la característica principal, o al menos la que más deberíamos considerar es la capacidad del array de poder mantener un bajo y constante RT en el tiempo.
Porqué un bajo y sobre todo constante RT es tan importante? Pensemos a que estamos desarrollando un proyecto (DB, custom application, etc) en un array flash nuevo (apenas comprado), donde hay mucho espacio a disposición. Después de varias pruebas vemos que para ejecutar un trabajo son necesarios digamos 3 horas. Digamos que este es un valor excepcional cuando comparamos el mismo trabajo en un array tradicional que usa discos “mecánicos”. Seguramente desearíamos que el trabajo que hoy, cuando lo probamos duraba 3 horas, dentro de un tiempo, cuando el array empezará a tener más datos, dure también 3 horas. Esto, desgraciadamente, por efecto de la GC en un array proyectado para hacer la GC a nivel de los controllers de front-end no sucederá. Apenas comenzará el proceso de GC el RT disminuirá notablemente. El proceso de GC no puede ser detenido o posticipado. Es la prioridad número 1 para permitir al array de continuar a funcionar. Este fenómeno puede presentarse varias veces en el mismo día y seguramente empezará apenas las celdas del array serán todos escritas.
Podríamos pensar que para evitar el proceso de GG bastaría no llenar nunca el array, o sea utilizar el array digamos un 50% o 70% ocupado. En realidad, la tecnología flash trabaja en un modo diferente haciendo en modo que “todas” las celdas de “todos” los discos sean escritas en el modo más uniforme posible. Si nuestro array es de 10TB y creamos una LUN de 1TB no escribiremos solo sobre este espacio, escribiremos 1TB de datos, pero estos datos serán distribuidos sobre la capacidad total del array, en nuestro caso sobre los 10TB. Porqué esto es así?
P/E y escrituras uniformes: Al principio de este post dijimos que no es posible escribir un bloque de celdas directamente si este bloque contiene ya datos, es necesario antes que nada borrar los datos antes de reescribir. Nos referimos a este proceso como ciclos P/E (Program/Erasure).
Ahora bien, según el tipo de disco, el número de ciclos de P/E es un valor pre-determinado, de algunas miles de veces, 3000 ciclos para los discos flash de tipo “consumer” llamados también cMLC (consumer multi level cell), utilizados por muchos vendors, o 30.000 ciclos de P/E para un disco de tipo eMLC (enterprise multi level cell), utilizados en XtremIO. Cualquier aplicación es en grado de hacer miles de I/Os por segundo, y de ser así, un disco flash duraría muy poco si escribiéramos el mismo dato sobre la misma celda tantas veces. Para minimizar este efecto, los discos flash utilizan un sistema de “over-provisioning” interno, es decir, presentan una capacidad lógica al host diferente (menor) de la verdadera capacidad física. Este over-provisioning o nivel de virtualización es usado internamente por los discos flash para “dirigir”, en la medida de lo posible, las escrituras siempre sobre celdas diferentes en TODO el array y utilizando TODOS los discos del array independientemente de que nuestro array sea de 10TB y nuestra LUN sea de 1TB o 10GB.
Numerosos documentos describen la importancia de estas consideraciones. En particular los siguientes documentos describen detalladamente como efectuar un test de un flash array.
IDC White Paper:
AFA Performance Testing Framework
XtremIO mantiene el RT constante en el tiempo
Concluyendo: Si bien todos los array que utilizan discos flash pueden tener óptimos rendimientos, el aspecto principal de tener en consideración es el de un RT bajo y constante en el tiempo. Es el Response Time el valor fundamental que nos permite hacer más trabajo en menos tiempo y sobre todo, un RT constante nos permite planificar adecuadamente que nuestras aplicaciones serán veloces hoy y lo serán en el tiempo.
Para mayor información:
What is a Flash Technology. EMC Glossary
