【Azure Redis 快取 Azure Cache For Redis】Azure Redis由低級別(C)升級到高級別(P)的步驟和注意事項, 及對用戶現有應用的潛在影響，是否需要停機時間窗口，以及這個時間窗口需要多少的預估問題

• 2020 年 12 月 7 日
• 筆記
• 【Azure Redis 快取 Azure Cache For Redis】, Azure Redis, 升級問題

問題描述

由於Azure Redis的性能在不同級別表現不同，當需要升級/縮放Redis的時候，從使用者的角度：

• 需要知道有那些步驟？
• 注意事項？
• 潛在影響？
• 停機事件窗口?
• 升級預估時間？

解決方案

從使用的步驟出發，升級的步驟為：

1）Azure門戶頁面操作

• 選擇縮放(Scale)目錄
• 選擇需要的級別(C1 ~ C6, P1 ~P5)
• 點擊Select按鈕確認

2）使用Powershell命令

使用 Set-AzRedisCache 來縮放 Azure Redis 快取實例,修改 Size、Sku 或 ShardCount 屬性

Set-AzRedisCache
   [-ResourceGroupName <String>]
   -Name <String>
   [-Size <String>]
   [-Sku <String>]
   [-RedisConfiguration <Hashtable>]
   [-EnableNonSslPort <Boolean>]
   [-TenantSettings <Hashtable>]
   [-ShardCount <Int32>]
   [-MinimumTlsVersion <String>]
   [-Tag <Hashtable>]
   [-DefaultProfile <IAzureContextContainer>]
   [-WhatIf]
   [-Confirm]
   [<CommonParameters>]
=====================================================
縮放 Azure Redis 快取: //docs.azure.cn/zh-cn/azure-cache-for-redis/cache-how-to-manage-redis-cache-powershell#to-scale-an-azure-cache-for-redis
Set-AzRedisCache：//docs.microsoft.com/zh-cn/powershell/module/az.rediscache/set-azrediscache?view=azps-5.1.0

 

升級/縮放限制：

 

• 不能從較高的定價層縮放到較低的定價層。
• 不能從 高級 快取向下縮放到 標準 或 基本 快取。
• 不能從 標準 快取向下縮放到 基本 快取。
• 可從 基本 快取縮放到 標準 快取，但不能同時更改大小。 如果需要不同大小，則可以執行後續縮放操作以縮放為所需大小。
• 不能從 基本 快取直接縮放到 高級 快取。 必須在一個縮放操作中從 基本 縮放到 標準 ，並在後續的縮放操作中從 標準 縮放到 高級 。
• 不能從較大的大小減小為 C0 (250 MB) 。

注意事項：

1、在縮放操作期間快取名稱和密鑰不變，所以客戶端應用程式連接字元串不需要改變的。

2、標準和高級快取在縮放操作期間保持可用，但是可能會出現連接故障，這些連接故障預期為很小的故障，redis 客戶端應能立即重新建立連接，所以確保應用程式有重連機制。

3、如果高級版redis使用了虛擬網路，那麼客戶端應用也需要在該虛擬網路內才可以訪問redis。

4、如果您為高級redis開啟了群集功能的話，那麼客戶端也需要對應改動，詳細請參考：//docs.azure.cn/zh-cn/azure-cache-for-redis/cache-how-to-premium-clustering#do-i-need-to-make-any-changes-to-my-client-application-to-use-clustering

使用群集功能時，是否需要對客戶端應用程式進行更改？

• 啟用群集功能時，僅資料庫 0 可用。 如果客戶端應用程式使用多個資料庫並嘗試讀取或寫入資料庫 0 之外的其他資料庫，則會引發以下異常。 Unhandled Exception: StackExchange.Redis.RedisConnectionException: ProtocolFailure on GET ---> StackExchange.Redis.RedisCommandException: Multiple databases are not supported on this server; cannot switch to database: 6

  有關詳細資訊，請參閱 Redis 群集規範 – 已實現子集。

