Longhorn の高度な使用法: バックアップ、リカバリ、ReadWriteMany

バックアップとリカバリ

Longhorn はバックアップと復元の機能を提供します。この機能を使用するには、ボリュームのスナップショットを作成する必要があります。スナップショットは、指定された時点における Kubernetes ボリュームの状態です。

Longhorn UI のボリューム ページで、スナップショットを作成するボリュームをクリックし、ボリュームの詳細ページに移動して、下のスナップショットの作成ボタンをクリックしてスナップショットを作成します。スナップショットを作成すると、ボリューム ヘッダーの前のスナップショット リストに表示されます。たとえば、ここでは、前のテストで使用した mysql ボリュームのスナップショットを作成します。

作成されたスナップショット データは、ノードのデータ ディレクトリの下にも表示されます。

 ➜ツリー/ var / lib / longhorn / レプリカ/ pvc - ec17a7e4-7bb4-4456-9380-353 db3ed4307 - fbf72396 /
 / var / lib / longhorn / レプリカ/ pvc - ec17a7e4-7bb4-4456-9380-353 db3ed4307 - fbf72396 /
 ├── 改訂. カウンタ
├── 巻頭-002 . 画像​ ​
 ├── 巻頭-002.img . ​ ​ ​ メタ
├── 巻。 メタ
├── ボリューム- スナップ- 3 b1f877b - 24 ba - 44 ec - 808 e - ab8d4b15f8dd 。 画像
├── ボリューム- スナップ- 3 b1f877b - 24 ba - 44 ec - 808 e - ab8d4b15f8dd 。 画像. メタ
├── ボリューム- スナップ- 5 d403e8e - 65e8 - 46 d1 - aa54 - 70 aa3280dac4 。 画像
└── ボリューム- スナップ- 5 d403e8e - 65e8 - 46 d1 - aa54 - 70 aa3280dac4 。 画像. メタ
0 ディレクトリ、 8 ファイル

volume-snap-xxx の後のデータは、ページ上のスナップショット名と一致しています。たとえば、ページで作成したスナップショットの名前は 3b1f877b-24ba-44ec-808e-ab8d4b15f8dd です。 img ファイルはイメージ ファイルであり、img.meta は現在のスナップショットのメタ情報です。

 ➜ cat ボリューム- snap - 3 b1f877b - 24 ba - 44 ec - 808 e - ab8d4b15f8dd 。 画像. メタ
{ "名前" : "volume-head-001.img" 、 "親" : "volume-snap-5d403e8e-65e8-46d1-aa54-70aa3280dac4.img" 、 "削除済み" : false 、 "ユーザー作成日" : true 、 "作成日" : "2022-02-22T07:36:48Z" 、 "ラベル" : null }

メタデータには親ファイル イメージが含まれており、これは実際にはスナップショットが増分スナップショットであることを意味します。

手動でスナップショットを作成するだけでなく、Longhorn UI から定期的にスナップショットとバックアップを実行することもできます。これはボリュームの詳細ページでも設定できます。定期ジョブ スケジュール領域の [追加] ボタンをクリックして、スケジュールされたスナップショットを作成します。

タスクを作成するときに、タスクの種類をバックアップにするかスナップショットにするかを選択できます。タスク時間は CRON 式の形式で設定されます。保持するバックアップまたはスナップショットの数とタグを構成することもできます。

ボリュームに長期間新しいデータがない場合、定期的なジョブによって古いバックアップ/スナップショットが同じバックアップと空のスナップショットで上書きされる可能性があるという問題を回避するために、Longhorn は次の処理を実行します。

• 定期的なバックアップジョブは、ボリュームに前回のバックアップ以降に新しいデータがある場合にのみ新しいバックアップを実行します。
• 定期的なスナップショット ジョブは、ボリューム ヘッドに新しいデータがある場合にのみ新しいスナップショットを取得します。

さらに、Kubernetes の StorageClass を使用してスケジュールされたスナップショットを構成することもできます。 StorageClass の recurringJobs パラメータを使用して、スケジュールされたバックアップとスナップショットを構成できます。 recurringJobs フィールドは次の JSON 形式に従う必要があります。

 apiバージョン: ストレージ。 k8s 。 io / v1
 種類: ストレージクラス
メタデータ:
 名前: ロングホーン
