干翻 nio ,王炸 io_uring 来了 ,史上最详细说明及最全图解!!

Image
大趋势:全链路异步化,性能提升10倍+ 随着业务的发展,微服务应用的流量越来越大,使用到的资源也越来越多。 在微服务架构下,大量的应用都是 SpringCloud 分布式架构,这种架构总体上是 全链路同步模式 。 全链路同步模式 不仅造成了资源的极大浪费,并且在流量发生激增波动的时候,受制于系统资源而无法快速的扩容。 全球后疫情时代,降本增效是大背景。如何降本增效?一条好的路径: 全链路同步模式  ,升级为  全链路异步模式 。 全链路异步模式 改造 具体的内容,请参考尼恩的深度文章: 全链路异步,让你的 SpringCloud 性能优化10倍+ 先回顾一下全链路同步模式架构图 全链路同步模式  ,如何升级为  全链路异步模式 , 就是一个一个 环节的异步化。 40岁老架构师尼恩,持续深化自己的3高架构知识宇宙,当然首先要去完成一次牛逼的 全链路异步模式 微服务实操,下面是尼恩的实操过程、效果、压测数据(性能足足提升10倍多)。 全链路异步模式 改造 具体的内容,请参考尼恩的深度文章: 全链路异步,让你的 SpringCloud 性能优化10倍+ 并且,上面的文章,作为尼恩 全链路异步的架构知识,收录在《 尼恩Java面试宝典 》V52版的架构专题中 注:本文以 PDF 持续更新,最新尼恩 架构笔记、面试题 的PDF文件,请从这里获取: 语雀 或者 码云 全链路异步化的最终目标 全链路异步化的最终目标,如下图所示: 应用层:编程模型的异步化 框架层:IO线程的异步化 OS层:IO模型的异步化 一:应用层:编程模型的异步化 这个请大家去看 尼恩的 《 响应式 圣经 PDF 》电子书 随着 云原生时代的到来, 底层的 组件编程 越来越 响应式、流化, 从命令式 编程转换到 响应式 编程,在非常多的场景 ,是大势所趋。 而响应式编程, 学习曲线很大, 大家需要多看,多实操。 二:框架层:IO线程的异步化 这个大家 都选择 具有异步 回调功能的 异步线程模型,如 Reactor 线程模型 这个是面试的绝对重点 IO的王者组件,Netty框架,整体就是一个 Reactor 线程模型 实现 也是非常核心的知识,这里不做展开,请大家去看尼恩的畅销书《Java 高并发核心编程卷 1 加强版》。 三:OS层:IO模型的异步化 目前的一个最大难题,是IO模型的异步化。 注意,Netty

Openstack VM live migration


这篇文章是基于KVM作为虚拟机管理程序的假设,而Openstack在RHEL6.4之上的Grizzly上运行。

Openstack VM 实时迁移可以有 3 个类别:

  • 阻止没有共享存储的实时迁移

  • 基于共享存储的实时迁移

  • 卷支持的 VM 实时迁移

阻止实时迁移

块实时迁移不需要 nova 计算节点之间的共享存储,它使用 network(TCP) 将 VM 磁盘从源主机复制到目标主机,因此完成的时间比基于共享存储的实时迁移要长。此外,在迁移过程中,从网络和 CPU 的角度来看,主机性能将会降低。

要启用块实时迁移,我们需要更改每个 nova 计算主机上的 libvirtd 和 nova.conf 配置:

->编辑/etc/libvirt/libvirtd.conf

listen_tls = 0  
 listen_tcp = 1  
 auth_tcp = “none”

->编辑/etc/sysconfig/libvirtd

LIBVIRTD_ARGS=”–listen”

->重新启动libvirtd

service libvirtd restart

->编辑 ,添加以下行:/etc/nova/nova.conf

live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE

添加此行是要求 nova-compute 利用 libvirt 的真正实时迁移函数。默认情况下,由 nova-compute 完成的迁移不使用 libvirt 的实时迁移功能,这意味着来宾在迁移之前被挂起,因此可能会经历几分钟的停机时间。

