PR

[Nutanix]OpLogについて整理

Nutanix
Nutanix logo
スポンサーリンク
スポンサーリンク

はじめに

Nutanixのランダム書き込みI/OバッファであるOpLogについて整理します。

OpLogについて図でイメージを掴む

Nutanix Bible等に載っていますが改めて掲載します。

一枚目はOpLogに書き込まれたデータがReplication Factorの係数に従って複製され、他のノードのOpLogに書き込まれるフローを表しています。

ローカルに書き込まれたデータはRFの係数に従った数だけ複製され、他のノードのOpLogに書き込まれます。書き込まれたことを知らせるAckを全てのノードから受信したら、元々の書き込み要求に対してAckを返します。

2枚目の図では、Write I/Oの性質によって、OpLogに書きこまれるのか、直接Extent Store(永続データストア)に書き込まれるのかを表しています。

ランダム書き込みI/Oは基本的にはOpLogに書き込まれます。しかし、書き込みが一定程度継続した場合には、直接Extent Storeに書き込まれます。シーケンシャル書き込みI/Oの場合は必ずExtent Storeに直接書き込まれます。

OpLogについて

箇条書きで羅列します。重要なキーワードについては太字にしています。

  • OpLog はファイル システム ジャーナルに似ており、ランダム書き込みのバーストを処理し、それらを結合して、データをエクステント ストアに順次排出するためのステージング領域として構築されます。
  • 書き込み時には、データ可用性を目的として書き込みが確認される前に、OpLog は別の n 個の CVM の OpLog に同期的に複製されます。nについては、Replication Factorに依存します。例えば、RF2の場合は、データを異なる1つのCVMのOpLogに同期的にレプリケーションを行います。それが完了したら、ホストに対して書き込み完了のAckを返します。
  • すべてのCVMのOpLog はレプリケーションに参加し、負荷に基づいて動的に選択されます。
  • OpLog は CVM 上の SSD 層に保存され、特にランダム I/O ワークロードに対して非常に高速な書き込み I/O パフォーマンスを提供します。
  • 全てのSSDの間で分散されます。ただし、SSDの上限は1ノードあたり12個まで。Gflag: max_ssds_for_oplog(※)で制御可能みたいです。
  • NVMeが使用される場合は、SATA SSDの代わりにNVMeに配置されます
  • シーケンシャル書き込みの場合、OpLog はバイパスされ、エクステントストアに直接送信されます。
  • データが現在 OpLog 内にあり、排出されていない場合、すべての読み取りリクエストは排出されるまで OpLog から直接実行され、排出された後はエクステントストア/統合キャッシュによって処理されます。 フィンガープリント (別名 Dedup) が有効になっているコンテナの場合、すべての書き込み I/O はハッシュ スキームを使用してフィンガープリントされ、統合キャッシュ内のフィンガープリントに基づいて重複排除できるようになります。
  • OpLog は共有リソースですが、各 vDisk が均等に利用できるようにするため、割り当ては vDisk ごとに行われます。
  • ノードごとに使用される OpLog インデックス メモリの上限に達するまで、I/Opatterns に基づいて必要に応じて、個々の vdisk の OpLog が 6 GB を超えて増加し続けることができます。 この設計上の決定により、I/O の観点からよりアクティブな vdisk が少ない VM がある場合、それほどアクティブではない他の vdisk を犠牲にして、必要に応じて OpLog を増大し続けることができるという柔軟性が可能になります。

※Gflag:Nutanixのサポート経由でのみ修正が許容されるCVMの細かな挙動に関するパラメータ。AOSのバージョンによっても修正方法が異なるようですので、勝手に修正してはいけません。

OpLogの予約容量の計算

ディスク毎のOpLogの予約容量は、下記の公式に基づいて予約量が計算される。

MIN(((Max cluster RF/2)400 GiB)/numDevForOplog), ((Max cluster RF/2)25%) x Remaining GiB)

※MIN(a,b)にて、a < bならばaを、a > bならばbが予約量となります。

8個のSSDを搭載したRF2クラスターで、SSDの容量は1TiBのケース

MIN(((2/2)400 GiB)/ 8), ((2/2)25%) x ~900GiB)
= MIN(50, 225)
= 50 GiBがデバイス毎の予約容量となります。

※900GiBとしているのは、1TiBから内部で使用する容量を除いた概算分と思われます。

8個のSSDを搭載したRF3クラスターで、SSDの容量は1TiBのケース

MIN(((3/2)400 GiB)/ 8), ((3/2)25%) x ~900GiB)
= MIN(75, 337)
= 75 GiBがデバイス毎の予約容量となります。

4個のNVMeと8個のSSDを搭載したRF2クラスターで、それぞれの容量は1TiBのケース

MIN(((2/2)400 GiB)/ 4), ((2/2)25%) x ~900GiB)
= MIN(100, 225)
= 100 GiBがNVMeデバイスの予約容量となります。前述通り、SSDでは予約されません。

参考

Nutanix Cloud バイブル(日本語版) - NutanixBible.jp
The Nutanix Cloud Bible - Nutanix Cloud バイブル(日本語版) - HCIを中心としたNutanixプロダクトのアーキテクチャー詳細解説。高性能・高信頼かつシンプルに管理できるITインフラの仕掛けを、裏...
The Nutanix Cloud Bible - NutanixBible.com
The Nutanix Cloud Bible - A detailed narrative of the Nutanix architecture, how the software and features work and how t...
Nutanixのメリット その 1: 動的に分散されたストレージ | Nutanix Community
本記事はNutanixのSenior Technical Marketing EngineerのBhavik Desaiが2022年8月3日に投稿した記事の翻訳版です。原文はこちら。  我々はNutanix Cloud Platform(N...

コメント