ネットワーク図を書くときに考えること

study

[追記] 考えること(2)も書きました。

先日、ネットワーク図の書き方 - Akio’s Log を読みまして。自分もちょっとネットワーク図について書いてみようと思いました。入社以来なぜか関わる案件関わる案件でネットワーク図を書き続け、自分なりに思うところがそれなりにあったりするので。まあ、関わる案件で毎度ゼロから書いていたわけではなく、すでに作ってある案件もあるのですが…。結局、自分で書いてみないとわからないことが多いので、すでに図があろうがなかろうが毎度自分で描くってだけなんですけどね。

今回のサンプルは例によって自宅のネットワーク図にしましょう。図自体は以前のエントリにも載せているのですが、IHAnet 参加とか自宅ラック#3とか のあたりで機材追加したりしていろいろと変更を加えました。


参照

上でリンクを張ったこの記事 に参考リンクはいろいろあるのでそちらを参照したら良いのですが、ひとつ取り上げるとするとこれ。

この記事はイイですよね。私が入社直後くらいの記事で、自分で図を書く際にとても参考になりました。日経ネットワークの記事で使ってある図はとても良く作り込んであるので、図見るだけでも参考になります。

ツールとしては Visio でしょう。仕事だと自分も Visio を使っています。ただ Visio は個人で買うにはちょっとお高めなので、自宅では LibreOffice Draw を使っています。まあ何とか使えるけど、ただやっぱり操作感とか機能とかはやっぱり Visio のほうが数段上なので、Visio 買おうか迷うのですが…。

…と話がずれたので参考文献という話に戻しますが、あとひとつ、O'Reilly の "ネットワークウォリア" をおすすめしておきます。

ネットワークウォリア ―戦う管理者のための知識とテクニック

ネットワークウォリア ―戦う管理者のための知識とテクニック

33章「ネットワークの設計」の「ネットワーク図を書くためのヒント」がすごく良いです。ヒントだけ引用しておきます。(詳細は現物を読んでください。) この本、L1からいわゆる "L8" の話まで書いてあって面白いです。

  • 簡潔さを保つ
  • 物理的な概念と、論理的な概念を分離する
  • 線を交差させない
  • 直線をそろえる
  • できる限り線引きする
  • アイコンを整列させる

日経ネットワークの記事の方はこうです。共通点が見えますよね。

  • 何のために書くのか目的をはっきりさせる
  • 論理構成と物理構成を分けよ
  • 大胆に省略せよ
  • ルールを決めよ

ネットワーク設計とネットワーク図

ネットワーク図の目的

上であげた自己流のネットワーク図の目的ですが、それはもう単純にひとつ、「論理構成をコンフィグに起こすための論理-物理マッピング」です。一目見て複雑で、物理も論理も一緒くたに書いてあるので、ヒント : "物理と論理を分ける" に矛盾しているようですが、なぜこういう図を書いているのかという理由を説明していきます。

ネットワークを設計する上では、やりたいこと(要件)から論理構成図を作って、物理構成図に落として、実際にコンフィグを作成する、という作業をやります。自分の場合、それらのプロセスを行うなかで、最終的に上であげたような図を作成します。以降、ネットワークの設計のフェーズごとにどういうことを考えてどういう図を作っているかというのを振り返ってみます。

論理構成設計

そもそも、どういったネットワークを実現すべきか、という段階では必然的に L3 以上の内容で検討することになります。求められる機能とそれを実現するための構造を検討します。例えば、

  • どういったネットワーク、あるいはセグメントが必要なのか
  • 各ネットワークで提供すべきサービスは何か
  • 各セグメントには何があってどういうトラフィックを発生させるのか(トラフィックフロー)
  • セグメントごとの管理ポリシ、接続制御、セキュリティポリシはどう置くか
  • ネットワーク間の接続、経路制御はどのように行うか
  • 冗長性や性能をどこまで、どのように保証するか

…などなど。たとえば、IHAnet参加の際にはこういうラフスケッチを書いていました。

この図はスイッチ追加購入前の段階で検討していたものなので、今の図とは異なるのですが、マルチホームで BGP 接続した場合、何をどこにつないで、経路交換をどうするかというのを考えているものです。

IGP の設定とか経路制御を検討しているものはこれ。最終的にはひとつスイッチ買いたして四角形の構成にしました。最終的に経路制御とかをどのように設定したか、という話は前のエントリに。

ここで言いたいのは、ある程度上位の要件に対してどういうネットワークを作るか、という話をする際は、論理構成図(L3) を使うよね、ということです。まずは論理構成で、ネットワークの構造、実現したい機能、あるべき姿を決めます。

物理構成設計

論理構成がある程度決まった段階で、実際にどのような機材を使用してネットワークを実現させるかを考えます。具体的には、

