SQL Server

10
Ene
2024

Clasificación de datos con SQL Server Data Classification

En el post de ayer vimos cómo cifrar o enmascarar los datos en SQL Server pero, ¿qué datos debemos proteger? Eso es justo lo que vamos a ver hoy, en este artículo te voy a explicar cómo funciona Data Classification, cómo puedes usarla para clasificar tus datos y cómo puedes detectar los datos clasificados en tu base de datos. El objetivo es que al final de este post seamos capaces de aumentar el nivel de protección de nuestros datos. ¡Vamos allá!

¿Qué es Data Classification?

Data Classification es una función de SQL Server que te permite asignar etiquetas de sensibilidad y confidencialidad a tus columnas de datos. Estas etiquetas te ayudan a identificar qué datos son más críticos y qué medidas de seguridad debes aplicar para protegerlos. Por ejemplo, puedes etiquetar una columna que contiene números de tarjeta de crédito como «Alta sensibilidad» y «Confidencial», o una columna que contiene nombres de clientes como «Baja sensibilidad» y «Público».

¿Para qué sirve Data Classification?

Data Classification tiene varios beneficios para tu base de datos, principalmente nos ayuda a mejorar la seguridad. Podemos aplicar políticas de acceso, encriptación, auditoría y retención basadas en las etiquetas de tus datos. Por otro lado, nos va a permitir cumplir con las normativas de protección de datos, como el RGPD, que exigen que clasifiques tus datos según su sensibilidad y confidencialidad, y que informes a tus usuarios sobre el uso que haces de sus datos. Por último, facilita el análisis y la visualización de los datos, ya que podremos filtrar, agrupar y ordenar nuestros datos según sus etiquetas.

¿Cómo clasificar tus datos con Data Classification?

Para clasificar tus datos con Data Classification, tienes que seguir estos pasos:

  1. Abre el Explorador de objetos de SQL Server Management Studio (SSMS) y conecta con tu servidor de SQL Server.
  2. Expande la carpeta Bases de datos y selecciona la base de datos que quieres clasificar.
  3. Haz clic derecho sobre la base de datos y selecciona Tareas > Clasificar datos.
  4. Se abrirá el asistente de Data Classification, que te guiará por el proceso de clasificación.
  5. En la primera página del asistente, haz clic en Siguiente.
  6. En la segunda página del asistente, verás una lista de las tablas y columnas de tu base de datos, con las recomendaciones automáticas de clasificación basadas en los tipos y nombres de los datos. Puedes aceptar las recomendaciones o modificarlas según tus criterios. Para modificar una recomendación, haz clic sobre la fila correspondiente y selecciona la sensibilidad y la confidencialidad que quieras asignar. También puedes añadir o eliminar columnas del proceso de clasificación usando los botones Agregar o Eliminar.
  7. Cuando hayas terminado de clasificar tus columnas, haz clic en Siguiente.
  8. En la tercera página del asistente, verás un resumen de la clasificación que has realizado, con el número total de columnas clasificadas y el nivel medio de sensibilidad y confidencialidad. También podrás generar un informe en formato PDF o CSV con los detalles de la clasificación. Haz clic en Finalizar para aplicar la clasificación a tu base de datos.

¿Cómo detectar los datos clasificados en tu base de datos?

Una vez que hayamos clasificado nuestros datos con Data Classification, tendremos varias opciones para detectarlos. 

Asistente de Data Classification

Si abres el asistente de Data Classification, podrás ver las columnas que ya has clasificado y modificarlas si lo deseas. También nos ofrece la posibilidad de generar un informe.

Vistas del sistema

SQL Server almacena la información sobre la clasificación en el catálogo del sistema, en las vista sys.sensitivity_classifications. Podemos consultar esta vista usando consultas para obtener los detalles sobre la clasificación.

Propiedades de las columnas

Si seleccionas una columna clasificada en el Explorador de objetos de SSMS y abres el panel Propiedades, podrás ver la sensibilidad y la confidencialidad que le has asignado en la pestaña de propiedades extendidas.

Conclusión

En este artículo te he mostrado cómo puedes clasificar, detectar e integrar tus datos de SQL Server usando la función Data Classification. Esta función nos permite asignar etiquetas de sensibilidad y confidencialidad a nuestras columnas de datos. Espero que te haya resultado interesante, en el próximo artículo vamos a ver los siguientes pasos una vez que tenemos clasificados los datos. Si tienes alguna duda o comentario, puedes dejarlo abajo, en Twitter o en mi mail. ¡Hasta la próxima!

Publicado por Roberto Carrancio en SQL Server, 0 comentarios
09
Ene
2024

Cifrado de datos en SQL Server

El otro día, hablando de preguntas en entrevistas de trabajo para DBA, comentamos el tema del cifrado de datos en SQL Server. Como es un tema muy interesante y que a veces genera dudas vamos a verlo en profundidad. 

Antes de empezar, una aclaración. Mi profesor de ciberseguridad siempre decía que se dice CIFRAR, la palabra ENCRIPTAR nunca ha existido en el castellano. La gente usa encriptar por una mala traducción del inglés encrypt. Aunque lo cierto es que el uso de encriptar está tan extendido que en 2022 la RAE lo incluyó en las últimas versiones del diccionario (junto a almóndiga y cocreta), la forma correcta de decirlo sigue siendo CIFRAR. Al fin y al cabo no vamos a meter nada en ninguna cripta, ¿verdad?.

¿Qué es el cifrado y que tipos existen?

