DigiLoog

続きを読む »

メイン利用しているDNSはBINDとNSDだが、
アプリ間の差分を見る為にキャッシュDNSはunbound、権威DNSはPowerDNSも動いている。
今回はキャッシュDNSのみ移せば良かったので、
既存のキャッシュDNSでDNSルーティングを行いつつ、unboundでDNS64を応答する様にした。

unboundでDNS64を設定するのは意外と簡単で設定ファイルに次の設定を追記すれば動く。
BINDの様に細かく制御が出来ないので、単純なDNS64動作しかできない点に注意が必要だが、
そもそも、DNS64はAAAAレコードの合成が本質なのでサクッと組める方が嬉しかったりする。

server:
    module-config:  "dns64 iterator"
    dns64-prefix:   64:ff9b::/96
    dns64-synthall: no

………

DHCPv6は以前作成した構成メモをIPv6へアレンジして再実装した。
今回はDHCPv6サーバの冗長化も行いたかったので、hook-librariesを使ってHAも組む事に。
IPプールはIPv4と殆ど同じなので楽に組めるが、IPv6でHAを組む時はピア設定に工夫が必要だった。

実際に嵌ったポイントは”high-availability”の”peers-url”となる。
IPv6をWebブラウザで直接開く時にはブラケットで囲う必要があるのだが、
HAモジュールでHTTPを叩いているらしくURL指定もブラケットで囲わないと動かなかった。

    "hooks-libraries": [
        {
            "library": "/usr/local/lib/kea/hooks/libdhcp_lease_cmds.so",
            "parameters": { }
        },
        {
            "library": "/usr/local/lib/kea/hooks/libdhcp_ha.so",
            "parameters": {
                "high-availability": [
                    {
                        "this-server-name": "server-a",
                        "mode": "load-balancing",
                        "heartbeat-delay": 10000,
                        "max-response-delay": 60000,
                        "max-ack-delay": 10000,
                        "max-unacked-clients": 0,
                        "peers": [
                            {
                                "name": "server-a",
                                "url": "http://[2001:db8::a:a]:10547/",
                                "role": "primary",
                                "auto-failover": true
                            },
                            {
                                "name": "server-b",
                                "url": "http://[2001:db8::a:b]:10547/",
                                "role": "secondary",
                                "auto-failover": true
                            }
                        ]
                    }
                ]
            }
        }
    ],

Kea-DHCP v2.1.Xで実際に動かしたコンフィグは上の通りだが、
アプリのアップグレードが最近多くて動かなくなるかもしれない。

………

この構成で重要なのが、IPv6のネットワークからDHCPv6パケットを如何に転送するかになる。
筆者の場合、RA広報・RDNSS・DHCPv6-Relayに対応していて、
比較的購入しやすい価格入手できるFortigate 50Eを使っているのだが、
『対応しているならCLIで打ち込めば出来るだろう』と思いドキュメントを読んでみた。

結果、やはりCLIではちゃんと対応しており次のコマンドを打ったら正常動作した。

config system interface
    edit "lan1"
        set vdom "root"
        set type physical
        set device-identification enable
        set role lan
        set snmp-index 11
        config ipv6
            set ip6-address 2001:db8::b:1/64
            set ip6-allowaccess ping
            set ip6-send-adv enable
            set ip6-other-flag enable
            config ip6-prefix-list
                edit 2001:db8::b:0/64
                    set valid-life-time 21600
                    set preferred-life-time 10800
                    set rdnss 2001:db8::a:c 2001:db8::a:d
                    set dnssl "example.jp"
                next
            end
            set dhcp6-relay-service enable
            set dhcp6-relay-ip 2001:db8::a:a 2001:db8::a:b
        end
    next
end

FortigateでVDOMを切っているので”set vdom root”も入っているが、
VDOMを切っていなくてもインターフェースで上の様な物を入力すれば動く。

この状態で通信を流したり、Windows・Mac・Linux・Androidで接続できるかテストもしたが、
キャッシュDNSで名前解決する事は勿論の事、
DNS64によるAAAAレコード合成や、DHCPv6でDNSサーバを広報する事も出来た。