プロビジョナー: ドライバー。 ロングホーン。 io
 パラメータ:
 レプリカ数: "3"
 古いレプリカタイムアウト: "30"
 バックアップから: ""
 定期的ジョブ: '[
 {
 「名前」 : 「スナップ」 、
 「タスク」 : 「スナップショット」 、
 「cron」 : 「*/1 * * * *」 、
 「保持」 : 1
 },
 {
 「名前」 : 「バックアップ」 、
 「タスク」 ： 「バックアップ」 、
 「cron」 : 「*/2 * * * *」 、
 「保持」 : 1
 }
 ] '

定期的なジョブごとに次のパラメータを指定する必要があります。

• name: タスクの名前。 recurringJobs では重複する名前を使用しないでください。名前の長さは 8 文字を超えることはできません。
• タスク: タスクの種類。スナップショットまたはバックアップのみをサポートします。
• cron: タスクの実行時間を指定するCron式
• 保持: Longhornはタスクごとにいくつのスナップショット/バックアップを保持するか。1以上

この StorageClass を使用して作成されたボリュームは、これらの定期ジョブで自動的に構成されます。

ボリュームをバックアップするには、Longhorn でバックアップ ターゲットを構成する必要があります。 Longhorn ボリュームのバックアップ データを保存するには、NFS サービスまたは S3 互換のオブジェクト ストレージ サービスを使用します。バックアップターゲットは、「設定/一般/バックアップターゲット」で設定できます。ここではHelm Chartを使用してインストールします。最善の方法は、値ファイル内の defaultSettings.backupTarget をカスタマイズすることです。もちろん、Longhorn UI から直接構成することもできます。たとえば、ここではまずバックアップ ターゲットを nfs サービスとして構成し、バックアップ ターゲットの値を nfs://192.168.31.31:/var/lib/k8s/data に設定し (ディレクトリが存在することを確認)、バックアップ ターゲットの資格情報シークレットを空白のままにします。次に、一番下までスクロールして「保存」をクリックします。

バックアップターゲットが設定されたら、バックアップを開始できます。 Longhorn UI のボリューム ページに移動し、バックアップするボリュームを選択して、[バックアップの作成] をクリックし、適切なタグを追加して、[OK] をクリックします。

バックアップが完了したら、[バックアップ] ページに移動して、対応するバックアップ データを確認します。

これらのバックアップ データは、backupvolumes crd オブジェクトにも対応します。

 ➜ kubectl get バックアップボリューム- n longhorn - システム
最後のバックアップ時に作成された名前最後のバックアップ時に最後の同期された名前
PVC - ec17a7e4-7bb4-4456-9380-353 db3ed4307 2022-02-22 T09 : 23 : 24Z バックアップ- 8ae4af9c49534859 2022-02-22T09 : 23 : 24Z 2022 - 02 - 22 T09 : 41 : 09 Z

次に、NFS サーバーに移動し、マウント ディレクトリの下にバックアップ ストア ディレクトリが作成され、バックアップされたデータが保存されることを確認します。

 ➜ツリー/ var / lib / k8s / データ/ バックアップストア
/ var / lib / k8s / データ/ バックアップストア
└── 巻
└── 5 電子
└── b6
 └── PVC - ec17a7e4-7bb4-4456-9380-353db3ed4307
 ├── バックアップ
│ └── backup_backup - 8 ae4af9c49534859 . cfg
 ├── ブロック
│ ├── 02
 │ │ └── 2 電子
│ │ ―― 022 eefc6526cd3d8fc3a9f9a4ba253a910c61a1c430a807403f60a2f233fa210 。 黒
 ......
 │ └── f7
 │ └── e3
 │ └── f7e3ae1f83e10da4ece5142abac1fafc0d0917370f7418874c151a66a18bfa15 . 黒
└── 巻。 cfg

 51 ディレクトリ、 25 ファイル

同時に、スナップショット リストに移動して、バックアップするスナップショットを選択することもできます。

バックアップ データを取得した後にデータを復元する場合は、対応するバックアップ データを選択し、「最新のバックアップの復元」をクリックしてデータを復元します。

読み書き多数

