首页 文章 精选 留言 我的

精选列表

搜索[分代式],共10000篇文章
优秀的个人博客,低调大师

制作 OpenStack Windows 镜像 - 每天5分钟玩转 OpenStack(152)

这是 OpenStack 实施经验分享系列的第 2 篇。 OpenStack 通过 Glance 镜像部署 instance,上一节我们介绍了 linux 镜像制作方法,windows 镜像与 linux 有很大不同,今天我们以 windows2008 为例详细讨论。 镜像制作步骤如下:1.创建并运行 windows2008KVM 虚拟机2.安装 virtio 驱动3.安装 cloudbase-init4. 其他定制工作5.创建 Glance 镜像6.通过镜像部署新 instance 1. 创建并运行Windows2008KVM虚拟机 如果有 virt-manager,这一步可以在图形界面中完成。考虑到不是所有情况都有 virt-manager,我们这里直接在 KVM 宿主机上操作。下面的步骤用于创建 windows2008 虚拟机。 首先创建一块20G 的虚拟磁盘作为虚拟机的启动盘: qemu-img create -f qcow2 /var/lib/libvirt/images/win2008r2sp1.qcow2 20G copy 虚拟机模板 cp template.xml win2008r2sp1.xml template.xml 这个模板怎么来?其实很简单,通常直接 dump 现有 kvm 虚拟机的 xml 定义就可以了。比如: virsh dumpxml [vm-id] > template.xml 修改win2008r2sp1.xml中以下各项: 虚拟机名称 虚拟磁盘(前面通过 qemu-img 创建的)和启动ISO 创建虚拟机 virsh define win2008r2sp1.xml 启动虚拟机 virsh start win2008r2sp1 通过vnc连接虚拟机 这里 172.17.12.11 为宿主机 IP,端口号为 2(可通过 virsh vncdisplay 查询到)。连接成功后,显示虚拟机安装界面 通过向导安装操作系统,过程不再赘述。如果在安装过程中虚拟机没有自动重启,可以通过下面的命令启动虚拟机 virsh start win2008r2sp1 安装成功后,设置IP 地址 2. 安装 virtio 驱动 OpenStack 默认使用 virtio 磁盘和网卡,virtio 的性能很好。由于 windows 没有自带 virtio 的驱动,需要手动安装,步骤如下: 添加一个virtio 类型的磁盘。 virsh edit win2008r2sp1 修改当前的网卡设备为virtio。 重启操作系统,安装virtio 的驱动程序。 virtio driver 的下载地址为https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso 3. 安装 cloudbase-init cloudbase-init 使 windows 镜像部署的 instance 能够自动配置 IP 地址等个性化信息。其作用与 linux 的 cloud-init 一样,下面演示cloudbase-init 的配置方法。 下载cloudbase-init https://cloudbase.it/cloudbase-init/#download 在虚拟机中安装cloudbase-init 可通过远程桌面上传cloudbase-init 安装程序并安装 系统会自动关机。 4. 其他定制工作 重新启动虚拟机,完成其他定制工作,比如根据需要安装一些常用软件等。至此,windows 镜像文件已经准备好,文件路径为 /var/lib/libvirt/images/win2008r2sp1.qcow2 5. 创建 Glance 镜像 镜像创建方法与上一节 linux 镜像一样 glance image-create --name "Windows 2008 R2 SP1" --file /var/lib/libvirt/images/win2008r2sp1.qcow2 --disk-format qcow2 --container-format bare --is-public true --progress 6. 通过镜像部署新 instance 点击镜像后面的“启动云主机”按钮。 给 instance 命名,并点击“运行”,instance 创建成功并分配到 IP。 点击 instance 名字。 打开 console。 在 VNC 控制台可以看到 instance 正常启动。 点击Administrator 用户 第一次登录需要修改密码。 以上就是定制 OpenStack Windows 镜像的操作,下一节讨论几个镜像使用上的经验和技巧。

优秀的个人博客,低调大师

制作 OpenStack Linux 镜像 - 每天5分钟玩转 OpenStack(151)

