F根服务器浙江镜像节点上线 上网更快更安全

4月29日上午，F根服务器浙江镜像节点上线发布会在杭州举行，中国互联网络信息中心（CNNIC）、浙江省互联网信息办公室、浙江省经济和信息化厅相关领导出席了发布仪式。此次F根服务器浙江镜像节点上线揭开了我国新一轮根镜像引入工作的序幕，杭州也成为继北京之后拥有一台以上根镜像服务器的中国城市。

什么是根镜像服务器

“根镜像服务器”说起来可能比较陌生，但这和大家日常上网却有着莫大的关系，要了解根镜像服务器，首先要了解的是根服务器，根服务器主要用来管理互联网的主目录，全世界IPv4根服务器只有13台（这13台IPv4根域名服务器名字分别为“A”至“M”），由于 历史 原因，中国没有根服务器，而是使用了根镜像服务器。镜像服务器与主服务器的服务内容相同，且能同步更新，简单来说就是和照镜子一样。

互联网中每台计算机都有一个类似于身份z号码的编号，称之为“IP地址”，我们上网依赖的就是这个“IP地址”，不管是根服务器还是根镜像服务器的作用就是解析地址。根服务器就是整个互联网世界的地址登记表，就像我们在现实世界中只有通过地址才能找到朋友的家，虚拟世界里必须通过根服务器才能访问入网的各类网站和设备。

F根服务器浙江镜像节点上线的意义

对于F根服务器浙江镜像节点上线的意义，记者了解到有以下三个作用：

一是完善了我国国家城名服务体系布局。 在此之前，9个根镜像服务器中有8个位于北京，只有1个位于南方地区本次F根镜像服务器上线，优化了根镜像服务器区域配置，并在一定程度上缓解了南方地区根镜像服务器数量严重不足问题。

二是提高国内南方区域的上网体验。 简单来说，华东地区乃至南方地区的网民在上网时，以往需要前往北京F根镜像服务器查询的域名，现在在杭州就可以查询了。从数据上看，已经引入根在所有监测节点上的平均访问速度提高了一倍。所以该镜像服务器上线后，将有效缩短浙江和南方地区用户访问F根的解析响应时间，提高解析成功率，金融、能源、交通等对实时性要求高的行业受益将更加明显。

三是进一步提升我国互联网运行的安全性。 近年来，域名系统等互联网关键信息基础设施面临的安全风险仍较为突出，APT攻击、数据泄露、分布式拒绝服务攻击(DDoS攻击)等问题也较为严重。2018年2月28日，针对GitHub的DDoS攻击达到有史以来的135Tbps。F根服务器浙江镜像节点在浙江的落地，能够分流攻击流量、增强抗攻击能力，提高南方地区DNS安全冗余性，有助于抵御网络攻击、域名劫持和网络瘫痪等网络威胁，提升我国互联网运行的安全性和稳定性。

在公司搭建了elk集群，集群配置如下：

由于m21p22服务器配置比较老旧，而且上面还有其他人部署的其他应用。硬盘写入性能比较差，因此考虑吧elasticsearch部署在另外两台配置高的服务器，而将kibana、redis等与硬盘关系不大的软件部署在m21p22服务器。考虑到部署的复杂性以及服务器的实际情况，选择了redis接收beats的日志数据，再通过logstash实现负载均衡。这是之前elk集群的配置情况。
随着业务的深入，上述集群已经越来越难以满足业务的需要，日志量大会在redis中出现堆积，另外服务器查询量大之后，节点的cpu和load会触发告警。因此，与运维部门商议，又申请了2台服务器，作为elasticsearch的扩展节点，以降低原有服务器的负载。
如下是增加服务器之后的配置信息：

在新增加服务器到位之后，第一件事情就是决定将elasticsearch扩容。每台服务器部署2个节点，将原有集群扩大一倍，由4个节点扩大到8个节点。

原有节点：

扩展节点：

按上述配置对新增节点进行扩展，只需要配置好参数：
discoveryzenpingunicasthosts: ["1921682123", "1921682124","1921682188","1921682189"]
新增节点就可以加入集群进行水平扩容。当上述 *** 作都完成之后，新节点已加入集群，开始同步数据。

考虑到系统并未设置索引分片，全部索引一律采用的是系统默认的5个分片，而每个索引的数据可能大小不一，结果检查，决定将数据量较大的索引，分片数增加一倍。
*** 作如下：

注意，在采取put *** 作时，先采用get *** 作，得到_template信息，之后对需要修改的部分进行增加或者修改 *** 作，之后再进行put。这样保证其他不需要修改的数据不会被修改。

在做完上述这一切之后，已是晚上8点，因此打卡下班。

早上还没到单位，就被同事信息轰炸，elk集群已经不能用了！！
我赶到单位之后，连上服务器一看，新加入的节点全部处于假死状态。已经有大部分数据同步到新节点，而且服务器已无法连接。通知运维人员将elasticsearch进程干掉。
如下是恢复的过程中某个节点假死查到的状态：

对上述节点进行重启，集群状态恢复中。。

redis内存在迅速增加，已经达到10个G

查看logstash日志：

出现如下提示：

原来是宕机节点太多，导致部分节点的主分片未分配。这样日志在写入过程中会超时。这就导致logstash的写入速度下降。从而导致redis中数据增加。

至于节点假死的原因，查看了elasticsearch的日志：

发现一个关键的问题：/opt/elasticsearch/node6/data/nodes/0/indices/NP2tORUfSq6jl0lb5CzOVw/2/translog/translogckp: Too many open files in system
也就是说同时打开的文件数达到了系统的限制，这也就是无法登陆系统的原因。
不难理解上述问题的出现：一个服务器中配置了两个节点，这两个节点都运行在elastic用户下，该用户所在系统的limitconf中对该用户同时打开的文件数有限制。而在集群同步数据的过程中，系统在大量的写文件，同时实时数据又在大量写入。这样就导致文件达到最大的阈值。因此导致elasticsearch假死。

查询elasticsearch节点状态：

当天需要写入数据的索引，也存在部分分片未分配状态：

通过kibana也可发现该问题：

考虑到redis缓存一直增加，当务之急是让数据可以写入。保证redis的数据被消费。否则会出现redis服务器内存溢出。
先不考虑elasticsearch是否能自动恢复，以及自动恢复所花费的时间。
查询API后，要用到命令：reroute
通过kibana分配一个主分片

命令格式参考 >