导出 (0) 打印
全部展开

更新 Azure 服务

更新时间: 2014年5月

Azure 将你的角色实例划分为称为升级域的逻辑组。默认升级域数量为 5 个。可以在服务定义文件 (.csdef) 中包含 upgradeDomainCount 属性以指定不同数量的升级域。有关 upgradeDomainCount 属性的详细信息,请参阅 WebRole 架构WorkerRole 架构

在为你的服务中的一个或多个角色执行就地更新时,Azure 将根据所属的升级域更新角色实例集。Azure 更新给定升级域中的所有实例(停止这些实例,更新这些实例并将它们重新联机),然后移到下一个域上。通过仅停止在当前升级域中运行的实例,Azure 确保在执行更新时将对运行的服务造成的影响降到最低。有关详细信息,请参阅本文后面的 How the update proceeds

note备注
虽然更新升级术语在 Azure 上下文中的含义略有不同,但在本文中的功能过程和描述中可以互换。

你的服务必须至少定义角色的两个实例,以便就地更新该角色而无需停机。如果服务仅包含某个角色的一个实例,在完成就地更新之前,将无法使用你的服务。

本主题包含有关 Azure 更新的以下信息:

下表显示了在更新期间允许进行的服务更改:

 

允许对托管、服务和角色进行的更改 就地更新 过渡(VIP 交换) 删除并重新部署

操作系统版本

.NET 信任级别

虚拟机大小

Warning警告
更改虚拟机大小将会销毁本地数据。

note备注
需要 Azure SDK 1.5 或更高版本。

本地存储设置

仅增加。

note备注
需要 Azure SDK 1.5 或更高版本。

在服务中添加或删除角色

特定角色的实例数

服务的终结点数量或类型

note备注
需要 Azure SDK 1.5 或更高版本。

Important重要提示
在更新终结点时,可用性可能会暂时中断。

配置设置的名称和值

配置设置的值(但不包括名称)

添加新的证书

更改现有的证书

部署新的代码

在更新期间,不支持以下操作:

  • 更改角色的名称。删除角色,然后使用新名称添加角色。

  • 更改升级域计数。

  • 减小本地资源的大小。

如果对你的服务定义进行其他更新(如减小本地资源的大小),则必须执行 VIP 交换更新。有关详细信息,请参阅管理 Azure 来宾操作系统升级

在 Azure 结构控制器接受初始更新请求后,Azure 允许你对服务启动额外的操作,从而提高了在更新期间管理服务方面的灵活性。只有在更新(配置更改)或升级在部署上处于“进行中”状态时,才能执行回滚。只要至少有一个服务实例尚未更新为新版本,就认为更新或升级处于“进行中”状态。要测试是否允许回滚,请检查 获取部署获取云服务属性 操作返回的 RollbackAllowed 标志值是否设置为 true

note备注
这仅对在“就地”更新或升级上调用 Rollback 有意义,因为 VIP 交换升级涉及将服务的一个完整运行实例替换为另一个实例。

回滚进行中的更新将对部署产生以下影响:

  • 不会更新或升级任何尚未更新或升级为新版本的角色实例,因为这些实例已运行服务的目标版本。

  • 已更新或升级为新版本的服务包 (*.cscfg) 文件和/或服务配置 (*.cspkg) 文件的任何角色实例将恢复为这些文件的升级前版本。

此功能是由以下功能提供的:

  • 回滚更新或升级 操作;只要服务中至少有一个实例尚未更新为新版本,就可以在配置更新上调用该操作(通过调用 更改部署配置 触发),或者在升级上调用该操作(通过调用 升级部署 触发)。

  • LockedRollbackAllowed 元素;这是作为 获取部署获取云服务属性 操作响应正文的一部分返回的:

    1. Locked 元素用于检测何时可以在给定部署上调用变异操作。

    2. RollbackAllowed 元素用于检测何时可以在给定部署上调用 回滚更新或升级 操作。

    要执行回滚,你不需要检查 LockedRollbackAllowed 元素。确认 RollbackAllowed 设置为 true 就足够了。只有在使用设置为“x-ms-version: 2011-10-01”或更高版本的请求标头调用这些方法时,才会返回这些元素。有关版本控制标头的更多信息,请参阅服务管理版本控制

在某些情况下,不支持回滚更新或升级,其中包括:

  • 本地资源减少 - 如果更新增加了角色的本地资源,则 Azure 平台不允许进行回滚。有关如何配置角色的本地资源的详细信息,请参阅配置本地存储资源

  • 配额限制 - 如果更新是配额缩减操作,你可能没有足够的计算配额再完成回滚操作。每个 Azure 订阅具有关联的配额,以指定属于该订阅的所有托管服务可以使用的最大内核数。如果执行给定更新的回滚操作而导致订阅超过配额,则不会启用回滚。

  • 争用情况 - 如果初始更新已完成,则无法进行回滚。

