すべてのドメイン間で生成されたデータの量は、何百万ものデバイスで爆発しています 取得する 日々インターネットに接続しています。 各IoTアプリケーションは、毎日Terabytesのデータを処理する必要があります。 このような大量のデータを単一ノードサーバで処理することは不可能ではありません。 MQTTブローカーでも 市場は、スループット、大規模な生産環境のために十分にスケールされているMQTTの高可用性を必要とします 要求を効果的に満たすクラスター。
クラウドのSaaS時代は、サーバーがシステムの高い可用性のためにデプロイされる方法を再定義しました。 物事のインターネットが要求の99%がすべてのHTTPベースのソリューションだった前に構築されたアプリケーション 1つのサーバー(またはサーバーのパス)で提供される。 MQTTの高い可用性は、異なるセットをポーズ データの一貫性に対する課題。 プロトコルは、そのメッセージが上に配置されるように必須になります。 MQTT クラスターの特定のサーバー ノードは、クラスター内のすべてのノードに利用できるようにします。 より速く、より信頼できる方法でこのシステムに接続される顧客のために利用できる。 MQTT と言った クラスタは、REST またはその他のモードを経由して、ユーザーが利用できるデータを作る必要があります。 IoT/IIoTデータの全体的なエコシステム
MQTTクラスターアーキテクチャ
MQTTプロトコル仕様はデータの保存をサポートしていません。 しかし、高可用性クラスター データデリバリーが保証されることを確認するために過渡データのための明確なデータ貯蔵を必要としますMQTT QoSレベルMQTTパケットに指示。 単一のノードがある場合には、ストレージが必要ではない トランスエントメモリにデータが入ることができるようにデプロイ。 そのため、MQTTブローカークラスターは、より多くのコンポーネントを必要としています MQTT導入 高レベルでは、以下の場合に、過渡データのデータ保存が必要になります。 ケース:
- 新しい時MQTTブローカークラスターに参加する
- MQTTブローカーが物理的または機能的な再起動のために再起動すると。
すべてのブローカーが正常に実行されている場合は、インターブローカー通信 (IBC): : :
- 他人にデータを送信するMQTT サーバークラスターのインスタンス
- クラスター内の他のMQTTインスタンスからデータを受信するには
Load Balancer は、すべての高可用性のデプロイメントにおいて、プロトコルの見解性が欠如する際の必須事項です。 クライアントとサーバー間の通信に使用されます。 MQTT の設定に大きな役割を果たします。 クラスターは、クラスター内のMQTTノードを横断し、REST APIを経由して配信するだけでなく、 お問い合わせ MQTT クラスターがデプロイできるモードは2つあります。 ロードバランサーのサポートは重要な役割を果たします これらの設定のロール。
アクティブパッシブモード
この設定では、ロードバランサの後ろにデプロイされた2つのMQTTブローカーがあります。 の 1 つ MQTT ノードは Active として構成され、リクエストが処理されます。 二次ノードはステータスを保持します プライマリと同期してデータがスタンバイモードになります。 機能的または物理的がある場合 第一次サーバの故障、二次サーバが引き継ぎます。
このセットアップは、適度なデータ交換のシナリオと単一の MQTT ノードができる場所に最適です。 負荷を処理します。 二次ノードを最小限に保ち、エネルギーとコストを節約できます。 設定。
多マスター モード
単一ノードが生産データ負荷を処理できないデータ交換が増えた場合は、 ロードバランサとMQTTブローカーの背後にある複数のマスターをデプロイする必要があります。 並列。 TCP ベースのプロトコルであるため、設定の厳守は、クライアントが固執します。 接続するMQTTサーバー。 構成は重量を付けられた円形のロビンを配るために作ることができます より良い方法で読み込みます。
MQTT クラスターはデータの一貫性を維持するにはどうすればよいですか?
MQTTの特長 ブローカーは、Inter Brokerコミュニケーションとして呼ばれる作り付けのデータ交換メカニズムを支援しています エンジン(IBC) IBC はクラスター内の MQTT ノードごとに有効化し、データを送信・受信できるようにします。 他のMQTTクラスターノード。 すべてのノードはデータベースに並行してデータを保存し、冗長性を確保します。 故障の場合のデータ復旧を有効にします。
MQTTブローカー冗長
前述のように、MQTTプロトコル仕様とMQTTプロトコル仕様IoTアプリケーションMQTT 上に構築された多角化 M2MおよびM2Mのデータ一貫性の面でよりスケーラブルで信頼できるようにする条件のセット 実行されるすべての展開の固有の部分になっているデータ分析プラットフォームとの統合 今日。 ブローカーの背後にあるデータを保管し、購読者としてではなく、常にお客様に尋ねます。 これは助けます これらは、帯域幅コストだけでなく、展開のサイズを削減します。
物理的な冗長性
物理 MQTT 冗長性は、1 つまたは 2 つのノードが失敗し、新しいサーバーをプロビジョニングするまで、または 同じ物理サーバーは、クラスターが完全に機能するはずです。
機能冗長性
ノードの物理的な監視よりも、クラスターサポートのために機能監視が重要である スラ。 各ノードとすべてのノードは、すべてのノードに対して監視する必要があります。MQTTの特長機能だけでなく、応答性 ノード。 これらのチェックは、クラスターレベルだけでなく、全体で行われる必要があります。
大規模な MQTT クラスタをデプロイするときは、各ノードの全体的な設定を行なう必要があります サーバ全体負荷の60〜70%。 これにより、MQTTクラスターヘルスが最適です。 80%を超えて行く 生産中に 1 つまたは 2 つのノードが失敗したときにクラスターの失敗を引き起こします。
HAのセットアップは適用範囲が広く、あらゆる雲でまたは多様にされたセットが付いている前提サーバーに配ることができますデータストレージバリデータオプションをロードします。 ロードバランサの構成は、 接続とデータのバランスを取る必要があります。 しかし、最善の選択肢を作ることも、方法と場所によって異なります クラスターのセットアップがデプロイされます。
MQTT インストールの確保
MQTT インストールのセキュリティ確保は、機密データの保護に不可欠です。 アプリケーションの完全性を維持します。 効果的でMQTTの特長 セキュリティ対策は、 データを不正なアクセスから保護するだけでなく、データ全体の完全性を確保することができます コミュニケーションプロセス全体。 この積極的なアプローチは、潜在的な脅威を軽減し、 IoTエコシステムにおけるシームレスな運用を保証します。
以下は、MQTTインストールのセキュリティを強化するための重要な戦略です。
- TLS/SSL暗号化を使用する・ 導入事例TLS/SSLの特長(トランスポートレイヤーセキュリティ/セキュアソケットレイヤー) 暗号化 クライアントとブローカー間でデータを転送し、イーブスドロップや改ざんを防ぎます。
- 認証の実装- 接続するクライアントのアイデンティティを確認します 強力な実装によりブローカーにMQTTの特長 認証ユーザー名/パスワード、OAuth、トークンベースの認証などのメカニズム
- 認証制御- 認定されたユーザーが公開または公開できることを確認する クライアントを制限するために顆粒アクセス制御リスト(ACLs)を設定することにより、特定のトピックを購読 ロールに基づく権限。
- ロードバランサーを安全に- 無許可に対する負荷バランサーを保護して下さい アクセスと攻撃による IPホワイトリストやファイアウォールルールなどのセキュリティ対策を組み込む。
- クライアント接続を制限する- 同時接続数の制限 そしてメッセージの率 サービスの拒否(DOS)攻撃のリスクを軽減するための公開。
- モニターネットワークトラフィック- 珍しいMQTTトラフィックの追跡と分析 パターンまたは不正なアクセス ネットワーク監視ツールを活用した試み
- 内部コミュニケーションの保護- 仮想プライベートネットワーク(VPN)の構築 内部を安全にするため MQTTブローカーとクライアント間の通信, 追加の保護層を追加します。.
MQTTの特長 クラウド上のクラスタリング
AWSのMQTTクラスタ
Amazon Web Services は、ハードウェア (EC2) インスタンスのオプションのセットを提供しました。 MQTT を実行 クラスターのノード。 AWS EC2 は通信するために使用される必要がある内部 IP アドレスのセットが付属しています 内部的に。 Elastic Load のバランシングは、ポート 1883 または 8883 に TCP の負荷をリダイレクトするオプションです。
AWSのElastic Load Balancer(ELB)は、ロードバランシングに使用する必要があります。 4種類のタイプのうち オプション ELB は、MQTT のネットワーク ロードバランサの設定が必要です。 ネットワーク負荷バランサー TCP対応 ふりがなMQTTブローカー(CrystalMQ) はユーザーをサポートしています インターフェイスだけでなく、 アプリケーションロードバランサで設定します。 しかし、同じネットワークのロードバランサを使用できます。IoTダッシュボードお問い合わせ
AzureのMQTT高可用性
Azure Cloudは、MQTTブローカーを高度にセットアップするのに役立つツールの素晴らしいセットを提供します 冗長 アーキテクチャ。 AWSと同様に、VM、信頼できるデータベースサービス、および使用可能なAzure Load Balancerがあります。 選択した領域のAzureクラウド上で最も手頃な価格のMQTTクラスターを設定する。 Azure のような AWSは、サーバーのコストを節約するために、長期的なコミットメントに基づく割引価格設定を提供します。
セットアップのための詳細なステップバイステップの指示Azure IoT 高機能 よくある質問適用は使用することができます アプリケーションの生産の準備をしなさい。
高可用性 デジタルオーシャンのクラスタリング
弊社では、すべてのホスティングで数年間デジタルオーシャンを使用しています。 私たちについてクラウドホストMQTT ブローカーデプロイメントは、AWSに加えて、Digital Oceanをサポートしています。 私達にそれらと働く大きい時間があります。 デジタルオーシャン ご希望のMQTTブローカーをデプロイするための最も費用対効果の高いDrop(EC2相当)を提供 OS。 MQTT Server のセットは、他のサーバーと同じです。 デジタルオーシャンのネットワーク負荷バランサー MQTT サーバー間でのL3 / TCP Load共有をサポートしています。
全体的に、クラウドベースの展開を検討している場合は、UbuntuまたはRedhatをお勧めします MQTT インスタンスを実行し、 MySQL または PostgreSQL を別のサーバーまたはサーバーで実行するためのサーバー データレイヤーの冗長性が保たれるRDSのようなサービス。
MQTT 高可用性オンプレミス
ウィンドウズ NLB セットアップ:
ほとんどの企業は、Windowsベースの環境ですべての作業負荷を実行します。 もし、 そのような企業、 その後、Windows Serverとネットワークロードバランサー(NLB)の組み合わせは、堅牢な作成に役立ちます MQTTの特長 生産環境のクラスタ。
NLBは、すべてのWindowsサーバーインスタンスの不可欠な部分として動作します。 別のセットのための必要性無し ロードバランサを実行するためのサーバー。 しかし、いくつかの特別なWindows NLB構成は、上で行われる必要があります スイッチ/ルーターを使用すると、すべてのWindows MQTTブローカーが実行中のスムーズなデータ共有を保証します クラスター。 以前のように、MySQL または MSSQL はサーバーの別のセットで実行する必要があります。 マスタースレーブモードまたはマルチマスター。 複数のマスターで実行する場合は、 id をユニークに保つ必要があります。 2 つの DB インスタンスのオッサン設定。
UbuntuのNginxのセットアップ:
Linux環境では、ロードバランサを実行するための追加サーバーが必要です。 ロードバランサの必要性 信頼性を保障するためにモード上の失敗で構成されるため。 Nginxは最も信頼でき、TCP ベースの負荷です アプリケーションのバランスをとる。 詳しく見るNginx の設定 マニュアルMQTT クラスターのセットアップ
データベース構成:
私たちが実行しているMQTTブローカーの数にもかかわらず、我々は保存する能力を持っている必要があります シンジへのデータ すべてのブローカーが接続するデータベース。 データベースは、すべての着信データトラフィックを格納します すべてのノードは、ブローカー内のデータを同期するためによりシームレスになります。 この重要な利点 集中ストレージは、クライアントのMQTTブローカーとの接続を厳守していることです。 IBCの助けを借りて、利用可能なすべてのブローカーにデータをバイパスして、公開サブスクリプションフローを円滑にします。
例えば、ロードバランサーに接続されている2つのMQTTブローカーとクラスターセットを考えてみましょう。 そしてデータベース。 'A' クライアント、パブリッシャーは、ブローカー 1 と 'B' クライアント、購読者に接続されています。 ブローカー2は、ロードバランサを介して。 'A' クライアントは、トピック mqtt1 のデータを公開し、'B' はサブスクライブ お問い合わせ セットアップごとに、MQTT ブローカーは、それぞれに話し合い、IBC を通じてデータベースからデータを共有することができます。 データベースは、ブローカー 2 が、ブローカー 1 で受け取ったデータを取得し、購読しているクライアント 'B' に送信できるようにします。 したがって、すべてのブローカーが、クライアントが接続している誰のデータを受け取り、送信できるようにしますか?
ちなみに、一元化されたストレージのみが必須ではありません。 マスター/スレーブの実装 セットアップ データストレージは、要件に基づいて重みを追加します。
目的のデータベースを選択する際には、MySQL や PSQL を選ぶことが非常に検討できます。 十分なスケールのための このようなクラスターの高い可用性。 全体的に、分散アーキテクチャはより堅牢で、 膨大な数のクライアントからトラフィックを処理する信頼性の高いネットワーク。
データの一貫性を維持し、分散ノード間でスムーズな通信を確保 重要なのは 大規模IoT導入 堅牢なMQTTクラスターアーキテクチャのみが、自信を持たせる 高データトラフィックを処理し、稼働時間を維持し、中断することなくリアルタイムデータを配信します。 お問い合わせ 想いを込めたデザインMQTTブローカー(CrystalMQ)は弾力性を維持するために、 高い利用できる、および信頼できる下 すべての状況。 ミッションクリティカルなアプリケーションをスケーリングしたり、微調整したりしても、 カバー!
私たちのMQTTを ブローカーは今日試してみて、あなたのIoT展開のためのシームレスな接続を体験してください!