Nota
O acceso a esta páxina require autorización. Pode tentar iniciar sesión ou modificar os directorios.
O acceso a esta páxina require autorización. Pode tentar modificar os directorios.
Configurar ExpressRoute adoita ser máis complexo do que pensas. Na planificación ou na execución, é fácil pasar por alto ou subestimar factores como estes:
Configurando a súa rede para dirixir o tráfico á subrede que se conecta a ExpressRoute.
Evitando o enrutamento asimétrico, onde o tráfico vai directamente a Power Platform a través de Internet pero ExpressRoute devolve á rede corporativa e o cortalumes o rexeita.
Determinar se se deben establecer varios circuítos ExpressRoute para implementacións distribuídas.
Os custos xerais asociados ao uso de ExpressRoute, incluídos Microsoft Azure servizos, subministración de provedores de conectividade e configuración de enrutamento de rede de TI interna e servizos en curso.
Tamén debes considerar a posibilidade de problemas de rendemento de conectividade e riscos de seguridade. Este artigo analiza os problemas que poden xurdir ao usar ExpressRoute con Power Platform e como mitigalos.
Problemas de rendemento de conectividade
É importante comprender os problemas de rendemento da conectividade que poden xurdir con ExpressRoute.
Conectividade LAN deficiente: os novos servizos poden afectar a unha rede local xa saturada. Por exemplo, a túa Power Platform solución substitúe unha aplicación cliente grosa onde só se transmitiron os datos pola rede. Aínda que unha aplicación de navegador require menos administración de implantación no lado do cliente, require un maior ancho de banda para transmitir datos e información de presentación.
Conectividade WAN deficiente: a nivel da rede de área ampla (WAN), o tráfico pode atravesar a rede corporativa en lugar de dirixirse a Internet antes. Pode ser encamiñada a través dun servidor proxy ou a ligazón WAN pode estar saturada. Estes factores introducen unha latencia que pode afectar significativamente o rendemento. Se Power Platform o tráfico sofre estes desafíos, o rendemento do cliente tamén pode sufrir.
Mala conectividade a Internet: engadir servizos na nube pode xerar un consumo adicional e cargar a conexión corporativa a Internet. É posible que a conexión a Internet non poida soportar a carga adicional, especialmente nos momentos de maior uso. O fornecedor de Internet pode dirixir de forma ineficiente o tráfico á rede de Microsoft. A conexión pode sufrir unha mestura de tráfico que compite polo ancho de banda dispoñible, o que afecta a calidade da conexión.
Podes solucionar estes problemas obtendo máis ancho de banda ou conexións separadas a través do teu provedor de internet. Unha conexión separada que estea dedicada ao tráfico prioritario pode axudar a mellorar o rendemento e a previsibilidade do tráfico. Asegúrate de configurar a calidade de servizo (QoS) correctamente. Obtén máis información en Requisitos de QoS de ExpressRoute.
Control de seguranza
A seguinte consideración é a seguridade. ExpressRoute non cifra nin filtra o tráfico de forma nativa, excepto ExpressRoute Direct con MACsec activado. Simplemente establece unha conexión privada directamente entre Microsoft e os centros de datos dos clientes a través dun provedor de conectividade.
Calquera solicitude de calquera servizo en liña de Microsoft ou servizo de Azure á subrede que se anuncia a través dun circuíto ExpressRoute envíase a través dese circuíto, independentemente do servizo ou do cliente. Dado que a solicitude se dirixe á capa de rede, non hai ningún control a nivel de aplicación para comprobar se o solicitante é adecuado para o servizo de destino.
O tráfico á nube de Microsoft usa servizos públicos compartidos, aos que se pode acceder directamente a través da Internet pública. A autenticación a nivel de aplicación e a autorización controlan o acceso a estes servizos. As proteccións a nivel de infraestrutura protexen contra intrusións e ameazas como ataques de denegación de servizo. Para o tráfico dos servizos de Microsoft aos servizos aloxados locais, é responsable de proporcionar unha protección similar aos seus servizos cando se recibe tráfico a través dunha conexión ExpressRoute.
Posibilidade de restrinxir o uso de ExpressRoute só a determinados servizos de Microsoft
Un dos retos aos que pode enfrontarse é querer empregar ExpressRoute para un Microsoft Cloud Service específico pero non para outros. Aínda que as diferentes opcións de peering proporcionan certo nivel de control, o peering en si non proporciona un control granular dentro de servizos do mesmo tipo de peering; por exemplo, para permitir o enrutamento a máquinas virtuais de Azure pero non a Microsoft 365. Dado que os servizos Power Platform e Microsoft 365 se ofrecen a través do peering de Microsoft, a configuración do peering de Microsoft anuncia todos os servizos Power Platform e Microsoft 365 en todo o circuíto ExpressRoute de forma predeterminada.
ExpressRoute non ofrece a posibilidade de configurar directamente os servizos que se encamiñan a través dun circuíto específico. Non obstante, é posible utilizar etiquetas da comunidade Border Gateway Protocol (BGP) para controlar o enrutamento para que só os servizos específicos utilicen a conexión ExpressRoute.
Microsoft anuncia rutas nas rutas de interconexión de Microsoft coas rutas etiquetadas cos valores da comunidade BGP axeitados para as localizacións xeográficas e os tipos de servizo. Podes configurar os teus enrutadores para usar o etiquetas para Microsoft 365 servizos para enrutar o tráfico só para eses servizos a través do circuíto ExpressRoute e encamiñar o resto a través dun circuíto ExpressRoute diferente ou a Internet pública.
Non todos Microsoft 365 os servizos están deseñados para funcionar con ExpressRoute. Power Platform os servizos non teñen unha comunidade BGP designada como algúns Microsoft 365 servizos fan. En vez diso, deberías usar comunidades BGP rexionais para coincidir coa rexión onde se creou o Power Platform entorno . Dado que os Power Platform entornos usan dous conxuntos de centros de datos, asegúrate de consultar a Descrición xeral das rexións para identificar os dous centros de datos que se utilizan.
Teña en conta que permitir que as comunidades BGP enruten o tráfico para un servizo leva a que ambos se encamiñan a través de ExpressRoute, o que pode ter resultados desfavorables. Por exemplo, se determina o ancho de banda de rede que Power Platform necesita e dimensiona a conexión de ExpressRoute en consecuencia, pero sen querer dirixir todo o seu Microsoft 365 tráfico a través de ExpressRoute, pode saturar a súa rede e provocar problemas de rendemento.
Dado que os Power Platform servizos funcionan parcialmente como parte do servizo Microsoft 365 , tamén son necesarios moitos servizos cruzados, como o portal de administración e a autenticación. Non é posible protexer todos estes servizos mediante ExpressRoute. O Microsoft 365 centro de administración, por exemplo, non se publica en ExpressRoute.
Obtén máis información en Azure ExpressRoute para Microsoft 365.
Compatibilidade para nubes independentes
Os clientes que están obrigados a cumprir as regulacións específicas do goberno ou do país/rexión poden optar por utilizar unha nube soberana. As nubes soberanas sitúanse fisicamente nunha rexión para cumprir os requisitos específicos dun goberno ou país/rexión. Por exemplo, Power Apps for Government Community Cloud (GCC) está situada nos Estados Unidos, onde cumpre as regulacións e certificacións específicas do goberno dos Estados Unidos e cumpre os protocolos para cumprir eses requisitos.
Mira este vídeo para saber como Power Platform está dispoñible con nubes soberanas: Vídeo: Nubes soberanas con Marty Carreras.
Cando consideras usar un ambiente de nube soberano, tamén debes considerar cales son as limitacións que existen. Non todas as funcións están dispoñibles en comparación cos contornos de nube pública. A seguinte táboa enumera a dispoñibilidade de ExpressRoute para Power Platform por ambiente. Obtén información sobre outras diferenzas de dispoñibilidade en Power Automate descrición xeral das rexións.
| Rexión | Soporte de ExpressRoute |
|---|---|
| Nube comunitaria do Goberno dos Estados Unidos (GCC) | Compatible 1 |
| Cloud Community High (GCC High) | Compatible 1 |
| A China | Compatible 2 |
1 Debe utilizar Azure Government ExpressRoute, non a nube comercial de Azure ExpressRoute.
2 Debe utilizar Azure China 21Vianet ExpressRoute, non a nube comercial de Azure ExpressRoute.
Custos de Azure ExpressRoute
Para determinar o caso de negocio con precisión, recorda incluír os custos de Azure, os custos do provedor de conectividade e os custos do esforzo de configuración interna cando estimes os custos de ExpressRoute para Power Platform.
Custos de Azure
Azure ExpressRoute pódese mercar en diferentes modelos. O modelo que elixas depende do tipo de conexión que queiras establecer e dos servizos aos que queres acceder.
Tipo de facturación
- Pago por uso: un custo de subscrición base ao mes con tráfico de entrada ilimitado pero un cargo por GB para o tráfico de saída
- Ilimitado: un custo de subscrición base por mes con tráfico de entrada e saída ilimitado
SKU / Plan
Estándar
- Conexión básica mediante ExpressRoute
- Ofrece acceso a servizos dentro dunha única rexión xeográfica
Se o circuíto ExpressRoute está na mesma rexión que o Power Platform entorno ao que se conectan os usuarios, só se require o estándar ExpressRoute para ese circuíto.
Prémium
- Ofrece acceso a servizos xeográficos mundiais desde calquera lugar onde se realice a conexión
Se un usuario se conecta a través dun circuíto ExpressRoute desde unha rexión diferente do seu servizo final, necesitará ExpressRoute Premium para ese circuíto.
Obtén máis información en Azure ExpressRoute prezos.
Custos do fornecedor de conectividade
Nalgúns casos, os custos de establecer a conexión co provedor de conectividade poden ser significativos. Estes custos están separados dos custos de Azure para ExpressRoute.
Esforzo interno do cliente para configurar o enrutamento de rede
Para usar ExpressRoute, o enrutamento de rede debe estar configurado internamente. Para moitos clientes, este esforzo require unha carga cruzada interna para o equipo de rede, un custo externo para un provedor de subcontratación de TI ou, polo menos, un custo de oportunidade para os esforzos do persoal interno para centrarse na configuración.
Impactos nos servizos existentes Power Platform, Microsoft 365 e Azure
Cando utilizas o peering de Microsoft, o tráfico para Power Platform servizos, Microsoft 365 e Azure envíase por defecto a través de ExpressRoute. Se xa utilizas Power Platform, aplicacións de Dynamics 365 ou Microsoft 365 sen ExpressRoute, é importante ter en conta o impacto destes servizos existentes cando permites que Microsoft a interacción con ExpressRoute. Pode ser necesario configurar o enrutamento mediante comunidades BGP para separar o tráfico a diferentes servizos.
Reutilización de ExpressRoute en varios servizos en liña
Pódese usar unha única conexión ExpressRoute para acceder a varios servizos en liña, como Power Platform, Dynamics 365, Microsoft 365 e Azure.
Diagrama que mostra unha conexión ExpressRoute compartida cos servizos públicos de Microsoft e Azure. O peering de Microsoft para Microsoft 365, Power Platform, Dynamics 365 e os servizos públicos de Azure comparten a mesma conexión ExpressRoute co peering privado de Azure para redes virtuais.
ExpressRoute non separa diferentes tipos de servizos de Microsoft dunha subrede determinada. É posible usar etiquetas da comunidade BGP para controlar o encamiñamento do tráfico a servizos particulares a través de ExpressRoute. Microsoft non devolve o tráfico a través de ExpressRoute de xeito selectivo baseándose nas etiquetas da comunidade BGP. Se hai que devolver o tráfico de forma diferente en función do tipo de servizo, asegúrese de que o tráfico provén de diferentes enderezos IP públicos. Dado que o tráfico que regresa a unha subrede se xestiona a nivel de rede, configurar só parte do tráfico dunha subrede para usar ExpressRoute é perigoso e pode levar a un enrutamento asimétrico.