Azure Service Fabric の定期バックアップ構成を理解する

[アーティクル]
06/01/2023

Reliable Stateful Services または Reliable Actors の定期バックアップの構成は、次のステップで構成されます。

バックアップポリシーの作成: このステップでは、要件に応じて 1 つまたは複数のバックアップポリシーを作成します。
バックアップの有効化: この手順では、手順 1 で作成したバックアップポリシーを、目的のエンティティ、アプリケーション、サービス、または、パーティション に関連付けます。

バックアップポリシーの作成

バックアップポリシーは、次の構成で構成されます。

データ損失時の自動復元: パーティションでデータ損失イベントが発生した場合に、利用可能な最新のバックアップを使用して自動的に復元をトリガーするかどうかを指定します。

Note

運用環境クラスターでは、自動復元を設定しないことをお勧めします。

増分バックアップの最大数: 2 回の完全バックアップの間に実行される増分バックアップの最大数を定義します。増分バックアップの最大数は、上限を指定します。次の条件のいずれかに該当する場合は、指定した回数の増分バックアップが完了する前に、完全バックアップを実行できます。
1. レプリカがプライマリになった後、完全バックアップが一回も実行されていない。
2. 最後のバックアップの、ログレコードの一部が切り捨てられている。
3. レプリカが MaxAccumulatedBackupLogSizeInMB 制限を超えた。
バックアップスケジュール: 定期バックアップを実行する時刻または頻度。指定した間隔または固定された時刻 (毎日/毎週) にバックアップを繰り返すようにスケジュールできます。
1. 頻度ベースのバックアップスケジュール: 一定の間隔でデータバックアップを実行しなければならない場合は、このスケジュールの種類を使用する必要があります。 2 つの連続するバックアップの間の目的の時間間隔を、ISO8601 形式を使用して定義します。頻度ベースのバックアップスケジュールでは、分単位までの間隔がサポートされます。
```
{
    "ScheduleKind": "FrequencyBased",
    "Interval": "PT10M"
}
```
2. 時刻ベースのバックアップスケジュール: 1 日または 1 週間のうちの特定の時刻にデータバックアップを実行しなければならない場合は、このスケジュールの種類を使用する必要があります。スケジュールする頻度の種類は、毎日または毎週が可能です。
  1. Daily 時刻ベースのバックアップスケジュール: 1 日のうちの特定の時刻にデータバックアップを実行しなければならない場合は、このスケジュールの種類を使用する必要があります。これを指定するには、ScheduleFrequencyType を Daily に設定し、RunTimes に 1 日のうちの目的の時刻の一覧を ISO8601 形式で設定します (時刻と共に指定された日付は無視されます)。たとえば、0001-01-01T18:00:00 は、毎日の "午前 6 時" を表し、日付部分の 0001-01-01 は無視されます。次の例は、日次バックアップを "午前 9 時" と "午後 6 時" にトリガーする構成を示しています。
```
{
    "ScheduleKind": "TimeBased",
    "ScheduleFrequencyType": "Daily",
    "RunTimes": [
      "0001-01-01T09:00:00Z",
      "0001-01-01T18:00:00Z"
    ]
}
```
  2. Weekly 時刻ベースのバックアップスケジュール: 1 日のうちの特定の時刻にデータバックアップを実行しなければならない場合は、このスケジュールの種類を使用する必要があります。これを指定するには、ScheduleFrequencyType を Weekly に設定し、RunDays にバックアップをトリガーする必要がある曜日の一覧を設定し、RunTimes に 1 日のうちの目的の時刻の一覧を ISO8601 形式で設定します (時刻と共に指定された日付は無視されます)。定期バックアップをトリガーする曜日の一覧。次の例は、月曜日から金曜日の "午前 9 時" と "午後 6 時" に日次バックアップをトリガーする構成を示しています。
