Infra

20
Feb
2024

¿Qué nivel de RAID elegir para SQL Server?

En este artículo vamos a hablar de un tema muy importante para el rendimiento de nuestras bases de datos: el nivel de RAID más adecuado para los discos de los servidores de SQL Server. Aunque en el mundo de las máquinas virtuales y de la nube cada vez tenemos menos control sobre este tema, sigue siendo importante. Y seguro que, si lleváis tiempo en esto de las bases de datos, sobre todo en temas de arquitectura, habéis tocado el tema en alguna ocasión.

¿Qué es un RAID y por qué nos interesa?

RAID son las siglas de Redundant Array of Independent Disks, es decir, un conjunto redundante de discos independientes. Se trata de una forma de combinar varios discos físicos en una unidad lógica que mejora el rendimiento y la tolerancia a fallos. Con un RAID podemos aumentar la velocidad de lectura y escritura de los datos, así como protegerlos en caso de que uno o más discos fallen. Además nos ofrece una gran capacidad de redimensionamiento con unas posibilidades de crecer o decrecer impresionantes.

Niveles de RAID

Existen diferentes tipos de RAID, cada uno con sus ventajas e inconvenientes. Los más comunes son:

RAID 0

Consiste en dividir los datos en bloques y distribuirlos entre dos o más discos. No hay redundancia, por lo que si uno de los discos falla se pierden todos los datos. Sin embargo, ofrece el mayor rendimiento, ya que se aprovecha al máximo la capacidad y la velocidad de todos los discos.

RAID 1

Consiste en duplicar los datos en dos o más discos. Hay redundancia total, por lo que si uno de los discos falla se puede recuperar toda la información del otro. Sin embargo, se desperdicia la mitad de la capacidad y se reduce el rendimiento, ya que se tiene que escribir lo mismo en todos los discos.

RAID 5

Consiste en dividir los datos en bloques y distribuirlos entre tres o más discos, junto con un bloque de paridad que permite reconstruir los datos en caso de fallo de uno de los discos. Hay redundancia parcial, por lo que se puede tolerar la pérdida de un disco sin perder datos. Ofrece un buen equilibrio entre rendimiento y capacidad, ya que solo se pierde el espacio equivalente a un disco.

RAID 6

Es similar al 5, pero con dos bloques de paridad en lugar de uno. Esto permite tolerar la pérdida de dos discos sin perder datos. Ofrece mayor seguridad que el RAID 5, pero menor rendimiento y capacidad, ya que se pierde el espacio equivalente a dos discos.

RAID 10

Es una combinación de RAID 0 y 1. Consiste en crear varios grupos de discos en RAID 0 y luego duplicarlos en RAID 1. Ofrece el máximo rendimiento y seguridad, pero también el mayor coste y desperdicio de espacio, ya que se necesita el doble de discos que en un RAID 0.

¿Qué nivel de RAID elegir para SQL Server? 

El problema de SQL Server en este sentido, es que no todos los archivos tienen un uso de disco semejante. Al revés, cada archivo de SQL hace un uso distinto del disco por lo que no hay una solución ideal para todos los casos. Es por esto que vamos a diferenciar 4 grandes grupos distintos en función de sus necesidades. Por un lado tenemos las bases de datos de sistema master y msdb, por otro los archivos de log de transacciones (LDF), en tercer lugar los archivos de datos (MDF y NDF) y por último la base de datos de sistema TempDB. Cada uno tiene unas características y necesidades diferentes:

Base de datos master 

Esta base de datos contiene la información sobre las bases de datos y las configuraciones del servidor. Es un archivo pequeño pero crítico, ya que sin él no se puede iniciar SQL Server. Por eso, lo ideal es almacenarlo en un nivel que ofrezca la máxima seguridad, como el RAID 1 o el 10.

Archivos de Logs

Los archivos de logs contienen el historial de todas las transacciones realizadas en la base de datos. Es un archivo que crece continuamente y que requiere una alta velocidad de escritura. Por eso, lo ideal es almacenarlo en un nivel que ofrezca el máximo rendimiento, como el RAID 0 o el 10.

Archivos de datos

Los archivos de datos contienen los datos propiamente dichos de la base de datos. Es un archivo que puede ser muy grande y que requiere una buena velocidad tanto de lectura como de escritura. Por eso, lo ideal es almacenarlo en un nivel que ofrezca un buen equilibrio entre rendimiento, capacidad y seguridad, como el RAID 5 o el 6. 

TempDB

