Infra

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.

Publicado por Roberto Carrancio en Cloud, SQL Server, 0 comentarios

Instancias Administradas en Azure (Introducción)

En este artículo vamos a hablar de las instancias administradas de SQL Server en Azure, un servicio que nos permite tener una experiencia casi idéntica a la de un servidor SQL Server tradicional, pero con las ventajas de la nube. Las instancias administradas de SQL Server en Azure son una opción ideal para migrar nuestras bases de datos SQL Server existentes a Azure sin tener que modificar mucho el código ni la configuración. Además, nos ofrecen todas las ventajas de la nube como un alto nivel de rendimiento, seguridad, escalabilidad y disponibilidad.

¿Qué son las instancias administradas de SQL Server en Azure?

Las instancias administradas de SQL Server en Azure son un tipo de servicio PaaS (Platform as a Service) que nos permite crear y administrar instancias de SQL Server en la nube. Estas instancias tienen casi las mismas características y funcionalidades que un servidor SQL Server tradicional. También soportan las mismas versiones y ediciones de SQL Server, desde la 2008 hasta la 2022, y se actualizan automáticamente con los últimos parches y mejoras.

Las instancias administradas de SQL Server en Azure se diferencian de otros servicios de bases de datos SQL en Azure en que nos permiten tener un mayor control sobre la instancia, como el acceso al sistema operativo, la configuración del firewall, la administración de usuarios y roles, la auditoría y el seguimiento, etc. Además, nos permiten usar características avanzadas de SQL Server que no están disponibles en otros servicios, como el Always On Availability Groups, el Transparent Data Encryption, el Change Data Capture, el Service Broker, etc.

¿Cómo se administran?

La administración de las instancias administradas de SQL Server en Azure es muy similar a la de un servidor SQL Server tradicional. Podemos usar las mismas herramientas y métodos que estamos acostumbrados a usar, como el SQL Server Management Studio, PowerShell o T-SQL. También podemos usar los servicios integrados de Azure para facilitar algunas tareas, como el Azure Portal, el Azure Monitor o el Azure Automation. Veremos más sobre este tema en otro post.

Instancias administradas en Azure VS instancias On Premise

Las instancias On Premise son aquellas que se ejecutan en nuestros propios servidores físicos o virtuales, dentro de nuestra infraestructura local. Estas instancias tienen algunas ventajas sobre las instancias administradas en Azure, como un mayor control sobre el hardware, una menor latencia y una mayor personalización. Sin embargo, también tienen algunos inconvenientes, como un mayor coste, una mayor complejidad y una menor flexibilidad.

Las instancias administradas en Azure nos ahorran los costes y las molestias de tener que comprar, instalar y mantener nuestros propios servidores. Además, nos ofrecen una mayor escalabilidad y disponibilidad, ya que podemos aumentar o reducir los recursos según la demanda y contar con la garantía de un SLA (Service Level Agreement) del 99.99%. También nos facilitan la migración y la recuperación de nuestras bases de datos, ya que podemos usar herramientas como el Data Migration Service o el Backup and Restore.

La elección entre las instancias administradas o las instancias on premise dependerá de nuestras necesidades y preferencias. Si queremos tener una solución más económica y flexible, con todas las ventajas de la nube, las instancias administradas son la mejor opción. Si queremos tener una solución más personalizada y con menos dependencia de internet, las instancias on premise pueden ser suficientes.

Instancias administradas en Azure VS Bases de datos de Azure

El servicio de bases de datos SQL en Azure es otro tipo de servicio PaaS que nos permite crear y administrar bases de datos SQL en la nube como ya vimos en el post anterior. Sin embargo, a diferencia de las bases de datos de Azure, las instancias administradas nos ofrecen una instancia completa de SQL Server y no solo una base de datos aislada que se ejecuta en un servidor compartido con otros clientes. Esto implica que tenemos mayor control sobre la base de datos y que podemos usar algunas características de SQL Server propias de la instancia.

El servicio de bases de datos SQL en Azure tiene algunas ventajas sobre las instancias administradas, como un menor coste, una mayor elasticidad y una menor complejidad. Sin embargo, también tiene algunas limitaciones, como una menor compatibilidad con las versiones y ediciones de SQL Server, una menor capacidad para escalar verticalmente y una menor flexibilidad para migrar o restaurar bases de datos.

