Elementos básicos de la plataforma de virtualización de Flash (FVP), parte 2. Uso de su propia plataforma o sistema de archivos

Uno de los temas que discutí con Satyam y Murali Vilayannur fue el sistema de archivos que se utiliza para almacenar datos en dispositivos flash. Deben tenerse en cuenta los siguientes hechos notables: Satyam creó VMFS3, Murali fue el desarrollador líder de VMFS5. Desde este punto de vista, el uso de VMFS parece obvio. Sin embargo, la gran sorpresa para mí fue el hecho de que para los dispositivos flash no usamos VMFS, una sorpresa aún mayor fue que no usamos el sistema de archivos en absoluto.

¿Por qué no VMFS?
Los sistemas de archivos proporcionan características que no son necesarias y, a veces, incluso entran en conflicto con los requisitos de la plataforma que procesa la E / S activa en dispositivos flash. Uno de los mayores problemas con el uso de un sistema de archivos similar a VMFS en un dispositivo flash es que está optimizado para los sistemas de almacenamiento SAN y sus modelos de administración de datos; Satyam escribió un artículo sobre esto para ACM mientras trabajaba en VMware. Desafortunadamente, esto hace que el sistema de archivos sea una herramienta inapropiada para las tareas de FVP.

Los sistemas de archivos de dirección directa sobrecargan los dispositivos flash, lo que reduce su vida útil, no procesa de manera óptima las operaciones arbitrarias de E / S, prueba sus algoritmos de recolección de basura (a menudo muy frágiles) para su fuerza, y sus objetos (archivos y directorios) son menos adecuados para Gestión de nivel de máquina virtual y calidad de servicio, que es extremadamente importante para las tareas de FVP. La siguiente sección detallará el problema de administrar datos en dispositivos flash, pero por ahora una breve conclusión: si su dispositivo flash es costoso para usted, no coloque un sistema de archivos de direccionamiento directo en él.

Los sistemas de archivos también proporcionan capacidades que superan ampliamente las necesidades de FVP. Por ejemplo, bloqueos de disco. VMFS tiene un administrador de bloqueo distribuido avanzado que controla el acceso de diferentes hosts ESXi a los discos. FVP administra los discos locales del host y no requiere bloqueos en otros hosts, como resultado, el administrador de bloqueo distribuido se vuelve completamente superfluo. Lo mismo puede decirse sobre la compatibilidad con POSIX y las transacciones distribuidas. Y así sucesivamente.

Operaciones de flash de bajo nivel
Aquí hay un ejemplo de cómo escribir en dispositivos flash es fundamentalmente diferente de las grabaciones en discos duros. Flash no puede sobrescribir los datos existentes. Los datos en la memoria flash solo se pueden escribir en una página en blanco. Una característica de la memoria flash es que la grabación se puede realizar por páginas y el borrado solo se puede realizar en bloques. ¿Qué es una página y qué es un bloque? Flash almacena datos en celdas; las celdas se combinan en páginas (4 KB); Las páginas se agrupan en bloques. La mayoría de los fabricantes combinan 128 páginas en un bloque. Si desea borrar la página, debe borrar todo el bloque. Todos los datos necesarios de otras páginas deben guardarse en otro lugar. Es ampliamente conocido que los dispositivos flash tienen un número limitado de ciclos de escritura y borrado.

En consecuencia, una escritura de E / S aleatoria puede tener un impacto mayor del que pensaba. El problema es que la mayoría de los sistemas de archivos se desarrollaron en los años 80 y 90 y no han progresado desde entonces. Los sistemas de archivos no tienen en cuenta la degradación del rendimiento que causan a los dispositivos flash que utilizan operaciones de bajo nivel diseñadas para discos duros; La mayoría de los fabricantes de dispositivos flash implementan varios mecanismos para tener en cuenta la degradación progresiva del rendimiento. Con la ayuda de varios esquemas, consideramos estos mecanismos y descubrimos por qué la fragmentación tiene tal efecto en los dispositivos flash.

Manejo del desgaste
Tenga en cuenta que, para simplificar, decidí mostrar 9 páginas en un bloque en lugar de 128 páginas por bloque.

Vamos a empezar con el proceso de gestión del desgaste. En este ejemplo, la aplicación ya creó los datos y los grabó en las páginas A, B y C en el bloque 1 (Paso 1). Llegan nuevos datos (Paso 2), que se escriben en las páginas D, E y F. La aplicación actualiza los datos anteriores (AC) y, en lugar de usar las páginas anteriores, el dispositivo flash sigue utilizando las nuevas páginas. Estos nuevos datos están etiquetados A-1, B-1 y C-1. La distribución de registros de la manera más equitativa posible se denomina "gestión del desgaste". Las páginas antiguas ahora están marcadas como caducadas.

Recolección de basura y entrada múltiple.
En este ejemplo, el bloque A está lleno, ¿qué sucede si se acaba el espacio disponible para que el usuario pueda grabar y lleguen nuevos datos?

