Amazon Elastic Block Storage (EBS) 和 Microsoft Azure 驱动器之间的差异

发布于 2024-11-02 18:51:54 字数 1497 浏览 5 评论 0原文

我一直在考虑使用 Amazon EC2 或 Microsoft Azure 来托管新项目，并计划使用 Amazon EBS 或 Microsoft Azure Drives 来存储用于运行的文件一个 ASP.NET 网站。据我所知，这两种技术非常相似，都提供由云存储支持的虚拟硬盘驱动器 (Amazon S3< /a> 或 Azure Blob）。最近 EC2 和EBS（请参阅事后分析）我想了解有关 EBS 如何进行的更多信息与 Azure 驱动器相比。具体来说：

我知道 Azure 驱动器可以在单个实例上以读/写方式安装，也可以在多个实例上以只读方式安装。 EBS也是如此吗？我还听说 Microsoft Azure Drives 可以在使用 SMB 协议在多个实例上读取/写入模式。有人有这方面的经验吗？
甚至在之前就有很多人抱怨 Amazon EBS 的可靠性可靠性到今天的停电。我什至听说有些人提到使用多个 EBS 卷来创建类似 RAID 的系统，这对我来说似乎很愚蠢。与 EBS 相比，Microsoft Azure Drive 的可靠性如何？
我相信EBS和Microsoft Azure驱动器都允许您拍摄快照，快照可以用于备份或安装到VM实例并在不更改原始卷的情况下进行修改。这是升级在多个实例上运行的网站的合理方法吗（例如：创建快照、部署更改，然后在所有实例上以只读方式安装）

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

后知后觉 2024-11-09 18:51:54

通过阅读 Windows Azure 驱动器白皮书，我能够回答我的一些问题，其中解释了详细介绍如何使用页面 Blob 创建 Azure 驱动器。这意味着它应该包含在 Windows Azure 存储 SLA 中，其中规定：

Windows Azure 对于计算和存储有单独的 SLA。对于计算，我们保证当您在不同的故障和升级域中部署两个或多个角色实例时，面向 Internet 的角色将至少在 99.95% 的时间内具有外部连接。此外，我们将监控您的所有单独角色实例，并保证在 99.9% 的情况下我们将检测到角色实例的进程何时未运行并启动纠正措施。
对于存储，我们保证至少 99.9% 的时间我们将成功处理收到的添加、更新、读取和删除数据的格式正确的请求。我们还保证您的存储帐户将连接到我们的互联网网关。

这使得每年的停机时间窗口约为 26.28 分钟对于 Web/worker 角色，52.56 分钟用于存储或需要访问 Azure 驱动器的角色。 Windows Azure 具有与 Amazon AWS 提供的区域类似的区域，但在区域内它们没有不同的可用区。相反，他们有升级域和故障域，用于推出更新和定位不同硬件机架上的角色实例。故障域不可由用户配置，因此如果您想要更高级别的可用性，则必须在另一个区域设置单独的服务。

我无法找到有关如何创建 Amazon EBS 驱动器的类似描述，但它们似乎实际上不受 Amazon S3 支持，而是独立的存储系统。 Amazon S3 SLA 提供99.999999999% 的持久性和 99.99% 的可用性，但针对 EBS 提到的只是：

Amazon EBS 卷放置在特定可用区中，然后可以附加到同一可用区中的实例。
每个存储卷都会在同一可用区内自动复制。这可以防止由于任何单个硬件组件的故障而导致的数据丢失。
Amazon EBS 还提供了创建卷的时间点快照的功能，并将其保存到 Amazon S3。这些快照可用作新 Amazon EBS 卷的起点，并保护数据以实现长期持久性。相同的快照可用于实例化任意数量的卷。

他们还指出，EBS 的预期年故障率在 0.1% 至 0.5% 之间，而典型硬盘驱动器的年故障率约为 4%。由于 EBS 卷完全基于一个可用区，因此为备份创建快照也很重要：

EBS 卷具有内置冗余，这意味着如果单个驱动器发生故障或发生其他单一故障，它们也不会发生故障。但它们不像 S3 存储那样冗余，S3 存储会将数据复制到多个可用区：一个 EBS 卷完全位于一个可用区中。这意味着制作存储在 S3 中的快照备份对于长期数据保护非常重要。

最近EBS/EC2 中断的事后分析报告提供了有关以下架构的更多详细信息： EBS 并指示触发器是无效的网络配置更改。这一变化导致许多卷与其镜像解除关联，并很快引发了“重新镜像风暴”，即当节点在集群中搜索其存储空间时，大量卷实际上被“卡住”。这与一些竞争条件、不正确的回退超时和软件错误相结合，导致了影响多个可用区的长时间中断。亚马逊表示，他们正在采取一系列措施来防止未来发生这种情况，包括提高 EBS 控制平面对各个可用区故障的容忍度。

最后，系统的设计旨在期望和容忍故障受 AWS 中断的影响要小得多。至少，任何使用 Azure Drives 或 Amazon EBS 的系统都应该使用提供的快照功能创建定期备份，甚至可能需要考虑将快照发送到单独的区域或完全单独的存储提供商。

I was able to answer some of my questions by reading through the Windows Azure Drives whitepaper, which explains in detail how the Azure Drive is created using Page Blobs. This means that it should be covered under the Windows Azure Storage SLA that states:

Windows Azure has separate SLA’s for compute and storage. For compute, we guarantee that when you deploy two or more role instances in different fault and upgrade domains your Internet facing roles will have external connectivity at least 99.95% of the time. Additionally, we will monitor all of your individual role instances and guarantee that 99.9% of the time we will detect when a role instance’s process is not running and initiate corrective action.
For storage, we guarantee that at least 99.9% of the time we will successfully process correctly formatted requests that we receive to add, update, read and delete data. We also guarantee that your storage accounts will have connectivity to our Internet gateway.

This gives a yearly downtime window of around 26.28 minutes for web/worker roles and 52.56 minutes for storage or roles that require access to Azure Drives. Windows Azure has regions similar to what Amazon AWS offers, but within regions they do not have distinct Availability Zones. Instead they have Upgrade Domains and Fault Domains, which are used for rolling out updates and locating role instances on different hardware racks. Fault domains are not user configurable, so if you want a higher level of availability you have to setup separate services in another region.

I was not able to find a similar description of how Amazon EBS drives are created, but it appears that they are actually NOT backed by Amazon S3, but instead are a separate storage system. The Amazon S3 SLA provides 99.999999999% durability and 99.99% availability, but all that is mentioned for EBS is:

Amazon EBS volumes are placed in a specific Availability Zone, and can then be attached to instances also in that same Availability Zone.
Each storage volume is automatically replicated within the same Availability Zone. This prevents data loss due to failure of any single hardware component.
Amazon EBS also provides the ability to create point-in-time snapshots of volumes, which are persisted to Amazon S3. These snapshots can be used as the starting point for new Amazon EBS volumes, and protect data for long-term durability. The same snapshot can be used to instantiate as many volumes as you wish.

They also indicate that EBS has an expected annual failure rate of between 0.1% – 0.5% compared with typical hard drives which fail at around 4% a year. Since EBS volumes are based entirely in one Availability Zone it is also important to create snapshots for backups:

EBS volumes have redundancy built-in, which means that they will not fail if an individual drive fails or some other single failure occurs. But they are not as redundant as S3 storage which replicates data into multiple availability zones: an EBS volume lives entirely in one availability zone. This means that making snapshot backups, which are stored in S3, is important for long-term data safeguarding.

The post mortem report for the recent EBS/EC2 outage has a lot more detail about the architecture of EBS and indicates that the trigger was an invalid network configuration change. That change caused a number of volumes to become disassociated with their mirrors and 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. This combined with a few race conditions, improper back-off timeouts, and software bugs caused the prolonged outage that affected multiple availability zones. Amazon has stated that they are taking a number of actions to prevent this from occurring in the future, including making the EBS control plane more tolerant to failures in individual availability zones.

In the end, systems that were designed to expect and tolerate failures were much less effected by the AWS outage. At a minimal any system using Azure Drives or Amazon EBS should create regular backups using the provided snapshot feature and may even want to consider shipping the snapshot to a separate region or completely separate storage provider.

回复收藏 0 原文

~没有更多了~