Control-M + Azure Container Instances

あなたのAzure Container Instancesワークフローは、コンテナグループが実行される前に始まり、上流で何かが壊れると失敗する可能性があります。Azure Blob Storageオブジェクトが遅れて到着します。Azure Data Factoryパイプラインが期待される完了ウィンドウを逃します。Control-Mは、Blob Storageの到着、Data Factoryの処理、Azure Container Instancesの実行、および下流の配信の全チェーンをオーケストレーションします。

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

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

今週のあなたの状況のように聞こえますか？

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

上流の遅延

Blobは午前2時13分に到着しました。コンテナはすでに待機していました。

Control-MはAzure Blob Storageとコンテナワークロードの間の依存関係を調整し、上流のステップが正常に完了した後にのみ実行を解放します。コンテナは切り離されたスケジュールに依存するのではなく、ワークフローとシーケンスで実行されます。

コンテナの失敗

コンテナは一晩中終了しました。下流のワークフローは待機し続けました。

Control-MはAzure Container Instancesのコンテナグループを完了まで監視し、Control-Mジョブの設定された障害許容を適用し、ワークフローにおいて不成功の実行を反映します。

ログトラブルシューティング

コンテナが失敗しました。今、ログを見つけるためにツールを切り替えています。

Control-Mは、構成可能なテールラインとタイムスタンプを使用して、Azure Container Instancesのコンテナログをジョブ出力に取得します。オペレーターは、オーケストレーションされたワークフローに沿って実行コンテキストを取得し、失敗または遅延したコンテナワークロードの診断時にツールの切り替えを減らします。

クロスツールフロー

Data Factoryが完了しました。コンテナのハンドオフは行われませんでした。

Control-Mは、Azure Data FactoryとAzure Container Instancesのジョブを同じスケジューリング環境に配置し、ワークフローディペンデンシーを使用してハンドオフを調整します。成功した上流の完了はコンテナステップを解放し、失敗した前提条件は無効な下流の実行を防ぎます。

SLAリスク

コンテナは成功しました。午前7時のサービスの締切は依然として遅れました。

Control-Mは、コンテナジョブをより広いサービスワークフローに接続し、Azure Container Instancesジョブを含む周囲のジョブフロー全体にわたってControl-M SLA管理を適用します。

統合の事実