Procedimientos recomendados de arquitectura para Azure SQL Managed Instance

Familiarícese con SQL Managed Instance guía de confiabilidad del producto: para obtener más información, consulte los siguientes recursos:

• Información general sobre la continuidad empresarial
• Alta disponibilidad
• Lista de comprobación de alta disponibilidad y recuperación ante desastres
• Copias de seguridad automatizadas

Revise cuotas, límites y problemas conocidos de SQL Managed Instance: Sql Managed Instance aplica límites de implementación regionales, recuentos de bases de datos y límites de almacenamiento que varían según el tipo y el nivel de suscripción. Las implementaciones de nivel superior consumen más cuota de núcleos virtuales, lo que restringe el planeamiento de la capacidad regional.

• Tenga en cuenta los problemas conocidos que afectan a los grupos de conmutación por error, el comportamiento de copia de seguridad durante el uso del vínculo de replicación y las restricciones de migración de versiones anteriores de SQL Server. Revise estas limitaciones durante el diseño inicial para evitar restricciones que no se pueden corregir fácilmente más adelante.

Use características nativas de recuperación ante desastres y copia de seguridad: Use la restauración geográfica para recuperarse de una interrupción del servicio. Puede restaurar una base de datos en cualquier instancia administrada de cualquier región Azure. La restauración usa las copias de seguridad con replicación geográfica más recientes.

Utilice la restauración a un momento dado para realizar la recuperación en caso de errores humanos. La restauración a un punto en el tiempo devuelve la base de datos a un momento anterior para recuperar datos de cambios no intencionados. Combínelo con la inmutabilidad de las copias de seguridad para ayudar a protegerse contra el ransomware y la corrupción intencionada de datos.

Anticipe posibles errores: Use el análisis del modo de error para prever errores y planear mitigaciones para SQL Managed Instance.

Cree redundancia a través de la distribución de zona y la selección de nivel adecuada: Use la redundancia de zona y la selección de niveles adecuada para eliminar puntos únicos de error dentro de una región.

• Active la redundancia de nivel de zona para distribuir réplicas entre zonas de disponibilidad. La arquitectura y la idoneidad difieren según la configuración de nivel e implementación.

• Evalúe los efectos de redundancia en el rendimiento y los servicios dependientes, incluida la latencia entre zonas en las cargas de trabajo de procesamiento de transacciones en línea (OLTP) y la alineación del almacenamiento de copia de seguridad con implementaciones con redundancia de zona.

Planee el escalado en torno a los tiempos de ejecución de la operación de administración: Las operaciones de administración tardan horas en lugar de minutos, lo que requiere un enfoque diferente para escalar la estrategia y el planeamiento de la capacidad.

• Anticipe plazos prolongados para la creación inicial en la subred, que requiere significativamente más tiempo debido al aprovisionamiento de clústeres virtuales. Las operaciones simultáneas se ponen en cola secuencialmente dentro de una subred.

• Dimensione las subredes con margen suficiente para futuras ampliaciones. Las subredes infradimensionada restringen el crecimiento y las generaciones de hardware mixto crean clústeres virtuales independientes que consumen direcciones IP adicionales.

• Preaprovisiona instancias en espera cuando necesites tiempos de respuesta estrictos de escalado. Aísle las cargas de trabajo de producción en subredes dedicadas para evitar el bloqueo de operaciones entre instancias.

Configure la supervisión y las alertas para el estado de la instancia y el estado de replicación: priorice las alertas de las métricas que indican de forma temprana riesgos de confiabilidad. Realice un seguimiento de la disponibilidad de las instancias a través de eventos de Resource Health, supervise las transiciones del estado de la operación de administración a través de un registro de actividad y compruebe la finalización automatizada de copias de seguridad periódicamente porque los errores de copia de seguridad pueden aparecer silenciosamente cuando surgen problemas de almacenamiento o sistema de nombres de dominio (DNS). En las instancias configuradas con grupos de conmutación por error, establezca alertas sobre el retraso de replicación con respecto a los umbrales del objetivo de punto de recuperación (RPO) para detectar desviaciones de la replicación geográfica antes de que provoquen una exposición inaceptable a la pérdida de datos.

Las transiciones de estado del grupo de conmutación por error revelan interrupciones antes de que se conviertan en brechas de recuperación.

