ネットワークを考えるときに考えること(5)

既に息切れしているものの一応最後まで書かねば……という義務感により。非機能要件について。回が進むごとに雑になっている気がしますが大目に見てください。

非機能要件を考える

どこか前の方でも書きましたが、ひとつの技術要素が複数の要件と関連することがあるので、いくつかの見方でバランスを考えましょう。

冗長化・耐障害性・信頼性

信頼性って話を冗長性・耐障害性みたいなところと混ぜて書いてしまうのはどうかと思いつつもまとめてしまいます。

機器の信頼性・システムの信頼性

  • バイス単体の問題としてどういう信頼性なのか。
    • 電源やモジュール、ラインカード等の部品の冗長化などの仕掛けをどう使うか。ノード側(サーバ等)のNIC冗長化の仕掛けとの連動をどう設定するのか。
  • システムの信頼性としてどういう信頼性なのか。
    • クラスタリングVRRPやSTPなどの標準プロトコルによる複数デバイスの連携、動的経路制御を使った経路迂回など、システム全体としての冗長化などの仕掛けをどう使うか。
    • 電源周りも気をつけてください。必要に応じてUPSを。例えば、停電時UPSからシグナル受けてネットワークマウントしているファイルシステムにデータ書き出してアンマウントするようなシステムがある場合、その処理が終わるまでは間の経路のネットワークが維持されないと何も意味が無いわけです。

レイヤ別の検討

  • レイヤごとに使われる仕掛けがいろいろあるので、各レイヤごとに何を使ってどう保証するものかを考えていきます。
  • ある障害イベントに対して、どこかのレイヤで保証されるから他のレイヤの仕掛けは要らない、といった判断もあり得るでしょう。システムを平面的にとらえたときの位置…エッジでのポリシ、コアでのポリシ、外部接続部分でのポリシ…と、深さ(レイヤ)…どのレイヤでどういう技術を使うかを考えます。
    • L1: LAG(Link Aggregation), BFD(L1か?), Link State Tracking などの物理リンク状態をトリガにして動作する仕掛け
    • L2: STP, 少し前は Uplink Fast などの補助機能なんかがありましたがいま使うなら RSTP などでしょう。L2セグメントとインスタンストポロジ(Root Bridgeの設定)に注意してください。障害時にインスタンスがどういうツリーになって、変なところがブロックされないかどうかとかを考えます。あとは Root Guard とか BPDU Filter など STP 補助機能をどこでどう使うかというのも考えるべきでしょう。
    • L3: FHRP(HSRP, VRRP), 動的経路制御の利用。
    • L4: Firewall, Load Balancerなどのクラスタリング、ステートの引き継ぎ(ステートフルフェイルオーバ)の機能利用。LBそのものは負荷分散と言うだけでなく、複数のサーバをひとつのサービスとして束ね、サーバの単体障害に対して冗長性を高めるもの、という見方もあります。その他クラスタリング系全般は製品依存なので製品担当に確認を取りましょう…。
  • STPや動的経路制御など、トポロジ変化(通信経路変化)が伴うものは、どういうイベントに対して、どのようなトポロジになるかなどの動作を考えておく必要があります。

あと、これはネットワークの…というわけじゃなくてファシリティ面だとは思いますが。物理構成的側面として。

  • 耐震
    • 建物自体(耐震・免震)、ラック(免震ラック・耐震ラック)
    • 機器マウント(棚板上に載せてある機器や備品は耐震ベルトで固定する…などの対策)
  • 電源: 電源設備等の系冗長、非常用電源(設備有無、容量、耐久時間)
  • 回線: 回線の冗長、引き込み経路の分離

まあこうした話を誰がフォローするのかという問題もあるけど…。運用系やる人かネットワーク系やる人かになっていることが多い気がします。

障害対応

