Control-M + Amazon EC2

あなたの Amazon EC2 ワークフローは、VM ライフサイクル操作が実行される前に始まります。上流で何かが壊れると、失敗する可能性があります。Amazon S3 オブジェクトが届かない。AWS Step Functions ステートマシンが期待されるウィンドウ外で完了します。Control-M は、S3 オブジェクトの到着、Lambda 前処理、EC2 VM 操作、下流アプリケーションの引き渡しを編成します。

あなたのようなパイプラインで見る統合事実を見る

一般的なワークフローの問題

今週はこんな感じですか？

これはエッジケースではありません。これらは、複数のツールでAmazon EC2ワークフローを実行しているチームの通常の運用条件です。Control-Mがそれぞれをどのように処理するかを見てみましょう。

上流依存関係

あなたのS3オブジェクトが遅れています。EC2インスタンスはそれでも開始します。

Control-MはEC2操作を必要な上流条件が満たされるまで保持し、その後同じワークフローの一部として解放します。依存関係が切り離されたスケジュールに置き換わり、サポートするワークロードが準備できる前にコンピュートが開始されるのを防ぎます。

APIスロットリング

AWSはHTTP 429を返します。あなたの夜間ワークフローはそこで停止します。

Control-Mは設定されたHTTPレスポンスコードを検出し、EC2実行ステップを定義された間隔と試行回数を使用して再実行できます。一時的なAWS APIレスポンスは、自動的に再試行されることができ、即時の手動回復タスクになることはありません。

フリートオペレーション

タグ付けされた二十のインスタンスが開始する必要があります。誰かが再びスクリプトを作成しています。

Control-MはタグによってEC2仮想マシンを開始、停止、または再起動できます。複数の一致するインスタンスに操作を適用します。チームは生産ワークフロー内でフリートレベルのライフサイクルアクションを調整することができ、別々のスクリプトやスケジューリングロジックを維持する必要がなくなります。

状態の検証

開始リクエストは成功しました。インスタンスは期待される状態に達しませんでした。

Control-Mは、構成可能なポーリング間隔と許容範囲を使用してEC2ジョブの状態を検証します。操作が必要な状態に達しない場合、ジョブはNot OKで終了し、依存する作業が続行される前に失敗が明らかになります。

SLAリスク

EC2が遅れています。下流のビジネス締切が近づいています。

Control-Mは、EC2ジョブを上流および下流の作業と同じスケジューリング環境に持ち込み、チームがSLAジョブを添付できるようにします。オペレーターは、文脈内でインフラストラクチャの操作を追跡し、ワークフローの遅延が未達の約束になる前に対応できます。

統合事実