Implemente técnicas de resiliencia de conexión y autoconservación: Construya resiliencia a nivel de aplicación para mitigar fallos transitorios derivados del mantenimiento planificado, las conmutaciones por error y los cambios de rol en DNS.

• Agregue lógica de reintento con retroceso exponencial que tenga en cuenta la duración real de la conmutación por error y las ventanas ampliadas de actualización de DNS durante una conmutación por error geográfica.

• Prepárese para una degradación del rendimiento por caché fría después de las conmutaciones por error del nivel de Uso general, en las que la instancia se reinicia en un nodo nuevo sin réplicas activas.

• Programar ventanas de mantenimiento durante períodos de tráfico bajo. Escalone las ventanas de mantenimiento entre los pares de grupos de conmutación por error para evitar el mantenimiento simultáneo de ambos miembros.

Diseñe la estrategia de recuperación ante desastres mediante grupos de conmutación por error: Los grupos de conmutación por error replican todas las bases de datos de usuario como una unidad en una instancia secundaria geográfica de otra región, pero no se incluyen las bases de datos del sistema. Debe sincronizar los inicios de sesión, las credenciales, los trabajos del Agente SQL y la configuración de nivel de instancia de forma independiente para evitar errores de autenticación y brechas operativas después de la conmutación por error.

Use los puntos de conexión del agente de escucha del grupo de conmutación por error en las cadenas de conexión para evitar cambios durante la conmutación por error. Sincronice las directivas de retención entre miembros porque los cambios de configuración no se replican. Para entornos híbridos, el vínculo instancia administrada ofrece una ruta de replicación alternativa.

Establezca una línea base de seguridad: Comience con la línea de base de seguridad de Azure para Azure SQL. Céntrese en los controles que más afecta el modelo con ámbito de instancia, incluyendo roles personalizados a nivel de servidor para la segmentación administrativa, la delegación de subredes en redes virtuales para el aislamiento de red, la gestión de claves TDE (Cifrado de Datos Transparente) a nivel de instancia y la auditoría de operadores para el acceso al soporte técnico de Microsoft.

SQL Managed Instance comparte la base de seguridad de Azure SQL, pero presenta controles específicos de la instancia, como ensamblados de Common Language Runtime (CLR), servidores vinculados y agente SQL, que expanden la superficie expuesta a ataques más allá de lo que expone SQL Database. Priorice estos controles en la revisión de línea base.

Aplique estrategias de segmentación mediante controles basados en identidades y de nivel de red: SQL Managed Instance admite la segmentación basada en identidades a través de roles de nivel de servidor y de base de datos que aplican la separación de tareas. Los roles de nivel de servidor personalizados proporcionan una segmentación administrativa detallada que no está disponible en SQL Database. Separar el acceso del plano de control del acceso al plano de datos mantiene la administración de instancias distinta de las operaciones de datos.

La segmentación de nivel de red se basa en la implementación de instancias en subredes delegadas dedicadas en las que los grupos de seguridad de red (NSG) controlan los flujos de tráfico. Evite reutilizar tablas de rutas y grupos de seguridad de red (NSG) entre subredes que participen en el emparejamiento de redes virtuales con subredes de SQL Managed Instance.

Los grupos de instancias comparten recursos de máquina virtual subyacentes, lo que afecta a las garantías de aislamiento de inquilinos al consolidar instancias. Evalúe si las cargas de trabajo que tienen requisitos de seguridad diferentes necesitan instancias independientes.

Integración con Microsoft Entra ID para la administración de identidades y acceso: Sql Managed Instance admite la autenticación de Microsoft Entra a través de varios métodos. Este soporte centraliza la administración de identidades y admite directivas de acceso condicional. SQL Managed Instance también admite la autenticación de Windows mediante Kerberos para entidades de seguridad de Microsoft Entra, una funcionalidad que no está disponible en SQL Database. Puede realizar una migración lift-and-shift de aplicaciones heredadas sin cambios en el código.

Planee la arquitectura de identidad mediante la catalogación de identidades administrativas, de operador y de carga de trabajo. Asignar roles de la base de datos usando principios de mínimos privilegios. Use identidades administradas asignadas por el usuario como identidad de instancia para la integración de servicios de Azure.