Longhorn は、NFSv4 サーバーを通じて Longhorn ボリュームを公開し、RWX ワークロードをネイティブにサポートします。使用される RWX ボリュームは、longhorn-system 名前空間の下に share-manager- Pod を作成します。この Pod は、Pod で実行されている NFSv4 サーバーを通じて Longhorn ボリュームを公開する役割を担います。

RWX ボリュームを使用できるようにするには、各クライアント ノードに NFSv4 クライアントをインストールする必要があります。 Ubuntu の場合、NFSv4 クライアントは次のようにインストールできます。

 ➜ apt install nfs - 共通

RPM ベースのディストリビューションの場合、NFSv4 クライアントは次の手順でインストールできます。

 ➜ yum インストールnfs - ユーティリティ

次に、アクセス モードを ReadWriteMany として構成して、以下に示すように PVC オブジェクトを作成します。

 # html - 巻. ヤム
種類: PersistentVolumeClaim
 APIバージョン: v1
 メタデータ:
 名前: html
 仕様:
 アクセスモード:
 -ReadWriteMany
 ストレージクラス名: longhorn
 リソース：
 リクエスト:
 ストレージ: 1 Gi

上記のリソース オブジェクトを直接作成すると、PV が動的に作成され、それにバインドされます。

 ➜ kubectl でPVC HTML を取得
名前ステータスボリューム容量アクセスモードストレージクラス 年齢
html バウンドPVC - a03c5f7d - d4ca - 43e9 - aa4a - fb3b5eb5cf15 1 Gi RWX ロングホーン15 秒
➜ kubectl get pvc - a03c5f7d - d4ca - 43e9 - aa4a - fb3b5eb5cf15 を実行します
名前容量アクセスモード回収ポリシーステータス請求ストレージクラス理由年齢
pvc - a03c5f7d - d4ca - 43e9 - aa4a - fb3b5eb5cf15 1 Gi RWX 削除バウンドデフォルト/ html longhorn 63 s

次に、以下に示すように writer という名前のデプロイメント リソース オブジェクトを作成し、上記で作成した PVC を使用してデータを永続化します。

 # html ライター. ヤム
apiバージョン: アプリ/ v1
 種類: デプロイメント
メタデータ:
 名前: 作家
仕様:
 セレクター:
 マッチラベル:
 アプリ： ライター
テンプレート：
 メタデータ:
 ラベル:
 アプリ： ライター
仕様:
 コンテナ:
 - 名前: 内容
画像： アルパイン： 最新
ボリュームマウント:
 - 名前: html
 マウントパス: / html
 コマンド: [ "/bin/sh" , "-c" ]
 引数:
 - 真の場合; する
日付>> / html / index.html ;
 睡眠5 ;
 終わり
巻数:
 - 名前: html
 永続ボリュームクレーム:
 クレーム名: html

展開後、上記で作成した Longhorn ボリュームは接続された状態になります。

この時点で、共有マネージャー Pod が自動的に起動し、Pod で実行されている NFSv4 サーバーを通じて Longhorn ボリュームが公開されます。

 ➜ kubectl get pods -n longhorn -system -l longhorn 。 ​ ​ io / コンポーネント= 共有- マネージャー
名前準備完了ステータス再起動年齢
シェア- マネージャー- pvc - a03c5f7d - d4ca - 43e9 - aa4a - fb3b5eb5cf15 1 / 1 実行中0 2 m16s
 ➜ kubectl ログ- f 共有- マネージャー- pvc - a03c5f7d - d4ca - 43e9 - aa4a - fb3b5eb5cf15 - n longhorn - システム
