Longhornとは？Kubernetes分散ブロックストレージの仕組みとRook/Cephとの選び分けを実装者目線で解説

Longhornは、Kubernetesクラスタを構成する各ノードの内蔵ディスクをかき集めて、コンテナから使える永続ボリュームとして払い出すストレージ基盤です。外部のストレージ装置やクラウドのブロックストレージを用意しなくても、手元のノードだけでレプリカ付きのブロックボリュームを組み立てられます。この記事では2026年9月時点の1.12系を前提に、アーキテクチャ、導入の前提条件、スナップショットとバックアップを分けた運用設計、そしてRook/Cephやマネージドストレージとの選び分けを実装者の目線で整理しました。PVやPVCという枠組み自体の設計はKubernetes永続化ストレージの基本設計で補完してください。

まとめ：Longhornは手元のノードのディスクを永続ボリュームに変える薄い層

Longhornの立ち位置は、専用ストレージを持たないKubernetesクラスタに永続ボリュームを供給する薄い層です。各ノードのディスク領域をレプリカとして複製し、iSCSI経由でブロックデバイスとしてPodへ差し出します。CNCFには2019年10月11日に受け入れられ、2021年11月4日からIncubatingレベルに置かれているプロジェクトで、2026年9月時点の安定版は1.12系です。

採用の判断は、外部ストレージを用意できるかどうかという一点から始まります。マネージドなKubernetesサービス上でクラウドのブロックストレージを普通に呼べる環境なら、そちらのCSIドライバを使うほうが運用の担当範囲は小さくなるでしょう。オンプレミスやベアメタル、エッジ拠点のように、手元のディスクしか使えない前提のときにLonghornの価値が立ち上がります。

導入で最も事故が起きるのは、スナップショットをバックアップの代わりだと思い込む設計です。スナップショットはレプリカと同じディスク上に積まれる層であり、ノードやディスクごと失われれば一緒に消えます。外部のバックアップストアを最初に決め、定期実行の仕組みまで組んで初めて運用に載る、という順序を崩さないでください。

Longhornの定義と、ノード内蔵ディスクを分散ブロックストレージに束ねる仕組み

まず、この基盤がクラスタのどこに置かれ、何をブロックデバイスに変換しているのかを押さえます。

各ノードのディスクをレプリカとして束ねブロックボリュームを提供する

Longhornは、クラスタ内の各ノードが持つディスク領域を管理下に置き、そこにボリュームの実体データを分散して配置します。1つのボリュームには既定で3本のレプリカが作られ、それぞれ別のノードへ散らされる仕組みです。レプリカがN本あればN-1本までの同時障害に耐えられる計算になり、ノード1台の停止ではボリュームが読み書き可能なまま残ります。

Podから見た姿は、ごく普通のブロックデバイスです。ファイルシステムをその上に作って使うため、データベースのようにブロックデバイスを要求するワークロードをそのまま載せられます。オブジェクトストレージのようにAPI経由で扱う形式ではないため、アプリケーション側の書き換えは不要です。

ディスクはノードごとに複数登録でき、それぞれにスケジューリング可否と予約容量を設定します。容量の見積もりで見落としがちなのは、レプリカ数のぶんだけ実容量を消費する点です。100GiBのボリュームをレプリカ3本で作れば、クラスタ全体では300GiBのディスクが埋まります。

マネージャとエンジンの二層構造でボリューム単位に障害を閉じ込める

内部はコントロールプレーンとデータプレーンの二層で構成されます。コントロールプレーンにあたるManagerは全ノードにDaemonSetとして常駐し、ボリュームの作成・レプリカの配置・障害時の再構築を指揮します。データプレーンにあたるEngineは、ボリュームが接続されたノード上で起動するストレージコントローラです。

設計上の要点は、Engineが1つのボリュームだけを担当することにあります。共有のストレージコントローラが全ボリュームを捌く構造だと、1本の異常が全体を巻き込みかねません。ボリュームごとにプロセスを分けておけば、単一のEngine障害の影響範囲はそのボリュームに閉じます。