这是 OpenStack 实施经验分享系列的第 1 篇。 OpenStack 的 instance 是通过 Glance 镜像部署的,所以准备镜像是必须要做的工作。本节介绍 Linux 镜像的制作方法,后面还会讨论 Windows 镜像。 下载clould 镜像 最简单的方法是使用标准镜像。主流的Linux发行版都提供可以在 OpenStack 中直接使用的cloud镜像,下载地址: CentOS6:http://cloud.centos.org/centos/6/images/ CentOS7:http://cloud.centos.org/centos/7/images/ Ubuntu14.04:http://cloud-images.ubuntu.com/trusty/current/ Ubuntu16.04:http://cloud-images.ubuntu.com/xenial/current/ 下面以Ubuntu16.04为例演示如何将标准镜像导入 Glance。 创建Glance镜像 登录 OpenStack,打开 “项目->Compute->镜像”菜单。 点击“创建镜像”按钮。 在创建页面填写镜像相关信息,其中包括: 镜像名称为“Ubuntu 16.04” “镜像源”选择“镜像文件” 点击“选择文件”定位Ubuntu 16.04的Cloud image文件xenial-server-cloudimg-amd64-disk1.img “镜像格式”选择“QCOW2” 最小磁盘填写“20”,这相当于设置instance启动盘的最小容量 勾选“共有”选择框,这样所有Project都可以使用该镜像 点击“创建镜像”按钮,开始上传镜像。完成后,新的镜像将出现在镜像列表上。 定制镜像 cloud 镜像是标准镜像,没有图像界面,是美国时区,而且只能通过密钥登录。可以根据需要对该镜像进行定制,其方法是: 通过cloud 镜像部署出一个实例。 定制该实例。 创建该实例的快照,该快照将保存在Glance中。 以后通过该快照部署新的实例。 下面我们以CentOS标准镜像为例演示定制镜像的每个步骤,定制内容包括:添加图形界面,设置中国时区,设置ssh密码登录等。 1. 通过cloud镜像部署出一个实例 进入 “项目->Compute->镜像”菜单,点击镜像“CentOS6”后面的“启动云主机”按钮。 命名为“centos6-vm”。 因为cloud镜像默认是通过密钥对访问,点击“访问&安全”标签,选择事先创建好的密钥对“template”。 点击“运行”, centos6-vm部署成功。 在“项目->Compute->访问&安全”菜单中管理密钥对。“template”就是在这里创建的。也支持已有的密钥对。 在创建密钥时下载并保管好私钥文件template.pem,下面通过此文件登录centos6-vm。 ssh -i <key-path>/template.pemcentos@172.17.24.97 然后切换到root用户: sudo su – 2. 定制该实例 设置中国时区 cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime 设置yum 源 因为要安装图形等相关包,yum源需提前准备好(当然也可以用官网的源)。然后编辑 /etc/yum.repos.d/CentOS-Base.repo 如果是CentOS7,内容如下: 安装开发工具和图形界面 CentOS6安装如下包: yum groupinstall "Desktop" yum groupinstall "X Window System" yum groupinstall "Development tools" CentOS7安装如下包: yum groupinstall "Server with GUI" yum groupinstall "GNOME Desktop" yum groupinstall "Development Tools" 设置系统默认启动图形界面 CentOS6,编辑 /etc/inittab, CentOS7,执行 systemctl set-default graphical.target 设置 root密码 设置root密码默认为“passw0rd” 允许root 通过密码ssh登录 编辑 /etc/ssh/sshd_config,作以下修改。 重启ssh服务 service sshd restart 修改 /etc/cloud/cloud.cfgcloud image都是用 cloudinit 初始化instance,比如配置网络,extend 系统盘等,cloudinit 所有的配置都写在/etc/cloud/cloud.cfg,下面的配置将允许 root 通过password ssh 登录。 至此,centos6-vm已经可以启动图形界面,并且可以用密码通过ssh登录了。 安装cloud-utils-growpart(CentOS 6 only) cloudint 会用到这个软件管理磁盘分区,因为 CentOS6 cloud image 中没有安装,所以这里需要手工安装。下载地址:https://pkgs.org/centos-6/epel-x86_64/cloud-utils-growpart-0.27-10.el6.x86_64.rpm/download/ rpm -Uvh cloud-utils-growpart-0.27-10.el6.x86_64.rpm 3. 创建新镜像 我们在instance中完成了定制工作,接下来对instance做个快照,生成新的镜像。点击“centos6-vm”后面的“创建快照”按钮。 为快照命名。 点击“创建快照”。 4. 部署新实例 点击“启动云主机”通过快照部署新的实例。 点击“运行”,实例部署成功。 可以看到,该实例已经启动了图形界面,并且root可以通过ssh密码登录。 将 snapshot 转化为 image(可选) Glance镜像有两类:image和snapshot,前面通过对instance做快照创建的镜像类型为 snapshot,有时候可能会觉得不太方便,可以将snapshot转化为image。 以 CentOS 6.7n为例,可以直接glance image-create命令通过将其转化为image类型。步骤如下: 1. 在其详细信息里面记录下ID为:228f7bdc-fcf1-4f6a-8a7a-298b86f9e94b 2. 该镜像默认存放于控制节点 /var/lib/glance/images/228f7bdc-fcf1-4f6a-8a7a-298b86f9e94b。 3. 执行glance image-create创建新的镜像。 glance image-create --name "CentOS 6.7" --file 228f7bdc-fcf1-4f6a-8a7a-298b86f9e94b --disk-format qcow2 --container-format bare --is-public true --progress 4. 新创建的镜像类型为image。 以上就是定制 OpenStack Linux 镜像的常规操作,下一节我们讨论 Windows 镜像的制作方法。

优秀的个人博客,低调大师

OVS VxLAN Flow 分析 - 每天5分钟玩转 OpenStack(149)

