ネットワークを考えるときに考えること(5)
既に息切れしているものの一応最後まで書かねば……という義務感により。非機能要件について。回が進むごとに雑になっている気がしますが大目に見てください。
非機能要件を考える
どこか前の方でも書きましたが、ひとつの技術要素が複数の要件と関連することがあるので、いくつかの見方でバランスを考えましょう。
冗長化・耐障害性・信頼性
信頼性って話を冗長性・耐障害性みたいなところと混ぜて書いてしまうのはどうかと思いつつもまとめてしまいます。
機器の信頼性・システムの信頼性
- デバイス単体の問題としてどういう信頼性なのか。
- システムの信頼性としてどういう信頼性なのか。
レイヤ別の検討
- レイヤごとに使われる仕掛けがいろいろあるので、各レイヤごとに何を使ってどう保証するものかを考えていきます。
- ある障害イベントに対して、どこかのレイヤで保証されるから他のレイヤの仕掛けは要らない、といった判断もあり得るでしょう。システムを平面的にとらえたときの位置…エッジでのポリシ、コアでのポリシ、外部接続部分でのポリシ…と、深さ(レイヤ)…どのレイヤでどういう技術を使うかを考えます。
- 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のプロセスが起動したのにラインカードがまだリンクアップして無くてステートが思ったように切り替わらない、みたいな話。上記の通り、冗長化の仕掛けにもレイヤ別の依存関係があります。デバイスの停止やメンテナンスによる再起動なんかを考える場合は、複数の仕掛けが一気に動くようなケースがあり得ます。動作の依存性とか順序は注意してください。
- システム境界の冗長性・障害対策は念入りに。上流キャリアとの回線や他拠点接続などのテストはそうそうできません。初期構築段階での設計及びテストが重要です。
「ネットワークのテスト」って何やるのん? というのはまたそれはそれであるか…(今回はパス)
性能
性能の話ねえ…正直事前にこの辺を全部見通すというのはものすごく難しいですよ。システムの更新とか、既存のシステムがある場合ならそれを元に…と思うかもしれないけど、既存のシステムでこうした検討を行うための指標を継続的に測定していないなんてことの方が多いんじゃないでしょうか。
- 容量の問題
- 太くすべきところは太くする必要があります。
- トラフィックが集約されるところはどこですか? 複数のシステムを仮想化して載せている場合には非常に読みにくくなります。モニタリング頑張りましょう。
- システム全体のデータフローはどのような想定ですか? 通信量の多いアプリケーションはどこで使われていますか? ネックになりそうなところはどこでしょうか?
- 太くすべきところは太くする必要があります。
- 特性の問題
- 品質の問題
- 通信遅延
- 当然遠くなればなるほど遅延が大きくなります。音声など遅延影響の大きなサービス(アプリケーション)を使う場合は注意しましょう。
- パケットロス、高負荷時の動作など
- パケットロスやノイズ等によるエラー率の上昇などといった品質上の問題があり得ます。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など)といった高レイヤ処理系では要注意。
次回
引き続き非機能要件とか何とか。