読み出しの経路も理解しておくと運用の勘所がつかめます。Engineはまずライブデータを参照し、そこに無ければ新しいスナップショットから順に古い層へ遡る構造です。スナップショットを整理せず何十層も積み上げた状態は、読み出し性能を静かに削っていく要因になります。

CSIドライバとStorageClassでPVCから動的にボリュームを切り出す

KubernetesとのつなぎはCSIドライバが担い、インストール時にlonghornという名前のStorageClassが既定で用意されます。開発者はPVCを書くだけでよく、ボリュームの実体がどのノードのどのディスクに置かれるかを意識せずに済む構造です。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 20Gi

StorageClassのパラメータでは、レプリカ数・ファイルシステム種別・データローカリティ・削除時の挙動を制御できます。用途ごとに複数のStorageClassを定義し、ログ置き場はレプリカ2本、データベースは3本、といった具合に切り替える運用が扱いやすいはずです。コンテナオーケストレーションの基本的な考え方と同じく、宣言した状態へ寄せ続ける動きに任せる形になります。

ReadWriteManyで複数Podから同時に書きたい場合は、内部でNFSのshare-managerが立ち上がって共有アクセスを仲介します。この経路を使うには全ノードにNFSv4クライアントが入っている必要があり、要件を満たさないままRWXのPVCを投げると起動しない状態で止まります。

Longhorn導入の前提条件と、インストールから永続ボリューム作成までの手順

導入でつまずく箇所はほぼ前提条件に集中します。ノード側の準備を先に済ませるのが近道です。

Kubernetes 1.25以上とopen-iscsiが動く全ノードが前提になる

公式ドキュメントが示す1.12系の要件は、Kubernetes v1.25以上です。V1データエンジンを使う標準構成では、全ノードにopen-iscsiが導入され、iscsidデーモンが稼働している状態が求められます。加えて、iscsidサービスの起動前にiscsi_tcpモジュールが読み込まれている必要があり、ここが抜けているとボリュームのアタッチ段階で失敗します。

バックアップ機能を使うならNFSv4・v4.1・v4.2のいずれかに対応したクライアントが要り、前述のReadWriteManyでも同じ要件が効いてきます。ノードイメージを自分たちで作っている環境では、これらをイメージ側に焼き込んでおくとノード追加時の手作業が消えます。

環境チェック用のスクリプトが公式から配布されているため、インストール前に一度流して不足を洗い出してください。TalosやFlatcarのようなイミュータブル系のディストリビューションは、パッケージ導入の手順が通常のLinuxと異なります。

HelmまたはkubectlでインストールしUIから状態を確認する手順

導入方法はkubectl・Helm・Fleet・Flux・ArgoCD・Rancherのカタログ、そしてエアギャップ環境向けの手順まで用意されています。GitOpsで管理しているクラスタならHelmチャートを宣言に含めるのが素直な流れです。

helm repo add longhorn https://charts.longhorn.io
helm repo update
helm install longhorn longhorn/longhorn \
  --namespace longhorn-system --create-namespace \
  --set defaultSettings.defaultReplicaCount=3

導入が終わるとlonghorn-system名前空間にManagerとUIが立ち上がり、ブラウザからボリューム・ノード・ディスクの状態を確認できます。UIは既定で認証が付かないため、そのまま外部へ出さない配慮が要ります。

初回に必ず見ておきたいのはNodeタブのディスク一覧です。ノードのルートパーティションが既定のディスクとして登録されるため、専用のディスクやマウントポイントを使いたい場合はここで登録し直し、ルート側のスケジューリングを無効にします。ここを放置したまま運用に入ると、ボリュームの増加でノードのルート領域が埋まる事故につながります。

レプリカ数とデータローカリティの設定が可用性と読み書き遅延を左右する

