【问题标题】:Azure Batch mounting blob storage on pool results in error "Counld not install package"Azure Batch 在池上安装 blob 存储导致错误“无法安装包”
【发布时间】:2020-03-16 08:23:27
【问题描述】:

我有一个 Azure Batch 池,其中安装了三个 Blob 存储容器。但是,当节点第一次启动时,它会出现以下错误:

查看日志,似乎节点在安装 blobfuse 包时遇到了问题。反复收到此错误消息:

2020-03-11T09:15:48,654579941+00:00 - INFO: Downloading: https://packages.microsoft.com/keys/microsoft.asc as microsoft.asc
2020-03-11T09:15:48,770319520+00:00 - INFO: Downloading: https://packages.microsoft.com/config/ubuntu/16.04/prod.list as /etc/apt/sources.list.d/microsoft-prod.list
Hit:1 http://azure.archive.ubuntu.com/ubuntu xenial InRelease
Hit:2 http://azure.archive.ubuntu.com/ubuntu xenial-updates InRelease
Hit:3 http://azure.archive.ubuntu.com/ubuntu xenial-backports InRelease
Hit:4 http://security.ubuntu.com/ubuntu xenial-security InRelease
Get:5 https://packages.microsoft.com/ubuntu/16.04/prod xenial InRelease [4,002 B]
Get:6 https://packages.microsoft.com/ubuntu/16.04/prod xenial/main amd64 Packages [124 kB]
Fetched 128 kB in 0s (383 kB/s)
Reading package lists...
E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
...

2020-03-11T09:16:53,361634408+00:00 - ERROR: Could not install packages (apt): blobfuse

节点然后进入状态Unusable,直到我手动重新启动它们,这将“修复”问题,然后节点开始处理任务。

任务应该以提升的权限运行:

UserIdentity = new UserIdentity(
                new AutoUserSpecification(
                      elevationLevel: ElevationLevel.Admin,
                      scope: AutoUserScope.Pool
                  )
              ),

更新 1

我无法解决这个问题,所以我决定解决它。调整大小或重新创建池没有帮助。相反,我在 Docker 映像中安装了 blobfuse,并将 blob 存储容器安装在任务本身中。这工作得很好。

【问题讨论】:

  • 你需要root权限来安装这些包吗?
  • @Aravind 可能。任务本身以管理员身份运行,但当新节点加入时,此进程在池本身上运行。我对这个过程没有太多控制权。我所做的只是添加了安装配置,我认为 azure 应该可以解决其余的问题。
  • +1:这看起来像installation issue with the Blobfuse package,尝试将resizing or reboot 您的池恢复为零,然后扩大规模,我认为作为 joinpool 的新加入 VM 应该会触发新安装。这应该会有所帮助。
  • 嗨@NiklasNoem 好方法,但请记住,如果您的那种blobfuse驱动程序有一个现有的拥抱,它会在65小时后在此处提供详细信息:github.com/Azure/azure-storage-fuse/issues/329,如果 docker 不是必要时,您始终可以通过脚本在普通批处理节点的启动任务级别执行此操作。
  • @Tats_innit 谢谢你的提示。这可能比任何任务运行的时间都要长,并且池是自动缩放的,因此它将重新连接。再次感谢您的帮助。

标签: azure azure-batch


【解决方案1】:

您的方法看起来不错并且很高兴重新启动修复了它,在这种特定情况下,这是正确的修复以及重新调整大小。

感谢分享日志,这看起来像是failureInstallation with the Blobfuse 的问题

最大的好处是:**ERROR: Could not install packages (apt): blobfuse** 是最大的指标,本质上在引擎盖下节点看起来要安装 blobfuse,并且似乎某些进程具有长时间运行的 apt install 并行。 The cause of this error is detailed here E: Could not get lock /var/lib/dpkg/lock-frontend - open.

2个可能的解决方案

  • 就像您提到的那样,重新启动已修复。
  • 另一个选项是调整大小池。 更好:重新创建池,然后尝试。

为什么重启或调整大小会修复它:基本上在这两种情况下,VM 都会在批处理结束时调用加入池进程并刷新内存,这将有助于解除阻塞 blobfuse 的锁定情况。在批处理节点级别,我们可以尝试某种退避机制。我也会密切关注 blobfuse,如果其中的某些原因导致了这个 https://github.com/Azure/azure-storage-fuse

希望这会有所帮助。

【讨论】:

  • 感谢您的回复。池中有一个自动缩放公式。每当一个节点加入我认为的池时,都会出现这个问题。当我可以确认这一点时,我会回复你。如果是这样的话,我一定做错了什么。我不能每次都手动重启所有节点,所以希望能找到解决方案。
  • 感谢您的 ping!是的,那太好了,请检查一下,因为这不应该是任何时候的情况,我尝试了 5 次并且无法生成这个,但是如果底层 apt 之一需要更长的时间或者可能是 blobfuse 驱动程序,则可能会发生这种情况下载时遇到问题或花时间。
  • 不幸的是,我现在可以确认每次节点加入池时都会发生这种情况。
  • 感谢您的回复,@NiklasNoem 很酷,您是否尝试过将池的大小调整为零并再次返回,或者如果可以尝试重新创建池?本质上,就像上面提到的那样,在安装 blobfuse 驱动器时,一些长期运行的底层 apt 会被锁定。
  • 池采用自动缩放公式,每当创建新任务时,它会将池的大小调整为 0 并再次增加。它已自动、手动调整大小以及完全重新创建,但问题仍然存在。这意味着它一定是我做过的事情,我想?让节点运行的唯一方法是在它们达到初始不可用状态后手动重新启动它们。
【解决方案2】:

我遇到了完全相同的问题,因为我正在创建动态池和任务,因此无法手动介入并重新启动。

我的解决方法是将批处理帐户链接到存储帐户,然后将资源文件指定为任务的一部分。这使容器在任务的工作目录中可见。

这是我在 NodeJS 中的示例,它应该可以转换为您选择的语言。

{
        id: taskId,
        commandLine: "",
        containerSettings: taskContainerSettings,
        environmentSettings: [
            {
                name: "USER_ID",
                value: userId
            },
            {
                name: "RUN_ID",
                value: runId
            }],
        resourceFiles: [{"autoStorageContainerName": userId}]
};

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2019-06-09
    • 2019-07-06
    • 1970-01-01
    • 1970-01-01
    • 2020-08-02
    • 1970-01-01
    • 1970-01-01
    • 2013-08-11
    相关资源
    最近更新 更多