Por Daniel Pehush y Gunter Zink
La misión: precaución, tropiezos por delante
Recogiendo de nuestra anterior entrada del blog, con el rendimiento ajustado, la siguiente pieza importante fue seleccionar el proveedor (es) para nuestros dispositivos de almacenamiento.
Con la mayoría de los proveedores con los que hablamos, Qumulo ya había comprado o tenía experiencia con sus SSD SATA. Nuestra experiencia en la realización de calificaciones dio los siguientes resultados:
- Proveedor A: buen historial de confiabilidad, mejor rendimiento, no barato, buena oferta
- Proveedor B: Buena confiabilidad, suficientemente rápido, costoso, desafíos de la cadena de suministro
- Proveedor C: pruebas internas fallidas
- Proveedor D: pruebas internas fallidas
Bueno, solo hay una opción que se ajuste a lo que queríamos entregar a los clientes para su lanzamiento. Obviamente, esto no era ideal y nos hemos mantenido en estrecho contacto con estos proveedores para validar futuros candidatos para su uso en nuestros productos. Pasamos una cantidad adecuada de tiempo con cada proveedor tratando de hacer que su solución funcionara para nosotros, pero al final, solo tenía una gran solución.
El chasis que elegimos es una solución completa de un proveedor y viene con excelentes características, que incluyen: ventiladores reemplazables en campo sin herramientas, carrieres de unidad sin herramientas y adaptadores PCIe Riser sin herramientas que brindan acceso a nuestras tarjetas de conmutador PCIe y NIC PCIe tarjetas. Las unidades de fuente de alimentación (PSU) incluso están diseñadas de manera inteligente, de modo que una vez que se instala un cable de PSU, no puede presionar el interruptor para desbloquear una PSU del chasis sin quitar el cable de PSU. No es posible quitar la fuente de alimentación mientras la fuente de alimentación está encendida. Este diseño es una excelente manera de prevenir accidentes de usuarios. Los únicos componentes que colocamos desde el punto de vista de la personalización son las unidades y las NIC, ¡qué facilidad! Es un sistema bien hecho que irradia preparación empresarial, y nos complace hacerlo increíblemente rápido para archivos con nuestro software.
¿Obstáculos en las vías, o debo decir en el camino hacia el desarrollo?
Arquitectura de carril PCIe
Por lo tanto, el escenario se preparó para que la primera plataforma de hardware de flash de Qumulo se calificara y se entregara a los equipos de software para que comenzara el desarrollo. El chasis es completamente integrado (L9) de un proveedor, y tiene ranuras 24 para dispositivos NVMe. Esto es todo, como uno podría decir coloquialmente, vanguardia Tecnología, pero NVMe ha estado en el mercado por un tiempo, por lo que se esperaba que las cosas salieran bien. Además de la madurez de NVMe, nos sentimos confiados al elegir un chasis que ya está establecido en el mercado. Los equipos de Qumulo tienen mucha experiencia en la entrega de plataformas personalizadas, por lo que la entrega de una plataforma estándar debería tener menos arrugas, ¿verdad?
Después de que ya hayamos enviado una orden de compra para recibir varios de los servidores, se supo que mientras el chasis 2U se vende con bahías 24 para dispositivos NVMe U.2, solo se cablea 20 de las bahías para su uso real. Habíamos planeado hacer uso de todas las bahías 24, y así comenzamos una discusión de arquitectura PCIe sobre cómo podríamos obtener acceso a todas las bahías. Para comenzar, CPU1 tiene un total de carriles 16 disponibles de PCIe Gen3, mientras que CPU2 tiene carriles 32 de PCIe Gen3. Cada CPU tiene una cantidad de 2 Occulink PCIe x4 puertos. Para abordar los dispositivos 24 NVMe, cada dispositivo necesita carriles 4 de PCIe Gen3, que es un total de carriles 96 que deben ejecutarse en el plano posterior donde se conectan estas unidades. También necesitamos conjuntos 2 de carriles 16 para dar servicio a nuestros dos NIC de doble puerto 40GbE / 100GbE.
Si ha mantenido todos esos números en su cabeza, necesitamos un total de carriles 128 PCIe Gen3 y tenemos carriles 56 para trabajar. ¡Esos números no suman! Por supuesto, el diseño del servidor es como tal para abordar esto con los conmutadores PCIe. Si no está familiarizado, los conmutadores PCIe pueden crear varios conjuntos de carriles a partir de un conjunto más pequeño para permitir compartir con varios dispositivos. El servidor venía con dos conmutadores PCIe que tomaban 8 carriles y se distribuían en 8 dispositivos NVMe U.2 en total, o 32 carriles. Así que ahora nuestro total de carriles disponibles era de 104 carriles. Como se indicó, el proveedor solo tenía la intención de que 20 de las ranuras fueran direccionables, por lo que si elimináramos esos 4 dispositivos (un total de 16 carriles), tendríamos 104 carriles disponibles, para una necesidad de 112 carriles. Finalmente, podríamos haber reducido nuestras NIC de dispositivos x16 a dispositivos x8, reduciendo a la mitad el ancho de banda de nuestra red deseado para nuestros clientes, y luego tendríamos suficientes carriles para satisfacer la plataforma. Esta ... no era una solución que satisfaga a nuestros clientes.
Luego nos topamos con una restricción mecánica. Hay elevadores PCIe 3 en los sistemas. Estos son PCBA que alimentan los carriles PCIe en organizaciones mecánicas óptimas. El sistema fue diseñado originalmente para que Riser1 alimente tres tarjetas adaptadoras x8 PCIe, Riser2 para alimentar tres tarjetas adaptadoras x8 PCIe y Riser3 para alimentar una sola tarjeta adaptadora x4. ¡No había un lugar físico para instalar una tarjeta NIC x16 como habíamos deseado originalmente! En algún punto discutimos, como una forma de obtener suficientes carriles para las unidades, si pudiéramos reducir a la mitad el ancho de banda de los dispositivos NVMe y adjuntarlos a través de carriles 2 en lugar de 4 (llamado bifurcación). El proveedor volvió citando que esto estaría usando los dispositivos fuera de las especificaciones, por lo que esa dirección no era una opción.
Trabajamos con el proveedor para generar una solución que encantará a nuestros clientes, y descubrimos que había otro tipo de tarjeta vertical diseñada; validamos este nuevo elevador PCIe, que tenía una ranura x8 y una ranura x16, reorganizamos las cosas mecánicamente y conseguimos una solución óptima de una ranura x8 y una ranura x16. Ahora CPU1 alimenta dispositivos 2 NVMe a través de 2 Occulink PCIe x4 puertos y un x16 NIC, y CPU2 alimenta dispositivos XMe 2 a través de 2 Occulink PCIe x4 puertos, un x16 NIC, dos x8, 8 puertos PCIe switches, y uno x4, 4 puertos PCIe switches. Si hacemos algunas matemáticas rápidas ...
Carriles deseados (128) = (x16 NIC) ✕ (2) + (x4 NVMe U.2 Drive) ✕ (24)
Carriles disponibles (128) = (x4 Ocurrir puertos) (4) + (CPU1 x16 para NIC) + (CPU2 x16 para NIC) + (CPU2 x8, x8, x4 -> x8 conmutador de 8 puertos x32, x8 conmutador de 8 puertos x32, x4 conmutador de 4 puertos x16)
¡Éxito! ¡Tenemos la arquitectura PCIe para aprovechar al máximo el servidor sin compromiso! Esto no hubiera sido posible sin nuestra persistencia y cooperación con el proveedor, ¡tan bien merecidos felicitaciones a nuestro proveedor de servidor / chasis!
Validación Térmica
Mientras trabajábamos para elegir una CPU, el proveedor declaró que la CPU que deseábamos usar, la Intel Xeon Gold 6126 TDP de 125W, estaba demasiado caliente para usarla en el chasis. Necesitábamos utilizar una CPU TDP más baja que solo consumía 85W, por lo que probamos con el Intel Xeon Gold 5115. Esto tuvo una caída indeseable en el rendimiento en comparación con la CPU 6126. Además, configuramos el servidor de una manera que el proveedor no pretendía originalmente y agregamos 4 dispositivos NVMe que no tenían la intención de admitir. Para que este sistema ofreciera el rendimiento y el almacenamiento correctos para nuestros clientes, teníamos que obtener soporte térmico para esta configuración.
Trabajamos para volver a calificar la validación térmica del servidor. Luego nos dimos cuenta de que la calificación térmica original para el nodo solo admitía temperaturas de hasta 27 ° C. Discutimos con el proveedor que para que este sea un producto viable, necesitábamos poder soportarlo en un entorno que podría ser tan caliente como 35 ° C (10 ° C a 35 ° C a 10,000 pies de altura es el rango operativo de temperatura estándar para servidores / dispositivos (ASHRAE Clase A2)). Afortunadamente, el trabajo aquí solo involucró un par de reuniones, cambiar el modelo de fuente de alimentación a uno con un enfriamiento más eficiente y probar todo en la cámara térmica del proveedor, ¡lo que resultó en una plataforma calificada con la CPU y el número de unidades que deseábamos!
15mm vs. 7mm U.2 Devices
En algún momento, estábamos pensando en utilizar las unidades 7mm NVMe U.2 en lugar de las unidades 15mm NVMe. Esto nos permitiría utilizar una mayor cantidad de unidades NVMe en una plataforma 1U o 2U. Esta idea se descartó rápidamente al planificar con nuestros proveedores de discos preferidos. El formato 7mm parecía estar desapareciendo o no recibir soporte de nivel 1st. Al no querer diseñarnos en una cadena de suministro difícil y una situación insostenible, decidimos que los dispositivos 15mm U.2 serían la mejor opción de dispositivo de almacenamiento.
Selección del kernel 4.13
Luego llegó el momento de instalar nuestro software. Espera, ese no es el siguiente paso; el siguiente paso fue solo para ver si podemos hacer que nuestro sistema operativo vanilla se inicie en la plataforma. Sabíamos que con esta tecnología de vanguardia necesitaríamos aprovechar las características de SW / kernel que pueden no estar presentes en nuestra combinación actual de SO / kernel. Qumulo se ejecuta en Ubuntu 16.04, cuya versión base del kernel es 4.4. En ese momento, este kernel no tenía las características necesarias para manejar NVMe hotswap. Así que pasamos al kernel 4.8 de habilitación de hardware de Ubuntu. Este kernel tiene las características que necesitábamos, pero una escasa incompatibilidad con un controlador de video que causaría problemas al usar un carrito de emergencia, o KVM, o permitiría que el servidor arrancara. Hablamos durante algún tiempo sobre la inclusión del controlador de video en la lista negra, pero la pérdida de funcionalidad sería demasiado grande. Realizamos otro salto a un kernel de habilitación de hardware de Ubuntu 4.13. Idealmente, moveríamos toda la línea de productos al mismo kernel, pero algunos paquetes requeridos para otras plataformas que enviamos no se compilarían, por lo que dividimos nuestra base de productos entre kernels. Finalmente, un kernel que parecía tener el conjunto de características que necesitábamos y hasta ahora no se descubrieron inconvenientes evidentes ...
Hotswap prueba la fragilidad del sistema
En este punto del ciclo de validación, obtuvimos el sistema a un nivel básico de funcionalidad. Uno de los principales puntos de validación para cualquier plataforma de hardware es el hotswap o hotplug testing. Los dispositivos que se anuncian como tales, no deben causar una caída o un golpe demasiado grande en las líneas de alimentación a medida que se retiran y se insertan en diversas situaciones de alimentación. También deben trabajar con el software host y ser funcionales después de un hotswap; No causando problemas con el software. Durante las pruebas, las cosas se pusieron difíciles. Este tema es el gran obstáculo / montaña que enfrentamos durante la validación de este producto, de ahora en adelante lo discutiremos por un tiempo.
Durante las pruebas de hotswap, identificamos una serie de problemas que nos impedirían enviar la plataforma. Estos fueron todos los problemas en torno a cómo interactuaban el hardware y el software. Algunos de los modos de falla que se manifestarían se enumeran a continuación:
- Al retirar y volver a insertar una unidad NVME, el software no pudo detectar la reintroducción de la unidad. La ranura en sí parecía estar deshabilitada, por lo que incluso la instalación de otra unidad no daba como resultado que el sistema notara que la unidad estaba instalada. Por lo tanto, el sistema estaría fuera de servicio hasta un ciclo de encendido.
- Encontramos una instancia en la que al quitar la unidad no se eliminó el dispositivo en Linux, y luego todas las llamadas al dispositivo se bloquearían hasta que el nodo se reiniciara.
Estos problemas nos impiden enviar el producto.
Para corregir este comportamiento, deberíamos usar una función que se denomina "Dispositivo de administración de volumen" o VMD, para abreviar. Esta característica del BIOS proporciona estabilidad y control de administración de LED para el hotswap. Trabajamos con el proveedor para habilitar esta característica en el BIOS. Un pequeño cambio que nos llevó a tomar una versión posterior de lspci que se lanzó para manejar las nuevas longitudes de direcciones de los dispositivos que surgieron al habilitar VMD. Hasta tomar esa solución, lspci no funcionaba. Otro pequeño bulto durante este viaje.
Genial, así que ahora se supone que debemos solucionar los problemas de fragilidad de la unidad y el control LED de los dispositivos NVMe. ¿Mencioné que el control LED no funcionó en absoluto sin VMD? Luego también tuvimos que modificar el firmware del conmutador que se estaba cargando para habilitar ese control LED de los dispositivos NVMe.
Luego, descubrimos que el rendimiento de las unidades cuando nuestro software lo utilizaba se redujo en algunas cargas de trabajo en un porcentaje de 60. ¿Mencionamos que algunos de los problemas de fragilidad de la unidad mencionados todavía estaban presentes? Este no es realmente un cambio aceptable para una solución que queríamos ofrecer a nuestros clientes. Trabajando con nuestro proveedor, y realizando una variedad de recopilación de datos y experimentación para ellos, haciéndolos venir físicamente al lugar y trabajar hombro con hombro, identificamos varios parches de kernel a backport para abordar la fragilidad del disco y los problemas de rendimiento. Por último, se identificó que el controlador del conmutador, que se estaba cargando de forma predeterminada, causó una regresión de rendimiento en el conmutador y el trabajo con el proveedor determinó que no era necesario para la plataforma.
Si bien este problema y esta resolución se detallaron en un par de párrafos anteriores, esta fue una investigación de varios meses, con muchas discusiones con nuestro proveedor y muchos experimentos y pruebas realizadas para validar una solución.
El firmware temprano causa una muerte de componentes superior a la esperada
Esta fue otra piedra en nuestro zapato mientras todas estas investigaciones estaban en curso. Tuvimos un par de unidades mueren en nosotros. Siempre hay alguna expectativa de mortalidad infantil con cualquier componente, pero por la cantidad de falla de componentes que experimentamos, sospechamos. Resultó que el proveedor ya tenía conocimiento del problema y, cuando lo mencionamos, había una solución de firmware disponible para el componente. Lección aprendida, siempre pregunte por el último firmware por adelantado y con frecuencia.
Los componentes del segundo aprovisionamiento van mal.
Durante la puesta en marcha, uno siempre quiere tener múltiples fuentes si puede para un componente. En este caso, intentamos calificar a otro proveedor para nuestros dispositivos U.2 NVMe. Esto condujo a una investigación en la que las unidades no volverían a negociar con la plataforma después de la extracción y la reinserción. Esto puede sonar familiar a los problemas descritos anteriormente, pero es un problema completamente diferente. Al capturar una traza de bus y códigos de error de las unidades, encontramos que el puerto raíz estaba enviando comandos a una unidad después de un hotswap que tenía un tamaño de carga útil PCIe incompatible. La placa base en este caso fue el culpable. Esto tomó un tiempo para identificarlo, ya que sospechábamos que la unidad y el interruptor antes de descubrir la placa base estaban rompiendo la especificación de PCIe. Al final, identificamos un parámetro de grub de Linux que podríamos establecer para forzar al software a hacer lo correcto y hacer que este segundo componente fuente sea viable. ¡Éxito! Entonces, el rendimiento resultó ser una regresión de nuestra fuente principal, ¡no pudimos usarlos! ¡Gorrón! Otra lección aprendida, antes de profundizar en un problema, asegúrese de que no haya una manera más fácil de identificar la nave antes de pasar demasiados ciclos.
Selección de NIC
¿Recuerda en esta publicación en la que hablé sobre la habilitación de la plataforma con 2 de doble puerto 40GbE NIC o 100GbE NIC? Cuando está construyendo un servidor tipo Ferrari que cuesta $$$$, a veces la cantidad de dinero que ahorra al permitir que los clientes soliciten un componente según sus necesidades, termina costándole más soporte a su cliente, y le da más apoyo a múltiples componentes Al final del ciclo de desarrollo, decidimos pasar a una opción NIC para permitir una matriz de prueba más pequeña y proporcionar tanto 40GbE / 100GbE desde un solo componente. La calificación y el apoyo es más fácil, una victoria fácil.
El Resultado
El resultado de todo esto es que entregamos una plataforma totalmente flash capaz de archivos sobre NFS o SMB que puede entregar flujos 3 de video sin comprimir 4K por nodo. Por lo tanto, el clúster viable más pequeño de 4, los nodos 23T de la serie P, es capaz de transmitir 12 de video sin comprimir 4K. Dado que este hardware es capaz de más, nuestros equipos de software trabajan continuamente para bombear más rendimiento de la plataforma más rápida que Qumulo ha entregado al mundo hasta la fecha. Los esfuerzos para mejorar el rendimiento se están gastando en nuestra plataforma de todos los flashes.
Esta es la plataforma de mayor calidad que hemos enviado hasta la fecha. Y, pudimos aprovechar una plataforma de un proveedor para hacerlo. Aprovechando el esfuerzo y los recursos de ingeniería de otra compañía para complementarlos con nuestra propia validación y software. Con todo este rendimiento, también creamos una plataforma que ahorra energía, dibujando ~ 250W cuando está inactivo, y bajo la carga de trabajo de múltiples flujos más alta que hemos generado, hemos registrado ~ 650W en el consumo de energía. Parte de este ahorro de energía se debe a la falta de medios de almacenamiento giratorios, así como a la sofisticada administración de energía en las CPU y las unidades NVME.
Debido a nuestro ciclo de desarrollo de software iterativo, continuaremos mejorando este producto después de enviarlo a los clientes. Nuestros desarrolladores de software no se quedan inactivos; se esfuerzan constantemente por ofrecer el mejor producto y la mejor experiencia de mejora continua del planeta. ¡Esperamos que haya disfrutado de este viaje de desarrollo de plataformas de hardware en Qumulo!
Muchas gracias a los editores de esta serie de tres partes.: Michaela Hutfles, Luke Mulkey y Jason Sturgeon