既定のレプリカ数3は、ノードが3台以上ある前提での推奨値です。2台構成のクラスタで3本を要求するとスケジューリングが通らず、ボリュームがDegraded状態で止まります。小規模なエッジ拠点ではレプリカ2本に落とし、そのぶんバックアップの頻度を上げて釣り合いを取る設計になります。

データローカリティの設定は、Podが動くノードにレプリカを1本置くかどうかを決める項目です。無効のままだと読み出しが常にネットワーク越しになる場合があり、best-effortにしておけば可能な範囲で同一ノードに寄せてくれます。遅延に敏感なワークロードでは、この一設定が体感性能を分けます。

レプリカの再構築が走る際は、ノード間で実データが流れる点も見落とせません。1TiBのボリュームを持つノードを1台落とせば、その容量ぶんのトラフィックがクラスタ内で発生します。ストレージ用のネットワークを分離するか、再構築の同時実行数を絞って業務トラフィックへの影響を抑えてください。

スナップショットとバックアップを分けて設計する災害復旧の運用手順

台帳運用で最も差が出るのがこの領域です。2つの機能は名前が似ていますが、守れる範囲がまったく違います。

スナップショットはクラスタ内の層でありバックアップの代替にならない

公式ドキュメントはスナップショットを「イメージのレイヤ」に例え、最も古いスナップショットが基底層になると説明しています。実体はレプリカと同じディスク上に置かれる差分の層で、取得は一瞬で終わり、直前の状態への巻き戻しも高速です。アプリケーションの更新前に取っておく用途では扱いやすい機能でしょう。

ただし、これは同じディスク上の話です。ノードのディスクが物理的に壊れれば、そのレプリカのスナップショットも同時に失われます。クラスタごと失われる災害に対しては何の防御にもなりません。「スナップショットを毎日取っているから安心」という状態は、実質的にバックアップ未実装だと考えてください。

層を積み過ぎると読み出し時の遡りが深くなり、ディスク使用量も膨らみます。不要なスナップショットを削除する定期ジョブを併せて仕込み、層の数を一定に保つ運用が要ります。

バックアップストアにS3互換ストレージやNFSを指定して外部へ退避する

バックアップは、スナップショットのチェーンを平坦化してクラスタ外のバックアップストアへ書き出す機能です。転送は2MiBのブロック単位で行われ、変更のないブロックは複数のバックアップ間で使い回されるため、2回目以降の所要時間と通信量は初回より小さくなります。

バックアップストアの実体には、S3互換のオブジェクトストレージかNFSの共有を指定します。クラウドを併用するならS3やそれに準じたサービス、オンプレミスで完結させたいならMinIOのようなS3互換ストレージを別クラスタや別筐体に立てる構成です。ここで押さえるべき原則は、Longhornが載っているクラスタの外に置くことにあります。同じノード群の上にバックアップ先を作っても、災害時には共倒れです。

認証情報はSecretとして登録し、UIまたはBackupTargetの設定で接続先を指定します。設定直後にテスト用のボリュームでバックアップと復元を通し、リストアまで到達することを確かめてください。取得できているつもりで復元できない状態は、運用で最も高くつく失敗です。

RecurringJobで定期実行しDRボリュームで復旧時間を短縮する

定期実行はRecurringJobというカスタムリソースで定義します。スナップショットの作成、古いスナップショットの削除、バックアップの作成、ファイルシステムのトリムといった種類をcron形式のスケジュールで指定し、ボリュームやグループに紐づける仕組みです。ラベルでグループを切っておけば、新しく作られたボリュームにも自動で同じジョブが適用されます。

典型的な組み合わせは、業務時間中に数時間おきのスナップショット、深夜に日次バックアップ、そして一定世代を超えたスナップショットの削除という三段構えです。保持世代数もジョブ側で指定できるため、際限なく積み上がる状態を避けられます。

遠隔地への切り替えを速くしたい場合は、DR（災害復旧）ボリュームを使います。これは別クラスタ側で待機状態のボリュームを作り、バックアップストアを定期的に見に行って差分を先に取り込んでおく仕組みです。障害時には差分の残りだけを適用してアクティブ化すればよく、ゼロから復元する場合に比べて復旧までの時間を短く抑えられます。ポーリング間隔とバックアップの頻度が、そのまま復旧時点の粒度を決める関係になります。

