やったこと

ネットワークスペシャリスト合格教本 2022年

• サーバ負荷分散
• サーバ冗長化
• 経路冗長化
• NIC 冗長化

学んだこと

LBによる負荷分散

外部からのリクエストを、LB管理下のサーバに振り分ける。
その際、外部からのリクエストの宛先IPは、LBから振り分けられたサーバに変換する。
動作的には、リバースプロキシに近い。

LB管理下のサーバのヘルスチェックも可能

レイヤーに応じて、ヘルスチェックの手段が異なる

• レイヤー3 : pingを使用
• レイヤー4 : TCPセッションの確立を試みる
• レイヤー7 : 特定のリクエストを送信し、そのレスポンスを確認

ヘルスチェック機能を実現できる点は、DNSによるラウンドロビンには無い利点。

LBの振り分け戦略

色々ある。

• ラウンドロビン
• 事前に振り分け比重を決める
• 事前に優先度を決める
• レスポンスが最短のサーバ
• コネクションが最小（≒まだまだ余裕のある）のサーバ
• 何かしらの個別ルール

DSR (Direct Server Return)

LBを通したリクエストについて、レスポンスはLBを通過しないという戦略。
■request経路
client -> LB -> server

■response経路(DSR)
client <- server

利点

• LBの負荷軽減
• LB周辺ネットワークの帯域節約

特徴

VIPを用いてLBからserverへ振り分ける時、VIPは変化せず、MACアドレスのみ（LBからserverのMACアドレスへ）変化する。

DSRを使用する場合は、サーバー側には以下の設定が必要。

• LBと同じVIPを設定する
  • クライアントとやり取りするため、IPアドレスが必要
  • LBと同じIPアドレスであれば、クライアントは、サーバのレスポンスをLBのレスポンスとして解釈できる
  • -> サーバとLBのVIPが異なる場合、クライアントからすると、LBに送信したはずのリクエストが、LB以外のIPアドレスからレスポンスとして帰ってくることになり、通信が成立しなくなる
• VIPに対する ARP に応答しないこと
  • ARPに応答するのはLBとするため

LBによるセッション維持

■背景
現代では、Cookieを用いたステートフル通信が浸透している。
このため、セッションが維持されている限り、通信相手は（LBで振り分けた）サーバと同一である必要がある。
これを実現するのがセッション維持機能。

■仕組み
LBによって異なる

■セッションIDを識別するために
Cookieの中身を確認してセッションIDを識別する場合、HTTPSパケットを復号する必要がある。
これは、LBにこの機能を持たせる（≒LBにTLS終端機能を搭載する）ことで解決できる。

サーバの冗長化

スタンバイ系へのフェイルオーバー

サーバからクライアントへ、RSTフラグを立てたTCPを送信し、（障害が発生した）アクティブサーバとのTCPセッションを強制切断する。
これにより、迅速なフェイルオーバーをじつげんする。

スプリットブレインシンドローム

active/ stand by 構成のシステムにおいて、何らかの理由（主にハートビートの失敗）で、障害が発生していないにもかかわらずstand by系が起動する事象。

■問題点

• 仮想IPのARPに、active系とstand by系の両方が応答してしまう
• ディスクを共有している場合、保存しているデータにて競合が発生する可能性が高い

マルチホーミング（回線冗長化）

切断が許されないサービスを提供するサーバ(DNS、NATなど)への回線を冗長化することで、より確実なサービス提供が可能となる。

冗長化した回線を使用して、LBによるトラフィックの負荷分散を行う...といった戦略もある。

NICチーミング（Teaming）

複数のNICをまとめ、一つのNICに見せかける技術。

リンクステートトラッキング

L2SWに備わっている機能。
あるポート（上位ポート）がダウンした時、他のポート（下位ポート）を強制的にダウンさせる機能。

STPは、ブロードキャストドメインごとにスパニングツリーを一つ形成する

以上