AWS 的EBS(Elastic Block store)给Amazon的EC2实例提供了高可用高可靠的块级存储卷。EBS适合于一些需要访问块设备的应用，比如数据库、文件系统等。

• 提供1GB到1TB的容量。
• 存储卷像裸块设备一样，有块设备接口，可以在卷上创建文件系统。
• 每个EBS volume是存放在一个Availability Zone中，只有同一个Availability Zone中的EC2 instance才能访问。
• 每个volume在同一个Availability Zone中有多个副本，这可以保证当单个硬件失效时，数据不会丢失。
• EBS可以创建当前时间点的快照，快照是保存在S3中。这些快照可用于创建新的EBS volume(volume上的数据和快照的数据相同)。快照可以长时间保存数据。同一个快照可以实例化多个volume。
• volume可以从公共数据集中实例化(比如保存有基因数据的快照)。
• Amazon CloudWatch可以监控EBS volume，监控的指标有带宽、吞吐量、延迟、队列深度。并提供API接口。

• 每个volume只能挂载在一个EC2 instance上。每个EC2 instance可以挂载多个volume，这样可用于数据条带化(做软件RAID0)，以此提高I/O性能和吞吐率。这对于像数据库这种典型应用(频繁随机读写操作)很有帮助。
• EBS volume可以用作EC2 instance的启动分区，这样就能保存启动分区上的数据，并制作你的AMI。

• EBS volume支持创建快照，并把快照存放S3上。
• EBS volume上的第一个快照是全备份快照，以后的快照是增量备份的。只意味着只有被改变的数据才会被保存。
• 虽然快照是增量快照，但是删除一个快照时，只有对其他快照没用的数据才被删除。不管哪个快照被删除，所有活动的快照都包含了restore the volume所需的信息。而且，不管从哪个快照恢复(使用快照创建volume，也就是实例化volume)，所花的时间都是一样的。
• 快照能用于实例化多个新的volume，这些新的volume的容量可以大于快照的原volume的容量，而且这些新的volume可以在其他 Availability Zone。当创建一个新的volume时，可以选择保存在S3上的不同快照来创建。在这种情况下，新的volume实际上是快照的副本，但是可以是不同容 量(只能大于原volume)、不同Availability Zone。这种功能可以用于对旧的volume进行扩容，或者在不同的Availability Zone上复制volume。
• 从S3上的快照创建的新volume的载入方式是”load lazily”。当一个volume从一个快照上创建时，并不需要等待把S3上所有的数据都传送到EBS volume上。只有当你的EC2 instance开始访问这个volume时(访问某一数据块时)，这个volume才开始从S3传输数据，并在后台持续加载这个volume的所有数 据。
• EBS的快照可以支持共享。这样可以共享你的数据给你的同事，而且还可以把快照共享给所有AWS用户。
• 共享快照的操作可以通过AWS管理控制台或者API来执行。

• EBS volume适合于几乎所有方式的存储。你可以挂载多个volume在一个EC2 instance上，并条带化数据(做软件RAID，或者用LVM)。这种方式可以提高I/O性能，特别是大量随机访问。
• 实际的性能依赖于具体的应用。因为EBS的volume需要网络访问，在大型EC2实例上，速度更快、吞吐率更高。

• EBS volume的耐久性(durability)跟volume的大小和最近快照之后所修改数据的大小有关。假如一个20GB的volume，最近快照之后 只修改了很少的数据，它的AFR(年故障率 annual failure rate)是0.1%~0.5%。而一个普通硬盘的AFR是4%。
• 在同一个Availability Zone对volume做镜像并不能提高它的耐久性。但是可以对volume创建快照(快照保存在S3上，S3上的副本是保存在多个Availability Zone上)，因此频繁创建快照可以提高数据的耐久性。
• 当你的EBS volueme失效时，该volume的所有快照都是完整的，你可以基于这些快照创建新的volume。

根据下面相关资料，可以推断出EBS的大致架构。

• Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region
• A pictorial representation of AWS EBS Architecture
• Amazon’s Elastic Block Store explained
• Understanding and using Amazon EBS – Elastic Block Store

