Hadoop运维记录系列(十五)

早期搭建Hadoop集群的时候,在做主机和IP解析的时候,通常的做法是写hosts文件,但是Hadoop集群大了以后做hosts文件很麻烦,每次加新的服务器都需要整个集群重新同步一次hosts文件,另外,如果在同一个域下面做两个集群,做distcp,也需要把两个集群的hosts文件全写完整并完全同步,很麻烦。那么,一劳永逸的办法就是做DNS。DNS我这边已经用了很长时间了,几年前为了学这个还专门买了一本巨厚的BIND手册。

做DNS服务器最常用的就是BIND,ISC开发并维护的开源系统。

以centos6为例,使用BIND 9.8.2,在域名解析服务器上安装bind和域名正反向查询工具

yum install bind bind-utils

安装完成后,配置文件在 /etc/named.conf,域名数据文件通常我们会放在 /var/named,配置文件不是很复杂。留一个小问题,172.16.0.0/18写成子网掩码应该写多少?在该子网内可用的IP地址范围是多少?

/etc/named.conf

//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//

options {
        listen-on port 53 { 172.16.0.2; }; //监听内网地址53端口, ns1要改成172.16.0.1
//      listen-on-v6 port 53 { ::1; }; //不监听IPv6
        directory       "/var/named"; //DNS数据文件存储目录
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query     { 172.16.0.0/18; }; //允许172.16.0.0/18的子网IP主机进行查询,任意主机写any;
        recursion yes; //允许递归查询

        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside auto;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
        type hint;
        file "named.ca";
};

zone "hadoop" IN { //我们的hadoop域
        type master;
        file "hadoop.zone"; 
};

