ネットワークを考えるときに考えること(4)

memo

機能要件を考える

続きです。下に書いてあるのは機能要件の話なのか? といわれると微妙ではありますが…。アーキテクチャ検討の観点とかそういう方向だと思ってください。

境界と接続方式

管理ポリシの異なるドメインが重なる(相互接続する)ところはすべて「境界」です。例えば、システム間、セグメント間、セキュリティゾーン間…など。

  • ポリシ
    • 設計上どういった方式、方針でどのように接続するのか。
    • 管理上の境界点はどこか。誰が何をどこまで管理するのか。
    • 境界点で何を(何のためにどんな情報を)やりとりするのか。
  • 物理接続方式
  • 冗長化プロトコル・冗長化方式
    • L3であればOSPFなどの動的経路制御による冗長化を行うケースもあるし、専用アプライアンス製品を挟むような場合もある。
    • L2での接続は STP とループ回避方法が要注意
    • サーバ(ネットワークに接続する通信ノード)の場合はNIC冗長化方式(bonding/teaming)
    • LAGの利用の要否
    • 仮想化基盤、Hypervisor つかっているところや、仮想アプライアンスを使っているところでは、誰が何をどこまで見るべきか、運用上どのコンポーネントをどう担当させるか、などを考えることになります。
      • vSwitchのVLAN設定、NIC冗長化の方式やL2ループ防止の方式なども仮想化基盤方式と合わせて考えてください。
  • 管理
    • 難しいところですね…。システム間(管理単位)境界というのもありますが、技術担当者境界(ネットワーク担当者が何をどこまで見るのか)なんて話もあります。

複数の、管理主体が違うもの(システム)同士を接続するケースでは、IPアドレス(セグメント)の共有(L2ならさらにVLAN IDの共有)など、共有するものが相互に一意になる必要があり、また共有リソースをどういった方針で管理するかについても検討する必要があります。これも極力最初にやる必要がありますね…。

時間変化・時間的前後関係

通信は時間軸シーケンシャルに行われます。ネットワークシステムにおける「変化」は時間に沿って発生します。したがって時間軸に沿って変動するモノ、シーケンス、手順、フェーズなどを検討しておく必要があります。

  • 移行シーケンス
    • 旧システムの移行などを行う場合、ネットワークとして何をつなぐか、移行させるためにどういった通信が必要か。
      • 移行時に必要な、一時的な余剰を入れられるような作りになっているかどうか。
    • 移行中(移行フェーズ)ごとのテンポラリな構成、それらの経路設計や冗長化方式、切り替え時の作業や影響などは別途検討が必要です。
  • 変化・変動のシーケンス
    • 障害発生時の切り替え・切り戻しのシーケンスと時間順序
      • どういうイベントに対して、どういう変化が発生し、どのような時間変化をたどるのか。
    • システムの変更
    • システムの拡張
    • その上を流れる通信に対して与える影響
共有/占有, 分離/結合