El cifrado es un proceso que transforma la información en un formato ilegible para quienes no tienen la clave para descifrarla. De esta forma, podemos evitar que personas no autorizadas accedan a nuestros datos sensibles o confidenciales.

Existen dos escenarios principales donde el cifrado es importante: en tránsito y en espera. El cifrado en tránsito es la protección de los datos mientras se transmiten por la red, por ejemplo, entre el cliente y el servidor, o entre dos servidores. Sin embargo, cuando decimos cifrado en espera nos referimos a la protección de los datos mientras se almacenan, por ejemplo, en un disco duro o en la nube.

El cifrado en SQL Server

SQL Server nos ofrece varias opciones para implementar el cifrado en ambos escenarios. Veamos algunas de ellas:

TLS para cifrado en tránsito

Para el cifrado en tránsito, podemos usar el protocolo TLS (Transport Layer Security), que crea un canal seguro entre dos partes que se comunican por la red. SQL Server soporta TLS desde la versión 2005 y lo podemos habilitar mediante la configuración del servidor y del cliente. También podemos usar certificados digitales para autenticar las partes y garantizar la integridad de los datos. Los certificados son documentos electrónicos que contienen información sobre la identidad y la clave pública de una entidad. SQL Server nos permite crear, importar y administrar certificados mediante el uso de cláusulas Transact-SQL o mediante el uso de herramientas gráficas como el Administrador de configuración de SQL Server o el Explorador de objetos de SQL Server Management Studio.

TDE para cifrado en espera de bases de datos 

Para el cifrado en espera, podemos usar el TDE (Transparent Data Encryption), que cifra los archivos de datos, los logs de registro y las copias de seguridad de las bases de datos. SQL Server soporta TDE desde la versión 2008 y lo podemos habilitar mediante la creación de una clave de cifrado de base de datos y una clave maestra de base de datos. El TDE no afecta al rendimiento ni al diseño de las aplicaciones, ya que el cifrado y el descifrado se realizan de forma transparente.

TDE se puede configurar con EKM (Extensible Key Management), que nos permite usar proveedores externos para almacenar y administrar las claves de cifrado. El EKM nos ofrece mayor seguridad y flexibilidad para gestionar las claves.

Always Encrypted para cifrado en espera de columnas

Otra opción para el cifrado en espera es Always Encrypted, que nos permite cifrar los datos sensibles dentro de las columnas de las tablas, tanto en el servidor como en el cliente. SQL Server soporta Always Encrypted desde la versión 2016 y lo podemos habilitar mediante la configuración del driver del cliente y la creación de una clave maestra columnar y una clave columnar. El Always Encrypted nos permite separar las claves de los datos, lo que implica que ni siquiera nosotros como DBAs podremos ver los datos sin autorización.

Enmascaramiento de datos

Además del cifrado, otra forma de proteger nuestros datos es el enmascaramiento. SQL Server ofrece,desde la versión 2016, una opción llamada DDM (Dynamic Data Masking) que nos permite ocultar o modificar los datos sensibles cuando se muestran a los usuarios. Esta opción nunca va a alterar los datos reales almacenados en la base de datos. El DDM nos permite limitar la exposición de los datos según si el usuario tiene o no un permiso. En concreto los usuarios sysadmin o con el permiso UNMASK leerán los datos tal como están guardados en la base de datos y el resto verá los datos enmascarados

Es importante destacar que el DDM no es lo mismo que el cifrado, ya que el DDM no cambia los datos reales, sino solo su presentación. Por lo tanto, el DDM no es suficiente para garantizar la seguridad de los datos, sino que debe usarse junto con otras medidas como el cifrado o el control de acceso.

¿Cómo funciona DDM?

DDM funciona mediante la definición de máscaras o reglas que se aplican a las columnas que contienen los datos que queremos proteger. Estas máscaras pueden ser de diferentes tipos, como por ejemplo:

– Máscara parcial: oculta parte del valor original, dejando visible solo algunos caracteres. Por ejemplo, podemos mostrar solo los últimos cuatro dígitos de un número de teléfono o de una tarjeta de crédito.
– Máscara por defecto: reemplaza el valor original por un valor fijo o predeterminado. Por ejemplo, podemos mostrar un asterisco (*) en lugar del nombre completo de una persona.
– Máscara aleatoria: genera un valor aleatorio dentro de un rango especificado. Por ejemplo, podemos mostrar una fecha aleatoria entre el año 2000 y el 2020 en lugar de la fecha real de nacimiento de una persona.
– Máscara personalizada: permite definir una expresión o una función que se encarga de generar el valor enmascarado. Por ejemplo, podemos mostrar el nombre de una ciudad al azar en lugar del nombre real de la ciudad donde vive una persona.

Para implementar el DDM en SQL Server, solo tenemos que usar la instrucción ALTER TABLE y especificar el tipo de máscara y el valor que queremos aplicar a cada columna. Por ejemplo, si tenemos una tabla llamada Clientes con las columnas Nombre, Apellido, Teléfono y Ciudad, podemos definir las siguientes máscaras:

ALTER TABLE Clientes
ALTER COLUMN Nombre ADD MASKED WITH (FUNCTION = 'default()')
ALTER COLUMN Apellido ADD MASKED WITH (FUNCTION = 'partial(1,"XXXXXXX",0)')
ALTER COLUMN Teléfono ADD MASKED WITH (FUNCTION = 'partial(0,"XXX",4)')
ALTER COLUMN Ciudad ADD MASKED WITH (FUNCTION = 'random(1,10)')