->重新启动 nova-compute service

service openstack-nova-compute restart

->检查正在运行的虚拟机

nova list  
 +————————————–+——————-+——–+———————+  
 | ID | Name | Status | Networks |  
 +————————————–+——————-+——–+———————+  
 | 5374577e-7417-4add-b23f-06de3b42c410 | vm-live-migration | ACTIVE | ncep-net=10.20.20.3 |  
 +————————————–+——————-+——–+———————+

->检查 VM 在哪个主机上运行

nova show vm-live-migration  
 +————————————-+———————————————————-+  
 | Property | Value |  
 +————————————-+———————————————————-+  
 | status | ACTIVE |  
 | updated | 2013-08-06T08:47:13Z |  
 | OS-EXT-STS:task_state | None |  
 | OS-EXT-SRV-ATTR:host | **compute-1** |

->检查所有可用的主机

nova host-list  
 +————–+————-+———-+  
 | host_name | service | zone |  
 +————–+————-+———-+  
 | **compute-1** | compute | nova |  
 | **compute-2** | compute | nova |

->让我们将 vm 迁移到托管计算-2

nova live-migration  –block-migrate vm-live-migration compute-2

->当我们再次检查 vm 状态时,我们云上看到主机更改为 compute-2

nova show vm-live-migration  
 +————————————-+———————————————————-+  
 | Property | Value |  
 +————————————-+———————————————————-+  
 | status | ACTIVE |  
 | updated | 2013-08-06T09:45:33Z |  
 | OS-EXT-STS:task_state | None |  
 | OS-EXT-SRV-ATTR:host | **compute-2** |

->We can just do a migration without specifying destination host, nova-scheduler will choose a free host for you

nova live-migration  –block-migrate vm-live-migration

Block live migration seems a good solution if we don’t have/want shared storage , but we still want to do some host level maintenance work without bring downtime to running VMs.

Shared storage based live migration

This example we use GlusterFS as shared storage for nova-compute nodes. Since VM disk is stored on shared storage, hence live migration much much more faster than block live migration.

1.Setup GlusterFS cluster for nova-compute nodes

->Prepare 4 nodes, each node has an extra disk other than OS disk, dedicated for GlusterFS cluster

Node 1: 10.68.124.18 /dev/sdb 1TB
Node 2: 10.68.124.19 /dev/sdb 1TB
Node 3: 10.68.124.20 /dev/sdb 1TB
Node 4: 10.68.124.21 /dev/sdb 1TB

->Configure Node 1-4

 yum install -y xfsprogs.x86_64  
 mkfs.xfs -f -i size=512 /dev/sdb  
 mkdir /brick1  
 echo “/dev/sdb /brick1 xfs defaults 1 2” >> /etc/fstab 1014 cat /etc/fstab  
 mount -a && mount  
 mkdir /brick1/sdb  
 yum install glusterfs-fuse glusterfs-server  
 /etc/init.d/glusterd start  
 chkconfig glusterd on

->On Node-1, add peers

gluster peer probe 10.68.125.19  
gluster peer probe 10.68.125.20  
gluster peer probe 10.68.125.21

->On node-1, create a volume for nova-compute

gluster volume create nova-gluster-vol replica 2 10.68.125.18:/brick1/sdb \
10.68.125.19:/brick1/sdb 10.68.125.20:/brick1/sdb 10.68.125.21:/brick1/sdb  
gluster volume start nova-gluster-vol

->We can check the volume information

gluster volume info  
 Volume Name: nova-gluster-vol  
 Type: Distributed-Replicate  
 Status: Started  
 Number of Bricks: 2 x 2 = 4  
 Transport-type: tcp  
 Bricks:  
 Brick1: 10.68.125.18:/brick1/sdb  
 Brick2: 10.68.125.19:/brick1/sdb  
 Brick3: 10.68.125.20:/brick1/sdb  
 Brick4: 10.68.125.21:/brick1/sdb

