アプリケーションのリストア
Astra Control を使用すると、スナップショットまたはバックアップからアプリケーションをリストアできます。同じクラスタにアプリケーションをリストアする場合、既存の Snapshot からのリストアは高速です。Astra Control UI またはを使用できます "Astra Control API の略" アプリを復元するには、
-
最初にアプリケーションを保護する:アプリケーションを復元する前に、アプリケーションのスナップショットまたはバックアップを作成することを強くお勧めします。リストアに失敗した場合に、Snapshotまたはバックアップからクローニングできます。
-
デスティネーションボリュームの確認:別のストレージクラスにリストアする場合は、ストレージクラスで同じ永続ボリュームアクセスモード(ReadWriteManyなど)が使用されていることを確認してください。デスティネーションの永続ボリュームアクセスモードが異なると、リストア処理は失敗します。たとえば、ソースの永続ボリュームがRWXアクセスモードを使用している場合は、Azure Managed Disks、AWS EBS、Google Persistent Disk、など、RWXを提供できないデスティネーションストレージクラスを選択します `ontap-san`を指定すると、リストア処理は失敗します。原因は失敗します。永続ボリュームのアクセスモードの詳細については、を参照してください "Kubernetes" ドキュメント
-
必要なスペースを確保するための計画:NetApp ONTAP ストレージを使用するアプリケーションのインプレースリストアを実行すると、リストアしたアプリケーションで使用されるスペースが2倍になることがあります。In Placeリストアを実行したあとに、リストアしたアプリケーションから不要なSnapshotを削除して、ストレージスペースを解放します。
-
(OpenShiftクラスタのみ)ポリシーの追加:OpenShiftクラスタでアプリをホストするためのプロジェクトを作成すると、プロジェクト(またはKubernetesネームスペース)にSecurityContext UIDが割り当てられます。Astra Control Center でアプリケーションを保護し、 OpenShift でそのアプリケーションを別のクラスタまたはプロジェクトに移動できるようにするには、アプリケーションを任意の UID として実行できるようにポリシーを追加する必要があります。たとえば、次の OpenShift CLI コマンドは、 WordPress アプリケーションに適切なポリシーを付与します。
oc new-project wordpress
oc adm policy add-scc-to-group anyuid system:serviceaccounts:wordpress
oc adm policy add-scc-to-user privileged -z default -n wordpress
-
* Helmデプロイ済みアプリ*:Helm 3でデプロイされたアプリ(またはHelm 2からHelm 3にアップグレードされたアプリ)は完全にサポートされます。Helm 2 で展開されたアプリケーションはサポートされていません。
リソースを共有するアプリケーションでIn Placeリストア処理を実行すると、予期しない結果が生じる可能性があります。アプリケーション間で共有されているリソースは、いずれかのアプリケーションでインプレースリストアが実行されると置き換えられます。詳細については、を参照してください この例です。 |
-
「 * アプリケーション」を選択し、アプリケーションの名前を選択します。
-
[オプション]メニューの[操作]列で、*[リストア]*を選択します。
-
リストアタイプを選択します。
-
元のネームスペースにリストア:この手順 を使用して、アプリケーションを元のクラスタにインプレースでリストアします。
アプリケーションがでサポートされるストレージクラスを使用している場合 ontap-nas-economy
ドライバ。元のストレージクラスを使用してアプリケーションをリストアする必要があります。アプリケーションを同じネームスペースにリストアする場合、別のストレージクラスを指定することはできません。-
アプリをインプレースで復元するために使用するスナップショットまたはバックアップを選択します。これにより、アプリは以前のバージョンに戻ります。
-
「 * 次へ * 」を選択します。
以前に削除したネームスペースにリストアすると、同じ名前の新しいネームスペースがリストアプロセスで作成されます。以前に削除したネームスペースでアプリケーションを管理する権限を持つユーザは、新しく作成したネームスペースに手動で権限を復元する必要があります。
-
-
新しい名前空間に復元:この手順 を使用して、アプリを別のクラスタまたはソースとは異なる名前空間で別のクラスタに復元します。
この手順 は、どちらにも使用できます をバックアップされたストレージクラスに追加します ontap-nas
同じクラスタ*または*から作成されたストレージクラスを含む別のクラスタにアプリケーションをコピーしますontap-nas-economy
ドライバ。-
復元されたアプリの名前を指定します。
-
リストアするアプリケーションのデスティネーションクラスタを選択します。
-
アプリケーションに関連付けられている各ソースネームスペースのデスティネーションネームスペースを入力します。
Astra Controlは、このリストアオプションの一部として新しいデスティネーションネームスペースを作成します。指定するデスティネーションネームスペースがデスティネーションクラスタに存在していないことを確認してください。 -
「 * 次へ * 」を選択します。
-
アプリの復元に使用するスナップショットまたはバックアップを選択します。
-
「 * 次へ * 」を選択します。
-
次のいずれかを選択します。
-
元のストレージクラスを使用してリストア:ターゲットクラスタに存在しない場合を除き、元 々 関連付けられていたストレージクラスがアプリケーションで使用されます。この場合、クラスタのデフォルトのストレージクラスが使用されます。
-
別のストレージクラスを使用したリストア:ターゲットクラスタに存在するストレージクラスを選択してください。元 々 関連付けられていたストレージクラスに関係なく、すべてのアプリケーションボリュームが、リストアの一環としてこの別のストレージクラスに移動されます。
-
-
「 * 次へ * 」を選択します。
-
-
-
フィルタするリソースを選択:
-
すべてのリソースを復元:元のアプリケーションに関連付けられているすべてのリソースを復元します。
-
リソースのフィルタ:元のアプリケーションリソースのサブセットを復元するルールを指定します。
-
リストアされたアプリケーションにリソースを含めるか除外するかを選択します。
-
または[除外ルールを追加]*のいずれかを選択し、アプリケーションのリストア時に正しいリソースをフィルタするようにルールを設定します。設定が正しくなるまで、ルールを編集したり削除したり、ルールを再度作成したりすることができます。
includeルールとexcludeルールの設定については、を参照してください アプリケーションのリストア中にリソースをフィルタリングします。
-
-
-
「 * 次へ * 」を選択します。
-
リストア処理の詳細をよく確認し、プロンプトが表示されたら「restore」と入力して*[リストア]*を選択します。
Astra Control は、指定した情報に基づいてアプリケーションを復元します。アプリケーションをインプレースでリストアした場合、既存の永続ボリュームのコンテンツが、リストアしたアプリケーションの永続ボリュームのコンテンツに置き換えられます。
データ保護処理(クローン、バックアップ、またはリストア)が完了して永続ボリュームのサイズを変更したあと、Web UIに新しいボリュームサイズが表示されるまでに最大20分かかります。データ保護処理にかかる時間は数分です。また、ストレージバックエンドの管理ソフトウェアを使用してボリュームサイズの変更を確認できます。 |
ネームスペースの名前/ IDまたはネームスペースのラベルでネームスペースの制約を受けているメンバーユーザは、同じクラスタの新しいネームスペース、または組織のアカウントに含まれる他のクラスタにアプリケーションをクローニングまたはリストアできます。ただし、同じユーザが、クローニングまたはリストアされたアプリケーションに新しいネームスペースからアクセスすることはできません。クローンまたはリストア処理によって新しいネームスペースが作成されると、アカウントの管理者 / 所有者はメンバーユーザアカウントを編集し、該当するユーザに新しいネームスペースへのアクセスを許可するロールの制限を更新できます。 |
アプリケーションのリストア中にリソースをフィルタリングします
にフィルタルールを追加できます "リストア" リストアされたアプリケーションに含める、またはリストアされたアプリケーションから除外する既存のアプリケーションリソースを指定する処理。指定した名前空間、ラベル、またはGVK(GroupVersionKind)に基づいて、リソースを含めたり除外したりできます。
[Include(含める)]および[Exclude(除外)]のシナリオ
-
元のネームスペースを使用する包含ルールを選択した場合(インプレースリストア):ルールで定義した既存のアプリケーションリソースは削除され、リストアに使用する選択したSnapshotまたはバックアップのリソースで置き換えられます。includeルールで指定しないリソースは変更されません。
-
新しい名前空間を持つincludeルールを選択した場合:このルールを使用して、リストアされたアプリケーションで使用する特定のリソースを選択します。対象ルールに指定しないリソースは、リストアされたアプリケーションには含まれません。
-
元のネームスペースを含む除外ルールを選択した場合(インプレースリストア):除外するように指定したリソースはリストアされず、変更されません。除外するように指定しないリソースは、スナップショットまたはバックアップからリストアされます。対応するStatefulSetがフィルタリングされたリソースに含まれている場合、永続ボリューム上のすべてのデータが削除されて再作成されます。
-
新しい名前空間を持つ除外ルールを選択した場合:このルールを使用して、リストアされたアプリケーションから削除する特定のリソースを選択します。除外するように指定しないリソースは、スナップショットまたはバックアップからリストアされます。
ルールには、includeまたはexcludeタイプがあります。リソースの包含と除外を組み合わせたルールは使用できません。
-
リソースをフィルタするように選択し、[アプリケーションのリストア]ウィザードで[含める]または[除外するルールを追加する]を選択したら、*[除外するルールを追加する]*を選択します。
Astra Controlで自動的に追加されるクラスタ対象のリソースを除外することはできません。 -
フィルタルールを設定します。
ネームスペース、ラベル、またはGVKを少なくとも1つ指定する必要があります。フィルタルールを適用したあとに保持するリソースがあれば、リストアしたアプリケーションを正常な状態に保つのに十分であることを確認してください。 -
ルールの特定のネームスペースを選択します。選択しない場合は、すべての名前空間がフィルタで使用されます。
アプリケーションに複数のネームスペースが含まれていた場合、新しいネームスペースにリストアすると、リソースが含まれていなくてもすべてのネームスペースが作成されます。 -
(オプション)リソース名を入力します。
-
(任意)ラベルセレクタ:を含めます "ラベルセレクタ" をクリックしてルールに追加します。ラベルセレクタは、選択したラベルに一致するリソースのみをフィルタリングするために使用されます。
-
(オプション)[Use GVK (GroupVersionKind) set]を選択してリソースをフィルタリング*し、追加のフィルタリングオプションを指定します。
GVKフィルタを使用する場合は、バージョンと種類を指定する必要があります。 -
(オプション)* Group *:ドロップダウンリストからKubernetes APIグループを選択します。
-
種類:ドロップダウンリストから、フィルタで使用するKubernetesリソースタイプのオブジェクトスキーマを選択します。
-
バージョン:Kubernetes APIのバージョンを選択します。
-
-
-
エントリに基づいて作成されたルールを確認します。
-
「 * 追加」を選択します。
ルールを含むリソースと除外するリソースは必要なだけ作成できます。処理を開始する前に、リストアアプリケーションの概要にルールが表示されます。
経済性に優れたONTAP-NASストレージからONTAP-NASストレージへの移行
Astra Controlを使用できます "アプリケーションのリストア" または "アプリケーションのクローン" に対応するストレージクラスからアプリケーションボリュームを移行する処理 ontap-nas-economy`では、でサポートされるストレージクラスに制限されたアプリケーション保護オプションが許可されます `ontap-nas
Astra Controlのあらゆる保護オプションを利用できます。クローンまたはリストア処理では、を使用するqtreeベースのボリュームが移行されます ontap-nas-economy
でサポートされる標準ボリュームへのバックエンド ontap-nas
。ボリューム(ボリュームが存在するかどうかに関係なく) ontap-nas-economy
BACKED ONLYまたはMIXEDは、ターゲットストレージクラスに移行されます。移行が完了すると、保護オプションの制限がなくなります。
リソースを別のアプリケーションと共有するアプリケーションでは、インプレースリストアが複雑になります
リソースを別のアプリケーションと共有し、意図しない結果を生成するアプリケーションに対して、インプレースリストア処理を実行できます。アプリケーション間で共有されているリソースは、いずれかのアプリケーションでインプレースリストアが実行されると置き換えられます。
次に、NetApp SnapMirrorレプリケーションを使用してリストアすると望ましくない状況が発生するシナリオの例を示します。
-
アプリケーションを定義します
app1
ネームスペースを使用するns1
。 -
のレプリケーション関係を設定します
app1
。 -
アプリケーションを定義します
app2
(同じクラスタ上)ネームスペースを使用しますns1
およびns2
。 -
のレプリケーション関係を設定します
app2
。 -
のレプリケーションを反転した
app2
。これにより、が起動しますapp1
非アクティブ化するソースクラスタ上のアプリケーション。