SaltStack Config のインストールに必要なシステム アーキテクチャは、1) SaltStack Config のデプロイに使用しているインストール方法と 2) 環境のスループット(SaltStack Config を使用してシステムで実行する作業の量)という 2 つの主な要因によって決まります。

開始する前に

システム アーキテクチャに対するニーズを正確に評価するには、まず次の内容について確実に理解しておく必要があります。

  • SaltStack Config で使用できる 2 つのインストール方法
  • SaltStack Config SaltStack アーキテクチャの 4 つの基本コンポーネント(RaaS、Salt マスター、PostgreSQL、Redis)

インストール プロセスの一般的な概要を含む、これらの概念の概要については、SaltStack Config のインストールと構成を参照してください。インストール シナリオの選択のガイダンスについては、推奨のインストール シナリオも参照してください。

ミニオン アーキテクチャの決定

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

インストール シナリオの決定

インストール シナリオの選択のガイダンスについては、推奨のインストール シナリオを参照してください。お使いのシステムに最適なインストール方法が不明な場合は、標準インストールをお勧めします。ノード数が 1,000 台を超える本番環境のシステムでは、Lifecycle Manager インストール方法は推奨されません。

Lifecycle Manager インストールを選択する場合、必要なノードは 1 台のみで、次のシステム アーキテクチャが必要になります。

ハードウェア 最大で 1,000 台のノード(ミニオン)
[コア] 16 個の CPU コア
[RAM] 32 GB の RAM
[ディスク容量] 260 GB 以上の空き容量

以降、このガイドでは、標準インストール シナリオにおけるアーキテクチャのニーズについて説明します。

管理される Salt ミニオン数の予測

インストール前にシステムのスループットを測定することは困難ですが、SaltStack Config によって管理されるシステム内のミニオン(ノード)の数に基づいてニーズを予測することはできます。このガイドの最後のセクションでは、システム スループットを判断するための追加の測定について説明します。

SaltStack Config によって管理される Salt ミニオンの数が増えると、それに合わせてシステム アーキテクチャを拡張する必要が生じる場合があります。

必要な 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
注:

このドキュメントでは、SaltStack Config オンプレミス アーキテクチャについて説明します。SaltStack Config クラウドは現在、Salt マスターを 1 つのみ実行できます。つまり、ミニオン数は 20,000 未満に制限されています。

必要な 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 の現在の高可用性ソリューションでは手動フェイルオーバーのみがサポートされていることに注意してください。