2 Requisitos y recomendaciones de hardware #
Los requisitos de hardware de Ceph dependen en gran medida de la carga de trabajo de E/S. Se deben tener en cuenta los requisitos y recomendaciones de hardware siguientes como punto de partida para realizar una planificación detallada.
En general, las recomendaciones proporcionadas en esta sección dependerán de los procesos que haya activos. Si hay varios procesos en el mismo equipo, los requisitos de CPU, RAM, espacio en disco y red deben sumarse.
2.1 Descripción general de la red #
Ceph tiene varias redes lógicas:
Una red de procesador frontal denominada
red pública.Una red interna de confianza, la red de procesador final, denominada
red de clúster. Este campo es opcional.Una o varias redes cliente para las pasarelas. Esto es opcional y queda fuera del alcance de este capítulo.
La red pública es la red a través de la cual los daemons de Ceph se comunican entre sí y con sus clientes. Esto significa que todo el tráfico del clúster de Ceph pasa por esta red, excepto en el caso de que se configure una red de clúster.
La red de clúster es la red de procesador final entre los nodos de OSD para la réplica, el reequilibrado y la recuperación. Si se configura, esta red opcional proporcionaría, idealmente, el doble del ancho de banda que la red pública, con réplica de tres vías por defecto, ya que el OSD primario envía dos copias a otros OSD a través de esta red. La red pública se encuentra entre los clientes y las pasarelas por un lado para comunicarse con los monitores, los gestores, los nodos de MDS y los nodos de OSD. También la utilizan los monitores, los gestores y los nodos MDS para comunicarse con los nodos de OSD.
2.1.1 Recomendaciones de red #
Se recomienda tener una única red tolerante a fallos con suficiente ancho de banda para satisfacer sus necesidades. Para el entorno de red pública de Ceph, se recomiendan dos interfaces de red de 25 GbE (o más rápidas) asociadas mediante 802.3ad (LACP). Esto se considera la configuración mínima para Ceph. Si también utiliza una red de clúster, se recomiendan cuatro interfaces de red de 25 GbE asociadas. La asociación de dos o más interfaces de red proporciona un mejor rendimiento mediante la agregación de enlaces y, mediante enlaces y conmutadores redundantes, mejora la tolerancia a fallos y la facilidad de mantenimiento.
También puede crear VLAN para aislar diferentes tipos de tráfico a través de una asociación. Por ejemplo, puede crear una asociación para proporcionar dos interfaces VLAN, una para la red pública y la segunda para la red de clúster. Sin embargo, esto no es necesario al configurar la red de Ceph. Encontrará información detallada sobre la asociación de las interfaces en https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-network.html#sec-network-iface-bonding.
La tolerancia a fallos se puede mejorar aislando los componentes en dominios de fallo. Para mejorar la tolerancia a fallos de la red, la asociación de una interfaz desde dos tarjetas de interfaz de red (NIC) independientes ofrece protección contra fallos de una sola NIC. Del mismo modo, la creación de una asociación entre dos conmutadores protege contra el fallo de un conmutador. Se recomienda consultar con el proveedor del equipo de red para determinar el nivel de tolerancia a fallos necesario.
La configuración de red de administración adicional (que permite, por ejemplo, separar las redes SSH, Salt o DNS) no se ha probado ni se admite.
Si los nodos de almacenamiento se configuran a través de DHCP, es posible que los tiempos límite por defecto no sean suficientes para que la red se configure de forma correcta antes de que se inicien los daemons de Ceph. Si esto ocurre, los MON y los OSD de Ceph no se iniciarán correctamente (al ejecutar systemctl status ceph\* se producirán errores de tipo "no se puede asociar"). Para evitar este problema, se recomienda aumentar el tiempo límite del cliente DHCP a al menos 30 segundos en cada nodo del clúster de almacenamiento. Para hacerlo, hay que cambiar los valores siguientes en cada nodo:
En /etc/sysconfig/network/dhcp, defina
DHCLIENT_WAIT_AT_BOOT="30"
En /etc/sysconfig/network/config, defina
WAIT_FOR_INTERFACES="60"
2.1.1.1 Adición de una red privada a un clúster en ejecución #
Si no especifica una red de clúster durante la distribución de Ceph, se considera que se trata de un único entorno de redes público. Aunque Ceph funciona correctamente con una red pública, su rendimiento y la seguridad mejoran si se establece una segunda red de clúster privada. Para que admitan dos redes, cada nodo de Ceph debe tener al menos dos tarjetas de red.
Debe aplicar los cambios siguientes a cada nodo de Ceph. Hacerlo en un clúster pequeño es relativamente rápido, pero si el clúster está formado por cientos o miles de nodos, puede tardarse mucho tiempo.
Defina la red del clúster mediante el comando siguiente:
#ceph config set global cluster_network MY_NETWORKReinicie los OSD para asociarlos a la red de clúster especificada:
#systemctl restart ceph-*@osd.*.serviceCompruebe que la red de clúster privada funciona según lo previsto en el nivel de sistema operativo.
2.1.1.2 Nodos de monitor en subredes diferentes #
Si los nodos de monitor se encuentran en varias subredes, por ejemplo, se encuentran en distintas salas y emplean conmutadores distintos, es necesario especificar la dirección de la red pública con notación CIDR.
cephuser@adm > ceph config set mon public_network "MON_NETWORK_1, MON_NETWORK_2, MON_NETWORK_NPor ejemplo:
cephuser@adm > ceph config set mon public_network "192.168.1.0/24, 10.10.0.0/16"
Si especifica más de un segmento de red para la red pública (o de clúster) como se describe en esta sección, cada una de estas subredes debe ser capaz de encaminarse a todas las demás; de lo contrario, los MON y otros daemons de Ceph en diferentes segmentos de la red no podrán comunicarse entre sí y se producirá una situación de clústeres malinformados. Además, si está utilizando un cortafuegos, asegúrese de incluir cada dirección IP o subred en sus iptables y abrir puertos para ellos en todos los nodos según sea necesario.
2.2 Configuraciones de varias arquitecturas #
SUSE Enterprise Storage admite arquitecturas x86 y Arm. Al considerar cada arquitectura, es importante tener en cuenta que desde la perspectiva de los núcleos por OSD, la frecuencia y la RAM, no hay diferencia real entre las arquitecturas de CPU en lo que respecta al tamaño.
como ocurre con los procesadores x86 más pequeños (que no son de servidor), los núcleos basados en Arm de menor rendimiento podrían no proporcionar una experiencia óptima, especialmente si se utilizan para repositorios codificados de borrado.
En toda la documentación se utiliza SYSTEM-ARCH en lugar de x86 o Arm.
2.3 Configuración del hardware #
Para obtener el mejor resultado del producto, se recomienda comenzar con la configuración de clúster recomendada. Para un clúster de prueba o uno con menos requisitos de rendimiento, se indica una configuración de clúster mínima compatible.
2.3.1 Configuración de clúster mínima #
Una configuración de clúster mínima para el producto consta de:
Al menos cuatro nodos físicos (nodos de OSD) con coubicación de servicios
Ethernet dual de 10 Gb como red asociada
Un nodo de administración independiente (se puede virtualizar en un nodo externo)
Una configuración detallada está formada por:
Un nodo de administración independiente con 4 GB de RAM, cuatro núcleos y 1 TB de capacidad de almacenamiento. Normalmente, se trata del nodo master de Salt. Los servicios y pasarelas de Ceph, como Ceph Monitor, el servidor de metadatos, Ceph OSD, Object Gateway o NFS Ganesha no se admiten en el nodo de administración, ya que necesita organizar los procesos de actualización del clúster de forma independiente.
Al menos cuatro nodos de OSD físicos, con ocho discos de OSD cada uno, consulte los requisitos en la Sección 2.4.1, “Requisitos mínimos”.
La capacidad total del clúster debe ajustarse de modo que, incluso si un nodo no está disponible, la capacidad total utilizada (incluida la redundancia) no supere el 80 %.
Tres instancias de Ceph Monitor. Por motivos de latencia, los monitores deben ejecutarse desde el almacenamiento SSD/NVMe, no desde los discos duros.
Los monitores, el servidor de metadatos y las pasarelas se pueden coubicar en los nodos de OSD; encontrará más información sobre la coubicación de monitores en la Sección 2.12, “Servidor compartido por varios OSD y monitores”. Si tiene servicios coubicados, es necesario sumar los requisitos de memoria y CPU.
iSCSI Gateway, Object Gateway y el servidor de metadatos requieren al menos 4 GB de RAM y cuatro núcleos.
Si utiliza CephFS, S3/Swift o iSCSI, se requieren al menos dos instancias de las funciones respectivas (servidor de metadatos, Object Gateway e iSCSI) para la redundancia y la disponibilidad.
Los nodos deben estar dedicados a SUSE Enterprise Storage y no deben utilizarse para ninguna otra carga de trabajo física, ni en contenedores ni virtualizada.
Si alguna de las pasarelas (iSCSI, Object Gateway, NFS Ganesha, servidor de metadatos, etc.) se distribuye dentro de máquinas virtuales, estas no deben estar alojadas en equipos físicos que dan servicio a otras funciones del clúster. (Esto no es necesario, ya que se admiten como servicios coubicados).
Al distribuir servicios como máquinas virtuales en hipervisores fuera del clúster físico central, se deben respetar los dominios de fallo para garantizar la redundancia.
Por ejemplo, no distribuya varias funciones del mismo tipo en el mismo hipervisor, como varias instancias de MON o MDS.
Al distribuir dentro de máquinas virtuales, es fundamental asegurarse de que los nodos cuentan con una conectividad de red sólida y una sincronización del tiempo de trabajo adecuada.
Los nodos del hipervisor deben tener el tamaño adecuado para evitar la interferencia de otras cargas de trabajo que consumen recursos de CPU, RAM, red y almacenamiento.
2.3.2 Configuración recomendada para clúster de producción #
Si el tamaño del clúster ha aumentado, se recomienda reubicar los monitores Ceph Monitor, los servidores de metadatos y las pasarelas en nodos independientes para mejorar la tolerancia a fallos.
Siete nodos de almacenamiento de objeto
Ningún nodo individual debe superar aproximadamente el 15 % del almacenamiento total.
La capacidad total del clúster debe ajustarse de modo que, incluso si un nodo no está disponible, la capacidad total utilizada (incluida la redundancia) no supere el 80 %.
Ethernet de 25 Gb o superior, asociados para el clúster interno y la red pública externa cada uno.
Más de 56 OSD por clúster de almacenamiento.
Consulte la Sección 2.4.1, “Requisitos mínimos” para obtener más recomendaciones.
Nodos de infraestructura física dedicados.
Tres nodos de Ceph Monitor: 4 GB de RAM, procesador de 4 núcleos, SSD RAID 1 para el disco.
Consulte la Sección 2.5, “Nodos de monitor” para obtener más recomendaciones.
Nodos de Object Gateway: 32 GB de RAM, procesador de 8 núcleos, SSD para el disco.
Consulte la Sección 2.6, “Nodos de Object Gateway” para obtener más recomendaciones.
Nodos de iSCSI Gateway: 16 GB de RAM, procesador de 8 núcleos, SSD para el disco.
Consulte la Sección 2.9, “Nodos de iSCSI Gateway” para obtener más recomendaciones.
Nodos de servidor de metadatos (uno activo y uno en hot standby): 32 GB de RAM, procesador de 8 núcleos, SSD RAID 1 para el disco.
Consulte la Sección 2.7, “Nodos de servidor de metadatos” para obtener más recomendaciones.
Un nodo de administración de SES: 4 GB de RAM, procesador de 4 núcleos, SSD RAID 1 para el disco.
2.3.3 Configuración de múltiples rutas #
Si desea utilizar hardware de múltiples rutas, asegúrese de que LVM puede acceder a multipath_component_detection = 1 en el archivo de configuración en la sección devices (dispositivos). Esto se puede comprobar mediante el comando lvm config.
Como alternativa, asegúrese de que LVM filtre los componentes de múltiples rutas de un dispositivo mediante la configuración de filtro de LVM. Esto será específico para cada host.
Esta configuración no se recomienda y solo debe plantearse si no es posible definir multipath_component_detection = 1.
Para obtener más información acerca de la configuración de múltiples rutas, consulte https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-multipath.html#sec-multipath-lvm.
2.4 Nodos de almacenamiento de objetos #
2.4.1 Requisitos mínimos #
Las siguientes recomendaciones de CPU sirven para los dispositivos, independientemente del uso por parte de Ceph:
1 subproceso de CPU de 2 GHz por disco giratorio.
2 subprocesos de CPU de 2 GHz por SSD.
4 subprocesos de CPU de 2 GHz por NVMe.
Redes 10 GbE separadas (pública/cliente e interna): se requieren 4 de 10 GbE; se recomiendan 2 de 25 GbE.
Total de RAM requerida = número de OSD x (1 GB +
osd_memory_target) + 16 GBConsulte el Sección 28.4.1, “Configuración del tamaño automático del caché” para obtener más detalles sobre el valor de
osd_memory_target.Discos OSD en configuraciones JBOD o configuraciones RAID-0 individuales.
El diario del OSD puede encontrarse en el disco del OSD.
Los discos OSD deben utilizarse exclusivamente para SUSE Enterprise Storage.
Disco o unidad SSD dedicados para el sistema operativo, preferiblemente en una configuración de RAID 1.
Asigne al menos 4 GB adicionales de RAM si este host OSD va a alojar parte de un repositorio de caché utilizado para la organización en niveles del caché.
Los monitores Ceph Monitor, la pasarela y los servidores de metadatos pueden encontrarse en los nodos de almacenamiento de objeto.
Por motivos de rendimiento del disco, los nodos de OSD son nodos de hardware. Ninguna otra carga de trabajo debe ejecutarse en un nodo de OSD a menos que sea una configuración mínima de Ceph Monitors y gestores Ceph Managers.
Discos SSD para el diario con una proporción de 6:1 entre el diario de SSD y los OSD.
Asegúrese de que los nodos de OSD no tienen asignados dispositivos de bloques en red, como iSCSI o imágenes de dispositivos de bloques RADOS.
2.4.2 Tamaño mínimo de disco #
Existen dos tipos de espacio de disco necesarios para ejecutarse en OSD: el espacio para el dispositivo WAL/DB, y el espacio principal para los datos almacenados. El valor mínimo (y por defecto) para WAL/DB es de 6 GB. El espacio mínimo para los datos es de 5 GB, ya que a las particiones de menos de 5 GB se les asigna automáticamente un peso de 0.
Por lo tanto, aunque el espacio mínimo de disco para un OSD es de 11 GB, no se recomienda usar discos de menos de 20 GB, ni siquiera con fines de prueba.
2.4.3 Tamaño recomendado para el dispositivo WAL y DB de BlueStore #
Consulte la Sección 1.4, “BlueStore” para obtener más información sobre BlueStore.
Se recomienda reservar 4 GB para el dispositivo WAL. Aunque el tamaño mínimo de la base de datos es de 64 GB para las cargas de trabajo de solo RBD, el tamaño de base de datos recomendado para las cargas de trabajo de Object Gateway y CephFS es del 2 % de la capacidad del dispositivo principal (pero al menos de 196 GB).
ImportanteSe recomiendan volúmenes de base de datos más grandes para las distribuciones de alta carga, especialmente si hay un uso elevado de RGW o CephFS. Reserve parte de la capacidad (ranuras) para instalar más hardware y disponer de más espacio en la base de datos si es necesario.
Si tiene previsto colocar el dispositivo WAL y el dispositivo DB en el mismo disco, se recomienda usar una partición única para ambos dispositivos, en lugar de tener una partición independiente para cada uno. Esto permite a Ceph utilizar también el dispositivo DB para el funcionamiento de WAL. Por lo tanto, la gestión del espacio de disco es más eficaz, ya que Ceph utiliza la partición de DB para WAL solo si es necesario. Otra ventaja es que la probabilidad de que la partición WAL se llene es muy pequeña, y si no se utiliza por completo, su espacio no se desperdicia, sino que se usa para el funcionamiento del dispositivo DB.
Para compartir el dispositivo DB con el dispositivo WAL, no especifique el dispositivo WAL: especifique solo el dispositivo DB.
Encontrará más información sobre cómo especificar un diseño de OSD en el Sección 13.4.3, “Adición de OSD mediante la especificación DriveGroups”.
2.4.4 SSD para particiones WAL/DB #
Las unidades de estado sólido (SSD) no tienen piezas móviles. Esto reduce el tiempo de acceso aleatorio y la latencia de lectura, a la vez que acelera el rendimiento de los datos. Dado que su precio por MB es mucho mayor que el de los discos duros giratorios, las unidades SSD solo son adecuadas para almacenamiento de menor tamaño.
Los OSD pueden tener una mejora significativa del rendimiento si almacenan sus particiones WAL/DB en una unidad SSD y los datos del objeto en un disco duro independiente.
Dado que las particiones WAL/DB ocupan relativamente poco espacio, puede compartir un disco SSD con varias particiones WAL/DB. Tenga en cuenta que con cada partición WAL/DB, el rendimiento del disco SSD se resiente. No es recomendable compartir más de seis particiones WAL/DB en el mismo disco SSD, o 12 en discos NVMe.
2.4.5 Número máximo de discos recomendado #
Puede tener tantos discos como permita un servidor. Pero existen algunos asuntos que debe tener en cuenta a la hora de planificar el número de discos por servidor:
Ancho de banda de red. Cuantos más discos haya en un servidor, más datos deben transferirse a través de las tarjetas de red para las operaciones de escritura del disco.
Memoria. La RAM que supere los 2 GB se utiliza para el caché de BlueStore. Con el valor por defecto de
osd_memory_targetde 4 GB, el sistema tiene un tamaño de caché inicial razonable para los medios giratorios. Si utiliza SSD o NVME, plantéese la posibilidad de aumentar el tamaño de la memoria caché y la asignación de RAM por OSD para maximizar el rendimiento.Tolerancia a fallos. Si el servidor falla por completo, cuantos más discos tenga, más OSD perderá temporalmente el clúster. Además, para mantener las reglas de réplica en ejecución, necesita copiar todos los datos desde el servidor que ha fallado a los demás nodos del clúster.
2.5 Nodos de monitor #
Se necesitan al menos tres nodos de MON. El número de monitores debe ser siempre impar (1+2n).
4 GB de RAM.
Procesador con cuatro núcleos lógicos.
Se recomienda un disco SSD u otro tipo de almacenamiento suficientemente rápido para los monitores, específicamente para la vía
/var/lib/cephde cada nodo de monitor, ya que el quórum puede ser inestable con latencias elevadas de disco. Se recomiendan dos discos con configuración RAID 1 para aportar redundancia. Se recomienda utilizar discos distintos, o al menos particiones de disco independientes para los procesos de monitor a fin de proteger el espacio disponible en el monitor frente a estados como la ralentización del archivo de registro.Solo debe haber un proceso de monitor por nodo.
La mezcla de nodos de OSD, MON y Object Gateway solo se admite si los recursos de hardware disponibles son suficientes. Esto significa que deberán sumarse los requisitos de todos los servicios.
Dos interfaces de red vinculadas a varios conmutadores.
2.6 Nodos de Object Gateway #
Los nodos de Object Gateway deben tener al menos seis núcleos de CPU y 32 GB de RAM. Si hay otros procesos ubicados en el mismo equipo, deben sumarse sus requisitos.
2.7 Nodos de servidor de metadatos #
El tamaño correcto de los nodos del servidor de metadatos depende del caso de uso específico. Por lo general, cuantos más archivos abiertos deba gestionar el servidor de metadatos, más CPU y RAM se necesitará. Los requisitos mínimos de son los descritos a continuación:
4 GB de RAM para cada daemon de servidor de metadatos.
Interfaz de red vinculada.
2,5 GHz de CPU con un mínimo de 2 núcleos.
2.8 Nodo de administración #
Se requieren al menos 4 GB de RAM y una CPU de cuatro núcleos. Esto incluye la ejecución del master de Salt en el nodo de administración. Para clústeres de gran tamaño con cientos de nodos, se recomiendan 6 GB de RAM.
2.9 Nodos de iSCSI Gateway #
Los nodos de iSCSI Gateway deben tener al menos seis núcleos de CPU y 16 GB de RAM.
2.10 SES y otros productos SUSE #
Esta sección contiene información importante acerca de la integración de SES con otros productos SUSE.
2.10.1 SUSE Manager #
SUSE Manager y SUSE Enterprise Storage no están integrados; por lo tanto, SUSE Manager no puede gestionar actualmente un clúster de SES.
2.11 Limitaciones de nombres #
En general, Ceph no admite caracteres no ASCII en los archivos de configuración, los nombres de repositorio, los nombres de usuario, etc. Cuando configure un clúster de Ceph, se recomienda utilizar solo caracteres alfanuméricos sencillos (A-z, a-z, 0-9) y la puntuación mínima (".", "-" o "_") en todos los nombres de objeto y configuración de Ceph.
2.12 Servidor compartido por varios OSD y monitores #
Aunque es técnicamente posible ejecutar varios OSD y monitores MON en el mismo servidor en entornos de prueba, se recomienda encarecidamente disponer de un servidor independiente para cada nodo de monitor en entornos de producción. El motivo principal es el rendimiento: cuantos más OSD tenga el clúster, más operaciones de E/S deberán realizar los nodos de MON. Y cuando se comparte un servidor entre un nodo de MON y varios OSD, las operaciones de E/S de los OSD suponen un factor limitador para el nodo de monitor.
Otra consideración importante a tener en cuenta es si se comparten discos entre un OSD, un nodo de MON y el sistema operativo en el servidor. La respuesta es sencilla: si es posible, dedique un disco independiente al OSD y un servidor independiente a un nodo de monitor.
Aunque Ceph admite los OSD basados en directorios, un OSD siempre debe tener un disco dedicado distinto al que se use para el sistema operativo.
Si es realmente necesario ejecutar el OSD y el nodo de MON en el mismo servidor, ejecute MON en un disco independiente montando ese disco en el directorio /var/lib/ceph/mon para mejorar ligeramente el rendimiento.