Implemente el aislamiento de red mediante Azure Virtual Network: Instancia administrada de SQL se implementa en una subred de red virtual dedicada, que proporciona aislamiento de nivel de red de forma predeterminada y da forma a las decisiones de conectividad y seguridad.

• Mantenga desactivado el punto de conexión público porque crea otra superficie de ataque, y los grupos de conmutación por error y el vínculo de Instancia administrada solo admiten conectividad local de red virtual.

• Delegue la subred de instancia exclusivamente al tipo de instancia administrada y aplique reglas de NSG asistidas por servicio para el control de tráfico.

• Asigne tablas de rutas y NSG únicos a cada subred de SQL Managed Instance para el emparejamiento de redes virtuales. La reutilización de tablas compartidas provoca errores de conectividad.

Configure el cifrado de datos para la protección en reposo y en tránsito: Sql Managed Instance proporciona varias capas de cifrado que cubren los datos en reposo, en tránsito y en el nivel de aplicación. Cada capa requiere decisiones de configuración distintas.

Proteja las configuraciones de instancia para reducir la superficie expuesta a ataques: Sql Managed Instance expone funcionalidades más allá de SQL Database que expanden la superficie expuesta a ataques. Estas capacidades requieren decisiones de endurecimiento específicamente dirigidas, además de controles de gobernanza.

• La directiva de actualización controla la cadencia de revisiones de seguridad. Existe una disyuntiva entre la aplicación inmediata y la compatibilidad con el vínculo de Instancia administrada.

• Agente SQL, servidores vinculados, ensamblados CLR y xp_cmdshell cada uno requiere evaluación de riesgos. Desactive las funcionalidades sin usar y aplique los estándares TLS actuales.

• Use el control de acceso basado en rol de Azure (Azure RBAC) para restringir las operaciones de administración, aplicar bloqueos de recursos y aplicar configuraciones de seguridad a través de Azure Policy.

Proteja las credenciales y las claves de cifrado mediante identidades administradas y Azure Key Vault: Las identidades administradas eliminan las credenciales almacenadas para la conectividad entre instancias y las integraciones entre servicios. Las identidades gestionadas asignadas por el usuario eliminan los secretos de las cadenas de conexión y simplifican la gestión de la rotación de credenciales.

Key Vault proporciona una administración unificada del ciclo de vida de los protectores de TDE y las claves maestras de columna de Always Encrypted. La supervisión del acceso clave detecta patrones de uso inusuales que podrían indicar un riesgo.

Sql Managed Instance usa objetos de credenciales para escribir registros de auditoría en Blob Storage. Renueve estas credenciales antes de que expiren para mantener la continuidad de auditoría. Planee los procedimientos de entrega de credenciales para las identidades que usan la autenticación de SQL durante la migración.

Configure la supervisión de seguridad y el registro de auditoría: La auditoría de SQL Managed Instance admite Azure Blob Storage, Azure Event Hubs y registros de Azure Monitor como destinos de auditoría. La auditoría de operadores proporciona visibilidad sobre las operaciones de soporte técnico de Microsoft en la instancia. La integridad del registro de auditoría requiere controles de evidencia de alteración para el cumplimiento.

La integración de Log Analytics admite consultas avanzadas y correlación de eventos de seguridad, mientras que Event Hubs admite la integración externa de información de seguridad y administración de eventos (SIEM). Microsoft Defender para SQL agrega protección contra amenazas, incluidas las alertas de inyección, fuerza bruta y patrones de acceso inusuales.

Realice un seguimiento de los eventos de autenticación, la ejecución de consultas y los cambios de privilegios a través de especificaciones de auditoría para detectar intentos de escalación y acceso no autorizado.

Cree y mantenga un modelo de costo que tenga en cuenta el modelo de facturación de proceso aprovisionado: Sql Managed Instance usa un modelo de proceso aprovisionado siempre en el que los núcleos virtuales facturan continuamente independientemente del uso. El modelo de costos debe tener en cuenta los controladores de costos principales, que incluyen la selección del nivel de servicio, el recuento de núcleos virtuales, la generación de hardware y la asignación de almacenamiento en función del tamaño máximo configurado.

La facturación con ámbito de instancia implica que todas las bases de datos comparten los costes de proceso, lo que requiere una asignación clara para la refacturación y la presentación de costes. Incluya mecanismos de licenciamiento y compromiso, como Ventaja híbrida de Azure, capacidad reservada y réplicas en espera sin licencia. Cada palanca reduce el costo a través de un mecanismo diferente.

