V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
mattx
V2EX  ›  Amazon Web Services

aws ec2 架构疑问

  •  
  •   mattx · 2018-10-04 11:14:24 +08:00 · 5036 次点击
    这是一个创建于 2003 天前的主题,其中的信息可能已经有所发展或是发生改变。

    最近看了点 aws ec2 介绍,对 ec2 架构存疑(对比虚拟机实例),主要是计算能力方面的,在存储方面把磁盘用网络连接起来是可以理解.

    1. ec2 实例如果要扩容很多计算能力,比如从 4vcpu 变成 80vcpu 怎么实现,如果扩容的 cpu 超过了底层物理机的最大计算能力,怎么办?ec2 实例是否有可能跨越多个物理机?

    2. ec2 内存方面是否支持扩容,比如从 4g 扩容到 256g 内存

    3. 不同类型的 ec2 实例,在底层是怎么区分的,应该不是运行所在的物理机不同吧?感觉没这么简单

    希望知道的 v 友回答下,可能问题很简单,thx

    第 1 条附言  ·  2018-10-04 21:17:26 +08:00
    感谢大家回答了,之前看到有文章说 ec2 不只是 vps 之类的,估计也是概念的包装吧。实例跨物理机和 cpu 热插拔现在不大现实,现在分布式横向扩展都是增加集群中的机器来做吧。
    26 条回复    2018-11-29 13:00:42 +08:00
    shengyu
        1
    shengyu  
       2018-10-04 11:35:54 +08:00
    猜测一下 如果跨物理机的 性能也太差了吧 跨主机读取内存延迟感人吧 新老机器的 cpu 不同任务分配也有问题吧
    dot2017
        2
    dot2017  
       2018-10-04 11:44:42 +08:00
    1. vCPU 是虚拟化出来的啊,理论上虚拟资源不超过操作系统所支持的核心数都行。但是超物理核心太多会造成虚拟机所在的宿主主机的 cpu wait 时间超级高,cpu 争用太大会直接降低虚拟机的速度,体验极差。一般 8 物理核心 CPU 对应 16vCPU 是实践最多了。ESXi 不支持跨物理机,虽然显示的 CPU 资源池是所有物理机的。KVM 不知道,ec2 应该是用的 KVM 的

    2. 支持,所有虚拟资源都支持动态扩容,唯一区别是内存扩容不需要关机,CPU 不行。硬盘扩容一般是加盘,而不是对原盘扩容,原因是怕数据丢失(当然现在这么做的风险很低了)。

    3. 底层你不用管,hypervisor 有套很成熟资源分配的机制。
    AnyISalIn
        3
    AnyISalIn  
       2018-10-04 12:11:30 +08:00 via iPhone
    openstack vm resize 操作是会迁移到有足够资源的宿主机的,当然也看 nova scheduler 的策略
    lolizeppelin
        4
    lolizeppelin  
       2018-10-04 12:30:59 +08:00
    这种问题看 openstack 源码就懂了

    业务层怎么做最终落地还是执行具体的指令步骤及其虚拟化实现

    cpu 可以直接超售 内存 256G 是因为现在物理机真有 256G
    如何控制超售应该是云服务器厂商赚钱的核心部分之一了


    目前虚拟化实例应该是不支持跨物理机的...把多个机器当一台机来用目前应该没有
    如果这个功能很成熟的话,你想想多少架构都不用做了?全 TM 当单机来写就可以了

    第 3 个问题....你知道 kvm qemu 么?我觉得我白打字了
    webjin1
        5
    webjin1  
       2018-10-04 12:42:53 +08:00 via Android   ❤️ 1
    @lolizeppelin 先把所有机器 Hadoop 呢?
    zwh2698
        6
    zwh2698  
       2018-10-04 13:05:44 +08:00 via Android
    硬件虚拟化正在研究这个问题,你需求还是很前沿,
    zxiso
        7
    zxiso  
       2018-10-04 13:19:36 +08:00 via Android
    虚拟机扩容取决于母鸡资源。如果需求资源超过母鸡提供资源,应该会做迁移操作。
    毕竟以现在的技术来看,基本不可能垮设备
    xenme
        8
    xenme  
       2018-10-04 13:24:14 +08:00 via iPhone
    不要瞎想,现在有 80vcpu 的 ec2 实例卖么?而且卖的是计算能力,比如一核心 1ghz 等等,有 80 核心卖,那么它 host 就一定有超过这个能力的,你分配的话就会帮你迁移到其他物理机上了。
    binux
        9
    binux  
       2018-10-04 13:29:18 +08:00
    别想了,ec2 扩容 CPU 和 内存都是要停机的。
    EBS 硬盘扩容不需要停机,但是它本来就是磁盘虚拟化的啊。
    swulling
        10
    swulling  
       2018-10-04 13:32:42 +08:00 via iPhone
    技术上 EC2 并没有超过 OpenStack,所以你去看 OpenStack 就好了
    abmin521
        11
    abmin521  
       2018-10-04 13:40:25 +08:00 via Android
    @swulling 没有超过??? ebs 不关机扩容 这个好像还是比较少的吧
    AnyISalIn
        12
    AnyISalIn  
       2018-10-04 13:46:50 +08:00
    关于纵向扩容,个人觉得 vmware 做的很好,扩 CPU 内存都不需要重启
    []( https://docs.vmware.com/cn/VMware-vSphere/6.0/com.vmware.vsphere.hostclient.doc/GUID-F102B9BD-1B92-4AC5-ADC0-BE4E90473C5F.html)
    swulling
        13
    swulling  
       2018-10-04 14:12:58 +08:00 via iPhone
    @abmin521 分布式块存储扩容不难,国内阿里的云盘,百度的 CDS 都支持在线扩容,架构上没啥难点。

    OpenStack 中的 Ceph 也可以在线扩容
    fredcc
        14
    fredcc  
       2018-10-04 15:05:02 +08:00 via Android
    ec2 更改 cpu 和内存相当于更换实例类型,当然要重启,宿主机大概率不是同一台。只要 az 还有该实例可用资源你就能用,不用担心宿主机这种具体问题。不同实例类型的 cpu 架构都不一样,肯定不是一种宿主机搞定的
    abmin521
        15
    abmin521  
       2018-10-04 15:23:24 +08:00
    @swulling 我指的是根盘 对 Ceph 不了解 可能有点孤陋寡闻
    swulling
        16
    swulling  
       2018-10-04 15:25:51 +08:00 via iPhone
    @abmin521 我说的也没有排除系统盘
    msg7086
        17
    msg7086  
       2018-10-04 20:46:24 +08:00   ❤️ 1
    EC2 就是虚拟机。现在 EC2 部分放在 XEN 上跑,部分是 KVM。
    CPU 不能超过物理机 CPU 上限。比如现在插满的 8180 可以支持单机 448 个 vCPU。
    内存也可以扩容的,同样一般也不会超过物理机内存上限。比如 8180M 插满可以支持单机 12TB 内存。
    不同的 EC2 实例可以运行在同一台服务器上,只要限制 CPU 时间片就可以了。

    这里说的一般是离线扩容,EC2 就是这种模式。在线扩容也可以,但是涉及到 CPU 与内存的热插拔,支持起来难度很高,操作系统也不一定兼容,所以还是离线为主。

    EC2 其实就是个磁盘存储在外部的虚拟机。
    mattx
        18
    mattx  
    OP
       2018-10-04 21:19:46 +08:00 via iPhone
    @msg7086 #17 vcpu 单核来说,性能和我们物理机比怎么样,时间片是否能保证。
    msg7086
        19
    msg7086  
       2018-10-04 23:17:57 +08:00
    @mattx 可以查阅 AWS 关于“ EC2 计算单位”的部分。
    通常来说,单个 vCPU 要比普通的 i3 或者 i7 的单个核心慢。
    opengps
        20
    opengps  
       2018-10-05 07:46:55 +08:00 via Android
    80 核,256 内存完全可以没超过单台物理机资源
    以 4 路服务器 ibm3850 为例(只说我装过的,不说最大支持配置):
    CPU ~可以轻松 4 颗 e7 等于 64 个 vcpu,然后 CPU 是可以根据负载超售的,总资源不满就不会有直接体会单慢
    内存~ 8 块内寸板卡,每块板卡上能装 8 块 16g 内存,轻松过 T 级别内存
    lolizeppelin
        21
    lolizeppelin  
       2018-10-05 08:36:21 +08:00 via Android
    openstack 和 ec2 都可以看成是巨型运维管理工具
    你可以简单理解为与虚拟化技术是否先进无关

    cpu 内存能否在线扩容取决于调用的 qemu 是否支持
    以及虚拟机所运行的操作系统是否支持

    这些底层的支持了 上层才有必要开发相关运维管理代码


    cpu 可以超过逻辑 cpu 个数 配置里可以配置比例的 你配置 16 倍都可以


    内存也可以超售 我记得已经有技术可以让一个宿主机里的虚拟机里实际没分配的内存在 qemu 进程里不分配
    实际超过往 swap 里写


    云服务器商的超售控制得好 用户才不会卡 应该是云商关键技术数据 这没法从 openstack 里学到
    likuku
        22
    likuku  
       2018-10-05 13:43:33 +08:00
    以传统纵向升级单个物理机器,直到支持 CPU/内存 /主板统统可热插拔的强力小型机 思路

    来用 主要倡导无状态,分布式,横向 扩展的 云端资源,

    这有点不合适...
    mattx
        23
    mattx  
    OP
       2018-10-06 21:30:42 +08:00 via iPhone
    @likuku #22 是的,估计说 ec2 不只是虚拟机说的是这个思路吧。
    realpg
        24
    realpg  
       2018-10-07 14:26:45 +08:00
    @mattx #23
    EC2 跟普通的虚拟机其实差别不大
    CPU 内存资源(以下简称计算资源)都是基于物理机的池内资源 因为存储都是 IPSAN 网络的 可以挂载到任意的虚拟机 只需要考虑虚拟机跟存储网络连接的带宽是否充足( 10G/25G 以太网居多 考虑物理机开的虚拟机数量 配置 以及存储使用历史曲线) 迁移相对方便 对于调整 CPU 和内存 都是要彻底关虚拟机的 在本物理机计算资源、预期存储带宽资源充足的情况下可能是本机调整配置,在资源不足或者预期不足 或者资源足 但是按照傻瓜升级后 剩余资源无法充分销售的情况下 就会在别的物理机新开资源 将存储挂载过去

    然后结合历史大数据,进行适当超售 整个这个物理资源的自动化调度逻辑 其实是一个云服务商的核心技术
    mattx
        25
    mattx  
    OP
       2018-10-07 14:38:04 +08:00
    @realpg thx
    abmin521
        26
    abmin521  
       2018-11-29 13:00:42 +08:00
    @swulling #16 阿里云的系统盘不支持不关机扩容 还要做快照 https://help.aliyun.com/document_detail/44986.html
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3327 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 10:45 · PVG 18:45 · LAX 03:45 · JFK 06:45
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.