zabbix proxy/node 的使用总结教训

这两个的运用场景可以参见官方的这个文档
实际情况是,我们是同机房的不同 vlan 通过 proxy 收集,跨机房的则通过 node 跟目前的 master 并行。proxy 以及 node 的操作都没什么难度。这里跟大家说说我们在拆分 node 的一些教训。

# zabbix_server -n 20 -c /etc/zabbix/zabbix_server.conf
Dropping foreign keys ………………………………………. done.
Converting tables ………………………. done.
Creating foreign keys ………………………………………. done.
Conversion completed successfully.

上面这个如此简洁的 stdout 其实是我们新上的一个 zabbix server 做的 node,item 少的很。但是,当拿一个跑了有大半年的 zabbix server(跟那个新的 zabbix server 跨机房) 做 node 的时候,情况就不是那么美好了。

执行上面这条命令其实执行的是 src/libs/zbxdbhigh/dbschema.c 这个文件里面的 db_schema_fkeys 以及 db_schema_fkeys_drop 里面的 sql 语句。
慎重提醒,如果你的 zabbix 以及跑了很长的时间,像我们,单单 history_uint 表做了 partition 之后还有接近 1亿 的条目。要执行完上面的所有的 sql 语句会花费很长的时间。
之前对这个命令没有很好的理解,以为最多几分钟就能搞定的。结果等了几十分钟还没结束,幸好 zabbix_server 会把 slow query 打印在屏幕上,才能找到原来是上面那个 dbschema.c 文件里面执行的 sql。
另外,下面这条语句也能看到目前的 process:
> select * from information_schema.processlist  where info != 'NULL';

另外,官方说上面那个命令只能执行一遍,中途不能按 ctrl+c 停止,一直等到了最终执行完毕,整个过程持续了 6h+。

zabbix_server [310083]: Warning: slow query: 2965.823846 sec, "update history set itemid=itemid+1001000000000000 where itemid>0"
zabbix_server [310083]: Warning: slow query: 12539.601075 sec, "update history_uint set itemid=itemid+1001000000000000 where itemid>0"

基础设施做的不好,后期的维护成本会相应的变高。付出的人力精力时间也会成倍的增加,并且需要承担更大的风险。因此,这类基础性的设施是越早做越好。

传统产业跟互联网产业的 IT

接触了不少的传统行业,对服务器网络设备以及上面跑的应用程序在传统行业的应用有些了解,跟互联网行业做个对比,谈谈感想。

首先先定义下传统行业主要是指非互联网的行业,包括零售餐饮金融政府机构等等。IT 部门对于传统行业来说可能就是一个单独的小小的部门,包括公司所有 IT 相关的日常维护;对互联网公司来说,包括 se、ops、ne、qa 等职位的统称。

1. 首先说说服务器,这个稍微有点规模的都少不了,不过两个行业的选择差距非常的大:

  • 传统行业更倾向于选择像 IBM,Cisco UCS 这类高端大气上档次的服务器产品,大型机小型机也在其列
  • 互联网行业更愿意选择 DELL、HP 这类,甚至是定制机、组装机这类性价比超高的,价格便宜的机器

2. 接着是网络设备,这个二者的差距不是很大,目前路由交换的高端市场被 Cisco、Juniper 霸占,中低端的是国产国外大混战;而像 (NG)FW、LB、AD 跟前面的情况很类似。二者的区别是:

  • 传统行业更容易选购远超过其实际需求的网络设备产品
  • 互联网行业更能把握目前的业务发展有针对性的进行选择

3. 最后就是上面跑的软件了,以目前很火的 big data 为例:

  • 传统行业虽然不是互联网,但是也清楚数据的重要性,因此,需要对其进行分析处理,因为有这样的需求,也就诞生了像 splunk 这类的公司,他们在传统行业做的很好
  • 但是到了互联网产业,很少有公司愿意使用 Splunk,更多是以 Hadoop,NoSQL 为代表的数据处理保存方案

传统行业,钱多(中字开头的一批)不多(若干中小规模的民营公司)不确定,但是人傻,这里的傻主要是指其公司的 IT 人员的职业素养相对的比较低,包括技术视野水平沟通等方面,而需求却不低于互联网公司,导致的结果就是需要有一类产品来弥补这种缺陷,于是类似 UCS、Splunk 这类"傻瓜式"的产品出现了,他们的共同特点式易于部署易于维护,但是缺点也很明显,花数倍的费用不谈,功能、性能、扩展性、定制化等方面则不能完全满足自身的要求。曾经试用过从刀片机、FCoE 到 Nexus 5000、Nexus 7000 的全套的 UCS 产品,最初的感觉就是强大。后来随着深入的了解,还是发现了不少的问题,比如,一个最基本的需求,既然使用的 UCS 是为了方便我对众多刀片机虚拟机的管理,那么我可不可以将 100 台机器在很短的时间(小于 10s)的更新完 BIOS 重起,在场的工程师都没有能很好的给出答案。

Continue reading

跨机房部署

