クロス・クラウドのバックアップ

これらのコントロールプランは、複数のクラウドサービスがバックアップとして使用できる例です。スーパーノード（supernode）機能という階層的なコントロールプランを使用します。

二つの別々のクラウドベンダーを使って、Web ベースのアプリケーションを導入したとします。一方のクラウドサービスをプライマリとして使用します。バックアップの構成設定はされていますが、インスタンス化はされていません。（注：バックアップ側のサービスが稼動していてもかまいませんし、その場合バックアップへの切り替えがより早くできますが、稼動サービスに対して支払いが発生します。）

下記のコントロールプランが下記のチェックを行います。

プライマリのクラウドサービスは、稼動しているか確認するためチェックされます。この処理は、さらに詳しく以下で説明します。
稼動していない場合、バックアップのサービスが開始します。この処理はさらに詳しく以下で説明します。
バックアップのサービスが稼動したら、ダイナミック DNS サービスを使い、ホスト名がバックアップサービスを指すよう変更します。
全体プロセスのステータスが監視システムに送られると、オペレータは変更と問題について気が付くでしょう。

プレース check_primary_service と start_backup_service がスーパーノード、つまり別のコントロールプランとなっていることに注意してください。これらのプレースが実行されると、参照されているコントロールプランが実行されます。これにより、プロセスモデルの作成が単純化され、オペレータのための実行ビューがシンプルになります。プライマリのクラウドサービスが稼動しているか確認する check_primary_service コントロールプランを下記に示します。

このプランは、クラウドがダウンしていると判定する前に、複数のサービスの監視結果をチェックします。それは、Web アプリケーションの http チェック、サーバへの ping チェック、クラウドベンダーの API 応答のチェックおよび、接続確認のためにゲートウェイへの　ping を行います。これらすべてのチェックに基づいて、このクラウドサービスが機能しているかどうかの判断が下されます。追加イベントをチェックしてこのプラン内のロジックを拡張することを選んだり、結論を出す前にそのプランのプレースタスク内で追加アクティブチェックを実行することもできます。
バックアップ処理が開始した時、以下のコントロールプランはこの配備処理を実行します。この例は、Amazon Web サービスに基づいています。

Web アプリケーションのためのイメージが検出され、その後開始されます。インスタンスの実行が確認されると、http チェックが開始されたインスタンスに対して実行され、その Web アプリケーションが応答してきることを確認します。サーバの稼動を確認したた後、バックアップのサービス OK のイベントが生成されます。
start_backup_service プランが実行された後、マスターのコントロールプランに制御が戻されます。バックアップサービスが稼動していることが確認されているので、そのバックアップサービスをポイントするよう、ダイナミック DNS サービスを使用することができます。ダイナミック DNS サービスは、あなたにホスト名に関連付けられた IP アドレスを変更するよう、Web サービス呼び出しを発行できるようにします。 backup_service_start プロセスから新しい IP アドレスを取り出して、ホスト名のための DNS エントリをアップデートするための Web サービスを発行します。