Las restricciones de cuota de núcleo virtual regional pueden forzar arquitecturas de multisuscripción, lo que agrega complejidad al seguimiento y la gobernanza de costos.

Supervisar y analizar los costos para identificar oportunidades de optimización: En el modelo siempre aprovisionado, la computación inactiva sigue generando cargos. Use Microsoft Cost Management para realizar un seguimiento de los costos de proceso, almacenamiento, copia de seguridad y licencias por instancia. Compare el consumo real de almacenamiento con el máximo reservado para detectar el desperdicio en la facturación.

Supervise el uso de recursos para identificar el sobreaprovisionamiento de núcleos virtuales y compruebe si el nivel de servicio actual sigue justificado. Cree alertas de presupuesto, previsión y anomalías para detectar aumentos inesperados del costo a partir del escalado o los cambios de configuración.

Optimice las configuraciones de proceso y licencias para reducir los costos de recursos aprovisionados: Los costos de proceso se acumulan continuamente en el modelo de solo aprovisionamiento, por lo que ajuste el número de núcleos virtuales y optimice las licencias desde el principio. Analice el uso antes de seleccionar la configuración. Use el nivel De uso general cuando las cargas de trabajo toleran una mayor latencia de almacenamiento. La diferencia de nivel es el único factor de coste más grande.

Aplique la Ventaja de Azure Híbrido a las licencias existentes de SQL Server, comprométase con capacidad reservada para cargas de trabajo predecibles y designe las secundarias de los grupos de conmutación por error como réplicas en espera sin licencia cuando se usen únicamente para recuperación ante desastres.

Optimice los costos del entorno en las instancias de producción y no producción: Las configuraciones de producción y no producción idénticas desperdician el presupuesto en un modelo siempre aprovisionado. Diferencie los perfiles de costo del entorno aplicando mecanismos de ahorro específicos de SQL Managed Instance a cada nivel.

• Optimice los entornos no de producción utilizando stop/start en instancias de uso general durante períodos de inactividad predecibles para reducir los costos de cómputo y licencias.

• Diferencie las configuraciones de entorno mediante la implementación de instancias que no son de producción que usan recuentos de núcleos virtuales reducidos y precios de suscripción de pruebas de desarrollo.

• Optimice los entornos de recuperación ante desastres evaluando la restauración geográfica como alternativa de menor coste a los grupos de conmutación por error para cargas de trabajo no críticas.

Consolide cargas de trabajo pequeñas mediante grupos de instancias para mejorar la eficiencia de los recursos: Los grupos de instancias consolidan varias instancias pequeñas en el proceso compartido, lo que reduce la sobrecarga por instancia. Los pools son compatibles con configuraciones más pequeñas de vCore exclusivas para implementaciones agrupadas y están restringidos al nivel de uso general en las generaciones de hardware admitidas.

La computación del grupo se cobra a nivel de grupo, independientemente de cuántas instancias se ejecuten dentro de él, por lo que los vCores no utilizados siguen incurriendo en costos. Las decisiones sobre licencias y capacidad reservada se aplican uniformemente en todas las instancias del grupo.

Las instancias agrupadas comparten recursos de red y disco local, lo que puede crear efectos ruidosos y vecinos. Cada instancia recibe núcleos virtuales dedicados y memoria, pero las cargas de trabajo que requieren un aislamiento más seguro deben implementarse como instancias independientes.

Implemente procedimientos de implementación seguros para los cambios de configuración de instancia: Las operaciones de administración de SQL Managed Instance implican cambios en la infraestructura del clúster virtual que se ejecutan mucho más tiempo que las operaciones típicas de base de datos. Planee las prácticas de implementación en torno a estas duraciones extendidas para minimizar la interrupción de la carga de trabajo.

• Tenga en cuenta la duración extendida de las operaciones de creación, escala y cambio de nivel. No los programe durante las horas punta. Las operaciones dentro de la misma subred se serializan.

• Planee primero las estrategias de reversión y despliegue en etapas que validen los cambios de configuración en instancias no productivas, ya que las operaciones de escalado en cualquier dirección toman un tiempo comparable.

