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

Question

我一直在考虑使用 Amazon EC2 或 Microsoft Azure 来托管新项目，并计划使用 Amazon EBS或Microsoft Azure Drives存储用于运行 ASP.NET 网站的文件。据我所知，这两种技术非常相似，并且都提供由云存储支持的虚拟硬盘驱动器( Amazon S3 或 Azure Blobs )。随着最近outage of EC2 and EBS (请参阅 Post Mortem )我想详细了解 EBS 与 Azure 驱动器的比较。具体来说:

1. 我知道 Azure 驱动器可以在单个实例上以读/写方式安装，也可以在多个实例上以只读方式安装。 EBS也是如此吗？我还听说 Microsoft Azure Drives 可以在 Read/Write mode on multiple instances using the SMB protocol 中使用。有人有这方面的经验吗？

2. 有很多人提示 he reliability of Amazon EBS甚至在今天的停电之前。我什至听说有些人提到使用多个 EBS 卷来创建类似 RAID 的系统，这对我来说似乎很愚蠢。与 EBS 相比，Microsoft Azure Drive 的可靠性如何？

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

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

Answer 1

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

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.

这使得每年的停机时间窗口约为 26.28 minutes对于网络/ worker 角色和 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 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.

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

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 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.这与一些竞争条件、不正确的回退超时和软件错误相结合，导致了影响多个可用区的长时间中断。亚马逊表示，他们正在采取一系列措施来防止 future 发生这种情况，包括提高 EBS 控制平面对各个可用区故障的容忍度。

最后，系统是 designed to expect and tolerate failures AWS 中断的影响要小得多。任何使用 Azure Drives 或 Amazon EBS 的系统至少应使用提供的快照功能创建定期备份，甚至可能需要考虑将快照发送到单独的区域或完全单独的存储提供商。