De esta forma, cuando consultemos la tabla Clientes, veremos algo así:

Nombre Apellido Teléfono Ciudad
*AXXXXXXX XXX-12345
*BXXXXXXX XXX-56783
*CXXXXXXX XXX-90127

Conclusión

Hemos visto algunos ejemplos de los tipos de cifrado y protección que podemos usar con SQL Server. Aunque existen otras opciones como el cifrado estático de columnas son opciones antiguas que prácticamente no se usan. Como habéis podido ver, el cifrado y el DDM son herramientas muy útiles y poderosas para proteger nuestros datos y cumplir con las normativas de privacidad y seguridad. Cada opción tiene sus ventajas y desventajas, dependiendo del nivel de seguridad y rendimiento que se busque. Espero os haya gustado este post y que lo podáis poner en práctica. Como siempre dejo a vuestra disposición los comentarios, mi cuenta de Twitter y mi mail para cualquier duda.

 

Publicado por Roberto Carrancio en SQL Server, 4 comentarios
05
Ene
2024
Entrevista de trabajo con Inteligencia Artificial

Entrevista de trabajo con Inteligencia Artificial

Hoy os he preparado un artículo diferente, hace tiempo que rondaba por mi cabeza la idea de prepararos un artículo con preguntas y respuestas a las que es posible que os tengáis que enfrentar si hacéis una entrevista para un puesto de DBA de SQL Server. Otra idea que lleva rondando mi cabeza desde que inicié este proyecto era hacer un artículo con IA, cada vez está más claro que es una tecnología que ha venido para quedarse y en cuanto antes empecemos a ganar soltura mejor para nosotros. Así que hoy he decidido juntar esas dos ideas en este post y vamos a dejar que la IA nos haga una entrevista de trabajo. Además vamos a dejar también que responda a las preguntas. Por mi parte os añadiré unas notas con mi opinión sobre cada una de las preguntas y respuestas. ¡Vamos a ello!

Configurando nuestra entrevista con IA

Como ya sabéis la Inteligencia Artificial pone a nuestra disposición prácticamente todo lo que le podamos pedir, eso sí, hay que saber cómo pedirlo para obtener el resultado deseado. Lo que le pedimos a una IA se llama prompt y en mi caso ha sido este.

Por un lado le he dicho a Chat GPT que actúe como entrevistador. Le he pedido que haga una entrevista técnica de 5 preguntas:

Quiero que actúes como un entrevistador de RRHH haciendo una entrevista técnica a un candidato a una vacante de DBA SQL Server. Hazme un total de 5 preguntas de una en una y yo te daré la respuesta.

Para las respuestas, vamos a pedirle a Copilot, la IA de Bing (Microsoft) que nos de las respuestas. Este ha sido nuestro prompt:

Quiero que actúes como un candidato a una posición de DBA SQL Server durante una entrevista técnica con RRHH, yo te voy a hacer las preguntas y tú me respondes.

Nuestra entrevista con IA

Teniendo ya configuradas nuestras dos IAs podemos empezar con la entrevista, Chat GPT nos hará unas preguntas que copiaremos en Copilot. Las respuestas que nos de Copilot las copiaremos en Chat GPT para continuar con la entrevista, vamos a ello.

Pregunta 1

Entrevistador (Chat GPT):

¡Claro! Comencemos con la primera pregunta:
¿Puede explicarme qué es la normalización de bases de datos y por qué es importante en el contexto de SQL Server?

Candidato (Copilot):

¡Por supuesto! La normalización de bases de datos es el proceso de organizar los datos en una base de datos para reducir la redundancia y mejorar la integridad de los datos. En SQL Server, la normalización es importante porque ayuda a evitar errores de actualización y eliminación, mejora la eficiencia de las consultas y reduce el espacio de almacenamiento.

Opinión de Roberto: Una pregunta de teoría básica de base de datos para marcar las bases de la entrevista es una muy buena opción. La respuesta es correcta, echo en falta mencionar las formas normales (por lo menos hasta la tercera) pero, he visto que nosotros en el blog tampoco hemos hablado de este tema hasta ahora. Me lo apunto para darle solución lo antes posible.

Pregunta 2

Entrevistador (Chat GPT):

Excelente explicación. Ahora pasemos a la siguiente pregunta:
¿Cuáles son las diferencias entre una clave primaria y una clave externa en una base de datos SQL Server?

Candidato (Copilot):

¡Claro! Una clave primaria es una columna o un conjunto de columnas que identifican de forma única cada fila de una tabla y garantizan la integridad de la entidad de la tabla. Por otro lado, una clave externa es una columna o un conjunto de columnas que establecen una relación entre dos tablas y garantizan la integridad referencial de los datos. En otras palabras, una clave primaria se utiliza para identificar de forma única cada fila en una tabla, mientras que una clave externa se utiliza para establecer una relación entre dos tablas.

Opinión de Roberto: Podríamos considerar esta pregunta no tanto para DBA como para usuarios de bases de datos, sin embargo en nuestro día a día deberemos responder dudas de usuarios por lo que es importante tener claros todos estos conceptos. Nosotros profundizamos mucho más sobre claves primarias.

Pregunta 3

Entrevistador (Chat GPT):

Muy bien explicado. Ahora, avanzando a la tercera pregunta:
¿Cómo optimizaría el rendimiento de una consulta que está ejecutando lentamente en una base de datos SQL Server?

