Amazon ElastiCache 受管維護和服務更新說明頁面

概觀

我們會以無縫的方式將許多修補程式和升級套用到執行個體,頻繁地升級 Amazon ElastiCache 機群。我們透過以下兩種方式之一進行操作:

(a) 持續的受管維護,以及 (b) 服務更新。必須進行這些維護和服務更新才能套用升級,以強化安全性、可靠性和操作效能。

持續的受管維護會不時地直接在維護時段中進行,而無須您採取任何動作。
服務更新讓您可以靈活地自行套用它們。它們定時執行,在到期日期過後可能會移入維護時段以便我們進行套用。

您可以在排定的維護時段之前,選擇任意時間自己管理更新。當您自行管理更新時,執行個體會在重新啟動節點時收到 OS 更新,而排定的維護時段將會取消。

服務更新

服務更新是 Amazon ElastiCache 中的一項功能,讓您可以自行決定套用某些服務更新。這些更新可以是以下類型:安全修補程式或次要軟體更新。這些更新有助於增強叢集的安全性、可靠性和操作效能。

這些服務更新的價值在於,您可以控制何時套用更新 (例如,當發生重要業務事件,需要 ElastiCache 叢集具有全年無休可用性時,可以延遲套用服務更新)。

有關每項服務更新的詳細資訊,請參閱「更新描述」屬性的值。

當您的叢集有適用的服務更新時,我們會透過多種管道通知您,包括 Amazon ElastiCache 主控台、電子郵件、Amazon Simple Notification Service (SNS)、AWS Personal Health Dashboard 和 Amazon CloudWatch Events

透過我們的持續受管維護提供的更新與服務更新提供的更新是分開的。透過持續受管維護套用的更新直接在維護時段排程,無須您採取任何動作。服務更新則是定時的,可讓您控制何時按「建議套用日期」來套用更新。若屆時仍未套用更新,則 ElastiCache 可能會在維護時段排程這些更新。

若您的 ElastiCache 叢集正在參與 HIPAA、PCI 或 FedRAMP 合規計劃,則您必須按其中的「建議套用日期」來套用服務更新,以便保持合規。如需詳細資訊,請參閱合規的自助服務安全更新

若是其他叢集,我們建議您根據業務節奏套用服務更新。即使您無法按其「建議套用日期」來套用服務更新,也可以在其「更新到期日期」之前套用。但是,「更新到期日期」可能隨時變更,具體取決於新更新的可用性。

當您或 Amazon ElastiCache 將服務更新套用至一個或多個叢集時,更新會在每個碎片內一次套用至不超過一個節點,直到全部所選叢集完成更新。更新的節點幾乎不會有停機時間,而剩餘的叢集會繼續提供流量。

  • 叢集組態不會有任何變化。
  • 您會看到 CloudWatch 指標出現延遲,這些延遲會盡快趕上。

服務更新會透過節點替換以與「持續的受管維護更新」相同的方式套用。有關更新如何套用以及如何準備應用程式以將影響最小化的詳細資訊,請參閱本頁持續的受管維護更新部分中的以下問題。

  • 節點替換對我的應用程式有何影響?
  • 若要有順暢的替換體驗並將資料遺失的機率降到最低,應遵循何種最佳實務?
  • 我應該遵循哪些用戶端組態最佳實務,最大限度地減少維護期間的應用程式中斷狀況?

是,該節點將被新的空節點取代。快取內容將不再存在並重新開始。

您可以透過驗證「到期日後自動更新」屬性的值來判斷是否可以選擇退出服務更新。如果服務更新的「到期日後自動更新」屬性值為「」,則可以選擇退出此服務更新。然而,如果服務更新的「到期日期之後自動更新」屬性的值為「」且「建議套用日期」時間已過,ElastiCache 會自動在即將來到的維護時段期間將服務更新排程至任何其餘的叢集。此自動服務更新將在「更新到期日」之前排定,並且您將在更新前一週收到含有預定時間的通知。即使可以選擇退出,我們仍強烈建議套用安全性更新。  如果您選擇在維護期間之前將服務更新套用於其餘叢集,則 ElastiCache 不會在維護時段期間重新套用服務更新。