リソースやセグメントの分割、L3/L2マッピングの話は、何をどこまで共有するか・占有するか、という話でもあります。求められる通信帯域やセキュリティ的な観点に応じて共有・分散の方針を決めていく必要があります。

  • リソース観点での共有・占有: 回線や帯域の共有・専有
    • VLANを使うと言うことはひとつの物理リンクを複数のセグメントで共有するということでもあります。
    • LAGなど物理構成上の点を加味した上でどのリンクでどの程度の「幅」「太さ」を用意していくかを検討します。
      • LAGにあたってひとつ勘違いされることが多いのは、ひとつのフローで流せるのはLAGを構成する物理リンクの帯域上限によって制限されると言うことです。例えば 1Gbps のリンクを4本束ねた場合、論理的には 4Gbps のリンクに見える…と思うかもしれませんが、実態としては通信フローごとに4本の物理リンクのどこか振り分けられているに過ぎません。したがって、ひとつのフローが物理リンクの上限(1Gbps)を超えてトラフィックを流せるわけではありません。多数のフローがLAGを経由すると、全体的には4Gbpsのトラフィックがひとつの論理リンクを流れているように見えます。
    • リソースをどのようにコントロールするかは、リソースの量及び重要度によって決定されます。
      • 占有させる(物理NICやVLANを分けてネットワーク設計する、QoS等でリソース量を確保する): 重要度も量も多い…クラスタリング系(keepaliveなど)、ストレージ系、バックアップ系, 量は少ないが重要…リモートアクセスや監視系、など。
  • セキュリティやポリシ分離としての共有・専有
    • サービス上の分離: システムごとの独立性・顧客やユーザごとの独立性、マルチテナントサービスなど。
    • ポリシ上の分離: 重要度やセキュリティ上の要件、アクセス箇所の限定や分離、管理するデータの重要度や秘匿性に応じたアクセス権限・アクセスパスの制限など。
    • ネットワークではL2セグメントを分ける + セグメント間の通信を制限する、というのが基本的なポリシの分離方法になります。(L2セグメントを分けることで、必ずL3機器を経由しなければ通信ができない状態になる・直接通信ができなくなる)
      • あとは802.1x認証(認証VLAN)やMACアドレスの登録などもうちょっと違う方法もあるけど、その辺は使うところや要件に応じて選択を。
    • セグメント分割(L2)だけでなく、VR/VRFなどをつかったL3での論理構成分離などを行うことができます。
    • ひとつのデバイス(デバイスの計算機処理能力もまたリソースです。VLANやVR/VRFなどの仮想化機能を使用して、何をどこまで共有・専有させるかを検討します。
集中/分散, 統合/分割

上記の共有/占有とも関連して。共有するというのは複数の要素がひとつに集中するということでもあります。集中・分散は通常トレードオフの関係になります。必要な機能・コスト・サービスレベルに合わせてどの程度のバランスにするかを検討する必要があります。

  • 集中
    • コンポーネント数の削減
      • 機器コストの削減: UTMの導入など、従来複数の機器で行っていた機能をひとつの機器で実現する、VR/VRF/VLANなど複数の論理構成要素をひとつの物理機器で実現する。
      • 管理コストの削減: ひとつの機器で複数の要素を一括管理させることで管理方法をシンプルにする。物理的な構成要素を減らしてネットワーク構造をシンプルにする。
    • 影響範囲の拡大
      • 障害やキャパシティ管理など、ひとつのポイントで発生する影響が広範囲に広がる。
    • 拡張性とキャパシティ管理
      • 原則スケールアップ型になる。リソース上限に達したときの拡張法が難しい、あるいはスケールアップ時の初期コストが大きくなる可能性がある。
      • デバイスのCPU/メモリや設定可能な各種リソースの上限値などに注意しつつキャパシティ管理やリソース管理が必要。
  • 分散
    • 複雑化
      • 管理・制御ポイントの数が大きくなるに従って、管理コストや環境そのものの複雑度の上昇が発生する。
    • 影響範囲の縮小
      • 障害やキャパシティ管理など、ひとつのポイントで発生する影響範囲が限定される。
    • 拡張性
      • 原則スケールアウト型になる。ただし、拡張可能な構成や拡張方針を定義しておかなければ、拡張に伴って環境の複雑度が増大し、管理や問題の識別・キャパシティ管理のためのコストが跳ね上がる可能性がある。(ここで言う「複雑度」は組み合わせによって発生するものなので、非線形…というか指数関数的にあがる、と思って良い)
      • 分酸性を確保するための仕組み(動的経路制御やそのためのリソース)などに注意しつつキャパシティ管理やリソース管理が必要。

どちらにもメリット・デメリットがあります。理想的なのは物理的には分散・スケールアウトさせつつ論理(管理・制御)的には集中させられることです。そのためのプロトコルやネットワーク構成方法は、使う機器やプロトコルなどに応じていろいろ選択肢があります。システムとして求められているサービスレベルや拡張性、運用管理の方針などに合わせて検討します。

次回

求められている通信が実現できるようになったら、求められている質とか量とかが満たせているかという話を見ます。そんなわけで次は非機能要件の話。