共用方式為


Azure Managed Instance for Apache Cassandra 中的管理作業

Azure Managed Instance for Apache Cassandra 是純開放原始碼 Apache Cassandra 叢集的完全受控服務。 此服務也允許根據每個工作負載的特定需求來覆寫組態,以在需要時允許最大的彈性和控制。

本文定義此服務所提供的管理作業和功能。 其也說明在維護混合式叢集時,Azure 支援小組與客戶之間的責任區隔。

壓縮

  • 壓縮有不同的類型。 此服務目前會使用 repair 來執行小型壓縮,如需詳細資訊,請參閱維護。 此作業會執行 Merkle 樹壓縮,這是一種特殊的壓縮。

  • 根據資料表上使用 CQL 設定的壓縮策略 (例如 WITH compaction = { 'class' : 'LeveledCompactionStrategy' }),Cassandra 會在資料表達到特定大小時自動壓縮。 建議您仔細選取工作負載的壓縮策略。 請勿在策略之外執行任何手動壓縮。

修補

  • 作業系統層級的修補會每兩周自動完成。

  • 識別安全性弱點時,將進行 Apache Cassandra 軟體層級的修補。 修補頻率可能會有所不同。

  • 在修補期間,系統會一次一個機架重新啟動機器。 只要不使用仲裁 ALL 設定,而且複寫因數為 3 或更高,應用程式端就不應該會遇到任何降級情況。

  • Apache Cassandra 中的版本格式為 X.Y.Z。 您可以使用服務工具手動控制主要 (X) 和次要 (Y) 版本的部署。 可能需要的 Cassandra 修補程式 (Z) 會自動安裝於該主要/次要版本組合。

附註

該服務目前支援 Cassandra 版本,直到 v5.0。 若要在部署叢集時指定 Cassandra 版本,請參閱 Azure CLI 快速入門

維護

  • 該服務會使用 reaper 來執行 nodetool repair。 此工具每周執行一次。 如果您使用自己的服務進行混合式部署,您可能會想要停用 reaper 功能。

  • 節點狀況監控包含:

    • 主動監視 Cassandra 通道中每個節點的成員資格。
    • 自動偵測和自動緩解基礎設施問題,例如虛擬機、網路、儲存、Linux 及支援軟體故障。
    • 主動監視 CPU、磁碟、仲裁遺失和其他資源問題。
    • 自動恢復失敗的節點(如果可能),並手動恢復節點以響應自動生成的警告。

支援

Azure Managed Instance for Apache Cassandra 可為受控叢集內的資料中心可用性提供 SLA。 如果您在使用該服務時遇到任何問題,請在 Azure 入口網站中提出支援要求

我們的支援權益包括:

  • Cassandra 基礎結構問題的單一連絡點。 不需要分別向 IaaS 團隊提出支援請求,例如負責磁碟、運算和網路的團隊。
  • 透過電子郵件主動提供有關效能瓶頸、規模評估和其他資源限制問題的建議。
  • 全天候的支援涵蓋範圍,包括對任何嚴重中斷問題自動產生的事件。
  • 社群已核准的修補程式支援。 請參閱修補
  • 內部 Java JDK/JVM 工程小組支援。
  • 具有軟體供應鏈安全性的 Linux 作業系統支援。

重要事項

Microsoft 會使用支援案例來調查和診斷所回報的任何問題。 支援可盡可能解決或減輕問題。 您對任何導致 CPU、磁碟或網路問題的 Apache Cassandra 配置層級的使用最終承擔責任。

這類問題的範例包括:

  • 查詢作業沒有效率。
  • 輸送量超過容量。
  • 內嵌的資料超過儲存體容量。
  • keyspace 組態設定不正確。
  • 資料模型或分割區索引鍵策略不佳。

Microsoft可能會調查支援案例,並發現問題的原因位於 Apache Cassandra 組態層級。 這類問題並非來自 Azure 維護的任何基礎平台層級層面。 在關閉案例之前,支援仍會在可能的情況下提供解決或緩解的建議和指導。

