ネットワークを考えるときに考えること(2)
ネットワーク検討のためのインプットを考える
何事もインプットに対して処理があってアウトプットがあります。では、「ネットワーク(設計)」をアウトプットとした場合に必要なインプットとは何でしょうか?
全体的な要件は何か?
全般的に言えるのは、ネットワークはネットワークを必要とする物(システム)によって決定されると言うことです。ネットワークの要件は、「ネットワークの上で流すべき(ネットワークによって実現されるべき)通信」によって決定されます。これには
- トポロジ的要素: 通信ノードがどこにいて、どのノードと通信するのか
- 物理的配置(物理トポロジ)と論理的配置(論理トポロジ)があります。
- アプリケーション的要素: どういう通信が必要か
- いわゆる非機能的な要素全般。どういうプロトコルで、どのくらいのデータ量で、どの程度の通信品質で…など。
といった内容が含まれます。なので、ネットワーク設計のインプットとしては、ネットワークの上に載るシステムの通信的側面全般が入ってきます。上物全部についての理解…というと非常に難しいのですが、せめて上物のデータフロー的側面を押さえましょう。対象とするネットワーク上で、input/output, store, forward, process を行う要素は何でしょうか? 通信フロー source/destination, application はどういったものになりますか? それらのフローの特性はどういった物になりますか?
通信要件の検討
通信のトリガになる物、主体として何かしらのデータフローを発生させる物は何でしょうか?
- 主体(登場人物)
- 人
- システムを利用する人、エンドユーザ(顧客)
- 作る人(構築担当者)
- 運用する人(システム管理者)
- モノ・システム
- PC(デスクトップPC, ノートPC...)
- サーバ、その他ネットワークを必要とするすべての機器
- 他のシステム(連携先システム)
- インターネット上の何か
- 人
- 場所
- 地理的(物理的)な位置, オフィス、部屋、フロア、ビル、拠点、店、自宅…
- インターネット上のどこか
- 役割(ロール)と権限
- システム上・業務上何をどういう単位で分割すべきか。一緒にしていいところ・一緒にしてはいけないところは何か。
- 主体の役割
- 部署、会社
- アクセス方法
- 管理するデータ、参照・操作可能な領域
- システム上・業務上何をどういう単位で分割すべきか。一緒にしていいところ・一緒にしてはいけないところは何か。
ネットワーク上に置くべき「モノ」が見えたらモノ同士の関係性を考えます。ネットワーク検討におけるユースケース検討といてもいいのかと思いますが、基本的には通信フローとして、どのノードが、どのノードに対して、どういう通信を発生させるか、という点を検討します。
- 操作と位置
- 使い方(誰が、どこから、何を、どう使うか)
- 業務単位で誰が何をどこからどう使うかというのを考えます。必要に応じてそこから詳細化します。
- 何がどこにあるか
- 特に物理的な…地理的な配置を確認しましょう。最初に書いたとおり、ネットワーク設計においては物理的な位置や距離の考慮が必要です。
- 使い方(誰が、どこから、何を、どう使うか)
- システムあるいはサービスを実現させるための機能
- 通常、システムとして必要な機能(例えばエンドユーザに対して実現させるべき機能)の他に、システムそのものを構築・運用・管理していくための操作が別途あります(例えばバックアップを取る、など)。
- システム(サービス)として必要な機能・非機能(表)だけでなく、それを支えるための機能・非機能(裏)についても考慮が必要です。
特性・特徴の検討
特性については早めに検討しておく必要があります。とはいっても、(私の)経験上、アプリケーションとかやってる人たちがこうしたネットワーク特性等の条件についてこうしろと言ってくれることはなかなかありません…。絶対に認識してもらう必要があるのは、ネットワークはいつでもどこでも待ち時間ゼロで通信を実現できる魔法の箱ではありません、ということです。たとえば「VPNによって遅延なしで任意の箇所から当システムに接続できること」なんて条件が書いてあるRFPを見たことがあるのですが、そもそも光の速度に物理的限界がある以上、何をどうやったって距離による遅延は発生しますからねえ…。中継機器でのデータ処理の時間が加算されていくし。地球の裏側からVPNして遅延ゼロなんてことは物理的に不可能なわけです。必要なのは、実用上問題が無いのはどの程度までなのか、という許容範囲の設定です。
この辺が出てきたら要注意、というのを少し書いておきます。
- 他システム連携
- 他のシステム(他拠点にあるシステム、既存システム、他社システム、など)との連動・連携が必要な場合は、連携先システムと接続する際に求められる条件を早めに入手しておく必要があります。IPアドレス体系、接続時の物理構成(回線、物理メディアなど)、接続冗長化方式や利用可能なプロトコル、テスト方法、接続調整の窓口、接続の申請方法やリードタイムなど。とくに複数のシステムが連動するシステムではこうした条件は厳密に定義されているはずです。
- ネットワーク設計をやる以上、自分の設計範囲のことについてはそれなりにコントロールが効くはずですが、それ以外のシステムやネットワークについては自由にコントロールすることはできません。ネットワークが自律分散システムとして成立している以上これは覆せません。「自身で責任を持ってコントロールできないもの」に対しては注意して連携方法を検討していく必要があります。
- レガシ環境
- ストレージ系(IPストレージ)
- 大抵データ量が大量です。ストレージに求められるI/O要件に対して必要な帯域をちゃんと考えましょう。
- あとCIFSは結構通信遅延が効いてきます。ファイルサーバの配置なんかは要注意(拠点にファイルサーバおかずに中央集中、みたいな構造をうかつにやると、拠点からのファイルアクセスが異常に遅い、なんてこともありうる)。
- 大量データアクセス
- 音声(VoIP), リアルタイム通信系, 動画や画面配信系
- 即時性が求められるアプリケーションは通信遅延に敏感です。最近だと VDI(DaaS) とか? あと音声系の場合、専用のセグメントを切るとかネットワーク設計上の考慮点があったりしたはず。
- 同じ建物内くらいであれば間のホップ数をむやみに増やさない、という程度でしょうけど…。インターネットを挟む、VPNを挟む、など通信品質保証が難しいところを経由する場合は、安請け合いしないで事前検証の提案などを入れるのが無難だと思われます。
- 無線系(Wifi)
- 無線の話はそれはそれで考えるべき事がいっぱいあるので今回は省略…
- 非Ethernet, 非TCP/IPな通信プロトコルを必要とする通信や特殊なアプリケーションの有無
- メインフレーム系が残っているようなところでは注意しましょう。SNAとかいるんですとかあとで言われると機器選定がひっくり返ります。
- アプリケーションによっては、end-to-end で直接通信できなければいけない(NATしてはいけない)というアプリやシステムがあることがあります。これもクラスタリングシステムや、監視系エージェント通信なんかだったかな…。
- MACをIDとして(識別子として)使うシステムや、IPアドレスをIDとして使うシステム(アプリケーション)がある場合にも注意してください。MACが見える形で(つまりL2直結で)つながなければいけないとか、ライセンス認証がIP紐付けされていて、IP変更してはいけない、なんて話があるかもしれません*1。
- マルチキャスト系
- 個人的にはコレに当たったことがないのですが、マルチキャストを使うようなアプリケーションがある場合は注意した方が良いと思います。
- 認証系
- 認証VLANとか。認証システム側の方(認証側で持つアカウント情報やデータをどうするか、業務上どういった情報に基づいてどうネットワークを設定するのか)にも踏み込んで検討することが必要になります。機材選定の基準も変わってくるし。
あと通信特性について。
- 遅延
- 上述しましたが、遅延が効くアプリケーションというのがあります。
- 帯域・パケット処理速度
- 単純に何Mbps, 何Gbps, という話派もちろんなのですが、特にレイヤの高い装置においては pps で考えるべきケースがあります。例えば、携帯系Webシステムなんかはショートパケットが大量に降ってくるのでーデータ量ではなく pps 頭打ちになってしまう、なんて話もあったりしました。(こうした話を事前に検討するのは難しいのですが…。)
- パケットロス頻度などの通信品質
- 今時の回線サービスでこうした話が問題になるケースはもうほとんど聞かないですが、古い回線(細い回線)を使わなければいけないケースやインターネットを経由する通信についてはこうした特性が影響しうると言うのは検討に含めた方が良いと思われます。あるいはシステム高負荷時のトラブルとして。
- 時間
- ネットワークの特性は end-to-end の一番弱い(細い)ところできまります。
- すべてのノード感で太いパイプを引いてしまうのが一番楽なんですが、必ずしもそうできないケースは考慮が必要で、一部重ね合わせ(線の共有)を考えていく必要があります。
- 共有を考える場合、時間的特性を考えると棲み分けができることがあります。営業時間帯にピークを迎える業務システムと、夜間バッチのアプリケーションサーバで…など。
物理配置を検討する
ネットワーク図を書くときに考えること でもネットワークの物理設計という話について書いてあるのでそっちも見てください。お仕事上はこういった情報を集めましょう。物理配置・物理空間の話はいわば不動産の話です。時間のかかる調達調整が必要になり得ます。早いうちに状況を把握し調達計画を立てましょう。
- 縮尺の正確なオフィスやフロアのレイアウト図
- ちゃんとCADで書かれた縮尺の正確なフロアレイアウト図やラックレイアウト図なんかがあるのが望ましいです。ネットワークの物理構成要素…ケーブルとか、には、通常物理的な長さ制限が規格として定めてあります。声が届く範囲に限界があるように、物理信号は媒体中で必ず減衰するため、物理的な距離には上限があります。
- 図面上で必要な配線経路や距離を見積もることができるだけの情報をなるべく早めに集めましょう。
- 現状と合わせてどこまで正確か、というのは確認が必要です。じつは容れられると思っていた場所がもう使われてた…なんてことが無いですか?
- 動かせないもののチェック
- ファシリティ面での要素は実質動かせません。動かせないものに合わせて配置したりつないでやったりする必要があります。
- 電源の位置、口数/口の規格、電圧・電流定格など、機器設置に必要な情報を集めておきましょう。
- 配線経路(ラック間、フロア内・フロア間など)をフロアレイアウト図などと照らし合わせて確認してください。通常、ビル管理会社やデータセンタ管理者との調整になります。フロアをまたぐなど、自社(自システム)の占有スペース外、共有スペースをまたぐような接続が必要な場合には適切な調整を取る必要があります。場合によっては、ビル間の配線スペースが既に埋まっている…などの問題があるかもしれません。
- こうした都合と関連して、上位キャリアと接続するための回線など、外部との接続用回線については出せる位置や設置可能なスペースなどが限定されることが多くあります。
- 配線盤の話、HDFとかMDFとかケーブリングシステムあるいは構造化ケーブリングの話について知っておくと良いと思われます。(O'Reilly 詳説イーサネット がおすすめ)
- オフィスビルとかだと、防火設備とか消防法の都合で置けるモノが制限されたりすることがあります。
- 意外と、必要なラックの奥行きを見落としがちです。最近のネットワーク機器は奥行きが深くなっています。それなりの奥行きが必要なケースがあるので注意を。
- 場所にも寄りますが、特にオフィスとかのネットワークやる場合は、ホコリがひどいとか高温とか多湿とか、通常機器を設置するのに向かない環境に置かなければいけないケースがあり得るので現地調査やれるときはそういうところも見てください。人通りの多いところでファン音が迷惑じゃないかとか、ついうっかり掃除のおばちゃんがぶつけてしまうとか、そういうことが起きないような場所かどうか見る、なんて話もあります。
次回
必要な情報が集まったらネットワークに求められる機能を考えましょう。ということで機能要件の話をします。
*1:ネットワークの話と外れますが、ソフトウェアのライセンス紐付けが何によって行われているかというのは気をつけた方がいいです。紐付けやバックアップの話はその後の資産管理とかID管理とかに絡んでくるので。