V2データエンジンの現在地と、Longhornの性能を見積もるときの前提

性能の話題では、2つのデータエンジンが混同されがちです。それぞれの成熟度を切り分けて扱います。

V2データエンジンは技術プレビューで本番採用の判断は保留が妥当

V2データエンジンは、SPDKを土台にしてデータ経路をユーザー空間へ移した新しい実装です。カーネルのストレージスタックを通さずに入出力を処理するため、書き込みで2〜4倍、ランダム読み出しで2〜3倍といった改善が初期のベンチマークで報告されています。1.12系ではボリュームの高速クローンやシャーディングも入りました。

ただし公式ドキュメント上の位置づけは、2026年9月時点でも技術プレビューです。要件も重く、NVMe/TCPのためにLinuxカーネル6.7以上、vfio_pci・uio_pci_generic・nvme-tcpの各モジュール、ノードあたり2MiBページで2GiB分のHugePages、AMD64ではSSE4.2への対応が求められます。既存のノードイメージをそのまま流用できる話ではありません。

判断としては、本番の永続データをV2に預けるのは時期尚早と見るのが妥当でしょう。検証クラスタで性能特性を測っておき、GA表記に変わった時点で移行を検討する段取りが現実的です。

V1エンジンの性能はノードのディスクとネットワーク帯域で決まる

標準のV1エンジンでは、書き込みが同期的に全レプリカへ複製されます。したがって書き込み性能の上限は、最も遅いレプリカのディスクとノード間ネットワークの往復に引きずられる構造です。ノードのローカルディスクが高速なNVMeでも、1Gbpsの共用ネットワークで結ばれていれば、そこが天井になります。

実装の指針は3つに整理できます。第1にストレージ用のディスクは業務用途と分け、可能ならSSD以上を割り当てること。第2にノード間は10Gbps以上を用意し、可能ならストレージトラフィックを別セグメントへ逃がすこと。第3にIOPSを強く要求するデータベースは、レプリカ数とデータローカリティを含めて実測してから載せる判断をすることです。

Rook/CephやクラウドマネージドとLonghornを選び分ける判断軸

ここからは、導入手順の記事が踏み込まない採用可否の線引きを、条件付きで言い切ります。

Rook/Cephとはスケールとプロトコル要件の広さで役割が分かれる

同じくKubernetes上で分散ストレージを構成する選択肢に、CephをオペレータでKubernetes上に載せるRook/Cephがあります。両者は守備範囲が違い、機能の多寡だけで比べると判断を誤りかねません。Rook側の構成と運用の詳細はRook Cephのオペレータ構成と採用判断で扱っています。以下に主要な観点を並べます。

Longhornが向くのは、ノード数台から十数台の規模でブロックボリュームだけがあればよいケースです。導入が半日で終わり、UIで状態を追えて、障害時の挙動が読みやすい。この扱いやすさが最大の資産になります。Rook/Cephはオブジェクトやファイル共有まで1つの基盤で賄え、数十ノード規模でも伸びますが、そのぶんチューニングと障害対応に専任の知識が要ります。

Longhornを採用してよい3つの条件を実装の制約から整理する

第1の条件は、外部ストレージやクラウドのブロックボリュームを使えない前提があることです。ベアメタルのオンプレミス、工場や店舗のエッジ拠点、閉域網の検証環境など、手元のノードのディスクしか選択肢がない環境なら導入の価値が明確に立ちます。

第2の条件は、必要な提供形式がブロックボリュームに収まることです。S3互換のAPIや大規模なファイル共有まで1つの基盤に求めるなら、設計の初期段階から別の選択肢を検討すべきでしょう。ReadWriteManyは使えますが、内部のNFS経由という構造上、高負荷な共有ファイルサーバー用途には向きません。

