LoginSignup
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

@yuzo_____(yuzo)

DNSラウンドロビンを使った負荷分散と暗号化（WEBサーバー構築②）

Posted at

はじめに

前回の投稿で学んだ暗号化通信と簡易的な負荷分散通信を実際に手を動かしながら動きを確認する。

負荷分散を簡易的に行える【DNSラウンドロビン】を使う。
DNSラウンドロビンド.png

事前に準備するサーバーは5台
①DNSサーバー
②Webサーバー2台
③CLサーバー2台

全体の動きは以下の通り。

  • CL1,CL2がhttps://www.d000.mgt.local でアクセスする
  • SVもSV2も両方ともwww.d000.mgt.localを運用している
  • よって上図の矢印のように同じURLで違うSVにランダムにアクセス（負荷分散）される ※DNSラウンドロビン
  • 通信はすべて暗号化通信(SSL)

DNSラウンドロビンとは

  • DNSサーバのzoneファイルを設定するだけで負荷分散ができる。
  • DNSサーバで１つのドメイン名に対して複数のサーバIPアドレスを対応付ける。
  • ドメイン名の要求に対して、対応付けているIPアドレスを順番に返答する。

スクリーンショット 2022-12-11 030302.png
「引用：まさるの勉強部屋 【#51 ネットワーク CCNA CCNP 講座】 DNSラウンドロビンってなんだ？ 」

では早速設定に移る

DNSサーバー

DNSラウンドロビンの設定をするためにzoneファイルを編集するため、'/root'配下にバックアップ取っておく。

[root@ns ~]# cp /var/named/chroot/var/named/d000.mgt.local.db .
[root@ns ~]# ls -l /root/
合計 16
-rw-------. 1 root root 1537 11月 12 00:33 anaconda-ks.cfg
-rw-r--r--. 1 root root  959 12月 11 03:41 d000.mgt.local.db
-rw-r--r--. 1 root root 1829 11月 12 00:36 initial-setup-ks.cfg
-r--r--r--. 1 root root   33 11月 12 00:18 machine-id

現行のzoneファイル確認。

  1 $TTL 86400
  2 $ORIGIN d000.mgt.local.
  3 d000.mgt.local. IN SOA ns.d000.mgt.local. root.d000.mgt.local. (
  4                 2022120401      ; serial
  5                         2M      ; refresh
  6                         15M     ; retry
  7                         1W      ; expiry
  8                         1D      ; minimum
  9 )
 10 d000.mgt.local.         IN      NS       ns.d000.mgt.local.
 11 d000.mgt.local.         IN      MX 10    sv.d000.mgt.local.
 12 d000.mgt.local.         IN      MX 20    sv2.d000.mgt.local.
 13 ns.d000.mgt.local.      IN      A        172.16.1.202
 14 ns.d000.mgt.local.      IN      AAAA     2001::ca
 15 sv.d000.mgt.local.      IN      A        172.16.1.201
 16 sv.d000.mgt.local.      IN      AAAA     2001::c9
 17 sv2.d000.mgt.local.     IN      A       172.16.1.201
 18 cl1.d000.mgt.local.     IN      A       172.16.1.101
 19 cl1.d000.mgt.local.     IN      AAAA     2001::65
 20 cl2.d000.mgt.local.     IN      A        172.16.1.102
 21 cl2.d000.mgt.local.     IN      AAAA     2001::66
 22 www.d000.mgt.local.     IN      A        172.16.1.201
 23 d000.mgt.local.         IN      A        172.16.1.201
 24 ns2.d000.mgt.local.     IN      CNAME   ns.d000.mgt.local.
 25 clientnumber1.d000.mgt.local. IN      CNAME   cl.d000.mgt.local.
 26 www.iphone.d000.mgt.local. IN   A       172.16.1.201
 27 www.android.d000.mgt.local. IN  A       172.16.1.203

全27行
serialナンバー：2022120401

本タスク様のzoneファイルに書き換えたいので、現行のzoneファイルを一度全て消す。
一度に削除する場合は、一行目にカーソルを合わせ
行数+dd (今回は27ddを押せばいい)

真っ新になったので、今回のDNSラウンドロビン用のzoneファイルを作成

serialナンバーは直近の番号より一つでも大きくしないと反映されないので、
serialナンバー：2022120401よりも必ず大きい値にする。

  1 $TTL      86400                         ; 1 day
  2 $ORIGIN   d000.mgt.local.               ; zone name
  3 d000.mgt.local.    IN    SOA   ns.d000.mgt.local.   root.d000.mgt.local.    (
  4                         2022121101      ; serial
  5                                 2M      ; refresh
  6                                15M      ; retry
  7                                 1W      ; expiry
  8                                 1D      ; minimum
  9 )
 10 d000.mgt.local.        IN      NS      ns.d000.mgt.local.
 11 ns.d000.mgt.local.     IN      A       172.16.1.202
 12 ns.d000.mgt.local.     IN      AAAA    2001::ca
 13 www.d000.mgt.local.    IN      A       172.16.1.201
 14 www.d000.mgt.local.    IN      A       172.16.1.203