などがあるでしょう。

また例によってラフスケッチですが、実際の機材に論理構成をマップしていきます。

これはマルチホーム検討の前の段階で一旦書いたものでちょっと古いですが…。機材間の接続とか、スイッチ間リンクをどう出すか、どこを Trunk で束ねるか、などを見ていたものと思われます。

もうちょっとベタな物理構成に落とすとこんな感じです。ここでは単純にポート数が足りるかどうかなどを検討しています。スイッチ足して、GbE のポートと FastEther のポートなどで種別があるので、どの機材をどこにつなぐかなどを決める必要がありました。実験用の機材はそれほど帯域を必要としないので FastEther で収容、普段使いのPCとかサーバ類は Gigabit で接続できるようにしてあります。

…自宅だとこの程度で済むんですけどね。

ネットワーク図、というテーマからちょっと脱線しますが、少し物理設計まわりの話について書きます。論理構成の設計については文献もいろいろあるのだけど、レイヤの低いところについて書いてある本とかなかなか見かけないですし、やって見ないとわからないことが多いと思うので。

  • システム構築全体で見ると、ネットワークの要件は最も最後に決まって、最も最初に構築が始まります。情報システムを作る際に、ほとんどあらゆることがネットワークの上に行われることを前提としています。土台が揺れると上物が全部揺れます…が、そのくせやたらと急かされる部分でもあります。厄介ですね。
  • 物理構成はいったん構築始まってしまうと後から変更がきかない + いちど間違うと修正がものすごく面倒くさいので、綿密に計画する必要があります。機材や部材はお金に直結する部分ですし、仮に不足や調達ミスなどがあると作業工程上ものすごく時間的な足止めを食います。故障することや物理構成上の仕様変更などに対応するための予備部材を含めた上で、予算上許容される部材を見積もる必要があります。あと、将来的な拡張枠を(ポート/配線等のスペース)見込んでおくことも重要です。
  • 特にネットワークの構築を行う場合は、ネットワークが物理的な位置を吸収する層であることに注意が必要です。いったんネットワークができた上で作業する人は、どこに何の機材があるのかを、おそらくほとんど意識しません。しかし、それを実現する人は、物理的に、何がどこにあるのかを把握し、設計する必要があります。
    • Ethernet には距離上限があります。GbE (Cat5e)だと 100m です。これは媒体(光ファイバなのか導線なのか)や帯域(10/100/1000, 10G) などにより規定されます。どこからどこに、何の規格のケーブルを使うかを、設計時点で決めておく必要があります。
      • 例えば、フロア間である程度距離の長いケーブルを引く場合には、ノイズ対策としてシールドの入ったUTPケーブルを使う、といったことがあります。
    • ケーブルの種類やコネクタの形状などの規格を確定させてください。
      • スイッチ間はストレートですか? クロスですか? サーバ側のファイバのコネクタは LC ですか? SCですか? SFP などのモジュールは確保されていますか? サーバ側で使うモジュールは誰が用意していますか? ファイバの場合、マルチモードファイバで大丈夫ですか? RJ45 であれば、サーバ側は MDIX-Auto ですか? …など。
      • 実際、境界部分を間違えた、担当者がお互い相手がやっていると思っていて検討から漏れた、という事例もあります。また、これらをあらかじめ検討していても、いざ接続したらうまくリンクアップしない、ということもままあります。(でも、どういう設定で接続するか決めていないとリンクアップしないときに次の対応策がとれない。)
    • 配線経路をあらかじめ設計してください。
      • 配線のルールを設定しましたか? ラック間を渡る配線は一旦ラックの上、あるいは床下を経由しますか? ラック内/ラック間/あるいはフロア間(を通す管路) など、ケーブルを通すための十分なスペースはありますか? スイッチの場合、他のスイッチの全面を配線が通過して、故障時に機材交換ができない状況になっていませんか? 今後ケーブルを増やしたときに十分な配線スペースが確保されていますか? DCを使う場合、DC 側と床下/床上の経路について調整していますか? パッチパネルを使う場合、パッチパネルの配線スペース(パッチパネル裏)、あるいはパネルの設置スペースが確保されていますか?
      • サーバのPDUやコンセント(電源ケーブルの配線)などのスペースを見落としたり、かぶっていたりしませんか? ラック上部のファンと干渉したりしていませんか? (一番上・一番下は要注意) エアフローを考慮していなかったために排気を妨げるところに配線が集中したりしていませんか? サーバの部品交換時など、スライドするもの、モジュールの出し入れなどを妨げるような配線をしてしまったりしていませんか? (配置が邪魔/ケーブルが短すぎる、など)
  • このほか、電源容量だのラックレイアウトだの、機材を入れる上で一般的な話が当然あります。
    • エアフローについては、最近のスイッチは吸排気方向を選択できるものが増えている(前面吸気/後面排気、または、後面吸気/前面排気)ので、設置ポリシに合わせます。ただ、大型の機材では横方向で吸排気するもの(例えば Catalyst6500 は正面から見て右面吸気/左面排気)がありますし、古めの機材では上下方向で排気する機材もあったりします(上面吸気・下面排気)。