La elección entre las instancias administradas o el servicio de bases de datos SQL en Azure dependerá de nuestras necesidades y preferencias. Si queremos tener una experiencia similar a la de un servidor SQL Server tradicional, con todas sus características y funcionalidades, las instancias administradas son la mejor opción. Si queremos tener una solución más simple y económica, con solo lo necesario para alojar nuestras bases de datos SQL, el servicio de bases de datos SQL en Azure puede ser suficiente.

Conclusión

Las instancias administradas de SQL Server en Azure son un servicio que nos ofrece una forma fácil y rápida de migrar nuestras bases de datos SQL Server existentes a la nube, sin perder ninguna característica ni funcionalidad. Se trata de un servicio PaaS que nos brinda un alto nivel de rendimiento, seguridad, escalabilidad y disponibilidad, así como un gran control sobre la instancia. Como esto se alargaba ya demasiado, mañana hablamos de temas más técnicos de la administración de este servicio (que seguro que os interesa más), mientras tanto, podéis dejarme vuestros comentarios aquí abajo, en Twitter o por mail.

Publicado por Roberto Carrancio en Cloud, SQL Server, 1 comentario

Data Migration Assistant: Migrar de SQL Server a Azure SQL

En el pasado post vimos las distintas soluciones de SQL en la nube. En este post vamos a hablar de la herramienta Data Migration Assistant (o DMA), una aplicación de Microsoft que nos va a permitir migrar bases de datos SQL de nuestros servidores On Premise a la nube de Azure de forma fácil y rápida. Esta herramienta es ideal para los profesionales que quieren aprovechar las ventajas de la nube, como la escalabilidad, la seguridad y el ahorro de costes, sin perder el control y el rendimiento de sus datos.

Que es Data Migration Assistant

Data Migration Assistant es una solución integrada que nos ofrece Microsoft para facilitar el proceso de migración de bases de datos SQL a Azure. Con esta herramienta, además, podemos realizar las siguientes tareas:

  • Analizar el estado y la compatibilidad de nuestras bases de datos SQL con Azure.
  • Seleccionar el servicio de Azure más adecuado para alojar nuestras bases de datos, ya sea Azure SQL Database, Azure SQL Managed Instance o Azure SQL Server en una máquina virtual.
  • Realizar la migración de los datos, los esquemas, los objetos y las configuraciones de nuestras bases de datos SQL a Azure.
  • Validar y monitorizar el resultado de la migración y resolver posibles problemas.

¿Cómo usar Data Migration Assistant?

Para usar Data Migration Assistant necesitamos tenerlo instalado en nuestro equipo local, no os preocupéis porque es una aplicación gratuita que nos permite realizar el análisis y la evaluación de nuestras bases de datos SQL. También necesitamos tener una cuenta de Azure con una suscripción activa.

El proceso de migración se realiza en cuatro pasos:

  1. Crear un proyecto de migración en el DMA, indicando el origen y el destino de los datos, el tipo de migración (esquema, datos o ambos) y el alcance del proyecto (una o varias bases de datos).
  2. Ejecutar una evaluación de las bases de datos seleccionadas, que nos mostrará un informe con los posibles problemas de compatibilidad, las recomendaciones y las acciones correctivas que debemos realizar antes de la migración.
  3. Crear o seleccionar el servicio de Azure donde queremos alojar nuestras bases de datos, configurando los parámetros necesarios como el tamaño, la ubicación, la red y la seguridad.
  4. Ejecutar la migración propiamente dicha, que se realizará en modo online u offline dependiendo del servicio de destino elegido. Durante la migración podremos ver el progreso y el estado de cada base de datos.

Al finalizar la migración podremos acceder a nuestras bases de datos SQL en Azure desde cualquier dispositivo y aplicación, con las mismas funcionalidades y herramientas que teníamos en On Premise, pero con las ventajas añadidas de la nube.

Otros usos de Data Migration Assistant