OVS 的数据流向都是由 Flow 规则控制的,今天我们就来分析 VxLAN 的 Flow 规则。提个醒:这可能是本教程最烧脑的一节,let's rock it ! 下面分析控制节点上的 flow rule,计算节点类似。 br-int 的 flow rule br-int 的 rule 看上去虽然多,其实逻辑很简单,br-int 被当作一个二层交换机,其重要的 rule 是下面这条: cookie=0xaaa0e760a7848ec3, duration=52798.625s, table=0, n_packets=143, n_bytes=14594, idle_age=9415, priority=0 actions=NORMAL 此规则的含义是:根据 vlan 和 mac 进行转发。 br-tun 的 flow rule 这些才是真正处理 VXLAN 数据包的 rule,流程如下: 上图各方块中的数字对应 rule 中 table 的序号,比如编号为0的方块对应下面三条 rule。 table 0 cookie=0xaaa0e760a7848ec3, duration=76707.867s,table=0, n_packets=70, n_bytes=6600, idle_age=33324, hard_age=65534, priority=1,in_port=1 actions=resubmit(,2) cookie=0xaaa0e760a7848ec3, duration=76543.287s,table=0, n_packets=56, n_bytes=4948, idle_age=33324, hard_age=65534, priority=1,in_port=2 actions=resubmit(,4) cookie=0xaaa0e760a7848ec3, duration=76707.867s,table=0, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=drop 结合如下 port 编号: table 0 flow rule 的含义为: 从 port 1(patch-int)进来的包,扔给 table 2 处理:actions=resubmit(,2) 从 port 2(vxlan-a642100b)进来的包,扔给 table 4 处理:actions=resubmit(,4) 即第一条 rule 处理来自内部 br-int(这上面挂载着所有的网络服务,包括路由、DHCP 等)的数据;第二条 rule 处理来自外部 VXLAN 隧道的数据。 table 4 cookie=0xaaa0e760a7848ec3, duration=76647.039s,table=4, n_packets=56, n_bytes=4948, idle_age=33324, hard_age=65534, priority=1,tun_id=0x64 actions=mod_vlan_vid:1,resubmit(,10) table 4 flow rule 的含义为: 如果数据包的 VXLAN tunnel ID 为 100(tun_id=0x64),action 是添加内部 VLAN ID 1(tag=1),然后扔给 table 10 去学习。 table 10 cookie=0xaaa0e760a7848ec3, duration=76707.865s,table=10, n_packets=56, n_bytes=4948, idle_age=33324, hard_age=65534, priority=1 actions=learn(table=20,hard_timeout=300,priority=1,cookie=0xaaa0e760a7848ec3,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:NXM_OF_IN_PORT[]),output:1 table 10 flow rule 的含义为: 学习外部(从 tunnel)进来的包,往 table 20 中添加对返程包的正常转发规则,然后从 port 1(patch-int)扔给 br-int。 rule 中下面的内容为学习规则,这里就不详细讨论了。 NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:NXM_OF_IN_PORT[] table 2 cookie=0xaaa0e760a7848ec3, duration=76707.866s,table=2, n_packets=28, n_bytes=3180, idle_age=33324, hard_age=65534, priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,20) cookie=0xaaa0e760a7848ec3, duration=76707.866s,table=2, n_packets=42, n_bytes=3420, idle_age=33379, hard_age=65534, priority=0,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,22) table 2 flow rule 的含义为: br-int 发过来数据如果是单播包,扔给 table 20 处理:resubmit(,20) br-int 发过来数据如果是多播或广播包,扔 table 22 处理:resubmit(,22) table 20 cookie=0xaaa0e760a7848ec3, duration=76543.287s,table=20, n_packets=28, n_bytes=3180, idle_age=33324, hard_age=65534, priority=2,dl_vlan=1,dl_dst=fa:16:3e:fd:8a:ed actions=strip_vlan,set_tunnel:0x64,output:2 cookie=0xaaa0e760a7848ec3, duration=76707.865s,table=20, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=resubmit(,22) table 20 flow rule 的含义为: 第一条规则就是 table 10 学习来的结果。内部 VLAN 号为 1(tag=1),目标 MAC 是 fa:16:3e:fd:8a:ed(virros-vm2)的数据包,即发送给 virros-vm2 的包,action 是去掉 VLAN 号,添加 VXLAN tunnel ID 100(十六进制 0x64),并从 port 2 (tunnel 端口 vxlan-a642100b) 发出。 对于没学习到规则的数据包,则扔给 table 22 处理。 table 22 cookie=0xaaa0e760a7848ec3, duration=76543.282s,table=22, n_packets=2, n_bytes=84, idle_age=33379, hard_age=65534, dl_vlan=1 actions=strip_vlan,set_tunnel:0x64,output:2 cookie=0xaaa0e760a7848ec3, duration=76707.82s,table=22, n_packets=40, n_bytes=3336, idle_age=65534, hard_age=65534, priority=0 actions=drop table 22 flow rule 的含义为: 如果数据包的内部 VLAN 号为 1(tag=1),action 是去掉 VLAN 号,添加 VXLAN tunnel ID 100(十六进制 0x64),并从 port 2 (tunnel 端口 vxlan-a642100b) 发出。 VXLAN 的路由和 floating IP 支持 对于多 VXLAN 之间的 routing 以及 floating IP,实现方式与 vlan 非常类似,这里不再赘述,请参看前面 vlan 相关章节。 总结 本章重点讨论 Neutron 的架构,并通过分析 Linux Bridge 和 Open vSwitch 两个 mechnism driver 的技术细节,实践了 local,flat,vlan,vxlan 四种网络类型,同时也讨论了 routing 以及 floating IP 的实现细节。 Linux Bridge 和 Open vSwitch 都支持 Securet Group,Firewall as a Service ,Load Balancing as a Service 等高级功能,其实现方式也大致相同。 通过本章的学习,大家应该能够掌握 Neutron 的理论知识并应用到实践部署中。 到这里,OpenStack 的核心技术全部讨论完了,下一次 CloudMan 会带着大家回顾一下这些知识,给大家一些深入学习的建议,同时也会谈谈对后续新教程的一些想法。

优秀的个人博客,低调大师

访问 Neutron 外部网络 - 每天5分钟玩转 OpenStack(143)

前面我们学习了位于不同 Neutron subnet 的 instance 可以通过 router 通信,今天开始讨论 instance 如何访问外部网络。 这里的外部网络是指的租户网络以外的网络。租户网络是由 Neutron 创建和维护的网络。 外部网络不由 Neutron 创建。如果是私有云,外部网络通常指的是公司 intranet;如果是公有云,外部网络通常指的是 internet。 具体到我们的实验网络环境: 计算节点和控制节点 eth1 提供的是租户网络,IP 段租户可以自由设置。 控制节点 eth2 连接的就是外部网络,IP 网段为 10.10.10.2/24。如下图所示: 配置准备 为了连接外部网络,需要预先在配置文件中告诉 Neutron 外部网络的类型以及对应的 Open vSwitch 网桥。 外部网络是已经存在的物理网络,一般都是 flat 或者 vlan 类型。 这里我们将外部网络的 label 命名为 “external”,网桥为 br-ex。 如果类型为 flat,控制节点 /etc/neutron/plugins/ml2/ml2_conf.ini 配置如下: 如果类型为 vlan,配置如下: 在我们的网络环境中,外部网络是 flat 类型。 修改配置后,需要重启 neutron 的相关服务。另外,我们需要提前准备好 br-ex,将 eth2 添加到 br-ex。 br-ex 已经存在,我们只需要添加 eth2。 下一节我们演示如何创建外部网络 ext_net。

优秀的个人博客,低调大师

Neutron Router 工作原理 - 每天5分钟玩转 OpenStack(142)

