Planear uma implementação do ExpressRoute a utilizar com o Microsoft Power Platform
Agora que decidiu usar o ExpressRoute para o Microsoft Power Platform, é importante planear a implementação para ajudar às suas necessidades e ambiente.
Pré-requisitos do ExpressRoute
A criação do ExpressRoute requer que sejam considerados e configurados vários pré-requisitos. Estes podem levar a custos e atividades inesperados, que se não forem previstos podem afetar o projeto e o funcionamento contínuo de outros serviços.
Pré-requisitos externos
O ExpressRoute não fornece a ligação física em si; proporciona a conectividade privada sobre uma conexão física já estabelecida. A conectividade física deve primeiro ser criada por um fornecedor de conectividade. Existem várias formas de estabelecer esta conectividade com os parceiros ExpressRoute existentes. A documentação do ExpressRoute fornece explicações detalhadas sobre as opções e os parceiros atualmente disponíveis.
Como parte do planeamento, terá de ter em conta o seguinte:
Geografia: Como discutiremos mais detalhadamente mais adiante, entender geograficamente de onde uma ou mais conexões precisam ser feitas afetará seu planeamento geral.
Custo: O provedor de conectividade cobrará pelo estabelecimento da conexão privada. Isto pode ser um custo significativo; variará dependendo do tipo e número de ligações necessárias.
Tempo de configuração: Em alguns casos, o hardware físico precisará ser configurado. Este tempo de configuração terá de ser incorporado no calendário de implementação.
capacidades e recursos de configuração: a maior parte da complexidade da configuração reside na configuração do roteamento interno em sua rede. É essencial que garanta que pessoas qualificadas estão disponíveis para fazer isto.
Microsoft Pré-requisitos
Depois de a conectividade física estar no lugar, pode proceder com a configuração das ligações do ExpressRoute propriamente ditas. Esta operação irá requerer:
Uma subscrição do Azure dentro da qual aprovisionar e faturar os circuitos do ExpressRoute.
Configuração dentro da subscrição do Azure dos circuitos do ExpressRoute, que é feita através das ferramentas do Azure.
Planear a configuração de encaminhamento para o tráfego do Microsoft Power Platform através do ExpressRoute
Ao planear o encaminhamento de tráfego do Microsoft Power Platform, terá de ter em conta os vários tipos de tráfego, que dependem da forma como configurou e utilizou o Microsoft Power Platform.
Para entender como configurar o ExpressRoute para o Microsoft Power Platform, terá de considerar as diferentes utilizações e ligações de e para o Microsoft Power Platform, que dependem dos serviços e funcionalidades que utiliza.
Configuração de encaminhamento
A configuração de encaminhamento é feita pelo fornecedor de conectividade ou pelo cliente, dependendo do tipo de ligação fornecido.
Embora a ligação ExpressRoute em si seja entre datacenters, a ligação real da rede é maioritariamente a partir dos dispositivos clientes do utilizador (que muitas vezes serão distribuídos por um WAN mais amplo, por exemplo, agências bancárias distribuídas). Isto significa que as ligações são encaminhadas da localização do dispositivo cliente através de WAN para o datacenter e, em seguida, através do circuito do ExpressRoute. Isto requer configuração cuidadosa. O WAN deve ser criado de modo a que:
O caminho através da subrede da rede esteja configurado para o ExpressRoute.
or
O circuito de ativação pós-falha seja escolhido como preferência em vez da ligação pública à Internet para o Microsoft Power Platform.
Por isso, é importante identificar que subredes dentro da sua rede devem ser o destino das ligações de sessão do Protocolo BGP (BGP) principais e de contingência, para garantir que os prefixos do Microsoft Power Platform preferem esse caminho. Não é necessário configurar especificamente os serviços em cada extremidade, porque esta configuração é feita através da publicidade das subredes/prefixos IP através desta ligação. Quando um pedido é iniciado, o algoritmo de encaminhamento vê essa ligação BGP direta como o caminho preferido para o tráfego para a subrede ligada ao circuito do ExpressRoute e direciona o tráfego dessa forma.
Configurar o ExpressRoute para bases de utilizadores distribuídas
O ExpressRoute foi projetado para fornecer conexões privadas, dedicadas e, portanto, previsíveis do seu ambiente à Microsoft rede. Quando você tem uma conexão dedicada e direta através do provedor de Microsoft conectividade, você reduz o potencial de ter que lidar com outro tráfego nas conexões que você compartilha através da rede do provedor de conectividade. Não deve ser necessário usar o ExpressRoute para alcançar esta qualidade de ligação através de um fornecedor de conectividade, mas é uma forma de ajudar a garantir isso.
No exemplo seguinte, um utilizador numa sucursal tem a sua ligação encaminhada através de WAN para a ligação do datacenter do cliente ao ExpressRoute.
Quando um cliente tem uma rede de utilizadores altamente distribuída, como uma rede de balcões distribuídos por um país/região, o tráfego de rede precisa de ser ligado eficientemente a partir de múltiplos locais altamente distribuídos geograficamente. O padrão típico para isso é encaminhar através de WAN para a rede local ligada ao ExpressRoute, como mostra a imagem seguinte.
Se a ligação entre o cliente e o ExpressRoute for fraca ou for saturada ou ineficiente de outra forma, o ExpressRoute não será capaz de resolver isto, porque os problemas de ligação na entrada do ExpressRoute continuarão a afetar a experiência do utilizador. Em um caso como este, você deve considerar o uso do ExpressRoute Direct, que lhe dá a capacidade de se conectar diretamente à Microsoft rede global do Express.
Quando ligar a serviços cloud e for limitado por desafiar ligações WAN, pode ser benéfico estabelecer fugas de Internet locais a partir de agências locais. Isto evitará a ligação WAN mais lenta e aproveitará o alcance do fornecedor de conectividade para obter uma ligação mais direta ao serviço cloud.
É possível configurar circuitos do ExpressRoute a partir de vários locais e, até mesmo para sucursais individuais, através de uma fuga de Internet local, como mostra a imagem seguinte.
A abordagem de conectar filiais a um datacenter central por meio de uma WAN e estabelecer circuitos de Rota Expressa entre o cliente e Microsoft os datacenters é normalmente preferível e mais prática do que tentar estabelecer uma conexão de Rota Expressa a partir de cada local de filial. Isso seria relativamente dispendioso e complicado de configurar e manter, se tal fosse necessário em muitos locais.
Uma abordagem alternativa é conectar todas as filiais e datacenter do cliente na mesma VPN IP e fazer com que o provedor de serviços de VPN IP se conecte em um local da Rota Expressa Microsoft .
Se tem desafios com uma ligação WAN local, é normalmente melhor otimizar isso, através de métodos como ganhar obter largura de banda adicional ou otimizar o encaminhamento, em vez de tentar estabelecer uma ligação ExpressRoute a partir de cada localização.
Para as redes que são distribuídas por uma vasta área geográfica, pode ser valioso ter vários hubs ligados ao ExpressRoute para minimizar o número de ligações ExpressRoute necessárias, oferecendo ainda um ponto de ligação mais local para cada utilizador. Neste caso, é importante garantir que os IPs públicos exclusivos sejam publicados através de cada circuito ExpressRoute; cada uma destas subredes tem de ser distinta, o que requer que tenha tantas subredes publicamente viradas quantas as ligações ExpressRoute.
Isto é 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 puder ser estabelecida uma ligação mais direta para Microsoft cada uma delas.
Também é possível que diferentes regiões tenham diferentes requisitos de privacidade e não é necessário que todas as regiões utilizem ExpressRoute simplesmente porque o tem. Pode ser possível que algumas ligações sejam encaminhadas diretamente através da Internet e outras através do ExpressRoute, como mostra a imagem seguinte.
O ExpressRoute (padrão) oferece conectividade apenas dentro de uma região geográfica específica; o ExpressRoute Premium é obrigado a oferecer acesso de várias regiões geográficas a partir de um único ponto de ligação ExpressRoute. Isto seria relevante se, por exemplo, um cliente tivesse escritórios sediados nos EUA e na Europa, todos a utilizar um único ambiente do Microsoft Power Platform. Se o inquilino Microsoft Power Platform do cliente estiver implementado nos Estados Unidos, o seu circuito ExpressRoute na Europa tem de ser o SKU Premium. Se o seu inquilino Microsoft Power Platform estiver na Europa, o circuito dos EUA teria de ser o Premium.
Evitar encaminhamento assimétrico
Um desafio a ser observado é o roteamento assimétrico, em que a configuração de roteamento dentro da rede do cliente roteia o tráfego para o Microsoft datacenter diretamente pela Internet, mas o tráfego de retorno determina que as respostas devem ser roteadas por meio de um circuito de Rota Expressa. Isto pode muitas vezes fazer com que uma firewall rejeite o tráfego, porque recebe pacotes de resposta sem ter enviado os pacotes de pedido.
Isso pode acontecer se a rede local de um cliente determinar que o roteamento mais eficiente para Microsoft serviços de nuvem é através da Internet pública em vez de através da WAN para o circuito privado de Rota Expressa. Mas se o endereço IP do cliente for um endereço IP público ou for traduzido através de mapeamentos NAT para um endereço IP público que é anunciado através do ExpressRoute, o caminho mais eficiente de volta a esse IP provavelmente será através da sessão BGP sobre ExpressRoute. Pode utilizar diferentes IPs NAT na sua extremidade de Internet e extremidade ExpressRoute. Com um endereço de origem distinto, o tráfego de regresso voltará inequivocamente para a mesma extremidade.
Isto também pode acontecer quando existem vários circuitos do ExpressRoute configurados para o mesmo cliente com encaminhamento de tráfego de saída através de um circuito, mas o encaminhamento de regresso através de outro onde as verificações de firewall podem bloquear o tráfego através do caminho de regresso. Para evitar o encaminhamento assimétrico através de um circuito do ExpressRoute diferente para os caminhos de saída e de entrada, é importante garantir que os IPs públicos exclusivos sejam publicados em cada circuito.
Como você pode ver, é importante determinar como o roteamento é gerenciado em sua WAN e garantir que os caminhos de e para os serviços de Microsoft nuvem sejam cuidadosamente considerados.
Conectividade externa de/para o Microsoft Power Platform
Ao fazer ligações para o Microsoft Power Platform a partir de localizações do cliente, existem vários tipos de tráfego a considerar. Isso pode levar a tipos Microsoft de emparelhamento e emparelhamento privado, e o mesmo circuito de Rota Expressa pode ser usado para esses tipos de emparelhamento, conforme mostrado na imagem a seguir.
Existem diferentes tipos de ligação que existem entre os serviços do Microsoft Power Platform e uma rede externa. Por exemplo, a conectividade dos Serviços Web do Exchange usando a sincronização do lado do servidor usa a Rota Expressa para passar o tráfego de rede da Microsoft rede para a rede do cliente. A conectividade de serviços da Web usa a Rota Expressa para o tráfego de entrada e de saída para a Microsoft rede. Para o cliente HTTPS, a conexão ExpressRoute é usada para acesso da rede do cliente à Microsoft rede. A imagem seguinte ilustra estes exemplos.
Tráfego de saída (tráfego dos serviços do Microsoft Power Platform)
Vários tipos de tráfego de saída podem ocorrer diretamente dos serviços do Microsoft Power Platform para serviços de cliente. Para cada um destes, é importante notar que o suporte ao cliente tem de ser publicamente endereçável com um IP público que pode ser resolvido através do DNS público pelos serviços do Microsoft Power Platform.
Esse endereço IP também precisa ser anunciado Microsoft por meio da Rota Expressa, para que o roteamento de rede interna dentro Microsoft Power Platform dos serviços saiba roteá-lo por meio dessa conexão de Rota Expressa.
Os serviços do Microsoft Power Platform não podem especificar qual a instância de serviço ou organização do cliente que pode fazer pedidos para que endereços IP. Por isso, é importante tratar os pedidos de entrada na rede corporativa como se fossem da Internet e os proteger como tal.
A tabela seguinte descreve o tráfego de saída dos serviços do Microsoft Power Platform.
| Descrição | Tipo de tráfego e direção | Tipo de peering | Propósito |
|---|---|---|---|
| Serviços Web | HTTPS a sair dos serviços do Microsoft Power Platform | Microsoft emparelhamento Publicar serviços Web em endereços IP públicos que se encontram dentro de subredes configuradas pelo ExpressRoute |
Plug-ins e atividades de fluxo de trabalho personalizados podem fazer pedidos de serviços Web a serviços externos |
| Integração do Exchange: modo híbrido | HTTPS a sair dos serviços do Microsoft Power Platform | Microsoft emparelhamento Serviços Web precisariam de ser publicados em endereços IP públicos que se encontram dentro de subredes configuradas pelo ExpressRoute |
Pedidos de Serviços Web do Exchange a partir da sincronização do lado do servidor para implementações híbridas (serviços do Microsoft Power Platform, Exchange no local) |
| Conectores | HTTPS a entrar nos serviços do Microsoft Power Platform | Microsoft emparelhamento | Pedidos de serviços do Microsoft Power Platform através do serviço de Gestão de API do Azure através de conectores que utilizam o gateway de dados no local |
| Azure Relay | HTTPS a sair dos serviços do Microsoft Power Platform | Microsoft emparelhamento Publicar serviços Web em endereços IP públicos que se encontram dentro de subredes configuradas pelo ExpressRoute |
Conectividade direta entre fluxos de nuvens Power Automate e fluxos de ambiente de trabalho |
Tráfego de entrada (tráfego para os serviços do Microsoft Power Platform)
O seguinte tráfego de entrada é possível para os serviços do Microsoft Power Platform da rede de clientes.
| Descrição | Tipo de tráfego e direção | Tipo de peering | Propósito |
|---|---|---|---|
| Conectividade do cliente | HTTPS a entrar para os serviços do Microsoft Power Platform | Microsoft emparelhamento Ligação direta à Internet para conteúdo estático servido pela Rede de Entrega de Conteúdos do Azure |
IU de pedidos de cliente para serviços do Microsoft Power Platform |
| Serviços Web | HTTPS a entrar para os serviços do Microsoft Power Platform | Microsoft emparelhamento | Pedidos de serviços do Microsoft Power Platform através de APIs de serviço Web (SOAP, API Web). Seja a partir de uma aplicação de cliente padrão ou personalizada |
| Conectores | HTTPS a entrar para os serviços do Microsoft Power Platform | Microsoft emparelhamento | Respostas de volta aos serviços Microsoft Power Platform através dos APIMs via conectores utilizando o gateway de dados no local |
Conectividade Interna da Cloud dentro dos serviços do Microsoft Power Platform
Microsoft Power Platform os serviços usam e integram-se a vários outros Microsoft serviços online hospedados no Azure e no Microsoft 365 Azure.
| Descrição | Tipo de tráfego e direção | Propósito |
|---|---|---|
| Integração do Exchange | HTTPS a sair para o Microsoft 365 | Pedidos de serviço Web do Exchange para o Exchange Online a partir da Sincronização do Lado do Servidor |
| Integração com o SharePoint | HTTPS a sair para o Microsoft 365 | Pedidos de serviço Web do SharePoint para o SharePoint Online a partir de serviços Microsoft Power Platform |
| Barramento de Serviço | HTTPS a sair para o Azure Service Bus | Encaminhe eventos para o Azure Service Bus como registo padrão de eventos ou de plug-ins personalizados e atividades de fluxo de trabalho |
| Sincronização de dados | HTTPS a entrar do Azure | Pedidos de controlo de alterações de entrada para sincronização de serviços de dados, incluindo informações de pesquisa/offline/cliente |
| Autenticação | HTTPS a sair para o Microsoft Entra | A maioria das autenticações é feita através de redirecionamentos passivos e tokens de afirmações, mas alguns dados são sincronizados diretamente com o Microsoft Entra ID |
| Fluxos de Dados | HTTPS a sair para o Azure Data Lake Storage | Fornece capacidades de análise e permite o acesso a soluções de macrodados incorporando dados de serviços Microsoft Power Platform e de outras origens, além das informações resultantes da análise. |
| Conectores | HTTPS a sair para os serviços Azure PaaS | Ligações a vários serviços Azure PaaS |
| Desktop flows | Saída HTTPS para Azure Relay | Conectividade direta entre fluxos de nuvem Power Automate e fluxos de ambiente de trabalho criados em Power Automate para desktop |
A conectividade real entre esses serviços, hospedados em assinaturas do Azure ou do Microsoft cliente, é tratada por Microsoft. O ExpressRoute não se aplica às ligações com estes serviços.
Onde os eventos são empurrados para o Service Bus, a conectividade entre os serviços 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 Microsoft de emparelhamento.
Conectividade em cloud pública e privada de clientes de/para serviços Microsoft Power Platform
Os serviços do Microsoft Power Platform permitem igualmente a integração direta com recursos públicos ou privados do Azure:
A partir de origens externas, utilizando as APIs de serviços Web do Microsoft Dataverse.
Para origens externas, utilizando pedidos de serviço Web feitos.
Para origens externas, utilizando conectores.
As implicações desta situação devem ser consideradas no encaminhamento ExpressRoute.
| Descrição | Tipo de tráfego e direção | Tipo de peering | Finalidade |
|---|---|---|---|
| Portais | HTTPS a entrar para o Azure | Interno ao datacenter, com exceção do conteúdo estático, que utiliza a Rede de Entrega de Conteúdos. (A Rede de Entrega de Conteúdos não é suportada pelo ExpressRoute, pelo que o conteúdo estático viajará através da Internet pública.) | Alojar serviços virados para o público. Pode haver cenários em que os funcionários internos possam aceder a estes recursos, por isso pode querer que o tráfego viaje através do ExpressRoute em vez da Internet pública |
| Percurso de Aprendizagem | HTTPS a entrar para o Azure | Utiliza a Rede de Entrega de Conteúdos, que não é suportada pelo ExpressRoute, pelo que o conteúdo viajará através da Internet pública | Isto é alojado num serviço virado para o público porque não contém dados de clientes privados. Para fins de previsibilidade, pode haver cenários em que pretende encaminhar isto através do ExpressRoute |
| Barramento de Serviço | HTTPS a entrar no Azure Service Bus | Datacenter interno | Obtenha eventos do Azure Service Bus que lá foram colocados como registo padrão de eventos ou de plug-ins personalizados ou atividades de fluxo de trabalho |
| Pedidos de serviço Web | De entrada do Azure IaaS/PaaS | Datacenter interno | Os clientes podem alojar aplicações personalizadas no Azure e fazer pedidos de serviços Web do Microsoft Power Platform |
| Pedidos de serviço Web | Saída para Azure IaaS/PaaS | Datacenter interno | Os clientes podem implementar plug-ins e atividades de fluxo de trabalho personalizados que fazem pedidos de serviços alojados do Azure |
| Fluxos de Dados | Ligações de dados ao Azure Data Lake Storage | Datacenter interno | Forneça capacidades de análise e permita o acesso a soluções de macrodados incorporando dados de serviços Microsoft Power Platform e de outras origens, além das informações resultantes da análise. |
| Azure Data Lake | Ligações de dados ao Azure Data Lake Storage | Datacenter interno | Forneça capacidades de análise e permita o acesso a soluções de macrodados incorporando dados de serviços Microsoft Power Platform e de outras origens e as informações resultantes da análise. |
| Azure SQL | Ligações de dados ao serviços Azure SQL | Datacenter interno | Com capacidades como a Exportação para o Armazém de Dados, a utilização de uma instância do Azure SQL para reter réplicas de dados do Microsoft Dataverse, seja para fins de relatórios ou para fins de replicação, aumentará. Pode ser valioso proteger as ligações a estes recursos sobre o ExpressRoute. |
Pode haver outros serviços públicos no futuro que se liguem internamente ao datacenter à medida que outras capacidades do Azure são utilizadas.