モバイルオペレーターを介したインターネットチャネルの集約

特に1時間以上運転する必要がある場合、旅行中に信頼性の高い高速インターネットを利用できると便利です。 経路が人口密集地域にある場合-4Gネットワ​​ークをサポートする最新の携帯電話では、通常すべてが正常に機能するため、従来どおりインターネットを使用し続けます。 当然、集落の外に旅行するとすべてが変わります。

移動中の車両では、インターネットには2つの方法でしかアクセスできません。

1. 「空から。」 「上から」データチャネルを中継する衛星、成層圏の統計およびその他の技術。
2. 地上インフラストラクチャを使用します。 地上に設置された基地局を介して無線信号を送信する方法。 これは、モバイルオペレータのインフラストラクチャ、Wi-Fiインフラストラクチャ、イーサネット無線の祖父などです。

もちろん、データ伝送用の独自のインフラストラクチャを作成するための予算を確保する人は誰もいません。したがって、衛星チャネルと「携帯電話」のインフラストラクチャのみが自由に使用できます。 顧客のフィンモデルが衛星チャンネルを介した販売に耐えられなかったため、選択が再び簡素化されました。 したがって、さらに、モバイルオペレーターを介して移動車両に最も安定したチャネルを適用する方法について説明します。

データ伝送チャネルの集約の本質は簡潔に表現できます。異なる物理回線によって提供される容量を要約することです。 条件付きで、1 Mbit / sの容量を持つ4つのチャネルがある場合、出力で4 Mbit / sの容量を持つ1つのチャネルを取得する必要があります。 私たちの場合、4つのモバイルオペレーターがあり、それぞれを通して最大70メガビット/秒の制限を絞り込み、合計で星が正しく収束すれば280メガビット/秒に絞り込めます。

280 Mbpsは列車のすべての乗客にとって十分ではなく、そのうち700が平均で700であり、集落の外でそのような速度を得るのは不可能であると誰かが言うでしょう。 さらに、接続がまったくない場合、魔法は発生しません。輸送中の通信もありません。 もちろん、この人は絶対に正しいです。 したがって、誰にとっても快適なチャネルではなく、通常のスマートフォンでは物理的に接続を確立できない何らかの種類のチャネルの問題を解決します。

この投稿は、あるインドの鉄道事業者の自動車および鉄道輸送でインターネットを利用するために自転車をゼロから発明しなければならなかった方法、この輸送の動きとルートの各ポイントでのデータ伝送チャネルの品質を記録し、続いてタランツールクラスターに保管する方法についてです。

プロジェクトの本質

集約は、フォールトトレランスの問題を解決したり、集約に関係するデータチャネルの容量を合計したりします。 集約のタイプ、ネットワークおよび機器のトポロジに応じて、実装は劇的に異なる場合があります。

各タイプの集計は個別の記事に値しますが、PD車両の信頼できる最大限の「ワイド」チャネルを提供するために、可能な限り特定のタスクがあります。

モバイルオペレータのインフラストラクチャは、タスクの基礎を提供します。

1. 統合環境。 データ転送は、オープンなインターネットおよびさまざまな通信事業者を通じて行われます。 つまり、 EtherChannelおよびその他のハードウェアでサポートされているプロトコルは当然機能しません。
2. トラフィック中のPDチャネルの高いエントロピー。 各チャネルの静電容量と遅延は、オペレーターのBSまでの距離、その負荷、干渉などに大きく依存するため、予測不能かつ迅速に変化します。

技術的には、集約は非常にシンプルで繰り返し記述されているため、あらゆる深さの情報を簡単に見つけることができます。 要するに、これの本質。

クライアント機器から：

1. ネットワークのセットアップ。 独立したデータ伝送チャネルを介して、L3トンネルは単一の集約ポイント（NATが構成された外部サーバー）にセットアップされます。 1つのチャネル-1つのトンネル。 インターフェイスは、ネットワーク全体のデフォルトゲートウェイになります。
2. 特別なソフトウェア。 2つのことだけを行います。チャネルとトンネルの品質のターゲットメトリックを監視し、そのメトリックに基づいて、NATトラフィックをトンネル全体に分散します。

オペレータの信号レベル、通信の種類、基地局​​のロードに関する情報、オペレータのデータネットワークのエラー（L3トンネルと混同しないように）を監視し、これらのメトリックに基づいてデータストリームを配信することで、さまざまなモバイルオペレータを介してチャネルを独立して分析する必要性自分で解決策を書かなければならないこと。

