Planificar una implementación de ExpressRoute para su uso con Microsoft Power Platform
Ahora que ha decidido utilizar ExpressRoute para Microsoft Power Platform, es importante planificar la implementación para tener en cuenta sus necesidades y su entorno.
Requisitos previos para ExpressRoute
La configuración de ExpressRoute requiere tener en cuenta y configurar varios requisitos previos. Estos pueden generar costes y actividades inesperados, que si no se planifican pueden afectar el proyecto y la operación continua de otros servicios.
Requisitos previos externos
ExpressRoute no proporciona la conexión física en sí, proporciona la conectividad privada a través de una conexión física ya establecida. Primero, un proveedor de conectividad debe configurar la conectividad física. Hay varias formas de establecer esta conectividad con los socios de ExpressRoute existentes. La documentación de ExpressRoute ofrece explicaciones detalladas de las opciones y los partners actualmente disponibles.
Como parte de la planificación, deberá tener en cuenta lo siguiente:
Geografía: Como analizaremos con más detalle más adelante, comprender geográficamente desde dónde se deben realizar una o más conexiones afectará su planificación general.
Costo: El proveedor de conectividad cobrará por establecer la conexión privada. Esto puede representar un coste significativo, que variará según el tipo y la cantidad de conexiones necesarias.
Tiempo de configuración:: En algunos casos, será necesario configurar el hardware físico. Este tiempo de configuración deberá incorporarse la programación de la implementación.
Configuración capacidades y recursos: La mayor parte de la complejidad de la configuración radica en configurar el enrutamiento interno dentro de su red. Es esencial que se asegure de que haya personas capacitadas disponibles para hacer esto.
Microsoft Prerrequisitos
Una vez establecida la conectividad física, puede pasar a configurar las propias conexiones de ExpressRoute. Esta operación requerirá.
Una suscripción de Azure en la que aprovisionar y facturar los circuitos de ExpressRoute.
Configuración dentro de la suscripción de Azure de los circuitos de ExpressRoute, que se realiza a través de las herramientas de Azure.
Planificación de la configuración de enrutamiento para el tráfico de Microsoft Power Platform a través de ExpressRoute
Al planificar el enrutamiento del tráfico de Microsoft Power Platform, deberá tener en cuenta los distintos tipos de tráfico, que dependen de cómo haya configurado y utilizado Microsoft Power Platform.
Para comprender cómo configurar ExpressRoute para Microsoft Power Platform, deberá tener en cuenta los diferentes usos y conexiones desde y hacia Microsoft Power Platform, que dependen de los servicios y funciones que utilice.
Configuración de enrutamiento
La configuración del enrutamiento la realiza el proveedor de conectividad o el cliente, según el tipo de conexión proporcionado.
Aunque la conexión de ExpressRoute en sí es entre centros de datos, la conexión de red real proviene principalmente de los dispositivos cliente del usuario (que a menudo se distribuirán a través de una WAN más amplia, por ejemplo, sucursales bancarias distribuidas). Esto significa que las conexiones se enrutan desde la ubicación del dispositivo cliente a través de la WAN al centro de datos y luego a través del circuito de ExpressRoute. Esto requiere una configuración meticulosa. La WAN debe configurarse de manera que:
La ruta a través de la subred de la red está configurada para ExpressRoute.
or
El circuito de conmutación por error se elige con preferencia a la conexión a la red pública de Internet para Microsoft Power Platform.
Por lo tanto, es importante identificar qué subredes dentro de su red deben ser los destinos para las conexiones de sesión del Protocolo de puerta de enlace de borde (BGP) principal y de reserva, para asegurarse de que los prefijos de Microsoft Power Platform prefieran esa ruta. No es necesario configurar específicamente los servicios en cada extremo, porque esta configuración se realiza anunciando las subredes y prefijos de IP a través de esta conexión. Cuando se inicia una solicitud, el algoritmo de enrutamiento ve esa conexión de BGP directa como la ruta preferida para el tráfico hacia la subred conectada al circuito de ExpressRoute y dirige el tráfico de esa manera.
Configuración de ExpressRoute para bases de usuarios distribuidas
ExpressRoute está diseñado para proporcionar conexiones privadas, dedicadas y, por lo tanto, predecibles desde su Compartir a la red. Microsoft Cuando tiene una conexión dedicada y directa a través del proveedor de conectividad a Microsoft, reduce la posibilidad de tener que competir con otro tráfico en las conexiones que realiza a través de la red del proveedor de conectividad. No debería ser necesario utilizar ExpressRoute para lograr esta calidad de conexión a través de un proveedor de conectividad, pero es una forma de ayudar a garantizarlo.
En el siguiente ejemplo, un usuario en una sucursal tiene su conexión enrutada a través de la WAN hacia la conexión del centro de datos del cliente a ExpressRoute.
Cuando un cliente tiene una red de usuarios altamente distribuida, como una red de sucursales de oficinas distribuidas por un paísj o región, el tráfico de la red debe estar conectado de manera eficiente desde múltiples ubicaciones muy distribuidas geográficamente. El patrón típico para esto es enrutar elementos a través de la WAN hacia la red local conectada a ExpressRoute, como se muestra en la siguiente imagen.
Si la conexión entre el cliente y ExpressRoute es deficiente, o está saturada o es ineficaz de alguna otra manera, ExpressRoute no podrá resolver esto, porque los problemas de conexión para llegar al punto de entrada de ExpressRoute seguirán afectando a la experiencia del usuario. En un caso como este, debería considerar usar ExpressRoute Direct, que le brinda la posibilidad de conectarse directamente a la red global de Microsoft.
Cuando se conecta a servicios en la nube y se ve limitado por conexiones WAN complejas, puede ser beneficioso establecer interrupciones de Internet locales desde sucursales locales. Esto evitará la conexión WAN más lenta y aprovechará el alcance del proveedor de conectividad para lograr una conexión más directa al servicio en la nube.
Es posible configurar circuitos de ExpressRoute desde múltiples ubicaciones, e incluso hacia ubicaciones de sucursales individuales a través de una interrupción de la red local de Internet, como se muestra en la siguiente imagen.
El enfoque de conectar sucursales a un centro de datos central a través de una WAN y establecer circuitos ExpressRoute entre el cliente y los centros de datos suele ser preferible y más práctico que intentar establecer una conexión ExpressRoute desde cada sucursal. Microsoft Eso sería relativamente caro y complicado de configurar y mantener, si fuera necesario en muchos lugares.
Un enfoque alternativo es Conectar todas las sucursales y el centro de datos del cliente en la misma VPN IP y tener el proveedor de servicios VPN IP Conectar en una ubicación de ExpressRoute. Microsoft
Si tiene problemas con una conexión WAN local, normalmente es mejor optimizarlos (a través de métodos como ampliar el ancho de banda adicional u optimizar el enrutamiento) en lugar de intentar establecer una conexión ExpressRoute desde cada ubicación.
Para las redes que se distribuyen en una amplia zona geográfica, puede resultar útil tener varios concentradores conectados a ExpressRoute para minimizar la cantidad de conexiones ExpressRoute necesarias y, al mismo tiempo, ofrecer un punto de conexión más local para cada usuario. En este caso, es importante asegurarse de que se publiquen direcciones IP públicas únicas a través de cada circuito de ExpressRoute; cada una de estas subredes debe ser distinta, lo que requiere que tenga tantas subredes de cara al público como conexiones de ExpressRoute.
Esto es particularmente beneficioso si diferentes áreas operativas están ubicadas en áreas geográficas muy diferentes, o si la conectividad de red entre las áreas es limitada y se puede establecer una conexión más directa para cada una. Microsoft
También es posible que diferentes regiones tengan diferentes requisitos de privacidad, y no es necesario que todas las regiones usen ExpressRoute simplemente porque uno lo hace. Es posible que algunas conexiones se enruten directamente a través de Internet y otras a través de ExpressRoute, como se muestra en la siguiente imagen.
ExpressRoute (estándar) ofrece conectividad solo dentro de una región geográfica específica; se requiere ExpressRoute Premium para ofrecer acceso a múltiples ubicaciones geográficas desde un único punto de conexión ExpressRoute. Esto sería relevante si, por ejemplo, un cliente tuviera oficinas en EE. UU. y en Europa, todas usando un único entorno de Microsoft Power Platform. Si el inquilino de Microsoft Power Platform del cliente está implementado en los Estados Unidos, su circuito de ExpressRoute en Europa debe ser el SKU Premium. Si su inquilino de Microsoft Power Platform está en Europa, su circuito de EE. UU. debería ser Premium.
Evitar el enrutamiento asimétrico
Un desafío a tener en cuenta es el enrutamiento asimétrico, donde la configuración de enrutamiento dentro de la red del cliente enruta el tráfico al centro de datos directamente a través de Internet, pero luego el tráfico de retorno determina que las respuestas deben enrutarse a través de un circuito ExpressRoute. Microsoft Esto a menudo puede hacer que un firewall rechace el tráfico, porque recibe paquetes de respuesta sin haber enviado los paquetes de solicitud.
Esto puede suceder si la red local de un cliente determina que el enrutamiento más eficiente hacia los servicios en la nube es a través de Internet pública en lugar de a través de la WAN hacia el circuito privado ExpressRoute. Microsoft Pero si la dirección IP del cliente es una dirección IP pública o se traduce a través de asignaciones de NAT a una dirección IP pública que se anuncia a través de ExpressRoute, la ruta más eficiente de regreso a esa IP probablemente sería a través de la sesión de BGP a través de ExpressRoute. Puede usar diferentes IP de NAT en su perímetro de Internet y de ExpressRoute. Con una dirección de origen distinta, el tráfico de retorno volverá sin ambigüedades al mismo perímetro.
Esto también puede suceder cuando hay varios circuitos ExpressRoute configurados para el mismo cliente con enrutamiento de tráfico saliente a través de un circuito, pero enrutamiento de retorno a través de otro donde las comprobaciones de firewall pueden bloquear el tráfico a través de la ruta de retorno. Para evitar el enrutamiento asimétrico a través de un circuito ExpressRoute diferente para las rutas de entrada y salida, es importante asegurarse de que se publiquen direcciones IP públicas únicas en cada circuito.
Como puede ver, es importante determinar cómo se gestiona el enrutamiento dentro de su WAN y asegurarse de que las rutas hacia y desde los servicios en la nube se consideren cuidadosamente. Microsoft
Conectividad externa hacia y desde Microsoft Power Platform
Al establecer conexiones con Microsoft Power Platform desde las ubicaciones de los clientes, hay que considerar varios tipos de tráfico. Esto puede conducir a ambos tipos de peering, Microsoft y peering privado, y el mismo circuito ExpressRoute se puede utilizar para estos tipos de peering como se muestra en la siguiente imagen.
Hay diferentes tipos de conexión que existen entre los servicios de Microsoft Power Platform y una red externa. Por ejemplo, la conectividad de Exchange Web Services mediante sincronización del lado del servidor utiliza ExpressRoute para pasar el tráfico de red desde la red a la red del cliente. Microsoft La conectividad de servicios web utiliza ExpressRoute tanto para el tráfico entrante como para el saliente a la red. Microsoft Para el cliente HTTPS, se utiliza la conexión ExpressRoute para el acceso desde la red del cliente a la red. Microsoft En la siguiente imagen ilustra estos ejemplos.
Tráfico saliente (tráfico desde los servicios de Microsoft Power Platform)
Varios tipos de tráfico saliente pueden producirse directamente desde los servicios de Microsoft Power Platform hacia los servicios del cliente. Para cada uno de estos, es importante tener en cuenta que el servicio del cliente debe ser direccionable públicamente con una IP pública que pueda ser resuelta a través de un DNS público por los servicios de Microsoft Power Platform.
Esta dirección IP también debe anunciarse a través de ExpressRoute para que el enrutamiento de red interna dentro de los servicios sepa que debe enrutarla a través de esa conexión ExpressRoute. Microsoft Microsoft Power Platform
Los servicios de Microsoft Power Platform no pueden especificar qué instancia de servicio u organización del cliente puede realizar solicitudes a qué direcciones IP. Por lo tanto, es importante tratar las solicitudes entrantes a la red corporativa como si fueran de Internet y protegerlas como tales.
La siguiente tabla describe el tráfico saliente desde los servicios de Microsoft Power Platform.
Descripción | Tipo y dirección del tráfico | Tipo de emparejamiento | Objetivo |
---|---|---|---|
Servicios web | HTTPS saliente desde los servicios de Microsoft Power Platform | Microsoft mirando fijamente Publicar servicios web en direcciones IP públicas que se encuentran dentro de subredes configuradas por ExpressRoute |
Los complementos personalizados y las actividades de flujo de trabajo pueden realizar solicitudes de servicios web a servicios externos |
Integración de Exchange: modo híbrido | HTTPS saliente desde los servicios de Microsoft Power Platform | Microsoft mirando fijamente Los servicios web necesitan publicarse en direcciones IP públicas que se encuentran dentro de subredes configuradas por ExpressRoute |
Solicitudes de servicios web de Exchange desde la sincronización del lado del servidor para implementaciones híbridas (servicios de Microsoft Power Platform, Exchange local) |
Conectores | HTTPS entrante desde los servicios de Microsoft Power Platform | Microsoft mirando fijamente | Solicitudes desde los servicios de Microsoft Power Platform a través del servicio Azure API Management a través de conectores usando la puerta de enlace de datos local |
Azure Relay | HTTPS saliente desde los servicios de Microsoft Power Platform | Microsoft mirando fijamente Publicar servicios web en direcciones IP públicas que se encuentran dentro de subredes configuradas por ExpressRoute |
Conectividad directa entre los flujos de nube de Power Automate y los flujos de escritorio |
Tráfico entrante (tráfico hacia los servicios de Microsoft Power Platform)
El siguiente tráfico entrante se pude enviar a los servicios de Microsoft Power Platform desde la red del cliente.
Descripción | Tipo y dirección del tráfico | Tipo de emparejamiento | Objetivo |
---|---|---|---|
Conectividad del cliente | HTTPS entrante hacia los servicios de Microsoft Power Platform | Microsoft mirando fijamente Conexión directa a Internet para contenido estático proporcionado por Azure Content Delivery Network |
Solicitudes de clientes para la interfaz de usuario de los servicios de Microsoft Power Platform |
Servicios web | HTTPS entrante hacia los servicios de Microsoft Power Platform | Microsoft mirando fijamente | Solicitudes para servicios de Microsoft Power Platform a través de las API de servicios web (SOAP, API web). Ya sea desde una aplicación de cliente estándar o personalizada |
Conectores | HTTPS entrante hacia los servicios de Microsoft Power Platform | Microsoft mirando fijamente | Respuestas de vuelta a los servicios de Microsoft Power Platform a través de los APIM a través de conectores utilizando la puerta de enlace de datos local |
Conectividad interna en la nube dentro de los servicios de Microsoft Power Platform
Microsoft Power Platform Los servicios utilizan e integran varios otros servicios en línea alojados tanto en Azure como en Azure. Microsoft Microsoft 365
Descripción | Tipo y dirección del tráfico | Finalidad |
---|---|---|
Integración de Exchange | HTTPS saliente a Microsoft 365 | Solicitudes del servicio web de Exchange para Exchange Online desde la sincronización del lado del servidor |
Integración con SharePoint | HTTPS saliente a Microsoft 365 | Solicitudes de servicio web de SharePoint a SharePoint Online desde los servicios de Microsoft Power Platform |
Service Bus | HTTPS saliente a Azure Service Bus | Envíe eventos a Azure Service Bus como registro de eventos estándar o desde los complementos personalizados y actividades de flujo de trabajo |
Sincronización de datos | HTTPS entrante desde Azure | Solicitudes de seguimiento de cambios entrantes para la sincronización de servicios de datos, incluida la búsqueda, la desconexión e información del cliente |
Autenticación | HTTPS saliente a Microsoft Entra | La mayor parte de la autenticación se realiza a través de redireccionamientos pasivos y símbolos (tokens) de notificaciones, pero algunos datos se sincronizan directamente con Microsoft Entra ID |
Flujos de datos | HTTPS saliente a Azure Data Lake Storage | Proporciona capacidades de análisis y permite el acceso a soluciones de macrodatos que incorporan datos de los servicios de Microsoft Power Platform y otras fuentes, además de la información resultante de la analítica. |
Conectores | HTTPS saliente a servicios PaaS de Azure | Conexiones a varios servicios de PaaS de Azure |
Desktop flows | HTTPS saliente a Azure Relay | Conectividad directa entre los flujos de nube de Power Automate y los flujos de escritorio en Power Automate para escritorio |
La conectividad real entre estos servicios, alojados en suscripciones de Azure de los clientes, está gestionada por Microsoft . Microsoft ExpressRoute no se aplica a las conexiones con estos servicios.
Cuando los eventos se envían al bus de servicio, la conectividad entre los servicios de Microsoft Power Platform y Azure se gestiona internamente. Por otra parte, el cliente puede realizar solicitudes al Service Bus para recuperar información, y esto se puede gestionar a través de peering. Microsoft
Conectividad de nube pública y privada del cliente hacia y desde los servicios de Microsoft Power Platform
Los servicios de Microsoft Power Platform también permiten la integración directa con recursos de Azure públicos o privados:
Desde fuentes externas, utilizando las API de los servicios web de Microsoft Dataverse.
A fuentes externas, mediante el uso de solicitudes de servicios web realizadas.
A fuentes externas, mediante conectores.
Las implicaciones de esto deben considerarse en el enrutamiento de ExpressRoute.
Descripción | Tipo y dirección del tráfico | Tipo de emparejamiento | Finalidad |
---|---|---|---|
Portals | HTTPS entrante a Azure | Interno del centro de datos, con la excepción del contenido estático, que utiliza Content Delivery Network. (Content Delivery Network no es compatible con ExpressRoute, por lo que el contenido estático viajará a través de la red pública de Internet). | Hospede servicios para el público. Puede haber escenarios en los que los empleados internos puedan acceder a estos recursos, por lo que es posible que desee que el tráfico viaje a través de ExpressRoute en lugar de la red pública de Internet. |
Ruta de aprendizaje | HTTPS entrante a Azure | Utiliza Content Delivery Network, que noes compatible con ExpressRoute, por lo que el contenido estático viajará a través de la red pública de Internet | Está hospeado en un servicio público porque no contiene datos privados de clientes. Para fines de previsibilidad, puede haber escenarios en los que desee enrutar esto a través de ExpressRoute |
Service Bus | HTTPS entrante a Azure Service Bus | Interno al centro de datos | Extraiga eventos de Azure Service Bus que se hayan ubicado ahí como registro de eventos estándar o desde los complementos personalizados o actividades de flujo de trabajo |
Solicitudes de servicio web | Entrante desde la IaaS o PaaS de Azure | Interno al centro de datos | Los clientes pueden hospedar aplicaciones personalizadas en Azure y realizar solicitudes de servicios web de Microsoft Power Platform |
Solicitudes de servicio web | Saliente a la IaaS o PaaS de Azure | Interno al centro de datos | Los clientes pueden implementar complementos personalizados y actividades de flujo de trabajo que realizan solicitudes de servicios hospedados de Azure. |
Flujos de datos | Conexiones de datos a Azure Data Lake Storage | Interno al centro de datos | Proporciona capacidades de análisis y permite el acceso a soluciones de macrodatos que incorporan datos de los servicios de Microsoft Power Platform y otras fuentes, además de la información resultante de la analítica. |
Azure Data Lake | Conexiones de datos a Azure Data Lake Storage | Interno al centro de datos | Proporciona capacidades de análisis y permite el acceso a soluciones de macrodatos que incorporan datos de los servicios de Microsoft Power Platform y otras fuentes y la información resultante de la analítica. |
SQL de Azure | Conexiones de datos a los servicios de Azure SQL | Interno al centro de datos | Con capacidades como Exportar a almacén de datos, aumentará el uso de una instancia de Azure SQL para almacenar réplicas de datos de Microsoft Dataverse, ya sea con fines de generación de informes o de replicación. Puede resultar útil proteger las conexiones a estos recursos a través de ExpressRoute. |
Es posible que en el futuro haya otros servicios públicos que se conecten internamente al centro de datos a medida que se usen otras capacidades de Azure.