こういった検討にはオフィスのレイアウト図(縮尺の正確なもの)やラック図(ベイフェイスレイアウト)、ラック内のサーバ配置はおろか、サーバやストレージのモジュール構造、マウント方法、どこに NIC (ポート) があるか…など、物理的なあらゆる配置情報が必要になります。そのため、ビルあるいはDCの管理者、サーバやストレージの担当者などと綿密に話をしながら検討する必要があります。こういったことを整理し、ポリシを設定し、何をどうするか決めたところでようやく、必要な部材を確定して発注部材をまとめ、どこからどこに、何の線を引くか、という話を業者さんとやれるようになります。

さて。ネットワーク図の話に戻りますが…。

物理構成設計では、(物理的な位置として)どこに何があって、何のケーブルで、どうつながっているか、を決めます。もちろん図を書いて検討する必要があります。ただ、そこに持って行く前に、論理構成を物理構成の上に実現できているかどうかを見る必要があります。L3とL1の間 = L2、L2 といえば VLAN です。VLAN、最近だと VRF などの仮想化技術が間に挟まってきます。その上でさらに、STP や機材固有の冗長化機構などの話が入ってきます。もっともわかりにくく、最もややこしいところです。

物理構成図自体は、使うものと接続が決まっていればあとは根気の問題だと思います。(規模が大きい = 数が多いと、それはそれは面倒な作業ですが、やらなければいけない作業そのものはそこまで複雑ではないはずです。) 自分が大変だと思うのは、そこまで構成を落とし込む作業、作りたい論理構造を仮想化機能で分離し/束ね/実機の中に落とし込んだ上で、必要な要件を満たしているかどうか、物理構成上の冗長化や性能上のネックになりそうなところがないか、などを保証していく作業だと思います。

ネットワーク図の目的(Reprise)

最初の話に戻ります。図の目的として「論理構成をコンフィグに起こすための論理-物理マッピング」としました。

「論理と物理を分けろ」は必要なのだけど、「論理と物理をつなぐ図を書け」も必要なのですよ結局。VLAN を筆頭とした仮想化機能…VRF とか仮想デバイスコンテキスト(仮想ドメイン)などの機能を使う場合は特に。どの機材の、どのポートの、どのリンクに、何が通っているか? というのがわからなければ、結局実装もできないし、トラブルシュートもできない。物理構成だけでも足りないし、論理構成だけでも足りないのです。(目的に応じて必要な情報を載せた図を書こうね、というだけの話ですが。)

ということで、自分が書くネットワーク図は、論理から物理まで一緒くたにマッピングした図になっています。論理構成を把握する上では見づらく、物理構成の詳細を見たい場合には余計なものが入っていて必要な情報が足りません。ですが、実際に機材のコンフィグを入れる上ではこれが必要になります。なぜならどの機材のどこに、何の論理的な機能が載って、どういう仮想化機能を使って、ポート設定をしなければいけないか、を把握しなければいけないから。トラブルシュートする場合もこれが必要です。例えば、リンクダウンの SNMP Trap が上がったとして、それによって何のサービスが、どこまで影響を受けるのか? L2/L3 の冗長化機能によって経路が切り替わったとして、どこにトラフィックが迂回したか? 今後の対応として何をどうするべきか? という作業を検討する上では論理の情報も物理の情報もまとめて把握しておく必要があります。

もうちょっと言うと、実際に構築あるいは運用をする人は、こういった情報を脳内で合成した上で、いろいろ検討しているはずなのです。論理構成しか知らないとか、物理構成しか知らない、という状態では構築も運用もできないからです。「論理と物理を合成して、実際に作業をする上で必要な情報をまとめた図」が実務上では欲しくて、それを可視化したものを作っているつもりです。

まとめ

自分がよく作るネットワーク図をサンプルに、ネットワーク図を作る際にはこういう考え方もあるよ、という一例をあげてみました。ネットワーク図を書く際にはよく「論理と物理を分けろ」というのがセオリーとして言われますが、やりたいことに応じて適切な図を書こうね、っていってるだけなんですよね。別にネットワークに限りません。

ということで、論理も物理もマップした図をよく作っています。が、ややセオリーに反したことをするのであっという間に複雑化します。そこで効いてくるのがその他の「ヒント」であり「心得」だと思っています。…この辺はまた時間を見て書いてみようと思っています。