Aspectos básicos de OpenShift Data Foundation
Virtual Private Cloud Infraestructura clásica Satellite
OpenShift Data Foundation es una solución de almacenamiento de alta disponibilidad que puede utilizar para gestionar el almacenamiento persistente de sus aplicaciones en contenedores.
- ¿Qué es OpenShift Data Foundation?
- OpenShift Data Foundation es una solución de almacenamiento de alta disponibilidad que consta de varios operadores y tecnologías de código abierto como Ceph, NooBaa y Rook. Estos operadores permiten aprovisionar y gestionar almacenamientos de archivos, bloques y objetos para las cargas de trabajo contenerizadas en clústeres de Red Hat® OpenShift® on IBM Cloud®. A diferencia de otras soluciones de almacenamiento donde podría ser necesario configurar controladores y operadores independientes para cada tipo de almacenamiento, ODF es una solución unificada capaz de adaptarse o escalar a las distintas necesidades de almacenamiento. ODF también se puede desplegar en cualquier clúster OCP.
- ¿Cómo funciona OpenShift Data Foundation?
- ODF usa estos dispositivos para crear una capa de almacenamiento virtualizado, donde los datos de aplicación se replican para lograr una alta disponibilidad. Como ODF abstrae el almacenamiento subyacente, puede utilizar ODF para crear reclamaciones de almacenamiento de archivos, bloques o objetos del mismo almacenamiento en bloques subyacente sin formato.
- ODF usa volúmenes de almacenamiento en múltiplos de 3 y replica los datos de aplicación en estos volúmenes. Los volúmenes de almacenamiento subyacentes que se usen en ODF dependerán del tipo de clúster.
- Para los clusters VPC que utilizan máquinas virtuales, los volúmenes de almacenamiento son volúmenes de almacenamiento Block Storage for VPC.
- Para clústeres Classic o VPC que utilizan trabajadores bare metal, los volúmenes de almacenamiento son discos locales en sus nodos trabajadores bare metal.
- En los clústeres de Satellite, los volúmenes de almacenamiento son discos locales en los nodos trabajadores, o bien se pueden aprovisionar discos dinámicamente utilizando un controlador de almacenamiento de bloques compatible.
- ¿Puedo instalar OpenShift Data Foundation en clústeres VPC solo privados?
- Sí, puede instalar ODF en clústeres VPC solo privados a partir de la versión de clúster
4.16.23_1546_openshiftpara trabajadores de CoreOS y4.16.21_1544_openshiftpara trabajadores de RHEL. - ¿Puedo instalar el complemento de OpenShift Data Foundation en clústeres de Satellite ?
- Núm. El complemento de clúster solo está disponible para clústeres clásicos y de VPC.
- ¿Cómo se instala OpenShift Data Foundation en Satellite?
- Puede instalar ODF en Satellite utilizando una de las plantillas de almacenamiento de Satellite. Para obtener más información, consulte la documentación de almacenamiento deSatellite.
odf-local: elija esta plantilla cuando tenga almacenamiento local disponible para los nodos trabajadores. Si los volúmenes de almacenamiento son visibles al ejecutarlsblk, puede utilizar estos discos al desplegar ODF si están en bruto y sin formato.odf-remote: elija esta plantilla si tiene un controlador CSI instalado en el clúster. Por ejemplo, el controladorazuredisk-csi-driver. Puede utilizar el controlador CSI para suministrar dinámicamente volúmenes de almacenamiento al desplegar ODF.
Para una descripción completa de las funciones y ventajas, consulte OpenShift Data Foundation.
Visión general de la arquitectura
Revise el diagrama y la tabla siguientes para saber más sobre OpenShift Data Foundation.
![Arquitectura](images/ODF_components.svg "" caption-side="bottom"}"){: caption="
| Número | Componente ODF | Descripción |
|---|---|---|
| 1 | Clases de almacenamiento de OpenShift Data Foundation | Cuando se despliega ODF, el operador ODF crea clases de almacenamiento de archivos, bloques y objetos en el clúster. Referencie estas clases de almacenamiento en las PVC para reclamar almacenamiento para las aplicaciones. |
| 2 | Almacenamiento en bloques de OSD | Estos dispositivos proporcionan almacenamiento de aplicaciones en el clúster. Cada OSD es un dispositivo de almacenamiento de bloques en bruto que puede ser un disco local del nodo trabajador o aprovisionarse dinámicamente cuando se despliega
ODF. En los clústeres VPC, los dispositivos OSD de almacenamiento en bloques se aprovisionan dinámicamente usando el controlador de Block Storage for VPC. En los clústeres Satellite, se pueden usar volúmenes locales en los nodos trabajadores
o aprovisionar dinámicamente dispositivos de almacenamiento en bloques usando un controlador de dicho almacenamiento que soporte aprovisionamiento dinámico. En los clústeres clásicos, los dispositivos OSD de bloque son discos locales
en los nodos trabajadores. Cuando se despliega ODF, cada dispositivo es montado por un pod OSD. El almacenamiento total disponible a las aplicaciones es igual a osdSize (tamaño de OSD) multiplicado por numOfOsd (número de OSD). |
| 3 | Pods de demonio de almacenamiento de objetos (Object Storage Daemon, OSD) | Los pods OSD gestionan la colocación y replicación de los datos en los dispositivos de almacenamiento. |
| 4 | Pods de supervisión (Mon) | Los pods supervisores mantienen un mapa del clúster de almacenamiento de OpenShift Data Foundation y supervisan el estado de salud de dicho clúster. |
| 5 | Dispositivo de almacenamiento en bloques supervisor (Mon) | Los dispositivos de almacenamiento supervisores son los dispositivos de almacenamiento subyacentes de los pods supervisores. Cada dispositivo supervisor es un dispositivo de almacenamiento de bloques en bruto que puede ser un disco local del nodo trabajador o aprovisionarse dinámicamente cuando se despliega ODF. Cada dispositivo proporciona almacenamiento a un pod supervisor. |
Visión general de Multicloud Object Gateway
La Multicloud Object Gateway consiste en la herramienta de código abierto NooBaa y es un componente de OpenShift Data Foundation. Con Multicloud Object Gateway, se pueden gestionar objetos y grupos en varios proveedores de nube.
| Número | Componente Multicloud Object Gateway | Descripción |
|---|---|---|
| 1 | Almacén de respaldo | Un almacén de respaldo es un grupo de almacenamiento de objetos compatible con s3. En Multicloud Object Gateway, los almacenes de respaldo pueden estar en cualquier entorno de nube independientemente del proveedor. Se pueden conectar varios almacenamientos de respaldo a Multicloud Object Gateway. Cuando se despliega ODF, el almacenamiento de respaldo predeterminado usa dispositivos de almacenamiento de bloques en bruto especificados para el clúster de almacenamiento ODF. No obstante, y de forma opcional, se puede configurar IBM Cloud Object Storage como almacén de respaldo predeterminado. |
| 2 | Clase de grupo | Una clase de grupo consta de uno o más almacenes de respaldo (grupos) y de una política de colocación. Los almacenes de respaldo y las políticas de colocación se pueden configurar para que gestionen los objetos en diversas ubicaciones y nubes. |
| 3 | Clase de almacenamiento | Una clase de almacenamiento en Multicloud Object Gateway es similar a cualquier otra clase de almacenamiento de Kubernetes porque define los parámetros de recursos de almacenamiento. Sin embargo, en Multicloud Object Gateway, cuando se crea una clase de almacenamiento, se especifica la clase de grupo que se desea usar. Al crearse una clase de almacenamiento a partir de la clase de grupo, se puede hacer que los recursos de Multicloud Object Gateway estén disponibles en varios espacios de nombres. |
| 4 | Reclamación de grupo de objetos (OBC) | Una reclamación de grupo de objetos (OBC) se parece a una reclamación de volumen persistente (persistent volume claim, PVC) en que los desarrolladores o los administradores de almacenamiento pueden crear una OBC para reclamar recursos de almacenamiento. Cuando se crea una OBC, se especifica la clase de almacenamiento que se desea usar y, de forma opcional, se proporciona el nombre del grupo de objetos creado dinámicamente. |
| 5 | Secreto | Al crear una reclamación de grupo de objetos, también se crea un secreto de Kubernetes en el clúster. |
| 6 | ConfigMap | Cuando crea una reclamación de grupo de objetos, también se crea un ConfigMap en el clúster. |
| 7 | Grupo de objetos | Cuando se crea una reclamación de grupo de objetos, se aprovisiona dinámicamente un grupo de objetos. El grupo de objetos abstrae uno o más almacenamientos de respaldo en un único recurso. |
| 8 | Aplicación s3 | Una aplicación que utiliza el almacenamiento de objetos. |
| 9 | Referencia de secreto | Una referencia de secreto es una referencia a un secreto Kubernetes del clúster. Cuando se crea una reclamación de grupo de objetos, NooBaa crea los correspondientes secreto y mapa de configuración. Luego se podrán referenciar el secreto y el mapa de configuración en las aplicaciones sin necesidad de incluir directamente las credenciales en las aplicaciones. |
| 10 | Referencia ConfigMap | Una referencia de mapa de configuración es una referencia a un mapa de configuración de Kubernetes del clúster. Cuando se crea una reclamación de grupo de objetos, NooBaa crea dinámicamente los correspondientes secreto y mapa de configuración. El secreto y el mapa de configuración se pueden referenciar en las aplicaciones sin necesidad de incluir las credenciales en ellas. |
| 11 | Recurso de espacio de nombres | Un recurso de espacio de nombres es un grupo compatible con s3. Una vez añadidos los recursos de espacio de nombres (grupos) a Multicloud Object Gateway, se podrán referenciar dichos grupos creando un grupo de espacio de nombres que pueda usarse para leer y escribir en uno o más recursos de espacio de nombres. |
| 12 | Grupo de espacios de nombres | Un grupo de espacios de nombres abstrae uno o más recursos de espacio de nombres en el espacio de nombres de NooBaa. Cuando se crea un grupo de espacios de nombres, se pueden especificar políticas de lectura o escritura en los recursos de espacio de nombres configurados en Multicloud Object Gateway. Por ejemplo, se puede leer de dos grupos en distintos proveedores de nube y escribir en un tercer grupo en otro entorno de nube independiente. |
| 13 | Clave de acceso al grupo de espacios de nombres | La clave de acceso se usa para acceder al grupo de espacios de nombres. Un grupo de espacios de nombres puede incluir varios recursos de espacio de nombres de distintos proveedores de nube o grupos locales. La clave de acceso al grupo de espacios de nombres y la clave secreta se usan en las aplicaciones s3 para configurar el acceso al grupo de espacios de nombres que luego define las políticas de lectura y escritura en los recursos de espacio de nombres que se configuran. |
| 14 | Clave secreta del grupo de espacios de nombres | La clave secreta se usa para acceder al grupo de espacios de nombres. Un grupo de espacios de nombres puede incluir varios recursos de espacio de nombres de distintos proveedores de nube o grupos locales. La clave de acceso al grupo de espacios de nombres y la clave secreta se usan en las aplicaciones s3 para configurar el acceso al grupo de espacios de nombres que luego define las políticas de lectura y escritura en los recursos de espacio de nombres que se configuran. |
| 15 | Política de colocación | Cuando se crea una clase de grupo, hay que especificar una política de colocación. Una política de colocación define cómo se escriben los datos en un almacén de respaldo. La política de colocación de Replicación replica los objetos en almacenes de respaldo de la clase de grupo y la política de colocación de Distribución distribuye los objetos entre dichos almacenes. |
Soporte de características por tipo de facturación
| Soporte de característica | Essentials | Avanzado |
|---|---|---|
| Almacenamiento en bloques | Sí | Sí |
| Almacenamiento de archivos | Sí | Sí |
| Almacenamiento de objetos | Sí | Sí |
| Node y resiliencia de disco | Sí | Sí |
| Automatización basada en operador | Sí | Sí |
| Compresión | Sí | Sí |
| Instantáneas locales y clonación | Sí | Sí |
| Cifrado básico para todo el clúster | Sí | Sí |
| Cifrado avanzado con KMS | No | Sí |
| Recuperación tras desastre regional con réplica | No | Sí |
| Clústeres extendidos-Alta disponibilidad de Metro y recuperación tras desastre | No | Sí |
| Varios clústeres-Alta disponibilidad de Metro y recuperación tras desastre | No | Sí |
Prácticas recomendadas
Revise las secciones siguientes para conocer las prácticas recomendadas al instalar y gestionar ODF.
Planificación
- Planifique la distribución de los nodos trabajadores
- Para garantizar la alta disponibilidad, distribuya el clúster ODF entre los dominios de anomalía. Esta distribución ayuda a minimizar el impacto de las anomalías de nodo y a mantener la estabilidad global del clúster.
- Cumplir las especificaciones mínimas de nodo trabajador
- Los nodos trabajadores que utilizan ODF deben tener 16 vCPUs y 64GB de RAM o superior. Para los clústeres de IBM Classic, el tipo recomendado es
mb4c.32x384.3.8tb.ssdo superior. - Mantener un host en espera para alta disponibilidad
- Para garantizar una alta disponibilidad y minimizar el tiempo de inactividad si falla un host, es aconsejable mantener siempre un host de reserva.
- Cumplir las recomendaciones de recuento de dispositivos de almacenamiento por nodo
- Planifique tener menos de nueve dispositivos de almacenamiento por nodo. Esto ayuda a evitar posibles cuellos de botella y mejora la eficiencia del acceso y la recuperación de datos.
- Utilizar los tamaños y recuentos de dispositivos de almacenamiento recomendados
- Al desplegar almacenamiento local, utilice tamaños de disco de 4 TiB o menores. Es importante asegurarse de que todos los discos del clúster, en todos los nodos de almacenamiento, tengan el mismo tamaño y tipo para un uso óptimo del almacenamiento. Utiliza OSDs de al menos 512Gi.
- Escalar utilizando el factor de réplica predeterminado y la configuración del nodo de almacenamiento
- En OpenShift Data Foundation (ODF), el factor de réplica se establece en 3 de forma predeterminada. Cuando añada capacidad, planifique añadir nodos de almacenamiento en múltiplos de 3.
- Elija la configuración correcta para sus necesidades: Almacenamiento remoto frente a almacenamiento local
- Si tiene menos necesidades de almacenamiento o está utilizando instancias de servidor virtual, el almacenamiento remoto puede ser una opción conveniente y rentable. Sin embargo, si tiene grandes necesidades de almacenamiento, sería más adecuado un clúster bare metal o un almacenamiento de alto rendimiento con baja latencia de red, que utilice almacenamiento local.
- Simplifique la implantación mediante la función de detección automática
- En {: tag-classic-inf} [clásicos*] o entornos con almacenamiento local, aproveche la función de autodescubrimiento para identificar y configurar automáticamente los discos de almacenamiento disponibles en su cluster para ODF. Esta opción elimina la necesidad de selección de disco manual. A menos que existan requisitos de disco específicos para el suministro de ODF, la utilización de la característica de descubrimiento automático agiliza el proceso de despliegue y reduce el potencial de errores de configuración.
- Utilizar clases de almacenamiento metropolitano para instalaciones de ODF en almacenamiento remoto
- Al realizar una instalación de ODF que utiliza almacenamiento remoto, asegúrese de que utiliza una clase de almacenamiento que tiene un
VolumeBindingModedeWaitForFirstConsumerque retrasa la creación del Block Storage hasta que el primer pod que utiliza este almacenamiento esté listo para planificarse. - Dimensionar el despliegue
- Para obtener un análisis detallado de los requisitos de almacenamiento, la herramienta de dimensionamiento para determinar la capacidad de almacenamiento necesaria. También puede utilizar la herramienta de dimensionamiento oficial de Red Hat
- Configurar copias de seguridad periódicas
- Realizar copias de seguridad periódicas del clúster ODF es esencial para garantizar la protección de los datos y facilitar su recuperación en caso de desastre. Sin copias de seguridad regulares, la recuperación de datos de un evento catastrófico se vuelve significativamente más difícil y puede provocar una pérdida de datos permanente.
virtual
- Planificar el uso de nodos de almacenamiento dedicado
- En escenarios con cargas de trabajo pesadas, utilice nodos de almacenamiento dedicado para ODF. Al separar las operaciones de los nodos de almacenamiento, puede lograr un mejor rendimiento y escalabilidad para la infraestructura de almacenamiento.
- Configuración de la supervisión regular de la consola de Red Hat
- La consola Red Hat proporciona información valiosa sobre la salud y el rendimiento de su entorno ODF. Se recomienda supervisar regularmente la consola para mantenerse informado sobre cualquier problema potencial. La consola desencadena alertas siempre que se detectan problemas con ODF, lo que le permite tomar medidas proactivas.
- Direccionar avisos de capacidad con prontitud
- Cuando se emiten avisos de capacidad, es importante abordarlos con prontitud. Ignorar o retrasar la acción en estos avisos puede dar lugar a restricciones de capacidad de almacenamiento y a posibles interrupciones en las cargas de trabajo. Trate los avisos de capacidad como una oportunidad para evaluar sus necesidades de almacenamiento y tomar las medidas adecuadas para mitigar cualquier problema potencial.
Expansión de capacidad
- Comprenda sus opciones para la expansión de capacidad
- Hay dos opciones disponibles para la expansión de capacidad en ODF. La primera opción implica aumentar la capacidad añadiendo más OSD (Object Storage Daemons) en nodos existentes dentro del clúster. Esto permite utilizar los recursos disponibles para ampliar la capacidad de almacenamiento. La segunda opción es ampliar la capacidad añadiendo nuevos nodos al clúster. Una vez aumentado el número de OSD, los OSD se suministrarán automáticamente en los nodos recién añadidos.
Actualizar
- Realizar comprobaciones de estado sustituyendo nodos
- Evite sustituir un nodo de almacenamiento si ODF no está en buen estado. Antes de continuar con la sustitución del nodo, verifique siempre el estado de salud de ODF. Intente resolver los problemas antes de sustituir el nodo que no está en buen estado.
- Mantenga su entorno actualizado
- Mantenga la versión del clúster actualizada a la versión predeterminada o más reciente disponible. Mantenerse al día con la versión de clúster garantiza que puede aprovechar las prestaciones más recientes y mantener la compatibilidad con otros componentes del entorno.
- Realizar actualizaciones de ODF después de actualizaciones de clúster
- Actualice siempre primero el nodo maestro y el nodo trabajador del clúster y, a continuación, vaya a la actualización de ODF. Después de completar una actualización de clúster, es esencial actualizar también ODF. Aunque ODF da soporte a la versión de clúster actual (n) y a la siguiente versión de clúster (n+1), mantenga la versión de ODF igual que la versión de clúster. Esta alineación garantiza una compatibilidad óptima.
- Actualizar nodos de almacenamiento secuencialmente
- Al actualizar los nodos de almacenamiento, se recomienda realizar las actualizaciones una por una. Este enfoque secuencial le permite verificar el estado de ODF después de cada actualización de nodo y garantiza que la infraestructura de almacenamiento permanezca en buen estado durante todo el proceso. Al actualizar los nodos individualmente, puede supervisar de cerca el impacto de cada actualización en ODF e identificar y resolver rápidamente los problemas que puedan surgir.
Recuperación
- Sustituir hosts en mal estado
- Si se produce un desastre local, se recomienda sustituir un host de clúster insalubre por otro sano.
- Siga la documentación para recuperar los OSD
- Cuando un OSD (Object Storage Daemon) se desactiva en OpenShift Data Foundation (ODF), es importante seguir los pasos recomendados para la recuperación. La documentación proporcionada por IBM Cloud Platform proporciona instrucciones detalladas sobre cómo recuperar un OSD en tales situaciones.
Desinstalación y eliminación
- Supresión de pods y volúmenes persistentes (PV)
- Al eliminar recursos que utilizan clases de almacenamiento ODF, es importante seguir el procedimiento recomendado. Suprima siempre los pods y PV asociados creados utilizando las clases de almacenamiento OF antes de continuar con la supresión de otros recursos.
- Siga el orden de limpieza correcto
- Al poner fuera de servicio o eliminar ODF del clúster, asegúrese de que sigue la documentación al limpiar los recursos. Empiece suprimiendo el recurso
ocscluster, que es responsable de gestionar el ODF. Una vez eliminado el recursoocscluster, continúe eliminando el complemento ODF de la consola de IBM. Si se sigue esta secuencia, se garantiza una eliminación suave y adecuada de ODF del clúster, evitando posibles problemas o conflictos.
Resolución de problemas
- Revisar las alertas y umbrales de capacidad
- ODF genera alertas de capacidad cuando la capacidad de almacenamiento del clúster alcanza determinados umbrales. Estos umbrales se establecen en el 75% (casi lleno) y el 85% (lleno) de la capacidad total. Estas alertas indican que la capacidad de almacenamiento se acerca a sus límites y requiere atención.
- Revisar los problemas comunes
- Al encontrar problemas con OpenShift Data Foundation (ODF), es útil consultar los runbooks disponibles que proporcionan orientación sobre la resolución de problemas comunes. Los runbooks contienen una lista completa de problemas conocidos y sus soluciones correspondientes para ODF.
Despliegue de OpenShift Data Foundation
Revise las opciones de despliegue del proveedor de infraestructura.
- Clústeres de nube privada virtual (Virtual Private Cloud, VPC)
- Puede desplegar ODF utilizando el aprovisionamiento dinámico con Block Storage for VPC o utilizando discos locales en trabajadores bare metal. Puede obtener información adicional consultando Despliegue de OpenShift Data Foundation en clústeres VPC.
- Clústeres de Satellite
- Si desea desplegar ODF en clusters Satellite, puede utilizar la plantilla de almacenamiento Satellite. Para obtener más información, consulte los siguientes enlaces.
- Despliegue de la plantilla de OpenShift Data Foundation para discos remotos aprovisionados dinámicamente.
- Despliegue de la plantilla de OpenShift Data Foundation para discos locales.
- Clústeres clásicos
- ODF se puede desplegar usando discos locales en los nodos trabajadores bare metal. Puede obtener información adicional consultando Despliegue de OpenShift Data Foundation en clústeres clásicos.