我一直在寻找使用Amazon EC2或Microsoft Azure来托管新项目，并计划使用Amazon EBS或Microsoft Azure Drives来存储用于运行ASP.NET网站的文件。据我所知，这两种技术非常相似，都提供了一个由云存储（Amazon S3或Azure Blobs）支持的虚拟硬盘。使用最近的outage of EC2 and EBS（请参阅Post Mortem），我想了解更多有关EBS如何与Azure驱动器进行比较的信息。具体做法是：
我知道Azure驱动器可以在单个实例上以读/写方式挂载，也可以在多个实例上以只读方式挂载。 EBS也是如此吗？我还听说过Microsoft Azure Drives可以在Read/Write mode on multiple instances using the SMB protocol中使用。有人有这方面的经验吗？
在今天的停电之前，有很多人抱怨t he reliability of Amazon EBS。我甚至听到一些人使用多个EBS卷来创建类似RAID的系统，这对我来说似乎很愚蠢。 Microsoft Azure Drives与EBS相比有多可靠？
我相信EBS和Microsoft Azure驱动器都允许您拍摄快照，这些快照可用于备份或安装到VM实例并在不更改原始卷的情况下进行修改。这是升级在多个实例上运行的网站的合理方法（例如：创建快照，部署更改，然后在所有实例上以只读方式挂载）
这些只是我遇到的一些基本问题，但我很乐意听到任何有过Amazon EBS和Microsoft Azure Drives经验的人。
答案 0 :(得分：6)
通过阅读Windows Azure Drives whitepaper，我能够回答一些问题，详细解释了如何使用Page Blobs创建Azure云端硬盘。这意味着它应该包含在Windows Azure Storage SLA中，其中包含：
Windows Azure具有单独的SLA用于计算和存储。对于计算，我们保证当您在不同的故障和升级域中部署两个或多个角色实例时，面向Internet的角色将至少有99.95％的时间具有外部连接。此外，我们将监控您的所有单个角色实例，并保证99.9％的时间我们将检测角色实例的进程何时未运行并启动纠正措施。
对于存储，我们保证至少99.9％的时间我们将成功处理我们收到的添加，更新，读取和删除数据的正确格式化请求。我们还保证您的存储帐户可以连接到我们的Internet网关。
这为Web /工作人员角色提供了大约26.28 minutes的年度停机时间窗口，为需要访问Azure驱动器的存储或角色提供了52.56 minutes。 Windows Azure的区域与Amazon AWS提供的区域类似，但在区域内，它们没有不同的可用区。相反，他们有Upgrade Domains and Fault Domains，用于推出更新和查找role instances on different hardware racks。故障域不是用户可配置的，因此如果您想要更高级别的可用性，则必须在另一个区域中设置单独的服务。
我无法找到有关如何创建Amazon EBS驱动器的类似说明，但看起来它们是actually NOT backed by Amazon S3，而是一个单独的存储系统。 Amazon S3 SLA提供99.999999999% durability and 99.99% availability，但EBS提到的所有内容都是：
Amazon EBS卷放置在特定的可用区中，然后也可以附加到同一可用区中的实例。
每个存储卷都会在同一可用区内自动复制。这可以防止因任何单个硬件组件故障而导致数据丢失。
Amazon EBS还提供了创建卷的时间点快照的功能，这些快照会持久保存到Amazon S3。这些快照可用作新Amazon EBS卷的起点，并保护数据以实现长期持久性。可以使用相同的快照来实例化任意数量的卷。
他们还指出，与典型的硬盘驱动器相比，EBS的预期年度故障率在0.1％-0.5％之间，而每年的故障率约为4％。由于EBS卷完全基于一个可用区，因此为备份创建快照也很重要：
EBS卷内置冗余，这意味着如果单个驱动器发生故障或发生其他单个故障，它们不会失败。但它们并不像S3存储那样冗余，后者将数据复制到多个可用区：EBS卷完全存在于一个可用区中。这意味着制作存储在S3中的快照备份对于长期数据保护非常重要。
最近EBS/EC2 outage的验尸报告详细介绍了EBS的体系结构，并指出触发器是无效的网络配置更改。这一变化导致许多卷与镜像无关，quickly led to a “re-mirroring storm,” where a large number of volumes were effectively “stuck” while the nodes searched the cluster for the storage space it needed for its new replica.这与一些竞争条件，不正确的退避超时和软件错误相结合，导致多个可用区域的长时间中断。亚马逊表示，他们正在采取一系列措施来防止未来发生这种情况，包括使EBS控制平面更能容忍个别可用区域的故障。
最终，designed to expect and tolerate failures的系统受AWS中断的影响要小得多。使用Azure驱动器或Amazon EBS的任何系统都应该使用提供的快照功能创建定期备份，甚至可以考虑将快照发送到单独的区域或完全独立的存储提供程序。