服務更新的目的是讓您可以靈活選擇何時套用它們。對於不參與 ElastiCache 支援的合規性計劃的叢集,可以選擇不套用這些更新,或者選擇全年不使用這些更新。僅在服務更新「到期日期之後自動更新」屬性的值為「」時才會如此。如需詳細資訊,請參閱我是否可以選擇退出服務更新?

否,服務更新與叢集維護時段期間 Amazon ElastiCache 直接套用的持續受管維護更新互斥。

屬性及其描述的完整清單在套用自助服務更新中提供。

為幫助確定多長時間套用可用的服務更新,您可以參考「嚴重性」服務更新屬性,該屬性具有以下值 (按優先級排序):

1. 關鍵建議立即套用 (在 14 天或更短時間內)
2. 重要建議在您業務流程允許的情況下盡快套用 (30 天或更短時間內)
3. 建議在 60 天或更短時間內套用
4. 建議在 90 天或更短時間內套用

如需詳細資訊,請參閱我們的公共文件 – 套用更新

發佈計劃取決於服務更新的重要性。

此屬性反映您的叢集是否按「建議套用日期」進行更新。若在「建議套用日期」之後套用服務更新,則屬性「符合服務更新 SLA」將被設定為「」。

該資訊與參與 HIPAA、PCI 和 FedRAMP 合規性計劃的 Amazon ElastiCache 叢集相關。如需詳細資訊,請參閱合規的自助服務安全更新

是。除非服務更新「說明」屬性中另有說明,否則服務更新始終為累積:若您在「更新到期日期」前錯過套用這些更新,則它們將包含在下一次服務更新中。類型為「安全性」的服務更新屬於此累積類別。

否,服務更新在叢集級別套用。若取消正在進行的更新,則叢集可能會更新某些節點,而某些節點未更新。在這種情況下,叢集將繼續顯示在要套用服務更新的叢集清單中。叢集會繼續正常執行。

在兩種情況下可能會發生這種情況:

(a) 若錯過套用可選的服務更新,並且該更新現在處於「到期」狀態。因此,參與合規性計劃的叢集必須始終套用所有服務更新。
(b) 若您的節點由於任何其他原因而被取代,例如計劃中的維護事件或節點容錯移轉,Amazon ElastiCache 將為新節點提供包含最新服務更新的節點。

在這兩種情況下,叢集都會繼續正常執行。

新節點包含所有適用的服務更新,因此您可以手動取代尚未更新的現有節點以獲取最新更新。

是。服務更新可能僅適用於 Redis OSS,僅適用於 Memcached,或者適用於 Redis OSS 和 Memcached。您可以查找「引擎」和「引擎版本」服務更新屬性,以確定每次更新的範圍。

是,您可以變更維護時段,推遲服務更新。如果排定的日期符合叢集的維護時段,則排定的更新將僅套用至叢集。一旦變更維護時段,且排定的日期已過,服務更新將在未來幾週重新排程至新指定的時段。您將在新日期到來的前一週收到新的通知。

AWS 上的安全是共同的責任。強烈建議您盡早套用更新。

您的叢集可能屬於不同服務更新的一部分。大多數更新不會要求您分開套用。套用一個更新至您的叢集會在任何適用的時候將其他更新標記為已完成。如果狀態未自動變更為「已完成」,則您可能需要將多個更新分開套用至同一叢集。

如果「到期日期後自動更新」屬性的值為「」,則 ElastiCache 會在「建議套用日期」之後針對剩餘叢集排程服務更新。 更新將排定在叢集的維護時段,在更新套用之前,您會在排定日期的前一週收到新的通知。