zone "16.172.in-addr.arpa" IN { 
        type master;
        file "172.16.zone"; 
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

然后是正向解析文件 /var/named/hadoop.zone

$TTL 600
$ORIGIN hadoop.
@       IN      SOA     ns1     root ( ;SOA部分必写
        0; Serial
        1D; Refresh
        1H; Retry
        1W; Expire
        3H); Negative Cache TTL

@       IN      NS      ns1.hadoop.
@       IN      NS      ns2.hadoop.
;用两台namenode同时担负nameserver,反正namenode平时也没什么具体事干,DNS查询走udp端口,不会对 namenode造成压力
;另外一个原因是namenode基本不会挂,而DN等服务器比较容易挂,所以NN同时做NS也更稳定,当然,有钱可以单独购置NS服务器,土豪请随意。
;两台namenode一起
ns1             IN      A       172.16.0.1
ns2             IN      A       172.16.0.2

;两台正向解析服务器的A记录,至于A, CNAME, MX等含义不解释了。

namenode-01     IN      A       172.16.0.1
namenode-02     IN      A       172.16.0.2
;服务器的A记录

反向解析文件 /var/named/172.16.zone

反向解析文件里需要把IP地址的顺序倒过来写,例如,172.16.0.1在反向文件里要写成1.0.16.172,所以,文件名命名为16.172.zone更符合规则。

$TTL 600
@ IN SOA namenode-01.hadoop. root.namenode-01.hadoop. ( //SOA部分必写
        0; Serial
        1D; Refresh
        1H; Retry
        1W; Expire
        3H); Negative Cache TTL
; 反向解析文件里不能有$ORIGIN,所以在下面先写上全部主机名
@       IN      NS      ns1.hadoop.
@       IN      NS      ns2.hadoop.

1.0     IN      PTR     ns1.hadoop. 
2.0     IN      PTR     ns2.hadoop.
1.0     IN      PTR     namenode-01.hadoop.
2.0     IN      PTR     namenode-02.hadoop.

全部完成后执行

chkconfig --add named
service named restart

接下来在所有主机的/etc/resolv.conf文件中添加

nameserver 172.16.0.1
nameserver 172.16.0.2

然后删除所有主机中的hosts文件内容,只保留127.0.0.1

用nslookup测试一下

[[email protected] named]# nslookup 
> set q=A
> namenode-02.hadoop
Server:         172.16.0.1
Address:        172.16.0.1#53
#正向查询
Name:   namenode-02.hadoop
Address: 172.16.0.2
> set q=PTR
> 172.16.0.2
Server:         172.16.0.1
Address:        172.16.0.1#53
#反向查询
2.0.16.172.in-addr.arpa name = namenode-02.hadoop.

####然后关闭ns1的DNS服务进行测试。

[[email protected] named]# service named stop
停止 named:.                                              [确定]
[[email protected] named]# nslookup          
> set q=A
> namenode-01.hadoop
Server:         172.16.0.2
Address:        172.16.0.2#53

Name:   namenode-01.hadoop
Address: 172.16.0.1
> set q=PTR
> 172.16.0.1
Server:         172.16.0.2
Address:        172.16.0.2#53

1.0.16.172.in-addr.arpa name = namenode-01.hadoop.

这样,做好了Namenode高可用,也勉强算是做好了DNS的高可用,集群中任意一台Namenode挂机,也不会影响整个集群的正常服务,新买的服务器只需要装好操作系统,在/etc/resolv.conf里面设置两个nameserver的IP地址即可,这就比hosts文件方便多了。

时间: 2024-10-10 16:54:47

Hadoop运维记录系列(十五)的相关文章

Hadoop运维记录系列(十六)

应了一个国内某电信运营商集群恢复的事,集群故障很严重,做了HA的集群Namenode挂掉了.具体过程不详,但是从受害者的只言片语中大概回顾一下历史的片段. Active的namenode元数据硬盘满了,满了,满了...上来第一句话就如雷贯耳. 运维人员发现硬盘满了以后执行了对active namenode的元数据日志执行了 echo "" > edit_xxxx-xxxx...第二句话如五雷轰顶. 然后发现standby没法切换,切换也没用,因为standby的元数据和日志是5月

Hadoop运维记录系列(十四)

周末去了趟外地,受托给某省移动公司做了一下Hadoop集群故障分析和性能调优,把一些问题点记录下来. 该系统用于运营商的信令数据,大约每天1T多数据量,20台Hadoop服务器,赞叹一下运营商乃真土豪,256G内存,32核CPU,却挂了6块2T硬盘.还有10台左右的服务器是64G内存,32核CPU,4~6块硬盘,据用户反馈,跑数据很慢,而且会有失败,重跑一下就好了. 软件环境是RedHat 6.2,CDH Hadoop 4.2.1. 总容量260多TB,已使用200多T. 首先,这硬件配置属于倒

Hadoop运维记录系列(二十四)

从这篇开始记录一下集群迁移的事情 早先因为机房没地方,就已经开始规划集群搬机房的事情,最近终于开始动手了,我会把这次不停机迁移的过程遇到的主要问题和矛盾以及各种解决方法记录下来. 集群规模说大不大,几百台,总容量30PB左右.Hadoop使用CDH 5.5.1加一些自定义patch的rpm打包编译版本. 总的方案是集群不停机,在两个机房之间架设专线,旧机房decommission,拉到新机房recommission.每天不能下线太多机器,要保证计算. 新机房提前架设90台机器,测试带宽.带宽的测

Hadoop运维记录系列(二十三)

最近做集群机房迁移,在旧机房和新机房之间接了根专线,做集群不停机搬迁,也就是跨机房,同时要新加百多台服务器,遇到几个问题,记录一下. 旧集群的机器是centos 6, 新机房加的机器是centos 7. 一.丢包问题 在跨机房的时候,datanode显示很多Slow BlockReceiver的日志 WARN  org.apache.hadoop.hdfs.server.datanode.DataNode: Slow BlockReceiver write packet to mirror to

Hadoop运维记录系列(二十一)

Zeppelin启用https过程和Hack内核以满足客户需求的记录. 原因是这客户很有意思,该客户中国分公司的人为了验证内网安全性,从国外找了一个渗透测试小组对Zeppelin和其他产品进行黑客测试,结果发现Zeppelin主要俩问题,一个是在内网没用https,一个是zeppelin里面可以执行shell命令和python语句.其实这不算大问题,zeppelin本来就是干这个用的.但是渗透小组不了解zeppelin是做什么的,认为即使在内网里,执行shell命令能查看操作系统的一些文件是大问

Linux运维 第二阶段(十五)awk

grep(global researchexpression,文件过滤器,根据模式将匹配到的行显示出来,#grep  [options]  pattern FILE,使用方法详见<shell基础>) sed(stream editor,流编辑器,把每行读到内存空间(模式空间),默认不编辑源文件,仅对模式空间的数据作处理,处理结束将模式空间打印至屏幕,#sed  [options]  'AddressCommand'  file1...) awk(三个人名的首字母a.w.k.,gawk(gnu

python运维开发(二十五)---cmdb开发

内容目录: 浅谈ITIL CMDB介绍 Django自定义用户认证 Restful 规范 资产管理功能开发 浅谈ITIL TIL即IT基础架构库(Information Technology Infrastructure Library, ITIL,信息技术基础架构库)由英国政府部门CCTA(Central Computing and Telecommunications Agency)在20世纪80年代末制订,现由英国商务部OGC(Office of Government Commerce)负

openstack运维实战系列(十二)之nova aggregate资源分组

1. 背景说明    openstack设计时的宗旨是能够为企业提供大规模的云计算服务,包括计算,存储,网络等资源,以服务的形式交付给用户,在一个非常大的环境中,需要将openstack的资源划分,openstack nova支持三种划分的方式:Region区域,Zone空间和Aggregate分组,其中Region是指一个地区或者地域,如可以将中国划分为:华南地区,华中地区,东北地区,西南地区:Zone则可以按照机房的形式来划分,如北京兆维机房为一个Zone,北京鲁谷机房为另外一个Zone:A

自动化运维Saltstack系列(五)之中型Web网站架构设计

架构图