在 Azure VM 上執行 Apache Cassandra
警告
本文參考 CentOS，這是 Linux 發行版，已終止服務 (EOL)。 請據以考慮您的使用和規劃。 如需詳細資訊，請參閱 CentOS 生命週期結束指導。
本文說明在 Azure 虛擬機器 上執行 Apache Cassandra 的效能考慮。
這些建議是以您可以在 GitHub 上找到的效能測試結果為基礎。 您應該使用這些建議作為基準，然後針對您自己的工作負載進行測試。
適用於 Apache Cassandra 的 Azure 受控執行個體
如果您要尋找在 Azure 虛擬機器 上執行 Apache Cassandra 的更自動化服務，請考慮使用適用於 Apache Cassandra 的 Azure 受控執行個體。 此服務會將部署、管理（修補和節點健康情況）自動化，以及Apache Cassandra叢集中節點的調整。 它也提供混合式叢集的功能，因此部署在 Azure 中的 Apache Cassandra 資料中心可以加入現有的內部部署或第三方託管 Cassandra 通道。 服務是使用 Azure 虛擬機器擴展集 進行部署。 此服務開發期間已採用下列建議。
Azure VM 大小和磁碟類型
Azure 上的 Cassandra 工作負載通常會使用 Standard_DS14_v2、 Standard_DS13_v2、 Standard_D16s_v5或 Standard_E16s_v5 虛擬機。 Cassandra 工作負載受益於在 VM 中擁有更多記憶體，因此請考慮 記憶體優化 虛擬機大小，例如Standard_DS14_v2或Standard_E16s_v5，或 本機記憶體優化 的大小，例如Standard_L16s_v3。
針對持久性，數據和認可記錄通常會儲存在兩到四個 1 TB 進階受控磁碟 的等量集上（P30）。
Cassandra 節點不應該太密集數據。 我們建議每個 VM 最多有 1 到 2 TB 的數據，並有足夠的可用空間進行壓縮。 若要使用進階受控磁碟達到最高可能的合併輸送量和 IOPS，建議您從少數 1 TB 磁碟建立等量集，而不是使用單一 2 TB 或 4 TB 磁碟。 例如，在DS14_v2 VM 上，四個 1 TB 磁碟的 IOPS 上限為 4 × 5000 = 20 K，而單一 4 TB 磁碟則為 7.5 K。
針對需要較小磁碟容量的 Cassandra 工作負載評估 Azure Ultra 磁碟 。 它們可以在 VM 大小上提供較高的 IOPS/輸送量和較低的延遲，例如 Standard_E16s_v5 和 Standard_D16s_v5。
對於不需要長期記憶體的 Cassandra 工作負載，也就是可從另一個記憶體媒體輕鬆重建數據，請考慮使用 Standard_L16s_v3 或 Standard_L16s_v2 VM。 這些 VM 大小具有大型且快速的本機 暫存 NVM Express （NVMe） 磁碟。
如需詳細資訊，請參閱 比較 Azure 本機/暫時與連結/永續性磁碟 的效能（GitHub）。
加速網路
Cassandra 節點會大量使用網路，從用戶端 VM 傳送和接收數據，以及在節點之間進行通訊以進行複寫。 為了獲得最佳效能，Cassandra VM 受益於高輸送量和低延遲的網路。
建議您在執行 用戶端應用程式存取 Cassandra 的 VM 上，於 Cassandra 節點的 NIC 上啟用加速網路 。
加速網路需要具有最新驅動程式的新式 Linux 發行版，例如 Cent OS 7.5+ 或 Ubuntu 16.x/18.x。 如需詳細資訊，請參閱 使用加速網路建立Linux虛擬機。
Azure VM 數據磁碟快取
Cassandra 讀取工作負載在隨機存取磁碟延遲很低時效能最佳。 建議您使用已啟用 ReadOnly 快取的 Azure 受控磁碟。 ReadOnly 快取提供較低的平均延遲，因為數據是從主機上的快取讀取，而不是移至後端記憶體。
即使快取模式的輸送量限制比未快取模式低，Cassandra 這類隨機讀取工作負載也受益於較低的讀取延遲。 （例如， DS14_v2虛擬機的快取輸送量上限為 512 MBps，而未快取輸送量為 768 MBps。
ReadOnly 快取對於 Cassandra 時間序列和其他工作負載特別有説明，其中工作數據集適合主機快取和數據不會持續覆寫。 例如， DS14_v2 提供 512 GB 的快取大小，其最多可儲存來自 Cassandra 節點 1-2 TB 數據密度的數據。
啟用 ReadOnly 快取時，不會大幅降低快取遺漏的效能，因此，除了最大量寫入的工作負載外，建議使用快取模式。
如需詳細資訊，請參閱 比較 Azure VM 數據磁碟快取組態 （GitHub）。
Linux 預先讀取
在 Azure Marketplace 的大部分 Linux 散發套件中，預設區塊裝置的預先讀取設定為 4096 KB。 Cassandra 的讀取 I/OS 通常是隨機且相對較小的。 因此，藉由讀取不需要的檔案部分，讓大量讀取預先讀取浪費輸送量。
若要將不必要的外觀最小化，請將Linux區塊裝置的預先讀取設定設為8 KB。 （請參閱 DataStax 檔中的建議生產設定 。
針對等量集和數位裝置本身的所有區塊裝置，設定 8 KB 的預先讀取 （例如 /dev/md0）。
如需詳細資訊，請參閱 比較磁碟預先讀取設定 的影響（GitHub）。
磁碟數位 mdadm 區塊大小
在 Azure 上執行 Cassandra 時，通常會建立多個數據磁碟的 mdadm 等量集（也就是 RAID 0），以增加接近 VM 限制的整體磁碟輸送量和 IOPS。 最佳磁碟等量大小是應用程式特定的設定。 例如，針對 SQL Server OLTP 工作負載，建議為 64 KB。 對於數據倉儲工作負載，建議為 256 KB。
我們的測試發現 Cassandra 讀取工作負載的區塊大小 64k、128k 和 256k 之間沒有顯著差異。 似乎有一個小，略顯明顯，優勢為12.8萬塊大小。 因此，我們建議下列各項：
如果您已經使用 64 K 或 256 K 的區塊大小，則重建磁碟陣列使用 128-K 大小並無意義。
對於新的組態，從一開始就使用 128 K 是合理的。
如需詳細資訊，請參閱 測量 mdadm 區塊大小對 Cassandra 效能 的影響 （GitHub）。
認可記錄文件系統
Cassandra 寫入在高輸送量和低延遲的磁碟上時，認可記錄檔效能最佳。 在預設組態中，Cassandra 3.x 會每隔 10 秒將數據從記憶體排清到認可記錄檔，而且不會觸及每個寫入的磁碟。 在此組態中，寫入效能幾乎完全相同，不論認可記錄檔是否位於進階連結磁碟上，還是本機/暫時磁碟。
認可記錄必須持久，因此重新啟動的節點可以從已排清的認可記錄重新建構尚未在數據檔中的任何數據。 為了獲得更好的持久性，請將認可記錄儲存在進階受控磁碟上，而不是儲存在本機記憶體上，如果 VM 移轉至另一部主機，可能會遺失。
根據我們的測試，在 CentOS 7.x 上的 Cassandra 在 xfs 與 ext4 檔系統上認可記錄檔時，寫入效能可能 較低 。 開啟認可記錄壓縮可讓 xfs 效能與 ext4 一致。 壓縮的 xfs 會在我們的測試中執行壓縮和非壓縮的 ext4。
如需詳細資訊，請參閱 ext4 和 xfs 文件系統上的觀察和壓縮的認可記錄 （GitHub）。
測量基準 VM 效能
部署 Cassandra 通道的 VM 之後，請執行一些綜合測試來建立基準網路和磁碟效能。 使用這些測試，根據 VM 大小確認效能符合預期。
稍後，當您執行實際工作負載時，知道效能基準可讓您更輕鬆地調查潛在的瓶頸。 例如，瞭解 VM 上網路輸出的基準效能有助於排除網路作為瓶頸。
如需執行效能測試的詳細資訊，請參閱 驗證基準 Azure VM 效能 （GitHub）。
文件大小
Cassandra 讀取和寫入效能取決於檔大小。 當您使用較大的檔讀取或寫入時，可能會看到較高的延遲和較低的作業/秒。
如需詳細資訊，請參閱 比較各種 Cassandra 檔大小 （GitHub） 的相對效能。
複寫因子
大部分的 Cassandra 工作負載在使用連結的進階磁碟時，都會使用復寫因數 3，在使用暫時/暫時本機磁碟時，甚至使用 5。 Cassandra 通道中的節點數目應該是複寫因數的倍數。 例如，RF 3 表示通道為 3、6、9 或 12 個節點，而 RF 5 會有 5、10、15 或 20 個節點。 使用大於 1 的 RF 和LOCAL_QUORUM一致性層級時，讀取和寫入效能通常低於使用 RF 1 執行的相同工作負載。
如需詳細資訊，請參閱 比較各種復寫因素 的相對效能（GitHub）。
Linux 頁面快取
當 Cassandra 的 Java 程式代碼讀取數據檔時，它會使用一般檔案 I/O，並受益於 Linux 頁面快取。 一次讀取檔案部分之後，讀取內容會儲存在OS頁面快取中。 對相同數據的後續讀取存取速度要快得多。
基於這個理由，針對相同的數據執行讀取效能測試時，第二次和後續讀取看起來會比原始讀取快得多，這需要存取遠端數據磁碟上的數據，或在啟用 ReadOnly 時從主機快取存取數據。 若要在後續執行時取得類似的效能測量，請清除 Linux 頁面快取，然後重新啟動 Cassandra 服務以清除其內部記憶體。 啟用 ReadOnly 快取時，數據可能會位於主機快取中，而且即使在清除 OS 頁面快取並重新啟動 Cassandra 服務之後，後續的讀取也會更快。
如需詳細資訊，請參閱 Linux 頁面快取 的 Cassandra 使用量觀察 （GitHub）。
多數據中心複寫
Cassandra 原生支援多個數據中心的概念，讓您輕鬆地跨多個 Azure 區域 或跨 一個區域內的可用性區域 設定一個 Cassandra 通道。
針對多區域部署，請使用 Azure 全域 VNet 對等互連來連線不同區域中的虛擬網路。 當 VM 部署在相同區域，但在不同的可用性區域中時，VM 可以位於相同的虛擬網路中。
請務必測量區域之間的基準往返延遲。 區域之間的網路等待時間可比區域內的延遲高出 10-100 倍。 使用LOCAL_QUORUM寫入一致性時，預期數據出現在第二個區域中，或在使用 EACH_QUORUM 時大幅降低寫入效能。
當您大規模執行 Apache Cassandra，特別是在多 DC 環境中時， 節點修復 會變得具有挑戰性。 收割機等工具可協助大規模協調修復（例如，跨數據中心的所有節點，一次一個數據中心，以限制整個叢集的負載）。 不過，大型叢集的節點修復尚未完全解決問題，而且適用於內部部署或雲端中的所有環境。
當節點新增至次要區域時，效能不會以線性方式調整，因為某些頻寬和 CPU/磁碟資源會花費在接收和傳送跨區域復寫流量。
如需詳細資訊，請參閱 測量多 dc 跨區域複 寫的影響（GitHub）。
Hinted-handoff 設定
在多重區域 Cassandra 通道中，具有一致性層級LOCAL_QUORUM的寫入工作負載可能會遺失次要區域中的數據。 根據預設，Cassandra 提示的交接會節流至相對較低的最大輸送量和三小時的提示存留期。 對於大量寫入的工作負載，我們建議增加提示的交接節流和提示時段時間，以確保提示在復寫之前不會捨棄。
如需詳細資訊，請參閱 跨區域複 寫中提示交接的觀察 （GitHub）。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- 阿森·弗拉基米爾斯基 | 首席客戶工程師
其他投稿人：
- Theo van Kraay |資深項目經理
若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。
下一步
如需這些效能結果的詳細資訊，請參閱 Azure VM 效能實驗上的 Cassandra。
如需一般 Cassandra 設定的相關信息，而不是 Azure 特有的設定，請參閱：