ついでなので障害時の動作についてどう考えるかという話も。

  • 基本的なネットワーク障害の種別: リンク, モジュール, ノード(デバイス全体の故障)
  • 自動復旧の有無: 自動で元に戻るものなのか手動で戻すものなのか(preemptの有無など)
    • 自動で戻る場合はどのような条件で戻るか、手動で戻す場合はどのような条件(判断条件)でどういったオペレーションを行うか。自動で戻るものについては不安定さを引き起こす可能性があることに注意してください(フラッピングなど)。
    • メンテナンスのための系切り替え…たとえば、機器交換のための経路片寄せなどでどういった操作をする必要があるか、という点も検討しておくべきです。システム全体の通信影響を最小化するためのOS更新やハードウェアの追加・拡張・交換などの手順はどうなりますか?
  • FW/LBなどクラスタリングされて動く場合は、どちらがマスターかを見る…というのはもちろんありますが、ステートやコンフィグの同期の動作、IPアドレス引き継ぎの仕掛けなどを見ておいた方が良いです。
    • クラスタリングに寄らずVRRPとかでも似た感じですが…。たとえばVIPを共有して常にマスターがそのVIPを使うような物もあれば、系切替があったときにIPを入れ替えるような機械もあります。そしてIPアドレスの引き継ぎ(切替)は大抵 ARP (Gratuitous ARP)なんかが使われるんですが、この辺でトラブルがあってうまく引き継がれないとかあったので…(試験が面倒くさい)
    • こうした仕掛けを複合して使う場合、デバイスの起動順序とかモジュールの起動順序によってうまく動いてくれないケースが過去ありました。例えば、VRRPのプロセスが起動したのにラインカードがまだリンクアップして無くてステートが思ったように切り替わらない、みたいな話。上記の通り、冗長化の仕掛けにもレイヤ別の依存関係があります。デバイスの停止やメンテナンスによる再起動なんかを考える場合は、複数の仕掛けが一気に動くようなケースがあり得ます。動作の依存性とか順序は注意してください。
  • システム境界の冗長性・障害対策は念入りに。上流キャリアとの回線や他拠点接続などのテストはそうそうできません。初期構築段階での設計及びテストが重要です。

「ネットワークのテスト」って何やるのん? というのはまたそれはそれであるか…(今回はパス)

性能

性能の話ねえ…正直事前にこの辺を全部見通すというのはものすごく難しいですよ。システムの更新とか、既存のシステムがある場合ならそれを元に…と思うかもしれないけど、既存のシステムでこうした検討を行うための指標を継続的に測定していないなんてことの方が多いんじゃないでしょうか。

  • 容量の問題
    • 太くすべきところは太くする必要があります。
      • トラフィックが集約されるところはどこですか? 複数のシステムを仮想化して載せている場合には非常に読みにくくなります。モニタリング頑張りましょう。
    • システム全体のデータフローはどのような想定ですか? 通信量の多いアプリケーションはどこで使われていますか? ネックになりそうなところはどこでしょうか?
  • 特性の問題
    • アプリケーションごとの通信料の変化や使われているアプリケーション(プロトコル)の特性には特徴がありますか?
      • 時間帯・時間変化(時・日・週・月・季節・年、その他特定のイベント…)、プロトコル種別、ピーク性、など
      • 求められる要件に対してどのような対策を取るか: ピークに合わせて十分な帯域を用意する(富豪的)、何かしらの帯域制御装置(設定)やQoS設定を入れる、ネットワーク的な負荷分散で対応する、など。拡張性や耐障害性、運用の複雑さ、コストなどと合わせて考える必要があります。
  • 品質の問題
    • 通信遅延
      • 当然遠くなればなるほど遅延が大きくなります。音声など遅延影響の大きなサービス(アプリケーション)を使う場合は注意しましょう。
    • パケットロス、高負荷時の動作など
      • パケットロスやノイズ等によるエラー率の上昇などといった品質上の問題があり得ます。TCPによる再送で何とかなるものなのかなどは、アプリケーションや実際に使う回線などを踏まえて考えておく必要があります。
  • 計算負荷
    • 細い回線を使わざるを得ないケースでは、輻輳した状況でどうコントロールするかを検討しておくのが無難です。
    • CPUブン回ってしまってリモートアクセスすらできないと手に負えなくなります。仮想アプライアンスを使う場合やVC(Virtual Context)などの物理デバイス無い仮想インスタンス機能を持つようなものでは物理リソースを、どのインスタンスがどの程度まで食う物かという上限設定や割り振りなどを見ておく必要があります。(となりの環境がやらかしてしまって、同一ハードウェアにある他のシステムまで影響を受けてしまうことがあるのか、それを許容するのか: "共有と専有"のポリシ)
    • FW/LB, L3以上の処理を行う機材では、どういった処理がCPUで行われるかというのをある程度知っておいてください。
      • 大抵の機器ではASICで処理されているものの、特定の条件で(例えばTCAMがあふれて)ASICではなくCPU処理になって突然ネットワーク処理性能が低下する、などのトラブルがあります。L2でも多数のセグメントがあり、PVSTしていて多数のSTPインスタンスを持っているような場合は、トラブルによるトポロジ変化(再計算)がCPUで行われ、想定していた時間内に切替が起こらない…なんてことも考えられます。
      • …といった話で、高レイヤのネットワークサービスデバイスを考える場合には帯域(bps)というよりはパケット処理性能(pps)を見ておく必要があります。
      • NAT(そのほか何かしらの変換処理), フィルタ(ACL)・ポリシ設定、暗号処理系(VPN, SSL系)、圧縮処理(LB, WAN最適化など)、セキュリティ系(DPIなど)といった高レイヤ処理系では要注意。

次回

引き続き非機能要件とか何とか。