上一节我们创建了 router 连通了 vlan100 和 vlan101, 今天分析router是如何工作的。首先查看控制节点的网络结构发生了什么变化: br-int 上多了两个 port: 1. qr-d295b258-45,从命名上可以推断该 interface 对应 router_100_101 的 interface (d295b258-4586),是 subnet_172_16_100_0 的网关。2. qr-2ffdb861-73,从命名上可以推断该 interface 对应 router_100_101 的 interface (2ffdb861-731c),是 subnet_172_16_101_0 的网关。 与 linux bridge 实现方式一样, router_100_101 运行在自己的 namespace 中。 如上所示,qrouter-a81cc110-16f4-4d6c-89d2-8af91cec9714 为 router 的 namespace,两个 Gateway IP 分别配置在 qr-2ffdb861-73 和 qr-d295b258-45 上。 当前网络结构如图所示: route_101_101 上配置了 vlan100 和 vlan101 的网关,两个网络在三层上就通了。 下一节我们讨论 neutron 网络中的 instance 如何访问外网。

优秀的个人博客,低调大师

创建 OVS flat network - 每天5分钟玩转 OpenStack(134)

上一节完成了 flat 的配置工作,今天创建 OVS flat network。Admin -> Networks,点击 “Create Network” 按钮。 显示创建页面。 Provider Network Type 选择 “Flat”。 Physical Network 填写 “default”,与 ml2_conf.ini 中 flat_networks 参数值保持一致。 点击 “Create Network”,flat_net 创建成功。 点击 flat_net 链接,进入 network 配置页面,目前还没有 subnet,点击 “Create Subnet” 按钮。 设置 IP 地址为 “172.16.1.0/24”。 点击 “Next”,勾选 “Enable DHCP”。 点击 “Create”,subnet 创建成功。 底层网络发生了什么变化 查看控制节点的网络结构,执行 ovs-vsctl show: Neutron 自动在 br-int 网桥上创建了 flat-net dhcp 的接口 “tap83421c44-93”。 此时 flat_net 结构如图所示: 下一节部署 instance 并验证 flat 网络的连通性。

优秀的个人博客,低调大师

创建 OVS Local Network - 每天5分钟玩转 OpenStack(129)

上一节我们完成了 OVS 的准备工作,本节从最基础的 local network 开始学习。local network 不会与宿主机的任何物理网卡连接,流量只被限制在宿主机内,同时也不关联任何的 VLAN ID。 创建第一个 local network 下面我们通过 Web GUI 创建 local network。 进入菜单 Admin -> Networks,点击 “Create Network” 按钮。 显示创建页面。 “Provider Network Type” 选择 “Local”,点击 “Create Network”,first_local_net 创建成功。 点击 first_local_net 链接,进入 network 配置页面,目前还没有 subnet,点击 “Create Subnet” 按钮。 设置 IP 地址为 “172.16.1.0/24”。 点击 “Next”。 勾选 “Enable DHCP”,IP 池设置为 “172.16.1.2,172.16.1.99”。 点击 “Create”,subnet 创建成功。 同时 devstack-controler 针对此 subnet 的 DHCP 服务也已经 Active。 底层网络发生了什么变化? 创建 OVS local network 的过程与 Linux Bridge 没有什么区别。这是因为 Neutron 已经对不同 driver 进行了抽象,但底层实现肯定是有区别的。所以,接下来我们要搞清楚底层网络有了哪些变化? 打开控制节点的 shell 终端,用 ovs-vsctl show 查看当前 Open vSwitch 的状态。 可以看到 Neutron 自动在 br-int 网桥上创建了 port “tap7970bdcd-f2”。 从命名可知,该 port 对应 local_net 的 dhcp 接口。 与 linux bridge driver 一样,dhcp 设备也是放在命名空间里的。 目前网络结构如下图所示: 下节我们会部署 instance 到 first_local_network 并再次观察这张网络拓扑图的变化。

优秀的个人博客,低调大师

创建 Monitor 并测试 - 每天5分钟玩转 OpenStack(124)

前面我们创建了 Pool,VIP 并添加了 Member。今天将创建 Monitor,然后测试 LBaaS 是否能够正常工作。 创建 Monitor LBaaS 可以创建 monitor,用于监控 Pool Member 健康状态。 如果某个 member 不能正常工作,monitor 会将其状态设置为 down,从而避免将后续请求转发给它。 下面我们为 Pool 添加一个 monitor。 在 Monitors 标签页中点击 “Add Monitor” 按钮 Type 选择 “HTTP”,含义是通过 HTTP 检查 member 的健康状态。 Delay 设置为 “10”,含义是 10 秒检查一次 member 的状态。 Timeout 设置为 “5”,含义是如果 member 在 5 秒内无法应答,则超时。 Max Reties 设置为 “3”,含义是如果尝试 3 次都超时或者失败,则将 member 状态设置为 down。 HTTP Method 设置为 “GET” URL 设置为 “/” Expected HTTP Status Codes 设置为 “200” 上面三项的含义是通过 HTTP GET 请求 member “/” URL,如果返回码为 200,则认为 member 状态正常。 点击 “Add”,monitor 创建成功。 下面将新建的 monitor 添加到 pool 。 在 “web servers” 的操作列表中点击 “Associate Monitor” 选择我们刚刚创建的 monitor。 点击 “Associate”。 测试 LBaaS 经过上面的设置,我们创建了包含 member “Web1” 和 “Web2” 的 Pool “web servers”,并添加了 monitor。 准备就绪,可以测试 load balancer 是否正常工作了。 首先在 Web1 和 Web2 中启动 HTTP 服务,在 80 端口监听 这里我们使用 python 提供的 SimpleHTTPServer 模块启动了 HTTP 服务。 web server 的 index.html 显示当前访问的是哪个 member。 在 router 的 namespace 上多次执行 curl 172.16.100.11(VIP) 测试结果显示每次访问的都是 Web2 这个 member。 为什么没有访问到 Web1 呢? 还记得我们前面讨论的内容吗: Load Balance Method -- ROUND_ROUBIN Session Persistence -- SOURCE_IP 在这种配置下,第一个 curl 请求 HAProxy 通过 ROUND_ROUBIN 选择了 Web2。而后续的请求,HAProxy 则会应用 SOURCE_IP 机制,仍然选择 Web2。 下面我们修改一下配置。 在 “web servers” 的操作列表中点击 “Edit VIP”。 选择 “No session persistence” 并保存。 再进行 curl 测试。 可以看到已经在 “Web1” 和 “Web2” 之间 round robin 了。 下一节我们将分析 LBaaS 的内部实现和工作机制。