Además de para migrar hacia Azure, DMA nos permite realizar migraciones entre otros entornos incluidos de On Premise a On Premise, AWS a On Premise, incluso a servidores SQL en servidores Linux. DMA acepta como origen todas las versiones de SQL Server On Premise desde SQL 2005 hasta SQL 2022 así como AWS RDS. Como destino podremos seleccionar cualquier SQL On Premise desde SQL 2012 hasta SQL 2022 o los servicios de Azure ya mencionados.

Por si esto fuese poco, no solo migrará nuestras bases de datos sino también objetos como inicios de sesión, roles de servidor e, incluso, evaluará la viabilidad de la migración de los paquetes SSIS.

Alternativas

Si no queremos usar Data Migration Assistant para realizar la migración, existen otras alternativas como:

  • Usar el portal de Azure o PowerShell para crear y configurar manualmente los servicios de destino y copiar los datos mediante herramientas como SQL Server Management Studio (SSMS), Azure Data Studio o bcp.
  • Usar Azure Database Migration Service (DMS), que es un servicio gestionado que nos permite realizar migraciones online o offline con un mínimo tiempo de inactividad. DMS soporta más tipos de origen y destino que DMA, como Oracle, MySQL o PostgreSQL.
  • Usar otras herramientas o servicios externos que ofrezcan soluciones específicas para cada caso, como Apex, Flyway, Redgate o Attunity.

Conclusión

Data Migration Assistant es una herramienta muy útil cuando queremos llevar a cabo una migración de SQL Server a la nube o a un entorno local sin complicaciones ni riesgos. Con esta herramienta podemos realizar una migración rápida, segura y eficiente, aprovechando al máximo los recursos y servicios que nos ofrece Azure. Si os ha quedado cualquier duda o queréis contarme vuestra opinión os leo en los comentarios, en Twitter o en mi mail..

Publicado por Roberto Carrancio en Cloud, SQL Server, 2 comentarios
Instalación de SQL Server para SharePoint

Instalación de SQL Server para SharePoint

Hoy voy a compartir con vosotros algunos consejos y buenas prácticas para instalar y configurar SQL Server cuando se va a usar para alojar bases de datos de SharePoint. SharePoint es una plataforma de colaboración y gestión de contenidos que permite crear sitios web, intranets, extranets y aplicaciones web. Igual que SQL Server, Sharepoint es un producto de Microsoft. Esto hace que SQL Servery Sharepoint se integren perfectamente, pero requieren una configuración adecuada para aprovechar al máximo sus funcionalidades y evitar problemas de rendimiento, seguridad o compatibilidad.

En este artículo voy a explicar los pasos que hay que seguir para instalar y configurar SQL Server para SharePoint, desde la elección de la edición y la versión, hasta la creación de las bases de datos y la asignación de permisos. También voy a comentar algunas recomendaciones generales y específicas para optimizar el funcionamiento de SQL Server con SharePoint. Espero que os resulte útil y que os animéis a dejar vuestros comentarios y experiencias al final del post.

Elección de la versión de SQL Server ideal para SharePoint

Lo primero que hay que hacer es elegir la edición y la versión de SQL Server que se va a utilizar para SharePoint. Esto dependerá del tamaño, la complejidad y los requisitos de la solución que se quiera implementar. SQL Server ofrece varias ediciones, desde la gratuita Express hasta la más completa Enterprise, pasando por la Standard. Cada edición tiene unas características, unas limitaciones y un precio diferente, por lo que hay que evaluar cuál se adapta mejor a las necesidades del proyecto.

Además, hay que tener en cuenta la versión de SQL Server que se va a instalar, ya que no todas son compatibles con todas las versiones de SharePoint. Por ejemplo, SharePoint 2019 solo es compatible con SQL Server 2016 SP1 o superior, mientras que SharePoint 2016 puede funcionar con SQL Server 2014 SP1 o superior. Es importante consultar la documentación oficial de Microsoft para verificar la compatibilidad entre las versiones de SQL Server y SharePoint antes de proceder con la instalación.

Diseño de arquitectura ideal para SharePoint

SharePoint es una aplicación que hace un uso bastante intensivo de SQL Server, en especial del espacio en disco. Por lo tanto, un buen planteamiento de la arquitectura inicial del servidor nos evitará problemas a medio, largo plazo. Considera también el uso de sistemas escalables en caliente como máquinas virtuales que nos permitan añadir más RAM y almacenamiento en cabinas que permitan ampliar el espacio de tus unidades de disco duro. 