Candidato (Copilot):

Para optimizar el rendimiento de una consulta que se está ejecutando lentamente en una base de datos SQL Server, se pueden seguir algunas prácticas recomendadas. Primero, se puede identificar la consulta lenta y analizar su plan de ejecución para detectar cuellos de botella y posibles mejoras. Luego, se pueden crear índices adecuados para mejorar la velocidad de búsqueda y reducir el tiempo de respuesta. Además, se pueden ajustar las opciones de configuración del servidor y la base de datos para mejorar el rendimiento general.

Opinión de Roberto: Una pregunta sencilla que da mucho juego. Es muy probable que en nuestras entrevistas nos encontremos con esta pregunta o una muy parecida. Por esto mismo, tendremos que prepararnos muy bien la respuesta. Es una pregunta donde nos podremos extender y demostrar lo que sabemos, es muy abierta y con poca información por eso mismo. Quizá yo empezaria la respuesta preguntando, ¿cómo sabemos que va lenta? ¿iba bien antes pero se ha degradado el rendimiento o siempre ha tardado mucho y deseamos mejorar los tiempos? ¿tenemos habilitado Query Store para consultar los distintos planes de ejecución? A partir de aquí ya toca meterse a mirar el plan de ejecución, ver que componentes consumen más recursos y como se puede optimizar la consulta y los índices para mejorar. También miraremos el estado del servidor y el consumo de los principales recursos (CPU,RAM y Disco).

Pregunta 4

Entrevistador (Chat GPT):

Muy acertado. Ahora, pasemos a la cuarta pregunta:
¿Qué estrategias utilizaría para realizar copias de seguridad y restauración en SQL Server?

Candidato (Copilot):

Para realizar copias de seguridad y restauración en SQL Server, se pueden seguir algunas estrategias recomendadas. Primero, es importante identificar los datos críticos que deben ser respaldados y establecer un plan de copia de seguridad adecuado. Luego, se pueden programar copias de seguridad regulares y almacenarlas en un lugar seguro y fuera del sitio. Además, se pueden realizar pruebas de restauración periódicas para garantizar que los datos se puedan recuperar en caso de una falla del sistema. En cuanto a la restauración, se pueden utilizar las herramientas de restauración integradas de SQL Server para restaurar una base de datos a un estado anterior.

Opinión de Roberto: Nos encontramos, de nuevo, con una de las preguntas más frecuentes en las entrevistas de trabajo para DBA. No es casualidad, es una de las tareas diarias de todo DBA como comentamos aquí. No me voy a extender más pues ya tenemos en el blog un artículo dedicado a las copias de seguridad y sus restauraciones.

Pregunta 5

Entrevistador (Chat GPT):

Excelente enfoque. Ahora, para la última pregunta:
¿Cómo gestionaría la seguridad en una base de datos SQL Server, asegurando que solo usuarios autorizados tengan acceso a ciertos datos y funciones?

Candidato (Copilot):

Para gestionar la seguridad en una base de datos SQL Server y asegurarse de que solo los usuarios autorizados tengan acceso a ciertos datos y funciones, se pueden seguir algunas prácticas recomendadas. Primero, se puede establecer un plan de seguridad por capas que aproveche varias funcionalidades de seguridad destinadas a distintos ámbitos de seguridad. Luego, se pueden configurar los permisos de usuario y las entidades de seguridad para reducir el área expuesta de SQL Server. Además, se pueden cifrar los datos en reposo y a través de la conexión con Always Encrypted y Cifrado de datos transparente. Por último, se pueden programar auditorías y alertas para detectar y responder a posibles amenazas de seguridad

Opinión de Roberto: Para finalizar, la IA nos hace otra de esas preguntas que nunca faltan en una entrevista de trabajo. Gestionar la seguridad de los usuarios es clave para el cumplimiento de la normativa básica de seguridad de todas las empresas y, en entornos regulados, hasta la legislación. Vemos como la segunda IA da una respuesta muy completa, hace referencia a permisos por objeto como vimos cuando hablamos de las vistas. Nos habla también de distintas opciones de cifrado de datos que veremos en profundidad más adelante y finaliza con auditorías para vigilar y monitorizar el cumplimiento de las políticas de seguridad.

Conclusión

Ha sido un experimento divertido, hemos visto que las IAs han acertado en gran medida dentro del rol que les habíamos asignado y nos han dado gran variedad de temas a tratar en los próximos días. Lejos está aún el día que predicen que las IA serán capaces de quitarnos el trabajo (aunque es posible que llegue), lo que sí que ha llegado es el día de aprender a usarlas. Tenemos a golpe de click y de manera gratuita un universo infinito de posibilidades que nos puede ayudar como hemos visto desde para preparar una entrevista de trabajo como en el día a día. Tened claro que al blog han venido para quedarse y que más adelante hablaremos más de este tipo de herramientas. ¿Qué os parece a vosotros? ¿Os ha gustado este artículo diferente? Dejadme vuestro feedback aquí abajo, en Twitter o por mail.

Publicado por Roberto Carrancio en SQL Server, 3 comentarios
04
Ene
2024

Combinando soluciones de Alta Disponibilidad (HA Parte 7)

Bienvenidos a otra entrada mas de esta serie sobre Alta Disponibilidad en SQL Server, ya la última. Durante estos últimos días hemos podido ver una a una las soluciones que nos propone SQL Server para garantizar la continuidad de nuestro servicio y replicar los datos en segundas ubicaciones. Cada una de las soluciones que hemos visto tenía sus ventajas y sus inconvenientes y en ocasiones vamos a necesitar combinar varias de estas soluciones para cubrir los requisitos de nuestros clientes. 