Flash copiará los datos actuales a las celdas vacías. Los datos reales en el bloque se leen y escriben en otro bloque. Los datos atrasados ​​permanecerán en sus páginas y se borrarán junto con el resto de las páginas de bloques. Este proceso se llama "recolección de basura".

La recolección de basura está bien, pero la entrada múltiple que ocurre durante su operación causa un daño significativo a los dispositivos flash. Para grabar 3 páginas, el dispositivo flash debe leer 6 páginas y escribir las 6 páginas en otro lugar antes de poder escribir nuevos datos. Y no te olvides del ciclo de borrado. Supongamos un escenario en el que el disco está lleno, ¿dónde moveremos (temporalmente) los datos antes de registrar nuevos datos? En mi diagrama, agregué el bloque B para esta opción. Para hacer esto en una situación real (cuando se utiliza el sistema de archivos), debe asignar el espacio sobrante reservado por el controlador flash.

Para hacer esto en una situación real (cuando se utiliza el sistema de archivos), debe asignar el espacio sobrante reservado por el controlador flash

Exceso de espacio
La capacidad del flash se puede reservar para procesos gestionados por un controlador flash. Esto puede ser realizado tanto por el fabricante del dispositivo flash como por el usuario. Por ejemplo, cuando compra un acelerador PCIe flash de 160 GB, de hecho, obtiene una tarjeta de 192 GB. El usuario tiene a su disposición 160 GB y 32 GB están reservados adicionalmente para las operaciones de nivel de controlador a nivel de flash, como la recolección de basura, la corrección de errores y el firmware del controlador. Cuando compra una unidad SSD no industrial, por lo general obtiene un poco de espacio reservado. Al formatear este dispositivo flash en cualquier sistema de archivos, debe tener en cuenta estas características y, posiblemente, reservar espacio adicional fuera de la capacidad disponible. Actualmente no hay recomendaciones de escala estandarizadas, por lo que debe tomar decisiones basadas en su propia experiencia. En el peor de los casos, se encontrará con un disco fragmentado y la SSD tendrá que transferir datos constantemente para escribir otros nuevos. Imagina a los niños jugando a la etiqueta, solo el patrón de movimiento es un poco más complicado.

Reconsiderar la gestión de datos en dispositivos flash
Los ingenieros de PernixData han desarrollado un nuevo formato para administrar datos en dispositivos flash para FVP. Los detalles serán revelados en los siguientes artículos, y ahora algunos puntos fundamentales.

Optimizado para flash
El formato está diseñado para almacenar datos temporales de E / S con el mínimo conjunto de metadatos posible, y trabajar con un dispositivo flash con el máximo rendimiento disponible. Convierte entradas aleatorias en entradas consecutivas, para aprovechar el mayor rendimiento del flash en el modo de escritura secuencial. Esto reduce la cantidad de sobrescritura de datos redundantes y los ciclos de borrado. Y el algoritmo no contiene las limitaciones heredadas de los sistemas de archivos, como bloques de gran tamaño, directorios, archivos, transacciones largas, administradores de bloqueos, etc.

Capacidad compartida dinámicamente entre máquinas virtuales.
Gracias integración profunda Con VMkernel, FVP puede rastrear bloques de datos y determinar si su máquina virtual está leyendo o escribiendo. Independientemente del seguimiento de dichas operaciones, la plataforma puede escalar los búferes de lectura y escritura en el espacio asignado para la máquina virtual. FVP puede almacenar en caché o eliminar de la caché un conjunto arbitrario de datos de máquinas virtuales. En contraste, la política de evacuación de datos en el sistema de archivos tradicional para un dispositivo flash será subóptima y dará lugar a múltiples reescrituras, ya que el sistema de archivos solo puede escribir datos al final del archivo o eliminar bloques del final también.

También significa que no necesita asignar una configuración de espacio de caché estática para cada máquina virtual, como lo sería si usara un sistema de archivos con direccionamiento directo. Fue una gran decisión para nosotros; La experiencia del usuario con el producto debe ser lo más intuitiva posible.

Cito a nuestro gerente de producto Bala: "La elegancia del producto, en mi opinión, es que realiza tareas básicas, que no requieren ninguna acción nueva o inusual por parte del usuario".

En términos de trabajo diario, esto es excelente: no es necesario escalar previamente la memoria caché para cada máquina virtual. Esto significa que no necesita saber y predecir el uso futuro de flash: FVP hará todo por usted. La falta de una asignación de recursos duros significa la falta de subutilización de flash por las máquinas virtuales descargadas y la aparición de ciclos de limpieza de bloques redundantes para máquinas virtuales activas con un tamaño de caché flash insuficiente. Esto minimiza el problema de las grabaciones múltiples y asegura el máximo rendimiento y confiabilidad de los dispositivos flash.

Artículo original .

Desde 2016, FVP se retiró de la venta.

¿Por qué no VMFS?
¿Qué es una página y qué es un bloque?
En este ejemplo, el bloque A está lleno, ¿qué sucede si se acaba el espacio disponible para que el usuario pueda grabar y lleguen nuevos datos?
Supongamos un escenario en el que el disco está lleno, ¿dónde moveremos (temporalmente) los datos antes de registrar nuevos datos?