ところで、集約が機能するさまざまな許容レベルのソリューションがあります。 たとえば、Linuxのインターフェイスの標準ボンディング。 少なくともVPNサーバーまたはSSHトンネルを介して、利用可能なツールキットを介してL3トンネルを上げ、ルーティングを手動で構成し、仮想トンネルインターフェイスをボンディングに追加します。 同時にトンネルの容量が同じである限り、すべてがうまくいきます。 実際には、このようなネットワークトポロジでは、balance-rr集約モードのみが機能します。つまり、各トンネルは順番に同じバイト数を取得します。 つまり、容量（Mbps）が100、100、1の3つのチャネルがある場合、結果の容量は3 Mbpsになります。 つまり、最小チャネル幅にチャネル数が乗算されます。 容量が100、100、100の場合、結果は300になります。

もう1つの解決策があります。優れたVtrunkdオープンソースプロジェクトです。これは、2016年に長い間忘れられていました。 あなたが必要とするほとんどすべてがすでにそこにあります。 私たちは、モバイルオペレーターの通信品質の指標を監視するという観点からソリューションの最終決定に支払う準備ができていることを作成者に正直に書き、これらの指標をトラフィック分散メカニズムに含めましたが、残念ながら、私たちは最初から自分のバージョンを書くことにしました。

Qedr Summa

まず、モバイルオペレータのメトリック（信号強度、ネットワークタイプ、ネットワークエラーなど）を監視することから始めました。モデムは、オペレータのメトリックをどれだけうまく提供できるかに基づいて選択されたことに注意してください。 Simcom製のSIM7100モデムを選択しました。 関心のあるすべてのメトリックは、シリアルポートへの呼び出しを通じて提供されます。 同じモデムは、GPS / GLONASSの座標も高い精度で提供します。 また、コンピューターメトリックスの状態（CPU、SSD温度、RAMとディスク領域の空き容量、SMART SSDインジケーター）を監視する必要があります。 これとは別に、モジュールはネットワークインターフェイスの統計（受信および送信でのエラーの存在、送信キューの長さ、送信されたバイト数）を監視します。 デバイスのパフォーマンスは非常に制限されており、送信されるデータのパケットは最小限に抑える必要があり、Linuxで/ proc / sysを使用してこれらのメトリックを監視する容易さを考慮すると、監視サブシステム全体もゼロから開発されました。

メトリックス監視モジュールの準備が整った後、ネットワーク部分であるソフトウェアチャネル集約に進みました。 残念ながら、詳細なアルゴリズムは企業秘密であり、公開することはできません。 それにもかかわらず、トランスポートにインストールされた集約モジュールがどのように機能するかを一般的な用語で説明します。

1. 起動時に、仮想インターフェイスの設定を記述するJSON形式の設定を読み取ります。 集約サーバーのアドレスは、中央システムから動的に取得されます。 これにより、サーバー側の負荷分散と、集約サーバーに障害が発生した場合の条件付きでシームレスなハンドオーバーが提供されます。
2. 読み取ったデータに基づいて、集約サーバーへのL3トンネルを作成します。 ルーティングを構成します。 トンネルには、オプションでデータ圧縮と暗号化を含めることができます。
3. 監視モジュールからのデータに基づいて、各トンネルに独自の「重み」を割り当てます。 重みが大きいほど、このトンネルを通過するトラフィックが多くなります。 各トンネルの重みは毎秒更新されます。
4. デバイスの動作統計、地理的位置、およびビジネスロジックメトリックは10分以上蓄積され、トランザクションが形成されています。 トランザクションは、Tarantoolローカルデータベースに格納され、ネイティブのTarantool DBMSデータ複製メカニズムによって「ヘッド」に送信されます。これについては、このDBMSの開発者と活発なコミュニティに感謝します。

集約のサーバー側は根本的に単純です。 起動時に、集約モジュールは設定サーバーにアクセスし、JSON形式で構成を受け取り、それに基づいてL3インターフェイスを起動します。 一般に、すべては簡単です。

それとは別に、すべてのプロジェクトメトリックの収集および視覚化システムを説明する価値があります。 2つの大きな部分に分かれています。 最初の部分は、クライアントおよびサーバー機器の生命維持システムの監視です。 2つ目は、プロジェクトのビジネスメトリックを監視することです。

プロジェクトの技術スタックは標準です。 視覚化：Grafana、OpenStreetMap、クライアントおよびサーバー側のアプリケーションサーバー：Go、DBMS Tarantool。

タランツール