Esto es justo en lo que nos vamos a centrar hoy, combinaciones de soluciones de alta disponibilidad para, en la medida de lo posible, limitar los inconvenientes que nos podamos encontrar y garantizar la mayor disponibilidad posible.

Always On distribuidos

Como empezamos esta serie hablando de los Always On, hoy también vamos a empezar por esta solución. No es en sí una combinación de distintas soluciones de alta disponibilidad sino más bien una misma solución anidada como vamos a ver.

Alta Disponibilidad Distributed AG

Gracias a los Always On distribuidos vamos a poder tener dos o más grupos de disponibilidad (AG) replicados entre sí, de forma que cada AG actúa como una réplica secundaria del otro. Podemos usar Always On distribuidos para escenarios de recuperación ante desastres, ya que podemos tener los AG en diferentes centros de datos o regiones geográficas.

Combinaciones con Instancias de conmutación por error

Cuando hablamos de las FCI vimos que era una solución que nos garantiza alta disponibilidad con un único punto de conexión (el nombre del servidor SQL no varía aunque balancee el servicio). Sin embargo, uno de sus grandes inconvenientes es que no nos permite acceso de solo lectura a las réplicas. También, tiene un gran SPO en el almacenamiento compartido lo que puede hacer que no encaje en todos los escenarios. Para solucionar estos inconvenientes podemos optar por combinar esta solución de alta disponibilidad con otras.

FCI + Always On

Esta es quizá una de mis soluciones preferidas de alta disponibilidad ya que nos permite tener un clúster de conmutación por error (FCI) con dos o más nodos que comparten un almacenamiento compartido y nos brindan alta disponibilidad a bajo coste. Este FCI será, a su vez, uno de los nodos de un Always On con otro servidor o FCI. Además es escalable añadiendo al Always On más nodos o FCI en cualquier momento. 

De esta forma, podemos tener alta disponibilidad a nivel de instancia gracias al FCI y a nivel de base de datos gracias al Always On. También  nos beneficiamos de las características de los Always On como el acceso de solo lectura a los datos o la duplicidad de los datos en varias ubicaciones. 

El FCI nos garantiza el failover automático en caso de que uno de los nodos falle, y el AG nos permite tener copias sincrónicas o asíncronas de las bases de datos, con la posibilidad de leer desde las réplicas secundarias. Esta solución es ideal para entornos locales o híbridos, donde tenemos control sobre el almacenamiento compartido.

FCI + Database Mirroring

Es una combinación similar a la anterior, pero en lugar de usar grupos de disponibilidad, usamos el espejo de bases de datos (Mirroring). El Database Mirroring es una característica que nos permite tener una copia sincrónica o asíncrona de una base de datos en otra instancia de SQL Server, con la opción de tener un testigo que facilite el failover automático. Al combinar estas dos soluciones, podemos tener alta disponibilidad tanto a nivel de instancia como a nivel de base de datos, pero con algunas limitaciones respecto a los Always On, como la ausencia de compresión y cifrado de los datos, y la imposibilidad de leer desde la réplica secundaria. Esta solución es adecuada para versiones anteriores a SQL Server 2012, donde los Always On no estaban disponibles.

FCI + Log Shipping

Es otra combinación que nos permite tener FCI con dos o más nodos que comparten un almacenamiento compartido, y enviar los logs de transacciones a una o más instancias secundarias. De esta forma, podemos tener copias casi en tiempo real de las bases de datos, y usarlas para fines de consulta o reporte. El FCI nos garantiza el failover automático en caso de que uno de los nodos falle, y el Log Shipping nos permite restaurar manualmente las bases de datos en caso de que la instancia primaria falle. Esta solución es útil para entornos donde queremos tener copias adicionales de las bases de datos para solo lectura y de paso, tener una copia actualizada de los datos para una recuperación rápida.

Otras soluciones no oficiales

Cuando hablamos de Log Shipping os comenté que, aunque no es una solución oficial, se puede combinar con Always On. Es un procedimiento que requiere modificar manualmente los jobs del Log Shipping y recrearlos en el nodo secundario con un paso extra para validar si es o no servidor primario antes de ejecutarse. Al igual que las soluciones anteriores, nos permite expandir las posibilidades de estas soluciones de alta disponibilidad. En concreto podríamos usar esta solución para tener copias de solo lectura de nuestras bases de datos en un servidor fuera del cluster de Always On sin tener que pagar el extra de licenciamiento para hacer accesible el nodo secundario del AG. En este caso el Always On nos daría la capacidad de balanceo automático mientras que el Log Shipping nos dará copias casi en tiempo real de las bases de datos para usarlas para fines de consulta o reporte.

Es importante, no usar este tipo de soluciones en entornos de producción o críticos ya que, como hemos comentado, es una solución no soportada por Microsoft por lo que no tendremos soporte en caso de incidente.

Conclusión

Como hemos podido ver, existen variedad de soluciones de alta disponibilidad en SQL Server, y cada una tiene sus ventajas e inconvenientes. Además podemos combinarlas entre ellas para agregar funcionalidades extra o suplir alguno de sus inconvenientes. Lo importante es analizar las necesidades y los requisitos de nuestro sistema, y elegir la solución que mejor se adapte a nuestro caso. 

