2013年9月1日日曜日

DNSスレーブを構築してみる(CentOS6.4+Bind9.8)

前回のDNSサーバ(CentOS6.4+Bind9.8)の構築の続き。

スレーブサーバを立ててみる。とはいっても簡単そう。
・前回構築したsvr1をマスター
・svr2にスレーブを構築する
を想定。

1.パッケージをインストールする

# yum -y install bind bind-utils bind-chroot

2.設定をコピー&変更する


以下のファイルをsvr1からコピーする

・/etc/sysconfig/named
・/etc/named.conf
・/etc/named.rfc1912.zones
・/etc/named/named.root.hints
・/etc/named/named.local.hayachi617.com.zone

上記のゾーンファイルを一部修正する(いらないかもしれないけど)

# vi /etc/named/named.local.hayachi617.com.zone
>>
zone "hayachi617.com" {
                type slave;
                masters { 192.168.0.49;};
                file "hayachi617.com.slave.db";
};

zone "0.168.192.in-addr.arpa" {
                type slave;
                masters { 192.168.0.49;};
                file "0.168.192.in-addr.arpa.slave.db";
};
<<

3.chroot対応として、rsyslogの設定変更(変更分を記載)

# vi /etc/rsyslog.conf
>>
$AddUnixListenSocket /var/named/chroot/dev/log
<<
# service rsyslog reload

4.サービスの起動

ここまでで設定は一通り完了しているはずなので、サービスを起動してみる。

# chkconfig named on

# service named start

ちなみに、svr1の時と同じくchroot設定が有効か?チェックしてみると、同じだった。

# df -ha

Filesystem            Size  Used Avail Use% マウント位置
/dev/mapper/VolGroup-lv_root
                      8.5G  3.0G  5.1G  37% /
proc                     0     0     0   -  /proc
sysfs                    0     0     0   -  /sys
devpts                   0     0     0   -  /dev/pts
tmpfs                 935M     0  935M   0% /dev/shm
/dev/sda1             485M   32M  428M   7% /boot
none                     0     0     0   -  /proc/sys/fs/binfmt_misc
/etc/named            8.5G  3.0G  5.1G  37% /var/named/chroot/etc/named
/var/named            8.5G  3.0G  5.1G  37% /var/named/chroot/var/named
/etc/named.conf       8.5G  3.0G  5.1G  37% /var/named/chroot/etc/named.conf
/etc/named.rfc1912.zones
                      8.5G  3.0G  5.1G  37% /var/named/chroot/etc/named.rfc1912.zones
/etc/rndc.key         8.5G  3.0G  5.1G  37% /var/named/chroot/etc/rndc.key
/usr/lib64/bind       8.5G  3.0G  5.1G  37% /var/named/chroot/usr/lib64/bind
/etc/named.iscdlv.key
                      8.5G  3.0G  5.1G  37% /var/named/chroot/etc/named.iscdlv.key
/etc/named.root.key   8.5G  3.0G  5.1G  37% /var/named/chroot/etc/named.root.key


5.その他の設定

ルートヒントの情報を更新しておく。

# dig @a.root-servers.net . ns > /var/named/named.ca

設定再読み込みで完了。

# service named reload

最後に確認をする。

# dig @192.168.0.50 router.hayachi617.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 <<>> @192.168.0.50 router.hayachi617.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47164
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;router.hayachi617.com.         IN      A

;; Query time: 0 msec
;; SERVER: 192.168.0.50#53(192.168.0.50)
;; WHEN: Sun Sep  1 12:03:02 2013
;; MSG SIZE  rcvd: 39

これにて終了。




DNSを構築してみる(CentOS6.4+Bind9.8)

自宅に仮想環境でたくさんOSを立て始めたので、DNSサーバを立ててみた。
やる内容は
 ・環境は、Hyper-V上で構築したCentOS6.4上に、BIND 9.8を使う。
 ・内部のネットワーク向けのDNSサーバ(公開はしない)
 ・IPv4のみを使う(IPv6は使わない)
 ・折角なので、キャッシュサーバ機能を持たせてみる
 ・折角なので、chroot環境にしてみる
を目的とする。

1.パッケージをインストールする