SharePoint está preparado y optimizado para trabajar con varios servidores SQL Server, lo que nos permitirá añadir nuevos servidores cuando lleguemos al límite de recursos de los actuales. Como hemos comentado, hace un uso intensivo del almacenamiento por lo que, ahí tendremos nuestro cuello de botella. Es probable que Sharepoint rinda mejor con varios servidores SQL más pequeños que con uno grande al repartir más el consumo de E/S. Además de esto, ten en cuenta que como norma general sé recomienda un servidor SQL para máximo 4 servidores web. 

Recomendaciones de memoria RAM

La memoria RAM que necesiten nuestros servidores SQL Server irá directamente relacionada con el tamaño de las bases de datos que vayan a albergar. Como recomendación nunca asignaremos menos de 32 Gb de RAM a estos SQL. Si las bases de datos superan los 2 Tb de espacio la recomendación es de 64 Gb de RAM. Para bases de datos que superen los 5 Tb añadiremos más de 64 Gb de RAM.

Estimación del espacio en disco

Como hemos comentado, el diseño de nuestra infraestructura irá ligado a las necesidades de almacenamiento. Es por esto que, una estimación del tamaño necesario, es clave para el éxito de nuestro proyecto. 

SharePoint usa varios tipos de bases de datos, por un lado tenemos las bases de datos de configuración que son pequeñas y no nos consumirán más de 5Gb como norma general. Donde realmente vamos a consumir espacio, es en las bases de datos de contenido. Como existen multitud de casuísticas, se hace imposible dar una recomendación de espacio general. Sin embargo Microsoft nos proporciona la siguiente fórmula para nuestro cálculo:

Tamaño de base de datos (KB) = ((D x V) x S) + (10 KB x (L + (V x D)))

El valor D de la fórmula hace referencia al número de documentos. Es fácil conocer el número de documentos cuando estamos haciendo frente a una migración sin embargo para una nueva instalación la cosa se complica. Deberemos estimar un número de documentos por usuario y multiplicarlo por el número de usuarios de nuestro sitio.
V hace referencia al número de versiones que vamos a permitir almacenar de cada uno de los documentos.
El valor S hace referencia al tamaño medio de los documentos, aunque es difícil de calcular puede ser de ayuda calcular el tamaño medio de los documentos actuales con los que trabajan los usuarios.
Llegamos al valor L, lo más difícil de estimar. Este se corresponde con el número estimado de elementos de lista. Microsoft habla de un cálculo genérico de 3 veces la cantidad de documentos pero esto variará en función del tipo de aplicación y los escenarios de uso.
Por último el valor de 10 KB es una constante que hace referencia al tamaño de los metadatos de cada elemento.

Veamos un ejemplo:

Supongamos que tenemos una aplicación para 500 usuarios que usarán de media 100 documentos de aproximadamente 250 KB. Aunque admitimos 10 versiones de documentos hemos calculado que la media de versiones por documento será de 4. En este caso nuestro valor D es 50.000, S es 250 y V es 4. L será 150.000 (3 veces el número de documentos)

Tamaño de base de datos = ((50.000 x 4) x 250) + (10 KB x (150.0000 + (4 x 50.000)))
Tamaño de base de datos = 8.500.000 KB
Tamaño de base de datos = 8.500.000 KB / 1024 / 1024 = 8 Gb

Hay que tener en cuenta que en función de cómo se configure SharePoint puede requerir un espacio adicional, por ejemplo en esto juegan un papel importante la opción de papelera de reciclaje y la de auditoría además de otras opciones. Os recomiendo consultar detenidamente la documentación oficial sobre el tema conjuntamente con el administrador de SharePoint.

Otras recomendaciones de arquitectura

Para cerrar este apartado es importante mencionar un par de buenas prácticas a nivel red. Por un lado todos los servidores (tanto SQL como web) deben estar en la misma LAN (no se recomiendan las redes WAN) con una latencia igual o inferior a 1 milisegundo. Además, se recomienda que exista una subred dedicada a la comunicación de los servidores independiente a la red de tráfico de los usuarios. 