->On each nova-compute node, mount the GluserFS volume to /var/lib/nova/instances

yum install glusterfs-fuse  
mount.glusterfs 10.68.125.18:/nova-gluster-vol /var/lib/nova/instances  
echo “10.68.125.18:/nova-gluster-vol /var/lib/nova/instances glusterfs defaults 1 2” >> /etc/fstab  
chown -R nova:nova  /var/lib/nova/instances

2.Configure libvirt and nova.conf on every nova-compute node

->Edit /etc/libvirt/libvirtd.conf

listen_tls = 0  
 listen_tcp = 1  
 auth_tcp = “none”

->Edit /etc/sysconfig/libvirtd

LIBVIRTD_ARGS=”–listen”

->Restart libvirtd

service libvirtd restart

->Edit , add following line:/etc/nova/nova.conf

live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE

3.Let’s try live migration

->Check running VMs

nova list  
 +————————————–+——————-+——–+———————+  
 | ID | Name | Status | Networks |  
 +————————————–+——————-+——–+———————+  
 | 5374577e-7417-4add-b23f-06de3b42c410 | vm-live-migration | ACTIVE | ncep-net=10.20.20.3 |  
 +————————————–+——————-+——–+———————+

->Check which host the VM in running on

nova show vm-live-migration  
 +————————————-+———————————————————-+  
 | Property | Value |  
 +————————————-+———————————————————-+  
 | status | ACTIVE |  
 | updated | 2013-08-06T08:47:13Z |  
 | OS-EXT-STS:task_state | None |  
 | OS-EXT-SRV-ATTR:host | **compute-1** |

->Check all available hosts

nova host-list  
 +————–+————-+———-+  
 | host_name | service | zone |  
 +————–+————-+———-+  
 | **compute-1** | compute | nova |  
 | **compute-2** | compute | nova |

->Let’s migrate the vm to host compute-2

nova live-migration  vm-live-migration compute-2

->Migration should be finished in seconds, let’s check vm status again, we cloud see the host changes to compute-2

nova show vm-live-migration  
 +————————————-+———————————————————-+  
 | Property | Value |  
 +————————————-+———————————————————-+  
 | status | ACTIVE |  
 | updated | 2013-08-06T09:45:33Z |  
 | OS-EXT-STS:task_state | None |  
 | OS-EXT-SRV-ATTR:host | **compute-2** |

->We can just do a migration without specifying destination host, nova-scheduler will choose a free host for us

nova live-migration vm-live-migration

3.Volume backed VM live migration

VMs booted from volume can be also easily and quickly migrated just like shared storage based live migration since both cases VM disks are on top of shared storages.

->Create a bootable volume from an existing image

cinder create  –image-id <id of registered image in glance>  –display-name bootable-vol-rhel6.3 5

->Launch a VM from the bootable volume

nova boot –image <id of any image in glance, not used but needed>  –flavor m1.medium –block_device_mapping vda=<id of bootable vol created above>:::0 vm-boot-from-vol

->Check which host the VM is running on

nova show vm-boot-from-vol  
 +————————————-+———————————————————-+  
 | Property | Value |  
 +————————————-+———————————————————-+  
 | status | ACTIVE |  
 | updated | 2013-08-06T10:29:09Z |  
 | OS-EXT-STS:task_state | None |  
 | OS-EXT-SRV-ATTR:host | **compute-1** |

->Do live migration

nova live-migration vm-boot-from-vol

->Check VM status again

nova show vm-boot-from-vol  
 +————————————-+———————————————————-+  
 | Property | Value |  
 +————————————-+———————————————————-+  
 | status | ACTIVE |  
 | updated | 2013-08-06T10:30:55Z |  
 | OS-EXT-STS:task_state | None |  
 | OS-EXT-SRV-ATTR:host | **compute-2** |

VM recovery from failed compute node

If shared storage used, or for VMs booted from volume, we can recovery them if their compute host is failed.

