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

## はじめに

[前回の投稿](https://qiita.com/yuzo_____/items/568b3a1f5201a162893b)で学んだ暗号化通信と簡易的な負荷分散通信を実際に手を動かしながら動きを確認する。

負荷分散を簡易的に行える【DNSラウンドロビン】を使う。
![DNSラウンドロビンド.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2935967/d9dfabde-36c5-b7d4-3420-59471ab99d60.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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2935967/34222450-a79c-6201-d4c8-634410aad364.png)
[「引用：まさるの勉強部屋 【#51 ネットワーク CCNA CCNP 講座】 DNSラウンドロビンってなんだ？ 」](https://youtu.be/bDR8S9h0Xok)


では早速設定に移る

## 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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2935967/d9dfabde-36c5-b7d4-3420-59471ab99d60.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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2935967/184cebc4-ddc4-5483-6415-a2ba6e2da770.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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2935967/f6c44fa3-fb29-cf46-a081-4cbf90ed3b5e.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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2935967/d9dfabde-36c5-b7d4-3420-59471ab99d60.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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2935967/9ca23ab6-9a86-752b-0fe4-5c8f37e102f4.png)

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

![スクリーンショット 2022-12-11 061322.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2935967/93bd8599-7bd5-dbdb-4f22-4b977f335eb9.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ラウンドロビンを使ったロードバランシングと暗号通信の設定・動作確認でした。