Este archivo almacena los datos temporales generados por las consultas y operaciones internas del servidor. Es un archivo muy utilizado y muy sensible al rendimiento, por lo que requiere una atención especial. Lo ideal es almacenarlo en un nivel que ofrezca la mayor velocidad posible, como el RAID 0 o el 10. Sin embargo, hay que tener en cuenta que el archivo temporal se borra cada vez que se reinicia SQL Server, por lo que no hay que preocuparse por la seguridad o la capacidad de los discos así que podremos alojarlos también en un disco SSD que no tengamos configurado en RAID.

Conclusión

Como vemos, no hay una respuesta única al nivel de RAID óptimo para SQL Server, sino que depende del tipo y la importancia de cada archivo. Como norma general, la opción RAID 10 parece la menos mala dando un buen compromiso entre rendimiento y profundidad. Sin embargo, es la opción más costosa así que no es la adecuada para todo el mundo. Lo más recomendable es analizar las características y necesidades específicas de cada caso y elegir el nivel que mejor se adapte a ellas. Tendremos que conocer bien el uso de nuestro servidor para poder priorizar una solución RAID sobre otra en caso de que no tengamos la posibilidad de implementar varias.

Espero que este artículo te haya resultado útil e interesante. Si tienes alguna duda o comentario, no dudes en contactarnos en Twitter o por mail o dejarnos un mensaje en los comentarios de aquí abajo. Y recuerda que también tenemos un grupo de LinkedIn al que te puedes unir.

CREDITOS: Hoy quiero dar las gracias a mi amigo Aurelio Montalvillo García, arquitecto de soluciones IT que revisó este post antes de su publicación y me aconsejó alguna mejora.

Publicado por Roberto Carrancio en Rendimiento, SQL Server, 1 comentario
16
Feb
2024

DRP ¿Cómo sobrevivir a una caída total de las bases de datos?

Hoy nos sumergimos en las profundidades del Plan de Recuperación ante Desastres (DRP) en el mundo de las bases de datos. Los DRP son algo imprescindible para todos los que trabajamos con entornos de producción con cierta criticidad. Puede parecer algo lejano y muy avanzado si estás empezando en este mundo, pero no te preocupes, vamos a intentar aclarar el mar de acrónimos y jerga técnica que rodea este tema. 

¿Qué es un DRP?

Lo primero de todo sería aclarar que el DRP forma parte del BCP (plan de continuidad de negocio). En ocasiones se pueden llegar a confundir pero no son lo mismo. Mientras que un DRP es un plan técnico que se centra en recuperar la infraestructura, el BCP incluye mucha más información como los pasos necesarios para mitigar pérdidas y recuperar toda la organización. 

¿Para qué sirve el DRP?

Vale, ya hemos dicho que el DRP es un plan puramente técnico que recoge de la manera más detallada posible las acciones a realizar ante un incidente. Pero, ¿para qué sirve? Puede parecernos que algunas cosas son demasiado obvias para ponerlas en un documento y que nosotros como buenos DBAs sabemos que hay que hacer en caso de incidente. Sin embargo, tenéis que pensar que en caso de crisis, con la presión que vamos a tener encima, lo mejor es tener todo documentado y seguir un guion. El futuro de nuestra empresa estará en esa intervención y tendremos que estar a la altura.
Los beneficios de tener un DRP previamente pensado y documentado son varios, entre ellos podemos destacar:

  1. Reduce el tiempo de inactividad al máximo lo que se traduce en un mejor servicio para nuestros clientes y proveedores.
  2. Minimiza las pérdidas por inactividad al conseguir un mejor tiempo de respuesta.
  3. Reduce el estrés de la toma de decisiones. En un momento crítico, es de vital importancia que todo el mundo sepa cómo actuar y no pierda los nervios.
  4. Asegura que todo el mundo podrá volver a acceder a su información. 
  5. Nos ayuda a cumplir con la legislación vigente en entornos regulados.

Los 4+1 pasos para el éxito de nuestro DRP

Genial, necesitamos un DRP pero, ¿por dónde empezamos?. No te asustes que no es tan difícil. En tan solo 5 pasos vas a poder tenerlo todo atado ya verás.

1 Definiciones

Todo DRP debe empezar definiendo las necesidades de alcance y los objetivos del propio plan. Podríamos definir tres apartados dentro de este paso, el primero es el alcance es decir, qué servicios queremos tener cubiertos por el plan de recuperación.
Una vez que hemos definido el alcance o perímetro de nuestro DRP el siguiente apartado sería saber de que nos queremos proteger, pregúntate: ¿Qué podría pasar? ¿un apagón? ¿Un incendio? ¿Un ataque de ransomware? ¿O tal vez una ardilla se coma los cables del servidor? (Sí, eso también pasa. ¿Verdad compañeros?). 

