設定進階 Azure Cache for Redis 執行個體的虛擬網路 (VNet) 支援
Azure 虛擬網路部署加強了安全性及隔離性，並提供了子網路、存取控制原則和進一步限制存取的其他功能。 當 Azure Cache for Redis 執行個體以虛擬網路設定後，就無法公開定址。 而只能從虛擬網路內的虛擬機器和應用程式存取此執行個體。 本文說明如何設定進階層 Azure Cache for Redis 執行個體的虛擬網路支援。
注意
傳統部署模型將於 2024 年 8 月淘汰。 如需詳細資訊，請參閱雲端服務 (傳統) 部署模型將於 2024 年 8 月 31 日淘汰。
重要
Azure Cache for Redis 建議使用 Azure Private Link，可簡化網路架構並保護 Azure 中端點之間的連線。 您可以透過私人端點從虛擬網路連線到 Azure Cache 執行個體，而私人端點會在虛擬網路內的子網路中獲派私人 IP 位址。 我們的所有階層都有提供 Azure Private Link，包含 Azure 原則支援服務和簡化的 NSG 規則管理。 若要深入了解，請參閱 Private Link 文件。 若要將 VNet 插入的快取遷移至 Private Link，請參閱從 VNet 插入快取遷移至 Private Link 快取。
VNet 插入的限制
- 建立及維護虛擬網路設定往往容易出錯。 疑難排解也是一項挑戰。 不正確的虛擬網路設定可能會引發問題：
- 來自快取執行個體的計量傳輸受阻
- 複本節點無法從主要節點複寫資料
- 可能遺失資料
- 管理作業 (例如調整) 失敗
- 間歇性或完整的 SSL/TLS 失敗
- 無法套用更新，包括重要的安全性和可靠性改善
- 在最嚴重的情況下，會失去可用性
- 使用 VNet 插入快取時，您必須讓 VNet 保持更新，以允許存取快取相依性，例如證書吊銷清單、公鑰基礎結構、Azure 金鑰保存庫、Azure 儲存體、Azure 監視器等等。
- VNet 插入快取僅適用於進階層 Azure Cache for Redis，不適用於其他階層。
- 您無法將現有的 Azure Cache for Redis 執行個體插入虛擬網路中。 您必須在建立快取時選取此選項。
設定虛擬網路支援
虛擬網路支援是在建立快取時於 [新的 Azure Cache for Redis] 窗格中設定。
若要建立進階層快取，請登入 Azure 入口網站，然後選取 [建立資源]。 您也可以使用 Resource Manager 範本、PowerShell 或 Azure CLI 建立資源。
![顯示 [建立資源] 的螢幕快照。](media/cache-private-link/1-create-resource.png)
在 [新增] 頁面中，選取 [資料庫]。 然後選取 [Azure Cache for Redis]。
在 [新的 Redis 快取] 頁面上，設定新進階層快取的設定。
設定 建議的值 描述 DNS 名稱 輸入全域唯一名稱。 快取名稱必須為介於 1 到 63 個字元之間的字串，而且只能包含數字、字母或連字號。 名稱的開頭和結尾必須是數字或字母，且不可包含連續的連字號。 快取執行個體的主機名稱將是 \<DNS name>.redis.cache.windows.net。訂用帳戶 從下拉式清單中選取訂用帳戶。 這個新的 Azure Cache for Redis 執行個體建立所在的訂用帳戶。 資源群組 從下拉式清單中選取資源群組，或選取 [新建] 並輸入新的資源群組名稱。 這是要建立快取和其他資源的資源群組名稱。 將所有的應用程式資源放在一個資源群組中，您將可輕鬆地一併管理或刪除這些資源。 地點 從下拉式清單中選取位置。 選取其他將使用快取的服務附近的區域。 快取類型 從下拉式清單中選取進階層快取，以設定進階層功能。 如需詳細資訊，請參閱 Azure Cache for Redis 價格。 快取的可用大小、效能和功能取決於定價層。 如需詳細資訊，請參閱 Azure Cache for Redis 概觀。 選取 [網路] 索引標籤，或選取頁面底部的 [網路] 按鈕。
在 [網路] 索引標籤上，選取 [虛擬網路] 為連線方法。 若要使用新的虛擬網路，請先依照使用 Azure 入口網站建立虛擬網路或使用Azure 入口網站建立虛擬網路 (傳統) 中的步驟建立虛擬網路。 然後返回 [新增 Azure Cache for Redis] 窗格，建立並設定您的進階層快取。
重要
當您將 Azure Cache for Redis 部署到 Resource Manager 虛擬網路時，快取必須位於專用子網路中，該子網路只包含 Azure Cache for Redis 執行個體，不包含其他任何資源。 如果您嘗試將 Azure Cache for Redis 執行個體部署到包含其他資源、或已指派 NAT 閘道的 Resource Manager 虛擬網路子網路，則部署會失敗。 失敗的原因是 Azure Cache for Redis 使用的基本負載平衡器與 NAT 閘道不相容。
設定 建議的值 描述 虛擬網路 從下拉式清單中選取虛擬網路。 選取與您的快取位於相同訂閱和位置的虛擬網路。 子網路 從下拉式清單中選取子網路。 子網路的位址範圍應以 CIDR 標記法表示 (例如，192.168.1.0/24)。 其必須包含在虛擬網路的位址空間中。 靜態 IP 位址 (選擇性) 輸入靜態 IP 位址。 如不指定靜態 IP 位址，系統會自動選擇 IP 位址。 重要
Azure 會在每個子網路中保留一些 IP 位址，但這些位址無法使用。 子網路的第一個和最後一個 IP 位址會保留給相容的通訊協定，以及用於 Azure 服務的額外 3 個位址。 如需詳細資訊，請參閱在這些子網路內使用 IP 位址是否有任何限制？
除了 Azure 虛擬網路基礎結構使用的 IP 位址外，子網路中的每個 Azure Cache for Redis 執行個體都會為每個分區使用兩個 IP 位址，為負載平衡器使用一個其他的 IP 位址。 非叢集快取會視為有一個分區。
選取 [下一步: 進階] 索引標籤，或選取頁面底部的 [下一步: 進階] 按鈕。
在進階層快取執行個體的 [進階] 索引標籤中，設定非 TLS 連接埠、叢集和資料持續性的設定。
選取 [下一步: 標記] 索引標籤，或選取頁面底部的 [下一步: 標記] 按鈕。
或者，如果想要分類資源，您可在 [標記] 索引標籤中輸入名稱和值。
選取 [檢閱 + 建立]。 您會移至 [檢閱 + 建立] 索引標籤，其中 Azure 會驗證您的設定。
出現綠色的 [通過驗證] 訊息之後，請選取 [建立]。
建立快取需要一些時間。 您可以在 Azure Cache for Redis 的 [概觀] 頁面上監視進度。 當 [狀態] 顯示為 [執行中] 時，表示快取已可供使用。 建立快取之後，您可以從 [資源] 功能表中選取 [虛擬網路]，以檢視虛擬網路的設定。
Azure Cache for Redis 虛擬網路常見問題
下列清單包含 Azure Cache for Redis 網路相關常見問題的解答。
- Azure Cache for Redis 和虛擬網路有哪些常見的錯誤設定問題？
- 如何確認我的快取在虛擬網路中是否生效？
- 嘗試連線到虛擬網路中的 Azure Cache for Redis 時，為什麼會收到遠端憑證無效的錯誤？
- 虛擬網路可以搭配標準還是基本快取使用？
- 為什麼在有些子網路中建立 Azure Cache for Redis 執行個體會失敗，有些則不會？
- 子網路位址空間需求為何？
- 我可以從對等互連的虛擬網路連線到我的快取嗎？
- 已啟用 Azure Lighthouse 的快取是否支援 VNet 插入？
- 在虛擬網路中裝載快取時，所有快取功能都可以正常運作嗎？
- 已啟用 Azure Lighthouse 的快取是否支援 VNet 插入？
Azure Cache for Redis 和虛擬網路有哪些常見的錯誤設定問題？
在虛擬網路中裝載 Azure Cache for Redis 時，會使用下表中的連接埠。
重要
如果封鎖下表中的連接埠，快取可能無法正常運作。 在虛擬網路中使用 Azure Cache for Redis 時，最常見的錯誤設定問題就是封鎖了一或多個這些連接埠。
輸出連接埠需求
Azure Cache for Redis 需要網路連線需求，才能對快取運作所需的其他相依性服務進行輸出連線，甚至是 Redis 子網內部進行節點間通訊。
| 連接埠 | 方向 | 傳輸通訊協定 | 目的 | 本機 IP | 遠端 IP |
|---|---|---|---|---|---|
| 80、443 | 輸出 | TCP | Redis 相依於 Azure 儲存體、PKI（因特網）、操作系統、基礎結構和防病毒軟體 | (Redis 子網路) | * 4 |
| 443 | 輸出 | TCP | Azure Key Vault 和 Azure 監視器上的 Redis 相依項 | (Redis 子網路) | AzureKeyVault、AzureMonitor 1 |
| 12000 | 輸出 | TCP | Azure 監視器上的 Redis 相依性 | (Redis 子網路) | AzureMonitor 1 |
| 53 | 輸出 | TCP/UDP | DNS 上的 Redis 相依項 (網際網路/虛擬網路) | (Redis 子網路) | 168.63.129.16 和 169.254.169.254 2 和子網路的任何自訂 DNS 伺服器 3 |
| 123 | 輸出 | UDP | NTP 上的作業系統相依性 | (Redis 子網路) | * |
| 1688 | 輸出 | TCP | 啟用的作業系統相依性 | (Redis 子網路) | * |
| 8443 | 輸出 | TCP | Redis 內部通訊 | (Redis 子網路) | (Redis 子網路) |
| 10221-10231 | 輸出 | TCP | Redis 內部通訊 | (Redis 子網路) | (Redis 子網路) |
| 20226 | 輸出 | TCP | Redis 內部通訊 | (Redis 子網路) | (Redis 子網路) |
| 13000-13999 | 輸出 | TCP | Redis 內部通訊 | (Redis 子網路) | (Redis 子網路) |
| 15000-15999 | 輸出 | TCP | Redis 和異地複寫的內部通訊 | (Redis 子網路) | (Redis 子網路) (異地複本對等互連子網路) |
| 6379-6380 | 輸出 | TCP | Redis 內部通訊 | (Redis 子網路) | (Redis 子網路) |
1 您可以使用服務標籤 AzureKeyVault 和 AzureMonitor 搭配 Resource Manager 網路安全性群組 (NSG)。
2 這些 IP 位址為 Microsoft 所擁有，用於定址提供 Azure DNS 服務的主機 VM。
3 沒有自訂 DNS 伺服器的子網路，或可忽略自訂 DNS 的較新 Redis 快取，不需要此資訊。
4 如需詳細資訊，請參閱其他虛擬網路連線需求。
異地複寫的對等連接埠需求
如果您在 Azure 虛擬網路的快取間使用異地複寫：a) 請為整個子網路的輸入「和」輸出兩個方向以及 b) 兩個快取解除封鎖連接埠 15000-15999。 使用此設定，子網路中所有複本元件都可以彼此直接通訊，即使未來有異地容錯移轉也一樣。
輸入連接埠需求
有八項輸入連接埠範圍需求。 這些範圍內的輸入要求或從裝載在相同虛擬網路中的其他服務輸入， 或為 Redis 子網路的內部通訊。
| 連接埠 | 方向 | 傳輸通訊協定 | 目的 | 本機 IP | 遠端 IP |
|---|---|---|---|---|---|
| 6379, 6380 | 傳入 | TCP | 對 Redis 進行的用戶端通訊，Azure 負載平衡 | (Redis 子網路) | (Redis 子網路)、(用戶端子網路)、AzureLoadBalancer 1 |
| 8443 | 傳入 | TCP | Redis 內部通訊 | (Redis 子網路) | (Redis 子網路) |
| 8500 | 傳入 | TCP/UDP | Azure 負載平衡 | (Redis 子網路) | AzureLoadBalancer |
| 10221-10231 | 傳入 | TCP | Redis 叢集的用戶端通訊、Redis 的內部通訊 | (Redis 子網路) | (Redis 子網路)、(用戶端子網路)、AzureLoadBalancer |
| 13000-13999 | 傳入 | TCP | 對 Redis 叢集的用戶端通訊，Azure 負載平衡 | (Redis 子網路) | (Redis 子網路)、(用戶端子網路)、AzureLoadBalancer |
| 15000-15999 | 傳入 | TCP | Redis 叢集的用戶端通訊、Azure 負載平衡和異地複寫 | (Redis 子網路) | (Redis 子網路)、(用戶端子網路)、AzureLoadBalancer、(異地複本對等互連子網路) |
| 16001 | 傳入 | TCP/UDP | Azure 負載平衡 | (Redis 子網路) | AzureLoadBalancer |
| 20226 | 傳入 | TCP | Redis 內部通訊 | (Redis 子網路) | (Redis 子網路) |
1 您可以使用 Resource Manager 的 AzureLoadBalancer 服務標籤或傳統部署模型的 AZURE_LOADBALANCER 撰寫 NSG 規則。
其他虛擬網路連線需求
Azure Cache for Redis 需要網路連線需求，才能對快取運作所需的其他相依性服務進行輸出連線，甚至是 Redis 子網內部進行節點間通訊。
Azure Cache for Redis 需要下列所有輸出連線項目在虛擬網路內使用時正常運作：
| 主機名稱 | 通訊協定 | 輸出連接埠 | 目的 | 服務標籤 |
|---|---|---|---|---|
| *.vault.azure.net | HTTPS | 443 | Azure Key Vault | AzureKeyVault |
| *.table.core.windows.net | HTTPS | 443 | Azure 儲存體 | 儲存體 |
| *.blob.core.windows.net | HTTPS | 443 | Azure 儲存體 | 儲存體 |
| *.queue.core.windows.net | HTTPS | 443 | Azure 儲存體 | 儲存體 |
| *.file.core.windows.net | HTTPS | 443 | Azure 儲存體 | 儲存體 |
| ocsp.digicert.com | HTTP | 80 | Azure 公鑰基礎結構 | N/A |
| crl4.digicert.com | HTTP | 80 | Azure 公鑰基礎結構 | N/A |
| ocsp.msocsp.com | HTTP | 80 | Azure 公鑰基礎結構 | N/A |
| mscrl.microsoft.com | HTTP | 80 | Azure 公鑰基礎結構 | N/A |
| crl3.digicert.com | HTTP | 80 | Azure 公鑰基礎結構 | N/A |
| cacerts.digicert.com | HTTP | 80 | Azure 公鑰基礎結構 | N/A |
| oneocsp.microsoft.com | HTTP | 80 | Azure 公鑰基礎結構 | N/A |
| crl.microsoft.com | HTTP | 80 | Azure 公鑰基礎結構 | N/A |
| cacerts.geotrust.com | HTTP | 80 | Azure 公鑰基礎結構 | N/A |
| www.microsoft.com | HTTP | 80 | Azure 公鑰基礎結構 | N/A |
| cdp.geotrust.com | HTTP | 80 | Azure 公鑰基礎結構 | N/A |
| status.geotrust.com | HTTP | 80 | Azure 公鑰基礎結構 | N/A |
| shoebox3.prod.microsoftmetrics.com | HTTPS | 443 | Azure 監視器 | AzureMonitor |
| shoebox3-red.prod.microsoftmetrics.com | HTTPS | 443 | Azure 監視器 | AzureMonitor |
| shoebox3-black.prod.microsoftmetrics.com | HTTPS | 443 | Azure 監視器 | AzureMonitor |
| azredis.prod.microsoftmetrics.com | HTTPS | 443 | Azure 監視器 | AzureMonitor |
| azredis-red.prod.microsoftmetrics.com | HTTPS | 443 | Azure 監視器 | AzureMonitor |
| azredis-black.prod.microsoftmetrics.com | HTTPS | 443 | Azure 監視器 | AzureMonitor |
| global.prod.microsoftmetrics.com | HTTPS | 443 | Azure 監視器 | AzureMonitor |
| gcs.prod.monitoring.core.windows.net | HTTPS | 443 | Azure 監視器 | AzureMonitor |
| *.prod.warm.ingest.monitor.core.windows.net | HTTPS | 443 | Azure 監視器 | AzureMonitor |
| *.servicebus.windows.net | HTTPS | 443 | Azure 監視器 | EventHub |
| *.update.microsoft.com | HTTPS | 443 | 操作系統更新服務 | AzureCloud |
| *.windowsupdate.com | HTTP/HTTPS | 80、443 | 操作系統更新服務 | N/A |
| *.delivery.mp.microsoft.com | HTTP/HTTPS | 80、443 | 操作系統更新服務 | AzureCloud |
| go.microsoft.com | HTTP/HTTPS | 80、443 | 防毒 | N/A |
| *.wdcp.microsoft.com | HTTPS | 443 | 防毒 | AzureCloud |
| *.wdcpalt.microsoft.com | HTTPS | 443 | 防毒 | AzureCloud |
| *.wd.microsoft.com | HTTPS | 443 | 防毒 | AzureCloud |
| definitionupdates.microsoft.com | HTTPS | 443 | 防毒 | N/A |
| azurewatsonanalysis-prod.core.windows.net | HTTPS | 443 | 內部診斷 | AzureCloud |
| shavamanifestazurecdnprod1.azureedge.net | HTTPS | 443 | 內部診斷 | N/A |
| shavamanifestcdnprod1.azureedge.net | HTTPS | 443 | 內部診斷 | N/A |
| *.data.microsoft.com | HTTPS | 443 | 內部診斷 | AzureCloud |
- 虛擬網路的 DNS 組態必須能夠解析先前數據表專案中所述的所有端點和網域。 確定已針對虛擬網路設定及維護有效的 DNS 基礎結構，即可符合 DNS 需求。
如何確認我的快取在虛擬網路中是否生效？
重要
當您連線到裝載在虛擬網路中的 Azure Cache for Redis 執行個體時，您的快取用戶端必須位於相同的虛擬網路中，或位於相同 Azure 區域內已啟用虛擬網路對等互連的虛擬網路中。 目前不支援全域虛擬網路對等互連。 這項需求適用於任何測試應用程式或診斷 ping 工具。 不論用戶端應用程式裝載在哪個位置，都必須設定 NSG 或其他網路層，以允許用戶端的網路流量到達 Azure Cache for Redis 執行個體。
如上一節所述設定埠需求之後，在大部分情況下都需要重新啟動，以確保變更能正確反映。 否則，您可能會遇到一些連線問題。 您可以遵循下列步驟來確認快取是否正常運作：
- 重新啟動所有的快取節點。 如果無法觸達所有必要的快取相依項連線，快取將無法順利重新啟動，如輸入連接埠需求和輸出連接埠需求中所述。
- 重新啟動快取節點後 (Azure 入口網站的快取狀態會報告)，您就可以執行下列測試：
使用
tcping，從和快取同一虛擬網路的電腦中，使用連接埠 6380 Ping 快取端點。 例如：tcping.exe contosocache.redis.cache.windows.net 6380如果
tcping工具報告連接埠已開啟，就可以在虛擬網路中從用戶端使用快取連線。另一種測試方法：建立連線到快取的測試快取用戶端，然後從快取新增及擷取某些項目。 測試快取用戶端可以是使用 StackExchange.Redis 的主控台應用程式。 將範例用戶端應用程式安裝到與快取同一虛擬網路的 VM 上。 然後，執行此應用程式以驗證確認連線到快取。
嘗試連線到虛擬網路中的 Azure Cache for Redis 時，為什麼會收到遠端憑證無效的錯誤？
嘗試連線到虛擬網路中的 Azure Cache for Redis 時，您會看到類似這樣的憑證驗證錯誤：
{"No connection is available to service this operation: SET mykey; The remote certificate is invalid according to the validation procedure.; …"}
原因可能是您透過 IP 位址連線到主機。 建議您使用主機名稱。 換句話說，請使用下列字串：
[mycachename].redis.cache.windows.net:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False
避免使用類似下列連接字串的 IP 位址：
10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False
如果您無法解析 DNS 名稱，某些用戶端程式庫就會包含由 StackExchange.Redis 用戶端提供的設定選項，例如 sslHost。 此選項可讓您覆寫用於憑證驗證的主機名稱。 例如：
10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False;sslHost=[mycachename].redis.cache.windows.net
此外，如果裝載 Azure Cache for Redis 的子網封鎖透過埠 80 進行 SSL/TLS 功能的 TCP 輸出連線，用戶端可能會遇到間歇性 TLS 憑證驗證錯誤。
虛擬網路可以搭配標準還是基本快取使用？
虛擬網路只能搭配進階層快取使用。
為什麼在有些子網路中建立 Azure Cache for Redis 執行個體會失敗，有些則不會？
如要將 Azure Cache for Redis 執行個體部署到虛擬網路，快取就必須位於不包含任何其他資源類型的專用子網路中。 如要嘗試將 Azure Cache for Redis 執行個體部署到包含其他資源的 Resource Manager 虛擬網路子網路 (例如Azure 應用程式閘道執行個體和輸出 NAT)，部署通常會失敗。 建立新的 Azure Cache for Redis 執行個體之前，請先刪除其他類型的現有資源。
子網路中也必須有足夠的可用 IP 位址。
子網路位址空間需求為何？
Azure 會在每個子網路中保留一些 IP 位址，但這些位址無法使用。 子網路的第一個和最後一個 IP 位址會保留給相容的通訊協定，以及用於 Azure 服務的額外 3 個位址。 如需詳細資訊，請參閱在這些子網路內使用 IP 位址是否有任何限制？
除了 Azure 虛擬網路基礎結構使用的 IP 位址外，子網路中每個 Azure Cache for Redis 執行個體在每個叢集分區都會使用兩個 IP 位址，加一個供額外複本使用的 IP 位址 (如有)。 負載平衡器再使用一個 IP 位址。 非叢集快取會視為有一個分區。
我可以從對等互連的虛擬網路連線到我的快取嗎？
如果虛擬網路都位在相同的區域中，您就可以使用虛擬網路對等互連或 VPN 閘道 VNET 對 VNET 連線連接這些虛擬網路。
如果對等互連的 Azure 虛擬網路位在「不同的」區域：因為受到基本負載平衡器的條件約束，區域 1 中的用戶端 VM 無法透過其負載平衡的 IP 位址存取區域 2 的快取。 也就是說，除非是目前僅可使用「可用性區域」建立的標準負載平衡器快取才有可能。
如需虛擬網路對等互連條件約束的詳細資訊，請參閱＜虛擬網路 - 對等互連 - 需求和條件約束＞。 其中一個解決方案是使用 VPN 閘道 VNET 對 VNET 連線，而非使用虛擬網路對等互連。
在虛擬網路中裝載快取時，所有快取功能都可以正常運作嗎？
當快取是虛擬網路的一部分時，只有虛擬網路中的用戶端可以存取此快取。 因此，下列快取管理功能不適用於以下情況：
- Redis 主控台：因為 Redis 主控台在本機瀏覽器中執行 (通常是未連線到虛擬網路的開發人員電腦)，所以就無法連線到您的快取。
已啟用 Azure Lighthouse 的快取是否支援 VNet 插入？
否，如果您的訂用帳戶已啟用 Azure Lighthouse，您就無法在 Azure Cache for Redis 執行個體上使用 VNet 插入。 請改用私人連結。
搭配使用 ExpressRoute 與 Azure Cache for Redis
客戶可以將 Azure ExpressRoute 線路連接至其虛擬網路基礎結構。 如此，即可將內部部署網路擴充到 Azure。
新建立的 ExpressRoute 線路預設不在虛擬網路中使用強制通道 (公告預設路由 0.0.0.0/0)。 因此，允許直接從虛擬網路輸出連線到網際網路。 用戶端應用程式可以連線到其他 Azure 端點，包括 Azure Cache for Redis 執行個體。
常見的客戶設定是使用強制通道 (公告預設路由)，以強制輸出網際網路流量來替代透過內部部署方式流動。 如果輸出流量遭內部部署封鎖，而使得 Azure Cache for Redis 執行個體無法與其相依項通訊，此流量就會中斷與 Azure Cache for Redis 的連線。
解決方案是在子網路上定義包含 Azure Cache for Redis 執行個體的一或多個使用者定義路由 (UDR)。 UDR 會定義將使用的子網路特有路由，而非預設路由。
如果可行，請使用下列設定：
- ExpressRoute 設定會公告 0.0.0.0/0，且預設會使用強制通道將所有輸出流量傳送至內部部署。
- 包含 Azure Cache for Redis 執行個體之子網路所套用的 UDR，會定義 0.0.0.0/0 以及對公用網際網路 TCP/IP 流量有效的路由。 例如，將下一個躍點類型設定為「網際網路」。
這些步驟的合併效果是子網路層級的 UDR 會優先於 ExpressRoute 強制通道，因而確保來自 Azure Cache for Redis 執行個體的輸出網際網路存取。
因為效能原因，使用 ExpressRoute 從內部部署應用程式連線到 Azure Cache for Redis 執行個體，不是典型的使用案例。 為獲得最佳效能，Azure Cache for Redis 用戶端應與 Azure Cache for Redis 執行個體位於同一區域。
重要
UDR 中定義的路由必須明確足以優先於 ExpressRoute 組態所通告的任何路由。 下列範例使用廣泛的 0.0.0.0/0 位址範圍，因此可能一不小心就被使用更明確位址範圍的路由公告所覆寫。
警告
ExpressRoute 設定不支援 Azure Cache for Redis， 這些設定會錯誤地跨Microsoft對等互連路徑到私人對等互連路徑的路由進行交叉通告。 已設定Microsoft對等互連的 ExpressRoute 組態會從Microsoft接收一組大型Microsoft Azure IP 位址範圍的路由公告。 如果這些位址範圍在私人對等互連路徑上錯誤地交叉通告，結果會是來自 Azure Cache for Redis 執行個體子網路的所有輸出網路封包，都會不正確地使用強制通道傳送至客戶的內部部署網路基礎結構。 此網路流量會中斷 Azure Cache for Redis。 此問題的解決方案是停止從Microsoft對等互連路徑到私人對等互連路徑的跨廣告路由。
虛擬網路流量路由提供 UDR 的背景資訊。
如需 ExpressRoute 的詳細資訊，請參閱 ExpressRoute 技術概觀。
相關內容
深入了解 Azure Cache for Redis 功能。