• Coordine los cambios de implementación de los grupos de conmutación por error asegurándose de que las instancias tengan directivas de actualización coincidentes. Programe cambios en las instancias principales y secundarias en momentos diferentes.

Defina la infraestructura como código para las implementaciones de instancias integradas en la red virtual: Sql Managed Instance requiere una implementación integrada de red virtual con delegación de subredes, reglas de NSG y tablas de rutas en vigor antes del aprovisionamiento. Estructure sus plantillas de infraestructura como código (IaC) en capas de dependencias, de modo que primero se implemente la red, después la identidad y RBAC y, por último, los recursos de la instancia.

Configure la detección de desfase de configuración para las reglas de subred, las tablas de rutas y las propiedades de instancia. Use Azure Policy para aplicar estándares de implementación como etiquetas necesarias, niveles permitidos y requisitos de redundancia de zona para instancias de producción.

Diseñe canalizaciones de compilación e implementación para los cambios de esquema e instancia de base de datos: Los cambios en la infraestructura de instancia y las implementaciones de esquemas de base de datos funcionan en escalas temporales fundamentalmente diferentes. Separe las fases de canalización en consecuencia. Use sondeo basado en estado para las fases de infraestructura y puertas de aprobación antes de cualquier operación que desencadene tareas de administración prolongadas.

Los cambios de esquema requieren validación con diferencias de compatibilidad de T-SQL documentadas antes de la implementación. Compruebe la compatibilidad en la canalización y verifique las dependencias de consultas entre bases de datos y las funcionalidades con ámbito de instancia durante la validación posterior a la implementación.

Establezca la observabilidad mediante Azure Monitor y diagnósticos nativos de SQL: La observabilidad de SQL Managed Instance requiere telemetría de la plataforma de Azure Monitor y diagnósticos nativos de SQL, como vistas de administración dinámica (DMV), almacén de consultas y eventos extendidos. Combine estas capas para obtener una vista completa del estado de la instancia y el rendimiento de la carga de trabajo.

Configure la supervisión de la plataforma a través de Azure Monitor aplicando la configuración de diagnóstico en la instancia. Los eventos de la operación de administración aparecen en el registro de actividad y las alertas de Resource Health proporcionan una advertencia temprana de eventos planeados y no planeados. En la base de datos, use almacén de consultas como herramienta principal para el análisis de cargas de trabajo y la optimización de índices. SQL Managed Instance no admite el ajuste automatizado de índices.

Suscríbase a las alertas de Resource Health y a las notificaciones de mantenimiento anticipadas para la advertencia temprana de eventos planeados y no planeados.

Automatizar tareas de administración, supervisión y mantenimiento: SQL Managed Instance incluye el Agente SQL, un programador de trabajos integrado que controla el mantenimiento de la base de datos y las tareas operativas sin orquestación externa. Combine el Agente SQL con automatización de nivel de Azure para una cobertura completa tanto del motor de base de datos como de las operaciones del plano de administración.

• Use Agente SQL para el mantenimiento recurrente de bases de datos, la sincronización de inicios de sesión con las secundarias de los grupos de conmutación por error y las alertas sobre errores de trabajos.

• Use Azure Automation o Azure Functions para las operaciones que requieren la interacción de Azure Resource Manager, como la supervisión de operaciones de administración y la administración de la retención de copias de seguridad.

• Automatice las operaciones del ciclo de vida, como las programaciones de detención e inicio de las instancias aptas durante períodos de inactividad y la configuración de diagnóstico coherente al aprovisionar nuevas instancias.

Establecer prácticas de prueba y validación para las implementaciones de bases de datos: La compatibilidad de SQL Managed Instance con SQL Server admite herramientas de prueba estándar, pero todavía necesita validar las operaciones de administración, las dependencias entre bases de datos y las características con ámbito de instancia. Use entornos de prueba reales de SQL Managed Instance porque SQL Database y SQL Server tienen un comportamiento de operación de administración y infraestructura diferentes.

Llevar a cabo el planeamiento de la capacidad: Sql Managed Instance usa un modelo con ámbito de instancia en el que todas las bases de datos comparten núcleos virtuales, memoria, operaciones de entrada y salida por segundo (IOPS) y almacenamiento. El planeamiento de la capacidad en el patrimonio de la base de datos es esencial porque el consumo de recursos de una base de datos afecta directamente a todos los demás.

