Cloud

Abr

2024

¿Sirven de algo los bloqueos de recursos en Azure?

Volvemos con nuestros video blogs esta vez con un vídeo sobre los bloqueos de recursos en Azure. Esta opción nos va a permitir generar un bloqueo sobre un objeto de Azure para evitar que se pueda borrar. De esta manera, cuando alguien intente borrar nuestra base de datos o instancia gestionada desde el portal de Azure obtendrá un error indicando que el recurso está bloqueado.

Bloqueo de Recursos en Azure

Azure ofrece una característica llamada bloqueos que nos permite proteger nuestros recursos contra modificaciones o eliminaciones accidentales. Los bloqueos de recursos pueden ser aplicados a cualquier recurso de Azure, desde suscripciones y grupos de recursos hasta servicios individuales.

Plano de Control y Plano de Datos

Para entender cómo funcionan los bloqueos de recursos, primero debemos entender la diferencia entre el plano de control y el plano de datos en Azure.

El plano de control es responsable de las operaciones de gestión en Azure. Esto incluye acciones como la creación, modificación y eliminación de recursos. Cuando aplicamos un bloqueo de recursos, estamos interactuando con el plano de control.

Por otro lado, el plano de datos se encarga de las operaciones que se realizan en los recursos una vez que están creados. Esto incluye acciones como la lectura y escritura de datos en una base de datos o el envío de mensajes a través de un bus de servicio. Este plano de datos queda fuera del «paraguas» de protección de los bloqueos de recursos.

Aplicando Bloqueos de Recursos

Los bloqueos de recursos se pueden configurar para permitir solo lecturas o para evitar todas las modificaciones. Un bloqueo de solo lectura permitirá que los usuarios vean y consulten los recursos, pero no podrán hacer cambios. Un bloqueo de no modificación, por otro lado, evitará cualquier cambio en el recurso, incluyendo la eliminación.

Conclusión

La protección de nuestros recursos en Azure es esencial para mantener la integridad y seguridad de nuestros datos. Los bloqueos de recursos nos ofrecen una forma eficaz de prevenir borrados y modificaciones no deseadas, asegurando que nuestros recursos permanezcan seguros y protegidos. Sin embargo, esto debe ser combinado por una buena política de permisos en SQL Server o, de lo contrario una operación desde el plano de datos acabará con nuestros sistemas.

Recuerda, como administradores de bases de datos, nuestra prioridad es siempre la seguridad y la protección de nuestros recursos. Asegúrate de utilizar todas las herramientas a tu disposición para mantener tus recursos de Azure seguros. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Abr

2024

Detectando fragmentación de índices en SQL Server y Azure

Volvemos a la carga con un artículo sobre índices de esos que tanto nos gustan. Esta vez vamos a hablar de un tema muy importante y es detectar qué índices están más fragmentados y cómo solucionarlo. A menudo vemos que una mala gestión de los planes de mantenimiento provocan una degradación del rendimiento de las consultas y eso, gran parte de las veces es debido a un problema de fragmentación de índices o falta de mantenimiento de las estadísticas. Hoy vamos a centrarnos en el primero de estos aspectos.

¿Cómo detectar fragmentación en los índices?

Para ver la fragmentación de un índice en concreto podemos hacerlo desde el entorno gráfico de nuestro SSMS, haciendo click derecho sobre el objeto y mirando sus propiedades. Sin embargo, esto no es práctico cuando tenemos cientos de índices en nuestra base de datos y queremos saber de un vistazo cuales son los más fragmentados y cuanto. Para ello, usaremos una consulta sobre la función de sistema sys.dm_db_index_physical_stats.

Otra de las cosas que debemos tener en cuenta es el tamaño de nuestra tabla, con menos de 1000 páginas, el motor de base de datos directamente ignorará los índices nonclustered y, en el caso de los clustered, tampoco vamos a notar diferencia.

Con esto en mente vamos a preparar el script.

SELECT SCHEMA_NAME(ob.[schema_id]) Esquema,
       ob.[name] AS Objeto,
       i.[name] AS Indice,
       ob.type_desc AS TipoObjeto,
       i.type_desc AS TipoIndice,
       stats.page_count AS Paginas,
       stats.avg_fragmentation_in_percent AS Fragmentacion
FROM sys.dm_db_index_physical_stats (db_id(), NULL, NULL, NULL, NULL) stats
INNER JOIN sys.indexes i ON stats.[object_id] = i.[object_id] 
 AND stats.index_id = i.index_id
INNER JOIN sys.objects ob ON i.[object_id] = ob.[object_id]
WHERE ob.[type] IN('U','V')
AND ob.is_ms_shipped = 0
AND i.[type] IN(1,2,3,4)
AND i.is_disabled = 0
AND i.is_hypothetical = 0
AND stats.alloc_unit_type_desc = 'IN_ROW_DATA'
AND stats.index_level = 0
AND stats.page_count >= 1000 
AND stats.avg_fragmentation_in_percent > 5
ORDER BY stats.avg_fragmentation_in_percent desc

