Infra

20
Ene
2025

Optimización avanzada de Backups: BLOCKSIZE, MAXTRANSFERSIZE y BUFFERCOUNT

Cuando diseñamos nuestra estrategia de copias de seguridad en SQL Server, es esencial considerar no solo la integridad de los datos, sino también la eficiencia de los procesos. Quiero decir, además de la retención de los backups y factores como RPO y RTO que siempre tenemos en cuenta tenemos que pensar también en el rendimiento. En este sentido, ya hicimos un video sobre cómo afectaba la compresión de los backups a los tiempos de copia y restauración, ¿lo recuerdas? Lo tienes aquí por si quieres revisarlo.

Hoy, sin embargo, vamos a ir un paso más allá con esto del rendimiento de las copias de seguridad y vamos a ver tres opciones avanzadas que pueden marcar la diferencia en los tiempos y la utilización de recursos; estoy hablando de BLOCKSIZE, MAXTRANSFERSIZE y BUFFERCOUNT. Vamos a ver cómo funcionan y cómo optimizarlas.

Introducción al funcionamiento de las opciones de backups

Para entender estos complejos conceptos lo más simple posible tenemos que empezar pensando en el proceso de backup en SQL Server como en la transferencia de datos desde la base de datos hacia un destino de almacenamiento. Durante este flujo, como en cualquier transferencia de información informática, el tamaño del bloque, la cantidad de buffers y la cantidad de datos transferidos por operación son factores clave que pueden afectar considerablemente el rendimiento.

Entonces, tenemos por un lado el parámetro BLOCKSIZE que define el tamaño del bloque de datos utilizado en la operación de backup, MAXTRANSFERSIZE que determina el tamaño máximo de los datos que se transfieren en una única operación de I/O y BUFFERCOUNT que especifica cuántos buffers se asignan para la operación.

BLOCKSIZE

Como acabamos de comentar el parámetro BLOCKSIZE define el tamaño, en bytes, de los bloques que se utilizan para escribir datos en el medio de almacenamiento durante el backup. 

De manera predeterminada, y si no modificamos nada tendrá un tamaño de 64 KB. Sin embargo, podemos modificarlo, admitiendo valores que pueden oscilar entre 512 bytes y un máximo de 4 MB.

Un BLOCKSIZE mayor puede resultar en un uso más eficiente del disco, especialmente en sistemas con discos de alta velocidad y controladores optimizados.

Sin embargo, no todos los dispositivos admiten tamaños de bloque personalizados. Es vital verificar la compatibilidad con el hardware subyacente.

Ejemplo de uso:

BACKUP DATABASE MiBaseDatos 
TO DISK = 'C:\Backups\MiBaseDatos.bak'
WITH BLOCKSIZE = 65536; -- Tamaño del bloque especificado en bytes

MAXTRANSFERSIZE

Este parámetro controla la cantidad máxima de datos transferidos entre SQL Server y el medio de almacenamiento en una sola operación de I/O. Tiene un rango de valores posibles desde el mínimo 64 KB hasta un máximo de 4 MB (desde SQL Server 2012).

Un MAXTRANSFERSIZE mayor puede reducir la cantidad de operaciones de I/O, mejorando la velocidad del backup. Aumentar este valor puede ser beneficioso sobre todo en dispositivos con alto rendimiento de escritura secuencial como los actuales discos SSD. Pero cuidado, configurar valores altos puede requerir más memoria en el servidor, lo que podría ser contraproducente en sistemas con recursos limitados.

Ejemplo de uso:

BACKUP DATABASE MiBaseDatos 
TO DISK = 'C:\Backups\MiBaseDatos.bak'
WITH MAXTRANSFERSIZE = 1048576; -- 1 MB 

BUFFERCOUNT

Acabamos de hablar de la memoria y para optimizar este recurso y no tener problemas tenemos este último parámetro. BUFFERCOUNT define el número de buffers de memoria que se utilizarán durante la operación de backup. Es importante definirlo correctamente, sobre todo si hemos modificado los parámetros anteriores. 

Una mala configuración de BUFFERCOUNT nos puede dar muchos dolores de cabeza, por ejemplo valores bajos nos pueden provocar cuellos de botella si el flujo de datos excede la capacidad de los buffers disponibles y, sin embargo, unos valores altos aunque aprovechan al máximo la memoria disponible, deben equilibrarse con otros procesos en ejecución o usurparán sus recursos. Por suerte, tenemos una fórmula básica para calcular BUFFERCOUNT:

BUFFERCOUNT = (MAXTRANSFERSIZE / BLOCKSIZE) * número de hilos.

Ejemplo de uso:

BACKUP DATABASE MiBaseDatos 
TO DISK = 'C:\Backups\MiBaseDatos.bak'
WITH BUFFERCOUNT = 16;

Cómo optimizar tu backups

Ahora que ya hemos visto las tres configuraciones por sepradao vamos a ver como aplicarlas juntas. Esta es la clave ya que el rendimiento de los backups depende de cómo se ajustan estas tres opciones en conjunto. 

Lo primero que debemos hacer es analizar nuestro hardware.Si el sistema tiene discos rápidos y suficiente memoria, aumentar BLOCKSIZE y MAXTRANSFERSIZE puede sernos ventajoso. En sistemas con I/O limitado, priorizar un BUFFERCOUNT ajustado puede equilibrar la carga y ayudarnos a no impactar en otras operaciones.

En cualquier caso, es fundamental probar diferentes combinaciones en un entorno de prueba, lo más parecido al real posible, para determinar qué configuración ofrece el mejor rendimiento.

Lo cierto es que aunque SQL Server utiliza valores predeterminados razonables, ajustar estas opciones para nuestro escenario concreto puede ser crucial, sobre todo en bases de datos grandes o sistemas críticos.

Ejemplo completo:

BACKUP DATABASE MiBaseDatos 
TO DISK = 'C:\Backups\MiBaseDatos_Optimizado.bak'
WITH 
    BLOCKSIZE = 65536, -- 64 KB
    MAXTRANSFERSIZE = 1048576, -- 1 MB
    BUFFERCOUNT = 32;

En este ejemplo el BLOCKSIZE de 64 KB se combina con el MAXTRANSFERSIZE de 1 MB. 

El BLOCKSIZE de 64 KB es el adecuado si hacemos nuestros backups en un disco de los formateados según las buenas prácticas de SQL Server. Recordad que en estos discos definimos un tamaño de bloque de 64 KB que es justo lo que ocupa un EXTEND, es decir un bloque de 8 páginas cada una de 8 KB. El  MAXTRANSFERSIZE se ajusta a 1 MB para permitir que cada operación de I/O mueva datos en bloques razonablemente grandes, optimizando las escrituras en disco.

Ahora, si para estas operaciones de backup queremos aplicar 2 hilos, es decir dos núcleos virtuales del procesador, aplicamos la fórmula que hemos visto antes y nos da ese resultado.

32 = ( 1048576 /  65536 ) * 2

Conclusión

