首页 文章 精选 留言 我的

精选列表

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

Metadata Service 架构详解 - 每天5分钟玩转 OpenStack(165)

下面是 Metadata Service 的架构图,本节我们详细讨论各个组件以及它们之间的关系。 nova-api-metadata nova-api-metadata 是 nova-api 的一个子服务,它是 metadata 的提供者,instance 可以通过 nova-api-metadata 的 REST API 来获取 metadata 信息。nova-api-metadata 运行在控制节点上,服务端口是 8775。 通过进程 ID 13415 查看该启动程序。 我们这个环境是 devstack,nova-api-metadata 的程序名称就是 nova-api,nova-api-metadata 与常规的 nova-api 服务是合并在一起的。不过在 OpenStack 的其他发行版中可能有单独的 nova-api-metadata 进程存在。nova.conf 通过参数 enabled_apis 指定是否启用 nova-api-metadata。 osapi_compute 是常规的 nova-api 服务,metadata 就是 nova-api-metadata 服务。 neutron-metadata-agent nova-api-metadata 在控制节点上,走 OpenStack 内部管理网络,instance 是无法通过 http://controller_ip:8775 直接访问 metadata service 的,因为网络不通。那怎么办呢?答案是:借助 neutron-metadata-agent。neutron-metadata-agent 运行在网络节点上。instance 先将 metadata 请求发给 neutron-metadata-agent,neutron-metadata-agent 再将请求转发到 nova-api-metadata。 这里还有个问题需要解释清楚:instance 如何将请求发送到 neutron-metadata-agent?实际上 instance 是不能直接与 neutron-metadata-agent 通信的,因为 neutron-metadata-agent 也是在 OpenStack 内部管理网络上的。不过好在网络节点上有另外两个组件,dhcp agent 和 l3 agent,它们两兄弟与 instance 可以位于同一 OpenStack network 中,这样就引出了下一个组件: neutron-ns-metadata-proxy。 neutron-ns-metadata-proxy neutron-ns-metadata-proxy 是由 dhcp-agent 或者 l3-agent 创建的,也运行在网络节点。更精确的说法是:运行在网络节点的 namespace 中。如果由 dhcp-agent 创建,neutron-ns-metadata-proxy 就运行在 dhcp-agent 所在的 namespace 中;如果由 l3-agent 创建,neutron-ns-metadata-proxy 就运行在 neutron router 所在的 namespace 中。“neutron-ns-metadata-proxy” 中间的 ns 就是 namespace 的意思。neutron-ns-metadata-proxy 与 neutron-metadata-agent 通过 unix domain socket 直接相连。 这样整个链路就打通了:1. instance 通过 neutron network(Project 网络)将 metadata 请求发送到 neutron-ns-metadata-proxy。2. neutron-ns-metadata-proxy 通过 unix domain socket 将请求发给 neutron-metadata-agent。3. neutron-metadata-agent 通过内部管理网络将请求发送给 nova-api-metadata。可能大家对于 neutron-ns-metadata-proxy 还会有些疑虑:既然 dhcp-agent 和 l3-agent 都可以创建和管理 neutron-ns-metadata-proxy,使用的时候该如何选择呢?简单的说:各有各的使用场景,并且两种方案可以共存。大家不用担心,后面我们会通过例子详细讨论。Metadata Service 的架构已经讨论清楚了,下一节将通过实践加深理解。

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

Troubleshooting OpenStack Bug- 每天5分钟玩转 OpenStack(162)

这是 OpenStack 实施经验分享系列的第 12 篇。 问题描述 客户报告了一个问题:对 instance 执行 migrate 操作,几个小时了一直无法完成,不太正常。 问题分析 遇到这种情况,第一个要检查的就是 instance 所在计算节点的 nova-compute.log 日志,但不幸的是没有发现相关的错误。 如果 nova-compute 没有错误,那更底层的 hypervisor 有相关报错吗? 打开 /var/log/libvirt/libvirtd.log,这里我们发现了一些线索: 上面的 log 告诉我们:没有找到 instance swap 对应 image backing file /var/lib/nova/instances/_base/swap_8192。 当前这个 instance 确实使用了一个 8192M 的 swap disk,但奇怪的是:正在使用的 image backing file 为什么会不见了呢? 在排除了人为误删后,怀疑是一个 bug。搜索一下: 运气不错,第三个结果是 OpenStack 的 bug,好像就是我们要找的。 浏览 bug 信息发现描述的现象跟我们的情况一样,而且在客户使用的 kilo 版本上已经有 fix。 点击 commit 链接,可以看到 fix 都修改了哪些文件。 对照客户系统中的代码,确实没有包含该 fix,也印证了确实是这个 bug。 解决问题 因为 fix 的文件位于 nova 目录,可见这是 nova 模块的 bug。 接下来的工作就很直接了: 下载 nova 的代码。 安装 kilo 的最新版本。 重启所有 nova-* 服务。 关于如何更新 OpenStack 组件,请参考上一节的方法。 下节教大家如何快速安全地给 instance 做快照。

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

- 每天5分钟玩转 OpenStack(161)

