亚马逊的弹性块存储（EBS）和微软Azure驱动器之间的差异 [英] Differences between Amazon Elastic Block Storage (EBS) and Microsoft Azure Drives

问题描述

我一直在考虑使用任何的Amazon EC2或微软Azure托管一个新的项目，以及使用任何的亚马逊EBS 或微软的Azure驱动<​​/A>来存储文件用于运行一个ASP.NET网站。据我所知，这两种技术非常相似，都提供由云存储备份（ Amazon S3的虚拟硬盘驱动器或 Azure的斑点）。随着EC2最近停运EBS （见验尸）我想知道更多关于如何EBS相比之下，Azure的驱动器。具体做法是：

I've been looking at using either Amazon EC2 or Microsoft Azure to host a new project, and plan on using either Amazon EBS or Microsoft Azure Drives to store the files used to run an ASP.NET website. To my knowledge these two technologies are very similar and both provide a virtual hard drive that is backed by cloud storage (Amazon S3 or Azure Blobs). With the recent outage of EC2 and EBS (See Post Mortem) I'd like to know more about how EBS compares to Azure drives. Specifically:

1. 我知道Azure的驱动器可以安装作为单个实例读/写或多个实例上的只读。是一样如此EBS？我还听说，微软Azure的驱动器可以在<一个使用href="http://blogs.msdn.com/b/windowsazurestorage/archive/2011/04/16/using-smb-to-share-a-windows-azure-drive-among-multiple-role-instances.aspx"相对=nofollow>读/写在使用SMB协议的多个实例模式。任何人有这方面的经验？

1. I know Azure Drives can be mounted as read/write on a single instance or as read-only on multiple instances. Is the same true for EBS? I have also heard that Microsoft Azure Drives can be used in Read/Write mode on multiple instances using the SMB protocol. Anyone have experience with this?

已经有很多人抱怨亚马逊EBS叔他的可靠性之前就今天的停电。我甚至听到有些人参考使用多个EBS卷，以创建像系统，这似乎傻了我一个RAID。如何可靠的已在微软Azure驱动器比作EBS？

There have been lots of people complaining about the reliability of Amazon EBS even prior to today's outage. I have even heard some people reference using multiple EBS volumes to create a RAID like system, which seems silly to me. How reliable have the Microsoft Azure Drives been compared to EBS?

我相信无论EBS和微软Azure驱动器，使您可以拍摄快照，可用于备份或安装到虚拟机实例和修改不改变原有的体积。这是一个合理的方式来提升一个网站的多个实例上运行（例如：创建快照，部署更改，然后挂载为只读的所有实例）

I believe that both EBS and Microsoft Azure drives allow you to take snapshots, which can be used for backups or be mounted to a VM instance and modified without changing the original volume. Is this a reasonable way to upgrade a website running on multiple instances (Ex: create snapshot, deploy changes, then mount as read-only on all instances)

这些只是一些基本的问题我有，但我很想从任何人有与亚马逊EBS和微软Azure的经验驱动听到。

Those are just some basic questions I had, but I would love to hear from anyone that has experience with Amazon EBS and Microsoft Azure Drives.

推荐答案

我能够通过的 Windows Azure的驱动器白皮书，里面详细介绍了如何在Azure驱动器使用页斑点。这意味着，它应该在视窗Azure存储的SLA覆盖的，指出：

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中拥有独立的SLA的计算和存储。对于计算，我们保证当你部署在不同的故障两个或多个角色实例和升级域您的面向Internet的角色将有外部连接的时间至少为99.95％。此外，我们将监控所有单个角色实例，并保证99.9％的时间，我们会发现，当一个角色实例的进程不运行，并采取纠正措施。

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.

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

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.

这给出了各地26.28分钟为网络每年的停机时间窗口/辅助角色和52.56分钟存储或需要访问Azure中的角色驱动器。 Windows Azure的具有区域类似于亚马逊AWS提供的，但区域内，他们没有明显的可用性区域。相反，他们有<一个href="http://dotnetslackers.com/articles/aspnet/How-Windows-Azure-Works.aspx#s19-it-s-not-my-fault">Upgrade域和故障域，它们用于推出的更新和查找的在不同的硬件机架角色实例的。故障域不是用户可配置的，所以如果你想比较高的可用性水平，你必须设置独立的服务在另一个区域。

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.

我没能找到如何亚马逊EBS 驱动器创建了一个类似的说明，但现在看来，他们是< A HREF =htt​​p://blog.rightscale.com/2008/08/20/amazon-ebs-explained/>实际上并不是由Amazon S3 的支持，而是有一个单独的存储系统。亚马逊S3 SLA提供 99.999999999％的耐久性和99.99％的可用性，但提到了EBS都是：

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:

亚马逊EBS卷被放置在一个特定的状况区，并且可随后连接到实例，可以在相同的状况区

Amazon EBS volumes are placed in a specific Availability Zone, and can then be attached to instances also in that same Availability Zone.

每个存储卷将自动在同一可用性区域内复制。这prevents数据丢失所导致的任何单个硬件组件故障。

Each storage volume is automatically replicated within the same Availability Zone. This prevents data loss due to failure of any single hardware component.

亚马逊EBS还提供了创建卷，这是坚持到Amazon S3点即时快照的能力。这些快照可以用作起点新亚马逊EBS卷，保护用于长期耐久性的数据。同样的快照可以作为你希望实例尽可能多的卷。

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.

他们还表明，EBS有0.1％的预期年化故障率 - 0.5％，有大约4％的年一些公司的失败典型的硬盘驱动器相比。由于EBS卷在一个可用性区域完全基于同样重要的是创建快照进行备份：

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卷具有冗余内置的，这意味着如果单个驱动器​​出现故障或发生其他单点故障，他们就不会失败。但是，他们没有多余的，因为S3存储其中的数据复制到多个可用区：EBS卷完全生活在一个可用区。这意味着，使快照备份，它们存储在S3中，是用于长期数据保护重要

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.

验尸报告最近 EBS / EC2停运有很多更详细的关于EBS和体系结构表示触发器是无效的网络配置变化。这一变化引起了若干卷，成为解除关联与他们的镜子和迅速引发了一场重镜像风暴，那里有大量的卷是有效地卡住，而节点搜索集群为存储空间，它需要为它的新副本。这再加上一些竞争条件，不当回退超时，和软件​​缺陷造成的长时间停电，影响多个可用区。亚马逊公司表示，他们正在采取一些行动，以prevent这种情况发生在未来，包括使EBS控制面更耐个人可用区域故障。

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.

在最后，那名系统旨在期望和容忍失败人多地少的AWS停电影响。在最小的使用Azure的驱动器或Amazon EBS应使用所提供的快照功能创建定期备份，甚至可以考虑将快照运送到一个单独的区域或完全独立的存储供应商的任何系统。

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.

这篇关于亚马逊的弹性块存储（EBS）和微软Azure驱动器之间的差异的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！