优秀的个人博客,低调大师

创建 Pool & VIP - 每天5分钟玩转 OpenStack(122)

上节完成了 LBaaS 配置,今天我们开始实现如下 LBaaS 环境。 环境描述如下: 1. 创建一个 Pool “web servers”。 2. 两个 pool member “WEB1” 和 “WEB2”,均为运行 Ubuntu cloud image 的 instance。 3. load balancer VIP 与 floating IP 关联。 4. 位于外网的 client 通过 floating IP 外网访问 web server 我们从第一步开始。 创建 Pool 点击菜单 Project -> Network -> Load Balancers,点击 Pools 标签页中的 “Add Pool” 按钮。 显示 Pool 创建页面。 将 Pool 命名为“web servers”。 Provider 选择默认的 “haproxy”。 Subnet 选择 “172.16.100.0/24”。 Protocol 选择 “HTTP”。 Load Balancing Method 选择 “ROUND_ROBIN”。 点击 “Add” 按钮,“web servers” 创建成功。 这里对 Pool 的几个属性进行一下说明。 LBaaS 支持如下几种 Protocol: 因为我们用 web server 做实验,所以这里需要选择 “HTTP” LBaaS 支持多种 load balance method: ROUND_ROUBIN 如果采用 round robin 算法,load balancer 按固定的顺序从 pool 中选择 member 相应 client 的连接请求。 这种方法的不足是缺乏机制检查 member 是否负载过重。 有可能出现某些 member 由于处理能力弱而不得不继续处理新连接的情况。 如果所有 pool member 具有相同处理能力、内存容量,并且每个连接持续的时间大致相同,这种情况非常适合 round robin,每个 member 的负载会很均衡。 LEAST_CONNECTIONS 如果采用 least connections 算法,load balancer 会挑选当前连接数最少的 pool member。 这是一种动态的算法,需要实时监控每个 member 的连接数量和状态。 计算能力强的 member 能够更快的处理连接进而会分配到更多的新连接。 SOURCE_IP 如果采用 source IP 算法,具有相同 source IP 的连接会被分发到同一个 pool member。 source IP 算法对于像购物车这种需要保存状态的应用特别有用,因为我们希望用同一 server 来处理某个 client 连续的在线购物操作。 在我们的实验中选择的是 ROUND_ROUBIN 算法。 为 Pool 添加 VIP 现在 Pool 已经就绪,接下需要为其设置 VIP。 在 “web servers” 的操作列表中点击 “Add VIP”。 VIP 命名为 “VIP for web servers”。 VIP Subnet 选择 “172.16.100.0/24”,与 pool 一致。 指定 VIP 为 172.16.100.11,如果不指定,系统会自动从 subnet 中分配。 指定 HTTP 端口 80。 Session Persistence 选择 “SOURCE IP”。 可以通过 Connection Limit 限制连接的数量,如果不指定则为不加限制。 点击 “Add”,VIP 创建成功。 通常我们希望让同一个 server 来处理某个 client 的连续请求。 否则 client 可能会由于丢失 session 而不得不重新登录。 这个特性就是 Session Persistence。 VIP 支持如下几种 Session Persistence 方式: SOURCE_IP 这种方式与前面 load balance 的 SOURCE_IP 效果一样。 初始连接建立后,后续来自相同 source IP 的 client 请求会发送给同一个 member。 当大量 client 通过同一个代理服务器访问 VIP 时(比如在公司和学校上网),SOURCE_IP 方式会造成 member 负载不均。 HTTP_COOKIE HTTP_COOKIE 的工作方式如下: 当 client 第一次连接到 VIP 时,HAProxy 从 pool 中挑选出一个 member。 当此 member 响应请求时,HAProxy 会在应答报文中注入命名为 “SRV” 的 cookie,这个 cookie 包含了该 member 的唯一标识。 client 的后续请求都会包含这个 “SRV” cookie。 HAProxy 会分析 cookie 的内容,并将请求转发给同一个 member。 HTTP_COOKIE 优于 SOURCE_IP,因为它不依赖 client 的 IP。 APP_COOKIE app cookie 依赖于服务器端应用定义的 cookie。 比如 app 可以通过在 session 中创建 cookie 来区分不同的 client。 HAProxy 会查看报文中的 app cookie,确保将包含 app cookie 的请求发送到同一个 member。 如果没有 cookie(新连接或者服务器应用不创建 cookie),HAProxy 会采用 ROUND_ROUBIN 算法分配 member。 比较 Load Balance Method 和 Session Persistence 前面我们介绍了三种 Load Balance Method: 这里还有三种 Session Persistence: 因为两者都涉及到如何选择 pool member,所以很容易混淆。 它们之间的最大区别在于选择 pool member 的阶段不同: Load Balance Method 是为新连接选择 member 的方法 Session Persistence 是为同一个 client 的后续连接选择 member 的方法 例如这里我们的设置为: Load Balance Method -- ROUND_ROUBIN Session Persistence -- SOURCE_IP 当 client A 向 VIP 发送第一个请求时,HAProxy 通过 ROUND_ROUBIN 选择 member1。对于 client A 后续的请求,HAProxy 则会应用 SOURCE_IP 机制,仍然选择 member1 来处理请求。 Pool 创建完毕,下一节我们向 Pool 添加 Member。

优秀的个人博客,低调大师

应用新安全组 - 每天5分钟玩转 OpenStack(116)

