2007年、Ukrnamesがまだ小さく、最初の一歩を踏み出したとき、ほとんどの作業はプログラマーによって行われていました。 ドメイン管理システムを開発してテストし、これらすべてが機能するサーバーを管理しました。
また、ドメインがある場合は、DNSがあります。 DNSサーバーを作成する最も簡単な方法は何ですか？ ユビキタスBINDを配置します。 はい、BINDは簡単ではありませんが、MySQLと友達になるためのDLZパッチがあります。
年が経過し、システムが機能し、サーバーの容量が増加しました。 そして、いつものように、作業中-触れないでください。 したがって、次の8コアサーバーに対して負荷がかかり始めなかった場合、これはすべて続行されます。
この時点で、飽くなきBIND + DLZのハードウェアをもう一度アップグレードする代わりに、強い意思決定を下し、DNSサーバーの新しいシステムを構築する必要がありました。
そして、おとぎ話は終わり、管理者の厳しい平日が始まりました。
何がありますか？
Ukrnamesが無料でドメインに提供するサービス、つまり「Managed DNS」をサービスする必要があります。
現在、このサービスは10万を超えるドメインで使用されています。 ドメインは多様であり、出席者もそれぞれ異なります。負荷はドメインの数に依存しません。
このサービスは、Xeon X3430、8Gb DDR3、2x500Gb SATA RAID1の構成を持つ3つのDNSサーバーによって提供されます。 サーバーは、MySQLと組み合わせてBIND + DLZパッチを使用します。 データベースは、ドメインゾーンの現在アクティブなストレージサーバーのスレーブとして機能します。
自分で問題を探しています...頭
- 高負荷、100％のサーバー容量が使用されます。 半分はMySQLにあり、残りの半分はBINDにあります。
- DLZパッチはすでに古く、開発されていません。 BINDの新しいバージョンのパッチを際限なく作り直すことは、最善のアプローチではありません。
- 他のソリューションを使用する場合、古いデータベースの問題が発生します。この問題は、最初は特別なチェックなしで満たされていました。 多くのゴミ、RFCに準拠していない多くのレコード。 巨大なDNSはそれらを受け入れません。
タンバリンを発見
MySQLおよびNSD（ファイルの作業）を備えたPowerDNSは、既存の種類から選択されました。
古いBINDとこれらの2人の詐欺師のために競争することが決定されました。
PowerDNSを探します
一見したところ、最も論理的な選択はDNSサーバーを使用することです。DNSサーバーはすぐに使用でき、MySQLデータベースを使用して既存のデータベースにバインドできます。
実際には、既存のデータベースとPowerDNSで必要なもので、いくつかのやや不快な違いが見つかったことが判明しました。
その結果、実装のために、データベースの構造を変更する必要があり、これはシステム全体のコードの変更につながります。 松葉杖、つまりプロシージャまたはビューを構築します。
競争では、2番目のオプションが選択されました。 メインシステムに触れることは不可能でした。
NSDを感じる
ウィキペディアによると 、NSDは3つのルートサーバーで正常に実行されています。
NSDの機能は、すべてのゾーンを内部データベース形式にコンパイルしてから、完全にRAMにロードすることです。
開発者のサイトには、
RAM消費量を計算する
ツールがあり
ます 。 私たちの場合、約367 Mbでしたが、これは許容可能な結果を超えていました。
タンバリンを請求します
50スレッドでDNSサーバーに要求を送信するユーティリティが作成されました。 ドメインは既存のデータベースからランダムに選択され、レコードのタイプもランダムに変更されました。
PowerDNSの場合、目的の形式でデータを返すビューが作成されました。 テスト中、最適化のために3回書き換えられました。
NSDについては、私のお気に入りのGoogle Goで、データベース全体をサンプリングし、データベースを内部NSD形式に組み立てるコンバーターユーティリティで作成しました。
どちらの場合も、RFCとのすべての矛盾を消化可能な形式に変換するために論理フィルターが使用されました。
また、ベースの長期デブリも除去されました。 慣用表現がなければできなかったでしょう。 そのようなことがDNSに記録できるとは思っていなかったでしょう。 CNAMEレコードにはURLがあり、MXにはパスワード付きのメールがありました。 どうやら、最初はプログラマーもユーザーを信じており、レコードに対して通常のフィルターを作成していませんでした。
踊る
次に、参加者ごとにテストが実施されました。 テストの期間は10分です。 1分に1回、最後の1分間の平均応答時間と現在のプロセッサ負荷がパーセントで保存されます。 テストは、戦闘DNSサーバーと同じ構成のマシンで実行されました。
PowerDNSは、MySQLへのクエリの数を減らすためにSOAを独立して生成するように構成され、1分間のレコードキャッシュも含まれていました。
NSDは標準構成で4つのスレッドで機能しました。
結果
BIND + DLZは、いつものように、膨大な応答時間、スペース負荷を示しました。
PowerDNSは、メインデーモンとMySQLに約50〜50の負荷を与えるBINDと同様に、良好なパフォーマンスを示しました。 そして、テストにNSDがない場合、彼はリーダーになります...
応答時間：
CPU負荷：
NSDを使用したテストを3回繰り返しました。 何かが間違っているというしつこい感じがありましたが、これは不可能です。
まとめ
実際、結果はそれ自体を示唆しています。
MySQLのロジックは弱点です。 そのようなデータを受信者ですでに処理し、可能な限り少ない要求を行うことをお勧めします。
DNSの場合、データが30分以内に更新されれば問題ありません。 コンバータユーティリティは7秒で完了し、1分間の更新が可能です。
現在、サーバーでNSDが実行されており、ハードウェアのアップグレードについては、ドライブをより新しいものと交換することを除いて、すぐには考えません。