Las opciones BLOCKSIZE, MAXTRANSFERSIZE y BUFFERCOUNT nos ofrecen un control detallado sobre el rendimiento de las operaciones de backup en SQL Server. Aprovecharlas de manera efectiva requiere un análisis cuidadoso del entorno y pruebas específicas hasta dar con la mejor combinación. Pero merece la pena, en bases de datos críticas y de gran tamaño, estos ajustes pueden marcar una diferencia significativa, reduciendo los tiempos de los backups y optimizando el uso de recursos. 

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

Publicado por Roberto Carrancio en Rendimiento, SQL Server, 3 comentarios
10
Ene
2025

¿Por qué usar una red aislada para la comunicación de Always On (heartbeat network)?

La implementación de una arquitectura de alta disponibilidad en SQL Server Always On es un elemento clave para garantizar la continuidad del negocio y la disponibilidad de los datos. Mucho hemos hablado ya de este tema en el blog pero, si queremos ir un paso más allá, uno de los aspectos fundamentales en esta configuración es la red de comunicación entre los nodos de un grupo de disponibilidad o una instancia de clúster de conmutación por error. En este contexto, el uso de una red aislada para la comunicación de Always On, conocida como heartbeat network, juega un papel esencial en la estabilidad y rendimiento de la solución.

En este artículo, veremos por qué es recomendable utilizar una red dedicada para la comunicación de Always On, sus beneficios, y las mejores prácticas para su implementación.

Importancia de la comunicación en Always On

Always On en SQL Server nos permite la creación de entornos de alta disponibilidad y recuperación ante desastres mediante grupos de disponibilidad o clústeres de conmutación por error. Cuando lo configuramos, los nodos intercambian información de estado para determinar si uno de los servidores está en funcionamiento o si ha fallado y es necesario realizar una conmutación por error (failover).

Este intercambio de información se realiza a través de un mecanismo denominado heartbeat, que envía señales de estado periódicas entre los nodos del clúster. Si un nodo deja de responder en un tiempo determinado, el sistema automáticamente asume que ha fallado y puede desencadenar una conmutación automática al nodo secundario si así lo hemos configurado.

Además de la señal de heartbeat, en un Grupo de Disponibilidad Always On, esta misma red puede utilizarse para la sincronización de datos entre réplicas. Esto es especialmente crítico en entornos con replicación síncrona, donde la latencia y la estabilidad de la red influyen directamente en el rendimiento del sistema.

¿Por qué usar una red aislada para el heartbeat en Always On?

Como acabamos de ver, el tráfico de comunicación de Always On es crítico para mantener la estabilidad del clúster. Sin una red dedicada, esta comunicación puede verse afectada por la congestión de la red principal, lo que podría provocar falsos positivos en la detección de fallos y generar conmutaciones innecesarias. Además el rendimiento de SQL podría verse afectado sobre todo en replicaciones síncronas donde todos los nodos tienen que confirmar la escritura del dato antes de aplicarse. A continuación, analizamos las razones principales por las que una red aislada es recomendada.

1. Optimización del rendimiento en la replicación de datos

En configuraciones de Grupos de Disponibilidad Always On, los datos pueden replicarse de forma síncrona o asíncrona entre los nodos.En la replicación asíncrona, el rendimiento no se ve tan afectado por la latencia de la red, ya que el nodo primario no espera confirmación antes de continuar procesando transacciones. Sin embargo, en la replicación síncrona, cada transacción debe confirmarse en todas las réplicas antes de considerarse completada. Si la red es lenta o está congestionada, la latencia de confirmación aumentará, ralentizando drásticamente el rendimiento de las aplicaciones que dependen de la base de datos.

Utilizar una red dedicada para la sincronización de Always On reduce la latencia y garantiza tiempos de respuesta óptimos, evitando que la red de producción interfiera en la replicación de datos.

2. Evita congestión en la red de producción

Si la red de Always On comparte infraestructura con la red utilizada por los clientes y aplicaciones, el tráfico de consultas, backups y cargas de datos puede afectar negativamente la comunicación entre los nodos. Una red separada para heartbeat y sincronización de datos garantiza que las señales críticas del clúster no se pierdan ni se retrasen debido a otras cargas de trabajo.

3. Reduce los falsos positivos en la detección de fallos

Si los paquetes de heartbeat se retrasan o se pierden por congestión en la red, el clúster podría interpretar que un nodo ha fallado y desencadenar una conmutación innecesaria. Esto no solo interrumpe el servicio, sino que también puede generar pérdida de rendimiento o afectar transacciones en curso. Con una red dedicada, el tráfico de heartbeat permanece estable, minimizando estos riesgos.

4. Mayor estabilidad en entornos de “misión crítica”

En sectores críticos como finanzas, salud o comercio electrónico, donde SQL Server gestiona transacciones en tiempo real, cualquier interrupción puede tener un impacto severo. Una red dedicada para la sincronización y el heartbeat de Always On ayuda a mantener la estabilidad operativa, asegurando que la replicación de datos no se vea afectada por otros procesos.

5. Mejor eficiencia en la recuperación ante desastres

En escenarios donde Always On se extiende a un sitio de recuperación ante desastres (DR), la replicación de datos entre ubicaciones puede beneficiarse de una red dedicada para evitar problemas de latencia y pérdida de paquetes. Al separar el tráfico de sincronización, se mejora la eficiencia de la conmutación a los servidores de respaldo, reduciendo el tiempo de recuperación en caso de fallos.

6. Mayor seguridad en la comunicación entre nodos

Al utilizar una red aislada, los paquetes de comunicación de Always On quedan protegidos de posibles ataques de red o interferencias de otras aplicaciones. Esto es especialmente importante en entornos donde se manejan datos sensibles o regulados. 

Buenas prácticas para implementar una red de heartbeat en Always On

Para aprovechar al máximo los beneficios de una red dedicada en Always On, es recomendable seguir algunas buenas prácticas:

Utilizar interfaces de red dedicadas para la red heartbeat 

Cada nodo del clúster debe contar con al menos dos interfaces de red, una para la red de producción y otra exclusivamente para la comunicación de Always On (heartbeat + sincronización de datos). Esto permite segmentar el tráfico y garantizar que los paquetes críticos siempre tengan prioridad.

Configurar métricas de latencia adecuadas

Ajustar los valores de timeout y umbrales de latencia en el clúster es clave para evitar falsos positivos en la detección de fallos. Dependiendo de la infraestructura, puede ser necesario aumentar los valores predeterminados para optimizar la replicación.

Implementar calidad de servicio (QoS)

Si la red dedicada no es una opción viable, se pueden aplicar reglas de Quality of Service (QoS) para priorizar el tráfico de Always On sobre otros tipos de tráfico en la red de producción.

Monitorizar constantemente la red heartbeat de Always On

La monitorización activa de la red de comunicación y replicación de Always On es crucial para detectar anomalías antes de que afecten la estabilidad del clúster. Herramientas como SQL Server Management Studio (SSMS) y System Center Operations Manager (SCOM) pueden ayudar en esta tarea.

Usar VLANs y segmentación de red para heartbeat 