Por último, sabiendo que queremos proteger y de que lo siguiente sería definir lo que se conoce como BIA (Business Impact Analysis) o análisis de impacto de negocio. Aquí, tendremos que colaborar con otras áreas de la empresa para conocer el impacto de una crisis en su actividad y la de nuestros clientes.

2 Diseñar las estrategias de recuperación

Ahora que sabemos qué y de qué nos tenemos que proteger llega el momento del cómo. Diseñaremos una estrategia de recuperación para cada uno de los incidentes previamente descritos. Por ejemplo, esta es una lista de los escenarios más comunes y alternativas para su recuperación.

INCIDENTEEstrategia de RECUPERACIÓN
Borrado accidental de datosRestaurar copia de seguridad
Indisponibilidad de una base de datos
  1. Restaurar copia de seguridad
  2. Balanceo a otro nodo del cluster
Indisponibilidad de un servidor
  1. Balanceo a otro nodo del cluster.
  2. Reinstalación + restaurar copias.
Indisponibilidad de un centro de datos (CPD)
  1. Balanceo a otra ubicación geográfica.
  2. Reinstalación en otra ubicación y restaurar copias

3 Procedimentar las estrategias de recuperación

Como hemos dicho, no tenemos que dar nada por sentado y tenemos que detallar todos los pasos por lo que es el momento de explicar paso a paso como realizar todas y cada una de las acciones descritas en el paso anterior. Cuanto más detalle mejor, no olvidéis detallar la ubicación de las copias de seguridad o las direcciones IP y nombre de los servidores de respaldo, por ejemplo.

Podemos partir de la tabla anterior y añadir otra columna con los pasos, como en este ejemplo:

INCIDENTEEstrategia de RECUPERACIÓNProcedimiento de ACTUACIÓN
Borrado accidental de datosRestaurar copia de seguridad
  1. Identificar el problema.
  2. Avisar a todos los usuarios afectados.
  3. Intentar reparar el problema.
  4. Restaurar copia de seguridad de las bases de datos desde \\NuestroNAS\Copias\NuestroServer\NuestraBD
    4.1 Verificar que hay espacio disponible y solucionarlo en caso que sea necesario.
    4.2 Restaurar la base de datos.
  5. Probar que todo funciona.
  6. Avisar a los usuarios de que se ha resuelto la incidencia
  7. Monitorizar el correcto funcionamiento

4 Estimación de tiempos e impacto

Ya hemos visto todo lo que hay que hacer y como, es el momento de documentar cuánto tiempo vamos a tardar en cada uno de los escenarios y cual va a ser el impacto en los sistemas. Esto es lo que técnicamente se conoce como RPO y RTO que son las siglas en inglés de punto de recuperación objetivo y tiempo de recuperación objetivo.

El RPO hace referencia al máximo tiempo de pérdida de datos admisible, por ejemplo si tenemos una copia de seguridad diaria, en caso de fallo del servidor principal podremos tener hasta 24 horas de pérdida de datos.

El RTO es un poco más difícil de calcular, y seguramente tendremos que hacer pruebas para saberlo con exactitud, y hace referencia al tiempo que tardaremos en tener el servicio operativo nuevamente. Si en este punto hemos hecho todo bien, los RPO y RTO de las estrategias de recuperación estarán dentro de los márgenes admisibles que definimos en el paso número 2. 

5 Paso EXTRA: Revisión y pruebas

Aunque con los 4 pasos anteriores teóricamente habríamos completado nuestro DRP es importante que lo pongamos en práctica y que comprobemos que realmente funciona como habíamos pensado. Esto no hay que hacerlo solo una vez y olvidarnos, nuestras bases de datos son sistemas vivos que van cambiando día a día por lo que al menos una vez al año deberíamos hacer el ejercicio de probar el DRP y en caso de que sea necesario modificarlo para que se adapte a la situación actual de los sistemas. Este paso es el más importante y, en ocasiones, habrá entidades reguladoras que nos exijan evidencias de éxito de estos DRP Test.

Conclusión

Los DRP son imprescindibles para cualquier empresa que tenga sistemas en producción. Ya sea porque un regulador lo establece, porque estás tratando de adecuarte a la ISO 27001 o porque has pensado que este tipo de planes son importantes para ti, espero que este post te haya ayudado a resolver las dudas que tenías antes de empezar a leer. Si tienes alguna duda o comentario, no dudes en contactarnos en Twitter o por mail o dejarnos un mensaje en los comentarios de aquí abajo. Y recuerda que también tenemos un grupo de LinkedIn al que te puedes unir.

Publicado por Roberto Carrancio en Alta Disponibilidad, SQL Server, 1 comentario
31
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.

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

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
26
Ene
2024

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
22
Ene
2024
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
27
Dic
2023

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