关于EC2实例类型的选择
2015-03-12 14:01
399 查看
当前AWS大部分region都提供20种不同配置的实例可供选择
这些实例大概分5个类型:
免费实例 t1.micro
这种类型的实例为共享单核心,计算能力最高峰值可达2个ECU (ECU为AWS的计算单元,普通类型实例1个ECU大概相当于一个1.2GHz的CPU核心的计算能力);免费实例还包含613MB内存,和最大30GB的EBS磁盘,想使用AWS提供的免费一年t1.micro实例的同学,创建实例时,记得把EBS大小从默认的8GB修改成30GB,然后登陆进系统执行resize2fs /dev/xvde(取决于你具体的盘符),这样就可以将文件系统扩展到占满次磁盘的30GB,这样可以充分利用免费实例的存储。其实一个t1.micro实例足以跑一个个人网站。例如本博客所在的网站就跑着3个nginx虚拟主机和一个MySQL,负载也不高。
General purpose通用型
通用型实例适用于大多数需求不是很苛刻和特别的业务,他包含m1系列和m3系列,其实通用性实例也可看成内存加强型实例,M就表示内存,m3是第三代m型实例,他是m1系列的升级,底层CPU型号有升级,m1系列从m1.small, m1.medium, m1.large, m1.xlarge配置每升级一个档次,CPU和内存就都增长一倍,单价也是每升高一个档次就涨一倍的单价,m3系列没有m3.small,直接从m3.medium起步,最高可到m3.2xlarge。我们拿出m3.large和m1.large出来做个比较:
从表中对比我们发现,除了CPU的计算能力升级之外,自带的实例存储升级成了SSD,每小时单价还下降了0.5美分
Memory optimized内存优化型
内存优化型主要是给需要有高内存需求的业务,这个类型包含m2系列的3个档次配置,m2.xlarge起步,最高m2.4xlarge,内存从17GB到68GB
m2系列前两个配置m2.xlarge,m2.2xlarge的网络性能都是Moderate,升级到顶配m2.4xlarge之后,网络性能达到high。那么这么low, moderate, high是个大概什么级别的呢?虽然AWS没有带宽限制,但是由于多虚拟机共享host机的网络性能和IO性能,单个虚拟机的网络性能也不是特别好度量,不过大概是这样: low级别的大概是20MBps,moderate级别的是40MBps,high级别的能达到80MBps~100MBps
Storage optimized存储优化型
存储优化型的配置是针对需求连内存优化型都无法满足的业务,这个类型包含hs1.8xlarge这一个配置,这种配置包含16个虚拟核心,35个计算单元,117GB内存,网络性能明确标注是10Gbps,这种类型实例比较适合将数据库跑在内存中的业务。
Compute optimized计算优化型,也就是CPU加强型
这种类型CPU/内存比例比较大,适合计算密集型业务,他包含c1和c3系列,为什么木有c2系列,我也不知~
这种类型的shili实例除了较旧的两个c1系列的档次(c1.medium和c1.xlarge)是采用普通磁盘做实例存储的外,其他的档次(也就是c3系列的)全部都包含SSD做实例存储,其中最高档次的c3.8xlarge(32核心108个计算单元)的网络性能为明确标注10Gbps,C3系列被认为最具性价比的类型。
有一点需要注意的,c3.xlarge和m3.xlarge的性能比较,c3除了CPU是跟m3.xlarge差不多是同一个级别外,其他性能参数都是跟m3.large看齐的。这也容易造成困扰“同样是xlarge级别的实例,为什么c3的网卡性能比m3的差辣么多?”
其实这c3.xlarge其他性能参数和价格都是想m3.large看齐的,选择的时候要注意网络性能和IO性能
这些实例大概分5个类型:
免费实例 t1.micro
这种类型的实例为共享单核心,计算能力最高峰值可达2个ECU (ECU为AWS的计算单元,普通类型实例1个ECU大概相当于一个1.2GHz的CPU核心的计算能力);免费实例还包含613MB内存,和最大30GB的EBS磁盘,想使用AWS提供的免费一年t1.micro实例的同学,创建实例时,记得把EBS大小从默认的8GB修改成30GB,然后登陆进系统执行resize2fs /dev/xvde(取决于你具体的盘符),这样就可以将文件系统扩展到占满次磁盘的30GB,这样可以充分利用免费实例的存储。其实一个t1.micro实例足以跑一个个人网站。例如本博客所在的网站就跑着3个nginx虚拟主机和一个MySQL,负载也不高。
General purpose通用型
通用型实例适用于大多数需求不是很苛刻和特别的业务,他包含m1系列和m3系列,其实通用性实例也可看成内存加强型实例,M就表示内存,m3是第三代m型实例,他是m1系列的升级,底层CPU型号有升级,m1系列从m1.small, m1.medium, m1.large, m1.xlarge配置每升级一个档次,CPU和内存就都增长一倍,单价也是每升高一个档次就涨一倍的单价,m3系列没有m3.small,直接从m3.medium起步,最高可到m3.2xlarge。我们拿出m3.large和m1.large出来做个比较:
vCPU | ECU | 内存 | 实例存储 | IO性能 | 网络性能 | 小时单价 | |
m1.large | 2 | 4 | 7.5GB | 2x420 | Moderate | Moderate | $0.32 |
m3.large | 2 | 6.5 | 7.5GB | 2x32(SSD) | Moderate | Moderate | $0.315 |
Memory optimized内存优化型
内存优化型主要是给需要有高内存需求的业务,这个类型包含m2系列的3个档次配置,m2.xlarge起步,最高m2.4xlarge,内存从17GB到68GB
m2系列前两个配置m2.xlarge,m2.2xlarge的网络性能都是Moderate,升级到顶配m2.4xlarge之后,网络性能达到high。那么这么low, moderate, high是个大概什么级别的呢?虽然AWS没有带宽限制,但是由于多虚拟机共享host机的网络性能和IO性能,单个虚拟机的网络性能也不是特别好度量,不过大概是这样: low级别的大概是20MBps,moderate级别的是40MBps,high级别的能达到80MBps~100MBps
Storage optimized存储优化型
存储优化型的配置是针对需求连内存优化型都无法满足的业务,这个类型包含hs1.8xlarge这一个配置,这种配置包含16个虚拟核心,35个计算单元,117GB内存,网络性能明确标注是10Gbps,这种类型实例比较适合将数据库跑在内存中的业务。
Compute optimized计算优化型,也就是CPU加强型
这种类型CPU/内存比例比较大,适合计算密集型业务,他包含c1和c3系列,为什么木有c2系列,我也不知~
这种类型的shili实例除了较旧的两个c1系列的档次(c1.medium和c1.xlarge)是采用普通磁盘做实例存储的外,其他的档次(也就是c3系列的)全部都包含SSD做实例存储,其中最高档次的c3.8xlarge(32核心108个计算单元)的网络性能为明确标注10Gbps,C3系列被认为最具性价比的类型。
有一点需要注意的,c3.xlarge和m3.xlarge的性能比较,c3除了CPU是跟m3.xlarge差不多是同一个级别外,其他性能参数都是跟m3.large看齐的。这也容易造成困扰“同样是xlarge级别的实例,为什么c3的网卡性能比m3的差辣么多?”
vCPU | ECU | 内存 | 实例存储 | IO性能 | 网络性能 | 小时单价 | |
m3.xlarge | 4 | 13 | 15G | 2x40(SSD) | high | high | $0.63 |
c3.xlarge | 4 | 14 | 7.5G | 2x40(SSD) | moderate | moderate | $0.378 |
相关文章推荐
- AWS上的MongoDB:如果为你的MongoDB服务器选择正确的EC2实例类型?
- 关于Bos 开发中使用字段类型是选择已有基础资料的的源代码
- android中写一个内部类来选择文件夹中指定的图片类型实例说明
- 关于控件自动布局时,控件类型选择的处理
- 关于ES字符串类型(Text vs keyword)的选择
- T2: 一种能累积计算积分的EC2实例类型
- 关于反射中创建类型实例的两种方法
- Azure上的MongoDB:如何选择正确的实例类型?
- 扩展:关于ES字符串类型(Text vs keyword)的选择
- 关于mysql 的时间类型选择
- c/c++_Lua交互----关于Lua中table类型的使用实例
- T2: 一种能累积计算积分的EC2实例类型
- android 关于选择图片,判断图片的类型
- JDBC实例2 关于分包下不同表实体类的外键类型转换
- 关于jQuery参考实例2.0 用jQuery选择元素
- 关于科学选择地图投影类型的探讨
- QCombox使用代理(选择线条类型实例)
- mysql数据库关于时间类型的选择
- 关于jQuery参考实例2.0 用jQuery选择元素
- 关于值类型、引用类型和字符串类型的比较问题!通过实例来说明!