Deja de usar tu gateway como un simple tubo: qué hace realmente

By Mirko Peters · 2026-08-28

¡Bienvenido de nuevo al blog complementario del podcast! Si alguna vez has mirado una rueda girando mientras la actualización de un conjunto de datos de Power BI avanza a paso de tortuga, o si tus paneles empresariales caducan justo cuando la dirección más los necesita, probablemente estés señalando en la dirección equivocada. Demasiados arquitectos y administradores tratan el gateway de datos de

Automatically translated with AI from the original post. Read the English original

¡Bienvenido de nuevo al blog complementario del podcast! Si alguna vez has mirado una rueda girando mientras la actualización de un conjunto de datos de Power BI avanza a paso de tortuga, o si tus paneles empresariales caducan constantemente justo cuando la dirección más los necesita, probablemente estés señalando en la dirección equivocada. Demasiados arquitectos y administradores tratan el gateway de datos de Power Platform como un simple accesorio de fontanería: un tubo pasivo que solo transporta datos de un lado a otro entre las bases de datos locales y la nube. Nada más lejos de la realidad.

En esta entrada vamos a profundizar en la realidad arquitectónica del gateway. Veremos cómo actúa como un motor de procesamiento de alto rendimiento y por qué ignorar su configuración destruye activamente el rendimiento de tus informes. Si quieres desgranar estos conceptos arquitectónicos aún más y escuchar un análisis dinámico de escenarios reales de resolución de problemas, no dejes de escuchar nuestro episodio relacionado del podcast, Configure the Power Platform Data Gateway for Reliable Connectivity.

Vamos a levantar el capó y examinar cómo funciona realmente el gateway, junto con los pasos concretos que puedes dar para convertirlo de un cuello de botella en una autopista de alta velocidad.

El intermediario incomprendido: qué hace realmente el gateway

Para mejorar el rendimiento de tu gateway, primero necesitas entender qué ocurre realmente cuando un servicio en la nube hace una solicitud a un origen de datos local. El flujo de datos parece engañosamente sencillo sobre el papel: el servicio de Power BI se comunica con el clúster de gateway, que se comunica con la máquina host, que ejecuta una consulta contra tu origen de datos y después recorre el camino inverso para devolver los resultados. Pero esto no es un relé pasivo.

El gateway realiza un trabajo pesado en cada uno de los saltos. Gestiona los intercambios de autenticación, termina y restablece el cifrado Transport Layer Security (TLS), traduce las cargas de consulta y administra grandes búferes de memoria. Como gestiona el cifrado, la traducción de consultas y el almacenamiento temporal en búfer de archivos, la máquina del gateway es un motor de procesamiento completamente funcional. Tratarlo como un middleware ligero es una receta para el desastre.

También debes fijarte bien en el modo de implementación. El gateway en modo personal está diseñado estrictamente para escenarios de un único usuario y nunca debería utilizarse para informes empresariales compartidos. Para cargas de trabajo de producción, debes implementar el gateway de datos estándar, idealmente en una configuración en clúster con dos o más nodos para garantizar alta disponibilidad y equilibrio de carga. Además, las arquitecturas modernas pueden aprovechar las puertas de enlace de datos de Azure VNet para lograr cero exposición entrante, lo que deja contentos a tus equipos de seguridad sin renunciar a un rendimiento robusto.

Configuración predeterminada y lastres ocultos para el rendimiento

Cuando instalas una instancia nueva del gateway de datos de Power Platform, el instalador se basa en valores predeterminados conservadores, diseñados para que funcione de inmediato en casi cualquier hardware. Por desgracia, en un entorno empresarial estos valores predeterminados actúan como lastres silenciosos para el rendimiento.

Tomemos la simultaneidad, por ejemplo. De forma predeterminada, el gateway suele funcionar con una cola muy restrictiva que limita la ejecución de consultas en paralelo. Si tienes hardware potente sin usar mientras tus actualizaciones se acumulan en secuencia, estás desperdiciando recursos. Necesitas aumentar los límites de consultas en paralelo para que se ajusten a la capacidad real de tu host.