Revisemos el script, por un lado podemos ver que a la función para ver las estadísticas de los índices le estamos pasando el id de la base de datos actual para que se ejecute en ese contexto. Esto es para evitar que se ejecute por todas las bases de datos y podamos tener un problema de rendimiento con esta consulta. Por otro lado vemos que solo afecta a tablas y vistas de usuario que tengan un índice clustered, el tipo de índice 0 está excluido de los filtros. Las tablas HEAP (sin índice clustered) necesitan otro tipo de tratamiento. Podemos ver también el filtro para solo mostrar índices con más de 1000 páginas y el de fragmentación superior al 5%, que suele considerarse el umbral de fragmentación aceptable.

Solucionar fragmentación de índices

Ahora que sabemos cuales son los índices más fragmentados debemos actuar y solucionar el problema. Sabemos que tenemos a nuestra disposición dos alternativas: reorganizar o reconstruir. Para elegir entre una opción u otra tenemos varios factores a tener en cuenta.

Por un lado tenemos el modo de operación de estas instrucciones, reorganizar siempre es una operación online lo que significa que solo generará sobre nuestro índice un intento de bloqueo compartido. El índice se podrá seguir leyendo durante la reordenación sin causar bloqueos. En cuanto a la reconstrucción, solo es online si se lo especificamos manualmente y eso solo es posible en ediciones Enterprise de SQL Server o en las bases de datos o instancias gestionadas de Azure. Si la reconstrucción es offline se generará un bloqueo exclusivo sobre el índice.

Por otro lado, la reconstrucción es más eficiente que la reorganización para porcentajes elevados de fragmentación y eso deberemos tenerlo también muy en cuenta.

¿Debería reorganizar o reconstruir mis índices con mucha fragmentación?

Esto no es una ciencia exacta y es un tema sobre el que hay muchas opiniones discordantes. Normalmente se habla de reorganizar los índices con una fragmentación superior al 5 o 10% y menor al 15 o 30%. Como veis es una horquilla muy amplia y para atinar tenemos que pensar en las las implicaciones de estas operaciones que ya hemos visto antes. Yo os voy a contar cómo lo hago yo pero esto es totalmente personal y deberás adaptarlo a cada caso.

Escenario 1: Mantenimiento programado

En este primer escenario estamos hablando de un mantenimiento programado dentro de una ventana de mantenimiento en la que no hay interferencia con otros procesos. Este caso es el más sencillo porque no tenemos que pensar en no entorpecer a nadie. En estos casos yo pongo el umbral para empezar a actuar en un 5%. Si estamos hablando de una edición Standard de SQL Server reorganizaré los índices con una fragmentación entre un 5 y un 20% y reconstruiré los de mayor fragmentación. Para ediciones Enterprise o Azure reduciré esa horquilla para reorganizar entre un 5 y un 15% y haré reorganizaciones online a partir del 15%.

Escenario 2: Problema puntual de rendimiento

En este escenario estamos hablando de un momento de carga de trabajo elevada en el que hemos recibido o detectado una incidencia por problemas de rendimiento. Tenemos que actuar rápido para solventar la situación pero entorpeciendo lo menos posible a los procesos de negocio que ya de partida tienen un rendimiento mermado. En estos casos pongo el umbral para empezar a actuar en fragmentaciones por encima del 10% en vez del 5. A partir de ahí, si tenemos la suerte de contar con una edición Enterprise, o estamos en Azure, no hay más problema, reconstruiremos con las mismas condiciones que en el escenario anterior, a partir del 15%. Para una edición Standard, donde si vamos a generar bloqueos si reconstruimos, intentaremos reorganizar hasta el 30% de fragmentación.

Solucionar estadísticas desactualizadas

Las estadísticas son clave para SQL Server. Como ya hemos comentado en este blog muchas veces, unas estadísticas desfasadas pueden tener el mismo impacto negativo o peor que un índice fragmentado. Por este motivo, es importante tenerlas en cuenta a la hora de realizar nuestros mantenimientos o enfrentar una incidencia por degradación de rendimiento. Una reconstrucción de índices siempre actualizará las estadísticas asociadas a ese índice pero en el caso de las reorganizaciones deberemos hacerlo manualmente. Tenemos que contar también con que una actualización de estadísticas es más ligera y rápida que un mantenimiento de índices por lo que, en caso de una degradación de rendimiento de una consulta puntual, yo siempre actualizo las estadísticas de las tablas involucradas como primera medida.

Conclusión

Ante un problema de rendimiento, tenemos que verificar el estado de nuestros índices y estadísticas. Además, consultar su nivel de fragmentación será clave a la hora de decidir si vamos a reorganizarlo o reconstruirlo y, todo esto, siempre sin dejar de lado las estadísticas. Tened en cuenta que por mucho que tengamos implementada una solución de mantenimiento de índices y estadísticas nunca vamos a estar 100% seguros de que no va a haber una variación tal de datos que nos va a generar fragmentación o a dejar desfasadas nuestras estadísticas. Es importante que mantengamos una monitorización y vigilancia continua para garantizar el mejor desempeño de nuestros SQL Server.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Abr

2024

Configurar planes de mantenimiento en SQL Server y Azure

