設置のために運転していたとき、近くの渓谷からトラクターを取りました届きにくい場所にひどくグループ化されたさまざまな鉱物を生産するロシア人男性がいます。 多くの場合、それらを地面から取り出したり引き出したりするだけでも、非常に費用がかかります。 したがって、生産現場で開発されたインフラストラクチャはまれな現象です。 そのため、極東では、多くの場所で、繊維はまだ空想科学小説の一部であり、ワイヤは手に持って初めて野生で発見されます。
そこでの通信は衛星経由で行われます。
したがって、チャネルの要件は増大していますが、拡大は非常に苦痛で費用がかかります -衛星リソースは最もスケーラブルではなく、それを介したギガバイトは機能しません。
最も重要なものが常に最初になるように、トラフィックを圧縮し、チャネル内のアプリケーションに優先順位を付けることにより
、チャネル最適化の問題を解決しました 。 ネットワーク全体の探偵になりました。
入門
衛星にチャネルがあり、それを拡張することは高価です。 トラフィックを圧縮し、プロトコルレベルで交換を最適化して（冗長データが送信されないようにする）、さらに圧縮辞書のキャッシュ部分を自分でキャッシュできるRiverbedソリューションがあります。 これはすべて、データの種類と飛行方法に応じて、ストリップ全体で20％から80％のゲインを実現できます。
タスクは、重要なトラフィックの優先順位付けの可能性を計算するように求められたという事実から始まりました。 最適化は非常に有益であることが判明した後、上昇した衛星チャンネルに常に支払いをする必要があります。
調査
交換アーキテクチャ-大都市のハブを備えた複数の「スポーク付きホイール」。 たとえば、イルクーツク、マガダン、モスクワ。 ハブには光学または銅が適しています。 ケースの90％で、鉱業企業の遠隔地では衛星通信局が使用され、文字通り2本の無線中継線があり、さらにいくつかの点で、高速道路のために何らかの理由でそれを引きずった人が光学を共有しています。
データを収集する診断システムを設置します。
多くのアプリケーションがありますが、ユーザーはほとんどいません。主な交換は技術的なものです。 以下は、雪のはるか遠くのどこかの企業で働くことができるものの例です。
承認されたアプリケーション
|
観察されたトラフィックの解釈
|
Microsoft-DS Active Directory
|
オペレーティングシステムツールを使用したファイル共有
Windows（SMBダイレクト）。
|
Microsoftターミナルサーバー（RDP）
|
リモートデスクトップ
|
Https
|
Outlook Web Access
|
SMTP
|
Exchangeサーバー間でメールを転送する
|
MS SQL
|
MS SQL Serverへのアクセス
|
netview-aix-2
|
クライアント接続1C
|
ドメイン
|
ドメインネームサービス（DNS）
|
webcache
|
プロキシサーバーを介したインターネットアクセス
|
一般に、DNSとインターネットアクセスを除き、これらはすべてうまく縮小します。 また、Lync、VoIP、およびビデオ会議もあります。これらの機能により、圧縮されていませんが、優先順位1が必要です-特に、施設の長がビデオ会議ミーティングに呼び出される場合。
ほとんどの場合、毎日のトラフィックはファイル転送、リアルタイムトラフィックであり、生産監視、アカウンティング、センサーからの生データに関するデータもあります。 情報を送信するアプリケーションの多くは「おしゃべり」です。つまり、入手できる多くのパッケージを送信します。 したがって、そのようなことはリバーベッドによって非常に簡単に決定されます。
ここでは、最適化の前後でアプリケーションがどのように機能するかを比較します。
たとえば、よく知られている「おしゃべりな」CIFSプロトコルは、ファイルへのアクセスに使用されます。 ローカルネットワーク上の20〜40 MBのファイルが数秒でダウンロードされます。 上の図に示すように、ファイルがWANチャネルを介してリモートオフィスからダウンロードされる場合、ダウンロード時間は5分以上に延長できます。
リモートオフィスへのダウンロード時間を短縮するには、両方向のパス数を最小限に抑える必要があります。
トラフィックに優先順位を付けるには、パケットを分解する必要がありました-アナログDPIを取得してレベル7を確認する必要がありました。使用されているポートの単純な散乱は明らかに十分ではないためです-同じ種類のトラフィックは重要なセンサーまたはチャットのチャットのいずれかである可能性があります重要ではありません。 または、接続を確立する段階でも、Exchangeセッションを割り当て、それらの下に帯域を割り当てる必要がありました。
その前に、もちろん、彼らは単にルーターでそれを試しましたが、非常に複雑な制御があり、さらにこれをすべて設定で維持することは困難です。 完全に理解するために-私たちの場合、モスクワの中央オフィスにはサポートチームはありません。 主なものは、生産ポイントと親組織から等距離にありました。 場所はタイムゾーンのためにそのように選択されています-あちこちで就業日を見つける機会があります。 運用タスクのための中間チームがありますが、これらの人は誰も絶対に手動設定でそれほど多くの問題を作成する必要がありませんでした。 そして、将来の適切な動作の保証なし。
鉄
ここでは、このストーリー全体が紙の上でのみスムーズに聞こえると中断する必要があります。 もちろん、困難は-ミラー化されたトラフィック分析デバイスを接続するなどのありふれたものから始まりました。 道路のない、非常に遠く、どこかにある鉱山会社を想像してください。 陸路で到着できるのは、年に数か月だけです。 したがって、少なくとも1か月間他の場所に送信した後の鉄は、ポイントに到達します。 取得したら、接続する必要があり、ユーザーサポートサービスのローカルの誰かが接続されます。
幸いなことに、これらはすべてバイパスを介してサーバーの出口のギャップに接続されていたため、作業は非常に簡単になりました。 唯一の瞬間-エンジニアがケーブルを引っ張る前に、同じ電話が正確に結び付けられていたため、すべての指示を与える必要がありました。
オプティマイザーが一番下その結果、次のスキームが作成されました。
- モスクワの倉庫で鉄を受け取りました
- 接続後すぐにデバイスを制御できるように、診断とプリセットを行いました。
- 支店から送信
- その後、彼らはアバターを演じ、現場の専門家がケーブルでは理解できない動きをするのを助けました。 これはすべて、大きな遅延のあるビデオストリームで観察されることがありました。 面白い人はいませんでした。
- その後、1年後、クエストの2番目の部分が始まりました。ある時点から、測定機器を取り外して他の機器に装着する必要がありました。
繰り返しますが、北のロマンス-1つのデータセンターがそりの場所に到達しました。少なくとも犬はそうではありません。 データセンターのデータセンター、はい。
継続
そのため、どのトラフィックがどの量で流れるのかを確認しました。 何が遅れ、何がビジネスに重要であり、何がそうでないか。 会社にとって重要なのは、「殺す」ことができるもの-帯域内に重要なトラフィックがあった場合に「殺す」ことです。 さまざまな種類の情報に4つのサービスクラスを割り当て、それらを通信事業者と調整しました。 実際、私たちはこのトラフィックを「色付け」しました-そして、通信事業者はその場で形作りました。 各オブジェクトには独自のテレコムオペレーターがいるという別の特性がありました。サービスに追加料金を支払う必要があったり、単純に正しくシェーピングできなかったり、より少ないサービスクラスに適合して異なるハックを考え出さなければなりませんでした。
ネットワークの問題を支配します。 私たちのミラーセンサーは完璧なデバッグツールになりました。 センサーはすべての地域に設置され、トラフィックのコピーがありました-ブランチとセンターからのいくつかのポイントからトラフィックのコピーを取り、比較することができます。 各パッケージをあちこちで修正する機会があったことがわかりました。 その結果、通信事業者で何が起こっているのかを実際に評価することができました。 以下に例を示します。
顧客診断の例：
サーバーからクライアントへの途中でパケットが失われたホップを確認しますあるケースがありました-大ボスがブランチに来て、彼らが言う、あなたがここに持っている何か、1つの特定のターミナルが落ちると言いました。 「午前中に同梱された車に来ました-そして彼は落ちました。」 オンサイトエンジニアは単にセンサーに接続し、最後のセッションパケットを取得して、接続が終了した理由を確認しました。 パケットの30分間で、クライアント自体がタイムアウトにより接続を切断することがわかりました。 その理由はパッケージに書かれており、Googleでコードを記録し、すぐに設定が破損しないように確認しました。
何鉄？
通信チャネルの幅と、サイト上のユーザーと情報リソースの数に応じて、最年少から最古までのさまざまなオプティマイザーモデルがインストールされました。 私は
ここと
理論でリバーベッドのソリューションについてもっと書きました。
総トラフィック節約量はいくらですか？
ポイントの1つからの例を次に示します。
ここでの最適化の合計は、主要ノードの1つで最適化されたトラフィックに対して週57.05です。
実際、ここに物語があります。 あなたのプロジェクトにとって詳細が特に興味深い場合は、メールAVrublevsky@croc.ruで概算できます。 ここで、またはメールで質問に答える準備ができました。