El dimensionamiento de los búferes es otro error habitual. Si los búferes son demasiado pequeños, el gateway se ve obligado a volcar datos al disco, lo que provoca cuellos de botella de E/S muy graves. Dale a tu memoria RAM un margen razonable. Además, asegúrate de que el software antivirus de tu equipo de seguridad tenga las exclusiones adecuadas. El análisis en tiempo real de las rutas de instalación, caché y registros del gateway puede paralizar el procesamiento de consultas, ya que cada archivo temporal se inspecciona de forma exhaustiva.

También tenemos que hablar del ajuste StreamBeforeRequestCompletes. Aunque puede mejorar notablemente el rendimiento en redes locales de baja latencia, introduce riesgos graves en VPN de alta latencia. Por último, cuidado con el efecto de amnesia posterior a la actualización. Cada vez que actualizas el software de la puerta de enlace, las configuraciones predeterminadas pueden restablecerse y borrar tus ajustes personalizados. Vuelve a aplicar siempre tus ajustes de rendimiento inmediatamente después de actualizar la puerta de enlace.

El factor de red: enrutamiento, latencia y la realidad de la "cold-potato"

Puedes instalar el hardware más caro en el host de la puerta de enlace, pero si el enrutamiento de red es fundamentalmente deficiente, el rendimiento seguirá sufriendo. La latencia se acumula en cada salto de red, y un mal enrutamiento anulará por completo cualquier otra optimización que intentes.

Muchas organizaciones caen en la trampa de canalizar todo su tráfico a través de VPN corporativas y proxies web centralizados "por control". En realidad, este desvío innecesario añade cientos de kilómetros de distancia física, saltos de red adicionales y retrasos de inspección TLS que consumen muchos recursos. En su lugar, deja que tu tráfico salga localmente hacia el Punto de presencia (POP) de borde de Microsoft más cercano lo antes posible. Una vez que el tráfico llega a ese POP de borde, viaja por la red troncal global optimizada de Microsoft directamente hasta su destino.

Para el análisis sensible e interactivo, configura las preferencias de enrutamiento de red de Microsoft para garantizar un rendimiento de primer nivel. Reserva las opciones de enrutamiento por Internet estándar solo para transferencias de datos masivas y de baja prioridad. Salir del desvío por la VPN corporativa suele ser el cambio más impactante que una organización puede hacer para mejorar los tiempos de actualización de sus informes.

Hardware y alojamiento: cómo construir un host de puerta de enlace real

Como la puerta de enlace es un motor de procesamiento de alta exigencia, ejecutarla en una máquina virtual compartida y con recursos sobreasignados es una invitación al fallo. Debes tratar el host de la puerta de enlace como infraestructura empresarial de primer nivel.

En cuanto al hardware, apunta a una especificación base de al menos 16 GB de RAM, 8 o más núcleos de CPU físicos y almacenamiento SSD o NVMe rápido para la caché y los archivos de registro. Las máquinas virtuales son perfectamente aceptables, pero debes asegurarte de que los recursos de CPU y memoria estén estrictamente reservados y nunca sobreasignados.

Para eliminar puntos únicos de fallo y escalar el rendimiento, implementa clústeres de puertas de enlace compuestos por al menos dos nodos. Es fundamental que todos los nodos de un clúster tengan los mismos números de versión y configuraciones coincidentes. Para verificar que el hardware está bien dimensionado, mide lo que realmente importa con el informe integrado Gateway Performance junto con los contadores de Windows Performance Monitor (PerfMon) que monitorizan el uso de CPU, el consumo de RAM, los bytes privados y la duración de ejecución de las consultas.

Prácticas de optimización proactiva y mantenimiento

