我目前束手无策,试图解决这个问题。
我们有一个步骤函数管道,可以在 Fargate 和 EC2 ECS 实例的混合上运行任务。它们都在同一个集群中。
如果我们运行一个需要 EC2 的任务,并且之后想要运行另一个也使用 EC2 的任务,我们必须输入 20 分钟的 Wait
命令,以便第二个任务成功运行。
它似乎没有使用现有的 EC2 实例,或者当我们运行第二个任务时不再扩展?它给出了 RESOURCE:MEMORY
的错误。我希望它能够扩展更多的 EC2 实例以满足需求,或者使用现有的 EC2 实例来运行任务。
ECS 集群有一个容量提供程序,已开启托管扩展、开启托管终止保护且目标容量为 100%。
ASG 的最小容量为 0,最大容量为 8。 它已经成功扩大规模。 实例类型为r5.4xlarge
重现问题的示例步骤函数:
{
"StartAt": "Set up variables",
"States": {
"Set up variables": {
"Type": "Pass",
"Next": "Map1",
"Result": [
1,
2,
3
],
"ResultPath": "$.input"
},
"Map1": {
"Type": "Map",
"Next": "Map2",
"ItemsPath": "$.input",
"ResultPath": null,
"Iterator": {
"StartAt": "Inner1",
"States": {
"Inner1": {
"ResultPath": null,
"Type": "Task",
"TimeoutSeconds": 2000,
"End": true,
"Resource": "arn:aws:states:::ecs:runTask.sync",
"Parameters": {
"Cluster": "arn:aws:ecs:CLUSTER_ID",
"TaskDefinition": "processing-task",
"NetworkConfiguration": {
"AwsvpcConfiguration": {
"Subnets": [
"subnet-111"
]
}
},
"Overrides": {
"Memory": "110000",
"Cpu": "4096",
"ContainerOverrides": [
{
"Command": [
"sh",
"-c",
"sleep 600"
],
"Name": "processing-task"
}
]
}
}
}
}
}
},
"Map2": {
"Type": "Map",
"End": true,
"ItemsPath": "$.input",
"Iterator": {
"StartAt": "Inner2",
"States": {
"Inner2": {
"ResultPath": null,
"Type": "Task",
"TimeoutSeconds": 2000,
"End": true,
"Resource": "arn:aws:states:::ecs:runTask.sync",
"Parameters": {
"Cluster": "arn:aws:ecs:CLUSTER_ID",
"TaskDefinition": "processing-task",
"NetworkConfiguration": {
"AwsvpcConfiguration": {
"Subnets": [
"subnet-111"
]
}
},
"Overrides": {
"Memory": "110000",
"Cpu": "4096",
"ContainerOverrides": [
{
"Command": [
"sh",
"-c",
"sleep 600"
],
"Name": "processing-task"
}
]
}
}
}
}
}
}
}
}
到目前为止我已经尝试过:
我尝试更改 EC2 实例的冷却时间,取得了一些成功。唯一的问题是它现在扩展得太快了,我们仍然需要等待才能运行更多任务,只是我们需要等待的时间更短。
请告诉我我们想要的是否可行以及如何实现(如果可行) 谢谢
最佳答案
我最近在容量提供商处遇到了类似的情况。通过 ECS 运行任务(使用 Lambda 调用)进行的并发任务放置突发不会在响应中返回任务信息。尽管如此,任务还是在集群上以 PROCESSING 状态排队,等待一段时间,然后最终无法启动,并出现错误 RESOURCE:MEMORY。
推测:问题似乎与容量提供者的CapacityProviderReservation刷新间隔有关:https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/ .
CapacityProviderReservation 需要更改,以便您的集群根据其警报进行扩展(或缩小),但是超出当前总容量的突发任务放置似乎并不总是能满足此要求要求。
如果响应包含空的 tasks[]
集合,我们可以通过指数级后退并重试对 ECS run-task 的调用来克服无法放置任务的行为。这对我们的任务放置吞吐量仅产生了很小的影响,此后我们就没有看到问题再次出现。
关于amazon-web-services - ECS/EC2 自动缩放不处理一个接一个的两个任务,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/72315809/