VM/ベアメタルの Runtime Fabric をインストールする前に、このトピックの情報を参照してインストールする準備が整っていることを確認します。
始める前に
| VM/ベアメタルの Runtime Fabric でのインストールの問題のほとんどは、不適切なインフラストラクチャのプロビジョニングまたは設定が原因です。 |
VM/ベアメタルの Runtime Fabric をインストールする前に、以下を完了してください。
-
「VM/ベアメタルの Runtime Fabric の共有責任」を参照する。
インフラストラクチャがハードウェア、オペレーティングシステム、ネットワークの最小要件を満たしていない場合、Runtime Fabric は正常に動作できません。
-
VM/ベアメタルの Runtime Fabric で次のメンバーがタスクを実行する。
-
DevOps チームによるインフラストラクチャのプロビジョニングと管理
-
ネットワークチームによるポートの許可リストへの追加とプロキシの設定
-
セキュリティチームによるコンプライアンスの確認とセキュリティ証明書の取得
組織のこれらのチームと共同で作業を行うことにより、インストールを成功に導き、パフォーマンスや密集の問題を回避することができます。
-
-
VM/ベアメタルの Runtime Fabric をインストールする前に、このトピックの要件を確認して、すべての前提条件が満たされていることを確認する。
最小要件が満たされていない場合、インストールプロセスは失敗します。
開発設定と本番設定の説明は、「VM/ベアメタルの Anypoint Runtime Fabric」を参照してください。
必要に応じて、MuleSoft の担当者に連絡してサポートを要求してください。
一般的なインストール要件
VM/ベアメタルの Runtime Fabric をインストールするには、次の分野の知識が必要です。
-
Linux システムコマンド
-
ルートアクセス権による Linux の操作。インストールには、環境内のすべてのサーバーでルートアクセス (
sudo コマンドを実行するための権限) が必要です -
Terraform の操作 (Amazon Web Services (AWS) で実行する場合)
-
SSL や SSH などのリモート接続メカニズム
以下を計画します。
-
本番と本番以外のアプリケーションで別々の Runtime Fabric を作成する
-
DMZ と非公開ネットワークなど、環境のネットワークスコープに基づいて別々の Runtime Fabric を作成する
-
Runtime Fabric のデフォルトのポッドおよびサービスの CIDR ブロックがリージョンネットワークに干渉しないようにする
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 の機能への影響」を参照してください。
-
必要なハードウェアをプロビジョニングするか、インフラストラクチャプロバイダーを使用して必要なハードウェアを作成するのに十分なクォータを確保します。
-
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 でインバウンドトラフィックを有効化するかどうかを決めます。
インバウンドトラフィックを有効化する場合は、ネットワークのトラフィックを評価して、インバウンドロードバランサー用に専用ノードを設定する必要があるかどうかを決めてください。詳細は、「ネットワーク設定」と「内部ロードバランサー」を参照してください。
オペレーティングシステム要件
各 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 ネットワークポートの要件を示します。
インストール中に使用するポート
次の表に、すべてのノードでアクセスできる必要があるポートを示します。これらのポートは、インストール中にノード間の内部通信で使用されます。インストールが完了したら、これらのポートを安全に無効にできます。
| ポート | プロトコル | 説明 |
|---|---|---|
4242 |
TCP |
帯域幅チェッカー |
61008-61010 |
TCP |
インストール中に使用 |
61022-61024 |
TCP |
インストーラーエージェントのポート |
永続性ゲートウェイで使用するポート
永続性ゲートウェイには、Mule アプリケーションレプリカに永続データを保存するために Postgres 準拠のデータベースが必要です。Kubernetes クラスターがこのデータベースとポートにアクセスできることを確認してください。「永続性ゲートウェイ」を参照してください。
ネットワーク 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 |
アプリケーション固有 |
すべてのノード |
すべてのノード |
要求をアプリケーションにルーティングするために使用される内部サービスポート範囲 |
ポートの 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 |
|
コントロールプレーンとやりとりするための Runtime Fabric メッセージブローカー。 |
443 (v1.8.50 以降) |
TCP (Lumberjack) |
|
Runtime Fabric 用の Anypoint Monitoring エージェント。 |
443 |
HTTPS |
|
アセットを取得するための Anypoint Platform。 |
443 |
HTTPS |
|
Kubernetes ベースチャートリポジトリ。 |
443 |
HTTPS |
|
Kubernetes ベースチャートリポジトリ。 |
443 |
HTTPS |
|
Runtime Fabric バージョンリポジトリ。Runtime Fabric インストールでは、インストールおよびアップグレード時にこのリポジトリからのソフトウェアが使用されます。 |
443 |
HTTPS |
|
アプリケーションアセット用の Anypoint Exchange。 |
443 |
HTTPS |
|
アプリケーションファイル用の Anypoint Exchange。 |
443 |
HTTPS |
|
Runtime Fabric Docker リポジトリ。 |
443 |
HTTPS |
|
Runtime Fabric Docker リポジトリ。 |
443 |
HTTPS |
|
Runtime Fabric Docker リポジトリ。 |
443 |
HTTPS |
|
Runtime Fabric Docker イメージの配信。 |
443 |
HTTPS |
|
Runtime Fabric Docker リポジトリ。 |
443 |
HTTPS |
|
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 アプリケーションや API プロキシをデプロイするには、組織の Mule ライセンスファイルへのアクセス権が必要です。
インストール要件
インストール中、インストールパッケージはインストールのリーダーとして機能するコントローラー 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 個のノードが必要です。
以下のセクションでは、本番設定でのコントローラーノードとワーカーノードの最小システム要件について説明します。
| VM/ベアメタルの Runtime Fabric では、バースト可能な VM を使用したコントローラーノードの実行はサポートされません。アプリケーションをワーカーノードにデプロイする場合、バースト用に vCPU を割り当てることができます。詳細は、「Anypoint Runtime Fabric でのリソース割り当てとパフォーマンス」を参照してください。 |
コントローラーノード
本番環境で必要なコントローラーノードの最小数は 3 です。この要件は、高可用性を維持し、システムパフォーマンスを確保するための最小要件を反映しています。
フォールトトレランスを確保するには、奇数のコントローラーノードが必要です。偶数個のコントローラーノードはサポートされていません。
サポートされるコントローラーノードの最大数は 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) のディスクの読み書きパフォーマンスに変換されます。
-
このディスクは、
etcd デバイスと呼ばれます。
-
-
Docker オーバーレイおよびその他の内部サービス用にプロビジョニングされた 1000 IOPS を備えた最小 250 GiB の専用ディスク。これは、最小で 4 MBps のディスクの読み書きパフォーマンスに変換されます。
-
このディスクは、
docker デバイスと呼ばれます。
-
ワーカーノード
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 は、次の図で示すように最小 3 個のノードを必要とします。
| VM/ベアメタルの Runtime Fabric では、バースト可能な VM を使用したコントローラーノードの実行はサポートされません。アプリケーションをワーカーノードにデプロイする場合、バースト用に vCPU を割り当てることができます。 詳細は、「Anypoint Runtime Fabric でのリソース割り当てとパフォーマンス」を参照してください。 |
以下のセクションでは、開発設定での各コントローラーノードとワーカーノードの最小システム要件について説明します。
コントローラーノード
本番以外の環境で必要なコントローラーノードの最小数は 1 です。偶数個のコントローラーはサポートされていません。1 つのコントローラーのクラスターでは、etcd データベースが破損したときに復元できません。たとえば、 このナレッジ記事に記載された問題がそれに該当します。
サポートされるコントローラーノードの最大数は 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 のディスクの読み書きパフォーマンスに変換されます。
ワーカーノード
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 イメージをキャッシュして、アプリケーションを実行するための一時ストレージを提供し、ログストレージを提供するのに十分な領域を確保できます。