```
{
    "ScheduleKind": "TimeBased",
    "ScheduleFrequencyType": "Weekly",
    "RunDays": [
       "Monday",
       "Tuesday",
       "Wednesday",
       "Thursday",
       "Friday"
    ],
    "RunTimes": [
      "0001-01-01T09:00:00Z",
      "0001-01-01T18:00:00Z"
    ]
}
```
バックアップストレージ: バックアップをアップロードする場所を指定します。ストレージは、Azure BLOB ストアまたはファイル共有が可能です。
1. Azure BLOB ストア: Azure で生成されたバックアップを格納しなければならない場合は、このストレージの種類を選択する必要がります。 スタンドアロン クラスターと Azure ベースの クラスターは、両方ともこのストレージの種類を使用できます。このストレージの種類の記述では、接続文字列と、バックアップをアップロードする必要があるコンテナーの名前が必要です。指定した名前のコンテナーが使用できない場合は、バックアップのアップロード時に作成されます。
```
{
    "StorageKind": "AzureBlobStore",
    "FriendlyName": "Azure_storagesample",
    "ConnectionString": "<Put your Azure blob store connection string here>",
    "ContainerName": "BackupContainer"
}
```
  Note
  
  バックアップ復元サービスは、v1 Azure storage では機能しません。
2. ファイル共有: オンプレミスでデータバックアップを格納しなければならない場合は、スタンドアロン クラスター用のこのストレージの種類を選択する必要があります。このストレージの種類の記述では、バックアップをアップロードする必要があるファイル共有パスが必要です。ファイル共有へのアクセスは、次のオプションのいずれかを使用して構成できます。
  1. "統合 Windows 認証"。ファイル共有へのアクセスは、Service Fabric クラスターに属するすべてのコンピューターに提供されます。この場合は、次のフィールドを設定して、"ファイル共有" ベースのバックアップストレージを構成します。
```
{
    "StorageKind": "FileShare",
    "FriendlyName": "Sample_FileShare",
    "Path": "\\\\StorageServer\\BackupStore"
}
```
  2. "ユーザー名とパスワードを使用したファイル共有の保護"。ファイル共有へのアクセスは、特定のユーザーに提供されます。ファイル共有の指定では、プライマリユーザー名とプライマリパスワードでの認証が失敗した場合に、フォールバック資格情報を提供するためのセカンダリユーザー名とセカンダリパスワードを指定することもできます。この場合は、次のフィールドを設定して、"ファイル共有" ベースのバックアップストレージを構成します。
```
{
    "StorageKind": "FileShare",
    "FriendlyName": "Sample_FileShare",
    "Path": "\\\\StorageServer\\BackupStore",
    "PrimaryUserName": "backupaccount",
    "PrimaryPassword": "<Password for backupaccount>",
    "SecondaryUserName": "backupaccount2",
    "SecondaryPassword": "<Password for backupaccount2>"
}
```

Note

ストレージの信頼性が、バックアップデータの信頼性要件を満たしているか、それを上回っていることを確認してください。

アイテム保持ポリシー: 構成されたストレージでバックアップを保持するポリシーを指定します。 Basic アイテム保持ポリシーのみがサポートされます。
1. Basic アイテム保持ポリシー: これ以上必要としないバックアップファイルを削除することにより、このアイテム保持ポリシーで確実に最適な記憶域使用率にすることができます。 RetentionDuration を指定して、バックアップがストレージ内に保持される必要がある期間を設定できます。 MinimumNumberOfBackups は省略可能なパラメーターであり、RetentionDuration に関係なく指定されたバックアップ数が保持されるように指定できます。次の例は、バックアップを 10 日間保持し、バックアップ数が 20 未満にならないようにする構成を示しています。
```
{
    "RetentionPolicyType": "Basic",
    "RetentionDuration" : "P10D",
    "MinimumNumberOfBackups": 20
}
```

定期バックアップを有効にする

データのバックアップ要件を満たすバックアップポリシーを定義した後、バックアップポリシーを "アプリケーション"、"サービス"、または "パーティション" に適切に関連付ける必要があります。

Note

バックアップを有効にする前に、アプリケーションのアップグレードが進行中でないことを確認してください。

バックアップポリシーの階層的な伝達

Service fabric では、アプリケーション、サービス、およびパーティション間のリレーションシップは、アプリケーションモデルで説明されているように階層構造になっています。バックアップポリシーは、階層内の "アプリケーション"、"サービス"、または "パーティション" に関連付けることができます。バックアップポリシーは、次のレベルの階層に伝達されます。 1 つだけ作成されたバックアップポリシーが "アプリケーション" に関連付けられていると仮定した場合、"アプリケーション" のすべての Reliable Stateful Services と Reliable Actors に属するすべてのステートフルパーティションが、そのバックアップポリシーを使用してバックアップされます。バックアップポリシーが Reliable Stateful Services に関連付けられている場合は、すべてのパーティションが、そのバックアップポリシーを使用してバックアップされます。