Neutron 默认的安全组规则会禁止掉所有从外面访问 instance 的流量。 本节我们会修改安全组的配置,允许 ping 和 ssh instance。有两种方法可以达到这个目的: 1. 修改 “default” 安全组。 2. 为 cirros-vm1 添加新的安全组。 这里我们采用第二种方法。 在安全组列表页面点击按钮。 为安全组命名并点击 “Create Security Group”。 新的安全组 “allow ping & ssh” 创建成功。 点击按钮,查看 “allow ping & ssh” 的规则。 系统默认定义了两条规则,运行所有的外出流量。 为清晰起见,可以点击按钮删除这两条规则。 点击按钮,添加允许 ping 的规则。 “Rule” 选择 “All ICMP”,“Direction” 选择 “Ingress”,然后点击 “Add” 按钮。 同样的方式添加 ssh 规则。 在列表中查看添加成功的规则。 接下来设置 cirros-vm1,使用新的安全组。 进入 instance 列表页面,点击 cirros-vm1 下拉操作列表中的 “Edit Security Groups” 可以看到 cirros-vm1 当前使用的安全组为 “default”,可选安全组为 “allow ping & ssh”。 点击安全组 “allow ping & ssh” 后面的 “+” 按钮。 点击 “Save” 保存。 iptables 会立即更新,下面通过 vimdiff 查看 iptables 前后的变化。 “allow ping & ssh” 安全组引入了下面两条 iptables 规则。 作用是运行 ingress 的 ssh 和 ping 流量。 -A neutron-linuxbri-i8bca5b86-2 -p tcp -m tcp --dport 22 -j RETURN -A neutron-linuxbri-i8bca5b86-2 -p icmp -j RETURN 测试一下,现在能够 ping 和 ssh cirros-vm1 了。 小结 安全组有以下特性: 1. 通过宿主机上 iptables 规则控制进出 instance 的流量。 2. 安全组作用在 instance 的 port 上。 3. 安全组的规则都是 allow,不能定义 deny 的规则。 4. instance 可应用多个安全组叠加使用这些安全组中的规则。 安全组学习完了,下节我们讨论 Neutron 的另一个安全机制 -- 虚拟防火墙。

优秀的个人博客,低调大师

部署 instance 到 VXLAN - 每天5分钟玩转 OpenStack(112)

上一节我们创建了 vxlan 100_net,今天将部署 instance 并分析网络的连通性。 launch 新的 instance “cirros-vm1”,网络选择 vxlan100。 cirros-vm1 分配到的 IP 为 172.16.100.3。 cirros-vm1 被 schedule 到控制节点,对应的 tap 设备为 tap099caa87-cd,并且连接到 bridge brq1762d312-d4。 当前 vxlan100 的结构如下: 继续用同样的方式 launch instance cirros-vm2,分配到的 IP 为 172.16.100.4。 cirros-vm2 被 schedule 到计算节点,对应的 tap 设备为 tap457cc048-aa,并且连接到 bridge brq1762d312-d4。 因为计算节点上没有 hdcp 服务,所以没有相应的 tap 设备。 另外,bridge 的名称与控制节点上一致,都是 brq1762d312-d4,表明是同一个 network。 当前 vxlan100 的结构如下: cirros-vm1(172.16.100.3) 与 cirros-vm2(172.16.100.4) 位于不同节点,通过 vxlan100 相连,下面执行 PING 验证连通性。 在 cirros-vm1 控制台中执行 ping 172.16.100.4 如我们预料,ping 成功。 对于多 vxlan 之间的 routing 以及 floating ip,实现方式与 vlan 非常类似,这里不再赘述,请参看前面 vlan 相关章节。 下节我们讨论提高 VXLAN 工作效率的机制 - L2 Population。

优秀的个人博客,低调大师

VXLAN 概念(Part II)- 每天5分钟玩转 OpenStack(109)

上一节我们介绍了 VXLAN 的封装格式以及 VTEP。今天我们将通过例子讨论 VXLAN 封装和转发包的过程,以及 Linux 对 VXLAN 的原生支持。 VXLAN 包转发流程 VXLAN 在 VTEP 间建立隧道,通过 Layer 3 网络传输封装后的 Layer 2 数据。下面的例子演示了数据如何在 VXLAN 上传输: 图中 Host-A 和 Host-B 位于 VNI 10 的 VXLAN,通过 VTEP-1 和 VTEP-2 之间建立的 VXLAN 隧道通信。数据传输过程如下: Host-A 向 Host-B 发送数据时,Host-B 的 MAC 和 IP 作为数据包的目标 MAC 和 IP,Host-A 的 MAC 作为数据包的源 MAC 和 IP,然后通过 VTEP-1 将数据发送出去。 VTEP-1 从自己维护的映射表中找到 MAC-B 对应的 VTEP-2,然后执行 VXLAN 封装,加上 VXLAN 头,UDP 头,以及外层 IP 和 MAC 头。此时的外层 IP 头,目标地址为 VTEP-2 的 IP,源地址为 VTEP-1 的 IP。同时由于下一跳是 Router-1,所以外层 MAC 头中目标地址为 Router-1 的 MAC。 数据包从 VTEP-1 发送出去后,外部网络的路由器会依据外层 IP 头进行包路由,最后到达与 VTEP-2 连接的路由器 Router-2。 Router-2 将数据包发送给 VTEP-2。VTEP-2 负责解封数据包,依次去掉外层 MAC 头,外层 IP 头,UDP 头 和 VXLAN 头。 VTEP-2 依据目标 MAC 地址将数据包发送给 Host-B。 上面的流程我们看到 VTEP 是 VXLAN 的最核心组件,负责数据的封装和解封。 隧道也是建立在 VTEP 之间的,VTEP 负责数据的传送。 Linux 对 VXLAN 的支持 VTEP 可以由专有硬件来实现,也可以使用纯软件实现。 目前比较成熟的 VTEP 软件实现包括: 带 VXLAN 内核模块的 Linux Open vSwitch 我们先来看 Linux 如何支持 VXLAN,Open vSwitch 方式将在后面章节讨论。 实现方式: Linux vxlan 创建一个 UDP Socket,默认在 8472 端口监听。 Linux vxlan 在 UDP socket 上接收到 vxlan 包后,解包,然后根据其中的 vxlan ID 将它转给某个 vxlan interface,然后再通过它所连接的 linux bridge 转给虚机。 Linux vxlan 在收到虚机发来的数据包后,将其封装为多播 UDP 包,从网卡发出。 到这里,相信大家对 VXLAN 的原理已经有了大致的了解。 下节我们将学习如何在 Neutron 中配置和实施 VXLAN。

