2015年12月02日

DNSキャッシュサーバだけでできるローカルゾーンの名前解決

この記事はDNS Advent Calendar 2015 - Qiitaの2日目の記事です。

1日目で構築したUnboundはDNSキャッシュサーバとしての機能のみで
ゾーン情報を保持する権威サーバとしては動作しません。

なので普通に考えると、Unboundだけでは
「この名前でこのIPアドレスに変換させたい」
ということはできません。

ですが、Unboundにはlocal-dataという機能がありまして
「この名前でこのIPアドレスに変換させたい」を実現させることができます。

権威サーバを構築した場合との差は
・そのUnboundサーバに問い合わせした際しか有効でない
・他のDNSサーバに情報伝達することができない
あたりでしょうか。

小規模で簡単に名前解決させたい場合は権威サーバたてるより良いでしょう。

書き方はこんな感じです。これをunbound.confに書きます。
local-data: "host1.local. A 192.168.0.1"
local-data: "host2.local. A 192.168.0.2"
local-data: "host3.local. A 192.168.0.3"

なお、ヤマハルータでも以下のように書くことで同じことができるようです。
ip host host1.local 192.168.0.1
ip host host2.local 192.168.0.2
ip host host3.local 192.168.0.3



posted by maroon at 13:32| Comment(0) | IT_設定関連メモ | このブログの読者になる | 更新情報をチェックする

2015年12月01日

Raspberry PiでつくるDNSキャッシュサーバ

この記事はDNS Advent Calendar 2015 - Qiitaの1日目の記事です。

Raspberry Pi B+にUnboundをインストールして
DNSキャッシュサーバを構築したときの話です。

UnboundはオランダのNLnet Labsにより開発されている
オープンソースのDNSキャッシュサーバです。
BINDと異なり権威サーバの機能は持っておらず、
DNSキャッシュサーバとしてのみ動作します。
シンプルな設計となっていることから、
比較的設定が容易かつ高速で動作します。
デフォルトのconfigでもそれなりに動いてくれますが、
今回はRaspberry Pi B+のスペックに合わせた
チューニングを行いましたので
そのへんの話を中心に書きます。

■事前準備
1.Raspberry Pi B+でRaspbianが起動するようにする
2.コンソールかSSHでログインする
3.Unbound 1.15.1をインストールする
手順はこちら
http://blog.watercloud.net/article/410606733.html

■unbound.conf
unboundの設定ファイルは/etc/unbound/unbound.confになります。
デフォルトのまま使うと色々ゴチャゴチャ書いてあるので、
私は普段は
# cd /etc/unbound/
# mv unbound.conf unbound.conf.orig
として、新たにunbound.confを作成してしまいます。

チューニング前の本当に本当に基本的な設定だけを
している状態のunbound.conf
−−−−−−−−−−−−−−−−−−−−
server:
verbosity: 1
interface: 0.0.0.0
do-ip6: no
access-control: xxx.xxx.xxx.xxx/xx allow
edns-buffer-size: 1280
−−−−−−−−−−−−−−−−−−−−

後半にパフォーマンスに関与する項目を足しました。
−−−−−−−−−−−−−−−−−−−−
server:
verbosity: 1
interface: 0.0.0.0
do-ip6: no
access-control: xxx.xxx.xxx.xxx/xx allow
edns-buffer-size: 1280

#toshi__ya wrote
num-threads: 1
msg-cache-slabs: 1
infra-cache-slabs: 1
key-cache-slabs: 1
so-rcvbuf: 8m
so-sndbuf: 8m
num-queries-per-thread: 1000
outgoing-range: 2000
rrset-cache-size: 512m
msg-cache-size: 256m
−−−−−−−−−−−−−−−−−−−−
それぞれのパラメータの算出基準は
以下の資料を参考にして、
Raspberry Pi B+のスペックを考慮して設定しました。

−−−−−−−−−−−−−−−−−−−−
DNSキャッシュサーバチューニングの勘所
http://www.slideshare.net/hdais/dns-32071366
−−−−−−−−−−−−−−−−−−−−

■パラメータの解説
DNSキャッシュサーバの詳しい動作や考え方などは
上記の資料によくまとまっているので
こちらをご参照いただくとして
それぞれの値の説明をしていきます。

num-threads: 1

これはCPUが1コアなのでワーカースレッドも1です。
複数コア・複数CPUの構成の場合、
コア数のぶんだけワーカースレッドをたてることになります。