# yum -y install bind bind-utils bind-chroot caching-nameserver

としたところ、caching-nameserverについては、

Package 32:bind-9.8.2-0.17.rc1.el6_4.6.x86_64 already installed and latest version

というメッセージがでてインストールできないようです。bindに統合されたということ
ですかね。ここにも記載が。


2.設定変更する

# vi /etc/sysconfig/named ※全記載
>>
ROOTDIR=/var/named/chroot
OPTIONS="-4"
<<

この"-4"はIPv4のみ有効にしてbindを起動するという指定です(IPv6の無効化)。

# vi /etc/named.conf ※全記載
>>

options {
//      リスンするIPアドレスを指定する。指定なしの場合は全てのIPでリスンする
//      listen-on port 53 { 127.0.0.1; };
//      listen-on-v6 port 53 { ::1; };

        directory       "/var/named";
        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     { localhost; };
        allow-query             { localnets; };
        allow-query-cache       { localnets; };

//      不要なエラーを省く
        empty-zones-enable no;

//      IPv6を無効化するのでポートは閉鎖
        use-v6-udp-ports { };

//      再帰的問い合わせはデフォルト無効化
//      recursion yes;
        recursion no;

//      DNS SECを無効化する
//      dnssec-enable yes;
//      dnssec-validation yes;
        dnssec-enable no;
        dnssec-validation no;

        dnssec-lookaside auto;

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

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

//      forward先の設定
        forwarders {
                192.168.0.1;
        };
};

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

//viewを使っている場合は、zoneはview内で記載する必要がある
//zone "." IN {
//      type hint;
//      file "named.ca";
//};
//include "/etc/named.rfc1912.zones";

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

//DNSキャッシュサーバ用設定
view localhost_resolver {
        match-clients      { localhost; };
        match-destinations { localhost; };
        recursion yes;
        include "/etc/named.rfc1912.zones";
        include "/etc/named/named.local.hayachi617.com.zone";
};

//LAN用設定
view "internal" {
        match-clients { localnets; };
        match-destinations { localnets; };
        recursion yes;
        include "/etc/named.root.hints";
        include "/etc/named/named.local.hayachi617.com.zone";
};

<<

# vi /etc/named.rfc1912.zones ※変更分を記載
>>


#IPv6は使わないので、コメントアウト
#zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
#       type master;
#       file "named.loopback";
#       allow-update { none; };
#};

<<

ゾーンファイルを作成する
# vi /etc/named.local.hayachi617.com.zone ※全記載
>>
zone "hayachi617.com" {
                type master;
                file "hayachi617.com.db";
};

zone "0.168.192.in-addr.arpa" {
                type master;
                file "0.168.192.in-addr.arpa.db";
};
<<

正引きのゾーンファイルの作成
# vi /var/named/hayachi617.com.db ※全記載
>>
$TTL            86400
@               IN      SOA     ns.hayachi617.com.   root.hayachi617.com.(
                                2013083101     ; Serial
                                28800             ; Refresh
                                14400             ; Retry
                                3600000          ; Expire
                                86400 )           ; Minimum

                 IN      NS      ns.hayachi617.com.
router         IN      A       192.168.0.1
ns              IN      A       192.168.0.49
svr2           IN      A       192.168.0.50
svr3           IN      A       192.168.0.51
svr4           IN      A       192.168.0.52

svr1           IN      CNAME   ns
www           IN      CNAME   svr2
ntp             IN      CNAME   svr1
<<

逆引きのゾーンファイルの作成
# vi /var/named/0.168.192.in-addr.arpa.db ※全記載
>>
$TTL    86400
@       IN      SOA     ns.hayachi617.com.   root.hayachi617.com.(
                        2013083101   ; Serial
                        28800        ; Refresh
                        14400        ; Retry
                        3600000      ; Expire
                        86400 )      ; Minimum

        IN      NS      ns.hayachi617.com.
        IN      PTR     hayachi617.com.
        IN      A       255.255.255.0

1       IN      PTR     router.hayachi617.com.
49      IN      PTR     svr1.hayachi617.com.
50      IN      PTR     svr2.hayachi617.com.
51      IN      PTR     svr3.hayachi617.com.
52      IN      PTR     svr4.hayachi617.com.
<<

