700以上のサーバーをSaltに移行した方法
長い間、データの一部がMySQLに格納され、他の部分がPuppet 3.8である2つのGitリポジトリを使用した、複雑で面倒な構成に満足していました。しかし、私たちのニーズは徐々に高まり、サービスの数が増え、構成のパフォーマンスが低下しました。次に、構成を改善し、利用可能なすべてのデータとツールを最適化するというタスクを設定します。
私たちのチームは、3つの段階で自分たちに適した構成を選択しました。私たちは、塩の最適化の経験、余分な努力なしに適用およびカスタマイズする方法を共有します。
注： Habréでは、同僚からのすばらしい記事を見つけたので、すでに取り上げた問題については詳しく説明しません。以下を読むことを強くお勧めします：
SaltStackの良い点と、SaltStackで解決できるタスク-からの記事ptsecurity、PositiveTechnologies。
インストール、起動、最初のコマンド、および機能の知識-著者の記事zerghack007..。
Saltは、構成管理およびリモート実行システムです。Pythonで記述されたオープンソースインフラストラクチャフレームワーク。
なぜ塩？
Salt、Ansible、Puppet、およびChefは、構成管理ツールを選択するための適切なオプションです。次の利点を優先したため、Saltを選択しました。
- Ansibleとは異なり、モジュール性、無料バージョンでのAPIの可用性。
- Python。つまり、コンポーネントを簡単に理解し、不足している機能を自分で作成できます。
- 高性能とスケーラビリティ。ウィザードは、最大のパフォーマンスを得るためにZeroMQを使用してミニオンとの永続的な接続を確立します。
- リアクターは、特定のメッセージがメッセージバスに表示されたときに実行される一種のトリガーです。
- オーケストレーション-複雑な関係を構築し、特定の順序でアクションを実行する機能。たとえば、最初にロードバランサーを構成し、次にWebサーバークラスターを構成します。
- PuppetとChefはRubyで書かれています。私たちのチームには、このプログラミング言語を扱う有能な専門家がいませんが、Pythonはよく知られており、私たちによってよく使用されています。
- 以前にAnsibleを使用したチームの場合、Ansibleプレイブックを使用する機能が関係します。これにより、痛みを伴わずにソルトに移行できます。
注意：
Saltを使用してから2年近くになりますが、次の点に注意することをお勧めします。
- Salt, , . , . , SaltStack .
- SaltStack . , . : , . , cmd.run file.managed, .
, , , .
. .
与えられた：
したがって、初期構成は次のとおりです。
- 2つのGitリポジトリ（1つはエンジニアと管理者用、もう1つは非常に重要なサーバー用で、管理者のみが利用できます）。
- MySQLのデータ。
- 他の部分-Puppet3.8（継承でやり過ぎ、実際にはHieraを使用しない-キー値ストレージ）。
目的：構成管理システムをSaltに移行し、そのパフォーマンスを向上させ、サーバー管理をより便利で理解しやすいものにすること。
解決策：
まず、元の構成を重要ではない個別のサービスサーバーからSaltに移行すると同時に、廃止されたコードを削除し始めました。
次に、VDSサーバーの構成を準備しました。私たちの場合、これらはサービスサーバー、開発サーバー、およびクライアントサーバーのプロファイルです。
PuppetからSaltに切り替える際の主な問題は、古いオペレーティングシステムでした（2018年には、Ubuntu 12.04と14.04がありました）。移行する前に、OSを更新する必要があり、サービス/サーバーの動作に影響を与えません。そうでなければ、すべてが十分に簡単でした：同僚は徐々にプロセスに関与しました。
主な利点の中で、チームは、たとえば、より理解しやすい構文に注目しました。同僚と私はSaltBest Practicesのヒントを使用することに同意しましたが、私たちの特殊性を反映した独自の推奨事項で補足しました。
チームは、構成の配信方法も評価しました。プッシュ（マスターの「プッシュ」）とプル（ミニオンの「プル」）です。マスターレスモードは、単純なものをテストする必要があると同時に、Gitリポジトリを台無しにしない場合に役立ちます。ミニオンをマスターレスモードで実行すると、別のマシンのソルトマスターに移動しなくても、あるマシンでソルト構成管理を使用できます。構成は完全にローカルです。
このようなソリューションで最大300のミニオンがあり、深刻な問題は発生しませんでした。その時点でのマスター構成は、6コアと4GBのメモリを備えたVDSです。
ただし、ミニオンの数が300に達するとすぐに、負荷平均（平均システム負荷）が3.5〜4に増加し、システムの速度が大幅に低下しました。以前は、state.applyコマンドに30〜40秒かかりましたが、現在は18分かかります。
もちろん、この結果は私たちには受け入れられませんでした。さらに、他社の専門家が10,000人の手先の成功事例について書いています。私たちは何が問題なのかを理解し始めました。
マスターの観察は質問に明白な答えを与えませんでした。十分なメモリがあり、ネットワークがロードされておらず、ディスクが10％使用されていました。 GitLabが原因だと思っていましたが、それも原因ではありませんでした。
十分なプロセッサパワーがなかったようです。コアを追加すると、負荷平均が自然に低下し、state.applyコマンドが実行されましたが、約5〜7分速くなりましたが、思ったほど速くはありませんでした。
ワーカーを追加することで問題は部分的に解決しましたが、メモリ消費量が大幅に増加しました。
次に、構成自体を最適化することにしました。
ステージ1
ピラーは保護されたストレージであるため、ストレージへのアクセスは暗号化操作に関連付けられており、CPU時間でアクセスの料金を支払う必要があります。したがって、柱への呼び出しの数を減らしました。同じデータが1回だけ取得されました。他の場所で必要な場合は、インポートを介してアクセスしました（{％-from'defaults / pillar.sls 'import profile％}）。
構成は1時間に1回適用され、実行時間はランダムに選択されます。1分間に実行されるタスクの数と、1時間の間にどれだけ均等に分散されるかを分析した結果、1時間の初め、1分から8分までで最も多くのタスクが通過し、34分では何も通過しないことがわかりました。週に1回、すべてのミニオンを通過し、タスクを均等に分散するランナーを作成しました。このアプローチのおかげで、負荷はジャンプすることなく均一になりました。
アイアンサーバーに移行する提案がありましたが、当時はそこになく、別の方法で問題を解決しました。メモリを追加し、キャッシュ全体をその中に配置しました。Grafanaダッシュボードを見ると、負荷平均が0.5に低下したため、ソルトマスターが機能していないと最初に考えました。state.applyの実行時間を確認したところ、20〜30秒という驚きもありました。勝利でした！
ステージ2
6か月後、ミニオンの数は650に増加し、...パフォーマンスの低下が再び発生しました。負荷平均グラフは、ミニオンの数とともに大きくなります。
最初に行ったのは、ピラーキャッシュを有効にし、有効期間を1時間に設定したことです（pillar_cache_ttl：3600）。これで、コミットは瞬時ではなく、マスターがキャッシュを更新するのを待つ必要があることに気付きました。
まったく待ちたくなかったので、GitLabでフックを作りました。これにより、コミットで、キャッシュを更新する必要があるミニオンを示すことができます。柱のキャッシュにより、負荷が大幅に軽減され、構成を適用する時間が短縮されました。
ステージ3
デバッグログについて少し瞑想し、仮説を立てました。ファイルバックエンドとファイルリストキャッシュ（gitfs_update_interval、fileserver_list_cache_time）の更新間隔を増やすとどうなるでしょうか。更新は1分に1回行われ、場合によっては最大15秒かかりました。更新間隔を1分から10分に増やすことで、再びスピードを上げました！LA指標は1.5から0.5に減少しました。構成を適用する時間は、目的の20秒に短縮されました。LAがしばらくして再び成長したという事実にもかかわらず、state.applyの実行速度は大きく変化しませんでした。これらのキャッシュの強制更新がgitpushのフックに追加されました。
Elasticsearchに分析を追加しました。組み込みのelasticsearch_returnを書き直し、state.applyの結果（平均実行時間、最長の状態、エラー数）を監視できるようになりました。
結果
これで、Saltのパフォーマンスに完全に満足しました。ミニオンの数を2倍にする計画があります。私たちのマスターがそのような負荷にどのように対処するかはまだ言うのが難しいです。おそらく、水平スケーリングに目を向けるか、魔法のパラメータを見つけるでしょう。時が教えてくれる！
バックエンドとしてgitfsを使用している場合は、5を指定してください。たぶん、あなたは私たちと同じ問題を経験しているでしょう。そのため、コメントでこのトピックについて喜んで話し合います。