->Launch 1 normal VM and 1 volume backed VM, make they are all running on compute1 node. ( Use live migration if  they are not on compute-1)

nova show vm-live-migration  
 +————————————-+———————————————————-+  
 | Property | Value |  
 +————————————-+———————————————————-+  
 | status | ACTIVE |  
 | updated | 2013-08-06T10:36:35Z |  
 | OS-EXT-STS:task_state | None |  
 | OS-EXT-SRV-ATTR:host | **compute-1** |

nova show vm-boot-from-vol  
 +————————————-+———————————————————-+  
 | Property | Value |  
 +————————————-+———————————————————-+  
 | status | ACTIVE |  
 | updated | 2013-08-06T10:31:21Z |  
 | OS-EXT-STS:task_state | None |  
 | OS-EXT-SRV-ATTR:host | **compute-1** |

->Shutdown compute-1 node

shutdown now

->Check VM status

nova list  
 +————————————–+——————-+———+———————+  
 | ID | Name | Status | Networks |  
 +————————————–+——————-+———+———————+  
 | 75ddb4f6-9831-4d90-b291-48e098e8f72f | vm-boot-from-vol | SHUTOFF | ncep-net=10.20.20.5 |  
 | 5374577e-7417-4add-b23f-06de3b42c410 | vm-live-migration | SHUTOFF | ncep-net=10.20.20.3 |  
 +————————————–+——————-+———+———————+

Both VMs get into “SHUTOFF” status.

->Recovery them to compute-2 node

nova evacuate vm-boot-from-vol compute-2 –on-shared-storage  
nova evacuate vm-live-migration compute-2 –on-shared-storage

->Check VM status

nova show vm-boot-from-vol  
 +————————————-+———————————————————-+  
 | Property | Value |  
 +————————————-+———————————————————-+  
 | status | SHUTOFF |  
 | updated | 2013-08-06T10:42:32Z |  
 | OS-EXT-STS:task_state | None |  
 | OS-EXT-SRV-ATTR:host | **compute-2** |

nova show vm-live-migration  
 +————————————-+———————————————————-+  
 | Property | Value |  
 +————————————-+———————————————————-+  
 | status | SHUTOFF |  
 | updated | 2013-08-06T10:42:51Z |  
 | OS-EXT-STS:task_state | None |  
 | OS-EXT-SRV-ATTR:host | **compute-2** |

两个 VM 现在都由 compute-2 管理

->重新启动 2 个虚拟机

nova reboot vm-boot-from-vol  
nova reboot vm-live-migration

-> 检查虚拟机列表

nova list  
 +————————————–+——————-+——–+———————+  
 | ID | Name | Status | Networks |  
 +————————————–+——————-+——–+———————+  
 | 75ddb4f6-9831-4d90-b291-48e098e8f72f | vm-boot-from-vol | ACTIVE | ncep-net=10.20.20.5 |  
 | 5374577e-7417-4add-b23f-06de3b42c410 | vm-live-migration | ACTIVE | ncep-net=10.20.20.3 |  
 +————————————–+——————-+——–+———————+

两个 VM 都已恢复为活动状态。

笔记

目前,Openstack没有机制来检测主机和虚拟机故障并自动恢复/迁移虚拟机到健康主机,这种对第三方的回复意味着这样做

还有一个名为openstack-neat的有趣项目,旨在提供OpenStack的扩展,使用实时迁移实现虚拟机(VM)的动态整合。动态虚拟机整合的主要目标是,根据实时资源需求,使用实时迁移重新分配虚拟机,并将空闲主机切换到休眠模式,从而提高物理资源的利用率并降低能耗。这真的像vSphere DRS功能。

项目网站:http://openstack-neat.org

Comments

Popular posts from this blog

V2rayN 电脑客户端如何在 win7/win10/win11上 实现全局代理

便宜好用又稳定的VPN-桔子云,性价比极高!

IOS小火箭/Shadowsocks无需AppleID即可在线安装!