Espero que esta serie os haya resultado útil e interesante. Ya sabéis que podéis dejarme aquí abajo vuestras dudas o comentarios y que también tenemos a vuestra disposición nuestro Twitter o mi mail.¡Hasta la próxima!

Publicado por Roberto Carrancio en Alta Disponibilidad, SQL Server, 0 comentarios
03
Ene
2024

Replicación (HA Parte 6)

Continuamos con nuestra serie sobre soluciones de alta disponibilidad en SQL Server hablando de la replicación. La replicación en SQL Server es un mecanismo que permite distribuir y sincronizar datos entre diferentes bases de datos, ya sea en la misma instancia o en instancias separadas. La replicación puede tener varios objetivos, como mejorar el rendimiento, la disponibilidad, la escalabilidad o la seguridad de los datos.

Existen diferentes tipos de replicación en SQL Server, cada uno con sus propias características, ventajas y desventajas. En este artículo vamos a explicar los conceptos básicos de la replicación, los tipos que existen y las razones por las que se utiliza.

¿Qué es la replicación?

La replicación es una solución que nos permite mantener actualizados los datos entre diferentes bases de datos. La base de datos que contiene los datos originales se llama publicador, y las bases de datos que reciben las copias se llaman suscriptores. El publicador puede tener uno o varios suscriptores, y cada suscriptor puede recibir una copia completa o parcial de los datos del publicador.

Todo el proceso se realiza mediante agentes, que son procesos que se encargan de leer, distribuir y aplicar los cambios de los datos entre el publicador y los suscriptores. Los agentes pueden ejecutarse de forma continua o programada, según el tipo de implementación y las necesidades del negocio.

Los agentes utilizan una base de datos intermedia llamada distribuidor, que almacena los cambios de los datos del publicador hasta que son enviados a los suscriptores. El distribuidor puede estar en la misma instancia que el publicador o en una instancia separada.

HA Replicación

Un aspecto importante de esta solución es que se hace a nivel de objeto, es decir, se pueden seleccionar qué tablas, vistas, procedimientos almacenados u otros objetos se quieren replicar, sin tener que replicar toda la base de datos o la instancia. Esto permite tener un mayor control y flexibilidad sobre lo que se replica y cómo se replica. Además, se pueden aplicar filtros, transformaciones o reglas personalizadas para adaptar los datos y objetos replicados a las necesidades específicas de cada caso.

Tipos de replicación

Existen tres tipos principales de replicación en SQL Server según el nivel de detalle, la frecuencia y la dirección de los cambios que se quieren replicar. Elegiremos un tipo u otro de implementación en función de nuestras necesidades. 

Replicación transaccional 

Consiste en enviar los cambios de los datos del publicador a los suscriptores casi en tiempo real, después de cada transacción. Este modo de implementación es adecuado para escenarios en los que necesitamos una alta consistencia y disponibilidad de los datos. Tiene una serie de limitaciones como que todas las tablas tienen que tener PK o que no se puede modificar la estructura de las tablas que participan en la replicación. 

Replicación de instantáneas (snapshot)

Consiste en enviar una copia completa de los datos del publicador a los suscriptores cada cierto tiempo. Este modo de implementación es adecuado para escenarios en los que los datos no cambian con mucha frecuencia o no necesitamos una sincronización inmediata, como por ejemplo en sistemas de reportes o análisis.

Replicación de mezcla (merge)

Consiste en combinar la replicación transaccional y la replicación de instantáneas, permitiendo que tanto el publicador como los suscriptores puedan modificar los datos y sincronizarlos periódicamente. Este modo de implementación es adecuado para escenarios en los que se requiere una alta escalabilidad y flexibilidad, como por ejemplo en sistemas distribuidos o móviles. 

Ventajas y desventajas de la replicación

Ventajas

Como venimos viendo en los distintos artículos de esta serie, tener los datos replicados mejora el rendimiento al reducir la carga de trabajo en el publicador y permitir acceso de lectura desde diferentes ubicaciones. 

Otra de las ventajas de la replicación es que mejora la disponibilidad al proporcionar redundancia y tolerancia a fallos en caso de que el publicador o alguno de los suscriptores no esté disponible. Además nos permite agregar más suscriptores según aumente la demanda lo que se traduce en una buena escalabilidad. Por último, mejora la seguridad al permitir aplicar diferentes niveles de acceso a los datos para cada suscriptor.

Inconvenientes

Sin embargo, la replicación también tiene algunas desventajas. Aumenta la complejidad al requerir una configuración y administración más cuidadosa y detallada. Por otro lado, aumenta el consumo de recursos al requerir más espacio en disco, memoria y red para almacenar y transmitir los datos.

Además, uno de los mayores inconvenientes de la replicación es el riesgo de inconsistencia o pérdida de datos si ocurren errores o conflictos durante el proceso de replicación. Por experiencia, es uno de los procesos en SQL Server con más tasa de error y con un mantenimiento complejo y, a veces, difícil de encontrar la causa de los problemas.

Relación vs Alta Disponibilidad

Como hemos podido ver, la replicación es una forma de lograr la alta disponibilidad. Sin embargo, la replicación no es lo mismo que la alta disponibilidad, ya que esta última implica otros aspectos como el balanceo de carga, el monitoreo, la recuperación ante desastres o el mantenimiento preventivo.

