AWS EBS介绍

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 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按需分配特性对测试结果的影响。

测试内容

  1. 顺序读的MBPS
  2. 顺序写的MBPS
  3. 顺序读的IOPS
  4. 顺序写的IOPS
  5. 随机读的IOPS
  6. 随机写的IOPS
  7. 文件服务器负载的IOPS
  8. 工作站负载的IOPS
  9. 数据库负载的IOPS
测试结果
顺序读的MBPS
块大小 队列深度 IOPS MBPS 平均响应时间(ms)
512B 1 2552.614510 1.246394 0.391199
1KB 1 2524.156227 2.464996 0.395633
2KB 1 2350.644532 4.591103 0.424932
4KB 1 2072.339333 8.095076 0.482010
8KB 1 2039.289339 15.931948 0.489753
16KB 1 1630.023004 25.469109 0.612951
32KB 1 1183.749847 36.992183 0.844174
64KB 1 840.482779 52.530174 1.189014
128KB 1 524.162471 65.520309 1.906990
256KB 1 311.572372 77.893093 3.207976
512KB 1 172.817188 86.408594 5.783251
1MB 1 93.531282 93.531282 10.689385
2MB 1 48.517478 97.034956 20.603371
4MB 1 24.702554 98.810217 40.448923
8MB 1 12.671283 101.370263 78.904828
16MB 1 6.462593 103.401494 154.324245
块大小 队列深度 IOPS MBPS 平均响应时间(ms)
64KB 1 849.835394 53.114712 1.176043
64KB 2 662.967552 41.435472 3.015535
64KB 4 1427.675388 89.229712 2.801068
64KB 8 1483.053670 92.690854 5.393741
64KB 16 1551.874317 96.992145 10.306176
64KB 32 1701.659058 106.353691 18.799876
64KB 64 1641.108362 102.569273 38.980397
64KB 128 1700.012987 106.250812 75.204437
64KB 256 1656.129006 103.508063 154.246022
顺序写的MBPS
块大小 队列深度 IOPS MBPS 平均响应时间(ms)
512B 1 1274.010536 0.622075 0.784215
1KB 1 1405.586809 1.372643 0.710890
2KB 1 329.071429 0.642718 3.038028
4KB 1 305.100347 1.191798 3.276715
8KB 1 213.994582 1.671833 4.671948
16KB 1 225.008289 3.515755 4.442891
32KB 1 177.171213 5.536600 5.642789
64KB 1 155.261980 9.703874 6.439292
128KB 1 88.958616 11.119827 11.238242
256KB 1 55.986377 13.996594 17.857944
512KB 1 34.848074 17.424037 28.692845
1MB 1 24.591388 24.591388 40.640801
2MB 1 15.409959 30.819918 64.867947
4MB 1 8.218889 32.875558 121.635786
8MB 1 4.246041 33.968326 235.503735
16MB 1 1.038540 16.616641 941.911582
块大小 队列深度 IOPS MBPS 平均响应时间(ms)
64KB 1 151.999081 9.499943 6.576373
64KB 2 152.297533 9.518596 13.132747
64KB 4 515.797143 32.237321 7.752766
64KB 8 282.601043 17.662565 28.295228
64KB 16 153.960955 9.622560 103.914596
64KB 32 153.934640 9.620915 207.635532
64KB 64 153.565797 9.597862 415.295611
64KB 128 153.072994 9.567062 827.534323
64KB 256 152.089254 9.505578 1645.074171
顺序读的IOPS
块大小 队列深度 IOPS MBPS 平均响应时间(ms)
512B 1 2623.937138 1.281219 0.380500
512B 2 2924.002741 1.427736 0.683421
512B 4 5281.204203 2.578713 0.756876
512B 8 9442.143799 4.610422 0.846785
512B 16 15710.583835 7.671184 1.017935
512B 32 16533.778754 8.073134 1.934920
512B 64 12102.555239 5.909451 5.285980
512B 128 13126.756871 6.409549 9.737574
512B 256 16076.423785 7.849816 15.920638
顺序写的IOPS
块大小 队列深度 IOPS MBPS 平均响应时间(ms)
512B 1 1629.355523 0.795584 0.613216
512B 2 1724.400716 0.841993 1.159318
512B 4 1350.314974 0.659333 2.961708
512B 8 1645.572631 0.803502 4.860792
512B 16 3131.141970 1.528878 5.109576
512B 32 5487.106291 2.679251 5.831239
512B 64 5436.232458 2.654410 11.769855
512B 128 5232.818035 2.555087 24.452925
512B 256 5116.757847 2.498417 50.006771
随机读的IOPS
块大小 队列深度 IOPS MBPS 平均响应时间(ms)
512B 1 514.083543 0.251017 1.944495
512B 2 525.098368 0.256396 3.808146
512B 4 975.315686 0.476228 4.100013
512B 8 1104.889829 0.539497 7.239507
512B 16 1115.011082 0.544439 14.348814
512B 32 1088.295950 0.531395 29.414582
512B 64 1087.907633 0.531205 58.817419
512B 128 1105.796372 0.539940 115.645245
512B 256 1106.769817 0.540415 230.405567
块大小 队列深度 IOPS MBPS 平均响应时间(ms)
4KB 1 388.525085 1.517676 2.572896
4KB 2 402.284369 1.571423 4.970561
4KB 4 805.948351 3.148236 4.961784
4KB 8 874.052415 3.414267 9.150627
4KB 16 866.534046 3.384899 18.465952
4KB 32 850.703072 3.323059 37.611484
4KB 64 831.472540 3.247940 76.908969
4KB 128 839.688149 3.280032 152.087256
4KB 256 822.089988 3.211289 310.311784
随机写的IOPS
块大小 队列深度 IOPS MBPS 平均响应时间(ms)
512B 1 96.503149 0.047121 10.360601
512B 2 98.621325 0.048155 20.276820
512B 4 100.934031 0.049284 39.607770
512B 8 104.181319 0.050870 76.778951
512B 16 110.957958 0.054179 144.199395
512B 32 107.146756 0.052318 298.740650
512B 64 108.161191 0.052813 588.390351
512B 128 104.039996 0.050801 1213.382441
512B 256 101.893613 0.049753 2419.665037
块大小 队列深度 IOPS MBPS 平均响应时间(ms)
4KB 1 98.432005 0.384500 10.157615
4KB 2 96.816930 0.378191 20.652090
4KB 4 107.852760 0.421300 37.098685
4KB 8 104.088110 0.406594 76.806699
4KB 16 101.127657 0.395030 158.338818
4KB 32 94.930524 0.370822 337.534401
4KB 64 95.691460 0.373795 665.235826
4KB 128 94.706141 0.369946 1330.134074
4KB 256 93.288342 0.364408 2637.288612
文件服务器负载的IOPS
文件服务器负载参数