バックアップポリシーの上書き

アプリケーションのすべてのサービスに対して同じバックアップスケジュールでデータをバックアップする必要があるが、特定のサービスに対するもっと高い頻度でのデータのバックアップや、別のストレージアカウントやファイル共有に対するバックアップの実行が必要なシナリオが存在する場合があります。このようなシナリオに対処するために、バックアップ復元サービスには、サービスとパーティションのスコープでポリシーを上書きできる機能が提供されています。バックアップポリシーが "サービス" または "パーティション" に関連付けられた場合、伝達されたバックアップポリシーは上書きされます (存在する場合)。

例

この例では、2 つのアプリケーション (MyApp_A と MyApp_B) の設定を使用します。アプリケーション MyApp_A には 2 つの Reliable Stateful Services (SvcA1 & SvcA3) と、1 つの Reliable Actor サービス (ActorA2) が含まれています。 SvcA1 には 3 つのパーティションが、ActorA2 と SvcA3 にはそれぞれ 2 つのパーティションが含まれています。アプリケーション MyApp_B には 3 つの Reliable Stateful Services (SvcB1、SvcB2、および SvcB3) が含まれています。 SvcB1 と SvcB2 には、それぞれ 2 つのパーティションが、SvcB3 には 3 つのパーティションが含まれています。

これらのアプリケーションのデータのバックアップ要件は以下であると仮定します。

MyApp_A
1. このアプリケーションに属するすべての Reliable Stateful Services と Reliable Actors のすべてのパーティションのデータの日次バックアップを作成します。バックアップデータは、場所 BackupStore1 にアップロードします。
2. サービスの 1 つである SvcA3 では、データのバックアップを 1 時間ごとに実行する必要があります。
3. パーティション SvcA1_P2 内のデータのサイズが予想を超えているため、そのバックアップデータは、別の保存場所 BackupStore2 に格納する必要があります。
MyApp_B
1. 毎日曜日の午前 8 時に、SvcB1 サービスのすべてのパーティションのデータのバックアップを作成します。バックアップデータは、場所 BackupStore1 にアップロードします。
2. 毎日曜日の午前 8 時に、パーティション SvcB2_P1 のデータのバックアップを作成します。バックアップデータは、場所 BackupStore1 にアップロードします。

これらのデータのバックアップ要件に対処するには、バックアップポリシー BP_1 から BP_5 を作成し、以下のようにバックアップを有効にします。

MyApp_A
1. バックアップポリシー BP_1 を作成します。これは頻度ベースのバックアップスケジュールであり、頻度は 24 時間間隔に設定され、バックアップストレージは保存場所 BackupStore1 を使用するように構成されます。 Enable Application Backup API を使用して、アプリケーション MyApp_A に対してこのポリシーを有効にします。このアクションによって、アプリケーション MyApp_A に属する Reliable Stateful Services と Reliable Actors のすべてのパーティションに対して、バックアップポリシー BP_1 を使用したデータのバックアップが有効になります。
2. バックアップポリシー BP_2 を作成します。これは頻度ベースのバックアップスケジュールであり、頻度は 1 時間間隔に設定され、バックアップストレージは保存場所 BackupStore1 を使用するように構成されます。 Enable Application Backup API を使用して、サービス SvcA3 に対してこのポリシーを有効にします。このアクションによって、伝達されたポリシー BP_1 が、サービス SvcA3 のすべてのパーティションに対して明示的に有効化されたバックアップポリシー BP_2 によって上書きされ、これらのパーティションでバックアップポリシー BP_2 が使用されるようになります。
3. バックアップポリシー BP_3 を作成します。これは頻度ベースのバックアップスケジュールであり、頻度は 24 時間間隔に設定され、バックアップストレージは保存場所 BackupStore2 を使用するように構成されます。 Enable Partition Backup API を使用して、パーティション SvcA1_P2 に対してこのポリシーを有効にします。このアクションによって、伝達されたポリシー BP_1 が、パーティション SvcA1_P2 に対して明示的に有効化されたバックアップポリシー BP_3 によって上書きされます。
MyApp_B
1. バックアップポリシー BP_4 を作成します。これは時刻ベースのバックアップスケジュールであり、スケジュールの頻度の種類は週次に設定され、実行日は日曜日に設定され、実行時刻は午前 8 時に設定されます。バックアップストレージは、保存場所 BackupStore1 を使用するように構成されます。 Enable Application Backup API を使用して、サービス SvcB1 に対してこのポリシーを有効にします。このアクションによって、サービス SvcB1 のすべてのパーティションに対して、バックアップポリシー BP_4 を使用したデータのバックアップが有効になります。
2. バックアップポリシー BP_5 を作成します。これは時刻ベースのバックアップスケジュールであり、スケジュールの頻度の種類は日次に設定され、実行時刻は午前 8 時に設定されます。バックアップストレージは、保存場所 BackupStore1 を使用するように構成されます。 Enable Partition Backup API を使用して、パーティション SvcB2_P1 に対してこのポリシーを有効にします。このアクションによって、パーティション SvcB2_P1 に対して、バックアップポリシー BP_5 を使用したデータのバックアップが有効になります。