Tanto la replicación como las soluciones de alta disponibilidad buscan mejorar la confiabilidad y la continuidad del servicio minimizando las interrupciones o las pérdidas de datos. La replicación y la alta disponibilidad se complementan y se benefician mutuamente. Sin embargo, mientras que la replicación se enfoca en distribuir y sincronizar los datos, una solución de alta disponibilidad nos debe garantizar el funcionamiento del servicio. La replicación puede ser una parte de una solución de alta disponibilidad, pero no es suficiente por sí sola. 

Conclusión

La replicación en SQL Server es un mecanismo poderoso y versátil que nos permite sincronizar datos entre diferentes bases de datos. Dependiendo del tipo de replicación elegido, se pueden obtener diferentes beneficios y desafíos. Como DBAs, debemos analizar las necesidades del negocio y las características de los datos antes de implementar una solución basada en la replicación. Asimismo, es importante entender la relación entre la replicación y la alta disponibilidad, y cómo ambas pueden contribuir a mejorar el servicio.

La replicación en SQL Server es un tema muy amplio y con muchas opciones de configuración y personalización. En este artículo solo hemos visto una introducción general a la teoría y el por qué de las cosas. Seguro que en futuros artículos hablaremos más en profundidad de este tema, aunque ya será fuera de esta serie. Como ya sabéis, podéis dejarme vuestras dudas y comentarios abajo, por Twitter o mail. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Alta Disponibilidad, SQL Server, 0 comentarios
02
Ene
2024

Log Shipping (HA Parte 5)

Continuamos con la serie de artículos sobre alta disponibilidad, hoy hablaremos de Log Shipping. Log shipping es una técnica de alta disponibilidad que permite replicar los datos de una base de datos de SQL Server en una o varias bases de datos secundarias. De esta forma, podremos tener una copia actualizada (o casi) de los datos en caso de que la base de datos principal falle o se pierda. También nos va a permitir crear copias de sólo lectura de nuestra base de datos en otra ubicación.

¿Cómo funciona Log Shipping?

Log Shipping funciona mediante la creación y el envío periódico de copias de seguridad del log de transacciones de la base de datos principal a las bases de datos secundarias. Estas copias de seguridad se restauran en las bases de datos secundarias, aplicando así los cambios que se han producido en la base de datos principal. 

Cuando configuremos Log Shipping se crearán una serie de jobs en las instancias SQL Server principal y secundarias para hacer las copias de seguridad, moverlas y restaurarlas. Podremos cambiar manualmente las programaciones de estos jobs en función de la periodicidad que deseemos en las instancias secundarias. Esto marcará en gran medida nuestro RPO, por defecto será una copia de seguridad cada 15 minutos pero podemos reducirlo si lo necesitamos.

Pros y contras de Log Shipping

Ventajas

Log shipping es una solución sencilla y económica que no requiere de licencias Enterprise ni clústers complejos para funcionar. Nos va a permitir tener varias bases de datos secundarias, lo que puede mejorar el rendimiento de las consultas de solo lectura y la distribución geográfica de los datos. Además, podremos tener un control total sobre el proceso, ya que se puede configurar la frecuencia, el horario y el modo de envío y restauración de las copias de seguridad. Por último, nos va a ayudar a mantener un RTO relativamente bajo, ya que se puede usar la base de datos secundaria como principal en caso de emergencia.

Inconvenientes

Sin embargo, Log Shipping también tiene algunas limitaciones. No garantiza una sincronización en tiempo real, siempre habrá un retraso entre la base de datos principal y las secundarias dependiendo del intervalo de copia de seguridad y restauración. Esto implica que los objetivos RPO y RTO pueden no ser tan bajos como con otras soluciones. Con Log Shipping, el RPO y el RTO dependen del intervalo configurado para las copias del log.
A nivel operativa diaria, no permite realizar cambios en la estructura o el esquema de la base de datos principal, ya que estos cambios no se replican a través de copias de log de transacciones. Tampoco nos va a permitir en ningún momento tener bases de datos secundarias en modo lectura/escritura. No es compatible con algunas características de SQL Server, como la compresión de datos, el cifrado transparente de datos o las instantáneas de base de datos. Ni con otras soluciones de alta disponibilidad como los Always On (aunque se puede llegar a hacer funcionar no es una solución aprobada por Microsoft.)
Además, no nos va a facilitar ninguna opción de balanceo automático. En caso de error, tendremos que activar manualmente la base de datos secundaria y redirigir a ella todas las conexiones.

Opciones de implementación de Log Shipping

Hemos dicho antes que en Log Shipping podemos tener las copias secundarias accesibles en modo lectura. Esto lo tendremos que configurar cuando configuremos la restauración en el servidor secundario. Tendremos la opción de restaurar las copias de seguridad en modo NORECOVERY o STANDBY. El modo STANDBY nos permitirá mantener nuestras bases de datos secundarias accesibles para lectura. Sin embargo, solo podremos hacerlo si el servidor principal y el secundario tienen la misma versión de SQL Server. Tendremos que usar el modo NORECOVERY si nuestra base de datos secundaria es de una versión superior a la principal.

Tendremos también la posibilidad de modificar el comportamiento de nuestro Log Shipping modificando los jobs que genera. En el servidor principal tendremos dos jobs, uno encargado de hacer las copias de seguridad de log de transacciones y otro que comprobará si se hacen las copias y enviará alertas en caso contrario. Es importante que no tengamos ninguna otra copia de seguridad de log fuera de este job o Log Shipping dejará de funcionar.
En el servidor secundario nos encontraremos tres jobs, el de copia de los archivos de copia de seguridad del servidor principal al secundario, el de restauración y otro de monitorización.

