Planeje uma implantação do ExpressRoute para uso com o Microsoft Power Platform
Agora que você decidiu usar o ExpressRoute para o Microsoft Power Platform, é importante planejar a implantação para atender às suas necessidades e ambiente.
Pré-requisitos do ExpressRoute
A configuração do ExpressRoute requer que vários pré-requisitos sejam considerados e configurados. Isso pode gerar custos e atividades inesperados que, se não planejados, poderão afetar o projeto e a operação contínua de outros serviços.
Pré-requisitos externos
O ExpressRoute não fornece a conexão física em si; ele fornece a conectividade privada por meio de uma conexão física já estabelecida. A conectividade física deve ser configurada antes por um provedor de conectividade. Essa conectividade pode ser estabelecida de várias maneiras com os parceiros existentes do ExpressRoute. A documentação do ExpressRoute fornece explicações detalhadas sobre as opções e os parceiros disponíveis atualmente.
Como parte do planejamento, você precisará considerar o seguinte:
Geografia: Como discutiremos com mais detalhes posteriormente, entender geograficamente de onde uma ou mais conexões precisam ser feitas afetará seu planejamento geral.
Custo: O provedor de conectividade cobrará pelo estabelecimento da conexão privada. Esse custo pode ser significativo, e variará dependendo do tipo e da quantidade de conexões necessárias.
Tempo de configuração: Em alguns casos, será necessário configurar o hardware físico. Esse tempo de configuração precisará ser incluído no cronograma de implementação.
Configuração habilidades e recursos: A maior parte da complexidade da configuração está na configuração do roteamento interno na sua rede. É essencial garantir que pessoas qualificadas estejam disponíveis para fazer isso.
Microsoft pré-requisitos
Depois que a conectividade física estiver estabelecida, você poderá prosseguir com a configuração das conexões do ExpressRoute propriamente ditas. Isso exigirá:
Uma assinatura do Azure para provisionar e cobrar os circuitos do ExpressRoute.
Configuração na assinatura do Azure dos circuitos do ExpressRoute, que é feita por meio das ferramentas do Azure.
Planejamento da configuração de roteamento para tráfego do Microsoft Power Platform pelo ExpressRoute
Ao planejar o roteamento de tráfego do Microsoft Power Platform, você precisará considerar os diversos tipos de tráfego, que dependem de como você configurou e usou o Microsoft Power Platform.
Para entender como configurar o ExpressRoute para o Microsoft Power Platform, você precisará considerar os diferentes usos e conexões de e para o Microsoft Power Platform, que dependem dos serviços e recursos que você usa.
Configuração de roteamento
A configuração de roteamento é feita pelo provedor de conectividade ou pelo cliente, dependendo do tipo de conexão fornecido.
Embora a conexão do ExpressRoute em si seja entre data centers, a conexão de rede real é, em grande parte, dos dispositivos clientes do usuário (que geralmente serão distribuídos em uma WAN mais ampla, por exemplo, agências bancárias distribuídas). Isso significa que as conexões são roteadas do local do dispositivo cliente através da WAN até o data center e, depois, através do circuito do ExpressRoute. Isso exige uma configuração cuidadosa. A WAN deve ser configurada de modo que:
A rota por meio da sub-rede da rede seja configurada para o ExpressRoute.
or
Seja dada preferência ao circuito de failover em relação à conexão pública com a Internet para o Microsoft Power Platform.
Portanto, é importante identificar quais sub-redes dentro de sua rede devem ser os alvos para as conexões de sessão principal e de fallback do Border Gateway Protocol (BGP), a fim de garantir que os prefixos do Microsoft Power Platform prefiram essa rota. Não é necessário configurar especificamente os serviços em cada extremidade, pois essa configuração é feita por meio do anúncio das sub-redes/prefixos IP através dessa conexão. Quando uma solicitação é iniciada, o algoritmo de roteamento enxerga essa conexão BGP direta como a rota preferencial para tráfego até a sub-rede conectada ao circuito do ExpressRoute, direcionando o tráfego dessa maneira.
Configuração do ExpressRoute para bases de usuários distribuídas
O ExpressRoute foi projetado para fornecer conexões privadas, dedicadas e, portanto, previsíveis do seu ambiente para a Microsoft rede. Quando você tem uma conexão dedicada e direta por meio do provedor de conectividade para Microsoft, você reduz a possibilidade de ter que lidar com outro tráfego nas conexões que você compartilha por meio da rede do provedor de conectividade. Não deveria ser necessário usar o ExpressRoute para obter essa qualidade de conexão por meio de um provedor de conectividade, mas é uma maneira de ajudar a garantir isso.
No exemplo a seguir, um usuário em uma filial tem sua conexão roteada via WAN para a conexão do data center do cliente com o ExpressRoute.
Quando um cliente tem uma rede de usuários amplamente distribuída, como uma rede de filiais de escritórios distribuídos em um país/região, o tráfego da rede precisa ser conectado de maneira eficiente de várias localizações distribuídas geograficamente. O padrão típico para isso é rotear coisas através da WAN para a rede local conectada ao ExpressRoute, conforme mostrado na imagem a seguir.
Se a conexão entre o cliente e o ExpressRoute for ruim, saturada ou ineficiente de alguma outra forma, o ExpressRoute não conseguirá resolver isso, porque os problemas de conexão para chegar ao ponto de entrada do ExpressRoute ainda afetarão a experiência do usuário. Em um caso como esse, você deve considerar usar o ExpressRoute Direct, que lhe dá a capacidade de se conectar diretamente à rede global do Microsoft.
Ao se conectar a serviços de nuvem e sofrer limitações por conexões WAN desafiadoras, pode ser benéfico estabelecer fugas locais da Internet a partir de filiais locais. Isso evitará a conexão WAN mais lenta e aproveitará o alcance do provedor de conectividade para obter uma conexão mais direta com o serviço de nuvem.
É possível configurar circuitos do ExpressRoute de vários locais, e até mesmo para filiais individuais, através de uma fuga local da Internet, conforme mostrado na imagem a seguir.
A abordagem de conectar filiais a um datacenter central por meio de uma WAN e estabelecer circuitos ExpressRoute entre o cliente e os datacenters é normalmente preferível e mais prática do que tentar estabelecer uma conexão ExpressRoute de cada filial. Microsoft Isso seria relativamente caro e complicado de configurar e manter, caso fosse necessário em muitos locais.
Uma abordagem alternativa é conectar todas as filiais e o data center do cliente na mesma VPN IP e fazer com que o provedor de serviços de VPN IP se conecte a um local do ExpressRoute. Microsoft
Se você enfrenta desafios com uma conexão WAN local, normalmente é melhor otimizar, por meio de métodos como ganhar largura de banda adicional ou otimizar o roteamento, em vez de tentar estabelecer uma conexão do ExpressRoute a partir de cada local.
Para redes distribuídas em uma ampla área geográfica, pode ser valioso ter vários hubs conectados ao ExpressRoute para minimizar o número de conexões do ExpressRoute necessárias e, ao mesmo tempo, oferecer um ponto de conexão mais local para cada usuário. Nesse caso, é importante garantir que IPs públicos exclusivos sejam publicados por meio de cada circuito do ExpressRoute. Cada uma dessas sub-redes deve ser distinta, o que requer que você tenha a mesma quantidade de sub-redes voltadas para o público e conexões do ExpressRoute.
Isso é particularmente benéfico se diferentes áreas operacionais estiverem localizadas em áreas geográficas muito diferentes, ou se a conectividade de rede entre as áreas for limitada e uma conexão mais direta puder ser estabelecida para cada uma delas. Microsoft
Também é possível que regiões diferentes tenham requisitos de privacidade diferentes, e não é necessário que todas as regiões usem o ExpressRoute simplesmente porque uma usa. É possível que algumas conexões sejam roteadas diretamente pela Internet e outras por meio do ExpressRoute, conforme mostrado na imagem a seguir.
O ExpressRoute (padrão) oferece conectividade apenas dentro de uma região geográfica específica. É necessário usar o ExpressRoute Premium para oferecer acesso multigeográfico de um único ponto de conexão do ExpressRoute. Isso seria relevante se, por exemplo, um cliente tivesse escritórios nos Estados Unidos e escritórios na Europa, todos usando um único ambiente do Microsoft Power Platform. Se o locatário do Microsoft Power Platform do cliente está implantado nos Estados Unidos, seu circuito do ExpressRoute na Europa precisa ser o SKU Premium. Se o locatário do Microsoft Power Platform está na Europa, o circuito dos EUA precisa ser Premium.
Como evitar roteamento assimétrico
Um desafio a ser observado é o roteamento assimétrico, onde a configuração de roteamento dentro da rede do cliente roteia o tráfego para o datacenter diretamente pela internet, mas então o tráfego de retorno determina que as respostas devem ser roteadas por meio de um circuito ExpressRoute. Microsoft Isso geralmente pode fazer com que um firewall rejeite o tráfego, porque ele recebe pacotes de resposta sem ter enviado os pacotes de solicitação.
Isso pode acontecer se a rede local de um cliente determinar que o roteamento mais eficiente para serviços em nuvem é pela Internet pública em vez da WAN para o circuito privado ExpressRoute. Microsoft Mas se o endereço IP do cliente for um endereço IP público ou for traduzido por meio de mapeamentos NAT para um endereço IP público anunciado por meio do ExpressRoute, a rota mais eficiente de volta para esse IP provavelmente será por meio da sessão BGP pelo ExpressRoute. Você pode usar IPs NAT diferentes na sua borda da Internet e na borda do ExpressRoute. Com um endereço de origem distinto, o tráfego de retorno voltará inequivocamente para a mesma borda.
Isso também pode acontecer nas situações em que há vários circuitos do ExpressRoute configurados para o mesmo cliente com roteamento de tráfego de saída por meio de um circuito, mas roteamento de retorno por outro, caso em que as verificações de firewall podem bloquear o tráfego pelo caminho de retorno. Para evitar o roteamento assimétrico por circuitos do ExpressRoute diferentes para os caminhos de saída e entrada, é importante garantir que IPs públicos exclusivos sejam publicados em cada circuito.
Como você pode ver, é importante determinar como o roteamento é gerenciado dentro da sua WAN e garantir que os caminhos de e para os serviços de nuvem sejam cuidadosamente considerados. Microsoft
Conectividade externa de/para o Microsoft Power Platform
Ao realizar conexões com o Microsoft Power Platform de locais do cliente, há vários tipos de tráfego a serem considerados. Isso pode levar a ambos os tipos de peering, Microsoft e peering privado, e o mesmo circuito ExpressRoute pode ser usado para esses tipos de peering, conforme mostrado na imagem a seguir.
Existem diferentes tipos de conexão que existem entre os serviços do Microsoft Power Platform e uma rede externa. Por exemplo, a conectividade do Exchange Web Services usando sincronização do lado do servidor usa o ExpressRoute para passar tráfego de rede da Microsoft rede para a rede do cliente. A conectividade de serviços da Web usa o ExpressRoute para tráfego de entrada e saída para a rede. Microsoft Para o cliente HTTPS, a conexão ExpressRoute é usada para acesso da rede do cliente à Microsoft rede. A imagem a seguir ilustra esses exemplos.
Tráfego de saída (tráfego de serviços do Microsoft Power Platform)
Vários tipos de tráfego de saída podem ocorrer diretamente de serviços do Microsoft Power Platform para serviços de atendimento ao cliente. Para cada um deles, é importante observar que o SAC deve ser publicamente endereçável com um IP público que pode ser resolvido por meio de DNS público pelos serviços do Microsoft Power Platform.
Este endereço IP também precisa ser anunciado Microsoft por meio do ExpressRoute para que o roteamento de rede interna dentro dos Microsoft Power Platform serviços saiba como roteá-lo por meio dessa conexão ExpressRoute.
Os serviços do Microsoft Power Platform não podem especificar qual instância de serviço ou organização do cliente pode fazer solicitações para quais endereços IP. Portanto, é importante tratar as solicitações de entrada para a rede corporativa como se fossem da Internet e protegê-las como tal.
A tabela a seguir descreve o tráfego de saída de serviços do Microsoft Power Platform.
| Descrição | Tipo de tráfego e direção | Tipo de emparelhamento | Finalidade |
|---|---|---|---|
| Serviços Web | Saída HTTPS de serviços do Microsoft Power Platform | Microsoft olhando Publicar serviços Web em endereços IP públicos que estão dentro de sub-redes configuradas para ExpressRoute |
Plug-ins personalizados e atividades de fluxo de trabalho podem realizar solicitações de serviço Web para serviços externos |
| Integração do Exchange: modo híbrido | Saída HTTPS de serviços do Microsoft Power Platform | Microsoft olhando Os serviços Web precisam ser publicados em endereços IP públicos que estão dentro de sub-redes configuradas para ExpressRoute |
Solicitações de serviços Web do Exchange da sincronização no servidor para implantações híbridas (serviços do Microsoft Power Platform, Exchange local) |
| Conectores | Entrada HTTPS de serviços do Microsoft Power Platform | Microsoft olhando | Solicitações de serviços do Microsoft Power Platform por meio do serviço de gerenciamento de API do Azure via conectores usando o gateway de dados local |
| Retransmissão do Azure | Saída HTTPS de serviços do Microsoft Power Platform | Microsoft olhando Publicar serviços Web em endereços IP públicos que estão dentro de sub-redes configuradas para ExpressRoute |
Conectividade direta entre os fluxos de nuvem do Power Automate e fluxos de desktop |
Tráfego de entrada (tráfego para serviços do Microsoft Power Platform)
O tráfego de entrada a seguir é possível para serviços do Microsoft Power Platform a partir da rede do cliente.
| Descrição | Tipo de tráfego e direção | Tipo de emparelhamento | Finalidade |
|---|---|---|---|
| Conectividade do cliente | Entrada HTTPS para serviços do Microsoft Power Platform | Microsoft olhando Conexão direta com a Internet para conteúdo estático oferecido pela Rede de Distribuição de Conteúdo do Azure |
Solicitações de clientes para interface do usuário de serviços da Microsoft Power Platform |
| Serviços Web | Entrada HTTPS para serviços do Microsoft Power Platform | Microsoft olhando | Solicitações para serviços do Microsoft Power Platform por meio de APIs de serviço Web (SOAP, API Web). De um aplicativo cliente padrão ou personalizado |
| Conectores | Entrada HTTPS para serviços do Microsoft Power Platform | Microsoft olhando | Respostas de volta para serviços do Microsoft Power Platform por meio dos APIMs via conectores usando o gateway de dados local |
Conectividade de nuvem interna dentro de serviços do Microsoft Power Platform
Microsoft Power Platform os serviços usam e se integram com vários outros Microsoft serviços online hospedados no Microsoft 365 e no Azure.
| Descrição | Tipo de tráfego e direção | Finalidade |
|---|---|---|
| Integração do Exchange | Saída HTTPS para o Microsoft 365 | Solicitações de serviço Web do Exchange para o Exchange Online da sincronização no servidor |
| Integração do SharePoint | Saída HTTPS para o Microsoft 365 | Solicitações de serviço Web do SharePoint para o SharePoint Online de serviços do Microsoft Power Platform |
| Barramento de Serviço | Saída HTTPS para o Barramento de Serviço do Azure | Enviar eventos por push para o Barramento de Serviço do Azure como registro de evento padrão ou de plug-ins personalizados e atividades de fluxo de trabalho |
| Sincronização de dados | Entrada HTTPS do Azure | Solicitações de controle de alterações de entrada para sincronização de serviços de dados, incluindo pesquisa/offline/insight do cliente |
| Autenticação | Saída HTTPS para o Microsoft Entra | A maior parte da autenticação é feita por meio de redirecionamentos passivos e tokens de declarações, mas alguns dados são sincronizados diretamente no Microsoft Entra ID |
| Fluxos de dados | Saída HTTPS para o Azure Data Lake Storage | Fornece recursos de análise e permite acesso a soluções de big data incorporando dados de serviços do Microsoft Power Platform e outras fontes, além de insights resultantes de análises. |
| Conectores | Saída HTTPS para serviços de PaaS do Azure | Conexões com vários serviços de PaaS do Azure |
| Desktop flows | Saída HTTPS para Azure Relay | Conectividade direta entre os fluxos de nuvem do Power Automate e os fluxos de área de trabalho criados no Power Automate para área de trabalho |
A conectividade real entre esses serviços, hospedados em assinaturas do Azure ou do cliente, é gerenciada por Microsoft . Microsoft O ExpressRoute não se aplica a conexões com esses serviços.
Nos casos em que eventos são enviados por push para o barramento de serviço, a conectividade entre os serviços do Microsoft Power Platform e o Azure é tratada internamente. Separadamente, o cliente pode fazer solicitações ao Service Bus para recuperar informações, e isso pode ser gerenciado por meio de Microsoft peering.
Conectividade de nuvem pública e privada do cliente de/para serviços do Microsoft Power Platform
Os serviços do Microsoft Power Platform também permitem integração direta com recursos públicos ou privados do Azure:
De fontes externas, usando as APIs de serviços Web do Microsoft Dataverse.
Para fontes externas, usando solicitações de serviço Web feitas.
Para fontes externas, usando conectores.
As implicações disso precisam ser consideradas no roteamento do ExpressRoute.
| Descrição | Tipo de tráfego e direção | Tipo de emparelhamento | Finalidade |
|---|---|---|---|
| Portais | Entrada HTTPS para o Azure | Interno para o data center, com exceção de conteúdo estático, que usa a Rede de Distribuição de Conteúdo. A Rede de Distribuição de Conteúdo não é compatível com o ExpressRoute, por isso o conteúdo estático viajará pela Internet pública. | Hospedar serviços voltados ao público. Pode haver cenários em que os funcionários internos podem acessar esses recursos, então pode ser desejável que o tráfego viaje pelo ExpressRoute em vez da Internet pública |
| Caminho de Aprendizado | Entrada HTTPS para o Azure | Usa a Rede de Distribuição de Conteúdo, que não é compatível com o ExpressRoute, por isso o conteúdo viajará pela Internet pública | Esse tráfego é hospedado em um serviço voltado ao público, pois não contém dados confidenciais do cliente. Para fins de previsibilidade, pode haver cenários em que você deseja rotear esse tráfego via ExpressRoute |
| Barramento de Serviço | Entrada HTTPS para o Barramento de Serviço do Azure | Interno para o data center | Extrair eventos do Barramento de Serviço do Azure que foram colocados nele como registro de evento padrão ou de plug-ins personalizados ou atividades de fluxo de trabalho |
| Solicitações de serviço Web | Entrada de IaaS/PaaS do Azure | Interno para o data center | Os clientes podem hospedar aplicativos personalizados no Azure e realizar solicitações de serviços Web do Microsoft Power Platform |
| Solicitações de serviço Web | Saída para IaaS/PaaS do Azure | Interno para o data center | Os clientes podem implementar plug-ins personalizados e atividades de fluxo de trabalho que realizam solicitações de serviços hospedados do Azure |
| Fluxos de dados | Conexões de dados com o Azure Data Lake Storage | Interno para o data center | Fornecer recursos de análise e permitir acesso a soluções de big data incorporando dados de serviços do Microsoft Power Platform e outras fontes, além de insights resultantes das análises. |
| Azure Data Lake | Conexões de dados com o Azure Data Lake Storage | Interno para o data center | Fornecer recursos de análise e permitir acesso a soluções de big data incorporando dados de serviços do Microsoft Power Platform e outras fontes, e os insights resultantes das análises. |
| SQL do Azure | Conexões de dados com serviços SQL do Azure | Interno para o data center | Com recursos como Exportar para data warehouse, o uso de uma instância de SQL do Azure para manter réplicas de dados do Microsoft Dataverse para fins de relatório ou replicação aumentará. Pode ser valioso proteger as conexões com esses recursos por ExpressRoute. |
Pode haver outros serviços públicos no futuro que se conectam internamente ao data center à medida que outros recursos do Azure são usados.