Instalar SQL para SharePoint

Una vez elegida la edición y la versión de SQL Server así como planteada la arquitectura, el siguiente paso es instalar el software en el servidor o servidores donde se va a alojar las bases de datos de SharePoint. Para ello, hay que seguir el asistente de instalación y seleccionar las opciones adecuadas según el escenario que se quiera configurar. Algunas de las opciones más importantes son:

– Tipo de instalación: se puede optar por una instalación nueva o una instalación existente. Siempre es recomendable crear una instalación nueva para nuestro SharePoint en un servidor dedicado para ella que no comparta recursos con otros procesos.
– Tipo de motor: se puede elegir entre un motor independiente o un motor en clúster. El motor independiente es el más sencillo y consiste en instalar SQL Server en un único servidor. El motor en clúster es más complejo y requiere configurar un WSFC para proporcionar alta disponibilidad y tolerancia a fallos. Tendremos que tener en cuenta nuestros objetivos de RPO y RTO así como nuestro presupuesto a la hora de elegir una solución u otra.
– Características: A la hora de elegir qué características queremos instalar os recomiendo siempre seleccionar el mínimo necesario. Una buena práctica sería instalar solo el motor de bases de datos para optimizar los recursos del servidor. Si necesitamos Analysis Services, Reporting Services o Integration Services la recomendación será instalarlos en otro servidor.
– Nombre de la instancia: Para SharePoint usaremos únicamente instancias con nombre, evitaremos usar las instancias por defecto.
– Collation: SharePoint creará sus bases de datos con la collation Latin1_General_CI_AS_KS_WS por lo que es importante elegir esta misma collation para el servidor. Si no lo hacemos podremos sufrir errores de conflicto entre collations.

Conclusión

En este artículo hemos visto todo lo necesario para la instalación de SQL Server para SharePoint. Os había prometido hablaros también de las buenas prácticas de configuración, que seguramente sea lo que más os importe a la hora de optimizar vuestros servidores, lamentablemente el tema es tan extenso que en un solo artículo no he podido añadirlo. Estad atentos porque en el siguiente artículo me centraré solo en este tema para garantizar que vuestros SQL rindan de la mejor manera posible con SharePoint. Si estáis leyendo esto el día que se ha publicado, mañana tendréis la segunda parte. Recuerda que puedes dejarme tus comentarios o preguntas al final del artículo, en Twitter o por mail. Hasta la próxima.

Publicado por Roberto Carrancio en SQL Server, 2 comentarios

Always On Availability Groups (HA Parte 2)

Como adelantamos ayer en la introducción sobre las distintas soluciones de alta disponibilidad que ofrece SQL Server vamos a profundizar una a una en cada una de ellas. Hoy en concreto vamos a hablar de la joya de SQL Server en este sentido, los grupos de disponibilidad Always On. Los Always On de SQL Server son una solución de alta disponibilidad y recuperación ante desastres que permite tener varias réplicas de una base de datos en diferentes servidores o ubicaciones. En este artículo, vamos a explicar cómo funcionan, qué ventajas ofrecen y cómo configurarlos paso a paso.

¿Qué son los grupos de disponibilidad Always On?

Los grupos de disponibilidad Always On son una característica introducida en SQL Server 2012 que nos permite tener hasta ocho réplicas secundarias de una base de datos primaria. Las réplicas secundarias se sincronizan automáticamente con la primaria de manera síncrona o asíncrona. Cada réplica secundaria puede tener un rol diferente, según el nivel de compromiso con la primaria y el tipo de operaciones que se permiten realizar sobre ella.

Los Always On permiten que las réplicas secundarias pueden estar en el mismo servidor o en servidores distintos, e incluso en diferentes regiones geográficas o la nube. Esto nos ofrece una gran flexibilidad y escalabilidad para adaptarlos a las necesidades de cada escenario.

Nivel de compromiso de las réplicas secundarias

Como hemos dicho, la replicación puede ser síncrona o asíncrona, esto es un factor clave a la hora de diseñar nuestra solución de alta disponibilidad y afectará a todo lo demás.

Replicación síncrona