• 每个EBS cluster管理一群EBS nodes，这些node之间是对等的。
• 每个EBS node保存有EBS volume数据的副本，并响应EC2 instance的读写请求。
• EBS volume data被复制到多个EBS node上，保证durability和availability。
• EBS node采用快速的故障转移策略(fast failover strategy)，并主动选择新的副本(当一个副本不能同步或者不可用时)。
• EBS node和EBS node、EC2 instance、EBS control plane services通过高带宽网络(Hign Bandwidth Network)进行通信。一个冗余的低带宽网络(Replication Network)用于EBS node间通信(可以用于副本的复制)。
• 假如A EBS node和保存有数据副本的B node失去连接，则该A认为B已经失效。为了保证数据的耐久性(durability)，A必须找到一个新的node，然后复制副本(称为re- mirroring)。在re-mirroring过程中，A在EBS cluster中搜寻另外一个有足够空间的node，然和跟这个node建立连接，然后复制数据到这个node上。
• EBS control plane接收用户的requests，并转发到相应的EBS cluster。每个EC2 Region上有一套EBS control plane。EBS control plane分布在多个Availability Zones上，具有高可用性、高容错性。EBS control plane还要帮EBS cluster 上的volume data选择primary replicas(为了保证一致性，每个volume在某个时刻只有一个primary replica)。control plane上还有其他服务。
• 当数据被re-mirroring的时候，所有保存这个数据副本的nodes会一直持有数据副本，直到它们确定其他节点已经接管了它们的工作(保存副 本)，这样可以提供数据保护。但在volume中的数据在re-mirroring时，访问这些数据是会被阻塞的，直到系统确定一个新的 primary(or writable) 副本(replica)。这个限制可以保证在所有潜在的失效模型中，EBS volume中的数据是一致的。但是从EC2实例的角度去观察，当在一个volume上执行I/O时发生re-mirroring操作，这个volume 就表现为阻塞。

• 每个volume被分成多个blocks。当创建volume的第一个快照时，所有的blocks都会被保存到S3上，快照的指针表也被保存到S3上。当 创建这个volume的第二个快照时，只有被修改过的blocks才被保存到S3上，相应的指针表也被保存到S3上。第三个快照创建过程相同。
• 增量快照(依赖快照)的优点是节约时间和空间。创建增量快照是非常块的，因为它只保存被修改过的blocks到S3上。创建快照的时候要注意一致性，当需要创建快照时，需要先冻结数据库、文件系统，然后创建快照，最后解冻。快照的性能跟S3的性能相同。
• 通过快照，可以从其他Availability Zone获得一个volume的数据(因为快照是保存在S3上，S3是跨多个Availability Zones)。你可以在一个volume上创建快照，然后在另外一个Zone上创建一个新volume(并选择快照)。

测试结果文档是AWS EBS测试记录。测试结果和测试工具、测试环境、AWS运行状况(多少个用户在使用EBS服务)等因素有关，因此此次测试结果并不代表EBS的平均性能。

可以对比的测试结果有 磁盘阵列测试文档 和 盛大云硬盘测试文档。

• 测试环境：在AWS上建立一个t1.micro的机器(615M内存)，安装windows2008。
• 测试对象：在AWS上创建一个10GB大小的EBS volume(和EC2 instance在同一个Availability Zone)。
• 测试设置：把volume挂载到EC2 instance上，并格式化。
• 测试工具：IOmeter
• 测试参数：1个worker。IOmeter测试前会在volume上创建并充填一个8GB大小的文件，这样减少了EBS按需分配特性对测试结果的影响。

测试内容

1. 顺序读的MBPS
2. 顺序写的MBPS
3. 顺序读的IOPS
4. 顺序写的IOPS
5. 随机读的IOPS
6. 随机写的IOPS
7. 文件服务器负载的IOPS
8. 工作站负载的IOPS
9. 数据库负载的IOPS

文件服务器负载参数

工作站负载参数

数据库负载参数

创建一个EC2 instance，安装Red Hat 6.1。

1. 创建一个2GB大小的EBS volume，然后挂载在Linux主机上。格式化这个volume，然后在上面创建填充一个1GB大小的文件。
2. 给EBS volume创建第一个快照Snap_01，快照的状态从pending变成completed花了十几分钟。
3. 写256MB的数据到文件上，然后创建第二个快照Snap_02，快照的状态从pending变成completed花了两分钟。
4. 写256MB的数据到文件上，然后创建第三个快照Snap_02，，快照的状态从pending变成completed花了两分钟。
5. 写1GB的数据到这个文件上，卸载这个volume，然后删除这个卷。

分别从不同的快照上创建新的volome，共创建3个volume，然后把这3个volume挂载到Linux主机上。

• 首先算出/dev/xvdl盘上文件的md5值(使用md5sum工具，md5sum会读取文件，然后计算md5值)，用了20秒(因为从把/dev /xvdl挂载到/mnt/xvdl目录开始，S3就开始把数据复制到EBS volume上，因此恢复快照时间为20+秒)。
• 然后算出/dev/xvdm盘上文件的md5值，用了4秒(md5sum计算文件的md5值花了4秒)。
• 最后算出/dev/xvdn盘上文件的md5值，用了4秒。

删除这3个volume，然后删除Linux主机。

在不同的Availability Zone中创建Linux主机，然后分别从不同的快照上创建新的volome，共创建3个volume，最后把这3个volume挂载到Linux主机上。

• 首先算出/dev/xvdl盘上文件的md5值(使用md5sum工具，md5sum会读取文件，然后计算md5值)，用了66秒(因为从把/dev /xvdl挂载到/mnt/xvdl目录开始，S3就开始把数据复制到EBS volume上，因此恢复快照时间为66+秒)。
• 然后算出/dev/xvdm盘上文件的md5值，用了3秒。
• 最后算出/dev/xvdn盘上文件的md5值，用了3秒。

删除这3个volume，然后删除Linux主机。