1

Azure Batch .net チュートリアルでは、タスク、ジョブ、プールの順に削除する方法が示されています。同時に、クリーンアップに関するこの記事を見つけました。ジョブとプールを削除するのではなく、使用されなくなった VM を削除するだけです。これは良い戦略ですか？タスクと一般的な組織を追跡するのに役立つと思いますが、完了したタスクの VM を削除した後、タスク、ジョブ、およびプールを保持することの意味は何ですか?

2018-05-15 更新

特定のジョブのタスクの最大数は 7770 です。

以下の回答に従って、最終的に 7770 のタスクを蓄積したジョブにたどり着きました。この魔法の数の後、バッチ サービスはジョブに新しいタスクを追加できなくなり、次の例外がスローされました。

System.AggregateException: One or more errors occurred. ---> Microsoft.Azure.Batch.Common.BatchException: InternalError: Server encountered an internal error. Please try again after some time.
RequestId:e6ab60e0-5c3b-4116-9ffb-ba2032154318
Time:2018-05-15T11:17:17.2186951Z
   at Microsoft.Azure.Batch.Protocol.CloudPoolOperations.<GetAsync>d__65.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Azure.Batch.Protocol.BatchRequest`2.<ExecuteRequestWithCancellationAsync>d__c.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Azure.Batch.Protocol.BatchRequest`2.<ExecuteRequestAsync>d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Azure.Batch.ProtocolLayer.<ProcessAndExecuteBatchRequest>d__11b`2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Azure.Batch.PoolOperations.<GetPoolAsync>d__3.MoveNext()
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at Microsoft.Azure.Batch.PoolOperations.GetPool(String poolId, DetailLevel detailLevel, IEnumerable`1 additionalBehaviors)
   at Pepe.Helpers.Batch.CreatePool()
   at Pepe.Helpers.LogEntryMaintainer.LaunchJob(LogFile log, PepeEntities db)

履歴データの定期的なクリーンアップをお勧めします。この情報をどこかに保持する必要がある場合は、テーブル ストレージなどの場所に移動することをお勧めします。

4

1 に答える 1

8

タスクやそのジョブを削除する必要はまったくありません。また、それらをシステムに残しておくことによる実際のマイナス面はありません。ただし、Batch アカウント内のアクティブなジョブの数にはクォータがあるため、完了時にジョブを終了する必要があります。

プールと VM に関しては、リソースをどのように管理するかはユーザー次第です (特に、これらにはコストがかかることを考えると)。一般的なアプローチには次のものがあります。

  • 1 つ以上のジョブを実行するプールを明示的に作成します。終了したらプールを削除します。VM の数を増減する場合は、プールを明示的にサイズ変更することもできます。
  • Autopool 機能を使用して、ジョブの送信で自動的に作成されるプールを指定します。ジョブが終了すると、プールは自動的に削除されます。
  • 明示的にプールを作成し、ジョブが送信されて完了したときにプールをスケールアップおよびスケールダウンできる自動スケーリング式を定義します。これは、リソースの使用率を最大化し、コストを最小化するための非常に強力な機能です。

それが役立つことを願っています。

于 2016-03-02T16:40:08.050 に答える