Las réplicas secundarias se comprometen a aplicar los cambios recibidos de la primaria antes de confirmar la transacción al cliente. Esto quiere decir que sin tener confirmación de todas las réplicas síncronas la transacción no se va a confirmar. Esto nos garantiza que las réplicas están siempre en el mismo estado, evitando la pérdida de datos, pero afectando al rendimiento de las escrituras. Las réplicas síncronas pueden tomar el rol de primaria en caso de fallo, mediante un proceso de conmutación por error automático o manual. Usaremos este tipo de réplicas como solución de alta disponibilidad siempre que la latencia de red no sea un problema. En este sentido, es recomendable usar una red dedicada para la replicación del Always On independiente a la red de servicio a los usuarios.

Replicación asíncrona

Las réplicas no se comprometen a aplicar los cambios recibidos de la primaria inmediatamente, sino que lo hacen cuando les sea posible. Esto mejora el rendimiento de las operaciones de escritura, pero puede provocar que la secundaria tenga un cierto retraso respecto a la primaria. Las réplicas asíncronas pueden tener pérdidas de datos por lo que requieren una intervención manual para forzar la conmutación por error.

Acceso a los grupos de disponibilidad Always On

Para facilitar el acceso a las bases de datos del Always On, se utiliza el listener, que es un nombre virtual que representa al grupo de disponibilidad y que se resuelve en la dirección IP de la réplica primaria o de una réplica secundaria legible, según el criterio de enrutamiento que se defina. El listener permite a las aplicaciones conectarse al grupo de disponibilidad sin tener que conocer el nombre o la dirección IP de cada réplica. Cuando conectamos al listener este nos redirigirá siempre a la réplica primaria a no ser que le especifiquemos lo contrario mediante el parámetro ApplicationIntent=ReadOnly que nos llevará a una réplica secundaria de solo lectura.

Para configurar el listener, se debe especificar un nombre, un puerto y una dirección IP para cada subred en la que se encuentren las réplicas. Además, se debe crear un registro DNS con el nombre del listener y las direcciones IP asignadas. 

Nivel de acceso a las réplicas secundarias

Hemos estado comentando que podemos acceder a las réplicas secundarias en modo de lectura. Realmente, pueden tener diferentes modos de acceso, según el tipo de consultas que se puedan ejecutar sobre ellas, vamos a verlo:

Modo solo lectura

Permite ejecutar consultas de solo lectura sobre la réplica secundaria, lo que puede servir para balancear la carga de trabajo o para realizar operaciones de mantenimiento o copia de seguridad sin afectar a la primaria. Para habilitar este modo, es necesario que la réplica secundaria esté sincronizada con la primaria y que tenga habilitada la opción READ_ONLY_ROUTING_URL, que indica la dirección a la que deben dirigirse las conexiones de solo lectura.

Modo solo intención de lectura

Permite ejecutar consultas de solo lectura sobre la réplica secundaria, pero solo si la conexión especifica explícitamente esa intención mediante el parámetro ApplicationIntent=ReadOnly. Esto puede servir para separar las conexiones que requieren acceso a la primaria de las que pueden usar una secundaria, según el criterio de la aplicación cliente. Para habilitar este modo, se requieren las mismas condiciones que para el modo solo lectura.

Modo sin acceso

No permite ejecutar ninguna consulta sobre la réplica secundaria, solo se usa para mantener una copia sincronizada con la primaria. Este modo se usa cuando no se desea dar acceso a los datos de la secundaria o cuando la réplica está en proceso de sincronización o restauración. Si contamos con una licencia de SQL Server con Software Assurance es probable que optemos por este modo de réplica secundaria ya que no requiere de licencia adicional para la instancia secundaria.

¿Qué ventajas ofrecen los grupos de disponibilidad Always On?

Los grupos de disponibilidad Always On ofrecen varias ventajas como solución de alta disponibilidad y recuperación ante desastres:

– Permiten tener varias copias de una base de datos en diferentes servidores o ubicaciones, lo que aumenta la protección ante fallos o desastres.

– Pueden conmutar por error entre réplicas de forma automática o manual, lo que reduce el tiempo de inactividad y facilita la administración.