プロジェクトにおけるDBMSの進化の歴史は、2009年のPostgreSQLから始まります。 特殊車両に搭載されたオンボードデバイスのジオデータを正常に保存しました。 PostGISモジュールが仕事をしました。 時間が経つにつれて、ストレージスキームなしでデータを処理するパフォーマンスが非常に低下しました。 バージョン2.4からバージョン3.2までのMongoDBを試しました。 数回、緊急シャットダウン後にデータを回復できませんでした（予算が重複データを許可していませんでした）。 次に、ArangoDBに注意してください。 当時のバックエンドがJavaScriptで記述されていると考えると、テクノロジースタックは非常に良さそうに見えました。 ただし、このベースは、2年間ずっと一緒にいましたが、過去のものです。大量のデータでRAMの消費を制御することはできませんでした。 このプロジェクトでは、彼らはタランツールに注意を払いました。 私たちの鍵は次のとおりです。

1. 組み込みのトランザクションメカニズム。
2. 非リレーショナルデータのストレージ。
3. InMemoryおよびVinylストレージ（ディスク上）。
4. マスタースレーブレプリケーションのメカニズム。
5. データセンターの強力なハードウェアおよび車両の非常に限られた機器での効果的な作業。

一見、1つのプロセッサコアでのみ動作することを除いて、すべてが良好です。 科学のために、彼らはこれが障害になるかどうかを理解するために一連の実験を行った。 ターゲットハードウェアでのテストの後、このプロジェクトではDBMSが完璧に機能していると確信しました。

主要なデータプロファイルは、金融取引、時系列（システム操作ログ）、地理データの3つだけです。

金融取引は、各デバイスの個人口座でのお金の動きに関する情報です。 すべてのデバイスには、異なる通信事業者のSIMカードが少なくとも3枚搭載されているため、各通信事業者の個人アカウントの残高を管理する必要があります。

時系列は、トランスポート内の各デバイスの累積帯域幅ログを含む、すべてのサブシステムからのログを単に監視しています。 これにより、パス上のどのポイントで各オペレーターのチャネルがどれであるかを知ることができます。 このデータはネットワークカバレッジ分析に使用されます。これは、通信事業者によるチャネルのプロアクティブな切り替えと重み付けに必要です。 特定の時点でこのようなオペレーターの品質が最も悪いことが事前にわかっている場合、このチャネルを事前に集約から切断します。

位置データは、ルートに沿った単純な車両追跡です。 毎秒、モデムに組み込まれたGPSセンサーに問い合わせて、座標と高度を取得します。 10分間続くトラックがパケットに収集され、データセンターに送信されます。 顧客の要求に応じて、このデータは永久に保存する必要があり、車両の数が増えると、インフラストラクチャを事前に非常に真剣に計画する必要が生じます。 ただし、Tarantoolでは、シャーディングは非常に簡単に行われ、急成長するデータのためにストレージをスケーリングすることについて困惑する必要はありません。 現在、このデータには履歴値がないため、データのバックアップコピーは書き込まれません。

すべてのタイプのデータについて、Vinylエンジン（ディスクにデータを保存）を使用しました。 それほど多くの金融業務はありません。また、それらが分析されるまで、ログ、自然、およびジオデータなどのメモリに常に保存する意味はありません。 分析が必要な場合、パフォーマンス要件に応じて、既に集計されたデータを準備してInMemoryエンジンに保存し、このデータを分析することが理にかなっている場合があります。 しかし、これらはすべて、顧客が要件を満たしたときに始まります。

Tarantoolが私たちの仕事の素晴らしい仕事をしたことに注意することが重要です。 彼は、リソースが限られたデバイスでも、10個のシャードがあるデータセンターでも同じように快適だと感じています。 輸送中のデバイスの仕様：

CPU：ARMv8、4Core、1.1 Ghz
RAM：2 Gb
ストレージ：32 GB SSD
データセンターサーバーの仕様：
CPU x64 Intel Corei7、8Core、3.2 Ghz
RAM：32 Gb
ストレージ：2×512 Gb（Soft Raid 0）

既に述べたように、トランスポートからデータセンターへのデータ複製は、DBMS自体を使用して調整されます。 10個のシャード間でのデータのシャーディングも、「すぐに使える」機能です。 すべての情報はTarantool Webサイトで入手できますが、ここで説明する必要はないと思います。 現在、このシステムは合計866台の車両に対応しています。 顧客は8,000に拡大する予定です。

アレクサンダーロダン、国立交通およびテレマティックシステム。 質問がある場合は、コメントまたはa.rodin@qedr.comに書き込んでください 。 できれば全員に答えようとします。