みなさんこんにちは。 Portworxの機能を連載形式でご紹介しております。

-------------------------------------------------------------------------------------------
　入門編　コンテナ環境と「データ」を考える
　第1回　PX-Storeによるボリュームの提供(初級編)
　第2回　PX-Storeによるボリュームの提供(応用編)
　第3回　ボリュームのスナップショット
　第4回　PX-Autopilotによるボリューム・ストレージの自動拡張
　第5回　PX-SecureによるRBACとOwnership
　第6回　PX-Migrateによるアプリケーションとデータの移行
　第7回　PX-DRによる災害対策
　第8回　PX-Backupによるアプリケーションとデータの保護
-------------------------------------------------------------------------------------------

今回は「PX-Backup」についてご紹介いたしますが、PX-Backupのインストールや基本操作については既にこちらで手順書がリリースされております。 そこで本ブログではPX-Backupを利用する上で知っておくと役立ちそうな情報をいくつかご紹介いたします。
なおPortworxにはBackup as a Serviceも存在しますが、本ブログはオンプレミス環境上のPX-Backupを前提としています。

PX-BackupとPortworx Enterpriseの関係性を紐解く

PX-Backupの主な機能はKubernetes上のアプリケーションやデータ、各種オブジェクトをバックアップ・リカバリすることです。連載「Portworx基礎」において前回まではPortworx EnterpriseならびにそのAdd-on機能についてご紹介して参りましたが、PX-Backupは他の"PX-"で始まる機能とは異なる特性を持っています。このため、まずは製品の体系としてPX-BackupとPortworx Enterpriseの関係がどのようになっているか整理しておきましょう。

PX-BackupはPortworx Enterpriseからは独立した製品となっており、メーカーサイトに記載の通りインストール要件が別に存在しています。 同一Kubernetesクラスター上でPX-BackupとPortworx Enterpriseを利用する場合であっても、それぞれ別にインストール作業を実施する必要があります。

この特性上、PX-BackupのライセンスとPortworx Enterpriseのライセンスも別になっています。さらにメーカーサイトのFeature Listも別になっています。
※ Portworx Enterprise / Essentialsはこちら、PX-BackupはこちらでFeature Listを確認することができます。

　

　

ここからは以下の検証環境を利用してPX-Backupの動作や機能をご紹介いたします。 オンプレミス環境にKubernetesクラスターを1台のMasterノード、3台のWorkerノードで構成しており、Portworx Enterprise バージョン2.12.1をインストールしています。

　

インストール要件「Backend drive」とは

PX-Backupをオンプレミスの環境へインストールする際の要件についてはこちらでご確認頂けますが、" Hardware Requirements"として"Backend drive : 307 GB (In Total)"と記載されています。 このディスク領域をどこに用意すればよいか確認しておきましょう。

PX-Backupでは大きく分けて2種類のストレージを必要とします。1つ目は"Backup Location"と呼ばれるバックアップデータを保管するためのオブジェクトストレージ、2つ目はPX-Backup自身が利用するためのストレージです。  前述のBackend driveは後者にあたります。 メーカードキュメントに記載の通り、PX-BackupはMongoDBを利用してスケジュール等のバックアップ運用に関連するデータを管理します。 PX-BackupはKubernetes上にインストールしますので、このようなデータを永続化するためにBackend driveが必要になるという訳です。

ここでは実際にPX-Backupをインストールし、ボリュームがどのように利用されるか確認してみましょう。

PX-Backupをインストールする際にPX-Centralでスペックを作成しますが、このときStorageClassの名称を指定します。 今回はPortworxのStorage Poolからボリュームを作成できるようStorageClass "portworx-sc"を用意し、こちらをPX-Central上で指定しました。

Namespace "central"にPX-Backup (バージョン2.3)をインストールした後のPVCやPVの一覧は以下の通りです。PX-Centralで指定したStorageClassを利用して合計307GiBのボリュームが作成されていることが分かります。

Backend driveはStorageClassがPX-Backup用にPVを払い出す場所ですので、PX-Backupインストール前に当該ストレージの容量を確認しておくとよいでしょう。

　

Portworx Backup SecurityによるRBAC

PX-BackupにはPortworx Backup Securityと呼ばれるRBAC(Role Based Access Control, ロールベースアクセス制御)のための機能が組み込まれています。 PX-Backupを既存のOIDCと連携させることもできますし、PX-Backupが持つKeycloak (Portworx Backup Keycloak)によってユーザーを管理することも可能です。

PX-Backupのロール

ここではPX-BackupのGUI(PX-Backup UI)にアクセスし、デフォルトで作成されるユーザー"admin"にどのような権限があるのかを確認してみます。adminとしてサインイン後、画面左下の人物のアイコンから「PX-Backup Security」をクリックします。

「Role Mapping」タブではユーザーに紐付いているロールを確認することが可能です。adminは"px-backup-infra.admin"というロールが割り当てられています。

「Roles」タブをクリックするとロールの情報を確認することが可能です。以下がデフォルトで存在しているロールです。(メーカードキュメントにもBuilt-inのロールに関する説明がございます。)