13・14行目でSV・SV2で同じFQDNを持っているが、IPアドレスだけが違うように設定した。
この設定がDNSラウンドロビン（IPベース）で結果として負荷分散になる。

zoneファイル編集したので、構文チェックし、デーモン再起動。
※本来構文チェックに以下の様に長いコマンド叩く必要あったが以前同コマンドをエイリアス設定したので
nchコマンドで構文チェックされる

設定したエイリアスも併せて確認。

[root@ns ~]# alias 
alias nch='named-checkzone d000.mgt.local /var/named/chroot/var/named/d000.mgt.local.db'

[root@ns ~]# nch
zone d000.mgt.local/IN: loaded serial 2022121101
OK

[root@ns ~]# systemctl restart named-chroot ; systemctl status named-chroot
● named-chroot.service - Berkeley Internet Name Domain (DNS)
   Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled; vendor preset: disabled)
   Active: active (running) since Sun 2022-12-11 04:08:49 JST; 14ms ago

編集したzoneファイルがデーモンに読み込まれたので、digコマンドを使いDNSラウンドロビンを確認。
同じFQDNにアクセスして、IPがコロコロ変わることを確認する。

[root@ns ~]# dig www.d000.mgt.local

;; ANSWER SECTION:
www.d000.mgt.local.	86400	IN	A	172.16.1.201    
www.d000.mgt.local.	86400	IN	A	172.16.1.203

[root@ns ~]# dig www.d000.mgt.local

;; ANSWER SECTION:
www.d000.mgt.local.	86400	IN	A	172.16.1.203
www.d000.mgt.local.	86400	IN	A	172.16.1.201

※＋shortオプションつけてドメインのIPだけ抽出した方が見やすいですね↓

[root@ns ~]# dig www.d000.mgt.local +short
172.16.1.203
172.16.1.201
[root@ns ~]# dig www.d000.mgt.local +short
172.16.1.201
172.16.1.203

CL1側の設定

CL1はDNS slaveサーバとしての機能も以前搭載したので、前述のDNSマスター側で編集した
zoneファイルを同期させるため、デーモン再起動する。

[root@cl1 ~]# systemctl restart named-chroot
[root@cl1 ~]# systemctl status named-chroot
● named-chroot.service - Berkeley Internet Name Domain (DNS)
   Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled; vendor preset: disabled)
   Active: active (running)

masterと同様にslaveでもDNSラウンドロビンの様子を確認。

[root@cl1 ~]# dig www.d000.mgt.local +short
172.16.1.203
172.16.1.201
[root@cl1 ~]# dig www.d000.mgt.local +short
172.16.1.201
172.16.1.203
[root@cl1 ~]# dig www.d000.mgt.local +short
172.16.1.203
172.16.1.201

SV2とSVとCL2

SV2を起動。
全体像を忘れてしまわないように、再度トポロジーを見ておく。
DNSラウンドロビンド.png

SV2は既に初期設定済みなので、上図とFQDN・IP同じか確認

[root@sv2 ~]# hostname
sv2.d000.mgt.local
[root@sv2 ~]# ip a s enp0s3
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:63:61:4b brd ff:ff:ff:ff:ff:ff
    inet 172.16.1.203/24 brd 172.16.1.255 scope global noprefixroute enp0s3

Apacheもインストール済みで、コンテンツも作成済。

[root@sv2 ~]# curl http://www.d000.mgt.local
<html>
  <head>
    <title>
        test
    </title>
  </head>
  <body text="white" bgcolor="black">
    <font size="7">
      <b><i>
        The path is <br>
        SV2 172.16.1.203 <br>
        /var/www/html/test.html
      </b></i>
    </font size>
  </body>
</html>

ブラウザーでアクセスすると以下の画面が表示される。
スクリーンショット 2022-12-11 050119.png

DNSラウンドロビンの確認。

[root@sv2 ~]# dig www.d000.mgt.local +short
172.16.1.203
172.16.1.201
[root@sv2 ~]# dig www.d000.mgt.local +short
172.16.1.201
172.16.1.203
[root@sv2 ~]# dig www.d000.mgt.local +short
172.16.1.201
172.16.1.203
[root@sv2 ~]# dig www.d000.mgt.local +short
172.16.1.203
172.16.1.201

SVも起動し、同様に確認する（SV2と同じなので割愛）

SVで準備しているコンテンツ↓
スクリーンショット 2022-12-11 053248.png

CL2も起動し、同様にDNSラウンドロビンの確認。

[root@cl2 ~]# dig www.d000.mgt.local +short
172.16.1.201
172.16.1.203
[root@cl2 ~]# dig www.d000.mgt.local +short
172.16.1.203
172.16.1.201

動作確認

DNSラウンドロビンド.png