优秀的个人博客,低调大师

VXLAN 概念(Part I) - 每天5分钟玩转 OpenStack(108)

除了前面讨论的 local, flat, vlan 这几类网络,OpenStack 还支持 vxlan 和 gre 这两种 overlay network。 overlay network 是指建立在其他网络上的网络。 该网络中的节点可以看作通过虚拟(或逻辑)链路连接起来的。 overlay network 在底层可能由若干物理链路组成,但对于节点,不需要关心这些底层实现。 例如 P2P 网络就是 overlay network,隧道也是。 vxlan 和 gre 都是基于隧道技术实现的,它们也都是 overlay network。 目前 linux bridge 只支持 vxlan,不支持 gre;open vswitch 两者都支持。 vxlan 与 gre 实现非常类似,而且 vxlan 用得较多,所以本教程只介绍 vxlan。 VXLAN 全称 Virtual eXtensible Local Area Network。 正如名字所描述的,VXLAN 提供与 VLAN 相同的以太网二层服务,但是拥有更强的扩展性和灵活性。与 VLAN 相比,VXLAN 有下面几个优势: 支持更多的二层网段。 VLAN 使用 12-bit 标记 VLAN ID,最多支持 4094 个 VLAN,这对于大型云部署会成为瓶颈。VXLAN 的 ID (VNI 或者 VNID)则用 24-bit 标记,支持 16777216 个二层网段。 能更好地利用已有的网络路径。 VLAN 使用 Spanning Tree Protocol 避免环路,这会导致有一半的网络路径被 block 掉。VXLAN 的数据包是封装到 UDP 通过三层传输和转发的,可以使用所有的路径。 避免物理交换机 MAC 表耗尽。 由于采用隧道机制,TOR (Top on Rack) 交换机无需在 MAC 表中记录虚拟机的信息。 VXLAN 封装和包格式 VXLAN 是将二层建立在三层上的网络。 通过将二层数据封装到 UDP 的方式来扩展数据中心的二层网段数量。 VXLAN 是一种在现有物理网络设施中支持大规模多租户网络环境的解决方案。 VXLAN 的传输协议是 IP + UDP。 VXLAN 定义了一个 MAC-in-UDP 的封装格式。 在原始的 Layer 2 网络包前加上 VXLAN header,然后放到 UDP 和 IP 包中。 通过 MAC-in-UDP 封装,VXLAN 能够在 Layer 3 网络上建立起了一条 Layer 2 的隧道。 VXLAN 包的格式如下: 如上图所示,VXLAN 引入了 8-byte VXLAN header,其中 VNI 占 24-bit。 VXLAN 和原始的 L2 frame 被封装到 UDP 包中。 这 24-bit 的 VNI 用于标示不同的二层网段,能够支持 16777216 个 LAN。 VXLAN Tunnel Endpoint VXLAN 使用 VXLAN tunnel endpoint (VTEP) 设备处理 VXLAN 的封装和解封。 每个 VTEP 有一个 IP interface,配置了一个 IP 地址。VTEP 使用该 IP 封装 Layer 2 frame,并通过该 IP interface 传输和接收封装后的 VXLAN 数据包。 下面是 VTEP 的示意图: VXLAN 独立于底层的网络拓扑; 反过来,两个 VTEP 之间的底层 IP 网络也独立于 VXLAN。 VXLAN 数据包是根据外层的 IP header 路由的,该 header 将两端的 VTEP IP 作为源和目标 IP。 下节我们通过例子进一步理解 VXLAN 封装和转发包的过程,并探讨 Linux 对 VXLAN 的支持。

优秀的个人博客,低调大师

外网访问原理分析 - 每天5分钟玩转 OpenStack(105)

本节我们会将上节创建的 ext_net 连接到 router,并验证内外网的连通性。 更重要的,我们会分析隐藏在表象之下的原理。 将外网连接到 Neutron 的虚拟路由器,这样 instance 才能访问外网。 点击菜单 Project -> Network -> Routers 进入 router 列表。 点击 router_100_101 的 “Set Gateway” 按钮。 在 “External Network” 下拉列表中选择 ext_net,点击 “Set Gateway”。 外网设置成功。 我们需要看看 router 发生了什么变化。 点击 “router_100_101” 链接,打开 “Interfaces” 标签页 router 多了一个新的 interface,IP 为 10.10.10.2。 该 interface 用于连接外网 ext_net。 查看控制节点的网络结构,外网 bridge 上已经连接了 router 的 tap 设备 tapb8b32a88-03。 在 router 的 namespace 中查看 tapb8b32a88-03 的 veth pair 设备。 该 veth pair 命名为 qg-b8b32a88-03,上面配置了 IP 10.10.10.2。 router 的每个 interface 在 namespace 中都有对应的 veth。 如果 veth 用于连接租户网络,命名格式为 qr-xxx,比如 qr-d568ba1a-74 和 qr-e17162c5-00。 如果 veth 用于连接外部网络,命名格式为 qg-xxx,比如 qg-b8b32a88-03。 查看 router 的路由表信息。 可以看到默认网关为 10.10.10.1。 意味着对于访问 vlan100 和 vlan101 租户网络以外的所有流量,router_100_101 都将转发给 ext_net 的网关 10.10.10.1。 现在 router_100_101 已经同时连接了 vlan100, vlan101 和 ext_net 三个网络,如下图所示: 下面我们在 cirros-vm3 上测试一下。 cirros-vm3 位于计算节点,现在已经可以 Ping 到 ext_net 网关 10.10.10.1 了。 通过 traceroute 查看一下 cirros-vm3 到 10.10.10.1 的路径 数据包经过两跳到达 10.10.10.1 网关。 1. 数据包首先发送到 router_100_101 连接 vlan101 的 interface(172.16.101.1)。 2. 然后通过连接 ext_net 的 interface(10.10.10.2) 转发出去,最后到达 10.10.10.1。 当数据包从 router 连接外网的接口 qg-b8b32a88-03 发出的时候,会做一次 Source NAT,即将包的源地址修改为 router 的接口地址 10.10.10.2,这样就能够保证目的端能够将应答的包发回给 router,然后再转发回源端 instance。 可以通过 iptables 命令查看 SNAT 的规则。 当 cirros-vm3(172.16.101.3) Ping 10.10.10.1 时,可用通过 tcpdump 分别观察 router 两个 interface 的 icmp 数据包来验证 SNAT 的行为。 vlan101 interface qr-e17162c5-00 的 tcpdump 输出: ext_net interface qg-b8b32a88-03 的 tcpdump 输出: SNAT 让 instance 能够直接访问外网,但外网还不能直接访问 instance。因为 instance 没有外网 IP。 这里 “直接访问 instance” 是指通信连接由外网发起,例如从外网 SSH cirros-vm3。 这个问题可以通过 floating IP 解决,下一节我们将讨论浮动 IP。