IPv6はクセが強い事もありNWを組もうとしても面倒だったりする。
一般生活者向けに浸透しているとは言えないが、
NEC AtermがRA広報とRDNSSに対応したり普及の兆しが見えてきたのも事実。
もっと普及させる為には、技術者側が腕を磨くのも重要なので今後も色々試してみようと思う。

« 続きを隠す

続きを読む »

HPE製品はサポート契約しないとアップデート用のBIOSを入手出来ない点が問題だが、
中身はDebian/UbuntuのProxmoxならハードウェア問題も発生しにくいと判断して許容した。
むしろ、この問題こそProxmoxを選んだ理由の大部分を占める。

NICは計3ポート搭載されており、2個がデータ送受信用で1個がiLO専用ポートとなる。
ディスプレイはD-Subのみ搭載なのでサーバっぽいと言えばサーバらしいが、
最近のモニタでは搭載していない事もあるので要注意ポイントだった。

中身はギチギチに詰まっておりサーバらしく排気用の4cm角ファンを搭載していた。
拡張カードを搭載するスロットや、
ThinMicroシリーズのディスクエンクロージャーを増設する端子も搭載されている。
ディスクマウンタは3.5インチなので、2.5インチSSDを搭載する為にはマウンタが必要となるが、
今回は端子位置に互換性があるマウンタを2個購入する事でSSDを搭載した。

SATA電源ケーブルと信号ケーブルはコネクタが一体化されている。
信号ケーブルは普通のSATAケーブルなので断線しても入れ替え可能だが、
電源ケーブルはマザーボード側が独自規格となっており入れ替え出来なそうだった。
保守部材に困りそうなので、お金に余裕が出たらコールドスタンバイ用に1台追加しようと思う。

………

自作PCの様にSSD搭載とメモリ増設を済ませたらハードウェアの準備が完了。
早速Proxmoxをインストールしていた所、OS本体からインストールする場合は、
mdadmによるRAID-1構成を標準では組めずZFSミラーにする必要があった。

ZFSはメモリ消費が激しい印象が強く出来る限り利用したく無かったのだが、
経験上ファイルシステムを弄るとパフォーマンスや構成に影響が出やすいのと、
インストールと同時にZFS領域を作れば全てProxmoxから管理出来るメリットがあるので、
メリット・デメリットを比較した上でZFSミラー構成を今回は選択した。

Proxmoxのインストール画面をクリックしていたらディスク構成以外は難なく終了した。
普段からLinuxのインストールをしている人なら30分もあれば終わる内容だと思う。
初めてのLinuxがProxmoxになる人は早々いないと思うが、
そんな人にはハードルの高い箇所があるのでLinuxで慣れてから触った方が良いと思う。

仮想サーバ1台と仮想ルータ3台を稼働させた状態がこちら。
ゲスト環境の負荷を一目で認識できるのは嬉しいポイントだったりする。
今回は利用していないがHCIの様に使う事出来るので、ディスクを管理する画面も備えている。
ZFSを利用する上で危惧していたメモリ使用率も今の所抑えられている。
“dedup=on”になっていない事を真っ先に確認したのも功を奏したと思う。

………

以前利用していたKVM管理ツールのKaresansuiや、今利用しているkimchiとも違う使い勝手だが、
画面構成が洗練されているからかドキュメントが無くてもゲストOSの構築まですんなり出来た。
流石にHAやHCIを組みだすとドキュメントを読まないと厳しいと思うが、
サクッと構築できるのは仮想サーバホスト構築の敷居を下げるメリットがあると感じた。

エンタープライズでオンプレミス仮想サーバホストを構築すると、
殆どのケースでVMware ESXiかOpenStackを使っておりProxmox事例は聞いた事が無いのが現状。
保守出来る所が少ないのも理由の一つだと思うが、
ホビー用途なら十分な利便性と性能を持っているので自宅サーバ勢の選択肢には上がると思う。
開発もまだまだ続く様なので実際に利用しつつ状況をウォッチし続けようと思う。

« 続きを隠す