右側にある「︙」から「Show Details」をクリックすると、当該のロールにどのような権限があるか確認することが可能です。 px-backup-infra.adminは全ての項目がFull Accessになっています。

なお、右上の「+ Add」をクリックするとロールを追加することが可能です。(ロール名の制限事項など詳細についてはメーカードキュメントをご参照ください。)
　

PX-Backupのユーザー

今回はKeycloak を利用してRBACの機能を試してみたいと思います。(OIDCと連携している場合はKeycloakでユーザーを管理する必要はありません。)

PX-BackupにはGUIがあり、バックアップの管理をするPX-Backup UIとユーザーを管理するためのKeycloak UIがあります。(UIへのアクセス方法はこちらで整理されています。) WebブラウザでKeycloak UIにアクセスすると以下のような画面が表示されます。

「Administration Console」をクリックするとサインイン画面が表示されます。ここではadminとしてサインインします。

今回は新しいユーザー"test-user"を作成してみます。 「Users」画面の「Add user」をクリックします。

ユーザー名、メールアドレス、名前を入力して「Save」をクリックします。

「Credentials」タブをクリックしてパスワードを設定し「Set Password」をクリックします。 「Temporary」がONになっている場合、次回サインイン時にパスワード変更が必要です。

PX-Backup UIに戻って「PX-Backup Security」を確認すると、test-userにロール"px-backup-app.user"が設定されていることが分かります。

なお、ロール"px-backup-app.user"の権限は下図の通り全ての項目が「View Only」になっています。
本環境におけるユーザーとロールのマッピングは下図の通りです。

なお、本ブログ記事では詳しく触れませんが、グループを作成し複数ユーザーをまとめて管理することも可能です。(グループに対するロールの設定についてはこちらをご参照ください。)

ロール"px-backup-app.user"のユーザーで操作

ここからはロール"px-backup-app.user"が割り当てられているtest-userによるPX-Backup UIの操作についてご紹介したいと思います。 test-userでのサインイン完了後、Schedule PoliciesやCloud Settingsの設定画面を見てみると設定を新規に追加することができないようになっています。(Cloud SettingsはBackup Locationに関連した設定を行う場所です。) 設定を追加しようとすると権限がない旨のメッセージが表示されます。

なお、PX-Backup UIの「+ Add Cluster」からバックアップ対象のKubernetesクラスターを登録することは可能です。

　

PX-Backupのリソースを他のユーザーにシェア

PX-Backupでは、自身が設定したBackup LocationやSchedule Policyなどのリソースを他のユーザーに利用させることが可能です。

例えば、test-userはバックアップジョブを作成すること自体は可能です。 しかしながらロール"px-backup-app.user"には前述の通りBackup LocationやSchedule Policyを新規に作成する権限がありません。 ジョブ作成時には少なくとも「Enter name for Backup」と「Backup location」を指定しなければならないため、事前にtest-userに対してBackup Location等のリソースを提供してあげる必要があります。 このような場合にリソースをシェアする(test-userによるアクセスを許可する)機能を利用します。
ここではadminが作成したBackup LocationやSchedule Policyをtest-userが利用できるよう、アクセスを許可してみたいと思います。

ここからはadminとしてPX-Backup UIにサインインして操作します。
Backup Locationへのアクセスを許可するには右側にある「︙」から「User Access」をクリックします。(今回はAzure Blob StorageをBackup Locationとして登録しています。)
今回はこちらのBackup Locationに対してPX-Backupユーザー全員がアクセスできるようにしてみます。(「Assign Users」でユーザーやグループを個別に指定することも可能です。) 「Make accessible to everyone」にチェックを入れ「Update」をクリックします。

また、今回はSchedule Policy "1hour"を作成していますのでこちらをシェアします。Schedule Policy名の右側にある「︙」から「User Access」をクリックします。

こちらもPX-Backupユーザー全員がアクセスできるようにしてみます。 「Make accessible to everyone」にチェックを入れ「Update」をクリックします。

改めてPX-Backup UIにtest-userでサインインしてみます。バックアップジョブ作成画面を確認すると、アクセスを許可したBackup LocationやSchedule Policyを指定することができるようになっています。

本ブログ記事ではBackup LocationとSchedule Policyを例にシェアの方法をご紹介しましたが、他にもシェアできるリソースがございます。詳細についてはメーカードキュメントをご参照ください。 また、バックアップをシェアする機能についてはこちらをご参照ください。

　

まとめ

今回はPX-Backupの利用に役立ちそうな情報をいくつかピックアップしてご紹介いたしました。 ぜひこちらの手順書も併せてご覧の上、PX-Backupをご活用頂ければと思います。

　

---

※ サービスや製品の仕様ならびに動作に関しては、予告なく改変される場合があります。
※ 本ブログにおける記載はPortworx Enterpriseバージョン2.12、PX-Backup (On-premises)バージョン2.3の情報に基づいています。 異なるバージョンにおけるサポート範囲 / 仕様変更等についてはメーカードキュメントをご確認ください。