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 5

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 Nodos de almacenamiento de objetos

2.1.1 Requisitos mínimos

  • Se necesitan al menos 4 nodos OSD, con 8 discos OSD cada uno.

  • Para los OSD que no usen BlueStore, se requiere como mínimo 1 GB de RAM por terabyte de capacidad OSD en bruto para cada nodo de almacenamiento OSD. Se recomiendan 1,5 GB de RAM por terabyte de capacidad OSD en bruto. Durante la recuperación, lo óptimo serían 2 GB de RAM por terabyte de capacidad OSD en bruto.

    Para los OSD que utilicen BlueStore, calcule primero el tamaño de RAM que se recomienda para los OSD que no utilizan BlueStore y, a continuación, calcule 2 GB más el tamaño del caché de RAM de BlueStore para cada proceso de OSD. Elija el valor más alto de RAM de esos dos resultados. Tenga en cuenta que el caché de BlueStore por defecto es de 1 GB para unidades HDD y 3 GB para unidades SSD. En resumen, elija el valor máximo de:

    [1GB * OSD count * OSD size]

    O

    [(2 + BS cache) * OSD count]
  • Se requiere como mínimo 1,5 GHz de núcleo CPU lógico por OSD para cada proceso de daemon de OSD. Se recomiendan 2 GHz por proceso de daemon de OSD. Tenga en cuenta que Ceph ejecuta un proceso de daemon de OSD por cada disco de almacenamiento; no cuente los discos reservados exclusivamente para usarse como diarios OSD, diarios WAL, metadatos omap o cualquier combinación de estos tres casos.

  • Ethernet de 10 Gb (dos interfaces de red vinculadas a varios conmutadores).

  • Discos OSD en configuraciones JBOD.

  • 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.

  • Por motivos de rendimiento del disco, los nodos OSD deben instalarse desde cero y no deben estar virtualizados.

2.1.2 Tamaño mínimo de disco

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.1.3 Tamaño recomendado para el dispositivo WAL y DB de BlueStore

Sugerencia
Sugerencia: más información

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

A continuación se indican varias reglas para determinar el tamaño del dispositivo WAL/DB. Si se usa DeepSea para implementar los OSD con BlueStore, se aplican automáticamente las reglas recomendadas y se notifica el administrador al respecto.

  • 10 GB del dispositivo DB por cada terabyte de capacidad OSD (1/100 del OSD).

  • Entre 500 MB y 2 GB para el dispositivo WAL. El tamaño del WAL depende del tráfico de datos y la carga de trabajo, no del tamaño del OSD. Si sabe que un OSD es físicamente capaz de gestionar pequeñas acciones de escritura y sobrescritura a un rendimiento muy elevado, es preferible disponer de dispositivos WAL en exceso a que su número sea insuficiente. Un dispositivo WAL de 1 GB es una opción equilibrada válida para la mayoría de las distribuciones.

  • 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:

    bluestore_block_db_path = "/path/to/db/device"
    bluestore_block_db_size = 10737418240
    bluestore_block_wal_path = ""
    bluestore_block_wal_size = 0
  • Si lo prefiere, puede colocar el dispositivo WAL en su propio dispositivo independiente. En tal caso, se recomienda usar el dispositivo más rápido para el funcionamiento de WAL.

2.1.4 Uso de unidades SSD para diarios OSD

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.1.5 Número máximo de discos recomendados

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. Para obtener un rendimiento óptimo, reserve al menos 2 GB de RAM por terabyte de espacio de disco instalado.

  • 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.2 Nodos de monitor

  • 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.3 Nodos de Object Gateway

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.4 Nodos del 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á. A continuación se muestran los requisitos mínimos:

  • 3 G de RAM por cada daemon del servidor de metadatos.

  • Interfaz de red vinculada.

  • 2,5 GHz de CPU con un mínimo de 2 núcleos.

2.5 Master de Salt

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

2.6 Nodos iSCSI

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

2.7 Recomendaciones de red

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.7.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.

  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.

    sudo systemctl start ceph.target

2.7.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 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 la 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.8 Limitaciones de denominación

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

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.10 Configuración mínima del clúster

  • Cuatro nodos de almacenamiento de objetos

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

    • 32 OSD por clúster de almacenamiento

    • El diario de OSD puede encontrarse en el disco de OSD

    • Un disco de SO dedicado para cada nodo de almacenamiento de objeto

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

    • 1,5 GHz por OSD para cada nodo de almacenamiento de objeto

    • Los monitores Ceph Monitor, la pasarela y los servidores de metadatos pueden encontrarse en los nodos de almacenamiento de objeto

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

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

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

  • Nodo de gestión independiente con 4 GB de RAM, cuatro núcleos y 1 TB de capacidad

2.11 Configuración de clúster de producción recomendada

  • 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.12 SUSE Enterprise Storage y otros productos SUSE

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

2.12.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 SUSE Enterprise Storage.

Imprimir esta página