Hola a todos y bienvenidos a este nuevo formato de Video Blog que espero que os guste y que podamos ver por aquí más a menudo. Hoy vamos a ver un caso práctico sobre como configurar planes de mantenimiento en nuestro SQL Server o instancia administrada en Azure gracias a los script de Ola Hallengren. En todo este tiempo como DBA (más de 10 años) os aseguro que más del 90% de las incidencias por supuestos problemas de rendimiento a las que me he enfrentado eran siempre por lo mismo, una falta de mantenimiento correcto. Por esto es importante programar tareas de reconstrucción de índices y mantenimiento de estadísticas. Y ya de paso, aprovechamos y configuramos las copias de seguridad y comprobaciones de integridad que también nos ofrece esta solución gratuita. Pocas veces vas a encontrar más por menos.

Guía de capítulos

00:00 Introducción
00:39 Descarga
01:20 Instalación
05:42 Backups
10:15 Integrity Check
11:42 Index Optimize
13:13 Limpieza
13:54 Log de procesos

Configurar planes de mantenimiento

Como podemos ver en el vídeo para descargar los scripts de mantenimiento solo deberemos acudir a la web de Ola Hallengren y descargar el script que se llama «MaintenanceSolution.sql». Con el script ya abierto en nuestro SSMS podremos configurar la base de datos donde se van a crear los scripts y una serie de configuraciones importantes para los jobs.

Una vez instalada la solución de planes de mantenimiento vamos a poder configurar en los distintos jobs las tareas de copias de seguridad, supervisión de la integridad y reconstrucción y actualización de índices y estadísticas para las bases de datos de sistema y de usuario. También es importante que configuremos los trabajos que incluyen las tareas de mantenimiento para no encontrarnos con incidencias de espacio en disco en un futuro.

Esta solución, además, tiene la ventaja de dejar un log bastante completo en una tabla llamada CommandLog que estará en la misma base de datos que hayamos creado los procedimientos almacenados de mantenimiento. En esta tabla podremos encontrar todo el historia de ejecuciones de todos los comandos con su detalle, horas de inicio y de fin y, por supuesto, si ha dado un error veremos el por qué.

Abr

2024

SQL o Azure ¿Qué solución es mejor para mi?

Si estás pensando desplegar un nuevo servidor, quizá por un proceso de migración, uno de los aspectos clave es elegir qué edición de SQL Server se adapta mejor a tus necesidades. Hoy en día, Microsoft ofrece una gran variedad de soluciones que, si bien están pensadas para satisfacer las necesidades de todas las empresas, puede ser un poco lioso para usuarios o administradores no iniciados en el tema del licenciamiento de SQL Server. Hoy, vamos a explorar las diferencias entre las ediciones de SQL Server 2022 (Express, Standard y Enterprise), las Bases de Datos de Azure y las Instancias Gestionadas de Azure.

Nube o local

Lo primero que tenemos que tener claro es si necesitamos desplegar un servidor en la nube o en local. En ocasiones, por regulación o por necesidades del proyecto ya podemos descartar varias de las opciones y, por tanto, lo tendremos bastante más fácil.
Un servidor local puede ser la elección correcta si tu empresa tiene requisitos de seguridad o cumplimiento muy específicos que requieren un control total sobre los datos. También puede ser beneficioso si ya tienes una infraestructura de sistemas robusta y el personal con experiencia en la gestión de servidores locales. En este caso no lo dudes y amortiza tu infraestructura local, ya habrá tiempo de replantearse la solución.

Por otro lado, una solución en la nube es ideal si necesitas flexibilidad, escalabilidad y ahorro de coste en el despliegue. Las soluciones en la nube, como Azure, pueden ofrecer, además, alta disponibilidad y copias de seguridad y actualizaciones de seguridad automáticas, liberando de carga de trabajo a los equipos de IT. Esta solución es también recomendable en escenarios descentralizados donde, de otra manera, tendríamos que tener en nuestra infraestructura local (y gestionar) servidores expuestos en internet. Sin embargo, a largo plazo el modelo de pago por uso puede derivar en grandes costes, sobre todo si no tienes personal con la formación adecuada para dimensionar y optimizar tanto la propia infraestructura en la nube como las aplicaciones que hacen uso de ella.

Soluciones locales

Microsoft nos ofrece varios “sabores” de SQL Server 2022, en concreto tenemos a nuestra disposición las ediciones Express, Standard, Enterprise y Development. Cada una de ellas con un coste y unas características. En este artículo nos vamos a centrar solo en las tres primeras pues son las destinadas a entornos de producción, de la edición Development solo comentaré que tiene todas las características de la edición Enterprise pero de manera gratuita a cambio de no poder usarse en entornos de producción.

SQL Server 2022 Express

La edición Express es una versión gratuita de SQL Server, diseñada para aplicaciones de pequeña escala. Aunque es gratuita y ofrece toda la robustez del sistema de gestión de bases de datos de Microsoft, tiene muchas limitaciones en términos de tamaño de las bases de datos y capacidades de procesamiento.

