blackpiglet
TA的个人档案
个人介绍
云原生技术爱好者。
擅长的技术
- 高分内容
- 最新动态
- 文章
- 问答
-
发表了文章 2019-01-14
Ceph 监控中应用 Prometheus relabel 功能
1. 问题描述 工作环境中有三个独立的 Ceph 集群，分别负责对象存储、块存储和文件存储。搭建这几个 Ceph 集群时，我对 Ceph 重命名 Cluster name 的难度没有足够的了解，所以使用的都是默认的 cluster name：ceph，不巧的是 Prometheus 的 ceph_exporter 就是用 cluster name 来区分不同集群，结果是 Grafana 中各个集群的数据无法区分，所有的集群数据都绘制在了一个图标中，非常乱不说，而且部分数据还无法正常显示。 也许大家会说，那就改 Ceph cluster name 不就好了。问题是 Ceph 修改 Cluster name 没那么简单，ceph 文件存储目录都是和 Cluster name 有对应关系的，所以很多配置文件和数据都需要修改目录才能生效，对于已经开始正式使用的 Ceph 集群，这么做风险有点大。当然如果给每个 Ceph 集群单独搭建一个 Prometheus 和 Grafana 环境的话，问题也能解决，但这种方式显得太没技术含量了，不到万不得已，实在不想采用。 我最开始想到的解决方式是修改 ceph_exporter，既然 cluster name 不行，那加上 Ceph 的 fsid 总能区分出来了吧，就像这样： 不过 fsid 这个变量很难直观看出来代表的是哪个 Ceph 集群，也不是一个好的方案。 最后多亏 neurodrone，才了解到 Prometheus 的 relabel 功能，可以完美的解决这个问题。 2. relabel 配置 Relabel 的本意其实修改导出 metrics 信息的 label 字段，可以对 metrics 做过滤，删除某些不必要的 metrics，label 重命名等，而且也支持对 label 的值作出修改。 举一个例子，三个集群的 ceph_pool_write_total 的 label cluster 取值都为 ceph。但在 Prometheus 的配置中，他们分别是分属于不通 job 的，我们可以通过对 job 进行 relabel 来修改 cluster label 的指，来完成区分。 # cluster1's metric ceph_pool_write_total{cluster="ceph",pool=".rgw.root"} 4 # cluster2's metric ceph_pool_write_total{cluster="ceph",pool=".rgw.root"} 10 # cluster3's metric ceph_pool_write_total{cluster="ceph",pool=".rgw.root"} 7 具体的配置如下，cluster label 的值就改为了 ceph*，并且导出到了新 label clusters 中。 scrape_configs: - job_name: 'ceph1' relabel_configs: - source_labels: ["cluster"] replacement: "ceph1" action: replace target_label: "clusters" static_configs: - targets: ['ceph1:9128'] labels: alias: ceph1 - job_name: 'ceph2' relabel_configs: - source_labels: ["cluster"] replacement: "ceph2" action: replace target_label: "clusters" static_configs: - targets: ['ceph2:9128'] labels: alias: ceph2 - job_name: 'ceph3' relabel_configs: - source_labels: ["cluster"] replacement: "ceph3" action: replace target_label: "clusters" static_configs: - targets: ['ceph3:9128'] labels: alias: ceph3 修改后的 metric 信息变成这个样子，这样我们就可以区分出不同的 Ceph 集群的数据了。 # cluster1's metric ceph_pool_write_total{clusters="ceph1",pool=".rgw.root"} 4 # cluster2's metric ceph_pool_write_total{clusters="ceph2",pool=".rgw.root"} 10 # cluster3's metric ceph_pool_write_total{clusters="ceph3",pool=".rgw.root"} 7 3. Grafana dashboard 调整 光是修改 Prometheus 的配置还不够，毕竟我们还要在界面上能体现出来，Grafana 的 dashboard 也要做对应的修改，本文使用的 dashboard 是 Ceph - Cluster。 首先是要 dashboard 添加 clusters 变量，在界面上操作即可。先点击 dashboard 的 "settings" 按钮（显示齿轮图标的就是） 如下图所示添加 clusters variable，最后保存。 我们已经可以在 dashboard 上看到新加的 variable 了： 接下来每个图表的查询语句也要做对应的修改： 最终改好的 dashboard json 文件可从如下链接下载到：ceph-cluster.json 4. 参考文档 Prometheus relabel configuration Prometheus relabeling tricks ceph_exporter issue: Can we consider to add "fsid" as a filter variable alongside with "cluster"? Prometheus中的服务发现和relabel
-
发表了文章 2019-01-07
CephFS 常用命令以及问题分析
最近公司的生产环境已经开始使用 CephFS 作为文件系统存储，记录一下使用过程中遇到的问题，已经一些常用的命令。 1. 常用命令 1.1 ceph daemon mds.xxx help ceph daemon 是一个很常用的命令，可以用来查看 Ceph 的各个守护进程的状态，这个 help 命令可以看到 MDS daemon 都支持哪些子命令： $ sudo ceph daemon mds.cephfs-master1 help { "cache status": "show cache status", "config diff": "dump diff of current config and default config", "config diff get": "dump diff get <field>: dump diff of current and default config setting <field>", "config get": "config get <field>: get the config value", "config help": "get config setting schema and descriptions", "config set": "config set <field> <val> [<val> ...]: set a config variable", "config show": "dump current config settings", "dirfrag ls": "List fragments in directory", "dirfrag merge": "De-fragment directory by path", "dirfrag split": "Fragment directory by path", "dump cache": "dump metadata cache (optionally to a file)", "dump loads": "dump metadata loads", "dump tree": "dump metadata cache for subtree", "dump_blocked_ops": "show the blocked ops currently in flight", "dump_historic_ops": "show slowest recent ops", "dump_historic_ops_by_duration": "show slowest recent ops, sorted by op duration", "dump_mempools": "get mempool stats", "dump_ops_in_flight": "show the ops currently in flight", "export dir": "migrate a subtree to named MDS", "flush journal": "Flush the journal to the backing store", "flush_path": "flush an inode (and its dirfrags)", "force_readonly": "Force MDS to read-only mode", "get subtrees": "Return the subtree map", "get_command_descriptions": "list available commands", "git_version": "get git sha1", "help": "list available commands", "log dump": "dump recent log entries to log file", "log flush": "flush log entries to log file", "log reopen": "reopen log file", "objecter_requests": "show in-progress osd requests", "ops": "show the ops currently in flight", "osdmap barrier": "Wait until the MDS has this OSD map epoch", "perf dump": "dump perfcounters value", "perf histogram dump": "dump perf histogram values", "perf histogram schema": "dump perf histogram schema", "perf reset": "perf reset <name>: perf reset all or one perfcounter name", "perf schema": "dump perfcounters schema", "scrub_path": "scrub an inode and output results", "session evict": "Evict a CephFS client", "session ls": "Enumerate connected CephFS clients", "status": "high-level status of MDS", "tag path": "Apply scrub tag recursively", "version": "get ceph version" } 1.2 ceph daemon mds.xxx cache status 这个命令是用来查看 Ceph MDS 缓存的使用情况，默认的配置是使用 1G 内存作为缓存，不过这不是一个固定的上限，实际用量可能突破配置。 $ sudo ceph daemon mds.cephfs-master1 cache status { "pool": { "items": 321121429, "bytes": 25797208658 } } 1.3 ceph mds stat 查看 MDS 组件状态，下面的例子输出的结果表示只有一个 MDS，而且 MDS 已经处于正常工作状态。 $ ceph mds stat cephfs-1/1/1 up {0=cephfs-master1=up:active} 1.4 ceph daemon mds.xxx perf dump mds 查看 MDS 的性能指标。 $ sudo ceph daemon mds.cephfs-master1 perf dump mds { "mds": { "request": 4812776, "reply": 4812772, "reply_latency": { "avgcount": 4812772, "sum": 4018.941028931, "avgtime": 0.000835057 }, "forward": 0, "dir_fetch": 170753, "dir_commit": 3253, "dir_split": 9, "dir_merge": 6, "inode_max": 2147483647, "inodes": 9305913, "inodes_top": 1617338, "inodes_bottom": 7688575, "inodes_pin_tail": 0, "inodes_pinned": 6995430, "inodes_expired": 13937, "inodes_with_caps": 6995443, "caps": 7002958, "subtrees": 2, "traverse": 5076658, "traverse_hit": 4835068, "traverse_forward": 0, "traverse_discover": 0, "traverse_dir_fetch": 91030, "traverse_remote_ino": 0, "traverse_lock": 109, "load_cent": 5356538, "q": 1, "exported": 0, "exported_inodes": 0, "imported": 0, "imported_inodes": 0 } } 1.5 ceph daemon mds.xxx dirfrag ls / 这个命令是用来查看文件系统某个目录下是否有脏数据。 $ sudo ceph daemon mds.cephfs-master1 dirfrag ls / [ { "value": 0, "bits": 0, "str": "0/0" } ] 1.6 该命令是用来查看 CephFS 的 session 连接。 $ sudo ceph daemon mds.cephfs-master1 session ls [ { "id": 9872, "num_leases": 0, "num_caps": 1, "state": "open", "replay_requests": 0, "completed_requests": 0, "reconnecting": false, "inst": "client.9872 192.168.250.1:0/1887245819", "client_metadata": { "entity_id": "k8s.training.cephfs-teamvolume-aaaaaa-pvc", "hostname": "GPU-P100", "kernel_version": "4.9.107-0409107-generic", "root": "/prod/training/cephfs-teamvolume-aaaaaa-pvc" } }, ...... ] 2. 问题分析 2.1 Client cephfs-master1 failing to respond to cache pressure client_id: 9807 正巧是我修改了 MDS cache 之后出现了这个告警，所以一开始怀疑是是不是因为改大了 cache 造成了这个问题，但当我恢复了 cache 的默认值之后，问题依然存在。于是在 Ceph 的邮件列表中搜索类似问题，发现该问题一般都是 inode_max 这个数值设置的不够大造成的，于是查看了一下当前的 inode 和 inode_max 信息： $ sudo ceph daemon mds.cephfs-master1 perf dump mds { "mds": { "request": 404611246, "reply": 404611201, "reply_latency": { "avgcount": 404611201, "sum": 9613563.153437701, "avgtime": 0.023760002 }, ...... "inode_max": 2147483647, "inodes": 3907095, ...... } inodes 远小于 inode_max，所以这里的配置也没有问题。继续搜索发现不只是 inodes 的数量会造成这个问题，已经过期的 inodes 也是有影响的。 $ sudo ceph daemon mds.cephfs-master1 perf dump mds { ...... "inodes_expired": 21999096501, ...... } 果然，inodes_expired 的数值已经非常大了。进一步搜索发现，造成这个问题的主因是 cephfs 不会自动清理过期的 inodes，所以积累时间久了，就容易出现不够用的现象。解决方法如下： $ sudo vim /etc/ceph/ceph.conf …… [client] client_try_dentry_invalidate = false …… $ sudo systemctl restart ceph-mds@cephfs-master1.service 2.2 MDS cache 配置 MDS 目前官方推荐的配置还是单活的，也就是说一个集群内只有一个提供服务的 MDS，虽然 Ceph MDS 性能很高，但毕竟是单点，再加上 MDS 运行的物理机上内存资源还是比较富裕的，自然想到通过使用内存作为缓存来提高 MDS 的性能。但是 MDS 的缓存配置项很多，一时还真不确定应该用哪个选项，而且配置成多大合适也拿不准。 经过进一步的整理后，把缓存配置进一步分解为以下四个小问题。 到底使用哪个选项配置缓存的大小 为什么大部分时间用不到配置的内存量 为什么有时 MDS 占用的内存远大于缓存的配置 应该将缓存配置成多大 2.2.1 到底使用哪个选项配置缓存的大小 相关的配置项主要有两个：mds_cache_size 和 mds_cache_memory_limit，mds_cache_size 是老版本的配置参数，单位是 inode，目前的默认值是 0，表示没有限制；mds_cache_memory_limit 是建议使用的值，单位是 byte，默认值为 1G。所以要调整 cache 大小，当然是要改 mds_cache_memory_limit 。 2.2.2 为什么大部分时间用不到配置的内存量 例如将 mds_cache_memory_limit 配置为 30G（mds_cache_memory_limit = 32212254726），而实际运行时，看到的缓存用量却是这样的： $ sudo ceph daemon mds.cephfs-master1 cache status { "pool": { "items": 321121429, "bytes": 31197237046 } } 虽然差距不大，但为什么总是用不到配置的内存量呢？原因在于这个参数：mds_cache_reservation，这个参数表示 MDS 预留一部分内存，没有具体的作用，就是为了留有余地。当 MDS 开始侵占这部分内存时，系统会自动释放掉超过配额的那部分。 mds_cache_reservation 的默认值是 5%，所以造成了我们看到的现象。 2.2.3 为什么有时 MDS 占用的内存远大于缓存的配置 但有时 MDS 占用的内存又远远大于配置的缓存，这个原因是 mds_cache_memory_limit 并非一个固定死不能突破的上限，程序运行时可能会在特定情况下突破配置的上限，所以建议不要把这个值配置的和系统内存总量太接近。不然有可能会占满整个服务器的内存资源。 2.2.4 应该将缓存配置成多大 官方文档有明确的说明，不推荐大于 64G，这里面的原因主要是 Ceph 的 bug，有很多使用者发现当高于 64g 时，MDS 有较高的概率占用远高于实际配置的内存，目前该 bug 还没有解决。 3. 参考文档 Why ceph status showing cephfs client failing to respond to cache pressure in RHCS MDS CONFIG REFERENCE Understanding MDS Cache Size Limits
-
发表了文章 2018-11-05
Prometheus 对比 Zabbix
公司要上监控，Prometheus 是最热门的监控解决方案，作为喜新厌旧的程序员，我当然是选择跟风了，但上级更倾向于 Zabbix，那没办法，只能好好对比一番，给出几个靠谱的理由了。 但稍稍深入一点，我就体会到，我之前其实并没有真的理解口口相传的 Prometheus 的优点，这次对比虽然是始于无奈，但还是蛮有意义的，正好总结一下自己粗浅的体会。 1. 对比 先对两者的各自特点进行一下对比： Zabbix Prometheus 后端用 C 开发，界面用 PHP 开发，定制化难度很高。 后端用 golang 开发，前端是 Grafana，JSON 编辑即可解决。定制化难度较低。 集群规模上限为 10000 个节点。 支持更大的集群规模，速度也更快。 更适合监控物理机环境。 更适合云环境的监控，对 OpenStack，Kubernetes 有更好的集成。 监控数据存储在关系型数据库内，如 MySQL，很难从现有数据中扩展维度。 监控数据存储在基于时间序列的数据库内，便于对已有数据进行新的聚合。 安装简单，zabbix-server 一个软件包中包括了所有的服务端功能。 安装相对复杂，监控、告警和界面都分属于不同的组件。 图形化界面比较成熟，界面上基本上能完成全部的配置操作。 界面相对较弱，很多配置需要修改配置文件。 发展时间更长，对于很多监控场景，都有现成的解决方案。 2015 年后开始快速发展，但发展时间较短，成熟度不及 Zabbix。 2. 解析 更进一步的分析两者的主要差异： 2.1 图形化还是配置文件 Zabbix 的图形化配置毫无疑问是完爆 Prometheus 的，但这真的是个优势吗？ 细想起来还真未必。图形化确实省去了手动改配置文件和命令行的繁琐，但这种努力毫无疑问是已经做出了需要人工介入的假设。但 Prometheus 是为云原生环境而生的，这种情况下，环境是动态变化的，服务器会随时增减，人工介入不太现实，那么图形化在这种情况下意义就不大了，毕竟要做自动化，那就不必要过图形界面这一道了。这么看来 Prometheus 在图形化方面的简约也是有意的取舍。 2.2 时序数据库还是关系型数据 近几年兴起的监控系统大部分都选择了将数据存储在时序型数据库中，Prometheus 用的就是自研的 TSDB，Zabbix 则用的是 MySQL 或 PostgreSQL。对于时序型数据库我了解不多，粗浅的来看，Prometheus 的时序型数据库在高并发的情况下，读写性能是远高过传统的关系型数据库的，另外还提供了很多内置的基于时间的处理函数，简化数据聚合的难度。也许这不能简单的理解为两种数据库的特性造成的结果，但至少说明，对专门监控场景进行存储优化，是十分必要的。 2.3 服务发现 大家都知道 Prometheus 在收集数据时，采用的 Pull 模型（服务端主动去客户端拉取数据），而以 Zabbix 为代表的传统监控采用的 Push 模型（客户端发送数据给服务端）。Pull 模型在云原生环境中有比较大的优势，原因是分布式系统中，一定是有中心节点知道整个集群信息的，那么通过中心节点就可以完成所有要监控节点的服务发现，去拉取数据就好了；Push 模型倒是省去了服务发现的步骤，但每个被监控的服务都需要内置客户端，还需要配置监控服务端的信息，这加大了部署的难度，Push 模型在 OpenStack 和 Kubernetes 等环境中用的不多。 2.4 开发语言 Golang 和 C 语言的开发对比，这就不用多解释了，不是一个时代的语言，Golang 占绝对优势。PHP 写界面倒是很常规的选择，但无奈 Grafana 写界面都不用编程语言，JSON 和 YAML 就可以搞定。所以真的要做定制开发，Prometheus 的难度要小很多。 3. 总结 Zabbix 的成熟度更高，上手更快，但更好的集成导致灵活性较差，问题更大是，监控数据的复杂度增加后，Zabbix 做进一步定制难度很高，即使做好了定制，也没法利用之前收集到的数据了（关系型数据库造成的问题）。Prometheus 基本上是正相反，上手难度大一些，但由于定制灵活度高，数据也有更多的聚合可能，起步后的使用难度远小于 Zabbix。 比较一番下来，我的建议是，如果是刚刚要上监控系统的话，不用犹豫了，Prometheus 准没错。 但如果已经对传统监控系统有技术积累的话，还是要谨慎考虑：如果监控的是物理机，用 Zabbix 没毛病，或者是环境变动不会很频繁的情况下，Zabbix 也会比 Prometheus 好使；但如果是云环境的话，除非是 Zabbix 玩的非常溜，可以做各种定制，那还是 Prometheus 吧，毕竟人家就是干这个的。 4. 参考文档 What's the difference between Prometheus and Zabbix? Prometheus vs Zabbix Zabbix vs Prometheus What's the difference between Prometheus and Zabbix?
-
发表了文章 2018-09-25
使用 pip 发布 Python 程序
pypi 写过 Python 程序的小伙伴们都知道，需要 import 个非 Python 自带的软件包时，都要用到 pip 这个程序。平时我们都是用 pip，如果我们写好了一个程序，想让大家都能用的到，那么是不是也可以通过 pip 发布出去呢？ 答案当然是可以了，这篇文章我们就来看看如何用 pip 发布一个 python 程序。 1. 环境准备 要用 pip 发布 python 程序，首先当然是要安装 Python 和 pip 这两个软件了，以 Ubuntu 16.04 为例： $ sudo apt update $ sudo apt install -y python python-pip CentOS 和 RedHat 因为 RPM 体系需要依赖于 python，更是默认就安装好了。 另外发布 Pypi，还需要安装一个发布工具，twine，以及其所依赖的 setuptools、wheel： $ sudo pip install --upgrade twine setuptools wheel 好，到这环境就已经就绪了。 2. 注册帐号 pip 上传代码包是最终保存在 https://pypi.org 这个网站上的，所以要用 pip 发布程序，就需要在这个网站上注册一个帐号。 访问该网址进行注册：https://pypi.org/account/register/ pypi 注册后还需要进行邮箱验证，流程和普通网站没有任何区别，所以具体步骤就不在这里详细介绍了。 3. 代码结构 要发布 Python 程序，程序的结构必须符合特定的要求，假设要发布的程序名为 example-pkg，基本的目录结构如下： /example-pkg /example-pkg __init__.py setup.py LICENSE README.md 说一下目录和文件的含义： 首先最外层要建立一个和发出程序同名的文件夹：/example-pkg 该文件夹下还要再简历一个同名文件夹，用来存放程序代码：/example-pkg/example-pkg Python 的老规矩，example-pkg/example-pkg 目录下当然要有一个 __init__.py 文件。 /example-pkg 目录下要有一个叫 setup.py 的文件，如果下载过 Python 代码包，应该都知道这个文件，需要通过这个文件进行 Python 代码的编译（可能会有依赖的其他代码包或者依赖的 C 文件）和安装。 LICENSE 文件：这个文件就是用来保存代码所使用的开源许可证。 README.md：这个是软件行业的惯例了，帮助文档。 对于 setup.py 文件，还有必要好好说说，先贴个例子，下面这个例子中，主要是实现了从 /example-pkg/example-pkg/__init__.py 文件中读取 version 参数，来配置当前软件的版本，并指定了代码包名（name）、作者（author）、邮箱（author_email）、描述信息（long_description、long_description_content_type）、依赖（install_requires），以及哪些文件不会被打包到程序中（exclude_package_data）。 另外需要提醒大家一点，给程序起名字不要带下划线（_），python import 代码包时，是不支持下划线包名的，出现这种情况就比较尴尬，代码装上了，还是用不了。 #!/usr/bin/env python import re import setuptools version = "" with open('example-pkg/__init__.py', 'r') as fd: version = re.search(r'^__version__\s*=\s*[\'"]([^\'"]*)[\'"]', fd.read(), re.MULTILINE).group(1) with open("README.md", "r") as fh: long_description = fh.read() setuptools.setup( name="example-pkg", version=version, author="example", author_email="author@example.com", description="This is the SDK for example.", long_description=long_description, long_description_content_type="text/markdown", url="http://example.com", install_requires=[ 'requests!=2.9.0', 'lxml>=4.2.3', 'monotonic>=1.5', ], packages=setuptools.find_packages(exclude=("test")), classifiers=( "License :: OSI Approved :: MIT License", "Intended Audience :: Developers", "Operating System :: OS Independent", "Programming Language :: Python", "Programming Language :: Python :: 2", "Programming Language :: Python :: 2.6", "Programming Language :: Python :: 2.7", "Programming Language :: Python :: 3", "Programming Language :: Python :: 3.3", "Programming Language :: Python :: 3.4", "Programming Language :: Python :: 3.5" ), exclude_package_data={'': ["example-pkg/test.py", "example-pkg/config.txt"]}, ) 4. 上传和检查 一切准备就绪，下面就可以执行打包命令，产生要上传的代码包了： $ python setup.py sdist bdist_wheel 执行结束后，会产生如下目录和文件： /example-pkg/dist/ example-pkg-0.0.1-py3-none-any.whl example-pkg-0.0.1.tar.gz 包有了，就差上传了，执行第一步中安装的 twine 命令： $ twine upload dist/* Uploading distributions to https://upload.pypi.org/legacy/ Enter your username: <your pypi.org username> Enter your password: <your pypi.org password> Uploading example-pkg-0.0.1-py3-none-any.whl 100%|█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 45.0k/45.0k [00:01<00:00, 24.0kB/s] Uploading example-pkg-0.0.1.tar.gz 100%|█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 43.8k/43.8k [00:00<00:00, 46.2kB/s] 上传完毕！不过这里有一点需要注意，上传新版本后，很可能 pip search 还没法查到版本的更新，这是正常的，我理解是pip search 命令依赖于缓存，所以不会立刻生效。 接下来就让我们下载自己刚刚上传的 python 试试吧： $ pip install example-pkg $ python >>> import example-pkg >>> example-pkg.name 'example-pkg' 最后再补充一点，上传可能会失败，提示无法上传指定的代码包，此时很大的可能是 pypi 中已经有了相同的代码包，所以建议在上传之前，先搜索一下是否有重名的代码包，选择一个不冲突的名字，再上传。 例如下面这个例子，example-pkg 已经存在了，如果要再上传，那当然会失败，换个名字就解决了。 $ pip search example-pkg example-pkg (0.0.7) - A small example package ...... 5. 参考文档 Packaging Python Projects
-
发表了文章 2018-09-25
DNSMasq 域名解析配置
DNSMasq DNSMasq 主要用来解决内网 DNS 域名缓存、DHCP、网络启动和路由通告功能，本文主要是将 DNSMasq 作为内网 DNS 使用。安装环境为 Ubuntu 16.04。 1. 安装 Ubuntu 安装很简单，使用自带的 APT 安装就可以了。 $ sudo apt update $ sudo apt install -y dnsmasq 完成后，需要对配置做些修改： $ sudo cp /etc/dnsmasq.conf /etc/dnsmasq.conf.bak $ sudo vim /etc/dnsmasq.conf .... resolv-file=/etc/resolv.conf strict-order listen-address=<host-ip> addn-hosts=/etc/hosts.dnsmasq 需要在配置文件中新增四行，下面解释一下新增这个四行的含义： resolv-file：从文件读取 DNSMasq 上游的 DNS 服务器配置。 strict-order：resolv-file 文件中如果指定了多个 DNS 服务器，严格安装 DNS 服务器的先后顺序查询域名。 listen-address：监听地址，配置为本机 IP 即可。 addn-hosts：从文件读取本地 DNS 域名和 IP 的对应关系，格式为 <IP> <Domain name>。其实可以把 IP 和域名的对应关系写在 /etc/hosts 文件中，DNSMasq 默认从那里读取，但如果要支持一个域名对应多个 IP，就必须使用 addn-hosts 选项了。 /etc/hosts.dnsmasq 文件内容如下： $ cat /etc/hosts.dnsmasq 10.0.0.1 blackpiglet.com 10.0.0.2 blackpiglet.com 10.0.0.3 blackpiglet.com 修改完成后重启 DNSMasq $ sudo systemctl restart dnsmasq.service 2. resolv.conf 设置 上面提到了 DNSMasq 是从 /etc/resolv.conf 文件中读取上游的 DNS 服务器的，所以可能要修改该文件，但是 Ubuntu 系统里该文件很可能是自动生成的，如果是自动生成的，系统重启，该文件的修改内容无法保存。 $ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 10.0.0.2 nameserver 114.114.114.114 nameserver 127.0.0.1 那么我们该怎么让修改一直有效呢？这个文件是由 resolvconf.service 来负责维护的，我们可以通过修改下面这个文件来达到我们想要的效果： $ cat /etc/resolvconf/resolv.conf.d/head # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 10.0.0.2 nameserver 114.114.114.114 3. 参考文档 dnsmasq安装使用和体验 解决dnsmasq安装好之后主机不能解析其他域名的问题 Dnsmasq 介绍与使用
滑动查看更多
暂无更多信息
-
发表了文章
2019-01-14
Ceph 监控中应用 Prometheus relabel 功能
-
发表了文章
2019-01-07
CephFS 常用命令以及问题分析
-
发表了文章
2018-11-05
Prometheus 对比 Zabbix
-
发表了文章
2017-06-01
ssh无密码登录失败分析
-
发表了文章
2018-03-13
如何使用 Gin 和 Gorm 搭建一个简单的 API 服务 （一）
-
发表了文章
2018-03-14
如何使用 Gin 和 Gorm 搭建一个简单的 API 服务 （二）
-
发表了文章
2018-04-21
Go 装饰器模式在 API 服务程序中的使用
-
发表了文章
2018-06-07
如何在 Kubernetes 环境中搭建 MySQL (二)：在 cloud native 环境下配置 MySQL 的几个关键点
-
发表了文章
2018-07-12
如何在单节点 Ceph 中配置多数据副本
-
发表了文章
2018-07-31
在 Kubernetes中，fluentd 以 sidecar 模式收集日志，并发送至 ElasticSearch
-
发表了文章
2018-09-25
DNSMasq 域名解析配置
-
发表了文章
2018-09-25
使用 pip 发布 Python 程序
滑动查看更多
暂无更多信息