排定的服務更新會以與「持續的受管維護更新」相同的方式套用至叢集。 有關如何套用更新、如何變更排定的更新,以及如何為針對排定的更新準備應用程式以將影響最小化的詳細資訊,請參閱以下章節。

為了保持叢集的穩定性,ElastiCache 會在一個碎片內一次僅套用至一個節點。如果服務更新無法在單一維護時段內套用至整個叢集,則將排定為在後續維護時段中繼續。您將在下個排定日期收到新的通知,並作出相應準備。

一旦更新開始,客戶便無法復原服務更新。如果在套用服務更新後發現問題,請聯絡 AWS Support 團隊

持續的受管維護更新

這些更新是強制性的,可以直接在維護時段套用,而無須您採取任何動作。這些更新與服務更新提供的更新是分開的。

取代通常可在幾秒內完成。某些執行個體組態和流量模式可能需要較長的時間替換。例如,Redis OSS 主節點可能沒有足夠的可用記憶體,也可能發生寫入流量過高的情況。如果從這種主節點同步空白複本,主節點可能會在嘗試處理內送寫入和同步複本時發生記憶體不足的情形。在這種情況下,主節點會中斷與複本的連線,然後重新啟動同步程序。而且可能需要嘗試很多次才能順利同步複本。如果內送寫入流量持續維持很高的情況,也可能永遠無法順利同步複本。

Memcached 節點不需要同步,因此,無論節點大小如何,都可以更快完成替換。

對於 Redis OSS 節點,替換程序旨在盡全力保留您的現有資料,且需要成功完成複寫。對於單一節點叢集,ElastiCache 會動態產生複本、複寫資料,然後容錯移轉至該複本。對於包含多個節點的複寫群組,ElastiCache 會替換現有的複本,並將資料從主複本同步到新的複本。如果啟用異地同步備份與自動容錯移轉,替換主複本會觸發容錯移轉到僅供讀取複本。對於設定成使用叢集用戶端的叢集組態,以及啟用自動容錯移轉的非叢集組態,計劃的節點替換會在叢集處理傳入寫入請求時完成。如果停用異地同步備份,ElastiCache 會替換主複本,然後從僅供讀取複本同步資料。在此期間,主節點無法使用,導致寫入中斷時間更長。

對於 Memcached 節點,替換程序會啟動空的新節點,並終止目前的節點。新的節點在切換期間將暫時無法使用。切換完成後,在空的新節點填入快取資料時,應用程式的效能可能會降低。

對於 Redis OSS 節點,替換程序旨在盡全力保留您的現有資料,且需要成功完成複寫。我們盡量一次僅從相同的叢集中替換可讓叢集保持穩定的節點數量。您可在不同的可用區域佈建主複本和僅供讀取複本。在這種情況下,節點替換後,將會從不同可用區域的對等節點同步資料。我們還建議您將 Redis OSS 引擎版本升級至 5.0.6 或更高版本,因為這些引擎版本提高了穩定性,且可讓您的叢集在修補活動期間 (如果已啟用自動容錯移轉) 連續服務傳入的寫入請求。最後,如果您的組態僅包括每個碎片一個主複本和一個單一複本,建議在修補之前新增其他複本。這將防止在修補過程中降低可用性和風險。對於單一節點叢集,建議您為 Redis OSS 提供足夠的記憶體,如此處所述。對於包含多個節點的複寫群組,也建議您將替換程序排在低內送寫入流量期間進行。

對於 Memcached 節點,將您的維護時段安排在內送寫入流量較低的時間、測試應用程式的容錯移轉功能,以及使用 ElastiCache 提供的「更加智慧」用戶端。您無法避免資料遺失,因為 Memcached 只將資料放在記憶體中。

