Azure Cache for Redis 常見問題

瞭解 Azure Cache for Redis 常見問題、模式和最佳做法的解答。

Redis 授權變更

Redis 授權有哪些變更?

Redis 開放原始碼專案已變更為雙授權模型,支援 Redis 來源可用授權第 2 版 (RSALv2) 或伺服器端公用授權第 1 版 (SSPLv1)。 如需詳細資訊, 請參閱 Redis 新聞稿 。 另請參閱 Redis 授權變更上的 Microsoft 部落格文章。

RsALv2 和 SSPLv1 授權現在是否也涵蓋 Azure Cache for Redis?

否,Azure Cache for Redis 會根據 Microsoft 服務條款提供給客戶。 RSALv2 和 SSPLv1 授權不適用於您使用 Azure Cache for Redis。

我的 Azure Cache for Redis 實例是否會繼續接收修補程式和 Bug 修正?

是,Azure Cache for Redis、Azure Cache for Redis Enterprise 和 Enterprise Flash 將會在授權公告之後繼續接收修補程式和錯誤修正。

作為 Azure Cache for Redis 客戶,以回應此授權公告,我需要做什麼?

我們的 Azure 客戶不需要採取任何關於授權公告的動作。

已淘汰的服務

哪些 Azure Cache for Redis 服務已被取代?

快取與 雲端服務 相依性 (傳統)

我應該使用任何相依於 雲端服務(傳統)的 Azure Cache for Redis 實例做什麼?

您應該移轉所有具有相依性 雲端服務(傳統)的快取。 2021年8月,我們宣佈 雲端服務(經典版)將於2024年8月31日退休。 任何相依於 雲端服務 (傳統) 的 Azure Cache for Redis 實例,都必須在相同的日期前淘汰。

您應該在 2024 年 8 月 31 日之前移轉相依於 雲端服務 (傳統) 的快取。

有多少個快取受到影響?

我們已努力盡可能多地移轉快取。 因此,很少有快取和客戶受到影響。

如何? 知道快取是否受到影響?

檢查 Azure Advisor 建議。 如果您的快取受到影響,您會在訂用帳戶中看到建議。

Advisor 建議從雲端服務移轉快取的螢幕快照。

如何? 將 雲端服務 快取移轉至 Azure 虛擬機器擴展集?

我們已將大部分快取從建置在 雲端服務 (傳統) 上移轉至建置在 Azure 虛擬機器擴展集 上。 移轉至 Azure 虛擬機器擴展集 會移除相依性。 有三種方式可以針對虛擬網路中的快取起始此程式:

  • 使用 Private Links 移轉至新的快取。

    建立新的快取,以使用 Private Link 進行網路隔離,而不是虛擬網路插入,並將 您的數據遷移至此快取。 此選項可讓您獲得最佳且最安全的網路隔離體驗,同時確保使用更新的基礎結構建立所有新的快取。

  • 遷移至新 Azure Resource Manager VNet 子網中的新快取。

    在傳統 VNet 內建立快取會建立 雲端服務(傳統)快取,而不是 Azure 虛擬機器擴展集 快取。 移轉至新 Azure Resource Manager VNet 子網中的新快取,可修正 雲端服務 的基礎相依性,同時維護類似的虛擬網路體驗。

    我們已將大部分快取從建置在 雲端服務 (傳統) 上移轉至建置在 Azure 虛擬機器擴展集 上。 若要移轉,請刪除現有的快取,並在新的 Azure Resource Manager VNet 子網中建立新的快取。 強烈建議在移轉快取時不要使用舊子網。 如需移轉快取中數據的建議選項,請參閱 移轉至 Azure Cache for Redis

  • 自動移轉並遺失數據(建議)。

    我們可以將快取從使用 雲端服務 (傳統) 移轉至自動使用 虛擬機器擴展集,並保留快取組態(包括存取密鑰和主機名)。 不過,此方法需要大約 30 分鐘的停機時間,並完成快取上的數據遺失。 您可以使用匯 入/匯出 功能,在移轉之前儲存數據的複本。

    若要使用此選項,請連絡 azurecachemigration@microsoft.com 或建立支援要求移轉要求。

我的快取未使用 VNet 插入,但收到需要移轉的通知。 我該怎麼做?

檢查您的快取是否使用異地複寫。 如果是,您必須將數據從目前的異地復寫配對移轉至新的異地複寫配對。

