2020年06月14日(日) - 19:35 | カテゴリ:
Linux
自鯖刷新によって様々なインフラを見直したのだが、実は権威DNSの構成変更は行わなかった。
刷新直前にグローバルロードバランサを組み込む構成変更を行ったのと、
権威DNSが止まるとサービス停止に陥るので、見直しをした上で安全重視で従来構成を踏襲した。
権威DNSは、グローバルIPを応答するインターネット向け権威DNS(インターネットドメイン)と、
プライベートIPを応答するイントラ向け権威DNS(ローカルネットドメイン)で分離する構成にしている。
インターネットドメインの方は、前回の権威DNS構成変更から基本設計を変更せず、
フロントエンドにdnsdist・バックエンドにBINDとgdnsdで処理する様にしている。
ローカルドメインは親ドメインを管理するBINDを最上位に構えつつ、
下位の権威DNSにサブドメインを委任する構成を取っている。
インターネットドメインは『dnsdist + BIND + gdnsd』の複合構成、
ローカルネットドメインは『BIND』単一構成と『dnsdist + PowerDNS』複合構成にした。
世間では、BIND脱却の為にNSDやPowerDNSを利用する機会も増えてきており、
いざという時に追従出来ないのは問題なので、少し囓った事のあるPowerDNSを使っている。
「自宅サーバでここまで必要か」と言われると不要だと思うが、
本職絡みでもDNSサーバ知識が必須なので、技術検証を柔軟に出来る様に上記構成を取っている。
………
今回のサーバ刷新時に構成変更を行っていないので紹介出来る内容が少なかった (´・ω・｀)
唯一の変更点は、レジストラに管理を委任していた他の検証ドメインも集約化を行い、
正引き・逆引き合わせて最終的に9ドメインを管理する体制にした事。
また、ドメイン集約化を行った事でドメイン管理が複雑化したので、
従来利用していたDNSゾーン適用ansibleを見直し、マルチドメインでも簡単に管理出来る様にした。
自鯖の刷新前後を比較して大きな変更点が無い為、権威DNSについて書く事も少なくなくなった。
とは言っても自鯖刷新で大きく構成変更した、仮想サーバ基盤と録画サーバはまだ紹介出来ていないので、
近いうちに書こうと思う。
2020年06月05日(金) - 20:36 | カテゴリ:
Linux
旧環境ではBINDを用いてキャッシュDNSサーバを運用していた。
デファクトスタンダードとなっているBINDに慣れておかないと職にも影響が出る上、
仕様変更・脆弱性情報も追いかけるには、実際に運用するのが手っ取り早いという理由もある。
昨今ではBIND以外にもキャッシュDNSが増えた上、BIND以外を採用する環境も増えてきた。
技術提供側としてはニーズに対してスキルを出せないのは不勉強と言わざるを得ないので、
今回のサーバ刷新を機に一部サーバはBIND以外を採用してみた。
また、今後はDNSSEC採用環境が増えて行くと思われる為、
再帰問い合わせが可能なキャッシュDNSでDNSSEC検証も有効化してみた。
“ns-lab BB” のネットワークではプロトコル接続テスト用にIPv4/IPv6で完全分離しており、
IPv6からIPv4に接続する技術も確認する為、FortiGate50EでNAT64も動いている。
NAT64の為には、DNS64も動かす必要があるので、IPv6環境専用キャッシュDNSも稼働している。
そんな中、メインとなる仮想サーバ群は北海道の「さくらの専用サーバ」で稼働しており、
“ns-lab BB” のバックボーン用ドメインとレコードの管理もそちらで行っている。
流石にバックボーン情報を平文でインターネットに通す訳にもいかないので、
拠点間VPNでNW接続を行い、各拠点のキャッシュDNSから上位フォワードをする構成にしている。
BIND以外の環境では、BINDっぽい挙動を再現する為にdnsdistを前段に配置している
IPv6環境ではユニキャストアドレスをそのまま使えば良いので、
敢えて宅内ドメインを持たずにインターネットに直で名前解決を行っている。
前述の通りNAT64+DNS64用のBINDが稼働しているので、下記の様な設定をBINDに施し、
AAAAレコードが割り当てられていない場合でも、AAAAレコードを生成応答する様にしている。
acl "client" {
2001:db8:face:1000::/64;
2001:db8:face:2000::/64;
localhost;
};
acl "private" {
10.0.0.0/8;
172.16.0.0/12;
192.168.0.0/16;
};
view "internal" {
dns64-server "dns64.example.org.";
dns64-contact "postmaster.example.org.";
match-clients { client; };
match-destinations { client; };
dns64 64:ff9b::/96 {
clients { client; };
mapped { !private; any; };
exclude { 64:ff9b::/96; ::ffff:0000:0000/96; };
suffix ::;
recursive-only yes;
break-dnssec yes;
};
};
|
設定を詰めれば単純化する事も出来るが、再帰接続の許可セグメントを限定している為、
ACLを弄って厳密に制御している。
………
DNSサーバなので前段にロードバランサーを介さなくても冗長化が可能な上、
キャッシュDNSは構成が枯れてきている為、特有の複雑設定は実施していない。
なお、dnsdistを前段に置く事でロードバランス・クエリ分散など高度な事が可能となり、
実際に “ns-lab BB” のインターネット向けの権威DNSで採用している。
今回のDNS刷新で難易度の高かった箇所は、
DNSSEC検証を有効化しているキャッシュDNSでトラストアンカーを読み込む箇所。
手動更新・自動更新など色々試してみたが、設定を細かく作り込むと安定しなかったので、
BINDによる自動制御を最終的に採用する事にした。
刷新後の環境は稼働開始してから半年以上経過しているが、
DNSSEC検証含めキャッシュDNSとして問題無く稼働している。
エンタープライズ環境だと、権威DNSはRoute53などを使って外出しする事が出来るが、
キャッシュDNSは自前で持っていないとどうしようも無い事が多い。
そうなると、BINDなりのOSSを使うか、ADドメコンをキャッシュDNSに指定するか、
アプライアンスを入れる事が大半だと思う。
DoT/DoH等の次世代技術も存在するが新環境での導入は見送った。
というのも、同じサーバで監視用Webサーバも動いておりポート番号も被ってしまうのと、
下手にポート変更する位なら実装しないのも手と判断した。
DoT/DoHについては、dnsdistで実現出来そうなので必要性が出た時に試そうと思う。
« 続きを隠す
2020年05月17日(日) - 21:34 | カテゴリ:
Linux
以前の記事で、新環境のデータベース構成について紹介したが、
今回の刷新を機にWebサーバも構成を大きく変更した。
静的ファイルを保存するデータ領域は設計方針を大きく変更してみた。
従来は負荷分散型NFSを自前で構築していたのだが、
アプリケーションのバージョン依存が強くメンテナンス性が悪すぎた事もありサーバ刷新時に廃止をした。
そうなると、別の仕組みで静的ファイルを保存する必要があるのだが、
自前でNFSを立てるとなると冗長化するのが辛い上、単一障害点を無くした上でシンプル構成にしたかった。
そんな事もあり今回は新たな取り組みとして、外部ストレージを利用する方針に変更。
サービス接続点・外部ストレージ自体が単一障害点になる可能性が残っているが、
自前で分散ストレージを立てる寄りも冗長性が上がるのと、
分散ストレージが必要とするサーバリソース・NW帯域を確保する事が出来なかったので諦めた。
何処の外部ストレージを使うか選ぶのが、一番大変だった…
レンタルサーバで”AWS S3″の様なサービスを展開していても、価格的に個人利用するのが不可能だった。
個人利用出来るサービスがあったとしても、APIで外部ストレージを叩いてHTTPベースで処理を行う物が多く、
Webサーバで直接参照するには速度が遅すぎて使い物にならなかった。
そんな中で唯一見つけたのが「さくらのVPS」で提供している追加NFSストレージだった。
可用性もそれなりに有る上、自鯖を稼働させている「さくらの専用サーバ」と相互接続が可能な事もあり、
今回の要件にも合致した。
試しにリード・ライト速度も測ってみたが、20～50Mbps程度出ており問題無くファイル処理が出来た。
………
“ns-lab BB”は、自前でリバプロ型ロードバランサを構築してあるので、
Webアクセスのフロントエンドもロードバランサで終端した後、
負荷分散ポリシーに従い、バックエンドのWebサーバに処理を再転送する2層・3層構造を取ってみた。
静的ファイルは「さくらのVPS 追加ストレージ」に存在するNFS領域にある為、
Webサーバから「さくらのクラウド ブリッジ接続」を用いてアクセスする様にしてある。
ブリッジ接続は追加費用が発生する物なので金が無駄にならない様に、
サポートに問い合わせ仕様を確認した後、仮構築を行ってから本番実装をした。
今回のWebサーバ構成を図に起こすと上の様になる。
ブリッジ接続の設備メンテナンス影響で1回だけ計画停止したが、この1回以外では停止していない。
………
ロードバランサはアクティブ・スタンバイ方式なので、障害発生時にはシステム切り替えが発生する。
しかし、他のサーバは両アクティブ構成となっており、可能な限りシステム切り替えが起きない様にしてある。
この構成を維持する為に、ロードバランサからWebサーバを監視するヘルスチェックを一定間隔で送信し、
Webサーバ停止時には自動的にプールメンバから外れ、復旧時には自動追加するようにしている。
フロントエンド構成は刷新前のWebサーバを踏襲している事もあり、安定稼働し続けている。
今回採用した、外部ストレージの応答速度が気がかりであったが、
実際には1ms程度の低遅延で応答があり、リード・ライト速度も水準をキープしつつ処理出来ている。
ブログデータを格納しているデータベースは以前紹介した通り負荷分散型にしてある為、
読込み処理を分散しながら高速処理を行っている。
実際にアクセス速度分析を行うと、前構成は平均120mで応答が返ってきていたのだが、
新環境は平均70msまで短くなり、構成変更の成果が数値としても出ていた。
また、今回はロードバランサを噛ましている事からスケールアウトが容易に出来るのもメリットとなる。
閲覧者増加時や、新サイト立ち上げによって負荷が増えたとしても、
スケールアウトする事で一定負荷をキープし、結果として応答速度の維持も出来るのいが大きい。
今回のサーバ刷新によって、Webサーバ系のシステムが全てスケールアウトを取れる様になったのは大きかった。
この考えはAWS等のクラウド基盤を使う場合にも応用が利くので、自鯖運用でスキルを貯めていこうと思う。
« 続きを隠す