3.chroot対応として、rsyslogの設定変更(変更分を記載)

# vi /etc/rsyslog.conf
>>
$AddUnixListenSocket /var/named/chroot/dev/log
<<
# service rsyslog reload

4.サービスの起動

ここまでで設定は一通り完了しているはずなので、サービスを起動してみる。

# chkconfig named on

# service named start

ちなみに、chroot設定が有効か?チェックしてみると、

# df -ha

Filesystem            Size  Used Avail Use% マウント位置
/dev/mapper/VolGroup-lv_root
                      8.5G  2.8G  5.3G  35% /
proc                     0     0     0   -  /proc
sysfs                    0     0     0   -  /sys
devpts                   0     0     0   -  /dev/pts
tmpfs                 2.9G     0  2.9G   0% /dev/shm
/dev/sda1             485M   47M  414M  11% /boot
none                     0     0     0   -  /proc/sys/fs/binfmt_misc
/etc/named            8.5G  2.8G  5.3G  35% /var/named/chroot/etc/named
/var/named            8.5G  2.8G  5.3G  35% /var/named/chroot/var/named
/etc/named.conf       8.5G  2.8G  5.3G  35% /var/named/chroot/etc/named.conf
/etc/named.rfc1912.zones
                      8.5G  2.8G  5.3G  35% /var/named/chroot/etc/named.rfc1912.zones
/etc/rndc.key         8.5G  2.8G  5.3G  35% /var/named/chroot/etc/rndc.key
/usr/lib64/bind       8.5G  2.8G  5.3G  35% /var/named/chroot/usr/lib64/bind
/etc/named.iscdlv.key
                      8.5G  2.8G  5.3G  35% /var/named/chroot/etc/named.iscdlv.key
/etc/named.root.key   8.5G  2.8G  5.3G  35% /var/named/chroot/etc/named.root.key


となっており、いくつかのファイルやディレクトリがchroot下にマップされていることがわかる。

5.その他の設定

ルートヒントの情報を更新しておく。

# dig @a.root-servers.net . ns > /var/named/named.ca

設定再読み込みで完了。

# servivce named reload

最後に確認をする。

# dig router.hayachi617.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 <<>> router.hayachi617.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7432
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;router.hayachi617.com.         IN      A

;; ANSWER SECTION:
router.hayachi617.com.  86400   IN      A       192.168.0.1

;; AUTHORITY SECTION:
hayachi617.com.         86400   IN      NS      ns.hayachi617.com.

;; ADDITIONAL SECTION:
ns.hayachi617.com.      86400   IN      A       192.168.0.49

;; Query time: 0 msec
;; SERVER: 192.168.0.49#53(192.168.0.49)
;; WHEN: Sun Sep  1 07:38:59 2013
;; MSG SIZE  rcvd: 88

これにて終了。

6.外のDNS問い合わせが遅い

その後外向けのDNS解決が遅いことに気が付いた。
ということで、fowardersを、ISPのDNSに変更をしてみたところ速くなった。
よかった。


(2014/6/29)
オプションの説明を補足と、もう少しセキュアに構築するよう変更。

2013年7月20日土曜日

待ち行列モデルとストレージ性能のあれこれ

お仕事の1つにストレージの設計・管理をやってます。で、性能調査をすることがあって、今一度パフォーマンスの整理をしてみたので、忘れないうちにメモメモ

大学時代にやった記憶がある待ち行列理論がでてきて、、懐かしい・・というより頭痛?
勉強って役に立つんだねぇ~(あるあるネタですね)。

まだまだこれからですが、とりあえず。

・ResponseTime = QueueLength × Service time

 そのストレージの中では、
  ResponseTime → ストレージ(のコントローラ)に入ってきてから、出ていくまでの時間
   QueueLength    → ストレージのコントローラで待ち行列に入っている数
   Service time  → ストレージ内部での処理時間
 となるとのこと。

 これはM/M/1モデルの
  Tw = Ts * ρ/ (1−ρ)
  Lw = ρ/ (1−ρ)
   ・Tw:待ち時間の平均 (ResponseTime)
   ・Lw:待ち行列の長さ    (QueuLength)
   ・Ts:平均サービス時間 (ServiceTime)
 の考えですね。へー、へー、なんか実感。