例如:

  1. 建立新的異地復寫組 進階版 快取,以符合您目前快取組的相同組態。
  2. 取消連結原始的異地復寫快取組,並從 主要快取匯出 RDB 檔案
  3. 將 RDB 檔案匯入至新異地複寫配對中的主要快取。

新配對的異地復寫快取不會與 雲端服務 具有相同的相依性。

如果我無法使用錯誤訊息「子網受到 雲端服務 淘汰的影響」建立新的快取實例,該怎麼辦?

我們開始使用 雲端服務 (傳統) 部署模型來封鎖新快取的建立。 如果新的快取是在包含 雲端服務 快取的虛擬網路子網中建立,或快取部署至傳統 VNet 中,仍然可以使用此舊的部署模型來建立。 如果您看到此訊息,請在要在其中部署快取的 VNet 中建立新的子網。 在虛擬網路中建立子網可確保建立快取,而不需要 雲端服務 相依性。

若要檢查子網中是否有一或多個 雲端服務 型快取,您可以在入口網站中檢查 Azure Advisor,或使用資源導覽連結 REST APIresource-navigation-links使用 API 搭配您的訂用帳戶標識碼、資源組名、虛擬網路名稱和子網名稱,以取得使用該 雲端服務 之子網中的任何快取。

如果您要使用 REST API 建立新的快取,也請確定您不會隨著建立要求一起傳遞 redis 組態 {"CacheVmType": "CloudService"} 。 該參數是未記載的參數,因此您不太可能這麼做。

如果您需要使用 雲端服務 (傳統) 部署模型建立新的快取,請連絡azurecachemigration@microsoft.com或建立支援要求豁免要求。

如果在 2024 年 8 月 31 日前未升級/移轉快取,會發生什麼情況?

這些快取將會關閉,而且您會遺失快取中的任何數據。

支持時程表為何?

淘汰會在三個階段中發生,因此您有移轉的時間上限:

  1. 現役階段 (現至 2023 年 4 月 30 日)

    快取具有完整支援,目前狀態沒有任何變更。 此期間可讓客戶有時間在最少中斷的情況下從雲端服務(傳統版)轉換。

  2. 維護階段 (2023 年 5 月 1 日至 2023 年 12 月 31 日)

    快取將會收到重要的安全性、穩定性和 Bug 修正,但不會有新功能。

  3. 非使用中階段 (2024 年 1 月 1 日至 2024 年 8 月 31 日)

    快取只會接收重要的安全性修正。 在收到支援之前,所有有支援問題的客戶都必須移轉至 VMSS 型快取。 客戶必須在 2024 年 8 月 31 日前移出其快取。

顯示淘汰雲端服務時間軸的時程表圖片(傳統)。

此時程表是否適用於在 Redis 4.0 上執行的快取?

否。 此時程表僅適用於 Redis 6.0 上執行的快取。 Redis 4.0 是個別淘汰的一部分,在 雲端服務(傳統)淘汰之前完成。 在 雲端服務 上使用 Redis 4.0 的所有剩餘快取都會在 2023 年 10 月 31 日之後自動移轉為使用 虛擬機器擴展集 和 Redis 6.0。 此移轉方法需要快取的停機時間和完整數據遺失,因此如果您想要避免停機或數據遺失,請在此日期之前移轉。 請連絡 azurecachemigration@microsoft.com 或建立支援要求,要求在 2023 年 10 月 31 日之前自動升級。

如果我有更多關於此淘汰的問題,我可以在哪裡取得詳細資訊?

將您的任何問題張貼到 Q&A 頁面,以取得 雲端服務 (傳統) 淘汰。 此外,您也可以傳送電子郵件給 , azurecachemigration@microsoft.com 以取得詳細資訊。

一般問題

如果我的 Azure Cache for Redis 問題未在這裡回答,該怎麼辦?

如果此處未列出您的問題,請告訴我們,讓我們協助您找到答案。

  • 若要觸及更廣泛的物件,您可以在 Azure 快取Microsoft Q&A 問題頁面上張貼問題,並與 Azure 快取小組和社群的其他成員互動。

  • 如果您想要提出功能要求,您可以將要求和想法提交至 Azure Cache for Redis 用戶語音

  • 您也可以在 將 azurecache@microsoft.com問題傳送給我們。