Desde una empresa de tecnología que se enfoca en el procesamiento del habla y el lenguaje, Yunzhisheng ha desarrollado su pila de tecnología para tener capacidades completas de inteligencia artificial, como imágenes, procesamiento de lenguaje natural y señales.Es la empresa unicornio de inteligencia artificial líder en China. La empresa adopta la computación en la nube y tiene soluciones correspondientes en salud inteligente, hoteles inteligentes y educación inteligente.
Atlas es la plataforma de tecnología subyacente de Unisound, que admite la iteración de todos los modelos de Unisound:
La primera capa es la capa comercial, principalmente el negocio de la empresa, como el procesamiento de voz, el procesamiento de imágenes, el procesamiento de lenguaje natural, etc.
La segunda capa es el centro de control, que se puede completar en una sola parada desde la producción de datos, el acceso a los datos hasta el lanzamiento del modelo.
La tercera capa es la capa informática central, que admite principalmente el aprendizaje profundo y el preprocesamiento de datos.
La capa inferior es la capa de infraestructura, que se compone principalmente de un clúster de GPU, un clúster de CPU y almacenamiento distribuido.Todas las máquinas están conectadas por una red de alta velocidad InfiniBand de 100 Gbps.
Escenarios y requisitos de almacenamiento
El objetivo de construcción inicial de Unisound es construir una plataforma de IA integral, que incluya la producción de modelos de IA, el preprocesamiento de datos, el desarrollo de modelos, la capacitación de modelos y el lanzamiento del modelo final.
Como se muestra en la figura anterior, cada paso debe interactuar con los datos, y el preprocesamiento de datos y el entrenamiento del modelo requieren un IO relativamente grande .
• El preprocesamiento de datos, principalmente el procesamiento del habla, extraerá las características del habla y las convertirá en archivos de formato numpy; en el proceso de procesamiento de imágenes, las imágenes se preprocesarán y se realizará la conversión de formato de los datos de entrenamiento; • Desarrollo del modelo, principalmente es el algoritmo ingeniero que edita el código y depura el algoritmo del modelo; • Para el entrenamiento del modelo, se requerirán múltiples rondas de lectura de datos en el camino, y el modelo se enviará al almacenamiento correspondiente. El IO requerido para este paso es muy grande; el servicio leerá los archivos del modelo en el sistema de almacenamiento. Para resumir nuestros requisitos de almacenamiento:
- El enlace completo que se puede conectar a todo el desarrollo del modelo debe ser compatible con varios bloques funcionales básicos;
- Admite tareas de lectura de datos de CPU y GPU;
- Nuestros escenarios son principalmente datos de voz, texto e imágenes.Estos escenarios se caracterizan por tamaños de archivo relativamente pequeños, por lo que se debe admitir el procesamiento de alto rendimiento en escenarios de archivos pequeños.
- Nuestro escenario comercial es principalmente leer más y escribir menos.Durante el entrenamiento del modelo, la mayoría de los datos se leen y básicamente no se escriben datos. Según los requisitos anteriores, necesitamos un sistema de almacenamiento distribuido confiable y de alto rendimiento.
Historial de construcción de almacenamiento de Unisound
En los primeros días, solo teníamos alrededor de una docena de GPU y usábamos NFS para construir un clúster a pequeña escala. Al mismo tiempo, el entorno de prueba de CephFS se introdujo en 2016. En ese momento, el rendimiento de esa versión de CephFS no era muy bueno en el escenario de archivos pequeños, por lo que CephFS no se incorporó al entorno de producción.
Más tarde, continuamos investigando y descubrimos que Lustre es el sistema de archivos de alto rendimiento más utilizado en el campo de HPC. Las pruebas muestran que Luster funciona bien en términos de construcción y rendimiento a gran escala, por lo que desde 2017 hasta 2022, usaremos Luster para transportar todos los servicios de datos.
Sin embargo, a medida que se utilizan más y más GPU, y ahora tienen una capacidad de procesamiento de coma flotante de aproximadamente 570 exaflops/s, la E/S del almacenamiento subyacente ya no puede seguir el ritmo de la capacidad informática de la capa superior . Por lo tanto, comenzamos a explorar nuevo almacenamiento y actualización para la expansión de almacenamiento posterior. Al mismo tiempo, también encontramos algunos problemas en el proceso de uso de Lustre.
Primero: el método de operación y mantenimiento . Lustre se basa principalmente en el kernel y está directamente integrado en el kernel. A veces, el problema de posicionamiento implicará operaciones como reiniciar la máquina;
Segundo: pila de tecnología , porque el desarrollo de nuestra plataforma en la nube se basa principalmente en golang, por lo que preferimos usar un almacenamiento que sea más compatible con el lenguaje de desarrollo. Lustre utiliza el lenguaje C, que requiere más mano de obra en términos de personalización y optimización.
Tercero: confiabilidad de los datos.Lustre se basa principalmente en la confiabilidad del hardware (como la tecnología RAID), y la capa de software implementa principalmente la solución HA de nodos de metadatos y nodos de objetos y datos. En comparación con estos, todavía preferimos usar soluciones de software más confiables, como tres copias o códigos de borrado.
Cuarto: Los requisitos funcionales del almacenamiento en caché multinivel . En 2021, utilizaremos Fluid + Alluxio como la aceleración distribuida de Lustre. Alluxio puede acelerar mejor el cálculo de nuestro clúster y reducir la presión sobre el almacenamiento subyacente. Sin embargo, hemos estado explorando la posibilidad de realizar el almacenamiento en caché del lado del cliente directamente desde el sistema de almacenamiento, de modo que la operación pueda ser más transparente para los usuarios.
Cuando JuiceFS se abrió por primera vez en 2021, realizamos una investigación sobre sus características.
En primer lugar, las características del producto : JuiceFS es compatible con la interfaz POSIX y se puede montar en forma de HostPath. Este método es exactamente igual a la forma en que usamos NAS, y los usuarios básicamente no necesitan realizar ningún cambio al usarlo; los metadatos y objetos de JuiceFS almacenamiento , hay muchas alternativas, como Redis y TiKV son más adecuadas en el campo de la IA. Los usuarios de almacenamiento de objetos en la nube pública, Ceph y MinIO subyacentes pueden elegir por sí mismos.
Segundo, programación de capa superior : JuiceFS no solo es compatible con HostPath, sino que también es compatible con el modo de unidad CSI, lo que permite a los usuarios acceder al almacenamiento correspondiente de una manera más nativa en la nube.
En tercer lugar, adaptación del marco empresarial : la interfaz POSIX se adapta al marco de aprendizaje profundo. Cuarto, operación y mantenimiento: el motor de metadatos y el almacenamiento de objetos son relativamente maduros en la industria, y hay muchas opciones, y JuiceFS tiene funciones automáticas de copia de seguridad de metadatos y papelera de reciclaje. JuiceFS encaja bien con el negocio, por lo que realizamos una prueba POC.
El entorno de prueba se muestra en la figura anterior. En comparación con JuiceFS, se encuentra que JuiceFS utiliza directamente la memoria caché de la página del núcleo y, en comparación con el acceso directo de Lustre al disco mecánico, el rendimiento mejora considerablemente (como se muestra en la figura a continuación, cuanto más pequeño, mejor).
Después de la prueba POC, decidimos llevar JuiceFS al entorno de producción. En la actualidad, todos los nodos de computación GPU de todo el clúster Atlas, así como todos los nodos de desarrollo y depuración, tienen instalado el cliente JuiceFS.
JuiceFS se conecta directamente al clúster redis y ceph, y la mayoría de los nodos informáticos usan HostPath para acceder. Al mismo tiempo, el controlador CSI de JuiceFS también se implementa en el clúster de Atlas y los usuarios pueden acceder a él de forma nativa en la nube.
Cómo se usa JuiceFS en Atlas
Para garantizar la seguridad de los datos, cada grupo en la plataforma de supercomputación pertenece a un directorio diferente, cada directorio son los miembros del grupo o departamento respectivo, y los directorios entre diferentes grupos son invisibles .
Los permisos de directorio se basan en el mecanismo de control de permisos de Linux. Cuando un usuario envía una tarea de capacitación en el clúster de Atlas, la herramienta de envío de tareas del clúster leerá automáticamente la información de UID y GID del usuario en el sistema y luego la inyectará en el campo SecurityContext del Pod de tareas enviado por el usuario, luego el contenedor El pod que se ejecuta en el clúster de Atlas Los UID de los procesos en ejecución de todos los contenedores son coherentes con la información del sistema de almacenamiento para garantizar que los permisos no superen los límites.
Los nodos acceden a JuiceFS para implementar el almacenamiento en caché de varios niveles:
-
El primer nivel: el caché es el caché de página de la memoria.
-
Nivel 2: Múltiples SSD en todos los nodos informáticos brindan capacidades de aceleración de nivel 2.
-
El tercer nivel: usar Ceph. Si tres SSD de 1 t aún no pueden admitir datos de usuario, se leerán de Ceph.
A principios de 2021, Unisound y el equipo de JuiceFS integrarán JuiceFSRuntime en Fluid. Debido a que la memoria caché se usa de manera básica, descubrimos que la visibilidad de la memoria caché no es buena para los usuarios. El sistema limpia automáticamente la memoria caché y la capacidad de control del usuario no es tan alta. Es por eso que integramos JuiceFS en fluido.
Fluid iniciará los componentes relacionados con JuiceFS, incluidos FUSE y Worker Pod. Entre ellos, FUSE Pod proporciona la capacidad de caché del cliente JuiceFS, y Worker Pod realiza la gestión del ciclo de vida de la caché.La tarea de entrenamiento fuera de línea de IA de la plataforma Atlas interactúa con el cliente FUSE Pod para leer los datos de entrenamiento de IA. .
A través de las capacidades de programación de caché proporcionadas por Fluid y la observabilidad de los conjuntos de datos, los usuarios de la plataforma pueden implementar cachés en nodos informáticos específicos a través de la programación de afinidad y, al mismo tiempo, los usuarios pueden ver intuitivamente el uso de cachés (como los datos almacenados en caché). conjuntos) tamaño, porcentaje de caché, capacidad de caché, etc.).
Práctica de construcción de JuiceFS
Actualmente, Atlas no puede acceder a la red pública y se encuentra en una red aislada dedicada, por lo que todas nuestras implementaciones están privatizadas.
El motor de metadatos de nuestro entorno de producción usa Redis. En 2020, la conexión entre TiKV y JuiceFS no está muy madura. Planeamos usar Redis primero para la transición y usar Ceph para el almacenamiento de objetos. El disco del sistema del nodo de Redis está configurado con RAID1 y los datos persistentes de Redis se sincronizarán periódicamente con otro nodo de copia de seguridad. Para la persistencia de datos de Redis, usamos la solución AOF + RDB para conservar los datos cada segundo.
El almacenamiento de objetos utiliza un clúster de Ceph autoconstruido y el clúster de Ceph se implementa mediante Cephadm. El entorno de producción actual utiliza la versión de Octopus. En ese momento, tomamos prestadas muchas soluciones de la industria, optimizamos la memoria a nivel de memoria e hicimos los ajustes correspondientes a nivel de software, principalmente de la siguiente manera:
Nivel de servidor (referencia) : • 42 núcleos 256GB 24 18T HDD • Disco del sistema: 2 960G SAS SSD • BlueStore • Deshabilitar NUMA • Actualizar kernel: 5.4.146 Habilitar io_uring • Kernel pid max, modificar /proc/sys/kernel/pid_max
Configuración de Ceph : • Ceph RADOS: llame directamente a la interfaz de librados, no use el protocolo S3 • Fragmento de cubeta • Desactive la función de ajuste automático de pg • Almacenamiento de registro OSD (usando bluestore, la relación recomendada de capacidad bruta - bloque: bloque.db : block.wal = 100:1:1, se recomienda SSD o NVMe SSD para los dos últimos) • 3 copias
Es importante mencionar que el kernel del clúster de Ceph debe actualizarse a una versión más nueva y luego debe habilitarse la función io_uring, para que el rendimiento mejore considerablemente. En términos de software, llamamos directamente a la interfaz rados en lugar de usar el protocolo S3, y la eficiencia será ligeramente mayor.Todos los nodos están interconectados con una red de alta velocidad 100G InfiniBand.
El almacenamiento de objetos conectado a JuiceFS en el entorno de Yunzhisheng es Ceph RADOS. JuiceFS usa librados para interactuar con Ceph, por lo que el cliente de JuiceFS debe volver a compilarse. Se recomienda que la versión de librados corresponda a la de Ceph. Preste atención a esto punto. Si usa el controlador CSI, se leerá en la creación de PV/PVC, y /etc/ceph/ceph.conftambién prestar atención al soporte de la versión.
Sistema de monitoreo perfecto
Ahora, todo el enlace es relativamente largo. La capa inferior tiene clústeres de motores de metadatos, clústeres de almacenamiento de objetos de Ceph y clientes y servicios de la capa superior. Cada capa debe tener una solución de monitoreo correspondiente.
Para el nodo del cliente, recopilamos principalmente registros. Cabe señalar que los registros del cliente de JuiceFS de cada punto de montaje deben agregarse y se requieren alarmas de error para evitar que los registros exploten el disco del sistema o que no se pueda escribir el nodo.
Cada cliente de JuiceFS también debe tener métodos de monitoreo correspondientes, como verificar si los archivos .stat y los indicadores de observación de registro de cada punto de montaje son normales, y luego verificar el IO y los registros de los clústeres de Redis y Ceph para garantizar que todo el enlace sea controlable Sí , es más conveniente ubicar el problema de esta manera.
La imagen de arriba es la imagen de monitoreo de Ceph, porque nuestros nodos de cliente usan caché SSD, y ahora los datos básicamente no se leen en Ceph, la mayoría de los datos se leen desde el caché, por lo que el tráfico de Ceph no es grande.
La imagen de arriba son los datos interceptados por el monitoreo de JuiceFS. Se puede ver que entre el 100 % y el 90 % de los nodos pueden ser afectados. La tasa de aciertos del caché sigue siendo relativamente alta y la mayoría de los datos aún están en el caché.
Participe en la construcción de la comunidad de JuiceFS
UniSound ha estado participando activamente en la creación de comunidades durante el proceso de uso de JuiceFS Community Edition. En 2021, trabajé con el equipo de JuiceData para desarrollar el tiempo de ejecución Fluid JuiceFS mencionado anteriormente. Recientemente, descubrimos que la cuota basada en directorios de la versión comunitaria aún no se ha desarrollado, por lo que desarrollamos una versión hace unos meses, que limita la cantidad de archivos en el directorio y el tamaño del archivo. ahora está trabajando con la comunidad de JuiceFS Haz el trabajo de fusión.
Escenarios de uso y beneficios de JuiceFS en Atlas
Actualmente, la memoria caché multinivel del cliente de JuiceFS se utiliza principalmente en nuestros escenarios de reconocimiento de texto, reducción de ruido de voz y reconocimiento de voz. Dado que la lectura de datos del entrenamiento del modelo de IA se caracteriza por más lectura y menos escritura, hacemos un uso completo del caché del cliente de JuiceFS para brindar los beneficios de aceleración de la lectura de IO.
Beneficio 1: acelerar el entrenamiento del modelo de IA
1) Prueba de reducción de ruido del habla
Los archivos dispersos se utilizan en la prueba del modelo de escena de reducción de ruido. Cada dato está en formato wav, un archivo de voz pequeño de menos de 100k. En la escena de reducción de ruido, probamos los datos de E/S en la etapa de carga de datos y el memoria del nodo cliente de JuiceFS. El caché es de 512G, y la prueba se realiza con un tamaño de lote de 40 bajo la escala de datos de 500h.
A partir de los resultados de la prueba, solo en términos de eficiencia de lectura de datos, en términos de archivos wav pequeños, JuiceFS es de 6,45 it/s, mientras que Lustre es de 5,15 it/s, y el rendimiento mejora en un 25 %. JuiceFS ha acelerado efectivamente nuestra capacitación de modelos de extremo a extremo y ha acortado el tiempo total de salida del modelo.
2) escena de reconocimiento de texto
En el escenario de reconocimiento de texto, el modelo es CRNN backbone y MobileNet v2, y el entorno de prueba es el siguiente:
Se genera un gran archivo de datos de LMDB. En este momento, IO tiene requisitos de ancho de banda relativamente altos en lugar de requisitos de rendimiento para archivos pequeños. La memoria caché de 200 G puede admitir todos los datos, por lo que en lugar de utilizar el almacenamiento subyacente, leemos directamente del cliente y el rendimiento general también ha mejorado considerablemente.
En esta prueba, la comparación de velocidad entre JuiceFS y Lustre se realiza principalmente. Según los resultados experimentales, se tarda 1,5 s en leer cada lote de Lustre y 1,1 s en leer cada lote de JuiceFS, un aumento del 36 %. Desde la perspectiva del tiempo de convergencia del modelo, desde las 96 horas de Lustre hasta las 86 horas de JuiceFS, el uso de JuiceFS puede acortar el tiempo de salida del modelo CRNN en 10 horas.
Depuración de modelos y procesamiento de datos.
Al realizar la depuración de código, varios usuarios ejecutarán pruebas de modelo y cruce de código en una máquina de depuración al mismo tiempo. En ese momento, la mayoría de los usuarios usarían algunos IDE remotos, se conectarían a nodos de depuración y luego construirían su propio entorno virtual, instalarán una gran cantidad de paquetes de instalación en Lustre por adelantado.
La mayoría de ellos son pequeños archivos de decenas de k o cientos de k, y necesitamos importar estos paquetes a nuestra memoria. Al usar Lustre anteriormente, debido a que hay demasiados usuarios, el rendimiento requerido es alto. Al mismo tiempo, los requisitos de rendimiento para archivos pequeños son relativamente altos. Descubrí que el efecto no es muy bueno. Al importar paquetes, será relativamente atascado, lo que da como resultado una depuración lenta del código y una eficiencia general relativamente baja.
Más tarde, se usó el caché del cliente JuiceFS, y la primera compilación también fue relativamente lenta, pero la segunda compilación debido a que todos los datos se habían colocado en el caché, la velocidad y la eficiencia fueron mayores, y el salto de código fue más rápido. insinuando que las importaciones también son más rápidas. Después de la prueba del usuario, hay un aumento de velocidad de aproximadamente 2 ~ 4 veces.
epílogo
De Lustre a JuiceFS
De 2017 a 2021, cuando usamos Lustre, también es relativamente estable.Cuando la capacidad de almacenamiento del clúster es inferior al 50%, la estabilidad del software es relativamente alta.
Como sistema de almacenamiento en el veterano campo de la HPC, Luster ha impulsado muchos de los sistemas de supercomputación más grandes del mundo y tiene muchos años de experiencia en entornos de producción. Tiene las ventajas de cumplir con el estándar POSIX, admitir varias redes de alto rendimiento y baja latencia y permitir el acceso a RDMA.Es adecuado para la informática de alto rendimiento en el campo HPC tradicional y es compatible con la interfaz de aprendizaje profundo. No es necesario realizar todos los negocios. Modificación del código. Pero también hay algunas desventajas:
En primer lugar, Lustre no puede admitir el controlador CSI nativo de la nube.
En segundo lugar, Luster tiene requisitos relativamente altos para el personal de operación y mantenimiento, porque todo está escrito en lenguaje C, a veces algunos errores no se pueden resolver rápidamente y la comunidad en general no es muy abierta y activa.
JuiceFS tiene tales características:
En primer lugar, JuiceFS es un producto de sistema de almacenamiento distribuido en el campo nativo de la nube que proporciona CSI Driver and Fluid para una mejor integración con Kubernetes.
En segundo lugar, el esquema de implementación de JuiceFS es relativamente flexible y el motor de metadatos es altamente opcional.Si la red del usuario permite el almacenamiento de objetos, en realidad es mejor conectarse al almacenamiento de objetos de la nube pública.
En tercer lugar, es relativamente simple en términos de operación y mantenimiento de expansión de almacenamiento . Totalmente compatible con el estándar POSIX, la aplicación de aprendizaje profundo se puede migrar sin problemas, pero debido a las características del almacenamiento de objetos de back-end, JuiceFS tendrá un gran retraso en la escritura aleatoria.
En cuarto lugar, JuiceFS es compatible con la memoria caché local y la memoria caché de la página del kernel, lo que realiza la estratificación y la aceleración de datos calientes y fríos . Esto es lo que más valoramos, es más adecuado en nuestros escenarios comerciales, pero no es adecuado para la escritura aleatoria. La función de caché distribuida de la versión comunitaria aún no está disponible.
Planificación posterior
• Actualización del motor de metadatos, TiKV es adecuado para escenarios con más de 100 millones de archivos (puede admitir hasta 10 mil millones de archivos) y tiene altos requisitos de rendimiento y seguridad de datos. Actualmente, hemos completado la prueba interna de TiKV y estamos activamente trabajando en ello Para seguir el progreso de la comunidad, el motor de metadatos se migrará a TiKV en el futuro. • Optimización de la cuota de directorio. En la actualidad, las funciones de la versión básica se han integrado en la versión de la comunidad de JuiceFS. También se han llevado a cabo discusiones con la comunidad de JuiceFS. En algunos escenarios, es necesario optimizar el rendimiento. • Espero hacer algunas funciones no raíz. Ahora todos los nodos tienen autorización de raíz para acceder a todos los datos. La autorización es demasiado grande. Esperamos abrir únicamente la autorización de raíz en nodos específicos. • Finalmente, verificaremos si existe una solución de QoS en la comunidad, como un límite de velocidad basado en UID o GID.
Si es de ayuda, preste atención a nuestro proyecto Juicedata/JuiceFS . (0ᴗ0✿)