本文探讨了在 Azure 中使用私有终结点访问 Cosmos DB 复制的方案。文章指出，当使用私有终结点时，由于 Cosmos DB 帐户在“主”区域创建，而私有终结点连接到主区域的虚拟网络，因此当主区域离线时，客户端如何重定向到其他副本，或者当工作负载存在于多个区域时，远程部署如何连接到本地 Cosmos DB 副本是一个问题。作者通过模拟实验，演示了使用私有终结点连接到不同区域的 Cosmos DB 复制，并分析了 DNS 配置的复杂性。文章最后建议，在使用全局共享的私有 DNS 区域的情况下，需要手动配置 DNS 记录，以便在不同区域的客户端之间实现无缝的故障转移和访问.

🎯 **问题：** 当使用私有终结点访问 Cosmos DB 复制时，当主区域离线或工作负载存在于多个区域时，如何确保客户端能够连接到本地或远程副本？

🎯 **解决方案：** 使用私有终结点连接到不同区域的 Cosmos DB 复制时，需要创建私有 DNS 区域，并手动配置 DNS 记录，以便在不同区域的客户端之间实现无缝的故障转移和访问。

🎯 **DNS 配置：** 每个区域的私有终结点都应该注册到相应的私有 DNS 区域，并配置 DNS 记录，确保全局帐户 FQDN 解析到主区域，每个区域的 FQDN 解析到该区域的私有终结点。

🎯 **注意事项：** 如果使用全局共享的私有 DNS 区域，则无法使用 DNS 区域配置功能自动注册私有终结点，需要手动配置 DNS 记录。

🎯 **结论：** 使用私有终结点访问 Cosmos DB 复制需要仔细规划 DNS 配置，以确保在不同区域的客户端之间实现无缝的故障转移和访问。

This post explains how to make Cosmos DB replicas available using Private Endpoint.

The Problem

A lot of (most) Azure documentation and community content assumes that PaaS resources will be deployed using public endpoints. Some customers have the common sense not to use public endpoints – who wants to be a zero-day target for well-armed attackers?!

Cosmos DB is a commonly considered database for born-in-the-cloud workloads. One of the cool things about Cosmos DB is the ability to use any number of globally dispersed read-only or write replicas with pretty low replication latency.

But there is a question – what happens if you use Private Endpoint? The Cosmos DB account is created in a “primary” region. That Private Endpoint connects to a virtual network in the primary region. If the primary region goes offline (it does happen!) then how will clients redirect to another replica? Or if you are building a workload that will exist in many regions, how will a remote footprint connection to the local Cosmos DB replica?

I googled and landed on a Microsoft forum post that asked such a question. The answer was (in short) “The database will be available, how you connect to it is your and Azure Network’s problem”. Very helpful!

Logically, what we want is:

What I Figured Out

I’ve deployed some Cosmos DB using Private Endpoint as code (Terraform) in the recent past. I noticed that the DNS configuration was a little more complex than you usually find – I needed to create a Private DNS Zone for:

The Cosmos DB service typeEach Azure region that the replica exists in for that service type

I fired up a lab to simulate the scenario. I created Cosmos DB account in North Europe. I replicated the Cosmos DB account to East US. I created a VNet in North Europe and connected the account to the VNet using a Private Endpoint.

Here’s what the VNet connected devices looks like:

As you can see, the clients in/peered with the North Europe VNet can access their local replica and the East US replica via the local Private Endpoint.

I created a second VNet in East US. Now the important bit: I connected the same Cosmos Account to the VNet in East US. When you check out the connected devices in the East US VNet then you can see that clients in/peered to the North America VNet can connect to the local and remote replica via the local Private Endpoint:

DNS

Let’s have a look at the DNS configurations in Private Endpoints. Here is the one in North Europe:

If we enable the DNS zone configuration feature to auto-register the Private Endpoint in Azure Private DNS, then each of the above FQDNs will be registered and they will resolve to the North Europe NIC. Sounds OK.

Here is the one in East US:

If we enable the DNS zone configuration feature to auto-register the Private Endpoint in Azure Private DNS, then each of the above FQDNs will be registered and they will resolve to the East US NIC. Hmm.

If each region has its own Private DNS Zones then all is fine. If you use Private DNS zones per workload or per region then you can stop reading now.

But what if you have more than just this workload and you want to enable full name resolution across workloads and across regions? In that case, you probably (like me) run central Private DNS Zones that all Private Endpoints register with no matter what region they are deployed into. What happens now?

Here I have set up a DNS zone configuration for the North Europe Private Endpoint:

Now we will attempt to add the East US Private Endpoint:

Uh-oh! The records are already registered and cannot be registered again.

WARNING: I am not a Cosmos DB expert!

It seems to me that using the DNS Zone configuration feature will not work for you in the globally shared Private DNS Zone scenario. You are going to have to configure DNS as follows:

The global account FQDN will resolve to your primary region.The North Europe FQDN will resolve to the North Europe Private Endpoint. Clients in North Europe will use the North Europe FQDN.The East US FQDN will resolve to the East US Private Endpoint. Clients in East US will use the East US FQDN.

This means that you must manage the DNS record registrations, either manually or as code:

Register the account record with the “primary” resource/Private Endpoint IP address: 10.1.04.Register the North Europe record with the North Europe Private Endpoint IP: 10.1.0.5.Register the East US record with the East US Private Endpoint IP: 10.2.0.6.

This will mean that clients in one region that try to access another region (via failover) will require global VNet peering and NSG/firewall access to the remote Private Endpoint.

The post Cosmos DB Replicas With Private Endpoint first appeared on Aidan Finn, IT Pro.