– Nos ayudan a balancear la carga de trabajo de nuestro servidor pudiendo delegar en las réplicas secundarias las consultas de solo lectura y las copias de seguridad.Para esto último,se debe configurar la opción «Backup priority» en las propiedades del grupo de disponibilidad.

– Permiten acceder a los datos de las réplicas secundarias para consultas de solo lectura o para operaciones de mantenimiento o copia de seguridad, lo que mejora el rendimiento y la escalabilidad.

– Se integran con otras características de SQL Server, como el agrupamiento en clústeres Windows Server Failover Cluster (WSFC), el servicio Broker para controlar el flujo

de mensajes entre las réplicas o el Listener para facilitar el acceso a las bases

de datos mediante un nombre virtual.

¿Qué requisitos se necesitan para usar los grupos de disponibilidad Always On?

Para usar los grupos de disponibilidad Always On se necesitan cumplir los siguientes requisitos:

– Tener instalada la edición Enterprise de SQL Server 2012 o superior, ya que la edición Standard solo permite tener una réplica secundaria y no admite el modo solo lectura ni el enrutamiento de lectura. La edición Developer también admite los grupos de disponibilidad Always On, pero solo para fines de desarrollo y pruebas.

– Tener configurado un clúster WSFC con al menos dos nodos, que serán los servidores donde se alojarán las réplicas primaria y secundaria. El clúster WSFC se encarga de monitorizar el estado de las réplicas y de realizar la conmutación por error si es necesario.

– Tener las bases de datos que se quieren proteger en modo de recuperación completa, lo que implica hacer copias de seguridad periódicas del log de transacciones para evitar que crezca demasiado.

¿Cómo se configuran los grupos de disponibilidad Always On?

Para configurar los grupos de disponibilidad Always On se deben seguir los siguientes pasos:

– Crear un grupo de disponibilidad en el servidor que aloja la base de datos primaria, especificando el nombre del grupo, las bases de datos que se quieren proteger y las opciones de configuración, como el modo de conmutación por error o el modo de acceso a las réplicas secundarias.

– Añadir una o más réplicas secundarias al grupo de disponibilidad, especificando el servidor donde se alojan, el modo de compromiso y el modo de acceso. También se debe indicar si la réplica secundaria será una copia de seguridad preferente o si tendrá habilitado el enrutamiento de lectura.

– Inicializar las réplicas secundarias mediante una copia de seguridad y restauración de las bases de datos primarias o mediante una sincronización automática si se dispone de una conexión compartida entre los servidores.

– Verificar el estado y el funcionamiento del grupo de disponibilidad, comprobando que las réplicas están sincronizadas, que se pueden realizar consultas sobre ellas y que se puede conmutar por error entre ellas.

Conclusión

Los grupos de disponibilidad Always On son una solución avanzada y flexible para garantizar la alta disponibilidad y la recuperación ante desastres de las bases de datos SQL Server. Permiten tener varias réplicas sincronizadas de una base de datos primaria, que pueden asumir el rol de primaria en caso de fallo o servir para consultas de solo lectura o para operaciones de mantenimiento o copia de seguridad. Para usar esta característica se requiere tener la edición Enterprise de SQL Server 2012 o superior y configurar un clúster WSFC. En este artículo hemos explicado cómo funcionan los grupos de disponibilidad Always On, qué ventajas ofrecen y cómo configurarlos paso a paso. Si os ha quedado alguna duda o comentario ya sabeis que podeis ponerlo aquí en los comentarios, mandarme un mail o en twitter.

Publicado por Roberto Carrancio en Alta Disponibilidad, SQL Server, 14 comentarios
PRE INSTALACIÓN DE SQL SERVER: Buenas prácticas

PRE INSTALACIÓN DE SQL SERVER: Buenas prácticas

Hola, amigos y amigas del blog. Hoy vamos a hablar sobre algunos aspectos a tener en cuenta y las buenas prácticas antes de instalar SQL Server. Sé que a muchos os puede parecer una tarea trivial pero es clave para el rendimiento futuro de nuestro servidor, no queremos que nuestra instalación termine siendo un desastre, ¿verdad?