La infraestructura requiere cuidados constantes, y las puertas de enlace de datos no son la excepción. Uno de los errores administrativos más comunes es habilitar las actualizaciones automáticas en las puertas de enlace de producción. Una actualización de software repentina y no validada puede alterar tus archivos de configuración o introducir problemas de compatibilidad que rompan informes críticos para el negocio.

En su lugar, establece un entorno de pruebas donde validar las actualizaciones antes de pasarlas a producción. Mantén siempre una copia de seguridad de la configuración de tu clúster y de tus orígenes de datos para poder recuperarte rápidamente si las cosas se tuercen. Crea paneles de estado semanales que correlacionen los picos de actualización con tu calendario, lo que te permitirá repartir las cargas de trabajo que consumen muchos recursos de forma uniforme a lo largo del tiempo.

Aprovecha los scripts de PowerShell para ejecutar comprobaciones de estado automatizadas que supervisen el estado del servicio, las versiones del software y la profundidad de la cola, e implementa reinicios programados y ordenados del servicio en horas de menor actividad. Documenta las versiones de tu sistema operativo, las versiones de .NET Framework, los puertos abiertos y las exclusiones de antivirus. Tratar la puerta de enlace como infraestructura real significa aplicar una gobernanza de TI disciplinada a sus operaciones diarias.

Lista de verificación de implementación para una conectividad fiable

Para ayudarte a poner en práctica estos conceptos de inmediato, aquí tienes una lista de verificación breve y accionable que puedes copiar, pegar y revisar con tu equipo:

• Verifica el modo: asegúrate de estar ejecutando una puerta de enlace estándar (nunca personal) y de tener al menos dos nodos en el clúster.
• Ajusta la concurrencia: aumenta las consultas paralelas por origen de datos y nodo, y aumenta los tamaños de búfer mientras supervisas el uso de RAM.
• Optimiza el almacenamiento: coloca la caché y los registros de la puerta de enlace en unidades SSD o NVMe rápidas, y configura exclusiones de antivirus completas.
• Evalúa el streaming: revisa la configuración StreamBeforeRequestCompletes según tu latencia de red real.
• Corrige el enrutamiento: enruta el tráfico de salida de forma local y evita VPN o proxies innecesarios para los endpoints de Microsoft 365 y Power Platform.
• Prioriza el tráfico: confirma que las preferencias de enrutamiento de Microsoft Network están habilitadas para el tráfico analítico.
• Dimensiona bien el hardware: asegúrate de que el host tenga al menos 16 GB de RAM, 8 o más núcleos físicos y recursos reservados si está virtualizado.
• Supervisa el rendimiento: habilita el informe Gateway Performance y conecta los contadores de PerfMon.
• Automatiza el estado: implementa comprobaciones de estado con PowerShell y reinicios de servicio programados y controlados.
• Gobierna las actualizaciones: prepara las actualizaciones de software en los nodos secundarios, conserva copias de seguridad de la configuración y documenta tu línea base operativa.

Conclusión

La puerta de enlace de datos de Power Platform es mucho más que un simple puente o una tubería pasiva: es un motor de procesamiento sofisticado que se encuentra en el corazón de tu arquitectura de analítica híbrida. Si dejas atrás la configuración predeterminada, optimizas el enrutamiento de red para aprovechar la red troncal global de Microsoft, inviertes en hardware adecuado para el host y mantienes hábitos operativos rigurosos, puedes eliminar por completo los cuellos de botella de actualización y ofrecer los informes ultrarrápidos que exige tu organización.

Si quieres escuchar un análisis más profundo de estos principios de arquitectura y encontrar aún más consejos prácticos para ahorrar minutos preciosos en tus ventanas de actualización, no dejes de escuchar el episodio del podcast Configure the Power Platform Data Gateway for Reliable Connectivity. ¡Sintoniza, suscríbete y toma el control de tu conectividad empresarial hoy mismo!