LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Longhornとは — k8s専用の分散ブロックストレージ

Longhornとは、Kubernetesクラスタ上で動作するPod向けに永続的なブロックストレージを提供する、Cloud Native Computing Foundation（CNCF、クラウドネイティブ技術の普及を推進する非営利団体）のプロジェクトです^*1。各ボリュームに専用のコントローラを割り当てるマイクロサービス的な設計により、軽量かつシンプルな分散ストレージを実現している点が特徴です^*2。

Longhornとは、Kubernetesクラスタのノードが持つディスクを束ね、Pod（コンテナの実行単位）に永続ボリュームを提供する分散ブロックストレージのことです。2019年にCNCFへ受け入れられ、2021年にIncubating（インキュベーティング、段階的な成熟度評価の中位段階）に区分が上がったプロジェクトで^*1、SUSE傘下のRancherが開発を主導しています^*2。

Kubernetesクラスタ上でデータベースやファイルサーバーのようなステートフル（状態を保持する）なワークロードを動かすには、Podが再作成されてもデータが失われない永続ストレージが要ります。Longhornは各ノードのローカルディスクを組み合わせ、複数ノードにデータを複製することで、単一ノードの障害でもデータを保持できる構成を実現します^*2。

PVの動的プロビジョニングとCSIドライバの仕組み

Longhornは、Kubernetesの標準インターフェースであるCSI（Container Storage Interface、コンテナ向けストレージの共通接続仕様）に対応したドライバとして実装されています^*3。CSIドライバはブロックデバイスを取得してフォーマットし、ノード上にマウントすることで、kubelet（各ノードでPodを管理するk8sのエージェント）がそのデバイスをPodにバインドマウントできるようにします^*3。

利用者はStorageClass（ストレージの種別や設定を定義するk8sリソース）でLonghornをプロビジョナーに指定します。PersistentVolumeClaim（PVC、ストレージ要求）が作成されると、そのStorageClassに応じてLonghorn側が自動でPersistentVolume（PV、実際のストレージ領域）を生成する仕組みです^*4。これが動的プロビジョニングと呼ばれる仕組みで、管理者が事前にボリュームを個別作成しておく必要がありません。

StorageClassには複製数（numberOfReplicas）などのパラメータを指定でき、値を明示しなければLonghornのグローバル設定で定義された既定値が使われます^*4。アプリケーション側はPVCをマウントするだけで、複製や配置の詳細を意識せずに永続ストレージを使えるという点が、Kubernetesネイティブな設計の利点です。

レプリカによるボリューム複製とノード間分散

Longhornのボリュームは、Longhorn Engine（ボリューム単位で動くコントローラプロセス）と複数のレプリカ（データの複製）で構成されます^*5。Engineは、そのボリュームを使うPodと同じノード上で稼働し、複数のレプリカへ同期的にデータを書き込みます^*5。

各レプリカはスナップショットのチェーン（連鎖）を保持しており、最初のスナップショットがベースレイヤーとして機能します^*5。レプリカは異なる物理ノード上に分散配置され、1つのノードやディスクに障害が起きても他のレプリカでデータを維持できる設計です^*2。

ボリュームのレプリカ数がN個の場合、そのボリュームはN−1個までのレプリカ故障を許容できます^*5。つまり最低1つの健全なレプリカが稼働していれば、データの読み書きを継続できるということです。レプリカ数を増やせば耐障害性は高まりますが、その分ディスク容量とネットワーク帯域を消費するため、ノード数や用途に応じた設計が欠かせません。

スナップショットとバックアップ — S3等への外部保存

Longhornには、似ているが役割の異なる2つのデータ保護機能があります。1つはスナップショットで、ボリューム内に保持するポイントインタイム（その時点の状態）のコピーです^*6。もう1つはバックアップで、スナップショットをクラスタ外部のバックアップストアへコピーしたオブジェクトを指します^*6。

スナップショットはクラスタ内のディスク上に残るため、ノード自体が失われるような障害には対応できません。そのためLonghornは、Amazon S3互換のオブジェクトストレージやNFSサーバーをバックアップターゲットとして設定し、スナップショットを外部へ退避できる仕組みを備えています^*6。バックアップターゲットの設定を済ませていないと、バックアップの作成自体がエラーになる点は運用上の留意点です^*6。

バックアップの取得方式には2種類あります。既定の増分バックアップは、前回バックアップ以降に変更されたデータブロックのみを転送する方式で、転送量を抑えられます^*6。バージョン1.7.0以降で追加されたフルバックアップは、全データブロックを転送してバックアップストア側の既存データを上書きする方式で、データ破損時の復旧に使う想定です^*6。取得したバックアップからは新規ボリュームとしてリストアでき、これが災害復旧（DR、Disaster Recovery）の基本手段になります。

Manager・EngineのDaemonSet構成と運用の要点

Longhornはいくつかのコンポーネントで構成されています。Longhorn Managerは、クラスタの各ノードでDaemonSet（全ノードまたは指定ノードに1つずつPodを配置するk8sの仕組み）として動作し、ボリュームの作成・管理やLonghorn UI・CSIプラグインからのAPI呼び出し処理を担います^*7。