优秀的个人博客,低调大师

虚拟 ​router 原理分析- 每天5分钟玩转 OpenStack(101)

上一节我们创建了虚拟路由器“router_100_101”,并通过 ping 验证了 vlan100 和 vlan101 已经连通。 本节将重点分析其中的原理。 首先我们查看控制节点的 linux bridge 结构发生了什么变化。 vlan101 的 bridge 上多了一个 tape17162c5-00,从命名上可以推断该 TAP 设备对应 router_100_101 的 interface (e17162c5-00fa)。 vlan100 的 bridge 上多了一个 tapd568ba1a-74,从命名上可以推断该 TAP 设备对应 router_100_101 的 interface (d568ba1a-740e)。 当前网络结构如图所示: 但发现一个问题:两个 TAP 设备上并没有配置相应的 Gateway IP。 如果没有 Gateway IP,router_100_101 是如何完成路由的呢? 答案是: l3 agent 会为每个 router 创建了一个 namespace,通过 veth pair 与 TAP 相连,然后将 Gateway IP 配置在位于 namespace 里面的 veth interface 上,这样就能提供路由了。 通过 ip netns 查看 namespace: router 对应的 namespace 命名为 qrouter-<router id>。 通过 ip netns exec <namespace name> ip a 命令查看 router_100_101 namespace 中的 veth interface 配置。 namespace 中有两个 interface: qr-e17162c5-00 上设置了 Gateway IP 172.16.101.1,与 root namespace 中的 tape17162c5-00 组成 veth pair。 qr-d568ba1a-74 上设置了 Gateway IP 172.16.100.1,与 root namespace 中的 tapd568ba1a-74 组成 veth pair。 网络结构如图所示: namespace 中的路由表也保证了 subnet_172_16_100_0 和 subnet_172_16_101_0 之间是可以路由的。 分析到这里,我们已经搞清楚 router_100_101 是如何打通 vlan100 和 vlan 101 了。但这里有一个关键问题需要进一步分析:为什么要把 router_100_101 放到 namespace 中?下一节我们将详细分析这个问题。

优秀的个人博客,低调大师

Neutron Vlan Network 原理- 每天5分钟玩转 OpenStack(92)

前面我们陆续学习了 Neutron local network,flat network 和 DHCP 服务,从本节将开始讨论 vlan network。 vlan network 是带 tag 的网络,是实际应用最广泛的网络类型。下图是 vlan100 网络的示例。 1. 三个 instance 通过 TAP 设备连接到名为 “brqXXXX” linux bridge。 2. 在物理网卡 eth1 上创建了 eth1.100 的 vlan interface,eth1.100 连接到 brqXXXX。 3. instance 通过 eth1.100 发送到 eth1 的数据包就会打上 vlan100 的 tag。 如果再创建一个 network vlan101,eth1 上会相应的创建 vlan interface eth1.101,并且连接的新的 lingux bridge “brqYYYY”。 每个 vlan network 有自己的 bridge,从而也就实现了基于 vlan 的隔离。 这里有一点要 特别提醒: 因为物理网卡 eth1 上面可以走多个 vlan 的数据,那么物理交换机上与 eth1 相连的的 port 要设置成 trunk 模式,而不是 access 模式。 下一节讨论如何在 Neutron 中配置 vlan 网络。

优秀的个人博客,低调大师

Neutron 物理部署方案 - 每天5分钟玩转 OpenStack(68)

前面我们讨论了 Neutron 的架构,本节讨论 Neutron 的物理部署方案:不同节点部署不同的 Neutron 服务组件。 方案1:控制节点 + 计算节点 在这个部署方案中,OpenStack 由控制节点和计算节点组成。 控制节点部署的服务包括:neutron server, core plugin 的 agent 和 service plugin 的 agent。 计算节点部署 core plugin 的agent,负责提供二层网络功能。 这里有两点需要说明: 1. core plugin 和 service plugin 已经集成到 neutron server,不需要运行独立的 plugin 服务。 2. 控制节点和计算节点都需要部署 core plugin 的 agent,因为通过该 agent 控制节点与计算节点才能建立二层连接。 3. 可以部署多个控制节点和计算节点。 方案2:控制节点 + 网络节点 + 计算节点 在这个部署方案中,OpenStack 由控制节点,网络节点和计算节点组成。 控制节点部署 neutron server 服务。 网络节点部署的服务包括:core plugin 的 agent 和 service plugin 的 agent。 计算节点部署 core plugin 的agent,负责提供二层网络功能。 这个方案的要点是将所有的 agent 从控制节点分离出来,部署到独立的网络节点上。 控制节点只负责通过 neutron server 响应 API 请求。 由独立的网络节点实现数据的交换,路由以及 load balance等高级网络服务。 可以通过增加网络节点承担更大的负载。 可以部署多个控制节点、网络节点和计算节点。 该方案特别适合规模较大的 OpenStack 环境。 以上就是 Neutron 两种典型的部署方案,下一节我们开始讨论 Neutron 的各个服务组件。将首先学习 Neutron Server 。

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册