第3の条件は、ストレージ運用を自社で持つ覚悟があることです。バックアップストアの設計、ノード追加時の準備、バージョン更新の検証は自分たちの仕事になります。ここに人手を割けるかが分岐点で、体制側から詰めるならインフラ構築の支援のように既存環境の調査から運用設計までまとめて引き受けられる相手と組むと、導入直後の手探り期間を短く済ませられます。

見送るべき場面と、クラウドのマネージドストレージへ寄せるべき判断

見送るべき筆頭は、マネージドなKubernetesサービスの上でクラウドのブロックストレージを普通に呼べる環境です。Amazon EKSのような基盤でAmazon EBSのCSIドライバを使えるなら、レプリカ配置もディスク障害への対応も事業者側の責任範囲に入ります。そこへ自前の分散ストレージを重ねると、可用性の担保を二重に背負い込むだけです。

2つ目は、ノードが2台以下の構成です。レプリカを分散させる余地がなく、ノード1台の停止がそのままボリュームの停止につながります。外部のNFSサーバーやクラウドのボリュームを1本引く構成のほうが素直でしょう。

3つ目は、極端に高いIOPSを継続的に要求する基幹データベースです。同期レプリケーションのぶん書き込みがネットワークに縛られるため、専用のストレージ装置やクラウドの高性能ボリュームと比べると不利になります。導入前に実データに近い負荷で計測し、要求値を満たすかを数字で確かめてから決めてください。

LonghornをKubernetesで運用するときによくある質問

設計と検証の場面で繰り返し挙がる論点を、実装の観点から答えます。

Longhornは本番環境で使えますか？

標準のV1データエンジンは安定版として提供されており、本番での利用実績もあります。2026年9月時点の安定版は1.12.1で、CNCFのIncubatingプロジェクトとして開発が続いています。ただしバックアップストアの構成とレプリカ配置の設計を済ませていることが前提で、既定値のまま入れただけの状態は本番運用とは呼べません。

スナップショットとバックアップはどう違いますか？

スナップショットはクラスタ内のレプリカと同じディスク上に積まれる差分の層で、直前状態への巻き戻しに使います。バックアップはそのチェーンを平坦化し、S3互換ストレージやNFSといった外部のバックアップストアへ2MiBブロック単位で書き出す機能です。ディスク障害やクラスタ全損に備えられるのはバックアップだけなので、両方を組み合わせて運用してください。

ノードは最低何台必要ですか？

既定のレプリカ数3を満たすには3台以上が要ります。2台構成でもレプリカ数を2に落とせば動きますが、1台停止した時点で冗長性が消えます。検証目的の1台構成ではレプリカ1本になり、可用性の仕組みは働きません。

V2データエンジンに切り替えるべきですか？

2026年9月時点では見送りを推奨します。公式ドキュメント上の位置づけが技術プレビューであり、Linuxカーネル6.7以上・HugePagesの確保・特定のカーネルモジュールといった要件も重いためです。性能改善は明確に報告されているので、検証クラスタで測りながらGA表記への切り替えを待つ進め方が無難でしょう。

Rancher以外のKubernetesでも動きますか？

動きます。もともとRancher発のプロジェクトですが、CNCFへ寄贈された現在はKubernetes v1.25以上であればディストリビューションを問いません。kubectl・Helm・ArgoCD・Fluxなど一般的な導入経路が用意されています。

関連記事

• Kubernetes永続化ストレージ入門｜PV・PVC・StorageClass：Longhornが差し込まれる枠組み。
• MinIOとは？S3互換オブジェクトストレージの仕組み：バックアップストアの構築候補。
• オブジェクトストレージとは？ブロックとの違い：提供形式の違いを押さえる土台。
• Amazon EBSとは？ボリュームタイプと料金モデル：クラウド側のブロックストレージ。
• Amazon EKSとは？ノード提供形態と料金モデル：マネージドk8sを選ぶ場合の比較先。
• コンテナオーケストレーションとは？Kubernetesの役割：前提となる基盤の考え方。