次の方法で共有

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

  • [アーティクル]

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

  1. バックアップ ポリシーの作成: このステップでは、要件に応じて 1 つまたは複数のバックアップ ポリシーを作成します。

  2. バックアップの有効化: この手順では、手順 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. マネージド ID を使用する Azure BLOB ストア: Azure で生成されたバックアップを格納する必要がある場合は、このストレージの種類を選択します。 "スタンドアロン" と "クラウドベース" の両クラスターは、このストレージの種類を使用できます。 このストレージの種類の記述には、BlobServiceUri と、バックアップをアップロードする必要があるコンテナーの名前が必要です。 指定した名前のコンテナーが使用できない場合は、バックアップのアップロード時に作成されます。 account-name をストレージ アカウント名に置き換えます。

      {
    "StorageKind": "ManagedIdentityAzureBlobStore",
    "FriendlyName": "AzureMI_storagesample",
    "BlobServiceUri": "https://<account-name>.blob.core.windows.net",
    "ContainerName": "backup-container",
    "ManagedIdentityType": "VMSS",
    "ManagedIdentityClientId": "<Client-Id of User-Assigned MI>" 
}

      [注意] 複数のユーザー割り当てマネージド ID がリソースに割り当てられている場合、または SAMI と UAMI の両方が割り当てられている場合は、省略可能なパラメーター ManagedIdentityClientId をユーザー割り当てマネージド ID のクライアント ID と共に使用し、既定値として UAMI を使用する必要があります。それ以外の場合は、このパラメーターは必要ありません。

      以下に示す Azure リソースでのマネージド ID の割り当ての手順に従います。

      1. VMSS でシステム割り当てまたはユーザー割り当てマネージド ID を有効にします (「仮想マシン スケール セットでマネージド ID を構成する」)

      2. VMSS マネージド ID にストレージ アカウントに対してロールを割り当てます (「Azure portal を使用して Azure ロールを割り当てる - Azure RBAC」)

        1. ストレージ BLOB データ共同作成者ロール以上

      マネージド ID の詳細情報

    2. ConnectionString を使用する Azure BLOB ストア: Azure で生成されたバックアップを格納する必要がある場合は、このストレージの種類を選択します。 "スタンドアロン" と "クラウドベース" の両クラスターは、このストレージの種類を使用できます。 このストレージの種類の記述では、接続文字列と、バックアップをアップロードする必要があるコンテナーの名前が必要です。 指定した名前のコンテナーが使用できない場合は、バックアップのアップロード時に作成されます。

      {
    "StorageKind": "AzureBlobStore",
    "FriendlyName": "Azure_storagesample",
    "ConnectionString": "<Put your Azure blob store connection string here>",
    "ContainerName": "backup-container"
}

      Note

      バックアップ復元サービスは v1 Azure ストレージでは機能しません。ConnectionString は、ユーザー認証なしでリソースに直接アクセスするため、運用環境では推奨されません

    3. ファイル共有: オンプレミスでデータ バックアップを格納しなければならない場合は、スタンドアロン クラスター用のこのストレージの種類を選択する必要があります。 このストレージの種類の記述では、バックアップをアップロードする必要があるファイル共有パスが必要です。 ファイル共有へのアクセスは、次のオプションのいずれかを使用して構成できます。

      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 つのパーティションが含まれています。

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

  1. MyApp_A

    1. このアプリケーションに属するすべての Reliable Stateful Services と Reliable Actors のすべてのパーティションのデータの日次バックアップを作成します。 バックアップ データは、場所 BackupStore1 にアップロードします。

    2. サービスの 1 つである SvcA3 では、データのバックアップを 1 時間ごとに実行する必要があります。

    3. パーティション SvcA1_P2 内のデータのサイズが予想を超えているため、そのバックアップ データは、別の保存場所 BackupStore2 に格納する必要があります。

  2. MyApp_B

    1. 毎日曜日の午前 8 時に、SvcB1 サービスのすべてのパーティションのデータのバックアップを作成します。 バックアップ データは、場所 BackupStore1 にアップロードします。

    2. 毎日曜日の午前 8 時に、パーティション SvcB2_P1 のデータのバックアップを作成します。 バックアップ データは、場所 BackupStore1 にアップロードします。

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

  1. 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 によって上書きされます。

  2. 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 アプリケーションの階層

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

データをバックアップする必要がない場合は、バックアップ ポリシーを無効にできます。 "アプリケーション" で有効なバックアップ ポリシーは、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 InfoGet 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 は、後続の結果セットを返します。 使用可能なすべての結果が返される場合、応答に継続トークンは含まれません。

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

次のステップ