次の図は、明示的に有効になっているバックアップポリシーと、伝達されたバックアップポリシーを示しています。

Service Fabric Application Hierarchy

バックアップを無効にする

データをバックアップする必要がない場合は、バックアップポリシーを無効にできます。 "アプリケーション" で有効なバックアップポリシーは、Disable Application Backup API を使用して、同じ "アプリケーション" でのみ無効にでき、"サービス" で有効なバックアップポリシーは、Disable Service Backup API を使用して、同じ "サービス" で無効にでき、"パーティション" で有効なバックアップポリシーは、 Disable Partition Backup API を使用して、同じ "パーティション" で無効にできます。

"アプリケーション" に対するバックアップポリシーを無効にすると、Reliable Stateful Services パーティションまたは Reliable Actors パーティションへのバックアップポリシーの伝達の結果発生するすべてのデータの定期バックアップが停止します。
"サービス" に対するバックアップポリシーを無効にすると、その "サービス" のパーティションへのバックアップポリシーの伝達の結果発生するすべてのデータの定期バックアップが停止します。
"パーティション" に対するバックアップポリシーを無効にすると、パーティションのバックアップポリシーによって発生するすべてのデータの定期バックアップが停止します。
エンティティ (アプリケーション/サービス/パーティション) に対するバックアップを無効にしている場合、CleanBackup を true に設定して、構成したストレージのバックアップをすべて削除することができます。
```
{
    "CleanBackup": true 
}
```

Note

バックアップを無効にする前に、アプリケーションのアップグレードが進行中でないことを確認してください。

バックアップの中断と再開

データの定期バックアップを一時的に中断しなければならない特定の状況が発生する場合があります。このような状況では、要件に応じて、"アプリケーション"、"サービス"、または "パーティション" で Suspend Backup API を使用できます。定期バックアップの中断は、中断が適用されたアプリケーションの階層からサブツリーに伝達されます。

Suspend Application Backup API を使用して "アプリケーション" に中断を適用した場合は、そのアプリケーションの下のすべてのサービスとパーティションで、データの定期バックアップが中断されます。
Suspend Service Backup API を使用して "サービス" に中断を適用した場合は、そのサービスの下のすべてのパーティションで、データの定期バックアップが中断されます。
Suspend Partition Backup API を使用して "パーティション" に中断を適用した場合は、そのサービスの下のパーティションで、データの定期バックアップが中断されます。

中断する必要がなくなったら、該当する Resume Backup API を使用して、データの定期バックアップを復元できます。定期バックアップは、中断された "アプリケーション"、"サービス"、または "パーティション " で再開する必要があります。

中断が "アプリケーション" に適用された場合は、Resume Application Backup API を使用して再開する必要があります。
中断が "サービス" に適用された場合は、Resume Service Backup API を使用して再開する必要があります。
中断が "パーティション" に適用された場合は、Resume Partition Backup API を使用して再開する必要があります。

中断とバックアップの無効化の違い

バックアップの無効化は、特定のアプリケーション、サービスまたはパーティションでバックアップが不要となった場合に使用する必要があります。クリーンバックアップパラメーターを true に (既存のバックアップもすべて削除されるように) 設定すると共に、バックアップの無効化要求を呼び出すことができます。しかし、ローカルディスクがいっぱいになった場合や、既知のネットワークの問題などによりバックアップのアンロードが失敗する場合など、バックアップを一時的に無効にするシナリオでは中断を使用する必要があります。

