.
OCP環境のバックアップ手法を検討する
本稿では、OpenShift Container Platform（以下、OCP）環境のバックアップについて、「何を考慮すべきか」「どのようにバックアップするか」といった視点で整理するとともに、これからOCPのバックアップで利用が増えると考えられるコンテナ仮想化の新機能「Container Storage Interface（以下、CSI）スナップショット」について、IBM Spectrum Protect PlusのKubernetes backup supportを具体例に説明する。
従来のインフラ環境では、VMware ESXiやIBM Power Systemsなどハイパーバイザー仮想化技術により環境の仮想化が進められてきたが、最近はコンテナ仮想化技術を使用するOCPが新しいインフラとして注目を集めている。
コンテナは新しいプロセスとして起動し、停止する場合には消滅するという基本的な性質を備える。そのため使用するデータについても一時的なデータという扱いが基本となり、現時点では定番と呼べるようなバックアップソリューションは確立されていない。
OCPを構成するコンポーネントは、OCPの管理サービスが稼働する「Masterノード」、アプリケーションコンテナが稼働する「Workerノード」に大別できる。そこでバックアップの対象として、各ノードのシステムバックアップとデータバックアップ、ノード上で稼働するコンテナイメージのバックアップとコンテナのデータバックアップなどに大まかに整理して検討を進める。
まず、ノードのシステムバックアップとデータバックアップの必要性について検討する。
Masterノード、Workerノードはともに最小構成であっても3ノードで構成するので、ノードの単体障害が発生しても残ったノードで役割が継続できる。
復旧方法として、Masterノードは必要な管理情報（etcd）を残存ノードからリカバリーできるので、システムバックアップは基本的に不要であるが、全体障害の対策として管理情報をバックアップすることも可能である。一方のWorkerノードはコンテナを稼働させるためのノードであり、固有のデータはもたないので、システムバックアップ、データバックアップともに不要である。
次に、コンテナとコンテナのデータのバックアップについて整理する。
コンテナの元となるイメージはアプリケーションなので、通常は実働環境で直接変更なすることはない。そのためバックアップは不要となるが、開発環境でアプリケーションとしてコード管理が行われていることが前提となる。
コンテナのデータはコンテナを停止すると失われる性質があるので、OCP環境内にデータを保持する場合は、外部ストレージなどコンテナ外部の領域を、コンテナが止まっても消えないPersistent Volume（PV）としてコンテナにマウントして、データを置く必要がある（PV上のデータをバックアップする方法については後述する）。
以上のバックアップ方針を整理すると、図表1になる。
.
.
PV上で実行する
4つのデータバックアップ方式
PVはKubernetesで管理するストレージの単位であり、プラグインを導入することで多様な形式のストレージがPVとして利用可能になる。
PVはコンテナにマウントして使用するため、PV上のデータのバックアップ方法は、PVへのアクセス方式で以下の4種類に分類できる。
1つ目は、PVをマウントしているコンテナ、つまりアプリケーションが用意する機能でバックアップする方法である。バックアップデータの過不足や、整合性に問題の出る可能性が低いことためリストアの信頼性は高いが、バックアップの粒度や保管方法などはアプリケーションに依存することになる。
2つ目は、PVをコンテナ外のレイヤであるストレージ装置のコピー機能などで複製する方法である。コンテナ仮想化に依存しない実装なので、考慮点などは従来のハイパーバイザー仮想化環境と同じである。つまりアプリケーションの状態に関係なく、ストレージとして断面を複製するので、静止点の確保やコンテナ、PV間でのデータの整合性に注意を向ける必要がある。
3つ目は、コンテナ対応のバックアップソフトウェアを使用する方法である。コンテナ化したバックアップソフトウェアのエージェントを、バックアップ対象コンテナのサイドカーコンテナとして構成することで、PVの共有が可能になり、PVからデータを読み出して、外部のバックアップサーバーに転送する。バックアップソフトウェアによる多様なバックアップ管理が可能になるが、バックアップとしてどのファイルを保管すればよいか、などはアプリケーションに合わせて検討する必要がある。
4つ目は、CSIのスナップショット機能を利用するバックアップソフトウェアによる方法である。3つ目と同様に、バックアップソフトウェアによる多様なバックアップ管理が可能になると同時に、スナップショットを利用してコンテナで使用中のPVへの影響を抑えられる。また、CSIプラグインの操作はKubernetesのインターフェースから実行できる。ただし最新のOCP4.4でも、CSIスナップショットはTechnical Previewの扱いなので、これから検証が必要となる。
各バックアップ方法を、図表2に整理した。
.
.
CSIスナップショットの
具体的な実装方法
ここからはIBM Spectrum Protect PlusのKubernetes backup support機能をもとに、CSIスナップショットの具体的な実装を説明する。
Spectrum Protect Plus（以下、SPP）は、仮想環境（VMware、Hyper-V）向けのデータ保護ソフトウェアである。仮想アプライアンスで提供されるため、数分で導入でき、１時間以内に環境の保護を始められる。
「Spectrum Protect（旧TSM） for xxxx」とは別製品で、単独で稼働する。仮想環境だけでなく、アプリケーション（Oracle、Db2、MS SQL、Exchange、MongoDB、MS Office365）のバックアップもサポートしている。クラウド環境への導入が可能で、IBM Cloud、AWSのVMware on Cloudサービス・メニューで購入することもできる。
SPPを構成する主要コンポーネントについて説明しよう。
SPPは管理インターフェースやポリシー、カタログ情報を保管するための管理サーバーで、１環境に１台のみ構成が可能である。また仮想サーバーにのみ導入できる。
vSnapはバックアップデータの保管先となるサーバーで、複数台構成が可能であり、vSnap間のレプリケーションが実行できるので、災害対策などにも適用できる。仮想サーバーだけでなく、物理サーバーにも導入が可能である。
VADP Proxyは、バックアップ／リストア処理の実行を制御するサーバーで、vSnapや管理サーバーと同居できる。複数台構成が可能で、仮想・物理サーバーいずれにも導入できる。
SPPでのバックアップ／リストアの実行・管理はすべて、Webブラウザ上のユーザー・インターフェースを使用する（REST APIで制御できるが、CLIツールは提供されない）。事前に定義したSLAポリシーとジョブを関連付けて、バックアップを実行する。
ここでいうSLAポリシーとは、バックアップのサービスレベルを決定するためのポリシーである。バックアップの頻度や保存期間、実行スケジュール、ターゲット・サイト（バックアップ先のvSnap）などを定義する。
Gold（4時間ごとに実行、1週間保管）、Silver（1日1回実行、30日間保管）、Bronze（1日1回実行、1週間保管）という3つのデフォルトSLAポリシーが定義済みで、カスタマイズも可能である（このデフォルトSLAは仮想環境、アプリケーション用で、後述するKubernetes環境用のSLAポリシーは別に用意されている）。追加で任意のSLAポリシーも作成できる。
SPP Kubernetes（K8s）Backup Supportは、K8sクラスタのコンテナに接続された永続ボリューム（PV）を保護する。PVのスナップショットが作成され、vSnapにコピーされる。
PVのバックアップは、SLAポリシーによって保護される。元のボリュームにあるデータが破損、あるいは消失した場合、スナップショットもしくはvSnapにあるコピー・バックアップからリストアできる。
K8s Backup Supportは、Container Storage Interface（以下、CSI）をサポートするストレージ・プラグインによって割り当てられたPVを保護できる。CSIプラグインは、バックアップ操作に使われるスナップショット機能を提供している。
図表3は、K8s Backup SupportがK8s環境でデプロイされる方法と、SPPが相互作用する方法を説明している。
.
.
K8s Backup Supportは、Persistent Volume Claim（PVC）を使用して、バックアップするPVを識別する。スケジュール・バックアップが実行されると、SLAによって指定された時間間隔で、PVのスナップショットおよびコピー・バックアップが作成される。
データムーバーはデータをコピーし、SPP管理インターフェースにスナップショット・バックアップを記録する。またオンデマンド・バックアップによって作成されたスナップショットは、SPPにも記録される。
SPPのK8sおよびOpenShiftのサポートは、現段階（v10.1.5）ではK8sのみで、OpenShiftは未サポートである（次期リリースでサポートを予定）。
バックアップの管理は、kubectlを使用している。SPPは本来GUIで管理するツールだが、現状、K8sバックアップで使用できるのはCLIのみとなっている。
現時点でSPPは、CSI経由でスナップショットとコピーを取得する機能のみを提供している。またPV間の整合性は、確保できない仕様となっている（個々のPVバックアップを取得するのみ）。
.
K8s Backup Supportの
バックアップ／ストア・タイプ
次に、K8s Backup Supportのバックアップ・タイプとリストア・タイプについて解説する。
スナップショット・バックアップは、CSIストレージ・プラグインのスナップショット機能を使ってPVのバックアップを作成する。
作成されたスナップショットは、スナップショット・クラスによってアサインされた場所に保管される。スナップショット・バックアップは、スケジュール・バックアップもしくはオンデマンド・バックアップのリクエストによって作成される。
オンデマンド・バックアップ・リクエストは、すでにスケジュール・バックアップで保護されているボリュームでのみ利用できる。スケジュール・バックアップの間、スナップショットおよびコピー・バックアップが、SLAポリシーによって定義された間隔で作成される。
またオンデマンド・バックアップ・リクエストはスナップショットのみを取得し、コピー・バックアップは作成しない。
コピー・バックアップは、vSnapにPV全体をコピーする。SLAポリシーに基づいて、SPPはスナップショット・バックアップよりコピー・バックアップを長く保管する。
スナップショット・リストアは、スナップショットを新しいPVにリストアする。このタイプの操作は、直近のスナップショット・バックアップを迅速にリストアするのに適している。
コピー・バックアップ・リストアは、コピー・バックアップを元のPV、もしくは新しいPVにリストアする。コピー・バックアップを元のPVにリストアする場合、PVが接続されているコンテナは停止する必要がある。
このタイプの操作は、SPPに長期間保管されているコピー・バックアップからPVをリストアするのに適している。たとえば、このタイプの操作を使用して、スナップショットの有効期限が切れたコピー・バックアップをリストアできる。
.
K8s Backup SupportのSLAポリシー
次に、K8s Backup SupportのためのSLAポリシーについて解説する。
前述した通常のSPPで使用するSLAポリシーと異なり、スナップショット・バックアップおよびコピー・バックアップの実行頻度、スナップショットおよびコピー・バックアップの保管期限をそれぞれ定義する。
PVを保護するのに使われるSLAポリシーには、以下の4つがある。
Test：15分ごとにスナップショット、1時間保管、1時間ごとにコピー・バックアップ、1日保管
Daily：4時間ごとにスナップショット、1日保管、1日ごとにコピー・バックアップ、1ヶ月保管
Weekly：1日ごとにスナップショット、1週間保管、1週間ごとにコピー・バックアップ、1ヶ月保管
Monthly：月に1回コピー・バックアップ、1年保管
なおK8s用のSLAポリシーは事前定義済みで、変更・新規作成はできない（v10.1.5時点）。1つのボリュームに関連付けられるSLAポリシーは、1つだけに制限されている。スナップショットが期限切れになると、K8s環境で自動的に削除される。コピー・バックアップが期限切れになると、SPPのメンテナンス・ジョブによって削除される。
.
K8s Backup Supportのリクエスト
K8s Backup Supportのリクエストについて解説する。
コンテナ・データを保護するには、K8s Backup Supportリクエストを実行する。リクエストは、BaaSReqの一種であるK8sカスタム・リソースで、そのリクエストはYAML構成ファイルで指定され、kubectlを使用してリクエストを送信する。
リクエスト・タイプは、YAMLファイルでrequesttypeキーの値として指定される。以下に利用可能なK8s Backup Supportのリクエスト・タイプを示す（リクエスト作成方法については後述）。
Backup：スケジュール・バックアップ・リクエスト
Restore：スナップショットもしくはコピー・バックアップからPVCをリストアする
Pause：スケジュール・バックアップを一時停止する
Resume：一時停止したスケジュール・バックアップを再開する
Destroy：すべてのスナップショットとコピー・バックアップを削除し、ジョブを破棄済みにする
OnDemandBackup：PVCのオンデマンド・バックアップ・リクエスト
.
K8s Backup Supportの導入方法
K8s Backup Supportを導入する方法について解説する。
まずシステム要件について確認しよう。SPPはV10.1.5以上が必要で、K8s 1.13以上の環境でサポートされている。CSIはV1.1.0以上が必要で、コンテナ・ストレージはCeph Storageのみサポートされている。導入可能なOSはRHEL7.6か7.7で、Core OSやRHEL8は未サポートである。その他のシステム要件詳細は以下を参照する。
technote 2013790
https://www.ibm.com/support/pages/node/304861
導入前の環境準備については、VolumeSnapshotDataSourceフィーチャーの有効化、メトリクス・サーバーの稼働確認、アプリケーションとPVCの関係定義が必要で、詳細は以下のマニュアルを参照してほしい。今回は説明を割愛する。
Prerequisites for Kubernetes Backup Support
https://www.ibm.com/support/knowledgecenter/SSNQFQ_10.1.5/spp/r_spp_cbs_prereqs.html#r_spp_cbs_prereqs__install_metrics_server
続いて、K8s Backup Supportイメージのインストールとデプロイ手順について以下に説明する。
① インストール・ノードとして使用するK8sクラスタのマスター・ノードのOSにログインする。
② 以下のコマンドを入力して、インストール・パッケージ（installer-10.1.5.tar.gz）を解凍する。installerという名前のフォルダが抽出される。
tar -xvf installer-10.1.5.tar.gz
③ 以下のコマンドを入力してインストーラー・ディレクトリに移動する。
cd installer
④ 以下の2つのコマンドを実行して、クラスタのCIDR（Classless Inter-Domain Routing）と、APIサーバーのIPアドレスとポートを取得する。値は手順⑤で使用する。
a. 以下のコマンドを発行して、クラスタのCIDRを取得する
kubectl cluster-info dump | grep -m 1 cluster-cidr
b. 以下のコマンドを発行して、クラスタAPIサーバーのIPアドレスとポートを取得する
kubectl config view|awk ‘/cluster\:/,/server\:/’ | grep server\: | awk ‘{print $2}’
⑤ テキスト・エディタでbaas_config.cfgファイルを編集し、環境に適切な値を指定して構成パラメータを変更する。
⑥ 以下のコマンドを発行して、インストールとデプロイを開始する。
./baas_install.sh -i
プロンプトが表示されたら、yesと入力して続行する。環境によって、パッケージのロードとデプロイに数分かかる場合がある。インストールとデプロイについての詳細は以下を参照する。
Installing and deploying Kubernetes Backup Support images
https://www.ibm.com/support/knowledgecenter/SSNQFQ_10.1.5/spp/t_spp_cbs_install_proc.html
.
PVのスケジュール・バックアップ手順
PVのスケジュール・バックアップ手順について解説する。
① オプション：以下のコマンドを発行して、ネームスペース内のリストを表示する。PVCのリストから、バックアップするPVCを指定する。
kubectl get pvc -n namespace
② スケジュール・バックアップ・リクエストを定義するYAMLファイルを作成する（図表4）。
.
③ バックアップ・リクエストを適用して、スケジュール・バックアップを開始する。コマンドラインで以下のコマンドを入力する。
kubectl create -f filename.yaml
④ バックアップ・リクエスト送信後、最初のスケジュール・バックアップが、SLAポリシーで定義したウィンドウ内で開始される。バックアップに関する情報を表示するには、リクエスト名またはPVC名を使用して、kubectl describeコマンドを発行する。任意のリクエストすべてのバックアップ・リストを表示するには、以下のコマンドでリクエスト名とネームスペースを指定する。
kubectl describe baasreq request_name -n namespace
.
コンテナ・データのリストア手順
最後に、コンテナ・データのリストア手順について説明する。
① PVCで使用可能なリストア・ポイントを表示するには、以下のコマンドを実行して、PVCのすべてのバックアップについて問い合わせる。
kubectl describe BaaSReq pvc_name -n namespace
② 表示されるステータス出力で、リストアするソース・スナップショットまたはコピー・バックアップのタイムスタンプを特定する。タイムスタンプは、バックアップ・タイプの前の出力のステータス・セクションに表示される（図表5）。
.
.
③ リストア・リクエストのYAMLファイルを作成する。restorepointパラメータにソース・スナップショットのタイムスタンプを挿入する（図表6）。
.
④コマンドラインで以下のコマンドを入力し、リストア・リクエストを開始する。
kubectl create -f filename.yaml
⑤ データを新しいPVにリストアした場合は、リストア完了後に、アプリケーションコンテナを再構成して新しいボリュームをマウントできる。
⑥ リストアに関する情報を表示するには、kubectl describeコマンドを発行する。リストア・ジョブのステータスは、コマンド出力のRestorestatusフィールドに表示される。
著者｜
能政 周平氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
オープンテクノロジー
ITスペシャリスト
2003年に日本アイ・ビー・エム システムズ・エンジニアリング入社。2011年までPower Systemsのテクニカルサポートを主に担当。2014年からIBM Spectrum Protect（TSM）、テープ装置のテクニカルサポートを担当。プロジェクトサポートにも並行して参画し、主にインフラの構築、運用、移行を担当している。
小林 規将氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
オープンテクノロジー
ITスペシャリスト
1998年に日本IBM入社、2017年より日本アイ・ビー・エム システムズ・エンジニアリングへ出向。2010年頃まではSystem x、Power Systemsプリセールス活動に従事し、2010年からストレージのプリセールス活動やBP様援などを担当。2017年よりSANスイッチやIBM Spectrum Protect（TSM）、Cisco UCSのSMEとして活動中。
････････
特集｜OpenShift
Part1 基礎から始めよう、OpenShiftネットワークの概要と活用例
Part2 OpenShift on IBM Cloudを活用した本気の開発環境デザイン
＿前編 提案時の悩み：コンテナ環境向け開発ツールの選定
＿中編 設計時の悩み：開発テスト環境のプライベートネットワーク構成
＿後編 運用時の悩み：OpenShift機能を活用して開発テスト環境へのデプロイを効率的に
Part3 OpenShiftでの最適なバックアップ手法
