ネットワーク図を書くときに考えること(2)
はじめに
1回目を書いてからまたしばらく間をあけてしまいましたが…。しかもその間で図をいったん全部書き直したりしているし。図は再掲します(Visioで書き直しました。)
2回目では「ヒント」「心得」についていくつか見ていこうと思います。1回目は「何のために書くのか目的をはっきりさせる」「物理構成と論理構成を分離する」という点についてでした。今回は「ルールを決めよ」「大胆に省略せよ」「簡潔さを保つ」です。「省略」と「簡潔さ」はだいたい同じことを言っていると思います。そして、そのためにはルール設定が必要です。
ネットワーク図のルール
ネットワーク図にはルールが必要です。まあ別にネットワーク図に限らず、技術文書に書くべき図には(…技術文書自体も)どれもルールが必要なのですが。なぜルールが必要なのでしょうか?
- スタイルや表記方法を統一する
- 読者の負荷を軽減する
- 誤解を防ぐ
- 記載する情報を簡略化する・あるいは圧縮する
細かく書けばもうちょっとあるでしょうけど、重要なのはまずこの辺だと思います。また例を見ながら書いていきます。
サンプルに見るネットワーク図のルール設定例
自宅のネットワーク図では以下のようなルールを採用しました。要素別に具体例を見ていきます。
通信を行う端末・機材・役割・プロセスの表記
- 物理的な機材(筐体)、仮想的な機材(インスタンス)、ネットワーク機器などの役割に応じた表記を考えます。
- Visio等ではスイッチやルータのアイコンが用意されていますが、こうした詳細な構成図を書く場合、個人的にはあまりアイコンを使いません。アイコンにするとレイアウトの柔軟さや埋め込める情報量が減ってしまうので…。
ポート・接続種別・コネクタ形状など接続規格
- ポートやリンクにも物理的な種別(ケーブルの種別やコネクタの形状)、役割(アクセス・トランク)、仮想化や論理構成(リンクアグリゲートや論理インタフェースなど)に応じて表記を考えます。
- 以下に一部抜粋したものを載せますが、これだけで、core では Gi1/0/1-2 を link aggregate したうえで Po1 を構成している、Po1 は Trunk として設定されている、Trunk には VLAN 701, 901 など複数の VLAN が許可されている、といったことが読み取れます。
- ポート種別はポート名でもわかりますが、GbE では太線を使用しています。(リンクの帯域で線の太さを変えてみる)
- trunk/access はポートの色によって判別できます。(trunk は黒, access はVLAN別の色) また、Trunk に流れているVLANは、スイッチ内部のどのVLANセグメントがそのTrunkに流入しているかで判別できます。
- Channel (LAG) は複数の物理ポートを束ねる書き方 (Poポート) をしていることで判別できます。
- 今の環境では光ファイバなどを使っていないため特に書き方を分けてはいませんが、線の端点を変えることでコネクタ形状を判別できるようにしたり(例えば端点が○ならLC, ●ならSCとか)というのをよくやります。
- このへんまでルールが設定してあると、図を見ただけでほぼ自動的にポートのコンフィグを起こすことができます。
- とはいえ speed/duplex/mdix などの設定やあるいは LACP を使うかどうかといった内容はこれではわかりません。いまの環境内では LACP はナシ (mode on), speed/duplex/mdix はすべて auto という暗黙のポリシ設定があります。必要に応じてこうしたポリシ設定を書き分ける必要があります。
VLAN, IP, ルーティング
- 物理・論理マッピングを考える上でまずはじめに問題になるのが VLAN まわりの表記です。L3 の構造がどのように L1 にマッピングされているかが分かるように記載する必要があります。
- ネットワーク機器の中で作るべき VLAN を端点が丸い線で記述しています。ポートもルーテッドで使うかスイッチポートとして使うかという使い分けがありますが、下の図のように、何らかの VLAN とひもづかないポート(Gi0, Fa8)はルーテッドポートです。この場合、物理ポートが直接セグメントの端点になっており、ルーティングプロセス(GRT)とひも付いています。物理インタフェースとルーティングインスタンスとの間に VLAN が入る物理ポート(Fa6など)はスイッチポートであり、ルーティングプロセスとは SVI でひも付くことになります。(Cisco の場合、SVI の名前は VLAN 名なのでこれで特定できる。)
- この場合、VLAN2 のように VLAN だけがあってルーティングプロセスにつながらないものは、単なるL2のセグメント(VLAN)が切ってあるだけで、その機器内ではルーティング対象になっていないことを示しています。
- 視認性を向上させる + trunk/access の使い分けを明示するためにVLAN/セグメントには色をつけてあります。物理ポートからVLAN の色の線がそのまま外に出ている場合は、その色の VLAN の access port ですし、黒い線で複数の VLAN を束ねて外に出ている場合は trunk port です。
- セグメントにはネットワークアドレスを併記(VLANの場合はVLAN IDも)し、インタフェースが持つアドレスを、ネットワークアドレスに対して末尾の部分だけ記載しています。こうすることでアドレスの表記を簡略化しています。
色の使い分け
- 重要度、セキュリティレベル、位置、など何らかの方針で色の使い分けを考えることでルール設定ができます。そこに、構築上、あるいは運用上の注意点などをひもづけていくことも考えられるでしょう。ただし、使う色は増えれば増えるほど識別するのが難しくなります。色の数が多い場合は、個々の色を判読しなければ判断できないようなルール設定は避けるべきです。(色系統によるおおざっぱな分類程度にとどめる。)
- VLAN(セグメント)には色を設定してあります。色は、赤〜茶色系統が実験系、青〜緑系統が内部、橙がストレージ系、といったようにある程度の使いわけをしています。
形や位置の使い分け
- ヒントの「アイコンを整列させる」にも通じますが、図としてみたときの階層性や対称性を意識してください。
- 冗長に2系統用意している場合は、対応する機器の水平位置や対称性をそろえるようにします。(ポジションによる役割・ルール設定) 水平/垂直/対称性を応用することで、図のレイアウトを統一することができます。
- また、そのルールからはみ出たものに対する注意を引くことができます。(特殊な要件のために追加で切れた機材や、冗長性を捨てて臨時で入っている機材などはこれらのルールに入らないため、必然的に「浮いた」位置に配置されます。)
- 同じ役割で並ぶオブジェクトや線の間隔はそろえましょう。斜めに線を引く場合には角度をそろえるとグルーピングするような効果が出ます。
- Visio では「角を丸める」機能があります。実際にやってみるとわかりますが、すべて通常の四角形で書いてみると、思いのほか図形の見分けが付かず、メリハリのない図になってしまいます。鋭角と丸など図形の使い分けを加えることで判別のしやすさが変わってきます。線の角を丸めた例を載せてみますが、結構印象や視認性に違いがあるのが分かるのではないかと思います。
「ルールを設定する」とはどういうことか
ルールを設定することで、表記を簡略化し、図により多くの情報を埋め込むことができます。ただし、これは言い換えると、表記方法を知らないと図を読み取ることができない、ということでもあります。多くの情報を書き方やルールに置き換えて図に埋め込んであるため、そのルールを知らないと情報をデコードしていくことができません。電気回路図や建物の設計図は記号や表記方法を知らないと意味不明なのと同じです。ネットワーク図だって同じ技術設計図だと思うのですが、あまりそういうものであるという理解がされない気がしますね…。
- 凡例をつけましょう
- 場合によっては、上で書いたような表記方法をまとめたドキュメントが必要になるケースがあります。また複数人で図を書く場合には統一されたルールがないととんでもない目に遭います。
- 図の中で何をどこまで、どのように埋めるかは使っている機材や技術によりけりで違いがあります。いま例として取り上げている図は「論理と物理の間を埋める」「コンフィグを作る際に必要になることを記載する」のが目的ですが、Cisco の機材を使っているために省略できていることもあります。
- たとえば SVI の名前などの記載は省略されていますが、もし Juniper の機材がある場合はそれらの点も明記する必要があります。(VLAN の論理インタフェース名を利用者が指定する必要があるため。)
- コンフィグに起こすために必要な情報をすべて記載しているわけではありません。例えば、経路制御の情報をほとんど記載していません。これは、経路制御設定については物理なし、L3 のみのネットワーク図で考える方が遙かにわかりやすいためです。同様にACL などの設定ポリシについても別になっています。記載する内容は、図の目的に合わせて「L1-L3 の情報をマッピングしないとわかりにくいこと」を中心にしてあります。
「省略・略記する」とはどういうことか
省略・略記もまた情報の圧縮です。(略記は一部の情報を切り捨てることでもあります。) 省略・簡略化する場合には、その図の中で注目すべき点が何か、省略することで失われる情報は本当に図の中では重要でない情報なのか、といった点を考える必要があります。図の目的に沿って、省けるところはどんどん省きます。
- 例えば、下の二つの図、ESXi の内部の接続については、仮想マシン-vSwitch間の接続は束ねてしまっています。しかし、シリアルコンソールサーバ-各機器の con0 の接続などはすべて個別の線として個別に記載してあります。これは、物理接続検討を行う上で、物理的に別のリンクは個別に扱うべきだからです。ESXi の内部、仮想マシン〜vSwitch 間接続は論理的なもので、どの vSwitch に接続されるか、という以上のことを認識する必要がないためにすべて束ねて記載しています。
- 省略や簡略化には、多数のサーバや端末など、用途や役割が同じものをまとめる(グループ化する)、あるいはここから先は外部、ということである点から先のネットワークを雲形でぼんやりまとめて書いてしまう(省略する)、といったパターンが考えられます。
- 省略の例: 無線LANセグメントについては、アイコンで表記しただけで、そこに接続してくる端末については省略してしまっています。接続してくる端末はノートPCだけでなくスマートフォンなどが考えられるため一意にしにくいこと、無線LANで接続してくる時点でアクセス方法や接続ポリシが同じものとしてまとめてみることができること、が理由として挙げられます。
- グループ化の例: 以下のように実験用に割り当てられた VLAN はすべてグループ化して同じように記載してしまっています。実験用という予約と割り当てがされていること/そこから先の用途はやりたいことによって変化することから、ひとかたまりに束ねてしまっています。
「図」を書く上の考慮点
- 最終的なアウトプットの形を考える
- 最終的に紙に印刷するのであれば、用紙サイズに収まるかどうか、フォントサイズが小さすぎて読めないなどの不具合がないかどうか、考える必要があります。
- 個人的な失敗談なのですが、かなりサイズの大きな図を作ってしまって失敗したことがあります。作業中は電子データとして参照していたのであまり問題ではなかったのでですが、いざドキュメント納品段階になって、指定された用紙サイズにどうしても収まらず、図を描き直す羽目になったことがあります。
- 紙に収まるかどうか、不自然な空白の有無、印刷時のレイアウト、サイズのミスマッチ(図のオブジェクトに対してフォントサイズが小さすぎる・大きすぎるなど)がないかどうかは考えておく必要があります。
- 他のドキュメントのリンクとなる情報を押さえる
- 物理構成という意味では、例えばどのラックに入っているかという情報も実運用上では必要になります。例えば、ネットワーク図上で機器間の物理配線を検討した上で、どのラックのどこからどこに、どのくらいの長さのケーブルを何本、というような見積もりをします。
- 資料間で統一される情報は何でしょうか。例えばホスト名かもしれませんし、あるいはネットワーク図上に物理設置位置を書いてしまうという方法も考えられます。資料の間での連携を見落とすと、使いどころのない図になってしまうかもしれません。
おわりに
もうちょっとメタな方法論の話が書ければ良かったのですが、いざ書いてみると難しいですね。基本的な考え方はありますが、それをどのように表現・表記するかは目的によってかなり大きく変わってくると思います。特に今回のように L1 まで含めるとなると、実際の機材や使っている技術・機能によって適した内容や書き方は異なります。単純に L3 の構成図、という話であれば、機器や技術への依存性がほとんどないのでほぼ統一した書き方ができるようになりますが、レイヤを下げるとどうしても依存性があります。
こうした依存性の強さや目的によって内容が大きく変動する当たりが難しいところで、たとえば電気回路図のような規格が生まれない要因でもあると思います。目的と書き手によってかなり表現に違いがあることが予想されます。つまり、ネットワーク図を書くという作業は、わりと属人的で、書き手の腕の見せ所でもある…と言うことです。
今回は個人的によくやるのはこういうこと、という一例を取りだしてみました。こういう考え方もあるよね、というサンプルとして何かに使ってもらえれば良いのだと思います。