Es una solución ideal para pequeñas empresas que están iniciando un proyecto que necesita una base de datos. Sin embargo, pronto se puede quedar corta debido a sus limitaciones de tamaño de máximo 10 Gb por base de datos (incluyendo datos y log de transacciones), 1 Gb de memoria RAM y solo un procesador (físico o virtual) del que además solo se aprovecharán 4 núcleos (físicos o virtuales). A estas limitaciones hay que sumarle que no dispone de agente de SQL Server por lo que no podremos utilizar esas funcionalidades. En cuanto a funcionalidades también encontraremos limitaciones como la imposibilidad de comprimir los backups o de reconstruir índices online.

SQL Server 2022 Standard

La edición Standard es una solución de gestión de datos y BI (Business Intelligence) completa que ofrece más capacidades que la edición Express. Es ideal para las medianas empresas que necesitan características avanzadas, pero no todas las capacidades de alto rendimiento de la edición Enterprise. Por ejemplo, solo dispone de una solución Always On simple para una sola base de datos y con únicamente un nodo secundario. Tampoco nos ofrece por ejemplo la posibilidad de reconstruir índices online. Esto hace que no sea una solución adecuada para entornos críticos donde necesitemos una disponibilidad 24×7.

SQL Server 2022 Enterprise

La edición Enterprise es la más completa y potente que ofrece Microsoft hasta la fecha. Ofrece todas las capacidades de SQL Server para las empresas que necesitan el más alto nivel de escalabilidad, disponibilidad y seguridad eso sí, a un coste muy elevado (unas 5x veces la licencia Standard). Si optamos por asumir el alto coste por licencia de una edición Enterprise a cambio nos llevaremos ventajas como la posibilidad de usar todas las funciones de Always On, la reconstrucción de índices online, mayores opciones en la replicación o la posibilidad de usar Resource Governor, por ejemplo.

Soluciones en la nube

Desde hace ya más de una década (madre mía cómo pasa el tiempo) Microsoft dispone de Azure, su nube con soluciones SQL Server entre otras. Centrándonos en SQL Server tenemos a nuestra disposición también varias opciones y para todos los gustos, tanto SaaS como IaaS. SaaS hace referencia al software como servicio (Software As A Service) mientras que IaaS es la infraestructura en la nube (Infraestructure As A Service). Esto quiere decir que en las soluciones SaaS solo dispondremos de una base de datos o una instancia de SQL como un servicio en la nube mientras que en las soluciones IaaS dispondremos de un servidor completo en la nube donde instalar cualquier aplicación como hacemos en los servidores locales.

Bases de Datos de Azure SQL

Las Bases de Datos de Azure son soluciones SaaS de bases de datos completamente administradas. Como características principales podemos destacar que nos proporcionan una buena protección de los datos y gran escalabilidad sin la necesidad de administrar la infraestructura subyacente ni la instancia SQL Server. Esto es también su mayor limitación dado que no dispondremos de todas las características propias de una instancia como el Agente de SQL Server. También hay que mencionar que, aunque dispone de características de alta disponibilidad estas no son tan completas como las de las instancias gestionadas. En cuanto a costes son muy variables ya que usan el método de pago por uso y podremos definir un escalado bajo demanda para reducir el presupuesto. Os recomiendo utilizar la calculadora de costes de Azure Database si estáis pensando en implementar esta solución.

Instancias SQL Gestionadas de Azure

Las Instancias Gestionadas de Azure son una opción para cuando necesitemos la flexibilidad y el control total de una instancia de SQL Server, pero con la comodidad de un servicio gestionado. Ofrecen casi el 100% de compatibilidad con SQL Server Enterprise sin renunciar a las ventajas propias de la nube como actualizaciones automáticas. Es reseñable para esta solución el 99,99% de disponibilidad que anuncia Microsoft para cada base de datos individual alojada en una instancia gestionada pero, si eso os parece poco, aún dispone de opciones de alta disponibilidad para acercar esa cifra aún más al 100%. También dispone de su propia calculadora de precios que os recomiendo consultar antes de cualquier implementación.

Otras soluciones SQL Server en la nube

Además de las soluciones propias de Microsoft podemos encontrar las instancias gestionadas de Amazon AWS llamadas RDS. Aunque no es una solución tan completa como la de Microsoft, puede ser una opción a tener en cuenta si vuestra infraestructura cloud está en esta plataforma.

Para finalizar con este resumen de soluciones en la nube, encontramos la posibilidad de desplegar un servidor IaaS sobre cualquier nube comercial (Azure, AWS, GCP, etc…) e instalar sobre él un SQL Server licenciado de igual manera que con las soluciones locales. De esta manera, tenemos ciertas ventajas de la nube sin renunciar a las características propias de una solución local.

Conclusión

Microsoft ofrece una variedad de soluciones de bases de datos para satisfacer las necesidades de las empresas de todos los tamaños. Desde la edición Express de SQL Server 2022 para las necesidades de pequeñas aplicaciones, hasta las Instancias Gestionadas de Azure para las empresas que buscan la máxima flexibilidad y control, hay una solución para cada situación. Además no son excluyentes y en la mayoría de los casos nos encontraremos con escenarios híbridos que combinan varias de estas soluciones tanto locales como en la nube.