time = "2022-02-22T10:07:42Z" level = info msg = "開始 RLIMIT_NOFILE rlimit.Cur 1048576、rlimit.Max 1048576"
 時間= "2022-02-22T10:07:42Z" レベル= info メッセージ= "終了 RLIMIT_NOFILE rlimit.Cur 1048576、rlimit.Max 1048576"
 time = "2022-02-22T10:07:42Z" level = debug msg = "ボリューム pvc-a03c5f7d-d4ca-43e9-aa4a-fb3b5eb5cf15 デバイス /dev/longhorn/pvc-a03c5f7d-d4ca-43e9-aa4a-fb3b5eb5cf15 には、" 形式のファイルシステムが含まれています。encrypted = false ボリューム= pvc - a03c5f7d - d4ca - 43e9 - aa4a - fb3b5eb5cf15
 I0222 10 : 07 : 42.432630 1 mount_linux 。 go : 425 ] ディスク「/dev/longhorn/pvc-a03c5f7d-d4ca-43e9-aa4a-fb3b5eb5cf15」はフォーマットされていないようです。 オプション: [ - F - m0 / dev / longhorn / pvc - a03c5f7d - d4ca - 43e9 - aa4a - fb3b5eb5cf15 ] を使用してタイプ: 「ext4」 としてフォーマットしようとしています。
 I0222 10 : 07 : 42.981928 1 mount_linux .go : 435 ] ディスクが正常にフォーマットされました( mkfs ) : ext4 - / dev / longhorn / pvc - a03c5f7d - d4ca - 43e9 - aa4a - fb3b5eb5cf15 / export / pvc - a03c5f7d - d4ca - 43e9 - aa4a - fb3b5eb5cf15
 time = "2022-02-22T10:07:43Z" level = info msg = "NFS サーバーを起動しています。ボリュームはエクスポートの準備ができています" 暗号化= false ボリューム= pvc - a03c5f7d - d4ca - 43e9 - aa4a - fb3b5eb5cf15
 time = "2022-02-22T10:07:43Z" level = info msg = "NFS サーバーを実行しています!"
 time = "2022-02-22T10:07:43Z" level = info msg = "ボリュームのヘルスチェックを開始しています" encrypted = false volume = pvc - a03c5f7d - d4ca - 43e9 - aa4a - fb3b5eb5cf15

次に、以下に示すようにデプロイメントを作成します。

 # HTML リーダー。 ヤム
apiバージョン: アプリ/ v1
 種類: デプロイメント
メタデータ:
 名前: 読者
仕様:
 レプリカ: 3
 セレクター:
 マッチラベル:
 アプリ: リーダー
テンプレート：
 メタデータ:
 ラベル:
 アプリ: リーダー
仕様:
 コンテナ:
 - 名前: nginx
 画像: nginx : 安定版- アルパイン
ポート:
 - コンテナポート: 80
 ボリュームマウント:
 - 名前: html
 マウントパス: / usr / share / nginx / html
 巻数:
 - 名前: html
 永続ボリュームクレーム:
 クレーム名: html
 ---
 APIバージョン: v1
 種類: サービス
メタデータ:
 名前: 読者
仕様:
 セレクター:
 アプリ: リーダー
タイプ: NodePort
 ポート:
 - プロトコル: TCP
 ポート: 80
 ターゲットポート: 80

上記で作成した PV と PVC は ReadWriteMany アクセス モードであるため、上記のリーダー Pod はライター Pod と同じ PVC を参照できます。上記のリソース オブジェクトを直接作成することで、NodePort を介してアプリケーションにアクセスできるようになります。

 ➜ kubectl get pods - l app = reader
 名前準備完了ステータス再起動年齢
リーダー- b54c4749d - 4 bjxf 1 / 1 実行中0 11 秒
リーダー- b54c4749d - 5 thwz 1 / 1 実行中0 4 m11s
 読者- b54c4749d - drcfk 1 / 1 実行中0 5 分35秒
➜ kubectl get svc リーダー
名前タイプクラスタ- IP 外部- IP ポート( S ) 年齢
リーダーNodePort 10.101 .54 .19 < なし> 80 : 31800 / TCP 84 秒
➜ http://192.168.31.31:31800 にカーソルを移動します。
 ......
 2022 年2 月22 日火曜日10:18:39 UTC
 2022 年2 月22 日火曜日10:18:44 UTC
 2022 年2 月22 日火曜日10:18:49 UTC
 2022 年2 月22 日火曜日10:18:54 UTC
 2022 年2 月22 日火曜日10:18:59 UTC
 ......

次に、リーダー Pod からデータを生成し、アプリケーションにアクセスしてデータが正しいことを確認してみます。

 ➜ kubectl exec reader - b54c4749d - 4 bjxf -- / bin / sh - c "echo longhorn rwx アクセス モード >> /usr/share/nginx/html/index.html"
 ➜ http://192.168.31.31:31800 にカーソルを移動します。
 ......
 2022 年2 月22 日火曜日10:23:49 UTC
 longhorn rwx アクセスモード

ここでは、ボリュームが Longhorn の ReadWriteMany アクセス モードを使用していることを確認します。