使用GCP可抢占式VM几个月以来都没有问题,但是在过去的4周中,我的实例在运行10分钟到20分钟的任何时间都一直关闭。
我将在训练中,笔记本电脑突然断开。终端将显示此错误:
jupyter@fastai-instance:~$ Connection to 104.154.142.171 closed by remote host.
Connection to 104.154.142.171 closed.
ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255].
然后我检查我的VM的状态,以查看它已关闭。
我搜索了终端回溯并发现了这个线程,它似乎很有前途:ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255]
当我运行sudo gcloud compute config-ssh
时,我的虚拟机在关闭之前的运行时间比平常长得多,但大约一个小时后以相同的方式关闭。从那以后,回到相同的行为。
我知道当平台需要资源时,可以关闭抢占式实例,但是我的理解是,它带有某种警告。关闭后,我已经检查了GCP服务器的状态,它们看起来还不错。每次打开虚拟机时,这种情况也以相同的方式发生,这似乎太抢占了。
我不确定在哪里可以找到任何线索–其他人有这样的问题吗?让我特别困惑的是,如果这实际上是SSH问题,为什么会导致VM本身关闭而不是仅仅断开连接?
非常感谢您的帮助!
答案 0 :(得分:2)
如果VM停止并且您具有到该VM的活动SSH连接(通过gcloud compute ssh
),则通常会收到错误消息。由于VM关闭,所有连接都将关闭,SSH连接也将关闭(您无法连接到已停止的实例)。 VM终止会导致SSH错误,而不是相反。
使用抢占式实例时,Google可以在需要时回收该实例。请注意(from the docs about preemptible instances limitations):
由于系统事件,Compute Engine可能随时终止可抢占的实例。通常,Compute Engine会为系统事件终止可抢占实例的可能性很小,但根据当前情况的不同,每天和每个区域都可能会有所不同。
这意味着有一天,您的实例可能会运行24小时而不会终止,但是另一天,如果Compute Engine需要回收某些资源,则实例可能会在启动后30分钟内停止。
答案 1 :(得分:1)
您是否尝试设置shutdown script并在文件中打印一些内容以验证VM停机时的状态?
尝试将其作为关闭脚本
fixed_str = [your json above, fixed into valid json format]
target = fixed_str.replace("dealDetails",'xxx{ "dealDetails').split("xxx") #this splits the script tag by first removing preceding irrelevant stuff
final = target[1].replace("}\n};","}}\n}xxx").split('xxx') #this splits it again by dropping trailing irrelevant stuff
json_obj = json.loads(final[0])
json_obj
如果文件中包含TRUE,那是因为VM已被抢占。
答案 2 :(得分:1)
对“持续关闭”部分的评论: (我也经历过)
请记住,与之前启动的实例相比,Google更喜欢关闭“最近启动”的可抢占实例。
下面的链接(以及之前提供的)具有以下语句:
通常,Compute Engine避免从单个客户那里抢占太多实例,并在可能的情况下优先于旧实例抢占新实例。
通常,这是说,是的,我想,如果您被抢占并重新启动,则很有可能一次又一次被抢占,直到区域中的负载减少为止。
令我惊讶的是Google并没有阻止您启动可抢占式VM一段时间(例如30至60分钟?)。 -浪费了多少CPU来回弹动VM并耗费了我们的手指??
P.S。。有一个肮脏的技巧可以消除您的无奈之感-相同地配置2个VM(可抢占性除外),但只有1个基础工作簿磁盘。如果您在抢先中度过了糟糕的一天,只需将启动磁盘“移动”到不可抢占的VM中,进行启动,然后继续。 -这是几个简单的gcloud命令,可轻松实现脚本且非常快速,以实现此目的。不要告诉Google我告诉过你。...
https://cloud.google.com/compute/docs/instances/preemptible#limitations