Si no es posible contar con una red física dedicada, una alternativa viable es configurar una VLAN (Virtual LAN) para separar lógicamente el tráfico de Always On del resto del tráfico de la red.

Configurar múltiples rutas de comunicación

Para entornos de alta disponibilidad extrema, es recomendable configurar múltiples rutas de comunicación entre los nodos utilizando distintas interfaces de red y switches redundantes. Esto permite continuar la comunicación en caso de fallos en una de las rutas.

Conclusión

El uso de una red aislada para la comunicación de Always On no solo garantiza una mayor estabilidad en la detección de fallos, sino que también optimiza el rendimiento en la replicación de datos, especialmente en configuraciones síncronas. Al reducir la latencia y evitar interferencias con el tráfico de producción, se mejora significativamente la eficiencia del clúster y se minimiza el riesgo de interrupciones.

Para cualquier organización que dependa de SQL Server Always On, implementar una red dedicada para heartbeat y sincronización es una estrategia clave para mantener un rendimiento óptimo y asegurar la continuidad del servicio en entornos críticos.

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

Publicado por Roberto Carrancio en Alta Disponibilidad, Rendimiento, SQL Server, 0 comentarios
20
Dic
2024

Always On y el mito de la perdida de datos cero

Cuando hablamos de Alta Disponibilidad en SQL Server, los Grupos de Disponibilidad Always On suelen ser la opción que se menciona con mayor frecuencia. No es para menos, realmente son la solución de alta disponibilidad más completa que ofrece SQL Server. Sin embargo, existe una idea errónea generalizada: que el modo sincrónico de AlwaysOn garantiza la pérdida cero de datos. A primera vista, esta suposición puede parecer razonable, pero en este artículo explicaré por qué no es necesariamente cierto y analizaremos las implicaciones técnicas detrás de esta afirmación.

El mito de la pérdida cero de datos en Always On

El modo sincrónico en los Grupos de Disponibilidad AlwaysOn está diseñado para garantizar que los datos se escriban en todas las réplicas sincrónicas antes de confirmar una transacción. Esto implica que las transacciones no se considerarán completadas hasta que los datos se escriban tanto en la réplica principal como en las secundarias configuradas en modo sincrónico. A simple vista, parece que este comportamiento elimina cualquier posibilidad de pérdida de datos, pero hay ciertos escenarios en los que esto no es así.

Cómo funciona el Always On en modo síncrono

En el modo síncrono, el proceso sigue estos pasos:

  1. El nodo primario recibe una transacción.
  2. Los datos de la transacción se envían a todas las réplicas secundarias configuradas en modo sincrónico.
  3. Las réplicas secundarias confirman que los datos han sido escritos en su registro de transacciones (log).
  4. Solo después de recibir las confirmaciones de todas las réplicas, el nodo primario completa la transacción. Realmente esto se puede ajustar para que no sea necesario esperar a todas las replicas secundarias con la opción REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT.

Aunque este flujo parece muy robusto, hay ciertas limitaciones y condiciones que pueden comprometer la integridad de los datos.

Excepciones

Todo esto suena muy bonito, precioso diría yo. Y así funciona realmente, excepto cuando algo no va bien. Si la réplica secundaria deja de estar disponible, llámalo reinicio, parcheo o cualquiera de los múltiples otros motivos que puedan surgir dejamos de tener alta disponibilidad. Realmente está contemplado, mirad. Si leemos la documentación nos encontramos con algo que ya no suena tan bien:

«Si la réplica principal y una réplica secundaria determinada se configuran ambas para el modo de confirmación sincrónica, la réplica principal espera a que la réplica secundaria confirme que ha reforzado el registro (a menos que la réplica secundaria no pueda hacer ping a la réplica principal en el período de tiempo de espera de sesión de la principal).
Si el período de tiempo de espera de sesión de la réplica principal es superado por una réplica secundaria, la replicación principal pasa temporalmente al modo de confirmación asincrónica para esa replicación secundaria. Cuando la replicación secundaria vuelva a conectarse con la replicación primaria, se reanuda el modo de confirmación sincrónica.«

En resumidas cuentas, y tiene hasta sentido, si la réplica secundaria no está disponible, por el motivo que sea, las transacciones no se detendrán y seguiremos trabajando con normalidad sobre la réplica principal sin notar nada pero no tendremos alta disponibilidad. Cuando la réplica secundaria nuevamente esté disponible empezará a replicar todas las transacciones pendientes y, un failover, antes de que termine, tendrá pérdida de datos.

Casos prácticos donde puede ocurrir pérdida de datos con Always On

Hemos nombrado ya alguno de los escenarios en los que podríamos tener una pérdida de datos con Always On, pero hay más, estos son los más comunes. 

  • Latencia de red alta: Si la red entre las réplicas tiene una latencia significativa, puede aumentar la probabilidad de inconsistencias. En casos extremos, una réplica secundaria podría quedar rezagada y, como dice la documentación, pasar a modo asíncrono hasta que se recupere la normalidad.
  • Fallos simultáneos en nodos múltiples: En un entorno de clúster, si tanto el nodo primario como las réplicas sincrónicas fallan al mismo tiempo (por ejemplo, por un corte de energía en el data center), se pueden perder datos que no hayan sido escritos en disco.
  • Problemas en el subsistema de almacenamiento: Si el almacenamiento subyacente es compartido para todos los nodos y experimenta corrupción o retrasos significativos, incluso las transacciones confirmadas podrían estar en riesgo.

Prácticas recomendadas en Always On para mitigar riesgos

Si bien sabemos que no es teóricamente imposible la pérdida de datos, también existen una serie de medidas que, como DBAs, podemos tomar para reducir el riesgo. La primera y más eficaz es configurar múltiples réplicas síncronas. Tener más de una réplica puede reducir las probabilidades de pérdida de datos, ya que sería improbable que todas las réplicas fallen simultáneamente. Recuerda que Always On admite un total de 8 réplicas secundarias.

Las siguientes medidas, aunque imprescindibles, no van a tener un impacto tan directo en la reducción del riesgo, simplemente nos permitirán localizar el problema y tomar medidas antes de que sea tarde. Como habrás adivinado ya, estoy hablando de monitorizar la latencia de replicación: Es crucial monitorizar continuamente la latencia entre el nodo primario y las réplicas y tener un buen sistema de alerta para detectar problemas potenciales. También deberemos realizar pruebas regulares de failover: Realizar pruebas regulares ayuda a garantizar que los nodos secundarios estén configurados correctamente y puedan asumir el rol de primario sin perder datos.

Por último, pero no menos importante deberemos tener una solución de respaldo complementaria. Aunque los Grupos de Disponibilidad AlwaysOn son poderosos, una estrategia de copias de seguridad sólida sigue siendo indispensable. No solo para afrontar fallos de la infraestructura, también porque un borrado o actualización incorrecta se replicará inmediatamente por todas las réplicas y las copias de seguridad serán lo único que nos salve.

Conclusión

