企業におけるキャンパスLANのほぼ全体がイーサネットとTCP/IPで構成されることが一般的になって数年が経過しました。キャンパスLANを利用するアプリケーションも“○○overIP”という言葉が多く聞かれるように多種多様化し、企業活動を支える重要な基盤に成長してきました。しかし、現実にはネットワークの無計画な構築、増設を繰り返した揚げ句、新しいアプリケーションに対応できないなどの問題を抱えているユーザーも多いようです。快適にかつ長期のキャンパスLAN利用のために最新機器・技術を用い、ふんだんに費用を掛けて構築するのも1つの方法ではありますが、今回は「ネットワーク設計の定石」ともいえる基本的な方法を用いたネットワーク設計の概略を準備、設計、構築と順を追ってご紹介したいと思います。
ネットワークを設計、構築する際の手順はほぼ同じと思いますが、以下の手順で実行することが多いように思います。
本稿ではこの順番に沿って、例を挙げながら設計、構築のプロセスを説明していきます。
最近ではスループットが高く低価格なインテリジェット型スイッチが多く市場に出回るようになったため、これらを活用して気軽に構築および展開できるようになっています。確かに詳細な通信量調査をすることも少なくなり、その意味では設計、構築が楽になったといえるでしょう。しかし、ネットワークに対する基本的なポリシーがなければ最終的には管理し切れない状態になってしまうのは変わりません。使い勝手も良く長く使えるネットワークを構築するためにあらかじめ基本方針を作ることが重要ですが、その第一歩は現状の把握と主な利用目的をはっきりさせることではないかと思います。最低限、以下の事柄を確認しておくべきでしょう。
これらの各項目は設計のポイントとなる要素でもあります。この項目に沿って整理できた事柄がそのままネットワーク構築のための要件となります。
ユーザー数の増減予測は構築すべきネットワークの規模を決定するための要素となります。次に現在利用しているアプリケーションと将来利用する可能性のあるアプリケーションを整理することで、ネットワークを利用するアプリケーションの重要度、優先度を決定できます。現状の問題点はいうまでもなく、新しいネットワークの構築に当たって改善すべき要素を示します。ユーザーの使い勝手は、構築されたネットワークに対するユーザーからの評価に直結しますので重要です。もちろん、企業活動なので良い評価を得なければ成功とはいえませんから、慎重に検討する必要があります。顧客情報や経理情報など、企業活動上の秘密として管理すべき情報が企業ネットワークには多く存在します。社員であればネットワークに自由に接続できることはもちろん重要ですが、セキュリティを確保しつつユーザーへ使いやすさを提供できる、ある意味矛盾のあるネットワークを構築する必要があります。これらの要素を設計に移す前に1つでも多くリストアップすることこそが、ネットワーク設計上最も重要な作業になります。
具体例として、架空の「A社」のネットワーク設計を説明していきたいと思います。もちろん、これがすべてではありません。読者の環境に合わせて検討してみるとよいでしょう。
現状の問題の整理や新しいネットワークで実現したい事柄はだいぶ整理されてきたと思いますが、具体的な設計に入る前に建物・電源に関する以下の項目は、調査・整理していた方がよいでしょう。
これらの情報の確認はつい忘れがちになる項目ですが、物理的な場所や電源容量が確保できなければ当然稼働できません。前回の資料が構築時との相違が多く、役に立たない場合もあり得ます。工事の要・不要は設計されたネットワークの機器配置計画によっても変わりますが、工事の手配・実施も構築の中で時間がかかる要素の1つですので、あらためて事前に調査・検討しておくとよいでしょう。
現状調査と利用計画ができた段階で、具体的なネットワークの設計と構築へ移行します。この時点ではすでに構築要件が固まってきていますので、要件を技術的に落とし込む作業になります。筆者が設計・構築を担当する場合は、以下の流れで進むことが多いです。
前項で現状利用中および今後導入が予想されるアプリケーションがリストアップされました。これらは業務上必要とされているものばかりですが、アプリケーションによってその特性や重要度が異なることもあり、無制御でネットワークへ流すわけにはいきません。業務上またはプロトコル上の重要度に合わせてランクごとに分類し、その順序に基づいてネットワーク機器で優先制御を実施して通信の最適化を図ります(どの位置で実施するかは別項目で検討することとします)。前出のA社の例に沿って、筆者の独断で大きく4つに分類すると以下のようになります。
A社の例では電話(VoIP)をランク1に据え、ERPの順位を下げました。人によっては疑問に思われるかもしれませんが、「業務上での重要性」と「通信プロトコルとしての不安定さ」を考慮して分類しました。ERPを利用する業務システムの通信プロトコルはTCP/IPであり、以前のようにSNAなどのホスト用プロトコルを使用しません。よって、以前ほど遅延を気にしなくても確実な通信が期待できるようになりました。ところが、ネットワーク上の品質条件が厳しいIP電話の考慮が必要不可欠になっています。IP電話はリアルタイム性を求めるため、遅延・揺らぎに対する条件はデータ通信より厳しくなります。e-mailは業務上のコミュニケーションのツールとして不可欠なアプリケーションではありますが、通信上はTCPを利用するため、優先度が下げられたことにより輻輳時に一時的なパケットロスなどが発生しても再送制御が期待できます。よって、実際には困ることは少ないため順位を下げています。
なぜ4分類なのか? と疑問に思われるかもしれません。4分類としたのは現状のネットワーク機器の大半が優先制御機能として4段階以上のキューイングに対応できることと、分かりやすくするという意味で検討しました。
次にネットワーク・トポロジーの検討に入ります。企業ネットワークのバックボーンにイーサネットが使われるようになるまでは(いまでも多く残っていますが)FDDIやATMなどが主流でしたので、バックボーンのトポロジとしてリング型、スター型、メッシュ型など多様な構成を取っていました。それぞれメリットがありましたが、イーサネットが主流になるにつれてスター型の構成が主流になっています。
本稿では基本的なエリア分けの分類とトポロジーを検討します。無線LAN、電話の配置について特性を考慮して別に検討します。
トポロジーを検討する際にはどうしても機器配置から考えてしまいますが、その前に構築するネットワークをエリア分けして検討するとよいと思います。エリアごとに役割や持たせるべき機能を明確にすることで、特定のネットワーク機器に無理に負荷を掛けることも避けられます。これにより効果的な機器選定ができるだけでなく、安定稼働の確保や障害発生時の問題切り分け時間の短縮に役立ちます。筆者は(前述のA社のような)中企業規模の構築では以下のように分類し、その境界に機器を配置して検討することが多いです。
ネットワークの規模がより大きい場合は配置される機器が多くなりますので、バックボーンエリアとユーザー接続エリアの間にもう1段「バックボーンアクセス」エリアを設けて考えます。これにより各エリアの範囲が小さくなり、エリアごとの必要条件の明確化が容易になります。
後はこれらのエリアごとに条件を付与していきます。A社の例で整理していきます。
サーバファームエリア
新しいネットワークの使い勝手の検討で指摘されたとおり、サーバ類はすべてこのエリアに集約します。トラフィックの大半(電話以外はほぼすべて)がここに集中しますので、バックボーンエリアとの接続帯域を太くし、ボトルネックにならないように配慮します。10Gbit/s対応の機器もありますが、現時点ではまだ高額ですので1Gbit/s接続を数本束ねるリンクアグリゲーションを使用してもよいでしょう。リンクアグリゲーション機能はいままではメーカーごとに独自に提供されていましたが、最近では標準規格(IEEE 802.3ad)にのっとった製品も出回っています。また、整備性も考慮し、シャーシ型の機器を使用したいところです。
バックボーンエリア
フロアをまたぐ通信のすべてがこのエリアを通ります。高速性を求めることも大事ですが、問題があっても通信が止まらないように整備する場合も考慮して、対策する必要があります。冗長性の考慮は次項に記述しますが、シャーシ型の機器を採用し、障害、増設時の対策はモジュール交換で対策できるようにします。バックボーンエリアとユーザー接続エリアの間は1Gbit/sで接続しますが、通信量の増加によってリンクアグリゲーションで拡張できるようにします。A社では当面ユーザー数の増加はないという予測ですが、バックボーンの機器には必ずスロット、ポートの余裕を持たせます。業務拡張時の接続点の確保や、障害時の緊急避難として対応が容易になります。
ユーザー接続エリア
文字通りユーザーのPCを接続するエリアです。サーバファームエリア、バックボーンエリアとは異なり、このエリアの機器1台の障害が通信全体を遮断することはありません。また、ユーザーのPCをそれぞれ接続しますので、機器台数も多く必要になることからなるべく安価な機器を選択し、コストを抑えた方がよいでしょう。故障時の交換を考慮して、実際の配置数より1、2台多めに購入しておくなどある程度、割り切ることも必要です。ただし、バックボーンエリアへデータを送出する際に最低限前項で分類したランク設定に基づいた優先制御は、このエリアの機器でも実施し、アプリケーションごとの通信品質を確保します。
次に電話(VoIP)についての検討です。内線電話のVoIP化はIP-PBXの普及やIP電話機をPCと同じようにネットワークに接続すればよいという手軽さもあり、従来のPBXを用いた内線電話からのコストダウンを目的として導入する企業が増えています。しかし一方、通話品質が悪くなることが頻出し困ったという相談や報告が増えています。その理由のほとんどが、ファイル転送などバースト的に帯域を消費中に音声通話用のパケットが重なることによる遅延でした。前項でも述べましたが、VoIPはネットワークのアプリケーションの中でも最もデリケートなアプリケーションの1つです。
安定した品質を確保するためにも、電話用のセグメントを一般のデータ通信用とは別に用意して、ユーザー接続エリア内では通信を分離し、ユーザー接続エリアスイッチで優先制御をさせてからバックボーンエリアに転送することを推奨します。最近のIP電話機にはスイッチ内蔵で優先制御ができる機器も販売されていますが、一般のボタン電話などと比べるとまだまだ高価なようですので、ネットワーク側で対応した方が低コストで済む場合が多いようです。また、今年、来年以降、今後はIP内線電話機の無線LAN化が進むといわれていますが、この場合も同様に音声用の無線LANをデータ通信用とは別に用意することを推奨します。
次は無線LANです。無線LANは機動性が特長ですので、この機動性を失わないように構築をするとともに脆弱性の対策をきちんと施すことが重要です。まずは電波強度の確保とアクセスポイント(AP)の配置計画を作ります。これによって無線LANの電波の届く範囲を検討します。確実に計画を立てるためにはサイトサーベイが必要ですが、大まかで構わないのならユーザー自身で簡易的にサイトサーベイをすることも可能です。無線LANのカード(特に海外製)に付属しているユーティリティには電波強度を表示する機能がありますので、これを使用します。APをある位置に置き、無線LANクライアントを室内で持ち歩き、いくつかのポイントで電波強度を計測します。APを数カ所移動して繰り返すとある程度の目安が作れます。ただし、少々手間が掛かりますので、手軽に済ます場合は無線LANスイッチなどを活用するとよいでしょう。価格はまだ高いですが、自動のチャンネル設計や配置のシミュレーションもできます。
最後にセキュリティの検討です。セキュリティというとどうしてもウイルス対策やインターネットからの侵入対策などが連想されますが、国内でも情報漏えい事件が多発し、LANアクセスでのセキュリティの対策を講じることがほぼ必須となりつつあります。最近では無線LANを中心としてIEEE 802.1X規格に対応の機器も増えており、ネットワークへアクセスするユーザーの特定ができるようになってきています。さらにIEEE 802.1X認証に合わせて自動でVLAN設定が切り替わる「ダイナミックVLAN」やユーザー単位でアクセス制限を自動で機器に設定できる「ダイナミックACL」などができる機器も出回り始め、ユーザーに機動性を提供しながらセキュリティを強化する構成が一般企業で導入されつつあります。拡張要件としてLANアクセスに対応できるシステムも視野に入れるとよいでしょう。
基本のネットワーク構成と無線・電話構成を組み合わせると、ほぼ図のようなネットワーク構成ができたと思います。
筆者は、普段の構築時にはできるだけシンプルな構成になるように心掛けています。ネットワーク機器も人間と同じで負荷を掛け過ぎると余裕がなくなり、故障する可能性が高くなります。エリア分けとシンプルな全体構成になることで負荷集中などを回避でき、結果壊れにくいネットワークを構築できることになります。
本来であれば前項で検討されるべき事柄と思いますが、あえて独立の項目として方法論に着目して検討したいと思います。「冗長化」と一言でくくってはいますが、大きく「機器の内部構成の冗長化」と「機器配置構成の冗長化」の2つがあります。また、後者は「経路制御」と「負荷分散」に分けられます。
前項で定義したエリアごとの冗長化要件を、A社の例に合わせて以下のとおり整理します。
これらを考慮して前項の図を修正すると次のようになると思います。
機器配置構成はこれで決定です。制御方法は全く同じトポロジを採用しても複数存在しますが、大きく以下の3種類から選択することになります。
スパニング・ツリーはIEEE 802.1dとして規定されているOSIのレイヤ2でのループを解消するためのプロトコルです。BPDUと呼ばれるデータと設定された優先度によって「ブロッキング」ポートを決定し、そのポートを論理的に通信できなくする方法です。広く一般的に使用されていますが、ネットワーク構成が変更された際の再構成に必要な時間の遅さ(30秒〜数分)が指摘されていました。最近ではIEEE802.1w ラピッド(高速)・スパニング・ツリー・プロトコル(RSTP:Rapid Spanning Tree Protocol)によりこの問題が解決されてきたほか、MST(Multiple Spannig-Trees:IEEE 802.1s)によってVLAN構成などをトリガに複数のSTP構成を設定することもできるようになっています。
VRRP(Virtual Router Redundancy Protocol)はRFC 2338で規定されているルータの多重化のためのプロトコル(参照記事:特集:10ギガビット・イーサネット大解剖)であり、STPと比較して構成変更時の処理速度の速い(数秒〜15秒程度)ことが特長です。同様の制御方式でHSRP、ESRP、FSRPなど独自に作成したプロトコルを利用しているメーカーもありますが、互換性は基本的にないと考えた方がよいでしょう。大まかな動作として複数のルータを1つのグループにまとめ、そのグループに対して「バーチャルルータ」を設定します。このバーチャルルータにはグループの中で最も優先度の高いルータのアドレスを「バーチャルアドレス」として設定し、通常はこのルータに自動的にデータが渡されます。しかしこのルータに障害が発生した場合は、自動的に次の順位のルータが設定を引き継ぎ通信が継続されます。プロトコルやネットワークアドレスなどを単位として複数のグループを設定することができます。
ルーティングで制御する方法は古典的な手法です。しかし、ターゲットに対して複数の経路が存在する経路制御には、管理者が比較的簡単に冗長化と負荷分散を両立できる方法として有効です。目的のセグメントに対するネットワーク上の距離になるようにトポロジを設計すると、たいていのルータ、L3スイッチは自動的に負荷分散をします。また、OSPF(Open Shortest Path First:参照記事:大規模で複雑なネットワークでの運用に堪えるOSPF)を応用して、プロトコルごとに経路を分けることも可能です。しかし、リンクごとに別々のネットワークにする必要があったり、機器の要件もL3スイッチが必須となり価格的なデメリットもあります。
A社の例では、通信の確実性とサーバエリアとバックボーンエリアの間はルーティング制御、バックボーンエリアとユーザーアクセスエリアの間はVRRPまたはルーティングで実施するという選択になります。
前段で冗長性を検討したとおり、「壊れないものは存在しない」ということが大前提です。「形あるものはいつか〜」とよくいわれるように、機器単体でも故障があり得ますが、システムですので故障する可能性は一層高くなります。日ごろからの管理・運用が重要ですが、少しでも楽にできるように検討したいと思います。
楽をするためにはツールを活用するか、お金をかけて管理委託してしまうのが一般的ですが、本稿では前者について検討します。ネットワーク機器は一般にSNMP(Simple Network Management Protocol) マネージャを利用して管理しています。若干高価ですが、機器選定時にSNMP対応の機器を選ぶとよいでしょう。マネージャの選択ですが、以下のポイントで自分自身に合ったものを選択するようお勧めします。
せっかく高機能の製品を購入しても使いこなせないと意味がありません。管理者自身が使いやすいと思える製品を検討・選択することが効率的な運用の第一歩となります。また、障害発生時は「どの機器のどの部分が故障したか」をいち早く見つけることが重要です。その意味でも障害を検知した機器の物理的な配置が分かっていればが対策に着手するまでの時間を短くできるようです。また、障害通知機能は複数選択できるものがほとんどですので、在席時は音を鳴らす、ランプで通知するなどの方法を取り、不在時はメールで携帯に通知させるなど使い分けるとよいでしょう。また、通信量の調査も定期的に実施することもお勧めします。MRTGなどフリーのツールも存在します。定期的な調査で変化を記録しておくと、次回の更新や見直しの有力な材料として活用できます。
一般的な事業活動ではPDCAサイクルを用いた管理手法が一般化してきていますが、ネットワークもPDCAサイクルによって管理されるべきものです。最近は市場の変化も激しく、構築時から短期間で組織や使い方が変化してしまうことも珍しくありません。とはいえ使える予算には限りがあります。構築計画(Plan)、設計構築(Do)、管理・運用を通した利用評価(Check)、見直し検討(Action)の繰り返しで、日常の管理・運用が結果としてネットワークを事業活動に対する有効なツールとして維持・進化するための重要な要素となります。
一般的なキャンパスネットワーク構築の基本的な手法としていくつかの例を挙げながら紹介してきました。もちろんこれがすべてではありません。状況に応じて柔軟な設計をすることが重要です。本稿が読者のネットワーク構築に対して若干でも貢献できれば幸いです。
後編はWANでのネットワーク設計の定石について解説します。
Copyright © ITmedia, Inc. All Rights Reserved.