私有云实战
1. 背景互联网的天空两片云，别人家的云，自家的云。微客户、中小企业更倾向于公有云，简单方便、运维成本低；而中大型企业通常是混合云(公有+私有)，那为什么还要部署私有云呢?1. 安全隐私机密数据只有在自家才最安全，使用公有云增加了数据被泄露的风险；2. 可定制化私有云是完全可控的，依据自身业务需求可动态调整架构、开发维护，而目前公有云大多提供的是”标准化”解决方案、企业个性需求难以得到满足；3. 服务质量企业自行部署，监控和运维粒度更细致，对服务质量的把控更到位；4. 成本考量私有云对基础资源充分整合，提高了物理硬件、网络带宽等利用率，长远上可一定程度节约IDC成本。基于种种刚需和”诱惑”，我们也从最初部署的一个实验云，到现今已稳定运行2年、承载数百个游戏业务的多集群自建云，为产品/研发/运维同事提供自助化服务：自助申请http://img.mp.sohu.com/upload/20170708/710b6090569646fcad12a7b97f144495_th.png弹性扩容http://img.mp.sohu.com/upload/20170708/22e49854ffdd48528b85ff0e94952c32_th.png工单管理http://img.mp.sohu.com/upload/20170708/0f32c27426c9488a9f526cc30710b5dc_th.png两年光阴，踩过坑、也吃过亏，还在漫漫云路中折腾前行。本文主要分享了自建云基础架构以及在网络上、磁盘IO上遇到的”有趣事”。2. 私有云架构私有云架构主要取决于企业实际需求，并没有标准答案。通常需要综合考量拓展性、冗余性、灾备性、成本支出等。下图是我司自建云的一些基础架构，仅供参考：总体架构图：http://img.mp.sohu.com/upload/20170708/e5fbd54eeeec4144b151fe9cd8148db7_th.png(1) 部分游戏业务选择公有云(如语音、视频等)，核心平台业务及功能机部署在私有云；(2) 异地多机房，南北集群实现灾备；(3) 香港集群承载部分海外业务。单集群架构图：http://img.mp.sohu.com/upload/20170708/9a8908957d6f4a85bdf94dcba69330cf_th.png(1) 每2组机柜组成1集群（即CG01、CG02），集群扩容也遵循该标准；(2) 单机柜交换机独立，聚合、上联到设备柜的汇聚交换机。网络拓扑图：http://img.mp.sohu.com/upload/20170708/e7dbea3e893a4a0fbd2472709dd9fb31_th.png(1) 每个集群分为两套网络，一个是存储网络，一个是通信网络。每台交换机都有备用交换机，确保故障时可以快速切换；(2) 计算节点和Ceph存储节点共用一台机器，多网卡来区分流量。存储规划图：http://img.mp.sohu.com/upload/20170708/a29de311197641d7bfb261d1727644ed_th.png(1) 网络节点、控制节点系统盘均为raid1(2块盘)，保障安全；(2) 计算节点系统盘同时也作为云OS基础镜像仓库；(3) 计算节点另外2块盘raid0,作为Ceph的OSD节点；(4) 存储网络采用两张千兆网卡绑定来提升吞吐量以及转发包量。完善的架构源于不停衍变，而非一次设计，我们自建云的架构也在不断调整优化。既能支撑现有需求，又具备良好的拓展性、冗余性是我们要努力的方向。3. 那些“有趣的事”3.1 包转发问题私有云上线初期，我们迁移了部分游戏业务上云。晚高峰期，部分玩家反馈游戏卡顿、出现掉线等现象，立即开始排查。排障过程：1、收集报障玩家信息，分析特征：报障玩家归属地、运营商无明显集中，DNS正常，基本排除部分地区网络、DNS问题2、确认游戏服所在机房网络：机房正常、无攻击抖动机房流量环比(昨天)、同比(上周)均正常，无明显波动内外网交换机均检查正常(负载、丢包量等指标)3、Zabbix监控到该游戏服有间接性丢包http://img.mp.sohu.com/upload/20170708/f0b1211eee9a47a5bd1a4a65ccdd2191_th.png初步排查：(1) 游戏服虚拟机 长ping 外网 –> 有丢包(2) 游戏服虚拟机 长ping 内网网关 –> 有丢包(3) 游戏服虚拟机 长ping 同集群其他内网IP –> 正常、无丢包(4) 网络节点外网 长ping 机房网关 –> 正常、无丢包(5) 游戏服宿主机 长ping 网络节点内网IP -> 间接性丢包(6) 检查内网交换机、负载正常，丢包数无异常推断是内网交换机到网络节点该段链路异常，更换内网网线、内网交换机接口后，问题依旧。初步判定是网络节点内网卡问题导致。具体排查：(1) 丢包期间，网络节点内网卡带宽较低，约120Mbps；(2) 包转发量(入向+出向)跑成一条直线，稳定在43W，怀疑达到瓶颈(网卡均已优化网卡队列)http://img.mp.sohu.com/upload/20170708/9d6f3e9d5cb34b34910280c16fbe857e.png针对高配Dell R420单网卡包转发量，压测数据如下：(全小包64KB)http://img.mp.sohu.com/upload/20170708/9008fd714e864f09ad60da4e5cb9e541.png证实的确是网络节点内网卡包转发量导致，但为什么包转发量会超负荷呢？这得从集群的网络通信模式说起。早期集群网络模式(openstack I版 — 非DVR模式)：http://img.mp.sohu.com/upload/20170708/9279a51d4a2548f0abe756a4e9cf582b_th.png(1) 所有计算节点上联内网交换机(2) 计算节点与外网通信流量先经过内网交换机，转发至网络节点内网卡，由网络节点内核路由、通过外网卡转发至公网缺点明显：游戏高峰时，网络节点的内外网卡包转发量会成为瓶颈，导致丢包。游戏业务通常是海量小包，网卡吞吐量不是瓶颈，压力集中在包转发量上。各大云厂商也存在这个瓶颈：(1) 一方面在于网卡虚拟化技术的成熟度，一般损耗不超过物理网卡20%；(2) 另一方面云厂商会针对云主机做资源限制(如网卡转发量限额等)通常可购买”网络增强型”的云主机来提高包转发量限制。解决方案：(1) 改用千兆网卡bonding，有条件可以直接上万M架构；(2) 或采用Openstack – DVR网络模式(J版及以后)，每一台宿主机都直连外网交换机，绕行网络节点，相当于分流。(早期线上部署OpenStack I版,该版不支持DVR)(3) 要记得针对网卡包转发量做监控哦！3.2 浮动IP异常早期的非DVR网络模式，网络节点包转发易成为瓶颈，我们也逐步替换为新网络架构 – DVR网络模式(OpenStack-J版及以后)，分散流量、规避单点瓶颈问题。新架构运行一段时间后，收到运维反馈无法连接至虚拟机。具体表现：(1) 虚拟机TCP/UDP均无法连接，VNC正常；(2) 虚拟机内网通信正常，浮动IP(外网)无法通信(3) 手工重绑浮动IP后恢复；但一段时间后，又多次出现，未彻底解决。理清思路：(1) 新建虚拟机时,脚本会写入IP转发规则到宿主机ip rule表：告知neutron-l3-agent服务内网IP为xxx的虚拟机需转义成公网IP(该过程为绑定浮动IP)(2) 虚拟机绑定浮动IP后，通过本机qrouter-namespace(命名空间)里面的rfp网卡，将流量转发给fip-namespace里面的fpr网卡(见上图)。然后再转发到fg网卡出去。详情见下图：http://img.mp.sohu.com/upload/20170708/586b7eb642fa47a39a4488f3097065d2_th.png(3) 终止虚拟机时，脚本会删除ip rule上该虚拟机对应规则故障分析：(1) 尝试复现故障后，查看宿主机上的ip rule规则#ip netns exec qrouter-e9db756c-0641-4955-9097-75284af1f079 ip -4 rule showStdout: 0: from all lookup local32766: from all lookup main32767: from all lookup default32768: from 10.10.0.83 lookup 1632768: from 10.10.0.163 lookup 1632769: from 10.10.0.105 lookup 1632769: from 10.10.0.176 lookup 1632770: from 10.10.0.138 lookup 1632770: from 10.10.0.189 lookup 1632768: from 10.10.0.111 lookup 16168427521: from 10.10.0.1/24 lookup 168427521并未发现对应虚拟机的ip rule规则(2) 尝试新添ip rule规则(即为虚拟机重新绑定浮动IP)ip -4 rule add from xxx table 16 priority 32772命令解释：-4 表示ip协议rule 路由规则add 添加from 来源xxx ip(必须是内网ip,就是机器网卡eth0上得ip，不是浮动ip)table 16 默认，不要去修改priority xxx 只要小于168427521 大于0，不和现有编号重复。此时虚拟机外网通信恢复，问题临时解决。(3) 为何ip rule规则会凭空消失？虚拟机终止时会删除绑定的浮动IP，即执行命令ip netns exec qrouter-e9db756c-0641-4955-9097-75284af1f079 ip -4 rule del table 16 priority 32768删除规则以priority作为限定条件，当priority重复时只删除第一条规则。如果没有严格保证priority不重复(默认是所属网络命名空间中当前最大priority+1)，则可能出现终止虚拟机 A时，结果虚拟机 B的ip rule被删除。例如原操作为终止10.10.0.163虚拟机，并删除对应ip rule由于priority重复，实际删除了10.10.0.83这条ip rule32768: from 10.10.0.83 lookup 16 #错误地被删除32768: from 10.10.0.163 lookup 16导致内网IP 10.10.0.83的虚拟机外网通信异常。(4)修复方法：修改函数、删除时以内网IP作为限定条件# vi /usr/lib/python2.7/dist-packages/neutron/agent/linux/ip_lib.pydef add(self, ip, table, rule_pr): ip_version = get_ip_version(ip) if not self._exists(ip, ip_version, table, rule_pr): args = ['add', 'from', ip, 'table', table, 'priority', rule_pr] self._as_root(, tuple(args))def delete(self, ip, table, rule_pr): ip_version = get_ip_version(ip) #以下为修改部分 args = ['del', 'from', ip, 'table', table] self._as_root(, tuple(args))即等价于ip -4 rule del from x.x.x.x table 16 #以内网IP为限定条件来删除规则3.3 Ceph与Raid性能对比硬盘有价，数据物价。我们私有云存储是基于Ceph搭建的分布式存储系统，其主要特性是：高扩展性：普通的x86服务器即是一个存储节点，支持PB级别的扩展，平行拓展简单方便；高可靠性：数据拥有多副本，并且可配置副本策略和故障域布局，支持强一致性。无单点，支持故障自检和故障自愈，恢复期间，可以保持正常的数据访问。并行恢复机制极大的降低了恢复时间，提高数据的可靠性和安全性。http://img.mp.sohu.com/upload/20170708/ac94056bfa38424ba5a32924abb44067_th.png高性能：Client和Server直接通信，不需要代理和转发。多个OSD允许同时并发。objects是分布在所有OSD上，OSD负载均衡。Client不需要负责副本的复制(由primary的OSD负责),这降低了Client的网络消耗。抛开这些”贴金”的赞美句，让咱们用实测数据对比ceph和raid10性能差距私有云Ceph存储IO性能测试：http://img.mp.sohu.com/upload/20170708/85c1b7adfff946b19ae7260ded713fda_th.pngCeph存储 VS 阵列卡Raid10 IO对比测试(4 * 600G SAS/15k)IOPShttp://img.mp.sohu.com/upload/20170708/2d0cbec943b842769fa251ccb09b29a9.png吞吐率http://img.mp.sohu.com/upload/20170708/f9fd177500f4438292c65909d05862d8.png测试结果：单机情况下RAID10性能优于Ceph，似乎并不理想。原因分析：仔细分析Ceph原理，我们发现：Ceph的I/O路径：虚拟机 -> 存储网络-> Ceph节点-> 节点磁盘文件系统 -> 节点物理磁盘客户端的每个写操作在Ceph节点中，会产生3-4个磁盘操作：把写操作记录到节点的Journal文件上。把写操作更新到Object对应的文件上。把写操作记录到PG日志文件上。单机Raid10的I/O路径：虚拟机->磁盘文件系统->(Raid卡)->物理磁盘显然Ceph的I/O路径明显长于Raid10,效率低，这也使得单机Ceph性能不如传统RAID10。而Ceph的优势在于它的扩展性，Ceph IOPS、吞吐量与OSD节点数成正相关。当然Ceph节点数越多，对网络带宽要求也越高，条件允许可以部署全万兆存储交换网络。3.4 IO基本优化随着私有云承载业务量剧增，云盘IO问题也凸显出来。高峰时，有运维反馈时不时IO卡顿，排查分析后，我们优化如下：1、设置IO缓存策略：通过物理内存缓存热点数据，以空间换取时间。Libvirt开启disk_cache方法：首先查看qemu-kvm的进程，io缓存模式默认为关闭cache，如需开启，则需修改配置:#vi /etc/nova/nova-compute.confdisk_cachemodes=”file=default,block=none,network=writeback”参数可以设置为 'file'，'block'，'network'，'mount'。其中，file 是针对 file-backend 的disk（比如使用 qcow2 格式的镜像文件），block 是针对块设备的disk（比如使用 cinder volume 或者 lvm），network 是针对通过网络连接的设备的disk（比如 Ceph）。Disk_cachemodes支持以下选项：(Directsync和Unsafe极端，这里不作讨论)http://img.mp.sohu.com/upload/20170708/7190daf097b64623860cece05b4dcc47.png我们的私有云系统盘是放宿主机本地磁盘的，设置file=none；而数据盘使用CEPH因此选择network=writeback。Ceph开启cache方法：# vi /etc/ceph/ceph.confrbd cache = true #开启缓存rbd cache size = 268435456 #缓存大小rbd cache max dirty = 134217728 #缓存中允许脏数据的最大值，用来控制回写大小rbd cache target dirty = 67108864 #开始执行回写过程的脏数据大小rbd cache max dirty age = 5 #缓存中单个脏数据最大的存在时间(1) 如果把rbd cache max dirty设置成0表示只做读缓存(2)设置rbd cache max dirty 非0，表示开启写缓存，Ceph会把写的操作缓存在内存，到时间会排序然后刷进硬盘。(3)rbd cache max dirty age 这个可以设置定时把内存的脏数据写入硬盘防止丢失。如果libvirt设置了writeback模式，不建议该值设置过大长时间留在内存。如果需要可以使用ssd来替代内存缓存。2、IO限速：Ceph集群就犹如一个大磁盘，使用的虚拟机越多，性能也会随之下降。通常情况下是少数几台虚拟机大量、长时间频繁读写拉低了整体Ceph性能。一般通过kvm限速机制进行调控，保障每个虚拟机IOPS。虚拟机磁盘限速方法：#查看虚拟机名称root@nova1:~# virsh list Id Name State---------------------------------------------------- 14 instance-0000002c running 15 instance-0000002a running 16 instance-00000028 running#查看虚拟机上绑定了哪些磁盘root@nova1:~# virsh domblklist 14Target Source------------------------------------------------vda /var/lib/nova/instances/659574e2-b8f8-40dd-8bb4-7f04eb09b006/diskvdb volumes/volume-df1e490b-990b-486a-bdac-658df2daa42a#限速命令，主要控制读写的iopsroot@nova1:~# virsh blkdeviotune instance-00000028 vdb --read-iops-sec 500 --write-iops-sec 300--total-bytes-sec 限制总吞吐率 --read-bytes-sec 限制读吞吐率 --write-bytes-sec 限制写吞吐率--total-iops-sec 限制总的iops--read-iops-sec 限制读的iops--write-iops-sec 限制写的iops4. 结尾私有云在充分整合基础资源、提高利用率的同时，其令人心动的秒级创建、弹性扩容、故障秒级切换等功能也解放了运维老哥的双手。上文是我们自建私有云的一些摸索和实践，希望对大家有借鉴意义。云路漫漫，有你有我。
页:
[1]