Los Grupos de Disponibilidad Always On son una solución robusta para alta disponibilidad y recuperación ante desastres. Sin embargo, como hemos visto, el modo sincrónico no es una garantía absoluta de pérdida cero de datos. Comprender estas limitaciones y diseñar una arquitectura con redundancias adicionales es fundamental para minimizar riesgos y garantizar la integridad de los datos. Siempre debemos complementar nuestras configuraciones con monitorización proactiva, pruebas de failover y estrategias de respaldo adecuadas.

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

 

Publicado por Roberto Carrancio en Alta Disponibilidad, SQL Server, 0 comentarios
18
Dic
2024

Always On Availability Groups sin WSFC

Always On Availability Groups (AG) es una funcionalidad avanzada de SQL Server que proporciona alta disponibilidad, recuperación ante desastres y replicación. Tradicionalmente, esta tecnología se implementa utilizando Windows Server Failover Cluster (WSFC). Sin embargo, existe una alternativa que elimina la dependencia de WSFC, simplificando la infraestructura en ciertos entornos y adaptándose mejor a escenarios específicos. En este artículo, y a raíz de una petición vuestra en un comentario a uno de mis videos en youtube, os explicaré cómo configurar AG en Windows sin cluster, sus características, limitaciones y casos de uso, además de los scripts necesarios para su administración.

Introducción a Always On sin WSFC

La configuración de Always On sin WSFC, también conocida como grupos de Disponibilidad de Escala de Lectura (Read-Scale Availability Groups, RSAG), es ideal en entornos donde no es posible o necesario implementar un cluster. Esta arquitectura, disponible desde SQL Server 2017, permite que las réplicas de SQL Server funcionen de manera independiente, conectándose directamente entre sí para mantener la sincronización de los datos. A diferencia de la configuración tradicional, no existe una gestión centralizada del Quórum ni un mecanismo de failover automático. En su lugar, los DBA asumimos un papel activo en la supervisión, configuración y administración de los failovers, listeners y otros elementos. Aunque este modelo elimina parte de la complejidad asociada a los clusters, también requiere conocimientos avanzados para garantizar un funcionamiento eficiente y seguro.

Características de Always On sin WSFC

La autonomía de las réplicas es una de las principales características de esta configuración. Cada instancia de SQL Server opera de forma independiente y no depende de un cluster subyacente para coordinar sus roles. El failover, por otro lado, debe realizarse manualmente o mediante scripts personalizados, lo que otorga flexibilidad pero requiere una monitorización constante. Los listeners, que en un entorno con WSFC se configuran automáticamente, aquí deben implementarse manualmente utilizando soluciones externas como balanceadores de carga o DNS, lo que puede agregar complejidad operativa.

En términos de sincronización, esta configuración solo admite el modo asíncrono, lo que prioriza el rendimiento pero, sumado a la falta de balanceo automático, descarta su uso como solución de alta disponibilidad para todos los escenarios. Además, aunque al eliminar la necesidad de WSFC, la infraestructura se simplifica, reduciendo los costes asociados sigue siendo necesario licenciar ambas instancias con una edición Enterprise lo que eleva los costes.

Ventajas y Limitaciones

La eliminación del cluster de Windows en esta configuración aporta beneficios significativos, como la reducción de costes al no requerir licencias adicionales ni configuraciones complejas asociadas a WSFC. Esto hace que sea una solución atractiva para entornos de pruebas y desarrollo. Además, la autonomía de las réplicas facilita la implementación en sistemas más simples, evitando la necesidad de depender de un cluster para mantener la alta disponibilidad.

Sin embargo, esta configuración también tiene limitaciones importantes. La ausencia de un mecanismo de quorum aumenta el riesgo de situaciones de split-brain (ocurre cuando uno o más nodos de un clúster experimentan la desconexión de los otros nodos, lo que resulta en la formación de subclústeres), especialmente en escenarios donde no se monitoriza adecuadamente el estado de las réplicas. Por otro lado, la falta de un listener nativo complica la integración con aplicaciones que dependen de un punto de acceso único para conectarse al nodo activo. La escalabilidad también es más limitada en comparación con un entorno gestionado por WSFC, lo que la hace menos adecuada para infraestructuras complejas o con muchos nodos.

Casos de Uso

Always On sin cluster en Windows es una solución especialmente útil en entornos de pruebas y desarrollo, donde la alta disponibilidad no es crítica pero la replicación de datos es necesaria para realizar simulaciones y validaciones. También es una opción adecuada para aquellos escenarios que no requieren failover automático, pero necesitan una forma de mantener datos sincronizados entre varias instancias para dividir las cargas de trabajo, por ejemplo replicas de solo lectura para análisis en tiempo real.

En sistemas autónomos, donde las réplicas pueden operar independientemente, esta arquitectura también encuentra un buen uso. Asimismo, es una alternativa viable cuando se dispone de soluciones externas avanzadas, como balanceadores de carga o gestión de DNS, que pueden mitigar las limitaciones asociadas a la falta de listeners nativos.

Configuración de Always On sin WSFC

La configuración comienza habilitando Always On en cada instancia de SQL Server desde el Configuration Manager, asegurándose de que las bases de datos estén en modo de recuperación completa. Los endpoints deben configurarse manualmente en cada réplica para permitir la comunicación entre ellas. Una vez configurados los endpoints, se procede a crear el grupo de disponibilidad desde la réplica primaria utilizando T-SQL, definiendo las bases de datos y réplicas participantes, junto con sus modos de sincronización.

En las réplicas secundarias, las bases de datos deben restaurarse en modo de recuperación incompleta (NORECOVERY) antes de añadirlas al grupo de disponibilidad. Finalmente, los listeners deben configurarse manualmente si es necesario, ya sea mediante un DNS dedicado o un balanceador de carga externo, lo que permite redirigir el tráfico al nodo activo.

Gestión y Scripts de Administración

La administración de Always On sin WSFC depende en gran medida de scripts personalizados ya que no dispondremos del dashboard de Always On. Por ejemplo, el estado de sincronización de las réplicas puede verificarse con consultas a las vistas dinámicas sys.dm_hadr_database_replica_states. Además, algunas columnas de esta DMV relacionadas con el clúster pueden mostrar datos sobre un clúster predeterminado interno. Estas columnas son solo para uso interno y se pueden ignorar.

El failover manual, que es una tarea común en esta configuración, se realiza utilizando el comando ALTER AVAILABILITY GROUP … FAILOVER. Además, tras un failover, es necesario reanudar las bases de datos en la nueva réplica primaria con el comando ALTER DATABASE … SET HADR RESUME.

Conclusión

Always On Availability Groups sin cluster en Windows es una alternativa poderosa para entornos específicos, especialmente aquellos donde los costes o la complejidad de WSFC no son aceptables. Aunque su implementación y administración requieren habilidades avanzadas y mayor supervisión, esta configuración ofrece flexibilidad y simplicidad en infraestructura, siendo especialmente adecuada para entornos de pruebas, desarrollo y réplicas de solo lectura. Sin embargo, su uso en producción debe evaluarse cuidadosamente, teniendo en cuenta sus limitaciones en términos de Quórum, failover automático y escalabilidad.

