Amazon Elastic Block Storage (EBS) 和 Microsoft Azure Drives 之间的差异

Posted 2023-03-04

【中文标题】Amazon Elastic Block Storage (EBS) 和 Microsoft Azure Drives 之间的差异

【英文标题】：Differences between Amazon Elastic Block Storage (EBS) and Microsoft Azure Drives

【发布时间】：2011-08-11 03:18:52

【问题描述】：

我一直在考虑使用 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 也一样吗？我还听说可以在Read/Write mode on multiple instances using the SMB protocol 中使用Microsoft Azure Drives。有人有这方面的经验吗？

甚至在今天的中断之前，就有很多人抱怨 the reliability of Amazon EBS。我什至听说有人提到使用多个 EBS 卷来创建类似 RAID 的系统，这对我来说似乎很愚蠢。与 EBS 相比，Microsoft Azure 驱动器的可靠性如何？

我相信 EBS 和 Microsoft Azure 驱动器都允许您拍摄快照，这些快照可用于备份或挂载到 VM 实例并在不更改原始卷的情况下进行修改。这是升级在多个实例上运行的网站的合理方法吗（例如：创建快照，部署更改，然后在所有实例上以只读方式挂载）

这些只是我遇到的一些基本问题，但我很想听听任何对 Amazon EBS 和 Microsoft Azure Drives 有经验的人的意见。

【参考方案1】：

通过阅读Windows Azure Drives whitepaper，我能够回答我的一些问题，其中详细解释了如何使用Page Blobs 创建 Azure 驱动器。这意味着它应该包含在Windows Azure Storage SLA 之下，该声明指出：

Windows Azure 对计算和存储有单独的 SLA。对于计算，我们保证当您在不同的故障和升级域中部署两个或多个角色实例时，您面向 Internet 的角色将至少在 99.95% 的时间具有外部连接。此外，我们将监控您的所有个人角色实例，并保证 99.9% 的时间我们会检测到角色实例的进程何时未运行并采取纠正措施。

对于存储，我们保证至少 99.9% 的时间我们将成功处理我们收到的格式正确的添加、更新、读取和删除数据的请求。我们还保证您的存储帐户将连接到我们的 Internet 网关。

这为需要访问 Azure 驱动器的存储或角色提供了大约 26.28 minutes 的年度停机时间窗口（用于 Web/工作角色）和 52.56 minutes 用于需要访问 Azure 驱动器的存储或角色。 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 卷的起点，并保护数据以实现长期持久性。同一个快照可用于实例化任意数量的卷。

他们还指出，与典型的硬盘驱动器每年大约 4% 的故障率相比，EBS 的预期年故障率在 0.1% 到 0.5% 之间。由于 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 Drives 或 Amazon EBS 的系统都应该使用提供的快照功能创建定期备份，甚至可能需要考虑将快照传送到单独的区域或完全独立的存储提供商。

【讨论】：

我还发现了这个有趣的 Azure Blob 存储基准站点：azurescope.cloudapp.net/BenchmarkTestCases

Netflix 的另一篇博文讨论了他们为什么避免 EBS：techblog.netflix.com/2011/04/…

以及该博客中概述 EBS 与 EC2 临时磁盘性能的评论：victortrac.com/EC2_Ephemeral_Disks_vs_EBS_Volumes