Recomendaciones de hardware de compilación Ceph "bien organizadas"
Ceph está diseñado para ejecutarse en hardware básico, lo que hace que sea económicamente viable construir y mantener clústeres de datos muy grandes. Al planificar el hardware del clúster, es necesario equilibrar una serie de consideraciones, incluidos los dominios de falla y los posibles problemas de rendimiento. La planificación del hardware debe incluir la distribución de los demonios Ceph y otros procesos que utilizan Ceph en varios hosts. En general, recomendamos ejecutar un demonio Ceph específico en un host que esté configurado para ese demonio. Recomendamos utilizar otro host para manejar los procesos que utilizan su clúster de datos (por ejemplo, OpenStack, CloudStack).
El servidor de metadatos Ceph redistribuye dinámicamente la carga, lo que requiere mucha CPU. Los OSD de Ceph ejecutan un servicio RADOS que utiliza CRUSH para calcular la ubicación de datos, replicar datos y mantener su propia copia del mapa del clúster. Por lo tanto, el OSD debe tener una potencia de procesamiento razonable (como un procesador de doble núcleo). El monitor simplemente mantiene una copia maestra del mapa del clúster, por lo que no requiere potencia de procesamiento intensiva de la CPU.
Además de los demonios Ceph, también debe considerar si el host ejecutará procesos que requieren un uso intensivo de la CPU. Por ejemplo, si el host ejecutará máquinas virtuales informáticas (como OpenStack Nova), deberá hacerlo. asegúrese de que estos otros procesos sean demonios Ceph. Deje suficiente potencia de procesamiento. Recomendamos ejecutar otros procesos que consumen mucha CPU en un host independiente.
En términos generales, más memoria es mejor.
El uso de memoria de los demonios monitores y administradores generalmente varía según el tamaño del clúster.
Para clústeres pequeños, 1-2 GB generalmente es suficiente.
Para clústeres grandes, debes proporcionar más memoria (5-10 GB).
Es posible que también desees considerar ajustar configuraciones como mon_osd_cache_size o rocksdb_cache_size
Bluestore usa su propia memoria para almacenar datos en caché en lugar de depender del caché de páginas del sistema operativo. En BlueStore, puede ajustar la cantidad de memoria en osd_memory_target usando la opción osd_memory_target
. Generalmente no se recomienda configurar osd_memory_target por debajo de 2 GB, lo que puede mantener la memoria por debajo de 2 GB y provocar un rendimiento extremadamente lento. Establecer el objetivo de memoria entre 2 GB y 4 GB generalmente funciona, pero puede resultar en una degradación del rendimiento porque los metadatos se pueden leer desde el disco durante la E/S a menos que el conjunto de datos activos sea relativamente pequeño. 4 GB es el tamaño predeterminado actual de osd_memory_target, que está configurado para equilibrar los requisitos de memoria y el rendimiento de OSD en condiciones de uso típicas. Configurar osd_memory_target en un valor superior a 4 GB puede mejorar el rendimiento cuando se trabaja con conjuntos de datos grandes (pequeños) o grandes (256 GB/OSD).
IMPORTANTE:
El escalado automático de memoria de OSD es el "mejor esfuerzo". Si bien OSD puede desasignar la memoria para permitir que el kernel la recupere, no hay garantía de que el kernel realmente recupere la memoria liberada en un período de tiempo determinado. Esto es especialmente notable en versiones anteriores de Ceph, donde las páginas enormes transparentes impedían que el núcleo recuperara memoria de páginas gigantes fragmentadas. Las versiones modernas de Ceph desactivan las páginas grandes transparentes a nivel de aplicación para evitar esta situación, pero esto aún no garantiza que el kernel recupere inmediatamente la memoria no asignada. Recomendamos reservar aproximadamente el 20 % de la memoria adicional en el sistema para evitar OOM de OSD durante picos temporales o debido a retrasos en el kernel al reclamar páginas libres.
Cuando se utiliza el backend tradicional de FileStore, el caché de la página se usa para almacenar datos en caché, por lo que generalmente no es necesario ajustarlo. El consumo de memoria de OSD generalmente está relacionado con la cantidad de PG para cada demonio en. el sistema
Planifique cuidadosamente la configuración de almacenamiento de datos. Al planificar el almacenamiento de datos, hay que considerar importantes compensaciones entre costos y rendimiento.
Las operaciones simultáneas del sistema operativo y múltiples procesos demonio que solicitan simultáneamente operaciones de lectura y escritura en una sola unidad pueden reducir significativamente el rendimiento.
IMPORTANTE
Dado que Ceph debe escribir todos los datos en el registro antes de enviar un ACK (al menos para XFS), el equilibrio de rendimiento entre el registro y OSD es muy importante. El registro de Ceph y el rendimiento de OSD son muy importantes aquí.
El OSD debe proporcionar suficiente espacio en el disco duro para los datos del objeto. Recomendamos un disco duro con una capacidad de al menos 1 T. Recomendamos dividir el precio de un disco duro por el gigabyte para calcular el costo por gigabyte, ya que las unidades más grandes pueden tener un impacto significativo en el costo por gigabyte. Por ejemplo, un disco duro de 1T con un precio de 75 dólares cuesta 0,07 dólares por gigabyte. En comparación, una unidad 3T de 150 dólares cuesta 0,05 dólares por gigabyte. En el ejemplo anterior, el uso de una unidad de 1T normalmente aumentaría el costo por gigabyte en un 40%, lo que haría que el clúster fuera significativamente menos rentable.
Consejo: ejecutar varios OSD en un solo disco (independientemente de la partición) no es una buena idea.
Consejo: ejecutar OSD y monitores en un solo disco, independientemente de la partición o los servidores de metadatos. no es una buena idea
Las unidades de almacenamiento tienen tiempos de búsqueda, tiempos de acceso, tiempos de lectura y escritura y rendimiento total limitados. Estas limitaciones físicas pueden afectar el rendimiento general del sistema, especialmente durante la recuperación. Recomendamos utilizar discos duros dedicados para el sistema operativo y el software, y un disco duro para cada demonio Ceph OSD que ejecute en el host. La mayoría de los problemas de "OSD lento" se deben a la ejecución de un sistema operativo, varios OSD o varios registros en el mismo disco duro. Debido a que el costo de solucionar problemas de rendimiento en un clúster pequeño excede el costo de las unidades de disco adicionales, puede optimizar la planificación del diseño del clúster evitando el consumo excesivo de unidades de almacenamiento OSD.
Puede ejecutar varios demonios Ceph OSD por disco duro, pero esto genera un consumo de recursos y un rendimiento general reducido. Puede almacenar datos de registros y objetos en el mismo disco duro, pero esto aumenta el tiempo necesario para escribir registros y ACK en el cliente.
Escritura ACK: después de completar este tipo de escritura, se enviará un ACK de escritura exitosa al cliente, por lo que se denomina escritura ACK.
Requisitos de mejores prácticas de Ceph Usted ejecuta el sistema operativo sistema, datos OSD y registros OSD en unidades separadas
Una oportunidad para mejorar el rendimiento es utilizar SSD para reducir el tiempo de acceso aleatorio y la latencia de lectura mientras se acelera el rendimiento. Los SSD suelen costar más de 10 veces más por gigabyte que los HDD, pero los tiempos de acceso a los SSD suelen ser al menos 100 veces más rápidos que los de los HDD.
Los SSD no tienen partes mecánicas móviles, por lo que no necesariamente están sujetos a las mismas limitaciones que los discos duros mecánicos. Pero los SSD tienen limitaciones importantes. Al evaluar los SSD, es importante considerar el rendimiento de lectura y escritura secuencial. Al almacenar varios registros para varios OSD, una SSD con un rendimiento de escritura secuencial de 400 MB/s puede funcionar mejor que una SSD con un rendimiento de escritura secuencial de 120 MB/s.
Importante
Recomendamos explorar el uso de un SSD para mejorar el rendimiento. Sin embargo, antes de realizar una gran inversión en un SSD, recomendamos encarecidamente probar el rendimiento del SSD al revisar las métricas de rendimiento del SSD y las configuraciones de prueba.
Dado que los SSD no tienen piezas mecánicas móviles, no es necesario utilizarlos. Cuándo Tiene sentido utilizar SSD para áreas Ceph con grandes cantidades de espacio de almacenamiento (como registros). Un SSD relativamente económico puede resultar atractivo para su mente financiera. Úselo con precaución. Al elegir un SSD para usar con Ceph, tener IOPS aceptables no es suficiente. Hay varias consideraciones de rendimiento importantes para el registro y los SSD:
Semántica de escritura intensiva: el registro implica una semántica de escritura intensiva, por lo que debe asegurarse de que el SSD que elija implementar funcione bien al escribir datos Igual o mejor que los discos duros mecánicos.
Los SSD económicos pueden introducir retrasos en la escritura y, al mismo tiempo, acelerar el acceso, ya que las unidades de alto rendimiento a veces pueden escribir más rápido que algunos de los SSD más asequibles del mercado, por lo que debe asegurarse de elegir el SSD que va a implementar. La escritura de datos es igual o mejor que la de un disco duro mecánico. Escrituras secuenciales: al almacenar varios registros en un SSD, se deben tener en cuenta las limitaciones de escritura secuencial del SSD, ya que pueden estar manejando solicitudes de escritura para múltiples registros OSD al mismo tiempo. Alineación de particiones: un problema común con el rendimiento de las SSD es que a las personas les gusta particionar sus unidades como práctica recomendada, pero a menudo no alinean correctamente sus particiones SSD, lo que puede resultar en velocidades de transferencia de datos más lentas desde la SSD. Asegúrese de que las particiones SSD estén alineadas correctamente
Aunque las SSD son más caras para el almacenamiento de objetos, si almacena los registros del OSD en el SSD y almacena el almacenamiento de objetos del OSD en un disco duro mecánico independiente, es posible que vea mejoras significativas en el rendimiento.
Una forma en que Ceph acelera el rendimiento del sistema de archivos CephFS es aislar el almacenamiento de metadatos de CephFS del almacenamiento de contenidos de archivos CephFS. No es necesario crear un grupo para metadatos de CephFS, pero puede crear una jerarquía de mapeo CRUSH para el grupo de metadatos de CephFS que apunte solo al medio de almacenamiento SSD del host. Para obtener más información, consulte Asignación de grupos a diferentes tipos de OSD. Esto significa que todos los datos del grupo se pueden almacenar en un OSD tipo SSD.
El controlador de disco también tiene un impacto significativo en el rendimiento de escritura. Se debe prestar especial atención al seleccionar un controlador de disco para garantizar que no cree un cuello de botella en el rendimiento.
Consejo: El blog de Ceph suele ser una buena fuente de información sobre los problemas de rendimiento de Ceph. Para obtener más información, consulte Rendimiento de escritura de Ceph 1 y Rendimiento de escritura de Ceph 2
?/community/ceph-performance-part-1-disk-controller-write-throughput/?/ community/ceph-performance-part -2-write-throughput- without-ssd-journals/
Puede ejecutar varios OSD en cada host, pero debe asegurarse de que el rendimiento total de los discos duros OSD sea la suma de No exceda el Ancho de banda de red requerido por el cliente del servicio para leer o escribir. También debe considerar qué porcentaje de los datos generales almacena su clúster en cada host. Si el porcentaje es grande en un host en particular y ese host falla, podría exceder la proporción completa, y así sucesivamente, lo que podría provocar que Ceph deje de funcionar, lo cual es una medida de seguridad para evitar la pérdida de datos.
Cuando ejecuta varios OSD por host, también debe asegurarse de que el kernel esté actualizado. Consulte las recomendaciones de su sistema operativo para glibc y syncfs(2) para asegurarse de que su hardware funcione como se espera al ejecutar varios OSD por host.
Considere utilizar redes de más de 10 Gbps en el rack. ¡Se necesitan 3 horas para copiar 1 TB de datos en una red de 1 Gbps y 30 horas para copiar 10 TB de datos! En comparación, en una red de 10 Gbps, la replicación tarda 20 minutos y 1 hora respectivamente. En clústeres de escala de petabytes, las fallas del disco OSD deben esperarse, no ser la excepción. Dada la relación precio/rendimiento, los administradores de sistemas apreciarán la capacidad de una PG para recuperarse de un estado degradado a un estado activo+limpio lo más rápido posible. Además, algunas herramientas de implementación aprovechan las VLAN para facilitar la administración del cableado de red y hardware. El uso del protocolo 802.1q puede ahorrar costos operativos. También vale la pena considerar Ethernet 10G cuando se utilizan VLAN para manejar el tráfico de máquinas virtuales entre clústeres y pilas de computación como OpenStack, CloudStack, etc. Los enrutadores en rack de cada red también deben poder comunicarse con enrutadores troncales de mayor rendimiento, como de 40 Gbps a 100 Gbps.
El hardware de su servidor debe tener un Controlador de administración base (BMC). Las herramientas de administración e implementación también pueden hacer un uso intensivo del BMC, por lo que debe considerar las compensaciones costo/beneficio de administrar una red fuera de banda.
El acceso SSH al hipervisor, la carga de imágenes de máquinas virtuales, la instalación de imágenes del sistema operativo, los sockets de administración, etc. supondrán una carga enorme para la red. Ejecutar tres redes puede parecer excesivo, pero cada ruta de tráfico representa un cuello de botella potencial de capacidad, rendimiento y/o rendimiento que debe considerar cuidadosamente antes de implementar un clúster de datos a gran escala.
BMC: Baseboard Management Controller
Fuera de banda: OOB, o todo fuera de banda, es un conjunto de redes independientes, independientes de cualquier red de datos empresarial, y disponible en cualquier momento, incluso durante En el caso de terminales de red empresarial, el centro de control de red también se puede conectar a la interfaz o consola de administración de cada servidor o dispositivo de red a través de la red fuera de banda.
Un dominio de fallo es cualquier fallo que impide que uno o más OSD fallen. Esto podría ser una parada del demonio en el host, falla del disco duro, falla del sistema operativo, falla de la tarjeta de red, falla de energía, corte de red, falla de energía, etc. Al planificar sus requisitos de hardware, debe equilibrar la reducción de costos que resulta de asignar demasiada responsabilidad a muy pocos dominios de falla con el costo adicional de aislar cada dominio de falla potencial resultante de aislar cada dominio de falla potencial.
Ceph. puede funcionar con hardware básico barato. Los clústeres de producción pequeños y los clústeres de desarrollo pueden ejecutarse correctamente en hardware moderado
Tipo de procesador Tipo de hardware Configuración mínima recomendada
La configuración mínima del procesador ceph-osd es un núcleo
200 -500 MB/s de un solo núcleo
1000-3000 IOPS de un solo núcleo
Los resultados son los mismos que los resultados anteriores
Los resultados pueden variar según el modelo de CPU y las capacidades de Ceph ( eliminación de piscinas, compresión, etc.)
Los procesadores ARM pueden requerir más núcleos
El rendimiento real depende de varios factores, incluidos el disco, la red, el rendimiento del cliente y la latencia. Se recomienda encarecidamente realizar pruebas comparativas
Memoria de 4 GB o más por demonio (cuanto más, mejor)
2-4 GB funcionan bien (puede ser más lento)
No se recomienda a continuación 2 GB
Almacenamiento de volumen Un disco duro por demonio
DB/WAL Una partición SSD por demonio (cuanto más, mejor) Una partición SSD por demonio para DB/WAL (opcional)
Red con al menos una tarjeta de red Gigabit o superior (se recomienda una tarjeta de red 10G) Procesador ceph-mon con al menos un núcleo
La memoria por proceso supera los 2 GB de memoria
El espacio en disco por proceso supera los 10 GB de espacio en el disco duro
El espacio en disco por proceso supera los 2 GB de espacio en el disco duro
El espacio en disco por proceso El proceso supera los 10 GB de espacio en el disco duro
La red tiene al menos un procesador ceph-mds de tarjeta de red gigabit, al menos un núcleo
de memoria y cada proceso tiene al menos 2 GB de memoria
Espacio en disco, al menos 1 MB de disco duro espacio para cada proceso
La red debe tener al menos una tarjeta de red gigabit