Con una correcta planificación y monitorización, esta arquitectura puede proporcionar una solución eficaz para mantener datos sincronizados en escenarios específicos. Si se implementa correctamente, Always On sin cluster puede ser un recurso invaluable para arquitecturas modernas y simplificadas.

Te invito a seguirnos en el canal de YouTube donde pronto trataré de mostrar la configuración paso a paso de este tipo de Always On.

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

Publicado por Roberto Carrancio en Alta Disponibilidad, SQL Server, 0 comentarios
13
Dic
2024

¿Qué alternativa tengo a SSMS?

Existen múltiples alternativas a SQL Server Management Studio (SSMS) que pueden ajustarse mejor a distintas necesidades y presupuestos. Estas opciones incluyen herramientas tanto de Microsoft como de terceros, así como opciones gratuitas y de pago. La elección de una alternativa adecuada a SSMS dependerá en gran medida del contexto de uso, las funcionalidades requeridas y la infraestructura de cada organización. Hoy quiero repasar con vosotros algunas de las principales opciones que vais a poder utilizar y para que casos de uso son más recomendadas.

Azure Data Studio: Una Alternativa Moderna de Microsoft

Una de las alternativas más destacadas la vamos a encontrar en el catálogo de Microsoft y no es otra que Azure Data Studio. De Azure Data Studio ya hemos hablado en alguna ocasión y es una herramienta moderna diseñada para entornos de nube y escenarios híbridos. Azure Data Studio se caracteriza por ser multiplataforma, permitiendo su uso en sistemas operativos Windows, macOS y Linux. Esto lo convierte en una opción versátil, especialmente para desarrolladores y administradores de bases de datos que requieren una interfaz ligera y flexible. Su sistema de extensiones permite personalizar el entorno y añadir funcionalidades específicas, como soporte para Power BI o notebooks interactivos que facilitan la visualización de datos. 

Sin embargo, aunque Azure Data Studio admite complementos y se actualiza regularmente, algunas funcionalidades avanzadas de administración de SQL Server todavía no están presentes, lo que limita su uso para tareas puramente administrativas en comparación con SSMS. Además, su enfoque está orientado más hacia el desarrollo que hacia la administración, lo que puede resultar insuficiente para ciertos administradores de bases de datos que necesitan un control total sobre sus instancias.

Aqua Data Studio: Versatilidad y soporte multi base de datos para desarrolladores

Otra opción a considerar es Aqua Data Studio, una herramienta que destaca por su compatibilidad con múltiples sistemas de gestión de bases de datos (SGBD), entre ellos SQL Server, Oracle, MySQL y PostgreSQL. Aqua Data Studio permite a los usuarios administrar, modelar y desarrollar sobre diversas bases de datos en una sola interfaz, lo que la convierte en una opción ideal para entornos con múltiples bases de datos. La herramienta también ofrece funcionalidades avanzadas de visualización de datos, que son útiles para el análisis y la toma de decisiones basadas en datos como por ejemplo poder filtrar y ordenar los resultados de una consulta como si de una tabla de excel se tratase. Para esto, hace uso de los datos ya cargados en local y no vuelve a ejecutar la consulta.

Otras de sus ventajas son la interfaz intuitiva, su soporte para diagramas ER y sus herramientas de depuración de SQL, que facilitan la optimización de consultas. No obstante, Aqua Data Studio es una herramienta de pago, y su coste puede ser elevado para algunos usuarios, especialmente aquellos que solo necesitan una solución específica para SQL Server.

DbForge Studio for SQL Server: Una alternativa para desarrollo y optimización

Siguiendo con las herramientas de terceros, DbForge Studio for SQL Server de Devart es una alternativa robusta, conocida por su enfoque en el desarrollo y optimización de bases de datos. Esta herramienta incluye un editor de SQL avanzado con funcionalidades de autocompletado, refactorización de código y análisis de dependencias, lo cual facilita el trabajo de desarrollo. 

Además, ofrece capacidades de perfilado de bases de datos, lo que permite identificar y resolver cuellos de botella en el rendimiento de consultas SQL, y funcionalidades para la comparación y sincronización de bases de datos. Estas características la convierten en una opción poderosa para entornos donde se requiere un control avanzado y optimización. Sin embargo, su precio puede ser una barrera, especialmente en organizaciones con presupuesto limitado, y está disponible únicamente en Windows, lo que limita su uso en entornos que requieren multiplataforma.

DBeaver: Una Alternativa Multiplataforma para Entornos Híbridos

Otra herramienta relevante es DBeaver, una aplicación de código abierto y multiplataforma compatible con diversos SGBD, incluyendo SQL Server. DBeaver es popular en entornos híbridos por su flexibilidad, y su sistema de plugins permite añadir funcionalidades específicas. La versión gratuita de DBeaver incluye funcionalidades básicas, mientras que la edición Enterprise (de pago) añade opciones avanzadas, como la administración de bases de datos y el soporte para control de versiones. 

Sin embargo, su interfaz, aunque flexible, puede resultar sobrecargada para quienes buscan un entorno exclusivamente enfocado en SQL Server. Además, al ser una herramienta genérica, carece de integración nativa con algunas soluciones de Microsoft, lo que puede limitar su uso en infraestructuras completamente basadas en el ecosistema de Microsoft.

Toad for SQL Server: Optimización y automatización para DBAs

Toad for SQL Server de Quest Software también es una alternativa sólida, especialmente valorada por sus capacidades de optimización y monitorización. Esta herramientas permite a los administradores de bases de datos automatizar tareas de mantenimiento y administración, así como optimizar consultas SQL con sugerencias basadas en análisis de rendimiento en tiempo real. 

Su soporte para control de versiones lo convierte en una excelente herramienta para el trabajo en equipo, permitiendo a los desarrolladores y administradores sincronizar cambios y trabajar colaborativamente en proyectos de base de datos. No obstante, el alto coste de Toad y la complejidad de su interfaz pueden ser barreras para usuarios con menos experiencia o para organizaciones pequeñas con recursos limitados.

SQuirreL SQL: Una alternativa gratuita y multi base de datos

Ya vamos acercándonos al final de este artículo con SQuirreL SQL, una opción de código abierto que, aunque no está especializada en SQL Server, ofrece una solución gratuita y multiplataforma para trabajar con múltiples SGBD. Si necesitamos compatibilidad con diversos motores de base de datos en un solo entorno SQuirreL SQL es la herramienta adecuada. Sin embargo, esta herramienta carece de funcionalidades avanzadas para administración y monitoreo de rendimiento en SQL Server, y su interfaz es menos moderna, lo que puede ser una desventaja para usuarios acostumbrados a herramientas más actuales.

HeidiSQL: Una alternativa portable

HeidiSQL es conocido principalmente por su compatibilidad con bases de datos MySQL y MariaDB, pero también soporta conexiones a SQL Server y PostgreSQL, ampliando su utilidad en entornos multi-SGBD. Es una herramienta liviana, con un diseño intuitivo y que permite gestionar bases de datos sin ocupar mucho espacio ni recursos del sistema. Su naturaleza portable es ideal para administradores y desarrolladores que necesitan acceder a SQL Server ocasionalmente o en situaciones donde no es posible instalar software de forma permanente.

