我们已在Azure自动化中设置了几个Runbook来备份数据库。
我们有4个Runbook,每个我们希望备份的数据库一个。
这些Runbook中的每一个都调用了一个子Runbook(DBBackup.ps1),其中包含用于标识要备份的数据库的特定参数,生成的blob的文件名前缀等。
DBBackup.ps1包含用于选择Azure帐户和订阅然后执行备份的代码。
我们每天凌晨1点运行一个计划,并且4个数据库Runbook与此计划相关联。
这一切都很好,有时候。
我们最终得出的结论是,因为这些Runbook并行运行,有时当他们尝试设置帐户和订阅时,他们会收到以下错误:
该进程无法访问该文件 'C:\ Users \ Client \ AppData \ Roaming \ Windows Azure Powershell \ AzureProfile.json'因为它正被另一个人使用 处理。 (该进程无法访问该文件 'C:\ Users \ Client \ AppData \ Roaming \ Windows Azure Powershell \ AzureProfile.json'因为它正被另一个人使用 过程。)
我不确定该怎么做,因为我认为Runbook会因为单独的工作而被隔离。
任何帮助表示感谢。
从评论中更新:
我意识到我可以将这一切包装在重试逻辑中。我想要理解的是为什么我认为彼此隔离的四个独立的工作尝试访问相同的本地文件。
作为我一夜之间结果的一个例子:
此列表中的第2和第4个作业失败,因为AzureProfile.json已被锁定。
答案 0 :(得分:3)
在Azure上运行Azure自动化Runbook时(与混合工作者相比),会生成沙箱环境以运行该作业。出于保护目的,同时运行的作业通常最终使用相同的沙箱环境。在这种情况下,似乎正在写入AzureProfile.json文件,以便存储您引用的订阅。由于您尝试编写和更改每个Runbook的订阅,因此会产生写入错误。要解决此问题,我建议您序列化Runbook或创建多个Azure自动化帐户,以便同时单独运行每个帐户。
编辑:ASM cmdlet具有Profile参数作为内置变通方法,但ARM cmdlet尚不支持此参数。如果这对您有影响,我建议您在GitHub(https://github.com/Azure/azure-powershell/issues/1257)上提出此问题。同时,您可以使用以下代码来锁定沙箱,确保它们落在同一个沙箱中,以便线程被序列化。
$LockName = $pid
Write-Verbose "Using lock $lockName";
$Lock = New-Object System.Threading.Mutex($false, $LockName);
$Lock.WaitOne();
try
{
}
finally
{
$Lock.ReleaseMutex();
$Lock.Dispose();
}