ONUG 秋季カンファレンス 2019
先月ニューヨークで開催された ONUG 秋のカンファレンスに参加できて本当に楽しかったです。 誰かがそれを検証する必要がある場合 SD-WAN は飛躍的に進歩し、主流になりつつあります。そこにいたら、その証拠が得られたでしょう。出席率の高さ、会場での素晴らしい議論、多くの参加者erp立ち上がって自分の経験を共有する SD-WAN 配備。 さらに、業界標準とリファレンス アーキテクチャに関する議論の夜明けが始まりました。 SD-WAN ONUG と MEF によって推進されていることから、テクノロジーが成熟に達しつつあることがわかります。
ご想像のとおり、私たちは混雑した展示会場や概念実証プレゼンテーションでさまざまなトピックについて議論していました (私の 10 分間のライブ映像をご覧ください) Aryaka デモ こちら）。 しかし、私たちが最も議論したトピックを要約しなければならないとしたら、私は次の項目を選択します – もちろん、皆さん自身の意見も歓迎します。
SD-WAN 複雑
一方、 SD-WAN 当初はネットワークの複雑さを解消するテクノロジーとして売り込まれていましたが、現在では多くのユーザーが最初の使用では問題が発生していると報告しています。 SD-WAN 導入は、ネットワークの簡素化という当初の期待に応えられませんでした。 実際、私は少なくとも 3 名の担当者と話をしました。erp利用を中止していたユーザーが増加 SD-WAN プロジェクトに取り組み、そのアプローチを再評価していました。 SD-WAN 実装。 私が聞いた主な問題点は、これまで悩まされてきたのと同じ問題でした。 耳鼻咽喉科erp上昇 WAN 過去には複雑さが増していました: アプリケーションのパフォーマンス、ユーザーエクスペリエンスと QoS （それらはすべて絡み合っています）。 理論的には、 SD-WAN は、「単純な」ポリシーを一元的に定義し、すべての場所への配布を調整/自動化することで、この問題に対処することになっていました。 驚くべきことに、政策はそれほど単純ではないようで、普遍的に適用できるものでもないようです。 そのため、最終的に何が起こるかというと、ネットワーク エンジニアは、初期の「汎用」ポリシーの作成に多くの時間を費やしており、その方法では、依然として過去の 600 以上の悪意のある CLI コマンドを思い起こさせることになります。 さらに、多くの場合、ラストマイルの動作の特殊性を考慮して、多くの場所でこれらのポリシーを調整する必要があり、基本的には、以前と同じタイプのノードごとの操作が必要になります。erp以前はネットワークの非効率性が高まっていました。 この問題が特に耳鼻咽喉科で蔓延していたと言っても驚かないでしょう。erp「Do-It-Yourself」に乗り出した新興企業 SD-WAN プロジェクト。
私がそう言ってもあなたは驚かないでしょう Aryakaのアプローチはこの問題を解決します。 そして、あなたが「まあ、それは マネージド サービス モデル そしてあなたは私に代わってそれをすべて実装するだけで、私に自分のことをほとんど制御できません SD-WAN 実装」をご覧になることをお勧めします。 ONUG POC デモ。 グローバル ポリシーとローカル ポリシーを作成および変更できる構成ポータルがあります。 非常に直感的に操作できます。 さらに、ラストマイルを私たちがコントロールできるということは、ほとんどの場合、普遍的な QoS 政策は単純に機能します。 いくつかの異なるアプリケーションの混在パターンに対応するために複数のグローバル ポリシーを作成することもできますが、お客様の導入環境を調べてみると、一般的な 200 のブランチ ネットワークには 2 つ、おそらく 3 つしかないことがわかります。 QoS ポリシーはもう必要ありません。
可視性とトラブルシューティング
ニューヨークのショーケースフロアは、次の事実を強調しました。 SD-WAN は、ネットワーク パフォーマンス監視 (NPM) 企業にとって非常に肥沃な遊び場となっています。 誤解しないでください、耳鼻咽喉科には正当な理由がたくさんあることを私は知っていますerpNPM ツールを採用するために立ち上がりました。 私が独自のネットワークを管理している場合は、高レベルの可視性とトラブルシューティング機能を提供する、ベンダー中立の追加ツールを少なくとも XNUMX つ選択するでしょう。 そうは言っても、奇妙に見えるのは、さらに別の NPM ツールを ent としてデプロイすることが必須要件になっているように見えることです。erpライズは0勝1敗2分の初日を迎える SD-WAN 旅。 主な理由は、Day 0 で動作するトラフィック ポリシーを定義するのに役立ち、Do-It-Yourself を使用して Day 1 または 2 のシナリオで運用/トラブルシューティングを行うときにオーバーレイとアンダーレイのネットワーク動作を調整することです。 SD-WAN。 1日目には、あなたは wanトラフィック ポリシーが期待どおりに実行されない理由を特定し、2 日目にはアプリケーションのパフォーマンスの問題をトラブルシューティングする必要があります。 いずれの場合でも、仮想オーバーレイと物理アンダーレイの可視性が分割されていても、間違いなく役に立ちません。
そしてもう一度言いますが、この問題は、 Aryaka アプローチ。 の MyAryaka カスタマー コンソールは、最初、中間、最後のマイルにわたる完全なエンドツーエンドの可視性を顧客に提供します。 オーバーレイとアンダーレイの分割可視性の問題を調整する必要はありません。 Aryaka ミドルマイル (当社のグローバル レイヤ 2 コア) の完全な所有権を持ち、密接に接続する閉ループ アプローチを採用しています。 Aryakaさん PoPs エッジデバイス（Aryaka Network Access Point別名 ANAP）最初と最後のマイルのパフォーマンスをリアルタイムで詳細に把握できます。 どこかに問題がある場合、トラブルシューティングのプロセスは非常に簡単です (繰り返しになりますが、 私の ONUG デモ）。 また、私たちの SLAs 初日から取り組むだけです。とても簡単です。
ネットワークエンジニアの役割
他にも多くの議論のトピックがありましたが、私が頻繁に取り上げていたのは、ネットワーク エンジニアの役割の将来についてでした。 それは、私の経歴から、私がネットワークに少し灰色のひげを生やしていることがわかるため (おそらくひげを剃ったほうがよいでしょう :-D)、また、次のような Network-as-a-Service 企業で働いているためだと思います。 Aryaka ネットワーク エンジニアは私にこう尋ねます。「あなたのサービスを購入したら、*私*は一日中何をするつもりですか?」 私は自分自身を不要にしているのではないか？」 これは簡単な議論ではありませんが、ネットワーク エンジニアの役割が変化しており、しばらくの間変化し続けていることは誰もが知っています。 ここにブログがあります 私は XNUMX 年以上前にこのテーマについてゴーストライターを書きました (ただし、私の意見の一部は変わっています!)。 ネットワーク エンジニアは、サーバー/アプリケーション エンジニアの役割がどのように変化したかに注目する必要があります。 DevOps は、ネットワークにおける新たな雄叫びとならなければなりません。 一言で言えば、これはインフラストラクチャをビジネス ニーズに合わせて継続的かつ迅速に調整し、運用を継続的に変更することを意味します。 それと、はっきり言っておきたいのですが、 Aryakaいつ見ても簡単にわかるように、 の主要顧客はネットワーク分野の専門家です。 彼らは私たちのウェビナーに参加します、テクノロジーとその機能を完全に認識しています。 しかし、彼らは優先順位が変わりつつあり、IT ビジネスの議論に参加してネットワークの象牙の塔から出る必要があると早い段階で判断したネットワーク エンジニアでもあります。 の中に WAN ルーターの時代、XNUMX つのネットワーク モデルがほぼすべてのエンタープライズに適合erpが増加し、接続が主要なサービスでした。 ネットワーク エンジニアは、包括的なビジネス モデルや優先順位を意識する必要はありませんでした。 デジタルでは、 cloud第一の時代、ネットワークは常にビジネス ニーズに迅速に適応する必要があります。そうでないと、ネットワークが邪魔になり、バイパスされたりアウトソーシングされたりすることになります。 の Aryaka 導入モデルにより、ネットワーク エンジニアは 70% 以上の時間 (複数の調査によると) のトラブルシューティングから解放され、ビジネスの成功に向けた計画により多くの時間を費やすことができるようになります。
までご連絡ください デモを入手する 当社の専門家からのメッセージです。
著者,