Una de las principales ventajas de HeidiSQL es su facilidad de uso y su enfoque en la administración básica y el desarrollo de SQL. Además, permite realizar tareas como editar y ejecutar consultas SQL, exportar e importar datos, y administrar tablas y vistas. Estas funcionalidades pueden ser suficientes para tareas de mantenimiento diario y desarrollo básico en SQL Server, sin la necesidad de instalar software más pesado como SSMS.

Sin embargo, es importante destacar que HeidiSQL no proporciona las herramientas avanzadas de administración y optimización que se encuentran en SSMS o en alternativas como Toad for SQL Server o DbForge Studio. Esto limita su uso a entornos en los que se requieren operaciones sencillas. Asimismo, su interfaz y opciones están más orientadas a usuarios de MySQL y MariaDB, por lo que algunos aspectos pueden resultar limitados en el entorno de SQL Server.

Conclusión

En conclusión, la alternativa más adecuada a SSMS dependerá de las necesidades específicas de cada equipo o proyecto. Herramientas como Azure Data Studio y Aqua Data Studio ofrecen opciones multiplataforma y flexibles que se integran bien en entornos modernos y de nube, mientras que DbForge Studio y Toad for SQL Server proporcionan funcionalidades avanzadas de optimización y administración, a un coste. DBeaver, SQuirreL SQL y HeidiSQL son opciones gratuitas (con opción de pago) adecuadas para entornos multi-SGBD, aunque con ciertas limitaciones en el ámbito de SQL Server. La elección final debe considerar factores como la funcionalidad necesaria, el presupuesto y el ecosistema tecnológico en el que se desarrollarán las actividades de administración y desarrollo.

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

Publicado por Roberto Carrancio en SQL Server, 0 comentarios
27
Nov
2024

Replicar datos de SQL a Fabric

Mucho hemos hablado en el blog de como pasar datos de SQL Server en local a la nube, o de la nube a local. Sin embargo, siempre nos hemos centrado en el ecosistema de SQL Server y Azure SQL que, con pequeñas diferencias, cubren las mismas necesidades. Pero, ¿qué pasa si lo que necesitamos es pasar nuestros datos de SQL recurrentemente a un servicio SaaS en la nube para ciencia y análisis de datos?. Eso es lo que vamos a ver hoy, cómo pasar nuestros datos de SQL Server a Fabric ya sea a un Lakehouse o a un Datawarehouse.

Fabric lakehouse vs Datawarehouse ¿qué son?

Al hablar de Fabric, uno de los primeros pasos cruciales es entender sus componentes principales para el almacenamiento de los datos, el Lakehouse y el DataWarehouse. Aunque realmente todo lo que almacenemos en Lakehouse o en Datawarehouse va a estar almacenado en el mismo sitio, nuestro Onelake, por encima de esa capa pura de almacenamiento tendremos que decidirnos por una de las dos estrategias anteriores de gestión de los datos. Puede parecer trivial, incluso en muchas ocasiones se confunden o se utilizan indistintamente pero, la realidad es que cada uno tiene características y funciones específicas dentro de un entorno de ciencia de datos y análisis en la nube. Estas particularidades van a ser claves a la hora de trabajar con ellos por lo que es importante que tengamos claro cuál va a ser nuestro destino antes de plantear el método de envío de datos.

Fabric Datawarehouse

Fabric Datawarehouse es una solución de almacenamiento de datos que integra las capacidades de un data warehouse tradicional con la flexibilidad de un data lake. Gracias a esta arquitectura podremos almacenar, procesar y analizar grandes volúmenes de datos estructurados y semiestructurados en un entorno unificado, lo que nos facilitará la gestión y el análisis de la información.

Una característica distintiva de Fabric Datawarehouse es su almacenamiento centrado en el lago de datos (One Lake), basado en el formato abierto Delta Lake. Este enfoque nos permite hacer uso de transacciones ACID y una interoperabilidad fluida con otras cargas de trabajo de Fabric, eliminando la necesidad de múltiples copias de datos y garantizando la consistencia y confiabilidad de la información. Además su punto de conexión SQL nos va a permitir consultar y manipular datos con código T-SQL 

Fabric Lakehouse

Fabric Lakehouse es una arquitectura de datos integrada en Microsoft Fabric que combina las funcionalidades de un data lake con las capacidades de un data warehouse. Esta estructura nos permite almacenar, procesar y analizar grandes volúmenes de datos no estructurados, semiestructurados y estructurados en un solo entorno, simplificandonos la gestión y el análisis de los datos.

El concepto de lakehouse en Fabric fusiona la escalabilidad y flexibilidad de un datalake, donde se puede almacenar información en su formato nativo, con el rendimiento y las capacidades analíticas de un data warehouse, facilitando la ejecución de consultas SQL de lectura directamente sobre los datos sin necesidad de moverlos. Fabric Lakehouse soporta el uso de diversos lenguajes de consulta y herramientas de análisis, como SQL, Spark y Power BI, proporcionando un entorno colaborativo y unificado.

Además, Fabric Lakehouse utiliza Delta Lake, que añade un nivel de transaccionalidad y consistencia a los datos almacenados, algo crucial en entornos de análisis donde la integridad de los datos es prioritaria. Delta Lake permite realizar lecturas y escrituras simultáneas y asegura la disponibilidad de datos limpios y consistentes para el análisis.

Enviar datos de SQL a Fabric

Bien, ahora que ya hemos decidido cual de los sistemas tenemos en destino vamos a ver las posibilidades de sincronización que tenemos para los datos de SQL. Vamos a centrarnos principalmente en dos herramientas, los Dataflows gen 2 y los pipelines.

Dataflows Gen2

Los Dataflows Gen2 son una opción no-code que nos permite llevar a Fabric datos de casi cualquier origen. Son una evolución de los Dataflows de Power BI, con un aspecto similar pero, con una gran diferencia, permiten seleccionar el destino. Gracias a esta funcionalidad vamos a poder usarlos para llevar nuestros datos de SQL o Azure SQL a Fabric, ya usemos Lakehouse o Datawarehouse, sin problema.

Para crearlo, simplemente accederemos a la interfaz de Dataflows Gen2 dentro del menú de Data Factory y, a través de la interfaz gráfica seleccionaremos nuestro origen, ya sea Azure SQL o una puerta de enlace previamente configurada con la conexión a SQL Server. A partir de aquí, podremos seleccionar las tablas o vistas que replicar y aplicar transformaciones, siempre cuidando de no romper el plegado de consultas o lo notaremos en el rendimiento.

Pipelines

Los pipelines son otra alternativa sencilla y no-code para la copia de datos, aunque tienen un inconveniente. Si bien es teóricamente posible usarlo para transferir nuestros datos desde SQL Server hacia Fabrik Lakehouse o Datawarehouse, lo cierto es que hacia este último destino va a requerir de una serie de pasos adicionales que complican el proceso hasta hacer que no sea recomendable, al menos en mi opinión. 

