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

memo

機能要件を考える

通信要件の検討ができていれば、ネットワークとして実現すべき機能の話がだいたい見えてくるはずです。機能的側面に関しての検討ポイントをいくつか挙げていきます。挙げていくのはあくまでも「観点」であり、特定の側面です。が、ひとつの技術が複数の観点で利用されることは良くあります(例えばLBは負荷分散・拡張性の確保という観点でも検討されますし、冗長性という観点でも検討されます)。ネットワーク(だけに限らず)設計においては、こうした様々な観点を元に、どういったメリット・デメリットがあるか、どこを優先しどこをあきらめるかを繰り返し考えながら最終的なバランスを決定していきます。

サービスとサービスレベル
  • システム全体として、何を、どのレベルまで実現すべきか(どのレベルを目標にするか)を定義しましょう。
  • システム全体のサービスレベルを実現するために、どこで何を担保すべきかを考えておく必要があります。例えば、アプリケーション側でデータの分散や保全を管理するのでネットワーク側は冗長経路と障害時の経路切り替えをどの程度保証しなければいけないとか、サーバ側は情報を持たずにシンプルな作りにしてLBによる振り替えで機能維持する、とか。
  • 数値目標が決まっていることが望ましいですが、せめて方針は考える必要があります。多少コスト高・冗長でもよいので安定性と耐障害性を選ぶのか、低コストであることを選ぶのか、拡張可能であることを選ぶのか…など。
表・裏
  • システムあるいはサービスとして提供すべき機能(表)と、それを維持管理するために必要な機能(裏)を考えます。
  • システムあるいはサービスを実現するための機能(利用者のための機能)というのは当然として。今後誰がどのようにそのシステムを運用、維持、管理するのか。どのような障害に対してどのようなオペレーションが必要になるのか、変更や拡張としてどの程度の頻度で何が想定されるか、など、システム全体に求められる業務やワークフローをイメージしながら考える必要があります。

運用管理のために必要な機能としては、一般的に以下の点を考慮する必要があります。

  • 管理対象機器へのアクセスパス, inbound/outbound の方針
    • 管理用のアクセスパスをサービス用のネットワークと共有するかどうかを検討してください。
    • 最近のネットワーク機器の場合、管理接続用の専用I/Fがあったり、VR/VRFなどで管理接続を機器内で論理的に分離することが可能な物が多くなっています。管理接続用の専用I/Fがある場合、そこで使える機能が限定されているケースがあるので注意してください。
    • シリアルコンソールサーバやリモートKVMなどを含めて検討しましょう。
  • 運用管理のためのネットワークサービス
    • 監視(SNMP/SNMP Trap)
    • DNS
    • NTP
    • Syslog
    • リモートアクセス(telnet/ssh, ftp/tftp)
    • 認証(AD, LDAP, tacacs, RADIUS)
      • CA/証明書管理
    • 外部からの運用用リモートアクセスサービスとその回線(VPN)
      • 緊急トラブル時の外部接続機能
      • 運用システムのための外部(インターネット)接続パス: ソフトウェアアップデートの取得、ウィルスパターンアップデートの取得、ソフトウェアライセンスのアクティベーション、運用担当者のWebアクセス(調査など)
    • 運用管理系メールサービス
    • NAT, 場合によってはVLAN ID変換
    • 運用担当者の配置とアクセスパス

いくつかの機能は連動するので、運用業務上何が必要になるかを合わせて考えていく必要があります。あとNTP, DNSは超重要なので必ずシステム検討に含めてください。漏れると死にます。

  • NTP
    • Syslog や SNMP(Trap) と合わせて必ず設置してください。トラブルシュート時にログのタイムスタンプがずれているとお手上げです。システム内で管理すべきすべてのイベントが正確な時刻で記録されることを保証してください。
    • システムで求められるセキュリティ要件によっては、インターネット経由で NTP ソースを取得するのが難しい(インターネット回線を設置することが難しい)場合があります。そうした場合にはGPSやFMなどをつかって時刻同期可能なNTPサーバ(アプライアンス)の導入などを検討する必要があります。
  • DNS(運用管理システム用名前解決)
    • ADなどの認証系、運用用のメールサーバなどを扱う際には必須になります。そうでなくとも管理系接続をすべてIPアドレス直接指定で行うのには限界があるので、一般的には運用用のDNSが必要になります。またCNAMEを使った複数役割の定義やDNSラウンドロビンといったDNSを使った冗長化・接続切り替えや移行の方式もあります。
    • ドメイン名の設定は詳細設計のあらゆるところで必要になります。設計段階の早い段階でドメイン名定義を決定する必要があります。
    • SSL-VPNや証明書ベースの何かしらの認証サービスを使う場合は合わせて証明書の管理方法を検討していく必要があります。
機能単位や登場人物などの配置とグルーピング
  • 最初の設計ではグループ単位でファイアウォールのゾーニングなどを検討し、粗い配置を決めることが多いです。
  • 一定のポリシに従ってまとめあられるところ・まとめるべき要素、それらのグループ間通信ポリシ、モジュール化(モジュラリティ)、グループの役割と機能の設定、グループ単位での機能単位の追加あるいは削除の考え方などを考えます。
  • グループ設定には論理的な側面(役割・権限などによる考え方)と物理的な側面(フロア、部屋、拠点など特定の場所単位)があります。
