Longhorn、Kubernetes 向けクラウドネイティブ分散ブロックストレージ

[[417918]]

この記事はWeChatの公開アカウント「Hacker Afternoon Tea」から転載したもので、著者はShaoです。この記事を転載する場合は、Hacker Afternoon Tea公式アカウントまでご連絡ください。

Longhorn は、Kubernetes 用の軽量で信頼性が高く、強力な分散ブロック ストレージ システムです。

Longhorn はコンテナとマイクロサービスを使用して分散ブロック ストレージを実装します。 Longhorn は、各ブロック デバイス ボリュームに専用のストレージ コントローラを作成し、複数のノードに保存されている複数のレプリカ間でボリュームを同期的に複製します。ストレージ コントローラーとレプリカ自体は Kubernetes を使用してオーケストレーションされます。

特徴

• 単一障害点のないエンタープライズグレードの分散ブロックストレージ
• ブロックストレージ増分スナップショット
• 効率的な変更ブロック検出に基づいて構築されたセカンダリストレージ（NFS または S3 互換オブジェクトストレージ）へのバックアップ
• 定期的なスナップショットとバックアップ
• 自動化された、中断のないアップグレード。実行中のストレージ ボリュームを中断することなく、Longhorn ソフトウェア スタック全体をアップグレードできます。
• 直感的なGUIダッシュボード

Longhornとは何ですか?

Longhorn は、Kubernetes 向けの軽量で信頼性が高く、使いやすい分散ブロック ストレージ システムです。

Longhorn は次のアーキテクチャをサポートしています。

• AMD64
• ARM64 (実験的)

Longhorn は無料のオープンソース ソフトウェアです。もともと Rancher Labs によって開発されましたが、現在は Cloud Native Computing Foundation のサンドボックス プロジェクトとして開発されています。

Longhorn を使用すると、次のことが可能になります。

• Kubernetes クラスター内の分散ステートフル アプリケーションの永続ストレージとして Longhorn ボリュームを使用する
• ブロックストレージをLonghornボリュームに分割し、クラウドプロバイダーに関係なくKubernetesボリュームを使用できるようにします。
• 複数のノードとデータセンターにまたがるブロックストレージを複製して可用性を向上
• バックアップデータをNFSやAWS S3などの外部ストレージに保存する
• クラスタ間災害復旧ボリュームを作成し、プライマリKubernetesクラスタのデータを2番目のKubernetesクラスタのバックアップから迅速に復元できるようにします。
• ボリュームの定期的なスナップショットをスケジュールし、NFS または S3 互換のセカンダリ ストレージへの定期的なバックアップをスケジュールします。
• バックアップからボリュームを復元する
• 永続ボリュームを中断せずに Longhorn をアップグレードする

Longhorn にはスタンドアロン UI が付属しており、Helm、kubectl、または Rancher アプリ カタログを使用してインストールできます。

マイクロサービスを使用した分散ブロックストレージの簡素化

現代のクラウド環境では数千から数百万の分散ブロック ストレージ ボリュームが必要となるため、一部のストレージ コントローラーは非常に複雑な分散システムになっています。対照的に、Longhorn では、ボリュームを共通のディスク プールから構築できる限り、大規模なブロック ストレージ コントローラを複数の小規模なストレージ コントローラに分割することで、ストレージ システムを簡素化できます。ボリュームごとに 1 つのストレージ コントローラーを使用することで、Longhorn は各ボリュームをマイクロサービスに変換します。コントローラーは Longhorn Engine と呼ばれます。

Longhorn Manager コンポーネントは、Longhorn エンジンが連携して動作するように調整します。

クラウドプロバイダーに依存せずにKubernetesで永続ストレージを使用する

Pod はストレージを直接参照できますが、Pod またはコンテナーを移植できないため、これは推奨されません。代わりに、Kubernetes 永続ボリューム (PV) と永続ボリューム要求 (PVC) でワークロードのストレージ要件を定義します。 Longhorn では、ボリュームのサイズ、IOPS 要件、ボリュームのストレージ リソースを提供するホスト上に必要な同期レプリカの数を指定できます。 Kubernetes リソースは、各 Longhorn ボリュームに対して PVC と対応する PV を使用したり、Longhorn ストレージ クラスを使用してワークロードの PV を自動的に作成したりできるようになります。

レプリカは、基盤となるディスクまたはネットワーク ストレージ上にシン プロビジョニングされます。

複数のコンピューティングホストまたはストレージホストにわたる複数のレプリカのスケジュール設定

可用性を向上させるために、Longhorn は各ボリュームのレプリカを作成します。レプリカはボリュームの一連のスナップショットで構成され、各スナップショットには前のスナップショットからの変更が保存されます。ボリュームの各レプリカもコンテナー内で実行されるため、レプリカが 3 つあるボリュームではコンテナーが 4 つになります。

Longhorn では、各ボリュームのレプリカの数と、レプリカがスケジュールされるノードを構成できます。 Longhorn は各レプリカの状態を監視し、必要に応じてレプリカの修復と再構築を実行します。

各ボリュームに複数のストレージフロントエンドを割り当てる

一般的なフロントエンドには、Linux カーネル デバイス (/dev/longhorn の下にマップ) と iSCSI ターゲットが含まれます。

定期的なスナップショットとバックアップ操作のスケジュールを指定する

これらの操作の頻度 (時間ごと、日ごと、週ごと、月ごと、年ごと)、これらの操作を実行する正確な時刻 (たとえば、毎週日曜日の午前 3 時)、および保持する定期的なスナップショットとバックアップ セットの数を指定します。