Lo primero que hay que hacer es verificar los requisitos mínimos del sistema para instalar SQL Server. No vaya a ser que nos quedemos sin espacio en el disco duro, o que nuestra memoria RAM no dé la talla. Para eso, podemos consultar la documentación oficial de Microsoft, o usar alguna herramienta como el Asistente de instalación de SQL Server, que nos ayuda a comprobar si nuestro equipo cumple con los requisitos.

Lo segundo que hay que hacer es planificar la configuración de SQL Server. Esto implica decidir qué características vamos a instalar, cómo vamos a organizar las instancias y las bases de datos, qué tipo de autenticación vamos a usar, cómo vamos a configurar la seguridad y el rendimiento, y otras opciones más. Para esto, yo siempre tengo en cuenta estos 4 puntos fundamentales:

ENTORNO

Se debe intentar que los servidores SQL sean dedicados, solo deben alojar aplicaciones de SQL server. En caso de que por necesidades de un aplicativo en SQL deba convivir con otros servicios de terceros debemos extremar la vigilancia sobre el rendimiento y la seguridad. Si seguimos las buenas prácticas de Microsoft, SQL Server no se instalará en ningún caso sobre un servidor que albergue el rol de controlador de dominio. Tampoco es recomendable instalar más de una instancia en un mismo servidor, si lo hacemos deberemos jugar después con resource governor para asegurarnos que el rendimiento de las instancias es el deseado.

SISTEMA OPERATIVO

La instalación de SQL Server se puede hacer sobre entornos Windows Server o Windows de usuario. Desde SQL Server 2017 también es posible instalar SQL Server sobre entornos Linux aunque en este caso es posible que no tengamos disponibles todas las características. En el caso de un sistema operativo Mac no hay soporte nativo, sin embargo, es posible beneficiarse de la posibilidad de instalación de SQL Server sobre contenedores Docker para tener una instancia funcional en estos entornos.

En caso de una instalación de un entorno de alta disponibilidad debe existir un Windows Server Failover Cluster entre los servidores o en el caso de Linux un clúster pacemaker.

DISCOS DUROS

Según las buenas prácticas, todo servidor SQL debe tener al menos 4 discos, uno para el sistema operativo y los de SQL: datos, log, y TempDB. Adicionalmente podrán existir más discos de datos o logs. A la hora de dimensionar los discos debemos dimensionar el disco de datos de manera que tenga capacidad suficiente para los datos actuales y futuros a medio plazo (en un mundo ideal este dato nos lo dará el equipo que solicita el servidor). Los discos de TempDB y Log deberán ser entre el 10 y el 30% de la capacidad total de los datos.

Si no nos ha quedado más remedio que instalar nuestro SQL en un servidor compartido con aplicaciones, estas deberemos instalarlas en un disco independiente a SQL Server. Del mismo modo, no es buena idea compartir discos duros entre varias instancias de SQL Server.

Para terminar con el apartado de discos duros, todos los discos de SQL server deben estar formateados con el valor bytes per cluster a 64kb. Para comprobarlo podemos ejecutar el siguiente comando de powershell: “fsutil fsinfo ntfsinfo <drive>”

Bytes per Cluster, Instalación SQL

 SEGURIDAD

En un entorno dedicado para SQL Server solo los administradores del sistema operativo y los DBAs deberían tener acceso. Los servicios de SQL deben ejecutarse bajo cuentas de servicio que cumplan con las políticas de seguridad. En este sentido, tenemos que tener en cuenta que las cuentas que configuremos para el motor de bases de datos y para el agente de SQL Server deberán tener permisos sobre los directorios de datos o backups en función de lo que esperemos hacer en un futuro.

Con todo esto definido ya habríamos terminado de prepararnos y podemos pasar a descargar la versión de SQL que más se adapte a nuestras necesidades y, por fin, a instalar, que en este punto ya estaréis todos deseosos de empezar a cacharrear.

Esto sería todo por hoy, espero que os haya gustado este post sobre los aspectos a tener en cuenta y las buenas prácticas antes de instalar SQL Server. Si han quedado dudas o tenéis algún comentario, no dudéis en dejarlo abajo. Y si os ha gustado, compartidlo con vuestros colegas DBAs. Hasta la próxima.

Publicado por Roberto Carrancio en SQL Server, 2 comentarios