通信機能を実現するために必要なネットワークの機能(サービス)
  • 粗い機能配置やグルーピング(論理・物理)ができているのであれば、それらのグループ間通信を実現するために必要なネットワーク機能を考えます。
  • ネットワーク構成単位(L2/L3): L2セグメント, IPアドレス体系、セグメント間経路制御(L3)
    • 設計対象とするシステムだけでなく、そのシステムが接続する連携先、システム間のL3情報や相互接続ポリシを入手しておく必要があります。
    • いざシステム設計をする段階で、連携先システムとIPアドレスが競合している、既存システムへのIP割り振りの都合、設計対象システムで必要なサイズのIPアドレスを確保できない、といったトラブルが発生することがあります。
  • ネットワークサービス(L4): ファイアウォールとグループゾーンニング、LB、NAT、Proxy、IDS/IPSなどネットワーク構成単位に求められる要件を保証するために必要な機能(ネットワークサービス)の配置。
通信機能を実現するために必要なネットワークの機能(エンドポイント)
  • ネットワークに配置される通信ノード(エンドポイント)は接続先と通信を行うためにどのような経路制御設定をする必要があるか。
    • サーバ側のNIC冗長化設定、複数セグメントと通信する場合はVLAN設定(Native VLAN設定)をどうするかなどのポリシを検討してください。
    • サーバが表・裏(運用系)にも同時にアクセスする場合には物理NICの分割の必要性、表・裏へ接続するための経路制御設定(スタティックルートとネクストホップの設定)ポリシを検討してください。
  • 物理的なI/Fの接続、セグメントごとの論理設定、静的経路制御設定は接続機器ごとにケースバイケースで行います。機器によってはこれらの設定ができない機器があるかもしれません。デバイスの担当者と、ネットワーク接続方式については認識あわせをしておく必要があります。
ネットワークレイヤ別の構成
  • L3構成: 論理ネットワーク設計
  • L2構成(L1含む): STP設計, LAG構成検討
    • L3設計(セグメント構成)およびL1配置(物理ネットワーク設計)がある程度見えていないとそれらのマッピング(L2)設計はできません。
    • L2設計はSTPプロトコル、STPインスタンスの持ち方によって考えるポイントが変わってくるので注意。
リソースの管理

管理すべきリソースにはどういったものがあるか。

  • L4
    • サービスによりますが、たとえばFWで設定可能なフィルタの数やLBで設定可能なポリシの数…等。搭載するメモリの量などにも依存します。
    • 仮想化機能を持つ場合はインスタンス数等。(デバイスコンテキスト、VR/VRFなどの上限(製品・OS等に依存します)
  • L3
    • IPアドレス
      • 拡張性や他システム連携との整合性といった面を含めて管理する必要があります。
      • NATを含めて、設計対象システムに対して input/output するすべての通信でIPアドレスが一意であることを確認してください。
    • HSRPやVRRPで使用するグループID
      • プロトコルのバージョンや使用するデバイスによって、使用可能なIDの範囲や同時に利用できるグループ総数などに制約がある場合があります。
    • 保持できる経路数
      • 動的経路制御を行っている機器、特にBGPフルルートをうけるようなところでは注意が必要です。
  • L2
    • VLAN ID
      • 機器によってあらかじめ予約されているVLAN IDアドレスがあることに注意してください。
      • 機器によって使用可能なVLANの数(同時に何セグメント保持できるか)に違いがあることに注意してください。
      • STPプロトコルの設定や保持できるインスタンスの数の違いに注意してください。特にPVSTの場合、VLAN数が多くなるとスイッチCPUへの負荷が大きくなります。
      • STPプロトコルの仕様上、L2セグメントの "直径(diameter)"…同一セグメント内で任意の2点間を接続するときに経由するL2機器数(ホップ数)の最大値には上限があります。7hopまでだったはず。
    • MACアドレステーブル
      • 機器が保持できるMACアドレスの数には上限があります。
      • クラウドサービスなどで多数の仮想マシンを抱えているところ(物理機器の数倍のMACアドレスが飛ぶ)、大きなL2セグメントを管理する必要があるところでは注意が必要です。
  • L1-L2
    • LAG
      • ひとつの論理リンクとして集約可能な物理リンクの数には上限があります。
      • 機器内で構成可能な論理リンクの数には上限があります。(機器によって異なります)
  • L1
    • 計算機リソース
      • 物理リンク(物理ポート)数
      • ネットワーク機器のCPU処理能力、メモリ使用量
    • 電源
      • コンセント口数、電流・電力容量
    • スペース
      • 機器設置スペース
      • 配線スペース(ラック内・ラック間、フロア内・フロア間、管路など)
      • 機器のモジュール交換、機器本体の交換、追加設置などの作業スペースを見込むこと。また、ラック内については吸排気のポリシと吸排気スペースを踏まえて配置設計をすること。むやみに密集させると、廃熱効率の低下、交換や拡張作業効率の低下、物理作業時のオペミスの誘発などのデメリットがあります。

リソースの管理に当たってはどこに注意する必要があるか。

  • 単位
    • 割り当てや利用の単位
  • 追加・変更・削除(CRUD)
    • 削除(と再利用)を考えてください。一回使ったら使い終わっても放置塩漬けにしてするんですか? 本当にそれで良いのかどうか真剣に考えてください。
  • 一意性
    • 一意であることが保証されなければいけないリソースは何か、一意性が保証されるべき範囲はどこまでか。
    • 関連性のないシステムでは同一のプライベートIPアドレスを使用できるように、必要な範囲で必要な一意性が保証します。
  • 上限
    • リソースには上限があります。システムのキャパシティや拡張性などと合わせて何がどこまで利用可能かをあらかじめ検討しておく必要があります。

次回

もうちょっと機能要件の話をします。