建議您 啟用計量 並熟悉 Azure 監視器整合 ,以避免 Apache Cassandra 中的常見應用程式/組態層級問題,例如先前所述。

警告

適用於 Apache Cassandra 的 Azure 受控實例也可讓您執行 nodetoolsstable 命令來進行例行 DBA 管理。 如需詳細資訊,請參閱 適用於 Apache Cassandra 之 Azure 受控實例的 DBA 命令

其中一些命令可能會破壞 Cassandra 叢集的不穩定。 您應該仔細執行這些命令,並且須在非生產環境中測試後再執行。 可能的話,請先使用 --dry-run 選項。 Microsoft 不會為改變預設資料庫配置或資料表的執行命令提供任何 SLA 或支援。

備份與還原

預設會啟用快照集備份,並每隔 24 小時進行一次。 備份會儲存在內部 Azure Blob 記憶體帳戶中,並保留最多兩天(48 小時)。 初始兩個備份不需要任何費用。 會收取額外的備份費用。 請參閱定價。 若要變更備份間隔或保留期間,您可以在 Azure 入口網站中編輯原則:

備份排程設定頁面的螢幕擷取畫面。

若要從現有的備份還原,請在 Azure 入口網站中提出支援要求。 當您提出支援案例時,您需要:

  1. 提供入口網站中您想要還原之備份的備份識別碼。 您可以在 Azure 入口網站中找到此識別碼:

    備份排程組態頁面的螢幕擷取畫面,其中醒目提示了備份識別碼。

  2. 讓我們知道來源資料中心是否已刪除。 這一事實對於確定要從中還原的正確備份帳戶非常重要。

  3. 如果您不需要還原整個叢集,請提供需要還原的密鑰空間和資料表(如果適用)。

  4. 建議您是要在現有叢集中還原備份,還是要在新叢集中還原備份。

  5. 如果您想要還原至新叢集,則必須先建立新叢集。 確定目標叢集在數據中心數目方面符合來源叢集。 確認對應的數據中心有相同數目的節點。 您也可以決定是否要將認證保留在新的目標叢集中。 或者,允許還原以使用最初所建立的使用者名稱和密碼來覆寫該使用者名稱和密碼。

  6. 您也可以決定是要將 system_auth Keyspace 保留在新的目標叢集中,還是允許還原以使用備份中的資料加以覆寫。 Cassandra 中的 system_auth Keyspace 包含授權和內部驗證資料,包括角色、角色權限權及密碼。 預設還原流程會覆寫 system_auth keyspace。

附註

回應從備份還原要求所需的時間取決於您引發的支援案例嚴重性、回應時間的 SLA,以及要還原的數據量。 我們不會提供完成還原所需時間的服務等級協議 (SLA)。 該值會因還原數據量的不同而隨時間變化。

警告

備份適用於意外刪除案例,且不是異地備援。 不建議備份作為區域性中斷的災害復原(DR) 策略使用。 若要防範全區域中斷,建議您部署多個區域。 如需詳細資訊,請參閱 多區域部署的快速入門

安全性

Azure Managed Instance for Apache Cassandra 提供許多內建的明確安全性控制與功能:

  • 使用受控供應鏈強化的 Linux 虛擬機器映像。
  • 作業系統層級的常見漏洞和暴露 (CVE) 監控。
  • 受控虛擬機器上裝載的 Apache Cassandra 和 Prometheus 軟體的憑證輪替。
  • 主動弱點掃描。
  • 主動病毒掃描。
  • 安全編碼做法。

如需安全性功能的詳細資訊,請參閱 適用於 Apache Cassandra 的 Azure 受控實例中的安全性

混合式支援

設定 混合式 叢集時,在服務中執行的自動化重新執行作業會讓整個叢集受益。 此層面包含不是由服務提供的數據中心。 您有責任維護內部部署或外部裝載的數據中心。