Longhorn Engineはボリューム単位のプロセスで、対象ボリュームを使うPodと同じノード上に起動します^*5。この設計により、ローカルI/Oに近い経路でレプリカへの同期書き込みを行えます。UI・API層とデータ経路のプロセスが分離されているため、コンポーネントごとの役割がわかりやすいことも運用のしやすさにつながっています。

導入方法はkubectl applyによる一括適用、またはHelm（Kubernetesアプリケーションのパッケージ管理ツール）チャートのいずれかが用意されています^*8。各ノードにはKubernetes対応のコンテナランタイムに加え、bash・curl・findmnt・grep・awk・blkid・lsblkといった標準的なLinuxコマンド、マウントプロパゲーションの有効化、root権限でのワークロード実行が必要です^*8。加えてV1データエンジンを使うボリュームをホストするノードにはopen-iscsiパッケージの導入とiscsidデーモンの起動が要求されます^*8。導入自体はコマンド1つで進められますが、事前のノード要件確認を飛ばすとボリューム作成時に失敗する原因になります。

Cephなど汎用分散ストレージとの違い

分散ストレージを検討する際によく比較されるのがCeph（Rook経由でk8sに統合される汎用分散ストレージ）です。両者は設計思想が異なるため、用途に応じた選び方が必要になります。

Longhornはブロックストレージに機能を絞ることで、Kubernetesクラスタへの導入と日々の運用にかかる負荷を抑えやすい設計です^*9。一方でファイル共有やオブジェクトストレージが必要な場合は、その用途をLonghorn単体で満たすことはできません。共有ファイルシステムが要る場合はNFS等を別途組み合わせる必要があり、こうした場面ではCephのように複数のストレージ種別を1つの基盤で提供できる構成が選ばれることもあります^*9。

データベースのように高いIOPS（Input/Output Per Second、単位時間あたりの入出力処理数）を要求するワークロードでは、Cephのような設計が優位に働く場面もあると比較記事で紹介されています^*9。どちらが向くかは、対象ワークロードの性能要件とクラスタ規模、社内で確保できる運用体制によって変わってきます。

構築を内製・外注どちらで進めるかの判断軸

Longhornの初期構築自体はコマンド1つで完了しますが、本番運用を見据えると検討すべき論点が複数あります。内製で対応する場合、CSI・PV/PVCの仕組みへの理解に加え、レプリカ数の設計、バックアップターゲットの設定、ノード障害時の切り替え動作の把握が必要になります。これらの検証には一定の学習期間と検証環境での動作確認の工数がかかります。

設計を誤ると影響も大きくなります。例えばレプリカ数が不足した状態でノード障害が重なると、ボリュームが読み書きできなくなるおそれがあります。バックアップターゲットを設定していないと、クラスタ全体の障害時にデータを復旧する手段がないままになります。こうした事態を避けるには、事前のレプリカ設計とバックアップ運用の検証が欠かせません。

専門パートナーに外注する場合は、要件に合わせたレプリカ数・StorageClassの設計、バックアップターゲットの構築、既存クラスタへの導入検証まで一括して対応してもらえる点が内製との違いです。社内にKubernetesストレージの設計・運用経験を持つ人材が確保できていない場合は、初期構築とその後の運用設計を外部パートナーに委ね、社内チームは日々の監視・アプリケーション連携に注力するという役割分担も選択肢になります。

内製・外注いずれの場合も、既存のアプリケーション要件（必要なIOPS・容量・可用性目標）を明確にしてから設計に入ることが、後工程の手戻りを避けるうえで大切です。

まとめ：Longhorn構築を検討する3つの視点

本稿ではLonghornによるKubernetes向け分散ブロックストレージの構築について整理しました。要点を3つに集約すると次の通りです。

第一に、LonghornはCSIドライバを通じてPVの動的プロビジョニングを行い、Engineとレプリカによる同期複製でノード障害に備える設計になっています。第二に、スナップショットとバックアップは役割が異なり、S3等の外部ストレージへのバックアップ設定が災害復旧の前提条件です。第三に、Cephのような汎用分散ストレージと比べてブロックストレージに機能を絞っているため、対応できる用途の範囲を踏まえたうえで内製か外注かを判断する必要があります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：CNCF「Longhorn」
2. *2　出典：Longhorn「What is Longhorn?」
3. *3　出典：Longhorn「Architecture and Concepts」
4. *4　出典：Longhorn「Create Longhorn Volumes」
5. *5　出典：Longhorn「Architecture and Concepts（Engine・Replica）」
6. *6　出典：Longhorn「Create a Backup」
7. *7　出典：Longhorn「Architecture and Concepts（Longhorn Manager）」
8. *8　出典：Longhorn「Quick Installation」
9. *9　出典：OneUptime「Longhorn vs Rook-Ceph: Kubernetes Storage Comparison」

Tweet