・ServiceTime = Utlization ÷ Throughput(IOPS)
 ※ Utlization × (1 ÷ Throughput)のほうがしっくりくるのかな?

 そのストレージの中では、
  Utilization   → コントローラのCPU使用率
   Throughput  → ストレージのスループット(1秒間あたりに捌くIOの数)
 となりそう(確認中)。


 随時更新していこう。

そのなもウタマロ(洗濯石鹸)

TVで紹介してた、なんか洗濯のもので、首回りなど汗、シミの汚れが落ちるらしい。その名も
ウタマロ!

http://www.e-utamaro.com/shop

このページもちょっとレトロ感があっていい感じ。

で、なんと近くのドラッグストアで売ってたので、衝動買い^^; 本当にきれいになるのかな?
いつかためそー(いまでしょっ!夏)

tips:Redhat/CentOSでのJumboFrame対応

RedhatやCentOS環境でiSCSIをつかっているので、JumboFrameに関する備忘録を記載。

■MTUの設定(CentOS/RHEL)

一時的に設定するなら、

# ifconfig [DEV] mtu 9000

恒久的に変えるなら、

# vi /etc/sysconfig/network-scripts/ifcfg-[DEV]

>>
MTU=9000
<<

でインターフェースを再起動。

# ifconfig [DEV]

でMTUを確認し表示されればOKです。


■tcpdumpでjumboframeをキャプチャするには

# tcpdump -i eth0 -s 9014 -B 9 host x.x.x.x -w /tmp/test.pcap

上記は
 ・インターフェース eth0で行われている (-i)
 ・通信の宛先が x.x.x.xの(host)
 ・size 9014以下のpacket(-s)
 ・デフォルトではバッファ制約により8138 Bytesまでしかキャプチャができないため、
  9014 Bytesまでキャプチャができるよう拡張(-B)
 ・収集したパケットデータを/tmp/test.pcapに保存(-w)
の例です。


ネットワーク経路でJumboフレームが通るか?確認

pingでフレームが分割されずに通るか?の確認です。

# ping -s 8972 -d [相手先] -M do -c 5

NGの場合は、、

PING [相手先](x.x.x.x) 8972(9000) bytes of data.
From [相手先] (x.x.x.x) icmp_seq=1 Frag needed and DF set (mtu = 1500)

OKの場合は、、

PING [相手先] (x.x.x.x) 8972(9000) bytes of data.
8980 bytes from [相手先] (x.x.x.x): icmp_seq=1 ttl=128 time=2.41 ms



※8972bytesはJumboframeのパケットサイズ9000bytesから、IPヘッダサイズ20bytes+ICMPヘッダサイズ8bytesを引いたもの。

※8980 bytesは、8972(指定)+ICMPヘッダサイズ(8Bytes) = 8090 Bytesのこと。



tips:vmware(vsphere4)でのJumboFrame対応

VMware(vpshere4でのみ確認)環境でiSCSIをつかっているので、JumboFrameに関する備忘録を記載。

今回は、esxiにコンソールログイン(もしくはsshログイン)して、確認する方法を記載
(設定はマニュアル見てGUIで)

■VMware本体(VMkernel)で使うiSCSI NICのMTU設定の確認

esxcfg-vmknic -l

Interface Port Group/DVPort IP Family IP Address Netmask Broadcast MAC Address MTU TSO MSS Enabled Type
vmk0 Service Console IPv4 x.x.x.x 255.255.255.0 x.x.x.x xx:xx:xx:xx:xx:xx 1500 65535 true STATIC
vmk1 VMotion IPv4 x.x.x.x 255.255.255.0 x.x.x.x xx:xx:xx:xx:xx:xx 1500 65535 true STATIC
vmk2 iscsi1 IPv4 x.x.x.x 255.255.255.0 x.x.x.x xx:xx:xx:xx:xx:xx 9000 65535 true STATIC

※上記の例では、vmk2というインターフェースのMTUが9000に設定されている。

