AWS EBS介绍
来源：互联网 发布：我的世界mac中文输入 编辑：程序博客网 时间：2024/05/21 19:28
http://freedomhui.com/2012/06/aws-ebs%E4%BB%8B%E7%BB%8D/?lang=zh-hans
AWS Elastic Block Store
目录
- AWS Elastic Block Store
- EBS介绍
- EBS特点
- 使用EBS
- EBS的快照
- EBS的性能
- EBS的持久性
- 架构
- 整体架构
- 快照架构
- 测试
- 性能测试
- 快照测试
EBS介绍
AWS 的EBS(Elastic Block store)给Amazon的EC2实例提供了高可用高可靠的块级存储卷。EBS适合于一些需要访问块设备的应用，比如数据库、文件系统等。
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接口。
使用EBS
- 每个volume只能挂载在一个EC2 instance上。每个EC2 instance可以挂载多个volume，这样可用于数据条带化(做软件RAID0)，以此提高I/O性能和吞吐率。这对于像数据库这种典型应用(频繁随机读写操作)很有帮助。
- EBS volume可以用作EC2 instance的启动分区，这样就能保存启动分区上的数据，并制作你的AMI。
EBS的快照
- 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的性能
- EBS volume适合于几乎所有方式的存储。你可以挂载多个volume在一个EC2 instance上，并条带化数据(做软件RAID，或者用LVM)。这种方式可以提高I/O性能，特别是大量随机访问。
- 实际的性能依赖于具体的应用。因为EBS的volume需要网络访问，在大型EC2实例上，速度更快、吞吐率更高。
EBS的持久性
- 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(并选择快照)。
测试
测试时间是2011年12月。测试结果文档是AWS EBS测试记录。测试结果和测试工具、测试环境、AWS运行状况(多少个用户在使用EBS服务)等因素有关，因此此次测试结果并不代表EBS的平均性能。 可以对比的测试结果有 磁盘阵列测试文档 和 盛大云硬盘测试文档(2011年11月测试的，现在盛大云硬盘已经升级了，估计性能有所提升)。
性能测试
- 测试环境：在AWS上建立一个t1.micro的机器(615M内存)，安装windows2008。
- 测试对象：在AWS上创建一个10GB大小的EBS volume(和EC2 instance在同一个Availability Zone)。
- 测试设置：把volume挂载到EC2 instance上，并格式化。
- 测试工具：IOmeter
- 测试参数：1个worker。IOmeter测试前会在volume上创建并充填一个8GB大小的文件，这样减少了EBS按需分配特性对测试结果的影响。
测试内容
- 顺序读的MBPS
- 顺序写的MBPS
- 顺序读的IOPS
- 顺序写的IOPS
- 随机读的IOPS
- 随机写的IOPS
- 文件服务器负载的IOPS
- 工作站负载的IOPS
- 数据库负载的IOPS
测试结果
顺序读的MBPS
顺序写的MBPS
顺序读的IOPS
顺序写的IOPS
随机读的IOPS
随机写的IOPS
文件服务器负载的IOPS
文件服务器负载参数所占百分比 数据块大小 读比例 随机比例 10%0.5KB80%100%5%1KB80%100%5%2KB80%100%60%4KB80%100%2%8KB80%100%4%16KB80%100%4%32KB80%100%10%64KB80%100%块大小 队列深度 IOPS MBPS 平均响应时间(ms) -1158.6451131.6972436.302122-2173.5012181.90444011.524715-4296.5310833.15297113.487062-8326.1569313.53337024.521028-16319.6058973.47142050.039720-32288.2549503.124912110.995466-64301.7233923.272893211.613380-128306.7356113.289809415.098553-256310.3500243.337515815.767888
工作站负载的IOPS
工作站负载参数所占百分比 数据块大小 读比例 随机比例 100%8KB80%80%块大小 队列深度 IOPS MBPS 平均响应时间(ms) -1200.4563741.5660654.987198-2203.3971701.5890409.831918-4274.9024752.14767614.549520-8325.5053762.54301124.569315-16371.6317912.90337343.040322-32378.7424932.95892684.493637-64387.6308323.028366164.880733-128385.0789533.008429331.252311-256383.4866852.995990661.003607
数据库负载的IOPS
数据库负载参数所占百分比 数据块大小 读比例 随机比例 100%8KB67%100%块大小 队列深度 IOPS MBPS 平均响应时间(ms) -1170.1884751.3295975.874187-2170.7030801.33361811.713854-4289.6703292.26304913.807330-8291.5214472.27751127.436836-16260.2969642.03357061.472165-32286.0745122.234957111.862068-64270.2968032.111694236.589546-128276.8398492.162811460.416307-256273.3694442.135699925.519759
快照测试
创建一个EC2 instance，安装Red Hat 6.1。
创建快照的所花时间
- 创建一个2GB大小的EBS volume，然后挂载在Linux主机上。格式化这个volume，然后在上面创建填充一个1GB大小的文件。
- 给EBS volume创建第一个快照Snap_01，快照的状态从pending变成completed花了十几分钟。
- 写256MB的数据到文件上，然后创建第二个快照Snap_02，快照的状态从pending变成completed花了两分钟。
- 写256MB的数据到文件上，然后创建第三个快照Snap_02，，快照的状态从pending变成completed花了两分钟。
- 写1GB的数据到这个文件上，卸载这个volume，然后删除这个卷。
从同一个Availability Zone中恢复快照所花时间
分别从不同的快照上创建新的volome，共创建3个volume，然后把这3个volume挂载到Linux主机上。volume名 快照名 盘符 vol-2dd44f40Snap_01/dev/xvdlvol-03d44f6eSnap_02/dev/xvdmvol-fdd44f90Snap_03/dev/xvdn
- 首先算出/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中恢复快照所花时间
在不同的Availability Zone中创建Linux主机，然后分别从不同的快照上创建新的volome，共创建3个volume，最后把这3个volume挂载到Linux主机上。volume名 快照名 盘符 vol-edfa6180Snap_01/dev/xvdlvol-c5fa61a8Snap_02/dev/xvdmvol-d3fa61beSnap_03/dev/xvdn
- 首先算出/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主机。
- AWS EBS介绍
- amazon aws EBS
- AWS linux挂载新的EBS
- 记录AWS使用产生的EBS费用
- AWS - Auto Scaling 介绍
- aws-cli简单介绍
- 亚马逊AWS之S3与EBS的区别
- AWS credential and creating EBS Snapshot(学习笔记)
- 有關AWS EC2 (EBS 收費)的問題
- AWS官方培训课程介绍
- AWS平台的基本介绍
- AWS Boto3 使用介绍(一)
- DevOps亚马逊AWS相关介绍
- AWS首席执行官Andy Jassy介绍AWS容器生态系统
- ORACLE EBS-组织架构介绍
- ORACLE EBS-组织架构介绍
- aws
- AWS
- Git详解之一 Git起步
- 将阿拉伯数组转换成为罗马数字
- CMainFrame::OnSwitchView()
- lwip源码分析4——ip层
- 估计准备
- AWS EBS介绍
- 在VS2005中生成时出错：error C4430: missing type specifier - int assumed. Note: C++ does not support default
- BJam
- 在Linux里设置环境变量的方法（export PATH）
- ORACLE的一些错误与配置收集【ora-00988,ora 12541 tns,exp ……】
- 删除容器(vector、list)中的iterator
- dojo dom-form模块
- windows7、ubuntu双系统安装
- ios学习--iphone开发私房菜_5_] iphone中如何实现下拉菜单 .
