Saltar a contenidoSaltar a navegación de páginas: página anterior [tecla acceso p]/página siguiente [tecla acceso n]
Se aplica a SUSE Enterprise Storage 6

2 Requisitos y recomendaciones de hardware Edit source

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 Configuraciones de varias arquitecturas Edit source

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.

2.2 Configuración mínima del clúster Edit source

  • Se necesitan al menos cuatro nodos OSD, con ocho discos OSD cada uno.

  • Tres nodos de Ceph Monitor (se requiere que la unidad de sistema operativo dedicada sea SSD).

  • Las instancias de iSCSI Gateway, Object Gateway y los servidores de metadatos requieren 4 GB de RAM incremental y cuatro núcleos.

  • Los nodos de Ceph Monitor, Object Gateway y de los servidores de metadatos requieren una distribución redundante.

  • Un nodo de administración independiente con 4 GB de RAM, cuatro núcleos y 1 TB de capacidad. Normalmente, se trata del nodo master Salt. Los servicios y pasarelas de Ceph, como Ceph Monitor, Ceph Manager, el servidor de metadatos, Ceph OSD, Object Gateway o NFS Ganesha no se admiten en el nodo de administración.

2.3 Nodos de almacenamiento de objetos Edit source

2.3.1 Requisitos mínimos Edit source

  • Recomendaciones de CPU:

    • 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úblico/cliente y procesador final de almacenamiento), 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 GB

    Consulte Sección 16.2.1, “Tamaño automático de 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 dedicado para el sistema operativo, preferiblemente en una configuración de RAID 1.

  • Si este host OSD va a alojar parte de un repositorio de caché que se utilice para la clasificación en niveles del caché, asigne al menos 4 GB de RAM adicionales.

  • 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, se recomienda usar nodos OSD instalados desde cero, y no máquinas virtuales.

2.3.2 Tamaño mínimo de disco Edit source

Existen dos tipos de espacio de disco necesarios para ejecutarse en OSD: el espacio para el diario del disco (para FileStore) o dispositivo WAL/DB (para BlueStore), y el espacio primario para los datos almacenados. El valor mínimo (y por defecto) para el diario/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.3.3 Tamaño recomendado para el dispositivo WAL y DB de BlueStore Edit source

Sugerencia
Sugerencia: más información

Consulte la Sección 1.4, “BlueStore” para obtener más información sobre BlueStore.

  • Se recomienda reservar 4 GB para el dispositivo WAL. El tamaño recomendado para DB es de 64 GB para la mayoría de las cargas de trabajo.

  • 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 la Sección 5.5.2, “DriveGroups”.

2.3.4 Uso de unidades SSD para diarios OSD Edit source

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 su diario en una unidad SSD y los datos del objeto en un disco duro independiente.

Sugerencia
Sugerencia: cómo compartir un SSD para varios diarios

Los datos del diario ocupan relativamente poco espacio, por lo que puede montar varios directorios de diario en un único disco SSD. Tenga en cuenta que con cada diario compartido, el rendimiento del disco SSD se resiente. No es recomendable compartir más de seis diarios en el mismo disco SSD o 12 en discos NVMe.

2.3.5 Número máximo de discos recomendados Edit source

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_target de 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.4 Nodos de monitor Edit source

  • Se necesitan al menos tres nodos de Ceph Monitor. 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/ceph de 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, monitor 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.5 Nodos de Object Gateway Edit source

Los nodos de Object Gateway deben tener de seis a ocho núcleos de CPU y 32 GB de RAM (se recomiendan 64 GB). Si hay otros procesos ubicados en el mismo equipo, deben sumarse sus requisitos.

2.6 Nodos del servidor de metadatos Edit source

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:

  • 3 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.7 Master de Salt Edit source

Se requieren al menos 4 GB de RAM y una CPU de cuatro núcleos. Esto incluye la ejecución de Ceph Dashboard en el nodo de administración. Para clústeres de gran tamaño con cientos de nodos, se recomiendan 6 GB de RAM.

2.8 Nodos iSCSI Edit source

Los nodos iSCSI deben tener de seis a ocho núcleos de CPU y 16 GB de RAM.

2.9 Recomendaciones de red Edit source

Es recomendable que el entorno de redes donde tenga previsto ejecutar Ceph sea un conjunto vinculado de al menos dos interfaces de red divididas lógicamente en una parte pública y una parte interna de confianza mediante VLAN. Se recomienda que el modo de vinculación sea 802.3ad, si es posible, para proporcionar el máximo ancho de banda y mayor estabilidad.