對於 Redis OSS,叢集模式組態在受管或非受管操作期間具有最佳可用性,而且始終建議使用支援叢集模式的用戶端連接到叢集探索端點。對於停用的叢集模式,建議一律在所有寫入操作使用主端點。複本節點的各個節點端點可用於所有讀取操作。如果叢集啟用自動容錯轉移,則主節點可能會變更,因此應用程式應確認節點的角色並更新所有讀取端點,確保不會對主節點造成重大負載。停用自動容錯移轉後,節點的角色不會變更,但與啟用自動容錯移轉的叢集相比,受管或非受管操作的停機時間會更長。避免僅將讀取請求導向僅供讀取複本。如果將用戶端設定成為僅將讀取請求導至僅供讀取複本,請確保至少有兩個僅供讀取複本,避免維護期間發生任何讀取中斷。

建議您在排定的維護時段內,由 ElastiCache 為您管理節點替換程序。建立 ElastiCache 叢集時,您可以透過每週維護時段指定偏好的替換時間。若要將維護時段變更為之後更方便的時間,可以使用 ModifyCacheCluster API,也可以在 ElastiCache 管理主控台按一下 Modify。

如果您選擇自行管理替換,可依照使用案例和叢集組態採取不同的動作:

變更維護時段
• 使用備份和還原程序重新啟動執行個體。
• 若您的叢集組態停用叢集模式

o 取代僅供讀取複本 (停用叢集模式) – 在複寫群組手動取代僅供讀取複本的程序。
o 取代主節點 (停用叢集模式) – 在複寫群組手動取代主節點的程序。
o 取代獨立節點 (停用叢集模式) – 取代獨立節點的兩種不同程序。

• 若您的叢集組態啟用叢集模式

o 使用一或多個碎片取代叢集中的節點 – 若要取代節點,您可以使用備份與恢復,或者擴展後再縮減。

如需這些所有選項的詳細說明,請參閱安排節點取代時可採取的動作頁面。

若是 Memcached,只要刪除和重新建立叢集即可。完成替換之後,您的執行個體應該不會再有任何相關聯的排程事件。

若要接收通知,您可以針對重大事件,如排程的取代事件,設定 Amazon SNS 通知。這可透過「事件」區段下的 ElastiCache 管理主控台,或使用 describe-events API 來檢查即將發生的 ElastiCache:NodeReplacementScheduled 事件來實現。

如需設定 SNS 通知,請使用此處提供的資訊。

是,您可以變更叢集的維護時段。若要將維護時段變更為之後更方便的時間,可以使用 API (ModifyCacheCluster 或 ModifyReplicationGroup),也可以在 ElastiCache 管理主控台按一下 Modify。

變更維護時段之後,ElastiCache 服務就會在新指定的時段安排節點維護。請參閱以下範例,了解變更如何生效。

例如,

假設現在是 11 月 9 日星期四 15:00,下一個維護時段是 11 月 10 日星期五 17:00。以下是三種案例及其結果:

• 您將維護時段變更為星期五 16:00 (現在的日期時間之後、下一個排定的維護時段之前)。節點將於 11 月 10 日星期五 16:00 進行替換。
• 您將維護時段變更為星期六 16:00 (現在的日期時間之後、下一個排定的維護時段之後)。節點將於 11 月 11 日星期六 16:00 進行替換。
• 您將維護時段變更為星期三 16:00 (早於這星期中現在的日期時間)。節點將於下一個星期三 11 月 15 日 16:00 進行替換。

需要進行這些替換,才能在基礎主機套用強制軟體更新。這些更新有助於強化我們的安全、可靠性和操作效能。

根據叢集組態,我們可能從相同叢集替換多個節點,但會保持叢集的穩定。如果是碎片叢集,我們盡量不會一次從相同碎片中替換多個節點。此外,我們盡量不會跨所有碎片替換叢集中的大部分主節點。
至於非碎片叢集,我們會嘗試盡可能在維護時段內錯開這些節點替換,以持續保持叢集的穩定。

是,如果這些叢集的維護時段設定在相同的時間,則這些節點可以同時替換。