La elección depende de las necesidades específicas de tu empresa y espero que, tras leer este artículo, estés más preparado para tomar la decisión. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Abr

2024

Protegiéndonos con Microsoft Defender para SQL Server

En el mundo digital de hoy, la seguridad de los datos es primordial. Como profesionales de la base de datos, entendemos la importancia de proteger nuestros activos más valiosos: nuestros datos. La creciente proliferación y sofisticación de las amenazas cibernéticas y la prevalencia de los ataques dirigidos a las bases de datos hacen que la necesidad de soluciones de seguridad robustas sea más importante que nunca. Hoy, vamos a explorar una herramienta que nos ayuda a hacer precisamente eso: Microsoft Defender para SQL Server.

¿Por qué necesitamos Microsoft Defender para SQL Server?

Las bases de datos son a menudo el objetivo de los ciberdelincuentes debido a la valiosa información que contienen. Con el aumento de las amenazas y la constante evolución de las tácticas de los ciberdelincuentes, es esencial contar con una solución de seguridad que pueda mantenerse al día. Ya dedicamos hace unas semanas un artículo a los ataques SQL Injection, que son los más predominantes, y que puedes leer aquí. Aquí es donde entra en juego Microsoft Defender para SQL Server que gracias a aprovechar todo el potencial de Azure nos permite protegernos de este y muchos otros escenarios.

¿Qué es Microsoft Defender para SQL Server?

Microsoft Defender para SQL Server es una solución de seguridad integral diseñada para proteger nuestras bases de datos SQL Server ya esten On Premise, en la nube de Azure o en otras nubes comerciales como ASW o GCP. Proporciona una capa adicional de protección, ayudándonos a detectar y responder a amenazas potenciales antes de que puedan causar daño. Pero, ¿qué significa esto en términos técnicos?

Características Clave

Microsoft Defender para SQL Server viene con una serie de características que lo hacen una opción atractiva para cualquier organización que busque mejorar su postura de seguridad. Además integrar una detección de amenazas, como estamos acostumbrados en los antivirus convencionales, incluye una evaluación de vulnerabilidades que nos permitirá detectar nuestros puntos flacos en la seguridad de nuestras bases de datos.

Detección de Amenazas

Una de las características más destacadas de Microsoft Defender para SQL Server es su capacidad para detectar amenazas en tiempo real. Utiliza algoritmos avanzados para identificar comportamientos sospechosos y alertarnos de posibles problemas. Esto incluye la detección de inyecciones SQL, anomalías en el comportamiento de la base de datos y configuraciones inseguras.

Integración con Azure

Como parte de la familia de productos de Azure, Microsoft Defender para SQL Server se integra perfectamente con otros servicios de Azure, lo que permite una visión unificada de la seguridad en toda nuestra infraestructura de Azure. Esto nos permite tener una visión unificada de nuestra seguridad en toda nuestra infraestructura de Azure. Esto significa que podemos ver y gestionar las alertas de seguridad de todas nuestras bases de datos SQL Server desde un único panel.

Cobertura de Microsoft Defender para SQL Server

Microsoft Defender para SQL Server ofrece una amplia cobertura para proteger nuestras bases de datos. Esto incluye la protección contra ataques de inyección SQL, la detección de anomalías en el comportamiento de la base de datos y la identificación de configuraciones inseguras. Además, proporciona recomendaciones de seguridad personalizadas basadas en nuestras configuraciones y patrones de uso específicos.

Entre las coberturas que Microsoft Defender para SQL Server ofrece una amplia cobertura para proteger nuestras bases de datos podemos encontrar:

Protección contra ataques de inyección SQL: Microsoft Defender para SQL Server utiliza técnicas de aprendizaje automático para detectar patrones de consulta SQL anómalos que podrían indicar un intento de inyección SQL.
Detección de anomalías en el comportamiento de la base de datos: Microsoft Defender para SQL Server puede identificar comportamientos anómalos, como un aumento repentino en el volumen de transacciones o cambios inusuales en los patrones de acceso a los datos.
Identificación de configuraciones inseguras: Microsoft Defender para SQL Server puede identificar configuraciones que podrían hacer que nuestras bases de datos sean más vulnerables a los ataques, como la falta de cifrado o el uso de contraseñas débiles.

Evaluación de Vulnerabilidades con Microsoft Defender para SQL Server

Otra de las características esenciales de Microsoft Defender para SQL Server es su capacidad para realizar evaluaciones de vulnerabilidades como ya hemos comentado. Lo más interesante de esta herramienta integrada es que analizando las configuraciones de nuestras bases de datos es capaz de descubrir e indicarnos cómo remediar posibles vulnerabilidades en la base de datos. Las evaluaciones de vulnerabilidades proporcionan una visión general del estado de seguridad de nuestras máquinas SQL y detalles de cualquier hallazgo de seguridad.