Entonces, si vas a trabajar con Fabric Lakehouse la cosa es simple, abres Pipelines desde la misma ventana de Data Factory que hemos comentado antes y practicamente sigues el asistente. Te va a pedir el origen (tu Azure SQL o tu puerta de enlace con la conexión a SQL Server, igual que antes), la tabla o consulta que se va a replicar y el destino con su tipo de datos para cada columna.

Bonus track: Fabric Mirroring, Shortcuts y Notebooks

Los que conocéis el ecosistema de Fabric sabéis que además de Dataflows Gen2 y Pipelines tenemos disponibles otras herramientas como son los mirroring shortcuts y Notebooks. Veamos qué podemos hacer con ellas.

  • Shorcuts: Igual que los accesos directos a los que estamos acostumbrados en nuestros sistemas operativos de Windows, los shortcuts en Fabric nos permiten leer información de otras fuentes sin tener que copiarlas a nuestro One Lake. Suena bien, ¿verdad? Pues es muy bonito pero, lamentablemente no están implementados ni para SQL Server ni para ninguna solución de SQL en la nube.
  • Notebooks: Los cuadernos (notebooks) son la principal herramienta de integración y manipulación de datos en Fabric. Sin embargo, no son compatibles con orígenes de una puerta de enlace por lo que solo podremos usarlos para copiar datos desde orígenes Azure SQL ya sean Managed Instance o bases de datos sin servidor.
  • Mirroring: He dejado lo mejor para el final. Mirroring es una nueva funcionalidad que promete replicar nuestras bases de datos SQL a Fabric. Sin embargo, aún está en Public Preview y solo para orígenes Azure SQL Database (bbdd sin servidor). Esperemos en un futuro cercano verlo en GA para todos los orígenes SQL Server.

Conclusión

Migrar datos de SQL Server a Microsoft Fabric abre un mundo de posibilidades para el análisis avanzado en la nube. Con herramientas como Dataflows Gen2 y Pipelines, podemos transferir datos de manera eficiente y sin código hacia entornos unificados de Fabric, eligiendo entre el Lakehouse, ideal para datos en formatos variados, y el Data Warehouse, optimizado para consultas estructuradas. Fabric facilita la gestión y transformación de datos en un entorno SaaS seguro, apoyado en OneLake y Delta Lake, que garantizan consistencia y escalabilidad. Así, centralizamos el análisis y optimizamos el rendimiento, aprovechando todo el potencial de nuestros datos en la nube.

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

Publicado por Roberto Carrancio en Cloud, Power BI, SQL Server, 0 comentarios
25
Nov
2024

Puertas de Enlace Power BI y Fabric

En el análisis de datos con Power BI o Fabric, las puertas de enlace juegan un papel fundamental. Son el puente que nos permite conectar de forma segura y eficiente los servicios en la nube de Microsoft con los datos locales de nuestra organización. Estas herramientas facilitan la comunicación entre los sistemas internos y Power BI, garantizando que los datos estén siempre actualizados y disponibles para análisis en tiempo real. Sin embargo, las puertas de enlace no solo son esenciales para Power BI; también pueden integrarse con Microsoft Fabric, potenciando los flujos de trabajo avanzados y las capacidades de procesamiento en paralelo. Este artículo se inspira en los artículos de Toni Jurado en explorandodatos.com, quien ha profundizado en las características esenciales y las mejores prácticas de las puertas de enlace en Power BI, y busca añadir una perspectiva integral sobre su uso y consideraciones técnicas. 

¿Qué es una puerta de enlace de Power BI y Microsoft Fabric?

Las puertas de enlace de Power BI y Fabric son un componente de software (programa) que se instala en nuestros servidores locales y que permiten a los servicios en la nube de Microsoft conectarse de manera segura a los datos almacenados en nuestras instalaciones on-premises. Esto es especialmente valioso para las empresas que, por razones de seguridad o privacidad, no desean o no pueden migrar sus datos sensibles a la nube. La puerta de enlace actúa como un intermediario, procesando solicitudes de datos y cifrando la comunicación entre la fuente local y el servicio en la nube, asegurando así la privacidad y protección de la información.

En la práctica, la puerta de enlace permite realizar transformaciones y filtrados de datos en el entorno local, reduciendo el volumen de datos que se envía a la nube. Esto optimiza el uso del ancho de banda de la red y mejora el rendimiento de las consultas en Power BI o Fabric. Sin embargo, este procesamiento requiere recursos en el servidor donde está instalada la puerta de enlace, lo que implica ciertas consideraciones técnicas a la hora de configurarla y mantenerla.

Tipos de puertas de enlace: Personal y Estándar

Existen dos tipos de puertas de enlace y, aunque las dos opciones sirven para enviar nuestros datos de los servidores locales a la nube de Power BI o de Fabric, tienen sus diferencias significativas. Tendremos que elegir una u otra en función de nuestras necesidades.

Puerta de enlace personal

Esta versión está diseñada para un único usuario y es ideal para casos de uso individual o pruebas rápidas. Permite conectar Power BI con fuentes de datos locales, pero está limitada a un solo usuario y no es adecuada para entornos de producción. No es compatible con los servicios de Microsoft Fabric.

Puerta de enlace estándar

Pensada para su uso en entornos de producción, esta puerta de enlace puede ser utilizada por múltiples usuarios y soporta una configuración avanzada para integrarse, además de con Power BI, con otros servicios, como Power Automate, Power Apps y Microsoft Fabric. Es ideal para empresas que manejan grandes volúmenes de datos y requieren análisis en tiempo real.

Es importante tener en cuenta que, aunque las puertas de enlace personales son útiles para usuarios individuales, en entornos de producción o con Microsoft Fabric se recomienda siempre utilizar las puertas de enlace estándar. Esto garantiza el soporte multiusuario, configuraciones avanzadas de balanceo de carga y alta disponibilidad, que son esenciales para entornos de análisis de datos complejos.

Uso de las puertas de enlace: Orígenes de datos compatibles

Una de las grandes ventajas de las puertas de enlace en Power BI y Fabric es su compatibilidad con una amplia variedad de orígenes de datos locales. Esto permite a las organizaciones integrar en sus análisis en la nube prácticamente cualquier sistema interno sin necesidad de migrar los datos a la nube, y manteniendo el control y la seguridad de la información. A continuación, os nombro algunos de los principales orígenes de datos locales que pueden conectarse a través de las puertas de enlace estándar:

Bases de datos relacionales

Entre los sistemas compatibles podemos encontrar SQL Server, Oracle Database, MySQL, PostgreSQL, DB2 y Teradata. Estos sistemas tienen la capacidad de plegar las consultas y nos permiten la conexión en modo DirectQuery, que consulta los datos en tiempo real, o en modo de importación, ideal para escenarios de carga periódica. Ambos modos facilitan el análisis sin necesidad de replicar todos los datos en la nube.

Fuentes de datos de archivos