跨机房的服务部署分两个小问题。第一个是系统(RAID、BIOS、OS) 的部署,另外一个则是 OS 上面的服务的部署。

系统
曾经想通过 dhcp over openvpn 来解决机房的"互联互通"问题,目前暂时仅仅解决了通过 openvpn 进行 lan to lan 的连接,而 over openvpn 的 dhcp(dhcrelay) 到目前为止还不清楚为什么获取不到 IP。

后来看 cobbler 的文档的时候发现可以通过 replicating 实现,这个需要在对端的 IDC 部署一台 cobbler server,由这台机器完成 tftp, dhcp 的功能,而由 central cobbler 实现统一的 system, repo 等配置。
部署起来也很简单。在对端部署一台跟 central cobbler 一样的 cobbler,默认不需要添加任何的 distro 等。该端所有的配置均从 central 拉取,因此需要足够的硬盘空间,尤其要同步 repo:
# cobbler replicate cobbler replicate –master=cobbler.example.org [–distros=pattern] [–profiles=pattern] [–systems=pattern] [–repos-pattern] [–images=pattern] [–prune] [–omit-data]

接下来该建立 RAID 的建立 RAID,该安装系统就安装系统。另外,官方推荐通过 trigger 机制来自动的同步 central 上的数据,这个我后来调研的时候发现并不是很好,如果有多个机房的话,会造成 system 的混乱。因此,暂时还是手动的在对端的 cobbler 上手动的执行一遍 replicating,每次机器上架的时候的才会用到,工作量并不大。

服务
这个相对就比较简单了,如果是通过 tunnel 形成的一个三层结构,那么通过 puppet master 或者类似的 saltstack 就能很轻松的完成,前提是注意 ntp 以及 dns(hosts) 的统一正确。

跨机房的网络通信

这个实现方式有很多种,有条件的可以走光纤专线;没钱的,开 VPN,其中关于 VPN 的实现方式有很多种,这里使用 OpenVPN。由于没有二层的需求,就不考虑使用 TAP(server-bridge) ,这里使用 TUN(server) 设备。
这里,我们把 client/gw 分别部署在 A、B 两 IDC GW 上,即 SNAT 的出口上。

各种复杂情况的组合无外乎下面两种情况的组合叠加:
1. Including multiple machines on the server side when using a routed VPN (dev tun)
这个模式就是我们最普遍使用的模式,科学上网以及一般内网的登录都是使用的该模式

2. Including multiple machines on the client side when using a routed VPN (dev tun) **
这个是让 server 访问 client 后面的机器,需要 client-config-dir 指令来维护路由

这里有个文档,涉及就是上面两种情况的结合,不过是通过普通的家用路由实现的,思路非常的好。而下面,我们会通过更 "纯正" 的方式实现上面的情景。

我们这里有 A、B 两个机房:
A(server): eth0(public), eth1(192.168.1.0/24)
B(client): eth0(public), eth1(10.18.10.0/24)

双方的 vpn 地址在 192.168.4.0/24 里面。

对于 A 的 server.conf 来说,最重要的就是下面几句话:
$ cat /etc/openvpn/server.conf
push "route 192.168.1.0 255.255.255.0"
client-config-dir       /etc/openvpn/ccd

$ cat /etc/openvpn/ccd/B
iroute 10.18.10.0 255.255.255.0

接着就是在 GW 上做 SNAT:
-A INPUT -s 192.168.4.0/24 -j ACCEPT
-A POSTROUTING -s 192.168.4.0/24 -o eth1 -j MASQUERADE

增加到 10.18.10.0/24 的 路由:
# route add -net 10.18.10.0/24 netmask 255.255.255.0 gw tun0

对于 B 来说,client.conf 跟正常的一样,没什么需要特别注意的,接着就是在 netfilter 上添加 SNAT:
-A INPUT -s 192.168.4.0/24 -j ACCEPT
-A POSTROUTING -s 192.168.4.0/24 -o eth1 -j MASQUERADE

最后要注意的是,双方同时开启 ip_forward。理清楚了,就这么简单。

通过 OpenVPN 隧道广播 DHCP

lan-to-lan(AB 两个 IDC) 的 OpenVPN(tun) 网络,A 端的 lan 里面部署有一台 DHCP,想通过隧道广播到 B 端内网里面,这个明显是不可能的,中间需要跨越多个网络。因此可以通过 relay 实现。
在 B 端的 GWb 上部署一台 dhcrelay,将其指向 A lan 的 DHCP,按理来说 B lan 里面的机器这下可以获取到从 A 过来的 relay 了,可是试了几次都没有成功。调试过程中用到了如下的两个工具。

一个是 dhcpdump。还有一个是 dhcping,这个用的比较多,可以模拟做 request:
# dhcping -h 00:12:3f:20:11:49 -s 10.1.200.200 -c 10.1.200.1 -V

或者
# dhcping -s 255.255.255.255 -r -V
在 g 上搜 "dhcp over vpn" 一搜一大把,应该是有不少成功的案例的,我这里为什么获取不到 IP,到目前为止还不清楚,就当抛砖引玉了。