La evaluación de vulnerabilidades emplea una base de conocimientos de reglas que señalan vulnerabilidades de seguridad y resaltan desviaciones de las mejores prácticas, como configuraciones incorrectas, permisos excesivos y datos sensibles sin protección. Las reglas se basan en las mejores prácticas recomendadas por Microsoft y se centran en los problemas de seguridad que presentan los mayores riesgos para nuestra base de datos y nuestros datos.

Además, cuando habilitamos el plan Defender para Azure SQL en Defender for Cloud, Defender for Cloud habilita automáticamente la Protección Avanzada contra Amenazas y la evaluación de vulnerabilidades con la configuración express para todas las bases de datos Azure SQL en la suscripción seleccionada. Esto nos permite realizar evaluaciones de vulnerabilidades a demanda para ver los hallazgos actuales.

Conclusión

Microsoft Defender para SQL Server es una herramienta valiosa para cualquier administrador de bases de datos que busque mejorar la seguridad de sus bases de datos SQL Server en la nube. Proporciona una serie de características de seguridad avanzadas y se integra perfectamente con Azure Security Center, lo que facilita la gestión de la seguridad de nuestras bases de datos. Aunque no es una solución de seguridad completa en sí misma, es un componente importante de una estrategia de seguridad de bases de datos efectiva.

Espero que este artículo te haya sido útil y que te ayude a tener mayor control sobre tus servidores SQL Server. Te animo a investigar más y definir nuevas alertas que puedan resultarte interesantes. Una vez hecho, puedes dejarlo en los comentarios y, entre todos, seguro que aprendemos algo nuevo. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Mar

2024

Escalado vertical y horizontal en SQL Server y Azure

¿Qué es el escalado en SQL Server y por qué es importante? En este artículo vamos a explicar los conceptos de escalado vertical y horizontal, las diferencias entre ellos y las ventajas y desventajas de cada uno. También veremos cómo aplicar estas técnicas en SQL Server, tanto en la versión On Premise como en la nube de Azure.

¿Qué es el escalado vertical y horizontal?

El escalado es la capacidad de aumentar o disminuir los recursos de un sistema para adaptarse a las necesidades de rendimiento y disponibilidad. Existen dos tipos de escalado: vertical y horizontal.

– El escalado vertical consiste en incrementar o reducir la potencia de un único servidor, ya sea añadiendo o quitando memoria, CPU, disco o cualquier otro componente. Por ejemplo, si tenemos un servidor con 8 GB de RAM y lo ampliamos a 16 GB, estamos haciendo un escalado vertical.

– El escalado horizontal consiste en agregar o eliminar servidores al sistema, de forma que se distribuya la carga entre ellos. Por ejemplo, si tenemos un servidor con 8 GB de RAM y le añadimos otro igual, estamos haciendo un escalado horizontal.

Ventajas y desventajas del escalado vertical y horizontal

Cada tipo de escalado tiene sus pros y sus contras, que debemos tener en cuenta a la hora de elegir la mejor opción para nuestro sistema.

Escalado vertical

– Ventajas: Es más sencillo de implementar, ya que no requiere cambios en la arquitectura ni en el código de la aplicación. Además, al tener un único servidor, se evitan problemas de sincronización, consistencia y latencia entre los nodos.

– Desventajas: Tiene un límite físico, ya que no podemos aumentar indefinidamente los recursos de un servidor. También implica un mayor coste, ya que los componentes más potentes suelen ser más caros. Además, al tener un único punto de fallo (SPOF), se reduce la disponibilidad del sistema.

Escalado horizontal

– Ventajas: Permite un mayor crecimiento, ya que podemos agregar tantos servidores como necesitemos. También implica un menor coste, ya que podemos aprovechar servidores más económicos y estándar. Además, al tener varios nodos, se aumenta la disponibilidad y la tolerancia a fallos del sistema.

– Desventajas: Es más complejo de implementar, ya que requiere cambios en la arquitectura y en el código de la aplicación. Además, al tener varios servidores, se generan problemas de sincronización, consistencia y latencia entre los nodos.

¿Cómo escalar SQL Server On Premise?

Para escalar SQL Server On Premise tenemos varias opciones, dependiendo del tipo de escalado que queramos realizar.

Escalado vertical On Premise

Para hacer un escalado vertical On Premise debemos modificar el hardware del servidor donde está instalado SQL Server. Esto, en algunos casos, implica detener el servicio, cambiar los componentes y reiniciar el servidor. Estos problemas desaparecen, en gran medida, cuando hablamos de servidores virtuales. Algunas recomendaciones para hacer un buen escalado vertical son:

Elegir componentes compatibles con el servidor y con SQL Server.
Prestar atención al licenciamiento, algunas ediciones y modos de licenciamiento de SQL Server tienen limitaciones en cuanto a CPU y RAM y si los superamos deberemos adquirir otra licencia.
Ajustar los parámetros de configuración de SQL Server según los nuevos recursos.
Realizar pruebas de rendimiento antes y después del cambio para verificar la mejora.

Escalado horizontal On Premise

Para hacer un escalado horizontal On Premise debemos agregar más servidores al sistema y distribuir la carga entre ellos. Esto implica crear una arquitectura distribuida, como un clúster, una réplica o una partición. Algunas recomendaciones para hacer un buen escalado horizontal son:

Elegir servidores con características similares al existente.
Configurar correctamente la redirección del tráfico entre los nodos.
Mantener la sincronización y la consistencia de los datos entre los nodos.

Las réplicas de solo lectura de los grupos de disponibilidad Always On son un ejemplo de este tipo de escalado. Añadiendo una réplica de solo lectura a nuestro grupo de disponibilidad podremos redirigir a ella las operaciones de lectura descargando de trabajo el nodo principal.

¿Cómo escalar SQL Server en Azure?

Para escalar SQL Server en Azure tenemos varias opciones, dependiendo del tipo de servicio que estemos usando.

Escalado vertical en Azure

Para hacer un escalado vertical en Azure debemos modificar el tamaño del servicio donde está alojado SQL Server. Esto implica cambiar el nivel de servicio o el plan de tarifa, lo que puede implicar un cambio de precio. Algunas ventajas de hacer un escalado vertical en Azure son:

No requiere detener el servicio ni reiniciar el servidor.
Se puede hacer desde el portal de Azure o mediante scripts.
Se puede automatizar según las métricas de rendimiento.
Valorar el apagado de los servicios cuando no están en uso para un menor coste. Esto es especialmente útil cuando hablamos de entornos de desarrollo y pruebas.

Mención especial en este apartado para las bases de datos de Azure en modo de licenciamiento sin servidor donde podremos adaptar los recursos según la carga de trabajo. Aumentando en horas punta y disminuyendo la cantidad de recursos en momentos de menos carga.

Otra opción muy interesante que se nos plantea en Azure son los grupos de recursos, podremos asignar un extra de recursos a un grupo con varios servicios para que los usen en caso de ser necesario. Esto nos permite no tener que sobredimensionar todos y cada uno de los servicios por separado y reducir costes. Si, por ejemplo, nuestra base de datos transaccional tiene su pico de trabajo por el día y la informacional por la noche podrán compartir un grupo de recursos.

Escalado horizontal en Azure

Para hacer un escalado horizontal en Azure debemos agregar más instancias al servicio donde está alojado SQL Server. Esto implica crear un balanceador de carga o un grupo de escalado, lo que puede implicar un cambio de precio. Además, en Azure podemos aprovechar las bases de datos elásticas, que son un tipo de servicio que permite escalar horizontalmente una base de datos SQL sin tener que gestionar los servidores ni la distribución de los datos. Las bases de datos elásticas se componen de un grupo de bases de datos que comparten recursos y se balancean automáticamente según la demanda. d.

Conclusión

El escalado es una técnica fundamental para optimizar el rendimiento y la disponibilidad de SQL Server, tanto en la versión On Premise como en la nube de Azure. Dependiendo de las necesidades y los recursos disponibles, podemos optar por un escalado vertical o horizontal, cada uno con sus ventajas y desventajas. Tienes que tener en cuenta que estos modos no son excluyentes, nuestra aplicación puede hacer uso de una base de datos de Azure por cliente, escalando horizontalmente con cada nuevo cliente y, a la vez, escalar verticalmente una base de datos cuando el volumen de datos o transacciones de un cliente lo requiera. Lo importante es elegir la opción más adecuada para nuestro sistema y realizar las pruebas necesarias para verificar la mejora.

Espero que este artículo te haya sido útil y que te ayude a optimizar el rendimiento de tus consultas en SQL Server. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Ene

2024

Administración de Instancias SQL en Azure

Ayer hablamos en profundidad sobre las instancias administradas de SQL Server en Azure y os prometí dedicar el post de hoy a temas de administración. Vamos a empezar hablando de los modos de licenciamiento y lo que nos ofrece cada uno de ellos y, a continuación, ya entraremos en materia con la administración.

Licenciamiento de instancias administradas en Azure

Como DBAs es probable que recaiga sobre nosotros la elección de la arquitectura SQL y por tanto su licenciamiento. En el caso de las instancias administradas de SQL Server en Azure el modelo de compra se basa en núcleos virtuales. Esto quiere decir que recursos como la RAM dependerán de la cantidad de núcleos de CPU que seleccionemos y no podremos ampliar un recurso sin el resto. Además de los núcleos tenemos otras opciones, por un lado podremos elegir el tipo de hardware y el nivel de servicio. Sé que es un poco lioso así, no os preocupéis que vamos a verlo con detalle.

En base al hardware, tenemos tres planes disponibles: el Gen5, el Premium y el Premium optimizados para memoria. La diferencia entre el Gen5 y el Premium es el tipo de procesador y, por tanto, su velocidad. Además el plan Premium nos da algo más de RAM por cada núcleo que contratemos. El Premium y Premium optimizado para memoria solo se diferencian en que este segundo da aún más RAM por cada núcleo.