Las puertas de enlace permiten el acceso a archivos de Excel, CSV, archivos de texto, XML y carpetas compartidas en red. Los datos de estos archivos pueden ser actualizados automáticamente para reflejar la última versión sin intervención manual. Esto es especialmente útil en entornos donde los datos se almacenan en archivos distribuidos en múltiples ubicaciones.

Sistemas de almacenamiento en la nube privada

Las puertas de enlace pueden conectar servicios de almacenamiento en la nube privada alojados dentro del entorno corporativo, incluyendo SAP HANA y SAP BW. Estos sistemas se encuentran en muchas grandes empresas, y la puerta de enlace asegura que los datos permanezcan en la red local mientras están disponibles para análisis en Power BI y Fabric.

Sistemas de información y aplicaciones empresariales

Power BI y Fabric permiten conectarse a sistemas como Microsoft Dynamics 365 on-premises y servicios OData, incluyendo SharePoint on-premises y otros servicios web empresariales. Estas integraciones son clave para empresas que utilizan sistemas empresariales complejos y desean incorporar datos de múltiples fuentes sin comprometer la seguridad.

Sistemas de mensajería y API REST

Las puertas de enlace también son compatibles con servicios que utilizan API REST, lo que permite integrarse con aplicaciones internas que exponen datos mediante servicios web. Esta opción ofrece flexibilidad para conectar sistemas personalizados de la organización.

Configuración de puertas de enlace en entornos de producción

La instalación y configuración de una puerta de enlace requiere ciertos conocimientos técnicos, especialmente en entornos de producción. Para instalar una puerta de enlace, debemos contar con un equipo (idealmente un servidor) que cumpla con los requisitos técnicos de Microsoft y que esté optimizado para manejar el flujo de datos y la carga de procesamiento.

Una vez instalada, la configuración de la puerta de enlace se gestiona desde el portal de administración de Power BI, donde podemos definir permisos de acceso a las fuentes de datos, configurar la autenticación de usuarios y programar las actualizaciones de datos. Las opciones de administración permiten a sus responsables controlar el acceso de los usuarios y gestionar los permisos para asegurar que solo personas autorizadas puedan acceder a los datos a través de la puerta de enlace.

Buenas prácticas para la instalación de puertas de enlace

Existen ciertas buenas prácticas recomendadas para optimizar el rendimiento y la seguridad de las puertas de enlace en entornos corporativos. A continuación, os comparto algunas consideraciones clave a tener en cuenta al instalar una puerta de enlace:

Separación de la puerta de enlace y el servidor de bases de datos

Aunque pueda parecer tentador, no es recomendable instalar la puerta de enlace en el mismo servidor donde reside la base de datos, ya que ambos servicios requieren recursos significativos. Si comparten el mismo servidor, podrían surgir conflictos de recursos en momentos de alta demanda, afectando la estabilidad y el rendimiento de ambos servicios. En su lugar, se recomienda instalar la puerta de enlace en un servidor dedicado que cuente con recursos suficientes para manejar la carga de trabajo de la puerta de enlace.

Ubicación en la misma subred

Para minimizar la latencia y optimizar el rendimiento de las transferencias de datos, es ideal que la puerta de enlace y el servidor de origen de los datos se encuentren en la misma subred. Esto permite una comunicación más rápida y reduce el riesgo de pérdida de paquetes de datos. Cuando la puerta de enlace y la base de datos están en diferentes subredes o ubicaciones, se puede experimentar una mayor latencia, lo cual afecta la eficiencia en el análisis de datos.

Ahora una recomendación personal. El tráfico de datos generado entre la puerta de enlace y un servidor de base de datos puede ser considerable lo que puede afectar al rendimiento de la red y verse afectado por otros usuarios de la red. Para estos casos la solución ideal es una subred aislada entre el servidor de bases de datos y la puerta de enlace. De este modo, nuestro servidor de bases de datos tendrá dos tarjetas de red, cada una en una red, una para el tráfico de los usuarios y otra exclusiva de comunicación con la puerta de enlace. Tampoco es raro encontrarnos en escenarios empresariales con una subred entre servidores aislada de los usuarios. En estos casos, deberéis valorar con los técnicos de redes si la puerta de enlace debe ir en esta red o en una dedicada.

Además, en entornos corporativos complejos, se recomienda aislar el tráfico de la puerta de enlace y la base de datos mediante VLANs independientes. Esta práctica no solo permite gestionar mejor el ancho de banda como acabamos de comentar sino que mejora la seguridad. La segmentación es particularmente importante cuando se trabaja con datos sensibles, ya que ayuda a cumplir con las normativas de privacidad y seguridad.

Balanceo de carga y alta disponibilidad

En organizaciones con grandes volúmenes de datos o con una alta frecuencia de actualizaciones, es recomendable implementar un clúster de puertas de enlace. Esto permite distribuir la carga de trabajo entre varias instancias, garantizando alta disponibilidad. En caso de que una puerta de enlace falle, otra puede asumir su carga, evitando interrupciones. El balanceo de carga es esencial cuando se trabaja con Microsoft Fabric, especialmente cuando usamos procesamiento de datos en tiempo real que requiere una infraestructura robusta y estable. Estos cluster de puertas de enlace solo los podremos hacer con puertas de enlace estándar, las personales no lo permiten.

Monitorización de recursos

Como la puerta de enlace realiza procesamiento de datos local, es importante monitorizar regularmente los recursos del servidor, como CPU, memoria y uso de red. Si detectamos un uso elevado de recursos, podríamos necesitar escalar la capacidad del servidor o migrar la puerta de enlace a un servidor con mayor capacidad para evitar problemas de rendimiento.

Consideraciones especiales para Microsoft Fabric

Con la integración de Microsoft Fabric, las puertas de enlace han ampliado su funcionalidad, permitiendo manejar flujos de datos más complejos y ejecutar análisis en tiempo real. En entornos de Fabric, es fundamental que la puerta de enlace tenga acceso a suficiente capacidad de procesamiento para soportar las demandas adicionales. Esto incluye configuraciones avanzadas para equilibrar la carga de procesamiento y distribuir las solicitudes de datos de forma eficiente. Además, como ya os he mencionado solo las puertas de enlace estándar son compatibles con Fabric, no vamos a poder usar una puerta de enlace personal.

Conclusión

Las puertas de enlace de Power BI y Microsoft Fabric son herramientas indispensables para las organizaciones que necesitan conectar sus datos locales con el servicio en la nube de forma segura y eficiente. Al permitir el procesamiento local de datos, las puertas de enlace optimizan el uso del ancho de banda y aseguran que solo los datos necesarios se transmiten a la nube, reduciendo la carga en la red y mejorando el rendimiento.

Este artículo y las ideas expuestas han sido inspirados en los artículos de Toni Jurado en explorandodatos.com, quien ha compartido valiosos conocimientos sobre el uso de puertas de enlace en Power BI. También os recomiendo el video sobre este tema del Power Quiz presentado por Ricardo Rincón y Diego jurado con Toni Jurado como quiz maker.

Espero que esta guía contribuya a un entendimiento más profundo de estas herramientas y a su implementación eficaz en entornos empresariales. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

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