以下の Automation Config のシステム要件を使用して、システムでサポート可能な対象を判断します。
Salt のサポート対象のオペレーティング システム
Automation Config は、オープンソースの自動化および構成管理エンジンであるSalt上で実行されます。構成管理のために Automation Config の使用を開始するには、Automation Config を使用して、管理するノードに Salt ミニオン サービスをインストールして実行する必要があります。
Salt 自体はオペレーティング システムに依存しない設計であり、ほとんどの標準オペレーティング システムのノードを管理できます。サポート対象の Salt オペレーティング システムのリストについては、Salt プラットフォーム サポートを参照してください。
Automation Config のサポート対象のオペレーティング システム
Automation Config のアーキテクチャは、次のいずれかでの操作に適した設計です。
- RHEL 7.4 ～ 7.9
- RHEL 8
- RHEL 9
- Photon
RHEL 7 のバージョンが 7.4 未満の場合は、インストール スクリプトを実行する前に、OpenSSL のバージョンを 1.0.2k にアップデートする必要があります。yum update を使用してこのバージョンを取得できない場合、またはサーバがインターネットに直接アクセスできない場合は、RedHat または任意のパブリック ミラーから以下のパッケージを取得します。
- openssl-1.0.2k-26.rpm
- openssl-libs-1.0.2k-26.rpm
サポート対象のその他のオペレーティング システム
Automation Config では次のオペレーティング システムもサポート対象ですが、推奨されません。
- Oracle Linux 7
- SUSE Linux Enterprise Server 15 (SLES 15)
- SUSE Linux Enterprise Server 12 (SLES 12)
これらのオペレーティング システムでの Automation Config のインストールには、手動でのインストール方法が必要になります。これは、Automation Config のエキスパートのサポートがある場合にのみ実行してください。
ミニオン アーキテクチャの決定
Automation Config のコンテキストでは、ミニオンは通常、1 つ以上の Salt マスターを介して Automation Config に接続して管理する本番環境内のノードを意味します。
Salt は、ミニオンで実行されている可能性のあるオペレーティング システムと連携するように設計されています。Salt は、標準的なオペレーティング システム（Linux、Windows、MacOS）に加えて、Arista、Juniper、AIX、Solaris などのさまざまなネットワーク デバイスに固有のオペレーティング システム用の専用ミニオン ソフトウェア（一般に「ネイティブ ミニオン」と呼ばれる）を提供します。
次の表に、Salt ミニオン サービスの最小メモリ要件をオペレーティング システム別に示します。
| オペレーティング システム | メモリの最小要件 |
|---|---|
| AIX ミニオン | 512 MB の RAM |
| MacOS ミニオン | 4 GB の RAM |
| Linux ミニオン | 512 MB の RAM |
| Windows ミニオン | 4 GB の RAM |
| プロキシ ミニオンを含むその他のネットワーク デバイス | 制御されたデバイスあたり 40 MB の RAM |
Salt マスターおよびミニオンの数の予測
インストール前にシステムのスループットを測定することは困難ですが、Automation Config によって管理されるシステム内のミニオン（ノード）の数に基づいてニーズを予測することはできます。このガイドの最後のセクションでは、システム スループットを判断するための追加の測定について説明します。
Automation Config によって管理される Salt ミニオンの数が増えると、それに合わせてシステム アーキテクチャを拡張する必要が生じる場合があります。
次の表に、システム内の管理対象 Salt ミニオン（ノード）の数に基づいて必要になる可能性のある Salt マスターの推奨数を示します。
| ミニオン | Salt マスター (16 CPU/16 GB) |
|---|---|
| 5,000 | 1 |
| 10,000 | 2 |
| 15,000 | 3 |
| 20,000 | 4 |
| 25,000 | 5 |
| 30,000 | 6 |
| 35,000 | 7 |
| 40,000 | 8 |
| 45,000 | 9 |
| 50,000 | 10 |
| 55,000 | 11 |
| 60,000 | 12 |
| 65,000 | 13 |
| 70,000 | 14 |
| 75,000 | 15 |
| 80,000 | 16 |
| 85,000 | 17 |
| 90,000 | 18 |
| 95,000 | 19 |
| 100,000 | 20 |
必要な RaaS ノードの数の予測
次の表に、システム内の管理対象 Salt ミニオン（ノード）の数に基づいて必要になる可能性のある RaaS ノードの推奨数を示します。
| ミニオン | 16 CPU/16 GB の RaaS ノード | 32 CPU/32 GB の RaaS ノード |
|---|---|---|
| 5,000 | 1 | |
| 10,000 | 1 | |
| 15,000 | 1 | |
| 20,000 | 1 | |
| 25,000 | 2 | |
| 30,000 | 2 | |
| 35,000 | 2 | |
| 40,000 | 2 | |
| 45,000 | 1 | 1 |
| 50,000 | 1 | 1 |
| 55,000 | 1 | 1 |
| 60,000 | 1 | 1 |
| 65,000 | 2 | |
| 70,000 | 2 | |
| 75,000 | 2 | |
| 80,000 | 2 | |
| 85,000 | 1 | 2 |
| 90,000 | 1 | 2 |
| 95,000 | 1 | 2 |
| 100,000 | 1 | 2 |
必要な PostgreSQL ノードの数の予測
次の 2 つの表は、システム内の管理対象 Salt ミニオン（ノード）の数に基づいて必要になる可能性のある PostgreSQL データベース ノードの推奨数を示します。
| ミニオン | 8 CPU/8 GB の PostgreSQL ノード | 16 CPU/16 GB の PostgreSQL ノード | 24 CPU/24 GB の PostgreSQL ノード | 32 CPU/32 GB の PostgreSQL ノード |
|---|---|---|---|---|
| 5,000 | 1 | |||
| 10,000 | 1 | |||
| 15,000 | 1 | |||
| 20,000 | 1 | |||
| 25,000 | 1 | |||
| 30,000 | 1 | |||
| 35,000 | 1 | |||
| 40,000 | 1 | |||
| 45,000 | 1 | |||
| 50,000 | 1 | |||
| 55,000 | 1 | |||
| 60,000 | 1 |
| ミニオン | 48 CPU/48 GB の PostgreSQL ノード | 56 CPU/56 GB の PostgreSQL ノード | 64 CPU/64 GB の PostgreSQL ノード |
|---|---|---|---|
| 65,000 | 1 | ||
| 70,000 | 1 | ||
| 75,000 | 1 | ||
| 80,000 | 1 | ||
| 85,000 | 1 | ||
| 90,000 | 1 | ||
| 95,000 | 1 | ||
| 100,000 | 1 |
必要な Redis ノードの数の予測
次の 2 つの表は、システム内の管理対象 Salt ミニオン（ノード）の数に基づいて必要になる可能性のある Redis データベース ノードの推奨数を示します。
| ミニオン | 4 CPU/4 GB の Redis ノード | 8 CPU/8 GB の Redis ノード | 12 CPU/12 GB の Redis ノード |
|---|---|---|---|
| 5,000 | 1 | ||
| 10,000 | 1 | ||
| 15,000 | 1 | ||
| 20,000 | 1 | ||
| 25,000 | 1 | ||
| 30,000 | 1 | ||
| 35,000 | 1 | ||
| 40,000 | 1 | ||
| 45,000 | 1 | ||
| 50,000 | 1 | ||
| 55,000 | 1 | ||
| 60,000 | 1 |
| ミニオン | 16 CPU/16 GB の Redis ノード | 20 CPU/20 GB の Redis ノード |
|---|---|---|
| 65,000 | 1 | |
| 70,000 | 1 | |
| 75,000 | 1 | |
| 80,000 | 1 | |
| 85,000 | 1 | |
| 90,000 | 1 | |
| 95,000 | 1 | |
| 100,000 | 1 |
スループットに基づくインストール後のアーキテクチャの最適化
Automation Config のインストールが完了した後に、システム監視メトリックを使用して、システムのスループットとアーキテクチャに関するニーズを効率的に特定することができます。
監視対象を特定する場合は、次の要因を考慮してください。
- [イベント システム上のトラフィック量] - イベント システム（「イベント バス」とも呼ばれる）は、Salt マスターと Salt ミニオンの両方によるプロセス間通信に使用されます。イベント バスの使用頻度が非常に高い場合は、メモリの割り当てを増やすことを検討します。
- [1 時間あたりのジョブの戻り値] - Automation Config では、Automation Config によって実行される各コマンド、タスク、および操作を表すために「ジョブ」という用語を使用しています。各ジョブは、レポート作成とデータ収集のために出力を Automation Config に送信します。指定した 1 時間内にシステムによって生成されたジョブの戻り値が、アーキテクチャのニーズに影響する可能性があります。
- [ピラー データの量] - ピラー データは Salt マスターに保存する必要があるデータです。ピラーは主に、アカウント認証情報、暗号化キー、パスワードなど、シークレットなどの機密性の高いデータを保存するために使用されます。Salt マスターに保存されているデータの量（さらに後で必要に応じてミニオンがアクセスする量）は、メモリとデータ ストレージのニーズに影響を与える可能性があります。
- [構成データ - マップ ファイル] - これらのファイルは、状態ファイルに直接配置する必要のない重要性の低いデータを格納する際に役立ちます。ピラー データと異なり、これらのマップ ファイルで Salt マスターに追加のリソース制約が発生することはありません。
- [カスタム グレインの量] - 特定のジョブまたはコマンドのターゲットにミニオンを設定するには、Salt でグレインを使用します。グレインとは、各ミニオンの基本的なデータと特性を意味します。Salt には、事前に構築された多数のグレインが付属しています。たとえば、オペレーティング システム、ドメイン名、IP アドレス、カーネル、メモリ、およびその他の多くのシステム プロパティによってミニオンをターゲットにすることができます。カスタム Grain データを作成し、システム内で一意のターゲットに設定する特性に基づいてミニオンのグループを別のグループと区別することもできます。作成するカスタム グレインの数が、アーキテクチャに関するニーズに影響する可能性があります。
- [ビーコンとリアクタの数] - ビーコン システムは、Salt ミニオン上のさまざまなシステム プロセスをリッスンできる監視ツールです。ビーコンはリアクタをトリガし、リアクタは変更の実装や問題のトラブルシューティングに役立ちます。たとえば、サービスの応答がタイム アウトになったときにリアクタ システムがサービスを再起動することができます。ビーコンをリアクタと組み合わせることで、インフラストラクチャやアプリケーションの問題に対して、事前に記述された自動応答を作成できます。リアクタを使用すると、事前に記述された修正状態を使用した自動応答によって Salt を拡張できます。定期的にアクティブ化されるビーコンとリアクタがシステムにある場合、システム アーキテクチャに関するニーズが高まる可能性があります。
- [ディスク サイズに関するニーズ] - 管理対象のミニオンの数や、ストレージに保持する必要がある各年のデータに基づいて、ディスク サイズを拡張する必要が生じる場合があります。たとえば、スループットが高いシステムによる、7 ～ 8 年間のデータ保持を必要とする規制の厳しい業界での運用では、ディスク サイズとストレージ容量の拡張が必要になる可能性があります。
- [地理的な場所とコンポーネント間の距離] - Salt マスターと Automation Config (RaaS) が実行されているサーバとの間に 65 ミリ秒以上の遅延が発生している場合は、問題が発生する可能性があります。Salt では、Salt ミニオンと Salt マスターの間の遅延による影響は小さく抑えられています。これらのコンポーネントを配置する場合は、必要に応じて、マスターを RaaS の近くに、ミニオンを RaaS から遠くに配置することを推奨します。
- [ビジネスクリティカルな運用] - Salt マスターと、Automation Config (RaaS) を実行しているサーバ間に 200 ミリ秒を超える大きな遅延がある場合、問題が発生する可能性があります。
これらの要因に基づいて、リソースを段階的に拡張し、システムのパフォーマンスへの影響を監視することを検討します。たとえば、4 個の CPU を搭載した 4 GB の RAM を増設してメモリ割り当てを増やします。
次の図に、高可用性 Automation Config アーキテクチャの設計例を示します。
この図に示すように、多くの高可用性システムが複数の Salt マスターに接続されています。高可用性システムでは、PostgreSQL データベースと Redis データベースに冗長性を組み込むことによって、データベース間のフェイルオーバーを可能にしています。PostgreSQL および Redis の現在の高可用性ソリューションでは手動フェイルオーバーのみがサポートされていることに注意してください。
