--- schema_version: "1" id: 68da3326399baeebf5e31980ff5e20b4493b1490cd77be33b69d8bde5003d44c 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/install-prereqs.md canonical_url: https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs source_site: docs.mulesoft.com content_type: documentation content_hash: 8748532b6ed32294030a271e763a4e63fd88832c0eaef65aa9a84773033ee3a7 description: MuleSoft Documentation Site release: "1.13" latest: false --- # VM/ベアメタルの Runtime Fabric インストールの前提条件 VM/ベアメタルの Runtime Fabric をインストールする前に、このトピックの情報を参照してインストールする準備が整っていることを確認します。 ## [](#始める前に)始める前に
VM/ベアメタルの Runtime Fabric でのインストールの問題のほとんどは、不適切なインフラストラクチャのプロビジョニングまたは設定が原因です。
VM/ベアメタルの Runtime Fabric をインストールする前に、以下を完了してください。 - [「VM/ベアメタルの Runtime Fabric の共有責任」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-vm-bare-metal#shared-responsibility-for-on-premises-runtime-fabric)​を参照する。 インフラストラクチャがハードウェア、オペレーティングシステム、ネットワークの最小要件を満たしていない場合、Runtime Fabric は正常に動作できません。 - VM/ベアメタルの Runtime Fabric で次のメンバーがタスクを実行する。 - DevOps チームによるインフラストラクチャのプロビジョニングと管理 - ネットワークチームによるポートの許可リストへの追加とプロキシの設定 - セキュリティチームによるコンプライアンスの確認とセキュリティ証明書の取得 組織のこれらのチームと共同で作業を行うことにより、インストールを成功に導き、パフォーマンスや密集の問題を回避することができます。 - VM/ベアメタルの Runtime Fabric をインストールする前に、このトピックの要件を確認して、すべての前提条件が満たされていることを確認する。 最小要件が満たされていない場合、インストールプロセスは失敗します。 開発設定と本番設定の説明は、​[「VM/ベアメタルの Anypoint Runtime Fabric」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-vm-bare-metal)​を参照してください。 必要に応じて、MuleSoft の担当者に連絡してサポートを要求してください。 ## [](#一般的なインストール要件)一般的なインストール要件 VM/ベアメタルの Runtime Fabric をインストールするには、次の分野の知識が必要です。 - Linux システムコマンド - ルートアクセス権による Linux の操作。インストールには、環境内のすべてのサーバーでルートアクセス (​`sudo`​ コマンドを実行するための権限) が必要です - Terraform の操作 (Amazon Web Services (AWS) で実行する場合) - SSL や SSH などのリモート接続メカニズム 以下を計画します。 - 本番と本番以外のアプリケーションで別々の Runtime Fabric を作成する - DMZ と非公開ネットワークなど、環境のネットワークスコープに基づいて別々の Runtime Fabric を作成する - Runtime Fabric のデフォルトのポッドおよびサービスの CIDR ブロックがリージョンネットワークに干渉しないようにする ## [](#anypoint-platform-のロールと権限)Anypoint Platform のロールと権限 Runtime Fabric を適切に使用するには、Anypoint Platform アカウントで次のロールと権限が有効になっている必要があります。 - アプリケーションをデプロイして管理するには、Anypoint Runtime Manager を使用するための権限が必要です。アプリケーションをデプロイするには、Anypoint Platform アカウントで「Exchange Contributors (Exchange コントリビュータ)」ロールも有効にする必要があります。 - Anypoint Platform ユーザーの権限を管理するには、Anypoint Access Management を使用するための権限が必要です。 - Runtime Fabric を使用するには、対応する環境の「Organization Administrators (組織のシステム管理者)」ロールまたは「Manage Runtime Fabrics (Runtime Fabric の管理)」権限が必要です。 - Runtime Fabric インスタンスを削除するには、システム管理者に組織レベルの「Manage Runtime Fabrics (Runtime Fabric の管理)」権限が必要です。 ## [](#インフラストラクチャ要件)インフラストラクチャ要件 次のアクションを実行します。 - スワップメモリを無効化します。 - chrony (システムクロック) 状況が同期していることを確認します。 - ウイルス対策アプリケーションやディープパケットインスペクション (DPI) ソフトウェアなどの特定のサードパーティソフトウェアパッケージを使用すると、Runtime Fabric アプライアンスの特定の機能に影響する可能性があります。詳細は、​[「ウイルス対策ソフトウェアと DPI ソフトウェアの Runtime Fabric の機能への影響」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/runtime-fabric-limitations#how-antivirus-and-dpi-software-impacts-runtime-fabric-functionality)​を参照してください。 - 必要なハードウェアをプロビジョニングするか、インフラストラクチャプロバイダーを使用して必要なハードウェアを作成するのに十分なクォータを確保します。 - x86 または x64 アーキテクチャ。x86 および x64 アーキテクチャのみがサポートされています。 - 仮想マシン - プロビジョニングされた IOPS を備えるディスク - 仮想ネットワーク - ファイアウォールおよびセキュリティグループ - ロードバランサー - AWS または Azure を使用してハードウェアをプロビジョニングする場合、必要なリソースを作成するための適切な権限が必要です。
最適なパフォーマンスを確保するには、専用ディスクが必要です。必要なディスクはインストール中に VM/ベアメタルの Runtime Fabric インストーラーによってフォーマットおよびマウントされます。
AWS および Azure プロビジョニングスクリプトのデフォルトの動作では、最小要件によって定義された一連の仮想マシンとディスクが作成されます。また、必要なネットワークポートが設定されたプライベートネットワークも作成されます。これは、プライマリネットワーク内に統合する前に VM/ベアメタルの Runtime Fabric を評価する場合に最適です。デフォルトの動作に互換性があるかどうかを判断するには、ネットワーク管理者にお問い合わせください。組織の要件に合わせてプロビジョニングスクリプトの変更が必要な場合があります。 - ログを組織のログプロバイダーに転送する方法を理解します。 - アラートを設定できるように組織の SMTP プロバイダーの情報を取得します。 - 次のネットワーク項目を確認します。 - アウトバウンド接続がプロキシにルーティングされる。 - アウトバウンドアクセスは、Anypoint Platform に対して websockets (ポート 443 経由) を使用して許可される。 - 組織のネットワークおよびセキュリティポリシー (以下を含む) - CIDR 表記の内部ネットワーク IP アドレス範囲 - Runtime Fabric で使用される CIDR 表記のサブネット範囲 - 公開 IP アドレス (仮想マシンが許可されている場合) - 各 VM へのシェルアクセスの取得方法 - 組織の Mule アプリケーションの機能に応じて、VM/ベアメタルの Runtime Fabric でインバウンドトラフィックを有効化するかどうかを決めます。 インバウンドトラフィックを有効化する場合は、ネットワークのトラフィックを評価して、インバウンドロードバランサー用に専用ノードを設定する必要があるかどうかを決めてください。詳細は、​[「ネットワーク設定」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-vm-bare-metal#network-architecture)​と​[「内部ロードバランサー」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-resource-allocation#internal-load-balancer)​を参照してください。 ## [](#オペレーティングシステム要件)オペレーティングシステム要件 各 Runtime Fabric ノードで同じオペレーティングシステムを使用します。別のオペレーティングシステムバージョンまたはディストリビューションに VM/ベアメタルの Runtime Fabric をインストールしようとすると、インストーラーは失敗します。 VM/ベアメタルの Runtime Fabric には、次のいずれかのオペレーティングシステムが必要です。 - Red Hat (RHEL) - v7.4 ～ v7.9 - v8.0 ～ v8.3 - v8.4 (Runtime Fabric アプライアンスバージョン 1.1.1636064094-8b70d2d 以降を使用) - v8.6 (Runtime Fabric アプライアンスバージョン 1.1.1660253001-ab8f5e5 以降を使用) - CentOS - v7.4 ～ v7.9

CentOS 8 は サービス終了​になっています。代替のオペレーティングシステムを使用することを検討してください。
- Ubuntu v18.04 (Runtime Fabric アプライアンスバージョン 1.1.1625094374-7058b20 以降を使用) - Ubuntu 20.04

コントロールグループ (cgroups) のメモリリークに関する既知の問題があり、その問題により RHEL や CentOS 7 でポッドの作成が失敗したりノードが誤動作したりする可能性があります。詳細は、 ナレッジベース記事​を参照してください。

この問題を回避するには、VM/ベアメタルの Runtime Fabric インストールで RHEL または CentOS 8.x を使用してください。
## [](#ネットワークおよびポートの要件)ネットワークおよびポートの要件 VM/ベアメタルの Runtime Fabric のインストールと操作には、特定のネットワークとポート設定が必要です。

VM/ベアメタルの Runtime Fabric では、クロスリージョンデプロイメントはサポートされていません。各ノード間のネットワークレイテンシーによりクラスターの健全性の問題が発生する可能性があります。
### [](#帯域幅要件)帯域幅要件 高帯域幅ネットワークが必要であり、VM/ベアメタルの Runtime Fabric を操作する各ノード間には 1 GBps 以上の接続、インターネットへのアウトバウンド接続には 100 MBps 以上が必要です。 Runtime Fabric と Anypoint コントロールプレーン間のトラフィックボリュームの例については、次の点を考慮してください。 - Mule Runtime 4.3.0 のイメージは 740 MB です。 - Runtime Fabric アプライアンスのアップグレードには 1.5 GB が必要です。アプライアンスのアップグレードプロセスには、本番サイズのクラスター (3 つのコントローラーと 3 つのワーカー) の場合、約 30 分かかります。 ### [](#必須のポート設定)必須のポート設定 以下のセクションで、VM/ベアメタルの Runtime Fabric の TCP および UDP ネットワークポートの要件を示します。 #### [](#インストール中に使用するポート)インストール中に使用するポート 次の表に、すべてのノードでアクセスできる必要があるポートを示します。これらのポートは、インストール中にノード間の内部通信で使用されます。インストールが完了したら、これらのポートを安全に無効にできます。
Table 1. インストールで必要なポート
ポート プロトコル 説明

4242

TCP

帯域幅チェッカー

61008-61010

TCP

インストール中に使用

61022-61024

TCP

インストーラーエージェントのポート
#### [](#永続性ゲートウェイで使用するポート)永続性ゲートウェイで使用するポート 永続性ゲートウェイには、Mule アプリケーションレプリカに永続データを保存するために Postgres 準拠のデータベースが必要です。Kubernetes クラスターがこのデータベースとポートにアクセスできることを確認してください。​[「永続性ゲートウェイ」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/persistence-gateway)​を参照してください。 #### [](#ネットワーク-tcp-および-udp-ポート)ネットワーク TCP および UDP ポート 次の表に、開く必要があるすべてのポートと、使用されるそれぞれのプロトコルおよび要求の実行元と宛先を示します。
Table 2. TCP と UDP で必要なポート
ポート レイヤー 4 プロトコル レイヤー 5 プロトコル ソース 宛先 説明

123

UDP

NTP

すべてのノード

インターネット

ネットワークタイムプロトコルを介した時計の同期

443

TCP

HTTPS

API コンシューマー

コントローラーノード

イングレスコントローラーへのインバウンド API 要求を許可

443

TCP

WebSockets 経由の AMQP

コントローラーノード

インターネット

Anypoint Platform 管理サービス

443

TCP

HTTPS

すべてのノード

インターネット

API Manager のポリシーの更新、API Analytics の取り込み、リソースの取得 (アプリケーションファイル、コンテナ画像)。

443 (v1.8.50 以降)

TCP

Lumberjack

すべてのノード

インターネット

Anypoint Monitoring、Anypoint Visualizer

5044 (非推奨)

TCP

Lumberjack

すべてのノード

インターネット

Anypoint Monitoring、Anypoint Visualizer

このポートとホスト名は Anypoint Runtime Fabric のバージョン 1.8.50 以降で非推奨になっています。​

以前のバージョンの Anypoint Runtime Fabric を使用している場合、このポートとホスト名を許可リストに追加する必要があります。それより新しいバージョンを使用している場合は、上で指定したポートとホスト名を使用してください。これは、US と EU の両方のクラウドのエンドポイントに適用されます。

53

TCP

DNS

localhost

localhost

内部クラスター DNS

2379、2380、4001、7001

TCP

HTTPS

すべてのノード

コントローラーノード

etcd サーバー通信

3008、3010、3011、3012

TCP

HTTPS/gRPC

すべてのノード

すべてのノード

Anypoint Runtime Fabric 内部サービス

3009

TCP

HTTPS

すべてのノード

内部ネットワーク

Anypoint Runtime Fabric 内部オペレーションセンター

3022 ～ 3025

TCP

SSH

すべてのノード

すべてのノード

内部 SSH コントロールサービス

3080

TCP

HTTPS

すべてのノード

コントローラーノード

Anypoint Runtime Fabric 内部オペレーションセンター

5000

TCP

HTTPS

すべてのノード

コントローラーノード

内部コンテナレジストリ

6060

TCP

HTTPS/gRPC

すべてのノード

すべてのノード

Anypoint Runtime Fabric 内部サービス

6443、8080

TCP

HTTPS/HTTP

すべてのノード

コントローラーノード

Kubernetes API サーバー

7373

TCP

RPC

localhost

localhost

ピアツーピア接続用の Serf RPC

7496

TCP

HTTPS

すべてのノード

すべてのノード

Serf (状態チェックエージェント)/ピアツーピア接続

7575

TCP

gRPC

すべてのノード

すべてのノード

クラスターの状況 API

10248-10250

TCP

HTTPS

すべてのノード

すべてのノード

Kubernetes コンポーネント

10255

TCP

HTTPS

すべてのノード

すべてのノード

Kubernetes コンポーネント

30000-32767

TCP

アプリケーション固有

すべてのノード

すべてのノード

要求をアプリケーションにルーティングするために使用される内部サービスポート範囲

32009

TCP

HTTPS

内部ネットワーク

コントローラーノード

Anypoint Runtime Fabric オペレーションセンター

32009

TCP

HTTPS

コントローラーノード

すべてのノード

オペレーションセンター内部 API

53

UDP

DNS

localhost

localhost

内部クラスター DNS

7496

UDP

HTTPS

すべてのノード

すべてのノード

Serf (状態チェックエージェント)/ピアツーピア接続

8472

UDP

VXLAN

すべてのノード

すべてのノード

オーバーレイネットワーク

30000-32767

UDP

アプリケーション固有

すべてのノード

すべてのノード

要求をアプリケーションにルーティングするために使用される内部サービスポート範囲
### [](#port-ip-addresses-and-hostnames-to-add-to-the-allowlist)ポートの IP アドレスとホスト名の許可リストへの追加 ネットワーク設定で、Anypoint Platform コンポーネントとサービスのホスト名とポートを許可リストに追加し、Anypoint Runtime Fabric がそれらと通信できるようにする必要があります。これは、インストールおよびアップグレード中に連動関係をダウンロードするためにも必要になります。 次の表に、Anypoint Runtime Fabric と Anypoint Platform 間の通信を許可するための許可リストに追加するポートとホスト名を示します。

次の表には、API Manager のポートおよびホスト名は含まれていませんが、これらの許可する必要がある可能性があります。追加のポートおよびホスト名のリストについては、​API Manager のドキュメント​を参照してください。
次のエンドポイントは相互 TLS 認証を使用しているため、接続を確立するためには、次の証明書を許可するための SSL パススルーを設定する必要があります。 - US コントロールプレーン - `transport-layer.prod.cloudhub.io` - `configuration-resolver.prod.cloudhub.io` - EU コントロールプレーン - `transport-layer.prod-eu.msap.io` - `configuration-resolver.prod-eu.msap.io`
ポート プロトコル ホスト名 説明

443

WebSockets 経由の AMQP

  • US コントロールプレーン: transport-layer.prod.cloudhub.io​

  • EU コントロールプレーン: transport-layer.prod-eu.msap.io

コントロールプレーンとやりとりするための Runtime Fabric メッセージブローカー。

443 (v1.8.50 以降)

TCP (Lumberjack)

  • US コントロールプレーン: dias-ingestor-router.us-east-1.prod.cloudhub.io​

  • EU コントロールプレーン: dias-ingestor-router.eu-central-1.prod-eu.msap.io

Runtime Fabric 用の Anypoint Monitoring エージェント。

443

HTTPS

anypoint.mulesoft.com

アセットを取得するための Anypoint Platform。

443

HTTPS

kubernetes-charts.storage.googleapis.com

Kubernetes ベースチャートリポジトリ。

443

HTTPS

docker-images-prod.s3.amazonaws.com

Kubernetes ベースチャートリポジトリ。

443

HTTPS

  • US コントロールプレーン: worker-cloud-helm-prod.s3.amazonaws.com​

  • EU コントロールプレーン: worker-cloud-helm-prod-eu-rt.s3.amazonaws.com ​worker-cloud-helm-prod-eu-rt.s3.eu-central-1.amazonaws.com

Runtime Fabric バージョンリポジトリ。Runtime Fabric インストールでは、インストールおよびアップグレード時にこのリポジトリからのソフトウェアが使用されます。

443

HTTPS

  • US コントロールプレーン: exchange2-asset-manager-kprod.s3.amazonaws.com​

  • EU コントロールプレーン: exchange2-asset-manager-kprod-eu.s3.amazonaws.com ​exchange2-asset-manager-kprod-eu.s3.eu-central-1.amazonaws.com

アプリケーションアセット用の Anypoint Exchange。

443

HTTPS

  • US コントロールプレーン: exchange-files.anypoint.mulesoft.com​

  • EU コントロールプレーン: exchange-files.eu1.anypoint.mulesoft.com

アプリケーションファイル用の Anypoint Exchange。

443

HTTPS

  • US コントロールプレーン: ecr.us-east-1.amazonaws.com​

  • EU コントロールプレーン: ecr.eu-central-1.amazonaws.com

Runtime Fabric Docker リポジトリ。

443

HTTPS

  • US コントロールプレーン: rtf-runtime-registry.kprod.msap.io​。

  • EU コントロールプレーン: rtf-runtime-registry.kprod-eu.msap.io

Runtime Fabric Docker リポジトリ。

443

HTTPS

  • US コントロールプレーン: api.ecr.us-east-1.amazonaws.com​

  • EU コントロールプレーン: api.ecr.eu-central-1.amazonaws.com

Runtime Fabric Docker リポジトリ。

443

HTTPS

  • US コントロールプレーン: prod-us-east-1-starport-layer-bucket.s3.amazonaws.com​ または ​prod-us-east-1-starport-layer-bucket.s3.us-east-1.amazonaws.com​

  • EU コントロールプレーン: prod-eu-central-1-starport-layer-bucket.s3.amazonaws.com​ または ​prod-eu-central-1-starport-layer-bucket.s3.eu-central-1.amazonaws.com

Runtime Fabric Docker イメージの配信。

443

HTTPS

  • US コントロールプレーン: runtime-fabric.s3.amazonaws.com​。

  • EU コントロールプレーン: runtime-fabric-eu.s3.eu-central-1.amazonaws.com

Runtime Fabric Docker リポジトリ。

443

HTTPS

  • US コントロールプレーン: configuration-resolver.prod.cloudhub.io​

  • EU コントロールプレーン: configuration-resolver.prod-eu.msap.io

Anypoint 設定リゾルバー。
### [](#必須のネットワーク設定)必須のネットワーク設定 前述のポート要件に加えて、VM/ベアメタルの Runtime Fabric を操作するには次のネットワーク設定が必要です。 - 他の VM を VM/ベアメタルの Runtime Fabric に追加するための割り当て可能な十分な IP アドレスを持つサブネット。
ポッドの CIDR ブロックが、ポッドまたはサービスが通信のために使用する IP アドレスと重複することはできません。クラスター内のサービスまたはノードにインストールしたサービスが、ポッドまたはサービスの CIDR ブロックと重複する IP 範囲を使用して通信する必要がある場合、競合が発生する可能性があります。CIDR ブロックが使用中であり、その IP アドレスをポッドまたはサービスが通信のために使用していない場合、競合はありません。複数のクラスターをデプロイする場合、各クラスターで同じ IP 範囲を再利用できます。これは、そのアドレスがクラスターノード内に存在し、クラスター間の通信が外部インターフェースで中継されるためです。
- VM/ベアメタルの Runtime Fabric をインストールするために使用する各 VM へのシェル/SSH アクセス。 - 各 VM に割り当てられた静的な非公開 IPv4 アドレス。再起動間で保持されます。 - 内部 Kubernetes 負荷分散を有効にするカーネル IP 転送。インストール中、各 VM で IPv4 転送が有効になります。 - ホスト Linux カーネルがホストされているコンテナとの間でパケットを双方向に変換できるようにするブリッジネット検索条件。このカーネルモジュールは、インストール中に各 VM で有効になります。 - VM/ベアメタルの Runtime Fabric によってトリガーされるメールアラートを管理する SMTP サーバーへのアクセス。 - 各コントローラー VM で実行されている内部ロードバランサーへの外部要求のバランスを取る外部ロードバランサー - インターネットへの発信要求をプロキシ経由でルーティングする必要がある場合、環境の HTTP プロキシ設定 - インターネットへの発信要求をプロキシ経由でルーティングする必要がある場合、Anypoint Monitoring および Visualizer の SOCKS5 プロキシのサポート
VMWare を使用していて、既存のアプリケーションに接続できないまたは新規アプリケーションをデプロイできない場合、MuleSoft ナレッジベースで 「RTF Networking Issues with VMware (VMware での RTF ネットワークの問題)」​を参照してください。
## [](#mule-ライセンス)Mule ライセンス Mule アプリケーションや API プロキシをデプロイするには、組織の ​[Mule ライセンスファイル](https://docs.mulesoft.com/on-premises/latest/installing-an-enterprise-license)​へのアクセス権が必要です。 ## [](#インストール要件)インストール要件 インストール中、インストールパッケージはインストールのリーダーとして機能するコントローラー VM にダウンロードされます。 VM/ベアメタルの Runtime Fabric は、複数の仮想マシンにわたるクラスターとして実行するように設定されています。各 VM は、次のロールのいずれかとして動作します。 - コントローラー VM。Runtime Fabric サービスの運用および実行専用です。内部ロードバランサーはコントローラー VM 内で実行されます。 - ワーカー VM。Mule アプリケーションの実行専用です。 1 つのコントローラー VM がインストール中にリーダーとして機能します。この VM は、インストーラーをダウンロードし、ポート 32009 で他の各 VM にアクセスできるようにします。他の VM はリーダーからインストーラーファイルをコピーしてインストールを実行し、リーダーに参加してクラスターを形成します。 インストール中、一連のプリフライトチェックが実行され、Runtime Fabric のハードウェア、オペレーティングシステム、およびネットワークの最小要件が検証されます。これらの要件が満たされていない場合、インストーラーは失敗します。 インストールプロセスは、次の手順の組み合わせです。 - AWS および Azure の場合、システム要件に従ってインフラストラクチャをプロビジョニングする - VM 全体で Runtime Fabric をインストールする - Anypoint 組織で Runtime Fabric をアクティブ化する。 - 組織の Mule Enterprise ライセンスをインストールする 前記の手順を完了するには、インストールの開始時に各 VM の環境変数を指定します。Mule ライセンスをアクティブ化して追加するには、リーダーに追加の変数が必要です。スクリプトが各 VM で実行され、次のアクションが実行されます。 - 各専用ディスクをフォーマットしてマウントする。 - 各ディスクのマウントエントリを ​`/etc/fstab`​ に追加する。 - iptable ルールを追加する。 - 必要なカーネルモジュールを有効にする。 - インストールを開始する。 インストールのリーダーであるコントローラー VM で次のアクションが実行されます。 - インストール後にアクティベーションスクリプトを実行する。 - 登録後に Mule ライセンス挿入スクリプトを実行する。 ## [](#本番設定要件)本番設定要件 VM/ベアメタルの Runtime Fabric の本番設定では、次の図で示すように少なくとも 6 個のノードが必要です。 ![コントロールプレーン、コントローラー (内部ロードバランサーやエージェントなど)、ワーカー、TCP ロードバランサーが含まれる Mule 開発の図](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/architecture-production.png) 以下のセクションでは、本番設定でのコントローラーノードとワーカーノードの最小システム要件について説明します。
VM/ベアメタルの Runtime Fabric では、バースト可能な VM を使用したコントローラーノードの実行はサポートされません。アプリケーションをワーカーノードにデプロイする場合、バースト用に vCPU を割り当てることができます。詳細は、​「Anypoint Runtime Fabric でのリソース割り当てとパフォーマンス」​を参照してください。
### [](#コントローラーノード)コントローラーノード 本番環境で必要なコントローラーノードの最小数は 3 です。この要件は、高可用性を維持し、システムパフォーマンスを確保するための最小要件を反映しています。 フォールトトレランスを確保するには、奇数のコントローラーノードが必要です。偶数個のコントローラーノードはサポートされていません。 サポートされるコントローラーノードの最大数は 5 です。 各コントローラーノードには以下のリソースが必要です。 - 最小 2 個の専用コア。 - 最小 8 GiB のメモリ。 コントローラーノードのサイズを変更する場合、内部ロードバランサーに必要なリソース量を検討する必要があります。詳細は、​[「内部ロードバランサー」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-resource-allocation#internal-load-balancer)​のリソースの割り当てを参照してください。 - 最小 80 GiB のオペレーティングシステム専用ディスク。 - `/tmp`​ ディレクトリ用に最小 20 GiB。​`/tmp`​ ディレクトリには参照、書き込み、実行可能権限が必要です。 - `/opt/anypoint/runtimefabric`​ ディレクトリ用に最小 8 GiB。 - `/var/log/`​ ディレクトリ用に最小 1 GiB。 - etcd 分散型データベースを実行するためにプロビジョニングされた最小 3000 IOPS を備えた最小 60 GiB の専用ディスク。これは、最小で 12 メガバイト/秒 (MBps) のディスクの読み書きパフォーマンスに変換されます。 - このディスクは、​`etcd`​ デバイスと呼ばれます。 - Docker オーバーレイおよびその他の内部サービス用にプロビジョニングされた 1000 IOPS を備えた最小 250 GiB の専用ディスク。これは、最小で 4 MBps のディスクの読み書きパフォーマンスに変換されます。 - このディスクは、​`docker`​ デバイスと呼ばれます。 #### [](#スケーリングの考慮事項)スケーリングの考慮事項 次のような状況では、コントローラーノードの数をスケールすることを検討してください。 - コントローラーノードのハードウェア障害の影響を軽減するためにフォールトトレランスが必要である。3 つのコントローラーノードを最小要件とすることで、1 つのコントローラーが失われた場合のフォールトトレランスが可能になります。2 つのコントローラーが失われた場合のフォールトトレランスを可能にするには、合計 5 つのコントローラーを設定する必要があります。 - VM/ベアメタルの Runtime Fabric で実行されているアプリケーションで本番トラフィックが処理されている。 ### [](#ワーカーノード)ワーカーノード VM/ベアメタルの Runtime Fabric は、Mule アプリケーションと API ゲートウェイを実行するために少なくとも 3 個のワーカーノードを必要とします。 サポートされるワーカーノードの最大数は 16 です。 ノードが使用できなくなった場合 (フォールトトレランス) や、再起動を必要とするメンテナンス操作中 (OS パッチの適用など) にアップタイムを維持するには、1 つ以上の追加のワーカーノードをプロビジョニングします。 これにより、ワーカーノードをクラスターから安全に削除して、アプリケーションの可用性に影響を及ぼすことなくアップグレードを適用できます。

Runtime Fabric は、内部サービス用としてワーカーノードごとに最大 0.5 個のコアを予約できます。これは、必要な CPU コアおよびワーカーノードの量を決定する場合に重要です。

たとえば、Runtime Fabric で 3 個のワーカーノードとそれぞれのワーカーノードについて 2 個の CPU コアを使用することもできます。Runtime Fabric でワーカーノードあたり 0.3 個のコア、合計 0.9 個のコアを予約している場合、Runtime Manager に表示される使用可能なコア数は 6 個の vCPU ではなく 5.1 個の vCPU です。
各ワーカーノードには以下のリソースが必要です。 - 最小 2 個の専用コア。 - 最小 15 GiB のメモリ。 Runtime Fabric で実行する Mule およびトークナイザーの数や、デプロイするためにどのようなライセンスを付与するのかを検討する必要があります。オーバーヘッドのためにワーカーノードあたり約 0.5 コアを計画します。 - 最小 80 GiB のオペレーティングシステム専用ディスク。 - `/tmp`​ ディレクトリ用に最小 20 GiB。​`/tmp`​ ディレクトリには参照、書き込み、実行可能権限が必要です。 - `/opt/anypoint/runtimefabric`​ ディレクトリ用に最小 8 GiB。 - `/var/log/`​ ディレクトリ用に最小 1 GiB。 - Docker オーバーレイおよびその他の内部サービス用にプロビジョニングされた最小 1000 IOPS を備えた最小 250 GiB の専用ディスク。これは、最小で 4 MBps のディスクの読み書きパフォーマンスに変換されます。 250 GiB あれば、アプリケーションを実行し、Docker イメージをキャッシュして、アプリケーションを実行するための一時ストレージを提供し、ログストレージを提供するのに十分な領域を確保できます。 ### [](#本番環境の追加のリソース要件)本番環境の追加のリソース要件 VM/ベアメタルの Runtime Fabric を本番環境で使用する場合: - 各コントローラー VM で実行されている内部ロードバランサーに外部要求の負荷を分散するように外部ロードバランサーを設定し、TCP ポート 443 の状態チェックを設定する必要があります。各コントローラーノードで構成されるサーバープールを使用した TCP ロードバランサーで十分です。 - 可用性を維持するため、内部ロードバランサーを 3 個以上のレプリカで実行します。 - インバウンド要求を処理するアプリケーションは 2 個以上のレプリカに拡大する必要があります。 ## [](#開発設定要件)開発設定要件 開発環境では、VM/ベアメタルの Runtime Fabric は、次の図で示すように最小 3 個のノードを必要とします。 ![コントローラー (内部ロードバランサーやエージェントなど) とワーカーが含まれる MuleSoft コントロールプレーンのネットワーク開発アーキテクチャの図](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/architecture-development.png)
VM/ベアメタルの Runtime Fabric では、バースト可能な VM を使用したコントローラーノードの実行はサポートされません。アプリケーションをワーカーノードにデプロイする場合、バースト用に vCPU を割り当てることができます。 詳細は、​「Anypoint Runtime Fabric でのリソース割り当てとパフォーマンス」​を参照してください。
以下のセクションでは、開発設定での各コントローラーノードとワーカーノードの最小システム要件について説明します。 ### [](#コントローラーノード-2)コントローラーノード 本番以外の環境で必要なコントローラーノードの最小数は 1 です。偶数個のコントローラーはサポートされていません。1 つのコントローラーのクラスターでは、etcd データベースが破損したときに復元できません。たとえば、 [このナレッジ記事](https://help.salesforce.com/s/articleView?id=001121251&type=1)​に記載された問題がそれに該当します。 サポートされるコントローラーノードの最大数は 5 です。 各コントローラーノードには以下のリソースが必要です。 - 最小 2 個の専用コア。 - 最小 8 GiB のメモリ。 - 最小 80 GiB のオペレーティングシステム専用ディスク。 - `/tmp`​ ディレクトリ用に最小 20 GiB。​`/tmp`​ ディレクトリには参照、書き込み、実行可能権限が必要です。 - `/opt/anypoint/runtimefabric`​ ディレクトリ用に最小 8 GiB。 - `/var/log/`​ ディレクトリ用に最小 1 GiB。 - etcd 用にプロビジョニングされた 3000 IOPS を備えた最小 60 GiB の専用ディスク。これは、最小で 12 メガバイト/秒 (MBps) のディスクの読み書きパフォーマンスに変換されます。 - Docker オーバーレイおよびその他の内部サービス用にプロビジョニングされた 1000 IOPS を備えた最小 100 GiB の専用ディスク。これは、最小で 4 MBps のディスクの読み書きパフォーマンスに変換されます。 ### [](#ワーカーノード-2)ワーカーノード VM/ベアメタルの Runtime Fabric は、Mule アプリケーションと API ゲートウェイを実行するために少なくとも 2 個のワーカーノードを必要とします。 サポートされるワーカーノードの最大数は 16 です。 ノードが使用できなくなった場合 (フォールトトレランス) や、再起動を必要とするメンテナンス操作中 (OS パッチの適用など) にアップタイムを維持するには、1 つ以上の追加のワーカーノードをプロビジョニングします。 これにより、ワーカーノードをクラスターから安全に削除して、アプリケーションの可用性に影響を及ぼすことなくアップグレードを適用できます。

Runtime Fabric は、内部サービス用としてワーカーノードごとに最大 0.5 個のコアを予約できます。これは、必要な CPU コアおよびワーカーノードの量を決定する場合に重要です。

たとえば、Runtime Fabric で 3 個のワーカーノードとそれぞれのワーカーノードについて 2 個の CPU コアを使用することもできます。Runtime Fabric でワーカーノードあたり 0.3 個のコア、合計 0.9 個のコアを予約している場合、Runtime Manager に表示される使用可能なコア数は 6 個の vCPU ではなく 5.1 個の vCPU です。
各ワーカーノードには以下のリソースが必要です。 - 最小 2 個の専用コア。 - 最小 15 GiB のメモリ。 - 最小 80 GiB のオペレーティングシステム専用ディスク。 - `/tmp`​ ディレクトリ用に最小 20 GiB。​`/tmp`​ ディレクトリには参照、書き込み、実行可能権限が必要です。 - `/opt/anypoint/runtimefabric`​ ディレクトリ用に最小 8 GiB。 - `/var/log/`​ ディレクトリ用に最小 1 GiB。 - Docker オーバーレイおよびその他の内部サービス用にプロビジョニングされた最小 1000 IOPS を備えた最小 100 GiB の専用ディスク。これは、最小で 4 MBps のディスクの読み書きパフォーマンスに変換されます。 100 GiB あれば、アプリケーションを実行し、Docker イメージをキャッシュして、アプリケーションを実行するための一時ストレージを提供し、ログストレージを提供するのに十分な領域を確保できます。