回滚更新可能是非常有用的,其中的一个例子是,在手动模式下使用 升级部署 操作控制为你的 Azure 托管服务部署主要就地升级的速度。

在升级部署期间,你可以在手动模式下调用 升级部署 并开始依次更新升级域。在监视升级时,如果你在某些时候注意到你检查的第一批升级域中的某些角色实例停止响应,你可以在部署上调用 回滚更新或升级 操作,这会将尚未升级的实例保持不变,并将已升级的实例回滚到以前的服务包和配置。

在某些情况下,你可能需要在进行的部署上启动多个同时的变异操作。例如,你可能执行一个服务更新,并在你的服务中部署该更新的同时希望进行一些更改,例如,回滚更新,应用不同的更新,甚至删除部署。一种可能需要执行此操作的情况是,服务升级包含错误的代码,而导致升级的角色实例反复崩溃。在这种情况下,Azure 结构控制器无法继续应用该升级,因为升级域中的正常实例数不足。这种状态称为卡住的部署。你可以回滚更新或应用全新的更新以覆盖失败的更新,从而纠正卡住的部署状态。

在 Azure 结构控制器收到更新或升级服务的初始请求后,你可以启动后续的变异操作。即,你不必等待初始操作完成,即可启动其他变异操作。

在进行第一个更新的同时启动第二个更新操作将以类似回滚操作的方式执行。如果第二个更新是在自动模式下执行的,将立即升级第一个升级域,这可能会导致多个升级域中的实例在同一时刻处于脱机状态。

变异操作如下所示:更改部署配置升级部署更新部署状态删除部署回滚更新或升级

获取部署获取云服务属性 这两个操作返回 Locked 标志,可以检查该标志以确定是否可以在给定部署上调用变异操作。

要调用返回 Locked 标志的这些方法版本,必须将请求标头设置为“x-ms-version: 2011-10-01”或更高版本。有关版本控制标头的更多信息,请参阅服务管理版本控制

Azure 在设置的升级域数之间平均分配角色的实例,可以将升级域数配置为服务定义 (.csdef) 文件的一部分。最大升级域数为 20 个,默认值为 5 个。有关如何修改服务定义文件的详细信息,请参阅 Azure 服务定义架构(.csdef 文件)

例如,如果你的角色具有 10 个实例,则每个升级域默认包含 2 个实例。如果你的角色具有 14 个实例,则四个升级域分别包含 3 个实例,第五个域包含 2 个实例。

以从零开始的索引标识升级域:第一个升级域的 ID 为 0,第二个升级域的 ID 为 1,依此类推。

下图说明了在服务定义了两个升级域时,如何分配包含两个角色的服务。该服务运行 8 个 Web 角色实例和 9 个辅助角色实例。

升级域的分发

note备注
请注意,Azure 控制如何在升级域之间分配实例。无法指定将哪个实例分配给哪个域。

你可以决定是要更新服务中的所有角色,还是更新服务中的一个角色。在这两种情况下,将停止要进行升级并属于第一个升级域的每个角色的所有实例,进行升级,然后恢复联机。在这些实例恢复联机后,将停止第二个升级域中的实例,进行升级,然后恢复联机。

下图说明了在升级服务中的所有角色时如何进行升级:

升级服务

下图说明了在仅升级一个角色时如何进行更新:

升级角色
note备注
在将服务从单个实例升级到多个实例时,由于 Azure 升级服务的方式,将在执行升级时停止服务。保证服务可用性的服务级别协议仅适用于部署的具有多个实例的服务。以下列表说明了每种 Azure 服务升级方案如何影响每个驱动器上的数据:

VM 重新启动:

  • C:已保留

  • D:已保留

  • E:已保留

门户重新启动:

  • C:已保留

  • D:已保留

  • E:已破坏

门户重置映像:

  • C:已保留

  • D:已破坏

  • E:已破坏

就地升级:

  • C:已保留

  • D:已保留

  • E:已破坏

节点迁移:

  • C:已破坏

  • D:已破坏

  • E:已破坏

注意,在上面的列表中,E:驱动器表示角色的根驱动器,而不应进行硬编码。相反,应使用 %RoleRoot% 环境变量表示该驱动器。

要在升级单实例服务时最大限度减少停机时间,请将新的多实例服务部署到过渡服务器中并执行 VIP 交换。

显示:
© 2014 Microsoft