这是 OpenStack 实施经验分享系列的第 11 篇。 本节教大家更新 OpenStack 组件的方法。请注意,是更新(Update)而不是升级(Upgrade)。更新是给组件打补丁,版本不变;而升级是刷新版本,比如从 kilo 升级到 liberty。 更新真的有必要吗? 对于已经部署好的 OpenStack,我们有更新某个组件的需求吗? 答案是:有! OpenStack 是软件,是软件就会有 bug。 OpenStack 包含了很多组件,结构很松散,每个组件可以单独更新,只要保证各个组件都属于同一个大版本(比如 kilo, liberty)就不会有问题。 当我们遇到了 bug,如果社区已经有 fix,只需要更新包含该 fix 的组件就可以了,其他组件保持不变。 下面以 nova 组件为例演示如何更新。 假设目前部署的 OpenStack 是 kilo,现在发现了一个 bug,需要升级,最简单的办法是升级到 nova 在 kilo 里的最新版本,步骤如下: 从 github clone nova。 切换到 kilo 的最新版本。 安装 nova python 源码。 重启所有 nova-* 服务。 从 github clone nova OpenStack 的所以代码都是在 github 上维护的,每个模块有自己的 repository. nova 的 repository 在https://github.com/openstack/nova 点击 “Branches”,可以看到 nova 最近的几个版本。 咦,怎么没有 kilo? 别着急,点击 “Tags”。 这里有 kilo-eol,"eol" 表示 “end of life”,意味着 nova 对于 kilo 不在更新了,是 kilo 的最终版本。如果要更新 kilo 上的 nova,用这个版本就行了。 通过 git clone 命令下载 nova,下载链接如下: 运行命令: git clonehttps://github.com/openstack/nova.git 切换到 kilo 的最新版本 下载完成后,查看当前的 branch 为 master: 切换到 kilo-eol: 确认目前已经是 kilo-eol 了: 安装 nova python 源码 OpenStack 用 python 开发,更新版本很简单,只需要通过 pip 命令安装新版本的源代码就行了,没有编译等步骤。 在 nova 目录下执行如下命令: pip install . nova 已经从 nova-2015.1.3.dev1 更新到 nova-2015.1.4 了。 重启所有 nova-* 服务 所有运行了 nova-* 服务的节点(控制节点和计算节点)都需要更新源代码并重启服务,最简单的方法是重启整个节点。 至此,nova 组件更新完成。下节我们将再分享一个 troubleshooting 的案例。

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

动态添加删除网卡 - 每天5分钟玩转 OpenStack(156)

这是 OpenStack 实施经验分享系列的第 6 篇。 在项目实施过程中,经常会有添加删除网卡的需求。比如一个运行数据库的 instance,初始只有一个网卡,数据库服务和备份共用这块网卡,后来为提高性能以及合规的要求需要加一块网卡专门做备份用。长久以来,Horizon 界面只支持在部署时为 instance 配置网卡,事后添加删除网卡只能用命令行,本节就来演示这个操作。 添加网卡 我们现在有一个 instance “c1”,有一块 vlan111 的网卡,IP 为 17.17.111.5。 当前有两个 vlan 网络 “vlan111” 和 “vlan112”。 执行命令nova interface-attach为 “c1” 添加一块 “vlan112” 的网卡,分配到的 IP 为 17.17.112.9。 在 instance 的控制台中可以看到新网卡为 eth1,但没有获取到 IP。 其原因是当前操作系统中还没有 eth1 的配置,编辑 /etc/network/interfaces 添加 eth1。 然后执行ifup eth1启用该网卡,这次 17.17.112.9 的 IP 就获取到了。 删除网卡 下面演示如何删除网卡,用到的命令是: nova interface-detach <server>用来指定 instance。 <port_id>是要删除网卡对应的 port。 可以通过neutron port-list查看 port 信息。 比如我们要删除 IP 为 17.17.111.5 的这个网卡,命令如下: instance 控制台中看到 eth0 已经没有了,只剩下 eth1。 在 horizon 中操作 Horizon 在 Newton 版本中加入了添加删除网卡的操作。instance 的操作列表中可以看到 “Attach Interface” 和 “Detach Interface”。 添加网卡,只需在下拉列表中选择网卡所属的网络。 删除网卡也很简单,直接选择网卡对应的 port。 GUI 总是跟随 CLI 的,我们期待 horizon 在新版本中加入更多实用的操作。 下一节我们将讨论另一个常见的网络操作场景:为 instance 配置静态 IP。

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

定制 cloud-init - 每天5分钟玩转 OpenStack(155)

这是 OpenStack 实施经验分享系列的第 5 篇。 对于 Linux 镜像,cloud-init 负责 instance 的初始化工作。cloud-init 功能很强大,能做很多事情,而且我们可以通过修改配置文件灵活定制 cloud-init。 cloud-init 的配置文件为 /etc/cloud/cloud.cfg,这里举几个应用场景: 1. 如果希望 root 能够直接登录 instance(默认不允许 root 登录),设置: disable_root: 0 2. 如果希望能以 ssh passwod 方式登录(默认只能通过 private key 登录),设置: ssh_pwauth: 1 3. 如果希望能够修改 instance 的 hostname(默认 instance 每次重启后 cloud-init 都会重新将 hostname 恢复成初始值),将cloud_init_modules列表中下面两项删除或注释掉: - set_hostname- update_hostname instance 每次启动 cloud-init 都会执行初始化工作,如果希望改变所有 instance 的初始化行为,则修改镜像的 /etc/cloud/cloud.cfg 文件;如果只想改变某个 instance 的初始化行为,直接修改 instance 的 /etc/cloud/cloud.cfg。cloud-init 有很多选项,这里只列举了几种常见的定制化场景,作用是给到大家一个重要的思路:可通过 cloud-init 改变 instance 的初始化行为。更多信息请参考官网https://cloud-init.io/下一节我们讨论配置 instance 虚拟网卡的相关技巧。

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

制作 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。

资源下载

更多资源
Mario

Mario

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

腾讯云软件源

腾讯云软件源

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

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册