La VLAN pública sirve para proporcionar el servicio a los clientes, mientras que la parte interna proporciona la comunicación de red Ceph autenticada. El principal motivo para esto es que, aunque Ceph proporciona autenticación y protección contra los ataques cuando las claves secretas están aplicadas, los mensajes que se utilizan para configurar estas claves podrían transferirse de forma abierta y son vulnerables.

Sugerencia
Sugerencia: nodos configurados a través de DHCP

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 (si se ejecuta systemctl status ceph\* se producirán errores de tipo "unable to bind" [no es posible vincular]). Para evitar este problema, se recomienda aumentar el tiempo límite del cliente DHCP al menos a 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.9.1 Adición de una red privada a un clúster en ejecución Edit source

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.

  1. Detenga los servicios relacionados con Ceph en cada nodo del clúster.

    Añada una línea a /etc/ceph/ceph.conf para definir la red de clúster, por ejemplo:

    cluster network = 10.0.0.0/24

    Si necesita asignar específicamente direcciones IP estáticas o anular los valores de cluster network (red del clúster), puede hacerlo con el comando opcional cluster addr.

  2. Compruebe que la red de clúster privada funciona según lo previsto en el nivel de sistema operativo.

  3. Inicie los servicios relacionados con Ceph en cada nodo del clúster.

    root # systemctl start ceph.target

2.9.2 Nodos de monitor en subredes diferentes Edit source

Si los nodos de monitor se encuentran en varias subredes, por ejemplo, se encuentran en distintas salas y emplean conmutadores distintos, es necesario ajustar el archivo ceph.conf según corresponda. Por ejemplo, si los nodos tienen las direcciones IP 192.168.123.12, 1.2.3.4 y 242.12.33.12, añada las líneas siguientes a su sección global:

[global]
[...]
mon host = 192.168.123.12, 1.2.3.4, 242.12.33.12
mon initial members = MON1, MON2, MON3
[...]

Asimismo, si debe especificar una dirección pública o red por cada monitor, deberá añadir una sección [mon.X] por cada monitor:

[mon.MON1]
public network = 192.168.123.0/24

[mon.MON2]
public network = 1.2.3.0/24

[mon.MON3]
public network = 242.12.33.12/0

2.10 Limitaciones de denominación Edit source

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.11 Un servidor compartido por varios OSD y monitores Edit source

Aunque es técnicamente posible ejecutar varios Ceph OSD y Ceph Monitor 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 monitor. Y cuando se comparte un servidor entre un nodo de monitor 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 monitor 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.

Sugerencia
Sugerencia

Si es realmente necesario ejecutar el OSD y el nodo de monitor en el mismo servidor, ejecute el monitor en un disco independiente montando ese disco en el directorio /var/lib/ceph/mon para mejorar ligeramente el rendimiento.

2.12 Configuración de clúster de producción recomendada Edit source

  • Siete nodos de almacenamiento de objeto

    • Ningún nodo individual debe superar aproximadamente el 15 % del almacenamiento total

    • Ethernet de 10 Gb (cuatro redes vinculadas a varios conmutadores)

    • Más de 56 OSD por clúster de almacenamiento

    • Discos de SO RAID 1 para cada nodo de almacenamiento OSD

    • Discos SSD para el diario con una proporción de 6:1 entre el diario de SSD y los OSD

    • 1,5 GB de RAM por TB de capacidad OSD en bruto para cada nodo de almacenamiento de objeto

    • 2 GHz por OSD para cada nodo de almacenamiento de objeto

  • 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

    • Un nodo de gestión de SES: 4 GB de RAM, procesador de 4 núcleos, SSD RAID 1 para el disco

    • Distribución física redundante de los nodos de pasarela o de servidor de metadatos:

      • Nodos de Object Gateway: 32 GB de RAM, procesador de 8 núcleos, SSD para el disco

      • Nodos de iSCSI Gateway: 16 GB de RAM, procesador de 4 núcleos, SSD para el disco

      • 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

2.13 SUSE Enterprise Storage 6 y otros productos SUSE Edit source

Esta sección contiene información importante acerca de la integración de SUSE Enterprise Storage 6 con otros productos SUSE.

2.13.1 SUSE Manager Edit source

SUSE Manager y SUSE Enterprise Storage no están integrados; por lo tanto, SUSE Manager no puede gestionar actualmente un clúster de SUSE Enterprise Storage.

Imprimir esta página