Identifique los objetivos de rendimiento para el tiempo de respuesta, el rendimiento y las sesiones simultáneas. Capture las líneas base de rendimiento antes de la migración y los patrones de crecimiento del proyecto para el recuento de bases de datos, el almacenamiento y los volúmenes de transacciones durante el ciclo de vida de la instancia. Tenga en cuenta las restricciones de TempDB específicas del nivel cuando planee cargas de trabajo con un uso intensivo de TempDB.

Las operaciones de administración para el escalado tardan horas en lugar de los minutos típicos de otras ofertas de Azure SQL. Planifique la capacidad con margen suficiente para evitar necesidades urgentes de escalado y coordine las operaciones con las ventanas de mantenimiento para minimizar la interrupción del negocio.

Seleccione la generación de hardware y el nivel de servicio para los requisitos de carga de trabajo: La selección de nivel de servicio y generación de hardware determina la proporción de memoria, las características de E/S y el perfil de latencia disponibles para la carga de trabajo.

Elija la estrategia de escalado adecuada para la carga de trabajo: Sql Managed Instance solo admite el escalado vertical. El servicio no ofrece escalado automático, computación sin servidor ni un nivel de Hiperescala.

• Planifique el escalado vertical teniendo en cuenta ventanas de operación de varias horas para los cambios de nivel, los cambios de generación de hardware y los ajustes de vCore. Programe estas operaciones durante los períodos de mantenimiento planeado.

• Descargue las cargas de trabajo de lectura en la réplica secundaria legible integrada del nivel Crítico para la empresa. Esta réplica atiende consultas de solo lectura sin coste adicional para cargas de trabajo como informes, análisis y lecturas con coherencia final.

• Use memoria flexible en Uso general de nueva generación para ajustar la asignación de memoria independientemente del número de vCore. Los cambios desencadenan una conmutación por error de la instancia como paso final.

Ejecute pruebas de rendimiento para validar el comportamiento de la carga de trabajo de la base de datos: Diseñe pruebas de rendimiento que validen el comportamiento simultáneo de varias bases de datos en el modelo con ámbito de instancia. Incluya combinaciones de transacciones realistas que combinan cargas de trabajo transaccionales, por lotes e informes que se ejecutan simultáneamente. Pruebe con el recuento real de bases de datos y los volúmenes de datos planeados para la instancia.

Capture las líneas base de implementación previa y compare el comportamiento posterior a la migración en diferentes generaciones de hardware y niveles de servicio para confirmar que la configuración seleccionada cumple sus requisitos. Mida el tiempo de recuperación de la carga de trabajo después de conmutaciones por error y operaciones de administración, especialmente en los niveles que usan almacenamiento remoto, donde debe reconstruirse el grupo de búferes.

Identificar y supervisar indicadores de rendimiento: Supervise en los niveles de instancia y base de datos para identificar la contención de recursos porque todas las bases de datos comparten recursos de proceso en el modelo con ámbito de instancia.

• Configure la supervisión en el nivel de instancia para realizar un seguimiento de las métricas principales y establecer alertas sobre los umbrales de uso antes de que se vean afectadas las cargas de trabajo. Incluya el rendimiento de escritura del registro con respecto a los límites de cada nivel.

• Use almacén de consultas como herramienta principal para identificar las consultas con regresión y planear los cambios. Combínelo con el análisis manual de índices porque SQL Managed Instance no admite el ajuste automático de índices.

• Agregue supervisión de recursos de nivel de base de datos para realizar un seguimiento del consumo por base de datos y detectar la contención de recursos compartidos, como TempDB y almacenamiento en memoria.

Optimizar el diseño de cargas de trabajo y el rendimiento de las consultas: SQL Managed Instance incluye funcionalidades de Enterprise Edition que abordan desafíos de rendimiento específicos del modelo con ámbito de instancia, como la gobernanza de recursos entre bases de datos, consultas entre bases de datos, transacciones distribuidas y procesamiento en memoria.

Tenga en cuenta las restricciones de recursos específicas del servicio en la estrategia de optimización. La asignación fija de TempDB, los límites de regulación de la velocidad del registro sobre el rendimiento de escritura y los modelos de IOPS dependientes del nivel presentan tanto restricciones como oportunidades de optimización.