CCDE への道 パート 2 (Marwan Al-shawi)

    本ページは英語ドキュメントを翻訳したものです。

     


     

    CCDE への道 パート 2(Marwan Al-shawi)以前お約束したように、Cisco Press の『CCDE スタディ ガイド』 [英語] の著者、Marwan Al-shawi によるブログのパート 2 をお届けします。 どうぞお楽しみください。 - Brett


    このブログのパート 1 では、「アート」と「ネットワーク設計」の類似点について簡単に説明しました。 また、『CCDE スタディ ガイド [英語]』に私がお勧めする読み方で取り組めば、優れたネットワーク設計者を目指す人全般や、CCDE 実技試験の準備をする特定の人にいかに役にたつかについても取り上げました。 今回のブログ(パート 2)では、非常にクリティカルで重要なトピック – 「ネットワーク設計者としての思考方法」を取り上げます。 わかりやすくするために、小さな設計シナリオを使用します。このシナリオでは 2 つの重要な設計原則に絞り、ネットワークの設計者またはアーキテクトが設計プロジェクトに取り組む際に、その思考方法とアプローチが、設計上の選択や結果全体に「どのような」影響を与える可能性があるかを示します。 言い換えれば、選択したテクノロジーまたは設計オプションは、技術的には有効であっても、最適なものではない可能性もあるということです。 一体これは何を意味しているのでしょうか。


    さまざまなコンサルティング契約や設計契約において、多くのネットワーク設計が問題を抱えているのを見てきました。管理が非常に難しい、あるいは、IT チームが組織のビジネス ニーズ(新しいリモート サイトを開設する、新たにデータセンターを追加するなど)に対応しようとしても、拡張性の制約を受けてしまうといった問題です。 実際のところ、ネットワーク設計が長期にわたって成功していると言えるかどうかは、ネットワーク設計者やアーキテクトの選択によるところが大きいのです。 つまり、上にあげた問題はほとんどの場合 2 つの原因のいずれかによるものです。ネットワーク内のさまざまな箇所(PIN)が別々に設計されたか、現在の要件にのみ対応するネットワーク設計になっているかのいずれかです(その両方の組み合わせである場合もあります)。いずれにせよ、これでは、最適とは言えない設計が選択される可能性が高いでしょう。 次のシナリオで詳しく説明します。

     

    XYZ 社は小売業を営む企業で、北米地域で急速にその存在感を高めています。そこで、XYZ 社の IT チームはネットワーク コンサルタントを雇い、自社の国際的なネットワークを再設計するプロジェクトの支援を依頼しました。  XYZ 社の現在のネットワークと、新たな要件の一部を次の通りまとめました(図 1 参照)。


    • データセンター(DC)が2 箇所あり、将来的に 3 番目のデータセンターを追加する予定。
    • グローバル WAN 全体で MPLS L3VPN に対応。
    • リモート サイトは別のサービス プロバイダー ネットワーク(MPLS L3VPN)を介してグローバル WAN(ハブ ルータ)に接続。
    • 社内スタッフのトラフィックと契約スタッフのトラフィックは分離する必要がある(すべてのリモート サイト、および WAN や DC 全体が対象)。
    • ネットワーク コンサルタント、アーキテクト、設計者は、提案されたソリューションのコンセプト実証(POC)を実施しなければならない。POC では、Region 3 のリモート サイトを利用してプライマリ DC へのエンドツーエンド接続を検証する。

     

    図 1


    このシナリオでネットワーク コンサルタントが主に重点を置いていたのは、これらの要件に対応することと、このプロジェクトのパイロットとして、Region 3 を利用した POC を成功させることでした。 図 1 に示すように、Region 3 には 18 のリモート サイトがあります(他よりもリモート サイト数が少ない)。 これに基づきネットワーク コンサルタントは、図 2 に示すように、ユーザ グループごとに「GRE トンネル + VRF」をプロビジョニングするというシンプルなソリューションを採用することにしました。その方法によってエンドツーエンドでパスを分離するという要件を満たすことにしたのです。 

     

    図 2

     

    このソリューションを技術的に検討すると、ネットワークは少なくとも次の数の GRE トンネルを作成し管理する必要があります。


    • Region 1 のハブ:リモート サイト用 GRE トンネル 200 + ハブから 2 箇所の DC までの GRE トンネル 8
    • Region 2 のハブ:リモート サイト用 GRE トンネル 160 + ハブから 2 箇所の DC までの GRE トンネル 8
    • Region 3 のハブ:リモート サイト用 GRE トンネル 36 + ハブから 2 箇所の DC までの GRE トンネル 8

     

    合計 420 の GRE トンネルです! (図 3 を参照)

     

    このソリューションは技術的に有効であり、POC もおそらく成功するでしょう。しかし、この小売業者がこのソリューションをさまざまな地域で展開し始め、セカンダリ データセンターと統合すると、次のような数多くの問題に直面することになります。


    • 拡張性や柔軟性の制約(新規リモート サイトを追加する際やリモート サイト向けの仮想ネットワーク/VRF を検討する際に、多くの変更が必要で、複雑さも増大)
    • 管理の難しさ(トラブルシューティングが複雑すぎるなど運用面での複雑さが増大)
    • 復元力の欠如(既存のデータセンターに新たな DC が追加されることでルーティングがさらに複雑になり、異なる DC でホストされているアプリケーションのトラフィック フローの制御が困難)

     

    その結果、このソリューションはビジネス目標や将来の計画を達成するという点で、ビジネスに制約をもたらすことになります。運用上の複雑さが増すだけでなく、ネットワークに問題が発生した場合のトラブルシューティングによって、ロガー サービスのダウンタイムが発生するリスクも増大します。

     

    図 3

     

    このブログの前半で強調したように、ここでの問題の原因は主に、ネットワーク コンサルタントが Region 3 と POC の結果を重視するあまり、そこだけを部分的に切り離してネットワークを設計してしまったことにあります。POC は 1 つの DC を使用してソリューションの正しさを検証することが目的でした。 このアプローチではビジネスを推進する重要な要因が考慮されておらず、他の地域がオーバーレイ(GRE トンネル)に加わった時にネットワークの全体像がどうなるかも把握しようとしていませんでした。 また、この企業が 3 番目の DC をネットワークに加えた場合に、設計の複雑さや復元力がどうなるかといった将来の計画も考慮されていませんでした(図 3 を参照)。

     

    ビジネス イネーブラとして機能するようにネットワークをうまく設計するには、ソリューションの技術面だけを見るのではなく、その先を見据えて、設計者やアーキテクトのように考えることが必要です。 言い換えれば、上記の例の小売業者、XYZ 社に最適な設計をするには、まず全体像に目を向け、「部分を切り離して設計する」のではなく、「全体的なアプローチ」を取ることが必要です。 全体的なアプローチで考えるべきシンプルな問題とは、「このソリューションで、プライマリ DC、セカンダリ DC、他の地域、MPLS 対応 WAN コアなどのネットワークのさまざまな要素をどのように統合するか」ということです。 このネットワーク コンサルタントが採用すべきだったもう 1 つの原則は、「明日のことを考慮しながら今日を築く」ということです。 この原則に従えば、現時点でネットワークが対処すべきことだけではなく、将来を見据えてビジネスの今後の計画も考慮し、提案された設計にそのことがどのような影響を与えるかを考えるようになるでしょう。たとえば、仮想ネットワーク、DC、アプリケーションの新規追加、他の企業との合併などが与える影響です。

     

    これら 2 つのシンプルながら非常に重要な原則を考慮することで、より優れた設計上の決定を下すことができるようになり、単なる技術面だけでなく、それ以外の要因で促進されるビジネス目標や将来計画をサポートできるようになるでしょう。

    これまでのことを考慮すると、XYZ 社に最適なソリューションの 1 つは MPLSoDMVPN(2547oDMVPN)を利用することです。 このソリューションによって次のことが実現されます(図 4 を参照)。


    • 高度な拡張性と柔軟性を備えたシンプルさ(各リモート サイトからのトンネルは 1 つ。新しくリモート サイトまたは仮想ネットワークを追加してもオーバーレイまたはコア ネットワーク設計に影響はなく、変更も不要)
    • 復元力(ルーティングの管理がシンプルな「L3VPN 方式」)

     

    図 4

     

    運用のシンプル化については少し議論の余地があります。というのは、確かにこのソリューションによってよりシンプルな柔軟性のあるルーティング設計となりますが、一方それを運用するには、MPLS、MP-BGP、IGP などの高度なネットワークに関する知識や経験のある人材が必要となるからです。

     

    ただし、与えられた情報だけでは、MPLSoDMVPN の利用がこの組織に最適かどうかを判断できません。 たとえば、このネットワーク内で使用されているアプリケーションやその特徴などが記載されていません。これらは設計上の選択に大きく影響します。 そのような問題はありますが、この例の目的は、「何」を選択するかを説明することではなく、「どのように」考えるかを学ぶことです。つまり、設計者のように考えてよりよい決定を下す方法を学ぶことが目的です。

     

    まとめると、設計プロジェクトに取り組む際に、ネットワーク設計者やアーキテクトのように考えることで設計上の決定がよりよいものになり、それができるかどうかでその設計の成功度合いが大きく左右されるのです。 したがって、設計プロジェクトに取り組む場合の考え方やアプローチは、技術を導入するエンジニアとして導入プロジェクトに取り組む場合と異なるものでなければなりません(CCDE と CCIE の考え方の違い)。 設計者のような思考を持つことによって、設計するときに考慮すべき新しい切り口が常に明らかになります。それが最終的には設計上のより賢明な決定を下す上で役に立つのです。

    CLNBanner