Windows Azure 部署域
.jpg "Joseph Fultz")
最近，我一直在认真考虑很多思想到应用程序的部署。原来的应用程序，获取故障容忍和升级路径的矩阵有点棘手 — — 更难的是当应用程序具有服务、 Web UI 和后端过程的混合。添加的地理分布和物流成为更令模糊不清。
在大型 IT 组织、 任何 Web 或应用程序的最低部署服务器往往涉及地理上分隔的两个服务器。这很容易移动四个服务器如果两个服务器指定为期望的负载和你有相同的设置与镜像站点 （当然，数据库和其他支持的服务器基础结构可以推数仍较高)。如果公司服务多个位置，例如，北美和欧洲、 中东和非洲 (EMEA) 吗？现在安装程序获取复制到大西洋两岸的什么车削成八个服务器为土力工程处故障转移和转移资产更接近消费者开始作为两个 Web 服务器。
最终，所有这些服务器上部署的应用程序，一切都畅 — — 然后有些冒失的开发人员创建新的功能，想要更新部署。
你可以想象，需要规划确定的顺序，服务器会排出连接、 获取更新和测试，，然后放回池中的好一些。有些人花晚升级计划，通过工作，这甚至是时有没有真正的问题。
Windows Azure 消除不需要升级计划，但它不会采取很多通过处理大部分是作为织物的一部分升级的复杂性。在本专栏中，我要去盖故障的域和升级的域，并编写代码来部署跨应用升级的稍微有点。
故障和升级域
Windows Azure 包括故障的域和升级的域，这两个几乎完全由它们的名称描述的概念。故障域定义的应用程序部署的物理单位和机架一级中通常分配的。通过将故障域放置在不同机架中，你单独的应用程序部署到硬件不够，不太可能都将会在同一时间失败的实例。进一步，一个故障域中的失败不应沉淀另一种的失败。具有两个配置实例的角色部署时，可确保织物，实例在两个不同的故障域中成长。不幸的是，与故障域，您可以使用多少个域或如何将角色分配给它们没有控制。
升级域是另一回事。您对这些域的控制，可以通过一次升级实例组跨部署执行增量或滚动升级。而故障域是有关物理部署的角色，则升级域涉及的逻辑部署。因为升级域是角色的逻辑分组，单个 Web 应用程序很容易存在五个不同的升级域分为只有两个单独的物理部署 （故障域） 中。在此情况下，要更新的 Web 应用程序，您可能更新组 0 （0 升级域） 中的所有角色，然后第一组中的所有角色，等等。您可以通过更新一次更新的每个域中的各个角色一行使有限的更多控制。
总之，将分成故障的至少两个域的应用程序需要多个实例。要使跨整个农场更容易升级 Web 应用程序中，角色组合到逻辑分组在同一时间进行更新。
查看部署配置
Windows Azure 管理控制台显示更新域的列，但不是故障域的列 （请参见图 1)。（请注意，升级域和更新域是可互换的术语。文档通常指的是升级域，但在 API 中，它被称为更新域）。
.png)
图 1 Windows 天蓝色的管理控制台
在图 1你可以看到我的四个部署中的数字由 0 至 3。默认情况下，Windows Azure 为每个服务使用五更新域，并为它们分配中循环的样式。这是您可以通过向 ServiceDefinition 元素的 upgradeDomainCount 属性分配所需的数量的升级域更改服务定义文件中。你会发现链接的 Web 和工人的角色，在架构的每个 msdn.microsoft.com/library/ee758711。要强制使用仅三个升级域的 WebRole，例如，您设置的 upgradeDomainCount 服务定义文件中：
<ServiceDefinition name="<service-name>" xmlns=”https://schemas.microsoft.com/ServiceHosting/2008/10/
ServiceDefinition” upgradeDomainCount="3">
<WebRole name="<web-role-name>" vmsize="[ExtraSmall|Small|Medium|Large|ExtraLarge]"
enableNativeCodeExecution="[true|false]">
...
</WebRole>
</ServiceDefinition>
这很重要，因为您的计划和执行，最终会影响更新域的数量。不幸的是，没有让你看到故障域分配的列。通过编写少量代码，但是，你可以回力有点上部署和见两个更新域和故障域分配，作为幕图 2 显示。
图 2 查找角色信息
protected void GetRoleInfo()
{
List<RoleInfo> RoleInfos = new List<RoleInfo>();
foreach (var role in RoleEnvironment.Roles)
{
RoleInfo info = new RoleInfo();
info.RoleName = role.Value.Name;
foreach (RoleInstance roleInstance in role.Value.Instances)
{
info.InstanceId = roleInstance.Id;
info.FaultDomain = roleInstance.FaultDomain.ToString();
info.UpgradeDomain = roleInstance.UpdateDomain.ToString();
}
RoleInfos.Add(info);
}
GridView1.DataSource = RoleInfos;
GridView1.DataBind();
}
此代码不显示小的类定义存储有关的信息。不幸的是，虽然我有这种好的嵌套的循环所经历的角色和实例，API 允许返回只运行代码的特定实例相关的数据页中运行的代码。因此，则代码将产生小网格的只是当前 WebRole 中的信息 （见图 3)，没有任何其他实例的信息。
.png)
图 3 当前 WebRole 信息
此代码提供快速查看当前 WebRole 的故障和升级域，但您需要使用获得部署其余 URI 来获得更全面的数据。它返回部署，除其他外，包含的元素的 XML，<Configuration/> 和每个 <RoleInstances/>。一旦你已经读取配置，可以更改它，并把它放回去。看看我在 2010 年 10 月的专栏 (msdn.microsoft.com/magazine/gg232759） 的显示的相同的操作将在这里涉及很多的例子。
升级策略
有两种基本策略更新 Windows Azure 部署：就地升级和虚拟 IP （或贵宾） 交换。VIP 换用更简单的方法是，允许完全测试的新的或更新的应用程序之前的大门向公众。此外，应用程序可以运行满负荷一样是活。如果有问题换用完成时，您可以快速到位以前的版本回虽然目前正在努力新的部署。
你会发现很好的参考，描述什么可以和不能做在每个部署模型中 bit.ly/x7lRO4。下面是可能会强制选择的点：
- 就地更新或删除和部署所需的更改的类型或终结点的数量时。
- VIP 交换或删除和部署所需，当更改角色名称或更新域的计数，或减少本地资源的大小。
除了这些点和一些 SDK 版本注意事项，它是你来决定。
换用过渡和生产环境的 VIP 是一个很好的解决方案，对许多人来说如果没有最，案件时推出的新版本。有时，这是唯一的方法，以保持站点大多是可用状态，同时进行更改，但如果您要升级大型部署，造就另一个全面部署可能会非常麻烦。也是与部署的完整副本相关的成本 — — 计算一小时收费的每个部署实例和正在运行的两个副本，然后将其他计算时间。
在 Web 场如今，更新的一般推出通过一个农场通过以下两种：一次以一台服务器脱机、 升级、 使服务器联机和它回到农场的池 ； 或成段划分农场和排水一段上的连接一次，然后升级每个段，使它联机和它回到农场，并最后移到下一段。
第二种模式像就地更新工程。然而，越升级域使用越多模式类似于第一个选项。使用更多的升级域的好处是，在整个升级过程中的站点容量减少仅由段的大小。
传统的非云部署面临的主要挑战是云计算部署相同的：当您执行滚动升级，将运行混合的版本的应用程序。实例可能会提供不同的视觉效果，使用不同的数据和服务的连接，等等。这可能会导致网站错误或甚至是不合要求的用户体验，并可能为您的业务，在完全不能接受。此外，它对确保在剧中有多个版本时，将运行应用程序的开发和测试团队将一个沉重的负担。
如果您不能使用 VIP 交换和可用性要求排除删除和部署，你该怎么办？您可以尝试使用更新的只有两个域和执行就地更新，这样就可以使部署过程中运行的应用程序的单个版本。缺点：您的站点容量的一半在过渡期间将不可用。
在网格图 4 可能会帮助您考虑哪种方法雇用在执行升级。
图 4 升级决策矩阵
| 部署策略 | 职业玩家 | 利弊 |
| 删除和部署 | 可以进行所有更改 | 应用程序过程中不可用 |
| VIP 交换 |
|
|
就地更新： 2 更新域 |
|
|
就地更新： 3++ 更新域 |
|
|
就地升级
执行升级管理控制台内，并通过编写脚本的能力方面取得了不错的进步。部署相对较少数量的中型组织小，这是最简单的方法管理通过 Windows Azure 管理控制台中显示更新图 5。
.png)
图 5 Windows 天蓝色的管理控制台
你可以看到在屏幕的左上角，手动升级正在运行。这就需要单击开始按钮，启动升级的每个域的过程 — — 这就是它的手动部分。一旦开始更新，控制台显示在每个域，在实例中怎么示图 6。
.png)
图 6 更新活动
手册 》，点击式方法很适合较小型的部署。对于较大的部署或那些凡要自动化生成测试部署过程中，您应选择编写脚本的方法。您可以自动执行过程使用 CSManage 命令行工具，您可以从下载 bit.ly/A6uQRi。CSManage 将启动升级，然后步行通过命令行从一次升级一个更新域的过程。虽然这是很有帮助，是有一定可以只完成直接使用其他 API 的精细控制。
自定义您的升级战略与故障域
如果因为某种原因你决定不更新域步行 0 – n，而是计划使用您自己的起始点或命令，你要看一看的更新和故障域组合。在网格图 7 使明显如果你要更新升级的域 1，在更新期间出现故障的故障域 0，网站将会彻底瘫痪。不过，这通常应包括面料、 和网格显示是否更新发生的顺序，总有不同的故障运行的域。
图 7 域矩阵
| 实例 | 升级域 | 故障域 |
| 0 | 0 | 0 |
| 1 | 1 | 1 |
| 2 | 2 | 0 |
这里的教训是规划，过程中考虑的潜在后果并不"修理"已经工作的东西。
接近尾声了
当你设计一个 Windows Azure 的应用程序时，您需要考虑部署体系结构。Windows Azure 提供保证应用程序将不断裂由于对单个硬件故障，同时提供了一种简单、 自动增量更新部署方法织物的功能。尽管如此，支持就地更新是一定要在应用程序中设计 — — 和被推的更新。
您可以更新使用 VIP 交换或双升级域、 就地计划哪里不能支持全地方更新 Windows Azure 服务。最后，有的用户界面和编程方式控制的部署和更新，这样，您可以执行计划的更新或甚至使用生成测试部署的时间表或计划的更新。
Joseph Fultz 是 Hewlett-Packard Co. 的软件架构师，参与 HP.com 全球 IT 小组的工作。他以前是微软使用其顶级企业和 ISV 客户定义的体系结构和设计解决方案的软件架构师。
多亏了以下的技术专家审查这篇文章： 唐格洛弗