無効化を呼び出せるのは、以前にバックアップに対して明示的に有効にしたレベルでのみとなりますが、中断は、バックアップに対して現在、直接または継承/階層を介して有効になっているレベルで適用できます。たとえば、バックアップがアプリケーションレベルで有効になっている場合、そのアプリケーションレベルでのみ無効化を呼び出すことができますが、中断は、アプリケーション、そのアプリケーションの下の任意のサービスまたはパーティションで呼び出すことができます。

データ損失の自動復元

予期しない障害によって、サービスパーティションでデータ損失が発生する場合があります。たとえば、パーティションの 3 つのレプリカのうちの 2 つのディスク (プライマリレプリカを含む) が破損または消去された場合です。

Service Fabric は、パーティションでデータ損失が発生したことを検出すると、パーティションで OnDataLossAsync インターフェイスメソッドを呼び出して、パーティションで必要なアクションを実行してデータ損失の状態を脱することを期待します。この状況では、パーティションの有効なバックアップポリシーで AutoRestoreOnDataLoss フラグが true に設定されている場合、このパーティションに対して利用できる最新のバックアップを使用して、復元が自動的にトリガーされます。

Note

運用環境クラスターでは、自動復元を設定しないことをお勧めします。

バックアップ構成を取得する

"アプリケーション"、"サービス"、および "パーティション" スコープでのバックアップ構成情報を取得するための API を使用できます。 Get Application Backup Configuration Info Get Service Backup Configuration Infoおよび Get Partition Backup Configuration Info が、それぞれに該当する API です。主に、これらの API は、適切なバックアップポリシー、バックアップポリシーが適用されるスコープ、およびバックアップの中断の詳細を返します。これらの API から返される結果についての簡単な説明を次に示します。

アプリケーションのバックアップ情報: アプリケーションに適用されたバックアップポリシーと、そのアプリケーションに属するサービスとパーティションのすべての上書きポリシーの詳細を示します。アプリケーション、サービス、およびパーティションの中断情報も含まれます。
サービスのバックアップ構成情報: サービスで有効なバックアップポリシーの詳細、そのポリシーが適用されたスコープ、およびサービスのパーティションのすべての上書きポリシーを示します。サービスとそのパーティションの中断情報も含まれます。
パーティションのバックアップ構成情報: パーティションで有効なバックアップポリシーの詳細と、そのポリシーが適用されたスコープを示します。パーティションの中断情報も含まれます。

使用可能なバックアップを一覧表示する

Get Backup List API を使用して、使用可能なバックアップを表示できます。 API 呼び出しの結果には、適切なバックアップポリシー内に構成されるバックアップストレージで利用できるすべてのバックアップに関連するバックアップ情報の項目が含まれます。アプリケーション、サービス、またはパーティションに属している使用可能なバックアップを一覧表示する、この API のさまざまなバリエーションが提供されています。これらの API は、すべての適切なパーティションで利用できる "最新の" バックアップの取得、または "開始日" と "終了日" に基づくバックアップのフィルター処理をサポートします。

これらの API は、結果の改ページもサポートし、MaxResults パラメーターがゼロ以外の正の整数に設定されている場合は、最大 MaxResults 個のバックアップ情報項目を返します。 MaxResults の値を超える数のバックアップ情報項目がある場合は、継続トークンが返されます。有効な継続トークンのパラメーターを使用して、後続の結果セットを取得できます。有効な継続トークンの値が後続の API の呼び出しに渡され、API は、後続の結果セットを返します。使用可能なすべての結果が返される場合、応答に継続トークンは含まれません。

サポートされているバリエーションに関する簡単な情報を次に示します。

アプリケーションバックアップリストの取得: 特定の Service Fabric アプリケーションに属するすべてのパーティションで使用できるバックアップの一覧を返します。
サービスバックアップリストの取得: 特定の Service Fabric サービスに属するすべてのサービスで使用できるバックアップの一覧を返します。
パーティションバックアップリストの取得:指定されたパーティションで使用できるバックアップの一覧を返します。

次のステップ

バックアップと復元用の REST API リファレンス

Azure Service Fabric の定期バックアップ構成を理解する

バックアップ ポリシーの作成

定期バックアップを有効にする

バックアップ ポリシーの階層的な伝達

バックアップ ポリシーの上書き

例

バックアップを無効にする

バックアップの中断と再開

中断とバックアップの無効化の違い

データ損失の自動復元

バックアップ構成を取得する

使用可能なバックアップを一覧表示する

次のステップ

その他のリソース

バックアップポリシーの作成

バックアップポリシーの階層的な伝達

バックアップポリシーの上書き