Alta Disponibilidad Log Shipping

Por último, igual que vimos en Database Mirroring, podremos configurar una instancia SQL Server de supervisión. En este caso no será encargada del balanceo pues no tenemos opción de automatizarlo, pero sí que recibirá y almacenará el estado actual y el historial de nuestro Log Shipping.

Conclusión

Aunque siempre se habla de Log Shipping como una solución de alta disponibilidad y hasta yo lo he tratado como tal hasta este punto, realmente no lo es. Como hemos podido ver, debido a sus limitaciones de RPO y RTO la alta disponibilidad real queda muy lejos de esta solución. Sin embargo, me parece una técnica muy útil para mantener una copia actualizada y disponible de los datos en SQL Server. Esto lo convierte en una solución ideal para un DRP o para tener copias de sólo lectura de nuestro servidor de producción, por ejemplo en servidores de análisis o DWH.

Espero que este artículo te haya ayudado a entender mejor qué es Log Shipping y cómo implementarlo en SQL Server. Si tienes alguna duda o comentario, no dudes en dejarlo abajo, en Twitter o por mail. Estaré encantado de ayudarte. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Alta Disponibilidad, SQL Server, 1 comentario
29
Dic
2023

Database Mirroring (HA Parte 4)

El espejo de bases de datos o Database Mirroring es una solución de alta disponibilidad presente en SQL Server desde la versión 2008. Igual que la solución Always On, funciona a nivel de base de datos pero, en este caso, debe configurarse individualmente en cada base de datos. Una de las instancias actuará como primaria (principal) y otra como secundaria (espejo). Como siempre hacemos, vamos a ver sus características y cómo funciona, sin embargo no vamos a comentar cómo implementarlo. Esta es una solución discontinuada por parte de Microsoft que desaparecerá en futuras versiones de SQL en favor de Always On.

Opciones de implementación de Database Mirroring

Database Mirroring funciona sincronizando la base de datos del servidor principal con la base de datos del servidor espejo. No admite más réplicas. Sin embargo, es posible configurar una tercera instancia como testigo (witness) que se encargará del balanceo automático en caso de fallo en el servidor primario. 

La opción más común de implementación de Database Mirroring es con dos servidores SQL cada uno con una instancia replicando una base de datos del principal al espejo. Sin embargo, es posible encontrar Database Mirroring configurados entre instancias de la misma máquina. También es común encontrar una pareja de servidores que son principales para unas bases de datos y espejo para otras. Os dejo esquemas de estas implementaciones sacados de la documentación oficial:

Database Mirroring
Principal + Espejo
Database Mirroring
Principal + Espejo + Testigo
Database Mirroring
Principal/Espejo MIXTO

Modos operativos de Database Mirroring

Podemos configurar nuestros Database Mirroring de tres maneras diferentes y, en función de como lo configuremos cambiarán su comportamiento. Como DBAs deberemos decidir cuál se adapta mejor a nuestro escenario.

Modo alto rendimiento

El modo alto rendimiento solo está disponible en versiones Enterprise de SQL Server. Si optamos por este modo no tendremos opción de usar un servidor como testigo. Los datos se enviarán del servidor principal al espejo de manera asíncrona. Al no admitir un servidor testigo, no es posible configurar un balanceo automático en caso de fallo del servidor principal. Cuando esto pasa, podemos esperar a que vuelva a estar operativo el principal (con la base de datos no disponible), forzar un balanceo manual (con posible pérdida de datos) o actualizar manualmente la base de datos espejo con la última copia de log del servidor principal. 

Modo alta seguridad

Disponible en todas las versiones de SQL Server el modo alta seguridad envía los datos de manera síncrona, la transacción se confirmará tras el commit en ambos servidores. Puede ser un problema si la latencia de red es elevada. En caso de fallo del servidor principal, los datos en el servidor espejo estarán actualizados y no tendremos perdida de datos. Podremos elegir si queremos esperar con la base de datos no disponible o forzar un balanceo manual sin pérdida de datos.

Modo alta seguridad con balanceo automático

Los datos se escriben de manera síncrona en el servidor principal y el espejo pero necesitaremos de un tercer servidor que haga de testigo. En caso de fallo del servidor principal, el servidor testigo será capaz de detectarlo y automáticamente balanceará el rol, convirtiéndose en principal la base de datos del servidor espejo.

Pros y contras de Database Mirroring

La principal ventaja de esta solución es su facilidad de configuración, no requiere de WSFC y es compatible con todas las ediciones y versiones de SQL Server desde 2008. Todo esto permitiéndonos configurar un balanceo automático. Además, se puede combinar con otras opciones como las FCI, el log shipping o la replicación. 

Como hemos empezado comentando, es una solución que será eliminada de futuras versiones de SQL Server en favor de Always On. Siendo soluciones de alta disponibilidad a nivel base de datos, Database Mirroring se debe configurar individualmente por base de datos, no tiene opción de configurar un listener como punto de escucha común para los dos servidores y solo admite una réplica. 

Conclusión

Hemos podido conocer los aspectos básicos de Database Mirroring, una solución de alta disponibilidad de SQL Server discontinuada y que se eliminará en un futuro. Como DBAs evitaremos configurar esta solución por los motivos ya mencionados aunque, como todos sabemos, el mundo real es muy diferente a la teoría y por eso debemos conocerlo y tener claro cómo funciona.

Publicado por Roberto Carrancio en Alta Disponibilidad, SQL Server, 2 comentarios