CL1とCL2がhttps://www.d000.mgt.localでアクセスすると、DNSラウンドロビンによってSV1若しくはSV2が
対応したりと負荷分散されている様子を確認する。
動作確認用のために、それぞれのSVのコンテンツに違うhtmlファイルを用意している。

それぞれのCL側のブラウザーのキャッシュをクリアしないと同じSVにだけ接続されるので
アクセスするたびにキャッシュクリア忘れずに
（それじゃ負荷分散の意味ないようなｗ DNSラウンドロビンってキャッシュを考慮してないので今が使われて
ない技術理解するのが正しいのかな？）

https通信は警告画面→詳細表示→危険性を承知で続行で対応する。

CL1からhttps://www.d000.mgt.localへアクセス。

スクリーンショット 2022-12-11 055922.png

CL2からhttps://www.d000.mgt.localへアクセス

スクリーンショット 2022-12-11 061322.png

何度も試しましたが、ブラウザーからのアクセスだとSV2だけにしかアクセスできず、
sv1の画面を確認できませんでした。。
digだとアクセス先が切り替わるの確認できるんですけどね。

[root@cl1 ~]# dig www.d000.mgt.local +short
172.16.1.201
172.16.1.203
[root@cl1 ~]# dig www.d000.mgt.local +short
172.16.1.203
172.16.1.201

ブラウザーで動作確認できず残念

今回ロードバランサ―にDNSラウンドロビンを使った。

zoneファイルを元に戻す

先ほど動作確認のためにzoneファイルを編集したが、編集前のバックアップを取っていたので、そのまま上書きして元に戻す。
上書き後、シリアル番号を増やしておくの忘れずに！

[root@ns ~]# pwd
/root
[root@ns ~]# ls -l
合計 16
-rw-------. 1 root root 1537 11月 12 00:33 anaconda-ks.cfg
-rw-r--r--. 1 root root  959 12月 11 03:41 d000.mgt.local.db
-rw-r--r--. 1 root root 1829 11月 12 00:36 initial-setup-ks.cfg
-r--r--r--. 1 root root   33 11月 12 00:18 machine-id  
[root@ns ~]# cp d000.mgt.local.db /var/named/chroot/var/named/d000.mgt.local.db 
cp: '/var/named/chroot/var/named/d000.mgt.local.db' を上書きしますか? yes

シリアル番号増やす

  1 $TTL 86400
  2 $ORIGIN d000.mgt.local.
  3 d000.mgt.local. IN SOA ns.d000.mgt.local. root.d000.mgt.local. (
  4                 2022121102      ; serial
  5                         2M      ; refresh
  6                         15M     ; retry
  7                         1W      ; expiry
  8                         1D      ; minimum
  9 )
 10 d000.mgt.local.         IN      NS       ns.d000.mgt.local.
 11 d000.mgt.local.         IN      MX 10    sv.d000.mgt.local.
 12 d000.mgt.local.         IN      MX 20    sv2.d000.mgt.local.
 13 ns.d000.mgt.local.      IN      A        172.16.1.202
 14 ns.d000.mgt.local.      IN      AAAA     2001::ca
 15 sv.d000.mgt.local.      IN      A        172.16.1.201
 16 sv.d000.mgt.local.      IN      AAAA     2001::c9
 17 sv2.d000.mgt.local.     IN      A       172.16.1.201
 18 cl1.d000.mgt.local.     IN      A       172.16.1.101
 19 cl1.d000.mgt.local.     IN      AAAA     2001::65
 20 cl2.d000.mgt.local.     IN      A        172.16.1.102
 21 cl2.d000.mgt.local.     IN      AAAA     2001::66
 22 www.d000.mgt.local.     IN      A        172.16.1.201
 23 d000.mgt.local.         IN      A        172.16.1.201
 24 ns2.d000.mgt.local.     IN      CNAME   ns.d000.mgt.local.
 25 clientnumber1.d000.mgt.local. IN      CNAME   cl.d000.mgt.local.
 26 www.iphone.d000.mgt.local. IN   A       172.16.1.201
 27 www.android.d000.mgt.local. IN  A       172.16.1.203

構文チェックし、デーモン再起動

[root@ns ~]# nch
zone d000.mgt.local/IN: loaded serial 2022121102
OK
[root@ns ~]# systemctl restart named-chroot

元に戻ったか、DNSの確認
もうラウンドロビンは起きないことを確認。

[root@ns ~]# dig www.d000.mgt.local +short
172.16.1.201
[root@ns ~]# dig www.d000.mgt.local +short
172.16.1.201

Slaveの役割でもあるCL1もデーモン再起動する。

[root@cl1 ~]# systemctl restart named-chroot
[root@cl1 ~]# systemctl status named-chroot

ここでもラウンドロビン起きないことを確認 ※SVでも確認（割愛）

以上、DNSラウンドロビンを使ったロードバランシングと暗号通信の設定・動作確認でした。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?