msg-cache-slabs: 1
infra-cache-slabs: 1
key-cache-slabs: 1

「スレッド数に近い2のN乗」の値を設定すると
良いとのことですが、なにぶんスレッド数が1なので、
全部1にしました。

so-rcvbuf: 8m
so-sndbuf: 8m

これはUnboundの大規模環境向け設定値が4Mまたは8Mと例示されている
とありますので、それに従って最大の8Mとしています。

num-queries-per-thread: 1000
outgoing-range: 2000

基本的にはメモリが許す限り大きな値に設定するとのことですが
そんなにメモリが潤沢なマシンではないので、
num-queries-per-threadはとりあえずで1000を設定。
outgoing-rangeはnum-queries-per-threadの2倍の値と
することが推奨されているので、1000の倍の2000としました。

rrset-cache-size: 512m
msg-cache-size: 256m

B+はメモリが512MBなのでrrset-cache-size は
フルフルに使えるように512mに設定。
実際はOSなどの動作を考えると使える
メモリ量はもっと少ないはずですが。。
msg-cache-sizeはrrset-cache-sizeの半分が
推奨値なので、256mとしました。

チューニングconfigの解説は上記の通り。
resperfを使って何回かベンチマークとりましたが
1000クエリ/秒の負荷で何回かかけると982qpsまで出たので
このハードウェアスペックを考えると上出来だと思います。
ちなみにこれ以上負荷をかけたらプロセスが死にました。。
posted by maroon at 20:21| Comment(0) | IT_設定関連メモ | このブログの読者になる | 更新情報をチェックする

2015年06月03日

#逸般の誤家庭

先日 #逸般の誤家庭 なるハッシュタグがTwitterを賑わせておりました。
http://togetter.com/li/829532

「逸般の誤家庭」って何でぇ。って話ですが、
簡単に言うと、自宅でサーバ・NW機器等のITインフラを運用していることのようです。
自宅ラッカーとニアリーイコールですね。
(まとめに出てくるアカウントを見る限りイコールだという説も)

ちなみに我が家は滅多に三段料金いかないので
「逸般の誤家庭」ではないと頑なに主張しているわけですが
我が家で運用されているITインフラをご紹介致しましょう。
IMGP5154.jpg

写真右側のNUC2台がESXiホストです。
奥がLANセグメント用。手前がDMZ用です。

なお右端に見えるhpロゴはネットブックで、
今はESXiの仮想マシンを配置するNFSサーバになっています。

左側がネットワーク機器群です。
一番下のが某社のUTMです。ここでPPPoE張ってLANとDMZを分けています。
その上にネットギアのスイッチが2台ありますが
下がLAN用、上がDMZ用です。
奥のバッファローのBBRは無線LAN-APとしてだけ稼働しています。

IMGP5156.jpg
第4世代NUCはDockerホストになっていますが
構築したばかりなのでまだあんまり弄れてません。

我が家は「静音・省電力・メモリは積むがCPUはケチる」がモットーなので
基本的にハイパワーマシンはありません。実家にFortigate400が2台あって
HA構成組めるんですが、うるさすぎて事故案件となりました。。

ちなみにファイルサーバはQNAPのNAS(RAID1)です。
日次で外付けHDDにバックアップとって
月次でAmazon S3にバックアップするようにジョブ組んでます。
QNAPはこのへん楽です。欠陥がないとは言いませんが。

やはりローカルにないといけないサーバというのもありますし
物理マシンでないとできない検証作業というのもありますので
自宅からサーバが完全になくなることは僕の職業柄ないのですが
それでも最近は、クラウドでできる検証作業はクラウドでやってます。

クラウドは専ら「さくらのクラウド」を使っています。
サーバを作って壊してアーカイブしておいて…という感じで
個人的には一番お手軽に検証ができるクラウドなので愛用しています。

今のメイン業務の流れですと、今後はAWSでの検証も増えるかもしれません。
AWS独自のサービスはAWS使わないと検証できませんからね(当たり前)

そんなわけで放置されているオンプレミス環境。。
IMGP5147.jpg
IMGP5148.jpg

いや本当は使いたいんですけどね、富士通のサーバ、固すぎて開かないんですわ。。
NECのタワーはうるさいので常用したくない(もともとは昔の会社で使ってた検証機)
DELLのタワーは仮想マシンが大量に必要になったらまた動かすかもしれません。

まぁ何事も適材適所ということで。
posted by maroon at 21:25| Comment(0) | IT_その他 | このブログの読者になる | 更新情報をチェックする
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。