多くのシステム管理者は、キャパシティプランニングを恐れているか、単にそれが不要だと考えています。まず、キャパシティプランニングを恐れる理由はありません（ロケット科学ではありません）。第二に、キャパシティプランニングは100％必要です。これまで、システム管理者は、新しいシステムを組み合わせたり、CPU、RAM、またはより高速なストレージを追加したりして、容量を追加し、パフォーマンスを向上させるための抜本的な意思決定を行う管理者に対処する必要がありました。常にではありませんが、通常、問題はアップグレードと容量の追加を超えて持続しました。しかし、「通常の」修飾子は、システム管理者と管理者を同様に困惑させる方程式の一部であり、実際の容量とパフォーマンスの計画と管理を誰も扱いたくないという点までです。
この問題は苦労する必要はありません。この記事では、Linuxのキャパシティプランニングを開始するために知っておく必要のある5つのことを紹介します。これらのガイドラインは、Linux、Windows、Unix、またはこれらのハイブリッドバージョンなどの任意の環境に適用することもできます。
キャパシティプランニングの基本
キャパシティについて話し合うときは、実際にパフォーマンスについて話し合っています。容量とパフォーマンスは常に一緒に言及されます。あらゆる種類の容量計画を行うには、パフォーマンスを測定および監視する必要があります。容量とは、ボトルネックやエンドユーザーへの影響なしにデータを処理および保存する機能を意味します。ほとんどの場合、システム管理者は、Webサイト、データベース、またはアプリケーションのデータ処理の観点からパフォーマンスを考えます。しかし、それはパフォーマンスが終わるところではありません。バックアップと復元のパフォーマンスについて考えてください。バックアップには、圧縮、重複排除、ディスクからディスクへの転送、またはネットワーク経由の転送が必要です。また、仮想マシンをあるホストから別のホストに移動するには、コンピューティング、ストレージ、およびネットワーク容量が必要であることを忘れないでください。
ここでのポイントは次のとおりです。容量とパフォーマンスは密接に関連しているため、異なる会話に分けることはできません。このプロセスの手順を見てみましょう。
最初：ベースラインを取得する
システムが新品であるか3年前であるかは関係ありません。容量の計画と予測を開始する前に、ベースラインを確立する必要があります。ベースラインはスナップショットではなく、パフォーマンスの長期的なビューであるため、ベースラインの確立には多少時間がかかります。システムごとに少なくとも1か月のベースラインを使用します。 1か月のデータから、容量のニーズを計画および予測できるパフォーマンスの範囲が得られるはずです。
予備の日付を収集した後、調べる必要のある3つの数値があります。ピーク、低、および平均の負荷または使用量です。このデータを分析すると、容量計画プロセスをガイドするために負荷スナップショットに依存できない理由がわかります。ベースラインは、このプロセスのどこにいるかを示します。
次に考慮する必要のあるデータセットは、現在の容量です。 RAM、CPU、ディスク、およびネットワーク容量の情報を評価する必要があります。次に、各システムの最大容量を確認する必要があります。現在の容量と最大容量の違いにより、成長能力が得られます。たとえば、次の構成を持つシステムについて考えてみます。2つのクアッドコアCPU、128GB RAM、RAID 1（ミラーリング）内の2つの1TBディスク、および1つのデュアルGbイーサネットネットワークインターフェイス。したがって、このシステムの最大容量は、4つのクアッドコアCPU、512 GBのRAM、6つのディスク、およびGbイーサネットネットワークインターフェースカード（NIC）などの拡張カード用の2つのオープンPCIeスロットです。
| CPU | 2-クアッドコア | 4-クアッドコア |
| RAM | 128 GB | 512 GB |
| ディスク | 2ディスク-1TB-RAID1 | 6ディスク |
| NIC | 2 GbE（デュアル） | 6 GbE（デュアル）-10 GbE（クワッド） |
次に、2つを比較します。このシステムには、計算能力、ネットワーク、およびストレージを増やすために利用できる容量がはるかに多くあります。これらのハードウェア容量パラメータと1か月分のパフォーマンスデータは、システムのアップグレードまたは完全なテクノロジーの更新のいずれの形式であっても、追加の容量の必要性を予測するための出発点です。
2番目：パフォーマンス監視を設定する
sysstatなどのパフォーマンス監視パッケージをまだお持ちでない場合 インストールすると、デフォルトのリポジトリから簡単に実行できます。 sysstatがあるかどうかを確認してください ：
$ rpm -qa |grep sysstat お持ちでない場合は、次のコマンドを使用してインストールしてください：
$ sudo yum -y install sysstat
次の2つのコマンドを実行して、sysstatを実行します。 のデータコレクターの起動時と起動時のsysstat システム上ののデータコレクター：
$ sudo systemctl enable sysstat sysstat-collect.timer sysstat-summary.timer
$ sudo systemctl start sysstat sysstat-collect.timer sysstat-summary.timer
sysstat パッケージは、CIFS / Sambaからディスク、Linuxタスクまで、さまざまなサブシステムとサービスのパフォーマンス統計を報告する少数のコマンドで構成されています。最も便利なコマンドはsarです 、システムアクティビティレポーター。 sar コマンドは、システムアクティビティ統計の実行リストを提供します。すべてのユーザーがsarを発行できます 統計を表示するコマンド：
$ sar
Linux 4.18.0-80.7.1.el8_0.x86_64 (rhel) 08/14/2019 _x86_64_ (1 CPU)
12:00:24 AM CPU %user %nice %system %iowait %steal %idle
12:10:01 AM all 0.22 0.00 0.43 0.01 0.00 99.33
12:20:32 AM all 1.18 0.05 1.24 0.12 0.00 97.41
12:30:01 AM all 0.27 0.00 0.49 0.01 0.00 99.23
12:40:32 AM all 0.20 0.00 0.38 0.00 0.00 99.41
12:50:32 AM all 0.18 0.00 0.36 0.01 0.00 99.46
デフォルトでは、システム統計は10分ごとに収集されます。 sar コマンドは一般的なシステム統計を表示しますが、はるかに便利で広範な統計オプションはすべてのsarを提供します -Aを使用して提供する必要があります オプション：
$ sar -A
出力が長すぎてここに投稿できませんが、sarのすべてのサブシステムとサービスのすべての統計が表示されることに注意してください 収集します。 sarを参照してください 特定の統計とそのオプションの詳細と詳細については、manページを参照してください。
3番目：データの分析とプロット
sysstat コレクターはシステム情報を収集し、 / var / log / saの下に保持します 。ファイル番号は、それらが収集された月の日です。このデータを収集して分析するための何らかの方法が必要になります。 BlairZajacのOrcaをお勧めします。また、収集したデータを中央リポジトリに転送して処理および表示することをお勧めします。つまり、パフォーマンス統計に悪影響を及ぼし、結果を歪めるため、本番システムで統計を処理しないでください。
Orcaは重要ですが、セットアップはそれほど難しくありません。数年前、Orcaを使用してウェブサーバーでパフォーマンス統計の表示を開始するのに役立つ記事を書きました。 Orcaはしばらく更新されていませんが、ドキュメントと私の記事に示されているように機能します。
4番目：パフォーマンスのしきい値を設定します
本番システムまたは監視対象システムのそれぞれについて、「忙しいのはどれくらいですか？」という質問に答える必要があります。完璧な答えはありません。ある時点で数値を微調整して、これらのしきい値に違反したことから受け取る通知の数を減らすことができます。たとえば、外部の顧客にWebサービスを提供するために負荷分散された5つのWebサーバーがあり、それらのパフォーマンスを監視して、いつシステムをファームに追加するか、またはいつシステムを追加できるかを予測する必要があるとします。もっとオフライン。
予備テストとして、5台のサーバーすべてのCPUしきい値を80％ビジーに設定しました。 1日に2回、システムが80％を超えたことを知らせる電子メールアラートを受信します。問題？ 5つのサーバーすべてから5分ごとに、2時間、1日2回アラートを受信します。これは、これらすべての通知を受け取るのが好きでない限り、しきい値の設定が低すぎることを示しています。
これらのピーク時のパフォーマンスを調べて、しきい値を設定する場所を決定する必要があります。また、全体的な使用率を下げるためにファームにシステムを追加する必要があるかどうかを判断する必要があります。数値を調べた後、どのサーバーのどのピーク時間でも使用率が87％を超えることはないことがわかります。次に、CPUしきい値を90％に設定し、5分ごとにモニターをチェックし続けることにしましたが、アラートしきい値を2時間以上90％持続するように下げました。これは、システムのCPU使用率が2時間以上90％を超えると、通知を受け取ることを意味します。この環境のしきい値は、合理的で管理しやすいものです。数か月の観察の後、ファームに新しいシステムを追加するための許容レベルは、2時間以上にわたってCPUが95％を超えています。
これは、ビジー状態と各サービスの許容レベルを決定するプロセスです。恣意的に見えますが、そうではありません。データを継続的に観察し、その観察に基づいて調整と決定を行っているからです。 2時間の90％の使用率は過度ではありませんが、そのレベルを超えたくない場合は、ユーザーがシステムからデータをプルするときに長い待機時間に悩まされるようになります。
5番目：パフォーマンスアラート
アラートについては説明しましたが、イベント（アラート）を作成および処理するためのソリューションはまだ提供されていません。 sarをチェックするBashスクリプトのような単純なものを作成できます。 使用率のデータですが、商用ソリューションまたはその中間に展開することもできます。アラートソリューションはお勧めしませんが、利用可能なオープンソースの監視およびアラートアプリケーションがいくつかあります。ほとんどがエージェントベースであるため、管理業務のリストに別のサービスのインストールと保守を追加します。
前のセクションで述べたように、特にアラートが携帯電話へのテキストとして表示される場合は、アラートに夢中にならないように、しきい値と許容値を調整する必要があります。何かがダウンしているか問題があり、解決のために注意が必要な場合にのみ通知が必要です。
キャパシティプランニングのジレンマ
最近のキャパシティプランニングとパフォーマンスモニタリングのジレンマは、サーバーのラックを複数購入するのではなく、サーバーハードウェアをリースするか、キャパシティとパフォーマンスがビジネスルールによって動的に処理されるある種のクラウドソリューションを使用していることです。 。 3年間のハードウェアリースでは、必要かどうかに関係なく、3年ごとにハードウェアの更新を行う必要があります。会社で使用しているハードウェアポリシーの種類によって、容量変更の計画方法が確実に変わります。
リースする場合でも、パフォーマンスモニタリングを実行し、容量について考える必要があります。ハードウェアのサイズが小さかったり、購入が少なかったりする場合は、必ず知っておく必要があるからです。購入する場合は、5年間のローリングベースでパフォーマンスとキャパシティプランニングを検討する必要があります。マネージャーやビジネスオーナーは、ハードウェアを購入する場合、3年ごとにハードウェアを交換したくないので、5年と言います。ハードウェアの購入を償却資産として使用している可能性があります。
購入した資産の秘訣は、購入が早すぎて容量を無駄にしたくないということです。最高級のシステムを購入して、それらのシステムの容量を利用せずに5年以内にシステムを更新するだけで、5年後には古すぎて更新やアップグレードを行うことができないという話が、多く出回っています。新しいリースまたは購入したハードウェアを取得するための最終的な収益は、成長を念頭に置いて購入し、使用率に基づいてアップグレードの予算を立てることで、その成長を利用することです。つまり、必要なものを購入し、必要に応じてアップグレードし、次の更新サイクルの前にハードウェア資産を最大限に活用します。
概要
キャパシティプランニングとパフォーマンスモニタリングが連携して、ハードウェアとソフトウェアのライフサイクルの全体像を把握します。監視とアラートを設定し、データを分析するために時間をかけて努力することが重要です。多くの場合、忙しいシステム管理者は、監視のための精巧なソリューションを設定し、それらを無視します。パフォーマンスアラートに夢中になっていることと、ダウンタイムの延長につながるアラートが表示されないことのバランスをとる方法を見つけてください。キャパシティプランニングは、サービスを過剰に使用されているシステムから十分に使用されていないシステムに再展開することで、コストを節約するのにも役立ちます。