以下の SaltStack Config のシステム要件を使用して、システムでサポート可能な対象を判断します。
Salt のサポート対象のオペレーティング システム
SaltStack Config は、オープンソースの自動化および構成管理エンジンであるSalt上で実行されます。構成管理のために SaltStack Config の使用を開始するには、SaltStack Config を使用して、管理するノードに Salt ミニオン サービスをインストールして実行する必要があります。
Salt 自体はオペレーティング システムに依存しない設計であり、ほとんどの標準オペレーティング システムのノードを管理できます。サポート対象の Salt オペレーティング システムのリストについては、Salt プラットフォーム サポートを参照してください。
SaltStack Config のサポート対象のオペレーティング システム
SaltStack Config のアーキテクチャは、次のいずれかでの操作に適した設計です。
- RHEL 7.4 ～ 7.9
- RHEL 8
- RHEL 9
- CentOS 7
RHEL 7 のバージョンが 7.4 未満の場合は、インストール スクリプトを実行する前に、OpenSSL のバージョンを 1.0.2k にアップデートする必要があります。yum update を使用してこのバージョンを取得できない場合、またはサーバがインターネットに直接アクセスできない場合は、RedHat または任意のパブリック ミラーから以下のパッケージを取得します。
- openssl-1.0.2k-12.el7.x86_64.rpm
- openssl-libs-1.0.2k-12.el7.x86_64.rpm
ミニオン アーキテクチャの決定
SaltStack Config のコンテキストでは、ミニオンは通常、1 つ以上の Salt マスターを介して SaltStack 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 マスターおよびミニオンの数の予測
インストール前にシステムのスループットを測定することは困難ですが、SaltStack Config によって管理されるシステム内のミニオン（ノード）の数に基づいてニーズを予測することはできます。このガイドの最後のセクションでは、システム スループットを判断するための追加の測定について説明します。
SaltStack 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 |
スループットに基づくインストール後のアーキテクチャの最適化
SaltStack Config のインストールが完了した後に、システム監視メトリックを使用して、システムのスループットとアーキテクチャに関するニーズを効率的に特定することができます。
監視対象を特定する場合は、次の要因を考慮してください。
- [イベント システム上のトラフィック量] - イベント システム（「イベント バス」とも呼ばれる）は、Salt マスターと Salt ミニオンの両方によるプロセス間通信に使用されます。イベント バスの使用頻度が非常に高い場合は、メモリの割り当てを増やすことを検討します。
- [1 時間あたりのジョブの戻り値] - SaltStack Config では、SaltStack Config によって実行される各コマンド、タスク、および操作を表すために「ジョブ」という用語を使用しています。各ジョブは、レポート作成とデータ収集のために出力を SaltStack Config に送信します。指定した 1 時間内にシステムによって生成されたジョブの戻り値が、アーキテクチャのニーズに影響する可能性があります。
- [ピラー データの量] - ピラー データは Salt マスターに保存する必要があるデータです。ピラーは主にシークレットや、アカウント認証情報、暗号化キー、パスワードなどその他の秘密データを格納するために使用されます。また、構成データなど、状態ファイルに直接配置することが望ましくない非シークレット データを格納する場合にも役立ちます。Salt マスターに保存され、後で必要に応じてミニオンからアクセスされるデータの量は、メモリとデータ ストレージに関するニーズに影響する可能性があります。
- [カスタム グレインの量] - 特定のジョブまたはコマンドのターゲットにミニオンを設定するには、Salt でグレインを使用します。グレインとは、各ミニオンの基本的なデータと特性を意味します。Salt には、事前に構築された多数のグレインが付属しています。たとえば、オペレーティング システム、ドメイン名、IP アドレス、カーネル、メモリ、およびその他の多くのシステム プロパティによってミニオンをターゲットにすることができます。カスタム Grain データを作成し、システム内で一意のターゲットに設定する特性に基づいてミニオンのグループを別のグループと区別することもできます。作成するカスタム グレインの数が、アーキテクチャに関するニーズに影響する可能性があります。
- [ビーコンとリアクタの数] - ビーコン システムは、Salt ミニオン上のさまざまなシステム プロセスをリッスンできる監視ツールです。ビーコンはリアクタをトリガし、リアクタは変更の実装や問題のトラブルシューティングに役立ちます。たとえば、サービスの応答がタイム アウトになったときにリアクタ システムがサービスを再起動することができます。ビーコンをリアクタと組み合わせることで、インフラストラクチャやアプリケーションの問題に対して、事前に記述された自動応答を作成できます。リアクタを使用すると、事前に記述された修正状態を使用した自動応答によって Salt を拡張できます。定期的にアクティブ化されるビーコンとリアクタがシステムにある場合、システム アーキテクチャに関するニーズが高まる可能性があります。
- [ディスク サイズに関するニーズ] - 管理対象のミニオンの数や、ストレージに保持する必要がある各年のデータに基づいて、ディスク サイズを拡張する必要が生じる場合があります。たとえば、スループットが高いシステムによる、7 ～ 8 年間のデータ保持を必要とする規制の厳しい業界での運用では、ディスク サイズとストレージ容量の拡張が必要になる可能性があります。
- [地理的な場所とコンポーネント間の距離] - Salt マスターと SaltStack Config (RaaS) が実行されているサーバとの間に 65 ミリ秒以上の遅延が発生している場合は、問題が発生する可能性があります。Salt では、Salt ミニオンと Salt マスターの間の遅延による影響は小さく抑えられています。これらのコンポーネントを配置する場合は、必要に応じて、マスターを RaaS の近くに、ミニオンを RaaS から遠くに配置することを推奨します。
- [ビジネス クリティカルな運用] - 使用環境における SaltStack Config のビジネスクリティカル度を評価する場合は、SaltStack Config の停止がビジネスに与える影響について確認します。1 時間以上ダウンした場合、深刻な影響があるかどうかも確認します。影響がある場合は、高可用性に関するニーズを SaltStack Config システム アーキテクチャの設計に取り入れることが必要になる場合があります。
これらの要因に基づいて、リソースを段階的に拡張し、システムのパフォーマンスへの影響を監視することを検討します。たとえば、4 個の CPU を搭載した 4 GB の RAM を増設してメモリ割り当てを増やします。
次の図に、高可用性 SaltStack Config アーキテクチャの設計例を示します。
この図に示すように、多くの高可用性システムが複数の Salt マスターに接続されています。高可用性システムでは、PostgreSQL データベースと Redis データベースに冗長性を組み込むことによって、データベース間のフェイルオーバーを可能にしています。PostgreSQL および Redis の現在の高可用性ソリューションでは手動フェイルオーバーのみがサポートされていることに注意してください。
