今回は、2022年4月にリリースされた、Ubuntu 22.04 LTS(Jammy Jellyfish) で正式に使用可能になった OpenZFS 2.1 について確認します。

Ubuntu 22.04 LTS での ZFS

Ubuntu 20.04LTS(Focal Fossa) では、ZFSでのブート構成は実験的採用(Experimental)でした。22.04LTSでは、ZFSブート構成の実験的という文字が取れ、正式採用となっています。また、ZFSのバージョンが0.8.3から2.1.3 にアップデートされています。

22.04 での ZFSブート構成は、20.04と同じくインストーラから設定可能です。ディスクのパーティション決定は自動的に行われ、設定できないところも 20.04 と同様です。以下は、実際にインストールした際のデバイスのパーティション情報です。1TBのストレージを使用した際のディスク割り振りは、20.04 と変更ありません。

## Ubuntu 20.04 LTS
ディスク /dev/nvme0n1: 931.53 GiB, 1000204886016 バイト, 1953525168 セクタ
Disk model: XXXXXXXXXXXXXXXXXXXXXXXXXXXXX 1TB
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: gpt
ディスク識別子: XXXXXXXX-9999-XXXX-9999-XXXXXXXXXXXX

デバイス       開始位置   最後から     セクタ サイズ タイプ
/dev/nvme0n1p1     2048    1050623    1048576   512M EFI システム
/dev/nvme0n1p2  1050624    5244927    4194304     2G Linux スワップ
/dev/nvme0n1p3  5244928    9439231    4194304     2G Solaris ブート
/dev/nvme0n1p4  9439232 1953525134 1944085903   927G Solaris ルート


## Ubuntu 22.04 LTS
$ sudo fdisk -l /dev/nvme0n1
51 GiB, 1000204886016 バイト, 1953525168 セクタ
Disk model: XXXXXXXXXXXXXXXXXXXXXXXXXXXXX 1TB
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: gpt
ディスク識別子: XXXXXXXX-9999-XXXX-9999-XXXXXXXXXXXX

デバイス       開始位置   最後から     セクタ サイズ タイプ
/dev/nvme0n1p1     2048    1050623    1048576   512M EFI システム
/dev/nvme0n1p2  1050624    5244927    4194304     2G Linux スワップ
/dev/nvme0n1p3  5244928    9439231    4194304     2G Solaris ブート
/dev/nvme0n1p4  9439232 1953525134 1944085903   927G Solaris ルート

Solarisと違い、Linuxではswap領域の使用はオプションです。特にkubernetes 使用時は、swap使用はできないので、swap領域をZIL領域にしてもいいでしょう。ただし、同じストレージにZILやL2ARCを使用するのは、障害発生時に問題があるため非推奨です。

Ubuntuのインストーラでは、1つのストレージデバイスにしかインストールできません。そのため、ブートストレージを RAID-Z にはできません。ただし、同じサイズのストレージデバイスをミラー構成として追加可能です。ブートデバイスを二重化したい場合、SSDなどにブート領域を置き、NVMeはZILやL2ARCとしての使用をお勧めします。

OpenZFS 2.1での変更点

OpenZFS 0.8.3 から 2.1.3 への変更を簡単に上げると、以下のようになります。

• シーケンシャルなリシルバ処理
  シーケンシャルなレジルバー機能は、従来のヒーリングレジルバーにかかる時間より早く、故障したミラーvdevを再構築できます。可能な限り迅速に復元、プールを自動的にscrub、すべてのデータのチェックサムを検証することにより、完全な冗長性を確保します。
• 永続的なL2ARC
  L2ARCキャッシュデバイスは再起動後も持続するため、zpoolのインポート後に通常必要なキャッシュのウォームアップ時間が不要になります。
• ZStandard 圧縮
  ZStandard 圧縮は最新の高性能汎用圧縮アルゴリズムで、gzip と同等かそれ以上の圧縮レベルを提供し、はるかに優れた性能を持ちます。ZStandardは、好ましいパフォーマンスと圧縮のトレードオフを選択できるように、圧縮レベルの大きな選択肢を提供します。
• Redacted zfs send/receive
  Redactedストリームを使用すると、ユーザはデータのサブセットをターゲットシステムに送信できます。ユーザーは領域の節約や、機密情報の選択的除外のために、与えられたデータセット内の重要でないデータを送信しません。
• 分散型スペアRAID (dRAID)
  新しい分散型RAIDZを使用してプールを作成し、統合されたホットスペアを使用して復元時間を劇的に短縮できます。完全な冗長性は、通常ディスクを交換するよりも短い時間で、zpool を復元できます。
• 互換性プロパティ
  新しい互換性プロパティにより、管理者は zpool で有効にすべき機能のセットを指定できます。この細かい制御により、ポータブルプールの作成が容易になり、OpenZFSのバージョン間やプラットフォーム間でプールの互換性を維持できます。
• InfluxDB サポート
  zpool influxdbコマンドでプールの統計情報をInfluxDBの時系列データベースに収集し、分析・監視に利用します。

終わりに

今回は、4月にリリースされたUbuntu 22.04LTS で使用している、OpenZFS について変更点を確認しました。次回は、OpenZFS 2.1以降の変更点について掘り下げてみます。次回をお楽しみに。

さて、このコラムを掲載いただいているデジタル・ヒュージ・テクノロジー社は老舗のOSSインテグレーターです。特にLinuxは強く、OSSを活用した業務システムの実績も多いです。興味がある方は以下のページもご覧ください。
DHT OSS導入コンサルティングサービス