■VMware本体(VMkernel)で使うiSCSI NICの仮想スイッチのMTU設定の確認

# esxcfg-vswitch -l

Switch Name Num Ports Used Ports Configured Ports MTU Uplinks
vSwitch0 128 5 128 1500 vmnic0,vmnic2

PortGroup Name        VLAN ID  Used Ports  Uplinks
  VMotion               135      1           vmnic2,vmnic0
  Service Console       125      1           vmnic0,vmnic2
Switch Name Num Ports Used Ports Configured Ports MTU Uplinks
Backup 128 4 128 1500 vmnic1

PortGroup Name        VLAN ID  Used Ports  Uplinks
  Backup                0        2           vmnic1
Switch Name Num Ports Used Ports Configured Ports MTU Uplinks
iSCSI 128 9 128 9000 vmnic6,vmnic7,vmnic10,vmnic11

PortGroup Name        VLAN ID  Used Ports  Uplinks
   ・
   ・
   ・

※上記の場合、iSCSIという仮想スイッチのMTUは9000Bytesになっている(つまりJumboFrame対応になっている)

※上記NICと仮想スイッチ両方がJumboFrame向け設定が必要となる。


■ネットワーク経路でJumboフレームが通るか?確認

# vmkping -s 8972 -d [相手先] 

  -s  : パケットサイズ
  -d  : Set Don't Fragment flag(IPv4)

NGの場合は、、

PING [相手先] (x.x.x.x): 8972 data bytes
sendto() failed (Message too long)

OKの場合は、、

PING [相手先] (x.x.x.x): 8972 data bytes
8980 bytes from x.x.x.x: icmp_seq=0 ttl=128 time=0.501 ms


※8972bytesはJumboframeのパケットサイズ9000bytesから、IPヘッダサイズ20bytes+ICMPヘッダサイズ8bytesを引いたもの。

※8980 bytesは、8972(指定)+ICMPヘッダサイズ(8Bytes) = 8090 Bytesのこと。

■tcpdumpでjumboframeをキャプチャするには

esxiにはtcpdumpの代わりに、tcpdump-uwが入っているので、これを使う。

# tcpdump-uw -i vmk0 -s 9014 -B 9 host x.x.x.x -w /tmp/test.pcap

上記は
 ・vmknicのvmk0で行われている (-i)
 ・通信の宛先が x.x.x.xの(host)
 ・size 9014以下のpacket(-s)
 ・デフォルトではバッファ制約により8138 Bytesまでしかキャプチャができないため、
  9014 Bytesまでキャプチャができるよう拡張(-B)
 ・収集したパケットデータを/tmp/test.pcapに保存(-w)
の例です。

tips:WindowsでのJumboFrameに関する話

Windows環境でiSCSIをつかっているので、JumboFrameに関する備忘録を記載。
試したのはWindows2008です。

■MTUの設定値の確認

# netsh interface ipv4 show interfaces

Idx     Met         MTU          状態                 名前
---  ----------  ----------  ------------  ---------------------------
  1          50  4294967295  connected     Loopback Pseudo-Interface 1
 11          10        1500  connected     iscsi1
 14          10        1500  connected     public

上記は1500になっている例。

※Windows2003やXPではnetsh interfaceの仕様が変わったようで、上記では実施できません。


■MTUの設定
上記のMTUの確認と同じコマンドで、対象NICのIdxを確認する(今回はiscsi1を変更)。

# netsh interface ipv4 set interfaces 11 mtu=9000

再度設定を確認しましょう!


■ネットワーク経路でJumboフレームが通るか?確認

pingでフレームが分割されずに通るか?の確認です。

・Windows2008からの確認

# ping [相手先] -l 8972 -f

  -l  : パケットサイズ
  -f  : Set Don't Fragment flag

NGの場合は、、

Packet needs to be fragmented but DF set.

OKの場合は、、

Pinging [相手先]  [x.x.x.x] with 8972 bytes of data:

Reply from x.x.x.x: bytes=8972 time<1ms TTL=127

※8972bytesはJumboframeのパケットサイズ9000bytesから、IPヘッダサイズ20bytes+ICMPヘッダサイズ8bytesを引いたもの。