我正在阅读 Microsoft 网站上对可用性集的解释，但不能 100% 理解这个概念。
http://www.windowsazure.com/en-us/documentation/articles/manage-availability-virtual-machines/
人们在评论中提出了很多问题，但没有来自 Microsoft 的技术支持来回答这些问题。
正如我对可用性集的正确理解，您可以使用 IIS 应用程序复制您的 VM，并使用 SQL 复制 VM，这意味着您必须使用 4 个 VM（支付 4 个）而不是 2 个。这意味着每当 IIS1 虚拟机关闭时，网站仍然会在 IIS2 虚拟机的帮助下在线，反之亦然？SQL1 和 SQL2 虚拟机也一样吗？
我会朝着正确的方向前进吗？如果是这种情况，如何让 SQL1 和 SQL2、IIS1 和 IIS2 虚拟机中的数据同时保持同步，以便在一台 VM 停机更新时，网站仍会保持最新的数据和代码？
可用性集结合了 Windows Azure PaaS 世界中的两个概念——升级域和故障域——这有助于使服务更加健壮。当多个 VM 部署到可用性集中时，Windows Azure 结构控制器会将它们分布在多个升级域和故障域中。
故障域代表一组具有单点故障的虚拟机——考虑它的一种方便（尽管不精确）的方式是具有单个顶部或机架路由器的机架。通过将 VM 部署到不同的故障域中，结构控制器可确保单个故障不会导致整个服务脱机。
结构控制器使用升级域来控制执行主机操作系统升级（即底层物理服务器）的方式。结构控制器一次执行一个升级域的这些升级，只有在前一个升级域的升级完成后才移动到下一个升级域。这样做可确保服务在主机操作系统升级期间保持可用，尽管容量减少。这些升级似乎每隔一两个月就会发生一次，并且将所有 VM 部署到可用性集中的服务不会收到任何警告，因为它们被认为对升级具有弹性。Microsoft 确实提供了有关升级到包含部署在可用性集之外的 VM 的订阅的警告。
此外，对于在可用性集之外部署 VM 的服务，没有 SLA。
对于 SQL Server，您可能需要研究 SQL Server 可用性组的使用情况，这些可用性组位于 Windows Server 故障转移群集之上并使用数据的同步复制。对于 IIS，您可能需要考虑将应用程序部署到 PaaS 云服务的可能性，因为这比将应用程序部署到 IaaS 云服务具有显着优势。您可以通过使用 VNET 创建集成 PaaS 和 IaaS 云服务的服务拓扑。
可用性集是这两个功能的组合
更新域（您可以在创建新的可用性集时选择最多 20 个）
故障域是物理（如机架、电源）集，可让您在可用性集中选择 2 个故障域，并且该可用性集中的机器将具有值 1 和 2，因此在任何物理上发生电源故障时至少有一个可用放。
更新域已设置，将由 azure system update 立即更新。如果选择 4 个更新域并且您的 2 个 VM 的值为 2,3，这意味着它们不会一起更新以进行任何计划维护
对于高可用性，重复的 VM 不应位于相同的故障域或相同的更新域上
现在您不能在创建 VM 后更改可用性集，它应该在创建时设置