• 如果使用的是 StackExchange.Redis，則必須使用 1.0.481 或更高版本。 連接到該快取時，可以使用的終結點、埠和密鑰與連接到未啟用群集功能的快取時使用的相同。 唯一的區別是，所有讀取和寫入都必須在資料庫 0 中進行。

  其他客戶端可能有不同的要求。 請參閱 是否所有 Redis 客戶端都支援群集功能？

• 如果應用程式使用的多個密鑰操作都在單個命令中成批執行，則所有密鑰都必須位於同一分片。 若要查找同一分片中的密鑰，請參閱密鑰在群集中是如何分布的？

• 如果使用的是 Redis ASP.NET 會話狀態提供程式，則必須使用 2.0.1 或更高版本。 請參閱 能否在 Redis ASP.NET 會話狀態和輸出快取提供程式中使用群集功能？

升級時間：

縮放時間取決於快取中的數據量，數據量越大，完成縮放所需的時間就越長。 縮放大約需要 20 分鐘。

潛在影響：

標準和高級快取在縮放操作期間保持可用，但是可能會出現連接故障，這些連接故障預期為很小的故障，redis 客戶端應能立即重新建立連接。

故障轉移如何影響我的客戶端應用程式？

客戶端應用程式遇到的錯誤數目取決於故障轉移時該連接上掛起的操作數目。 通過關閉連接的節點路由的任何連接將遇到錯誤。 在連接中斷時，許多客戶端庫可能會引發不同類型的錯誤，包括超時異常、連接異常或套接字異常。 異常的數目和類型取決於當快取關閉其連接時，請求在程式碼路徑中所處的位置。 例如，在發生故障轉移時發送了請求但未收到響應的操作可能會收到超時異常。 對關閉的連接對象發出的新請求將收到連接異常，直到重新連接成功為止。

大多數客戶端庫會嘗試重新連接到快取（如果採用此配置）。 但是，不可預測的 bug 偶爾會將庫對象置於不可恢復狀態。 如果出錯的持續時間超過了預先配置的時間，則應重新創建連接對象。 在 Microsoft.NET 和其他面向對象的語言中，可以使用 Lazy<T> 模式來重新創建連接，而無需重啟應用程式。

 

• 重複使用連接。 創建新連接是高開銷的操作，會增大延遲，因此請盡量重複使用連接。 如果你選擇創建新連接，請確保在釋放舊連接之前先將其關閉（即使是在 .NET 或 Java 等託管記憶體語言中）。

• 將客戶端庫配置為使用至少 15 秒的連接超時 ，以便即使是在 CPU 負載較高的情況下，系統也有時間建立連接。 使用較小的連接超時值無法保證在該時間範圍內能夠建立連接。 如果出現問題（客戶端 CPU 負載偏高、伺服器 CPU 負載偏高等），則使用較短的連接超時值會導致連接嘗試失敗。 此行為通常會使問題變得更糟。 使用較短的超時不僅無助於解決問題，而且會加劇問題，這會強制系統重啟嘗試重新連接的進程，從而可能導致出現「連接 -> 失敗 -> 重試」循環。 我們通常建議將連接超時保留為 15 秒或更長。 讓連接嘗試在 15 或 20 秒後成功，比失敗後立即重試更有利。 與最初讓系統花費更長時間嘗試連接相比，這種重試循環可能會導致服務中斷的持續時間變長。

性能變化：

每個級別的性能數據(連接數，RPS, 記憶體，CPU）變化如下：

 

【Azure Redis 快取 Azure Cache For Redis】使用Redis自帶redis-benchmark.exe命令測試Azure Redis的性能

 

參考資料：

縮放redis：//docs.azure.cn/zh-cn/azure-cache-for-redis/cache-configure#scale
縮放redis的注意事項：//docs.azure.cn/zh-cn/azure-cache-for-redis/cache-how-to-scale#scaling-faq
排查客戶端問題：//docs.azure.cn/zh-cn/azure-cache-for-redis/cache-troubleshoot-client#client-side-bandwidth-limitation
配置虛擬網路的redis：//docs.azure.cn/zh-cn/azure-cache-for-redis/cache-how-to-premium-vnet