所占百分比 数据块大小 读比例 随机比例
10% 0.5KB 80% 100%
5% 1KB 80% 100%
5% 2KB 80% 100%
60% 4KB 80% 100%
2% 8KB 80% 100%
4% 16KB 80% 100%
4% 32KB 80% 100%
10% 64KB 80% 100%
块大小 队列深度 IOPS MBPS 平均响应时间(ms)
- 1 158.645113 1.697243 6.302122
- 2 173.501218 1.904440 11.524715
- 4 296.531083 3.152971 13.487062
- 8 326.156931 3.533370 24.521028
- 16 319.605897 3.471420 50.039720
- 32 288.254950 3.124912 110.995466
- 64 301.723392 3.272893 211.613380
- 128 306.735611 3.289809 415.098553
- 256 310.350024 3.337515 815.767888
工作站负载的IOPS
工作站负载参数

所占百分比 数据块大小 读比例 随机比例
100% 8KB 80% 80%
块大小 队列深度 IOPS MBPS 平均响应时间(ms)
- 1 200.456374 1.566065 4.987198
- 2 203.397170 1.589040 9.831918
- 4 274.902475 2.147676 14.549520
- 8 325.505376 2.543011 24.569315
- 16 371.631791 2.903373 43.040322
- 32 378.742493 2.958926 84.493637
- 64 387.630832 3.028366 164.880733
- 128 385.078953 3.008429 331.252311
- 256 383.486685 2.995990 661.003607
数据库负载的IOPS
数据库负载参数

所占百分比 数据块大小 读比例 随机比例
100% 8KB 67% 100%
块大小 队列深度 IOPS MBPS 平均响应时间(ms)
- 1 170.188475 1.329597 5.874187
- 2 170.703080 1.333618 11.713854
- 4 289.670329 2.263049 13.807330
- 8 291.521447 2.277511 27.436836
- 16 260.296964 2.033570 61.472165
- 32 286.074512 2.234957 111.862068
- 64 270.296803 2.111694 236.589546
- 128 276.839849 2.162811 460.416307
- 256 273.369444 2.135699 925.519759

快照测试

创建一个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,然后删除这个卷。
从同一个Availability Zone中恢复快照所花时间
分别从不同的快照上创建新的volome,共创建3个volume,然后把这3个volume挂载到Linux主机上。

volume名 快照名 盘符
vol-2dd44f40 Snap_01 /dev/xvdl
vol-03d44f6e Snap_02 /dev/xvdm
vol-fdd44f90 Snap_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-edfa6180 Snap_01 /dev/xvdl
vol-c5fa61a8 Snap_02 /dev/xvdm
vol-d3fa61be Snap_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主机。

  • 0
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值