对机房服务器的整理记录和总结

 

双11过后，当前需要对本公司的所有服务器进行清点整理，便跟着运维一起学习了很多关于这方面的东西，同时自己也做了一些记录。

 

我们当前的机房的整体架构图：

 

 

所有设备，硬件防火墙，核心交换机，接入交换机以及vpn交换机，都采用2个设备，不会存在单点问题，后续会通过zabbix对所有设备进行硬件级故障监控；

 

所有刀片服务器通过接入交换机和核心交换机组成内网，使用192.168.1.*网段，内网之间不走硬件防火墙；

 

如果使用vpn登录，则请求通过“硬件防火墙-核心交换机-接入交换机-vpn交换机”，并虚拟出一个172 IP网段来处理；

 

虚拟化设备均安装ESXi，使用vcenter来对其进行部署： 

 

 

当前的网络拓扑结构：

 

 

 

需要购买外网IP以及域名，并通过DNSPod服务进行配置，从设置的页面来看，其实DNSPod相当于一个外网BIND服务，解析域名至外网IP上。当然所有服务器并不是都存在外网ip地址（外网ip地址有限），但是需要暴露给 DNSPod 以及 加速乐 服务的相关服务器节点，需要提供外网IP。

 

DNS服务中每个网域名称都有自己的一些档案，称为区域档案，是由多条记录组成，每条记录称为Resource Record，在设定DNS名称解析、反向解析以及其他管理目的时，需要使用不同的资源记录，类型主要有：

 

SOA：Start Of Authority，放在zone file一开始的地方，每个档案只能有一个SOA，一定是档案中的第一条记录，描述该zone负责的name server，例如：

 

$TTL 3H
@       IN SOA  @ rname.invalid. (
                                2015092461      ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum

 

 

• NS：Named Server，用来指定另外一个DNS来进行解析；
• A：Address，将DNS域名对应到IPV4的32位地址；
• CNAME：Canonical NAME，可以为同一部主机设置多个别名，设置的多个别名都会连接到同一个服务器，常被用于使用第三方服务，例如使用CDN加速器将图片进行托管等操作；
• MX：Mail eXcharger，设置区域中担任邮件服务器的主机，所有要送往那部服务器的mail都要讲过mai excharger转送。

 

其中部署的BIND服务，就是用于内网域名 -> 内网IP使用的，只有修改了/etc/resolv.conf 的内网服务器才能正常使用，

 

/etc/resolv.conf 配置文件是DNS客户机配置文件，用于设置DNS服务器的IP地址及DNS域名，还包含了主机的域名搜索顺序，该文件是由域名解析器(resolver，一个根据主机名解析IP地址的库）使用的配置文件，格式很简单：

 

nameserver    //定义DNS服务器的IP地址
domain       //定义本地域名
search        //定义域名的搜索列表
sortlist        //对返回的域名进行排序

 

 

其中最主要的是nameserver关键字，如果没有指定nameserver就找不到DNS服务器，nameserver表示解析域名时使用该地址指定的主机为域名服务器，按照文件中出现的顺序来查询的，且只有当第一个nameserver没有反应时才会去查询后续的nameserver，例如：

 

nameserver 192.168.1.xx
nameserver 192.168.1.xx
nameserver 208.67.220.xxx
nameserver 114.114.114.xxx

 

DNS服务由BIND软件提供，启动后服务名为named，管理工具为rndc，debug工具为dig，主要配置文件为/etc/named.conf。

 

虚拟机资源规划分配

 

针对每种不同的应用，也需要将其分配不同的资源，之前来说我们没有一个确定的规划，导致资源浪费非常严重，因此自己稍微总结了一下来作为参考（后续再测试调整）：

 

 

针对测试环境，我们可以将环境独立出来进行部署，例如zookeeper，metaq，redis，以便在资源有限的情况下，最大性地发挥其性能优势。

 

对资源的划分，可以拆分成表格：

 

应用类型	资源估算	说明
nginx	8，4，独占网络	worker_process进行请求分发的进程数取决于cpu核数，占用网络带宽，最好单台实体机中存在一台nginx？
tomcat	4，4	单JVM占用内存2G
redis	4，8	redis单线程模型，及时启用持久化也只会消耗2个内核，占用内存
zookeeper	4，4，网络连接数，磁盘	对磁盘的依赖非常严重，对zk数据状态的变更，都会以事务日志的形式写入磁盘，此外zk还会定时将内存数据库中的所有数据和所有客户端的会话信息记录进行快照
metaq	4，8，磁盘	Message写入速度低容量大的硬盘，对磁盘要求高，数据暂时存在页缓存（需要用到内存）中，到达某个阈值时，flush到磁盘，减少磁盘IO次数
solr	8，8	对于搜索来说，非常消耗CPU，solr JVM堆大小为4G
测试环境-nginx	4，4	单nginx可以随意分发至对应的测试服务中
测试环境-tomcat	4，16	单台测试环境往往部署多个tomcat，比较消耗内存
测试环境-redis	2，4	双核估计就够用了，单核用于服务，另外的负责系统调度+RDB文件生成
测试环境-zookeeper	2，4
测试环境-solr	4，4	测试solr仍然需要提供一定的cpu核数以及内存
测试环境-metaq	2，4	测试zookeeper配置低一点也应该无所谓
灰度环境-tomcat	4，16	灰度环境也需要部署多个tomcat，消耗内存较多
windows压测机	8，16	压测机比较消耗性能，CPU核数一定要跟上
windows监控服务	4，8/16	监测JVM需要使用visualvm，并将所有服务
linux监控服务	4，8	将所有监控服务进行统一部署，例如zabbix，ganglia，redis-stat，node-zk等服务，必要时可以关闭一些监控服务

 

 

降低基础服务配置可帮助我们能够在性能测试中查找出瓶颈点，因此测试环境的基础服务性能可以降低，必要时再将配置提升上去。