Materias de Storage para SQL Managed Instance habilitado para Azure Arc
El almacenamiento es un componente crítico en cualquier implementación de SQL Managed Instance habilitado para Azure Arc (SQL Managed Instance habilitado para Arc). Conocer la forma en que los conceptos relacionados con el almacenamiento que se describen en este documento afectan al funcionamiento de los clústeres de Kubernetes es un aspecto importante no solo de las opciones de diseño del almacenamiento, sino también de su administración.
En lugar de interactuar directamente con el almacenamiento subyacente, Kubernetes proporciona una capa de abstracción a varias tecnologías de almacenamiento a través de las clases de almacenamiento. Tanto los proveedores de nube como los proveedores de hardware u otras plataformas administradas por Kubernetes ofrecen distintas opciones de StorageClass que se ajustan a escenarios de implementación y entornos concretos.
SQL Managed Instance habilitado para Arc ni limita el uso de ninguna clase de almacenamiento ni exige su uso, por lo que es importante elegir el diseño y la configuración de almacenamiento correctos. El diseño del almacenamiento de SQL Managed Instance habilitado para Arc es tan importante como elegir los dispositivos de almacenamiento de respaldo para un servidor de SQL Server cuando se ejecutan en máquinas virtuales o en equipos sin sistema operativo. En última instancias, estas opciones representan los requisitos de objetivo de punto de recuperación, RTO, capacidad y rendimiento.
En el caso de las implementaciones de SQL Managed Instance habilitado para Arc, es fundamental planear eficazmente tanto las funcionalidades de almacenamiento como la configuración para que funcionen correctamente. Si sigue leyendo, obtendrá información sobre los factores relacionados con el almacenamiento que se deben tener en cuenta, así como recomendaciones para configurar SQL Managed Instance habilitado para Arc.
Architecture
En el siguiente diagrama arquitectónico se muestra el diseño lógico de los componentes de los servicios de datos habilitados para Azure Arc. Estos componentes incluyen un controlador de datos de Azure Arc necesario y una o varias instancias de SQL Managed Instance habilitado para Arc que contengan bases de datos aprovisionadas como referencia. Tanto el controlador de datos de Azure Arc como SQL Managed Instance habilitado para Arc ofrecen opciones para los dispositivos de almacenamiento de respaldo, que dependen de los proveedores de infraestructura de almacenamiento y distribución de Kubernetes.
Consideraciones de diseño
A continuación se indican las consideraciones para el diseño y la configuración del almacenamiento.
Clases de almacenamiento
Es muy importante elegir el objeto StorageClass y la configuración adecuados de Kubernetes para los componentes de los servicios de datos habilitados para Azure Arc, ya que mejora el rendimiento, la resistencia y la capacidad del almacenamiento de datos.
StorageClass, PersistentVolume (PV) y PersistentVolumeClaim (PVC) son objetos de recursos de Kubernetes que el sistema crea en el clúster de Kubernetes al aprovisionar los componentes de los servicios de datos habilitados para Azure Arc.
Las opciones de StorageClass varían en función de lo que ofrezcan tanto el proveedor de nube como el proveedor de hardware, así como de lo que el administrador de Kubernetes haya configurado. PersistentVolumeClaim solicita que se cree un objeto PersistentVolume para el objeto StorageClass y el tamaño solicitados. El diagrama siguiente muestra la relación entre estos recursos de Kubernetes y las posibles opciones de las clases de almacenamiento.
Los recursos de Kubernetes PV y PVC se configuran al aprovisionar el controlador de datos de Azure Arc y SQL Managed Instance habilitado para Arc, respectivamente.
Se puede elegir entre estos dos tipos de almacenamiento:
- Local: un volumen montado en un dispositivo de almacenamiento local conectado al nodo de Kubernetes en el que se ejecuta el pod. Este tipo de almacenamiento normalmente ofrece no solo una menor latencia, sino también un mayor número de operaciones de entrada/salida por segundo (IOPS) y un mejor rendimiento, en comparación con el almacenamiento remoto o compartido.
- Almacenamiento remoto o compartido: dispositivos de almacenamiento conectados a la red que tienden a tener redundancia integrada. Las opciones de almacenamiento habituales son los dispositivos NAS y SAN.
Al elegir un objeto StorageClass, tenga en cuenta los siguientes estándares. Estos criterios serían igual de válidos para cualquier servidor de base de datos que compilara:
- Rendimiento: tanto el rendimiento de entrada y salida (E/S) del dispositivo de almacenamiento como la IOPS deben cubrir las necesidades de la base de datos.
- Relación de lectura y escritura: conocer la carga de trabajo puede ayudarle a elegir el hardware de respaldo que mejor cubra sus necesidades, con un costo adecuado. Las cargas de trabajo en las que hay mucha escritura pueden aprovechar las configuraciones de RAID 0, mientras que los datos a los que se accede con poca frecuencia es posible que se sirvan mejor mediante un almacenamiento en dispositivos SAN.
- Aislamiento y colocalización de bases de datos: todas las bases de datos de una instancia de SQL Managed Instance habilitado para Arc comparten PV, por lo que, si lo desea, puede moverlas a instancias independientes de SQL Managed Instance habilitado para Arc, y así evitar la contención de los recursos de almacenamiento.
- Capacidad: el tamaño de almacenamiento definido debe cubrir la capacidad futura del controlador de datos y las instancias de base de datos, ya que así se evita tener que cambiar el tamaño de un objeto PVC. Tenga en cuenta las limitaciones de almacenamiento del objeto StorageClass elegido.
- Modo de acceso: los proveedores de clases de almacenamiento tienen diferentes modos de acceso, lo que permite utilizar diferentes funcionalidades de montaje, lectura o escritura por parte de los pods. Se requiere RWX (Read Write Many) para el volumen de copia de seguridad de SQL.
- Redundancia: replicación de los datos en la capa de almacenamiento físico (RAID) para admitir la conmutación por error sin problemas si se produce algún error de disco de hardware, algo que es independiente de la redundancia a nivel de base de datos que realizan grupos de disponibilidad (AG).
Tanto el controlador de datos de Azure Arc como los servicios de datos de Arc de SQL Managed Instance habilitado para Arc proporcionan opciones pormenorizadas para configurar diferentes clases de almacenamiento para los datos de las bases de datos. Estos servicios también proporcionan registros, lo que permite que haya flexibilidad al elegir las clases de almacenamiento que más se ajusten a nuestras necesidades.
Controlador de datos
Como requisito previo para crear instancias de SQL Managed Instance habilitado para Arc se requiere un controlador de datos individual de Azure Arc para un clúster de Kubernetes. No se admite que haya más de un controlador de datos en ejecución en un clúster.
El controlador de datos de Azure Arc tendrá cuatro pods con estado diferentes que se ejecutan en el clúster de Kubernetes: Controller SQL, Controller API, Logs DB y Metrics DB. Cada uno de ellos requiere dos volúmenes persistentes para los volúmenes de datos y de registros. Todos los componentes del controlador de datos requieren un objeto StorageClass remoto para garantizar la durabilidad de los datos, ya que los propios componentes del controlador de datos no proporcionan durabilidad de datos de forma nativa.
Asegúrese de tener en cuenta los recursos de proceso y memoria que requiere el controlador de datos de Azure Arc. El diagrama siguiente representa el almacenamiento del controlador de datos, y los recursos PV y PVC de Kubernetes.
El tamaño del volumen predeterminado del controlador de datos es el mínimo recomendado. El almacenamiento que se use depende del número de bases de datos, de cómo se usan las bases de datos y del número de registros generados. Al objeto StorageClass del controlador de datos de Azure Arc no le afecta una latencia baja. A pesar de ello, es posible que el aumento de la velocidad mejore las interfaces de Grafana y Kibana si hay muchas implementaciones de SQL Managed Instance habilitado para Arc en un clúster. Grafana y Kibana son herramientas de visualización de supervisión de código abierto implementadas con el controlador de datos y aprovisionadas con paneles para ver métricas y registros de SQL Managed Instance habilitado para Arc.
Aprovisionamiento del controlador de datos
Al aprovisionar el controlador de datos de Azure Arc, es preciso configurar el objeto StorageClass y la capacidad de almacenamiento tanto de los registros como de los datos. La configuración del almacenamiento de los registros y los datos se aplica a los ocho objetos PV que se crean para los pods del controlador de datos. Durante el aprovisionamiento, puede especificar una plantilla de implementación personalizada que reemplace los parámetros predeterminados, como la capacidad, la retención de registros y los elementos relacionados con la seguridad, como los tipos de servicio de Kubernetes. Una vez completado el aprovisionamiento, se crean los objetos PV y PVC de Kubernetes.
Es importante saber que el objeto StorageClass del controlador de datos no se puede cambiar una vez que se aprovisiona. Si no especifica ningún objeto StorageClass, el controlador de datos usa el predeterminado de Kubernetes, que puede variar según la instancia o el proveedor de Kubernetes que se usen.
Al desinstalar el controlador de datos de Azure Arc, se eliminan todos los volúmenes persistentes asociados a él. Archive los registros de nivel de plano de control de los servicios de datos habilitados para Azure Arc que la organización necesite guardar antes de desinstalar el controlador de datos.
SQL Managed Instance habilitado para Azure Arc
SQL Managed Instance habilitado para Arc ofrece dos niveles diferentes en función de los requisitos empresariales: De uso general y Crítico para la empresa. En ambos niveles, es importante examinar los límites de SQL Managed Instance habilitado para Arc mínimo y máximo, que se pueden configurar, y asegurarse de que el clúster de Kubernetes implementado tenga la capacidad de proceso y memoria adecuada.
En escenarios con varias bases de datos en una instancia de base de datos determinada, todas las bases de datos usan los mismos objetos StorageClass, PVC y PV especificados para SQL Managed Instance habilitado para Arc. Puede haber varias instancias de SQL Managed Instance habilitado para Arc en un único clúster de Kubernetes. Esta configuración permite volúmenes persistentes independientes y puede ayudar a separar la contención de E/S de diferentes bases de datos mediante la implementación de las bases de datos en diferentes instancias de SQL Managed Instance habilitado para Arc.
En la siguiente tabla se describen los distintos volúmenes persistentes que usa cada pod de SQL Managed Instance habilitado para Arc, así como su propósito.
| Volumen-persistente | Descripción | Requisitos de clase de almacenamiento |
|---|---|---|
| data | Archivos de datos de SQL Database (archivos .mdf) | Depende del nivel |
| DataLogs | Archivos de registro de SQL Database (archivos .ldf) | Depende del nivel |
| Registros | Agente de SQL, registros de errores, archivos de seguimiento, registros de estado | Depende del nivel |
| Copias de seguridad | Archivos de copia de seguridad de SQL Server, lo que incluye la copia de seguridad completa, diferencial y del registro de transacciones | Modo de acceso remoto, ReadWriteMany |
Nivel de servicio Uso general
El nivel De uso general nivel de SQL Managed Instance habilitado para Arc debe usar el almacenamiento remoto para la instancia de base de datos, con el fin de que, si se produce un error de un pod, los datos permanezcan disponibles para los pods recién creados. La conmutación por error se administra mediante la orquestación de los pods y nodos de Kubernetes. Esta configuración es menos compleja, en comparación con Crítico para la empresa, que usa grupos de disponibilidad de SQL y varias réplicas de SQL Managed Instance habilitado para Arc. La configuración de pod único del nivel de De uso general significa que se puede minimizar la cantidad de almacenamiento, ya que no hace falta duplicar la capacidad de almacenamiento para otras réplicas.
Nivel de servicio Crítico para la empresa
El nivel Crítico para la empresa usa un modelo con varios pods en el que los volúmenes de datos y de registro se pueden almacenar en clases de almacenamiento locales o remotas. Las clases de almacenamiento local suelen tener menor latencia y mejor rendimiento, ya que el dispositivo de almacenamiento está conectado directamente al nodo. El almacenamiento remoto suele ofrecer redundancia integrada, pero a menudo tiene una menor latencia y rendimiento, en comparación con el almacenamiento local. Tenga en cuenta que el uso de más réplicas de base de datos de nivel Crítico para la empresa requiere volúmenes persistentes adicionales para datos, registros y registros de datos. La capacidad de almacenamiento total necesaria es mucho mayor.
En el diagrama siguiente se muestra la configuración de almacenamiento de nivel Crítico para la empresa para SQL Managed Instance habilitado para Arc con dos réplicas.
El nivel Crítico para la empresa permite configurar dos o tres réplicas secundarias. El grupo de disponibilidad Always On de SQL administra la conmutación por error, lo que reduce el tiempo de inactividad por actualizaciones y errores, con respecto al nivel de De uso general.
La configuración de varias réplicas con la replicación de datos en modo de confirmación sincrónica garantiza una mayor protección frente a errores, como por ejemplo si se produce un error en un pod, nodo o hardware de almacenamiento. Protege contra errores porque hay varias copias de los datos en las réplicas. Considere la posibilidad de configurar réplicas secundarias como instancias de escalado horizontal de lectura, a las que los clientes se puedan conectarse si usan el punto de conexión del cliente de escucha secundario.
Aprovisionamiento y desinstalación de SQL Managed Instance habilitado para Azure Arc
Al aprovisionar SQL Managed Instance habilitado para Arc, tiene la flexibilidad de asignar diferentes clases de almacenamiento a cada uno de los volúmenes persistentes de SQL Managed Instance habilitado para Arc necesarios. Es posible que desee opciones de almacenamiento de mayor rendimiento para datos y registros de datos, pero los volúmenes de registros y de copias de seguridad pueden usar opciones de StorageClass más rentables para ahorrar costos. En aquellos escenarios en los que use el almacenamiento local, asegúrese de que los volúmenes pueden aterrizar en distintos nodos y dispositivos de almacenamiento físico, con el fin de evitar la contención en la E/S del disco. La colocación de datos y registros de datos en la misma unidad física puede provocar contención en dicha unidad de almacenamiento, lo que empeora su rendimiento. En su lugar, considere la posibilidad de colocar los datos y los registros de datos en unidades de almacenamiento independientes para paralelizar la entrada/salida de los datos de base de datos y de los registros.
Cuando se elimina SQL Managed Instance habilitado para Arc, no se quitan sus objetos PV y PVC asociados. Así se garantiza que el acceso a los archivos de base de datos en caso de que la eliminación haya sido involuntaria.
Recomendaciones de diseño
A continuación encontrará recomendaciones para el diseño y la configuración del almacenamiento.
Clases de almacenamiento para cargas de trabajo de producción
En el caso de nubes públicas concretas, las clases de almacenamiento recomendadas para cargas de trabajo de producción se muestran en la tabla siguiente.
| Proveedor | Almacenamiento validado y recomendado |
|---|---|
| Azure Kubernetes Service (AKS) | Azure Managed Disks (nivel Prémium) |
| Amazon Elastic Kubernetes Service (EKS) | Controladores de almacenamiento CSI de Amazon EBS |
| Google (GKE) | Discos persistentes de GCE |
Cuando se elige un objeto StorageClass de producción en escenarios locales o multinube, asegúrese de que es capaz de satisfacer las necesidades de capacidad de almacenamiento, IOPS, redundancia y rendimiento previstos. En las secciones siguientes se proporciona más recomendaciones para estos escenarios.
Diseño del controlador de datos
Elija un objeto StorageClass remoto compartido para garantizar la durabilidad de los datos. En caso de que se quiten un pod o un nodo, puede usar la copia de seguridad del pod y volverlo a conectar al volumen persistente. El objeto StorageClass subrayado debe proporcionar redundancia y alta disponibilidad.
Se recomienda usar una plantilla de implementación personalizada al crear el controlador de datos de los servicios de datos habilitados para Arc. Las plantillas personalizadas permiten ajustar las clases de almacenamiento, el tamaño de almacenamiento de datos y registros, la seguridad y los tipos de servicio de Kubernetes. Puede personalizarlas para ajustarlas a las necesidades de su empresa y entorno. El controlador de datos de Azure Arc requiere un total de ocho volúmenes persistentes. La configuración mínima predeterminada permite 15Gi para datos y 10Gi para registros en los volúmenes persistentes. Configure una capacidad que no solo cumpla las recomendaciones mínimas, sino que admita un mayor crecimiento, ya que tiene muchas implementaciones de SQL Managed Instance habilitado para Arc que se ejecutan en un clúster. Esta configuración evitará tener que cambiar el tamaño de los objetos PVC en el futuro.
Se recomienda elegir un objeto StorageClass de menor latencia en caso de que el clúster tenga muchas bases de datos e implementaciones de SQL Managed Instance habilitado para Arc. Una menor latencia mejora la experiencia del usuario en las interfaces de Grafana y Kibana.
Migración de SQL Managed Instance habilitado para Azure Arc
Se recomienda planear y tener en cuenta todas las bases de datos nuevas y existentes implicadas en la migración e implementación de SQL Managed Instance habilitado para Arc. El planeamiento evita la necesidad de mover bases de datos entre instancias posteriormente.
En función de la organización de clústeres de Kubernetes, aprovisione las implementaciones de SQL Managed Instance habilitado para Arc en distintos clústeres de Kubernetes en función de la necesidad de separar entornos (producción y no producción), regiones y otros factores empresariales. Para más recomendaciones, revise el área de diseño Organización de recursos. Si configura varias instancias de base de datos en un clúster, asegúrese de separar las bases de datos ocupadas en su propia instancia para evitar la contención de entrada/salida.
Use etiquetas de nodo para asegurarse de que las instancias de base de datos se colocan en nodos independientes para distribuir el tráfico de E/S global entre varios nodos. Para configurar las etiquetas, consulte los artículos sobre etiquetas de nodo de Kubernetes y etiquetas de afinidad y etiquetas antiafinidad de nodos de Kubernetes. Si funciona en un entorno virtualizado, asegúrese de que la entrada/salida se distribuye correctamente en el nivel de host físico.
Planee la capacidad de SQL Managed Instance habilitado para Arc para incluir los tamaños de almacenamiento adecuados para datos, registros, registros de datos y copias de seguridad. Cuando se planea la capacidad necesaria para ajustarse tanto a las necesidades actuales como al crecimiento previsto para todas las bases de datos que residirán en las instancias de SQL Managed Instance habilitado para Arc, evita tener que cambiar el tamaño de los objetos PVC en el futuro. Elija unidades físicas independientes para datos y registros de datos para permitir que se produzca actividad de entrada/salida en paralelo. La actividad de E/S paralela provoca una mejora del rendimiento, ya que evita la posible contención causada al usar una unidad compartida.
Aunque hay varios factores que pueden dictar una implementación de los niveles Crítico para la empresa o De uso general de SQL Managed Instance habilitado para Arc, el nivel Crítico para la empresa con almacenamiento local proporciona la latencia más baja y la mayor disponibilidad. Revise el área de diseño de continuidad empresarial de SQL Managed Instance habilitado para Arc para obtener recomendaciones relacionadas con la restauración a un momento dado, la alta disponibilidad y la recuperación ante desastres. Examine también el área de diseño de gobernanza de costos de SQL Managed Instance habilitado para Arc, donde encontrará más información sobre las implicaciones de los costos entre los niveles.
Las siguientes subsecciones proporcionan recomendaciones más específicas para cada nivel:
Recomendaciones del nivel de servicio De uso general
Se recomienda elegir un objeto StorageClass remoto de baja latencia para los volúmenes persistentes Data y DataLogs para obtener un rendimiento óptimo. Evite usar un objeto StorageClass que introduzca particiones de red, como tener un clúster local configurado para usar un objeto StorageClass proporcionado por Internet para los volúmenes persistentes Backup y Logs.
Recomendaciones del nivel de servicio Crítico para la empresa
Se recomienda revisar las diferencias del modo de disponibilidad, que requerirán una configuración diferente para cada modo elegido.
Para los escenarios en que se requiera la latencia más baja posible, elija el almacenamiento local si es una opción de la infraestructura de Kubernetes. Los volúmenes de almacenamiento local deben aterrizar en diferentes dispositivos de almacenamiento subyacentes para evitar que se produzca contención en la entrada/salida del disco y maximizar el rendimiento. El dispositivo de almacenamiento no debe tener varias funciones, como hospedar la partición del sistema operativo.
Para cargas de trabajo de alta disponibilidad en las que se realiza mucha lectura, configure varias réplicas, así como las aplicaciones o clientes para que usen réplicas secundarias como instancias de escalado horizontal de lectura. Las réplicas secundarias no se pueden leer de forma predeterminada; ese valor se puede configurar.
Supervisión
Se recomienda supervisar todos los objetos PVC creados por los servicios de datos habilitados para Arc, incluido el controlador de datos de Azure Arc y todas las instancias de SQL Managed Instance habilitadas para Arc en un clúster. Establezca alertas para recibir notificaciones cuando algún objeto PVC se aproxime a su máxima capacidad. La notificación le permite cambiar el tamaño del objeto PVC antes de alcanzar la capacidad. En el caso de los clústeres conectados directamente, la supervisión de los objetos PVC y la generación de alertas lo realizan Azure Monitor y Container Insights. Al usar clústeres conectados indirectos, realice la supervisión y la generación de alertas en Grafana y Kibana. La instalación de Grafana incluye paneles para métricas de SQL Managed Instance habilitado para Arc y recursos de Kubernetes.
En el artículo sobre las materias de gobernanza de SQL Managed Instance habilitado para Arc encontrará más recomendaciones sobre la supervisión de SQL Managed Instance habilitado para Arc.
Pasos siguientes
Para más información sobre el recorrido de nube híbrida y multinube, consulte los siguientes artículos:
- Examine la configuración de almacenamiento de los servicios de datos habilitados para Azure Arc.
- Examine las distribuciones de Kubernetes validadas de los servicios de datos habilitados para Azure Arc.
- Examine la guía de dimensionamiento de los servicios de datos habilitados para Azure Arc.
- Examine la supervisión con Grafana y Kibana de SQL Managed Instance habilitado para Arc.
- Experimente con escenarios automatizados de SQL Managed Instance habilitado para Azure Arc con Azure Arc Jumpstart.
- Para obtener más información sobre Azure Arc, revise la ruta de aprendizaje de Azure Arc en Microsoft Learn.
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente las Cuestiones de GitHub como mecanismo de retroalimentación para el contenido y lo sustituiremos por un nuevo sistema de retroalimentación. Para más información, consulta: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de