--- schema_version: "1" id: 56530e552a8a2c1fee8e50d5d074c9771032b77d630bf6e0185a3e875e614d97 title: VM/ベアメタルの Runtime Fabric collection: mulesoft version: current locale: ja-jp portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/runtime-fabric/1.13/index-vm-bare-metal.md canonical_url: https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-vm-bare-metal source_site: docs.mulesoft.com content_type: documentation content_hash: 9c5316c472f91ba4a37aedbe2fd405c25b20959897a3a0e73306dbc3c439d489 description: MuleSoft Documentation Site release: "1.13" latest: false --- # VM/ベアメタルの Runtime Fabric VM/ベアメタルの Anypoint Runtime Fabric は、クラスターを形成する一連の VM で構成されます。各 VM サービスは、コントローラーノードまたはワーカーノードのいずれかとして機能します。 ![2 つのワーカーにリンクされたコントローラーの図](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/architecture-controller-worker.png) - コントローラー: オーケストレーションサービス、分散型データベース、負荷分散、および Anypoint Platform からクラスターを管理できるサービスを含む、Runtime Fabric の運用専用の VM。 - ワーカー: Mule アプリケーションと API ゲートウェイの実行専用の VM。Mule アプリケーションと API プロキシはワーカーで動作します。 この責務の分離により、Mule アプリケーションの数に基づいてワーカーノードを拡張できます。また、デプロイメントの頻度、アプリケーションの状態の変化、およびインバウンドトラフィックの量に基づいて、コントローラーノードを拡張することもできます。ハードウェア障害が発生した場合にリソースを使用可能にしてアプリケーションを再スケジュールおよび再デプロイするため、ワーカーノードの数を多めにプロビジョニングすることをお勧めします。 デフォルトでは、Runtime Fabric を運用するサービスは、システム内で障害が 1 か所に集中することを防ぐためにコントローラーノード全体にデプロイされます。 VM/ベアメタルの Anypoint Runtime Fabric は、Mule Runtime で適切に動作するように調整された一連のテクノロジー (Docker や Kubernetes など) を使用します。Mule を Runtime Fabric にデプロイしたり管理したりするために、これらのテクノロジーに関する知識は必要ありません。Runtime Fabric の管理には、あらゆる規模のシステムをサポートするために必要な運用レベルおよびインフラストラクチャレベルの経験が必要です。予期せぬ障害に備えて、ベストプラクティスに従い、制御された環境で演習シナリオを実行することをお勧めします。
Anypoint Runtime Fabric での Mule が提供していないアプリケーションやゲートウェイのデプロイメントはサポートされていません。
## [](#開発設定と本番設定)開発設定と本番設定 VM/ベアメタルの Anypoint Runtime Fabric は、開発設定と本番設定をサポートしています。これらのサポート対象設定で、最小限必要なノードとリソースを指定します。 ### [](#開発設定)開発設定 開発設定はテストのみを目的としています。少なくとも 1 つのコントローラーと 2 つのワーカーノードが必要です。コントローラーノードは、Anypoint Platform への接続に使用される内部ロードバランサーとエージェントを実行します。エージェントと Anypoint Platform 間の通信は常にアウトバウンドです。アプリケーションの複数のレプリカを複数のワーカーで実行できます。 ![コントローラー (内部ロードバランサーやエージェントなど) とワーカーが含まれる MuleSoft コントロールプレーンのネットワーク開発アーキテクチャの図](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/architecture-development.png) ### [](#本番設定)本番設定 ![コントロールプレーン、コントローラー (内部ロードバランサーやエージェントなど)、ワーカー、TCP ロードバランサーが含まれる Mule 開発の図](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/architecture-production.png) コントローラーのみが、Anypoint Platform への接続に使用される内部ロードバランサーとエージェントを実行します。 エージェントは任意のコントローラーで実行できます。エージェントの通信は常にアウトバウンドです。 最小要件は、3 つのコントローラーと 3 つのワーカーノードです。3 つのコントローラーにより、1 つのコントローラーが失われた場合のフォールトトレランスが可能になります。2 つのコントローラーが失われた場合のフォールトトレランスを可能にするには、合計 5 つのコントローラーを設定する必要があります。 Mule アプリケーションはワーカーで実行されます。アプリケーションの複数のレプリカを複数のワーカーで実行できます。 ## [](#ネットワークアーキテクチャ)ネットワークアーキテクチャ 次の図は、VM/ベアメタルの Runtime Fabric の一般的なネットワークアーキテクチャを示しています。 ![コントローラーの内部ロードバランサーとワーカーが含まれる Runtime Fabric と TCP ロードバランサーの接続のネットワーク開発アーキテクチャの図](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/architecture-network.png) この図は、コントローラーで実行される内部ロードバランサー間で要求を負荷分散するために使用される、TCP ロードバランサーを示しています。また、ワーカーで実行される Mule アプリケーションの各レプリカに要求を分散する内部ロードバランサーも示しています。 内部ロードバランサーを有効化すると、次のモードがサポートされます。 - **共有モード** VM/ベアメタルの Runtime Fabric で専用の内部ロードバランサーノードを追加していない場合のデフォルト設定です。このモードでは、内部ロードバランサーは指定された量の CPU およびメモリを備えたすべてのコントローラーノードで実行されます。 - **Dedicated Mode (専用モード)** VM/ベアメタルの Runtime Fabric で専用の内部ロードバランサーノードが 1 個以上使用可能な場合のみ有効になります。専用の内部ロードバランサーノードでは、内部ロードバランサーを実行するためにすべての使用可能なリソースが使用されるため、CPU コアとメモリの量を指定できません。 インバウンドトラフィック負荷が高い場合は専用ノードが必要です。自分の環境で専用ノードが必要であるかどうかを判断するには、​[「内部ロードバランサー」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-resource-allocation#internal-load-balancer)​を参照してください。 ![要求 ping が含まれる Runtime Fabric と TCP ロードバランサーの接続のネットワーク開発アーキテクチャの図](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/architecture-network2.png) 1. 受信 HTTP 要求は外部 TCP ロードバランサーに転送されます。 2. TCP ロードバランサーは、Runtime Fabric で使用可能な内部ロードバランサーに要求を転送します。 3. 内部ロードバランサーは要求を復号化し、上の図の Mule アプリケーション (app2) の使用可能なレプリカに転送します。 4. アプリケーションはリクエスターに返送される応答を送信します。 ## [](#runtime-fabric-と他の-paas-プロバイダー)Runtime Fabric と他の PaaS プロバイダー VM/ベアメタルの Anypoint Runtime Fabric には、必要なすべてのコンポーネントが含まれています。これらのコンポーネント (Docker や Kubernetes など) は、Mule Runtime や他の MuleSoft サービスと効率的に連携するように最適化されています。
既存の Kubernetes ベースの PaaS 内で VM/ベアメタルの Anypoint Runtime Fabric をインストールすることはできません。この状況では、​自己管理型 Kubernetes の Runtime Fabric ​を使用することを検討してください。
PaaS ソリューションをすでに使用している場合、PaaS と平行して VM/ベアメタルの Runtime Fabric をデプロイすることをお勧めします。これにより、Anypoint Platform のすべての利点を活用できます。 ## [](#vmベアメタルの-anypoint-runtime-fabric-の共有責任)VM/ベアメタルの Anypoint Runtime Fabric の共有責任 VM/ベアメタルの Anypoint Runtime Fabric が正常に動作するかどうかは共有責任となります。お客様が管理する必要のある領域と MuleSoft によって管理される領域を理解することが重要です。Runtime Fabric は、必要なインフラストラクチャとメンテナンスが確保された場合にのみ正常に機能します。 オンプレミスの Runtime Fabric インスタンスにおける MuleSoft とお客様の共有責任の様子を下図に示します。 ![Runtime Fabric の共有責任](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/runtimefabricresponsibility.png) - MuleSoft の責任: MuleSoft は、Runtime Fabric アプライアンスを管理し、提供されたコンポーネント、Runtime Fabric アプライアンス、Runtime Fabric エージェント、Mule Runtime Engine、および Mule アプリケーションの他の連動関係に対する責任を負います。 - お客様の責任: お客様は、VM/ベアメタルの Runtime Fabric で必要なインフラストラクチャのプロビジョニング、設定、管理の責任を負います。 - インフラストラクチャには如何含まれます。 - VM リソース (CPU、メモリ) - ディスクのパフォーマンスと容量 - オペレーティングシステムとカーネルのパッチ - ネットワークポート - すべての VM 間のシステム時間の同期 - インフラストラクチャのプロビジョニングと管理では、組織の次のチームによる補助が必要になります。 - DevOps チームによるインフラストラクチャのプロビジョニングと管理 - ネットワークチームによる許可ポートの指定とプロキシの設定 - セキュリティチームによるコンプライアンスの検証とセキュリティ証明書の取得 詳細は、​[「VM/ベアメタルの Runtime Fabric インストールの前提条件」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs)​を参照してください。 ## [](#anypoint-management-center-への-runtime-fabric-の接続)Anypoint Management Center への Runtime Fabric の接続 Anypoint Runtime Fabric では、次の操作がサポートされています。 - Anypoint Runtime Manager からアプリケーションをデプロイする。 - API Manager を使用して API ゲートウェイのポリシーの更新をデプロイする。 - Anypoint Exchange でアセットを保存および取得する。 Anypoint Management Center とのインテグレーションを有効にするには、Runtime Fabric にポート 443 での Anypoint Platform へのアウトバウンドアクセス権が必要です。この接続は、相互 TLS を使用して保護されます。コントローラー VM で実行される一連のサービスは、アウトバウンド接続を開始して、アプリケーションをデプロイするために必要なメタデータとアセットを取得します。次に、これらのサービスは他の内部サービスを解釈してそれらと通信し、アセットをローカルにキャッシュしてアプリケーションをデプロイします。
組織のネットワークから必要なアウトバウンド接続を有効にする方法については、ネットワーク管理者にお問い合わせください。