Además, como hemos comentado, cualquiera de estos tres planes se puede contratar en dos niveles de servicio: estándar o crítico para la empresa. El nivel estándar nos proporcionará 16Tb de Azure Blob Storage de alto rendimiento y alta disponibilidad basada en Azure Blob Storage y Azure Service Factory. El nivel crítico para la empresa cambia la opción de almacenamiento por un SSD local extremadamente rápido que reduce la latencia de E/S. El tamaño del SSD variará en función del plan de hardware. Otras ventajas del nivel de servicio crítico es la alta disponibilidad Always On y una réplica de solo lectura adicional. Por último, este nivel, añade OLTP en memoria para usarse en cargas con necesidades de rendimiento muy altas.

La siguiente tabla resume todo lo que hemos comentado, para precios Microsoft ha puesto a nuestra disposición esta calculadora.

Operaciones de administración

Ahora que ya sabemos que opción contratar es momento de crear nuestra primera instancia. Para crear instancias, igual que para cambiar su configuración o eliminarlas, podremos hacerlo desde Azure Portal, usando PowerShell o la CLI (Command Line Interface) de Azure. Al crear una instancia tenemos que elegir el nombre, la ubicación, la versión y la edición de SQL Server, el tamaño del almacenamiento y la configuración del firewall. En cuanto a la configuración, podremos cambiar algunos parámetros como el número de núcleos virtuales (vCores), la cantidad de memoria RAM o el tamaño del almacenamiento. También podemos habilitar o deshabilitar algunas características como el Always On Availability Groups o el Transparent Data Encryption.

Copias de seguridad y restauraciones en instancias en Azure

Antes de empezar con este tema, vamos a hablar de una cosa que todos estáis pensando y que no es para menos. Con la presentación de SQL Server 2022 se nos mostró una funcionalidad llamada “Vínculo para Azure Managed Instance” que, haciendo uso de grupos de disponibilidad distribuidos, nos permitiría mantener sincronizados nuestro entorno On Premise con Azure. Sin embargo, aunque SQL Server 2022 salió al mercado en diciembre de 2022, a día de hoy (Enero de 2024) sigue siendo una versión preliminar que no está disponible para todo el mundo. Sé lo que estáis pensando, es una CHAPUZA que, habiendo pasado más de un año siga sin estar disponible esta característica. No olvidemos que es una de las principales novedades que justificaría la migración a esta versión de SQL Server. Yo tampoco lo entiendo.

Vale, pasemos página y dejemos atrás lo malo (aunque no lo olvidemos) y hablemos de las copias de seguridad en las instancias de Azure. Las copias de seguridad principales, son automáticas y no vamos a poder configurar nada. Las instancias administradas realizan copias de seguridad automáticas cada 5-10 minutos (dependiendo del tamaño de las bases de datos) y las almacenan en un almacenamiento redundante. Podemos restaurar nuestras bases de datos desde estas copias usando Azure Portal o PowerShell.

Sin embargo, nosotros también podemos realizar copias de seguridad manuales por nuestra cuenta usando T-SQL o PowerShell y almacenarlas en un almacenamiento externo como Azure Blob Storage o un recurso compartido SMB. Estas copias siempre serán Copy-Only para no interferir en la cadena principal de copias automáticas.

En cuanto a restauración de copias manuales, podremos usar T-SQL o PowerShell para restaurar nuestras copias en la instancia de Azure. Nuestra instancia administrada admitirá copias de otras bases de datos de Azure y de cualquier SQL Server superior a 2008. En el otro sentido, solo podremos restaurar copias de seguridad de Azure en SQL Server 2022.

Actualizaciones de instancias administradas en Azure

Las instancias administradas se actualizan solas con los últimos parches y mejoras de SQL Server sin necesidad de intervención manual. Sin embargo, sí tendremos que elegir entre dos modos de actualización: automático o manual. En el modo automático, las actualizaciones se aplican tan pronto como están disponibles mientras que en modo manual, podemos elegir cuándo aplicarlas. Os recomiendo este último modo para actualizar siempre dentro de una ventana de mantenimiento.

Monitorización de instancias administradas en Azure

Podemos monitorizar y diagnosticar nuestras instancias administradas usando las herramientas habituales que ya conocemos como SQL Server Management Studio o Extended Events. También podemos usar los servicios integrados de Azure como Azure Monitor o Azure SQL Analytics para obtener métricas e insights sobre el rendimiento, la disponibilidad y la salud de nuestras instancias.

Conclusión

Como hemos visto en este artículo y en el anterior, las instancias SQL Server administradas de Azure son una gran solución PAAS en el cloud de Microsoft. Nos ofrecen prácticamente todas las características de un SQL Server local sin necesidad de tenerlo en nuestra infraestructura. Además, Azure se encarga de las copias de seguridad por nosotros y nos garantiza una disponibilidad con un SLA cercano al 100%. Por contra, perdemos flexibilidad a la hora de gestionar ciertos temas de configuración de recursos y nos limita a 16 Tb de espacio en disco. ¿Qué opináis? ¿Trabajáis con esta solución?¿Os planteáis migrar a este servicio? Os leo en comentarios. También podéis dejar vuestro feedback en nuestro Twitter o en nuestro nuevo grupo de LinkedIn.

Cloud

NO TE PIERDAS NADA

Colabora con nosotros

Entradas recientes

Etiquetas

Comentarios recientes