自動スケーリング-リソースの自動垂直スケーリング用ツール（CPU | RAM | HDD）

今年の初めに、 クラウドVDSはパブリックAPIを導入しました。 クライアントは、パネルと同じようにクラウド仮想マシンとディスクでほぼすべてのアクションを実行できます：ディスクとVMの作成、削除、関税とディスクサイズの変更など。

APIの出現とともに、マシン内で動作する仮想マシン（VM）のリソースの監視システムを実装し、必要に応じて必要なリソース（自動スケーリング（AS））を自動的に増減するというアイデアが生まれました。



状況が危機に近いことを理解するために、ASはしばらくの間観察を行わなければなりません。 結局のところ、瞬時に負荷が急増する状況は、料金を変更するのに十分な理由ではない可能性が高いです。 したがって、ASが状況が重大であることを認識すると、何らかの悪い状況がすでに発生している可能性が高いことを考慮する価値があります（サイトのページが訪問者によって1分間ロードされていないか、VMの一部のプロセスが既にクラッシュしています） OOM-Killerによって終了します。これは、RAMが使い果たされた場合にシステムの残りの部分が動作し続けるように、どのプロセスを犠牲にするかを選択するLinuxカーネルサブシステムです。 つまり、ASはリソースの不足からサービスを保護することを保証する特効薬ではありません。 しかし、タイムリーな拡張によるリソースの枯渇による悪影響を最小限に抑えるように設定されています。 彼はあなたが自分で気づくよりも早く確実にそれを行うか、あなたのサーバーに問題が発生したことを発見し、あなたが手でリソースを拡大するためにVMコントロールパネルに到達する時間があるでしょう。 さらに、ほとんどの場合（すべてが負荷の増加のプロファイルに依存します）、ASは、リソースの不足が明確な否定的な方法で現れる前に関税を切り替えます。



同時に、リソースに関する重大な状況が観察されない場合、ASはこの特定の関税を実際に使用する必要があるかどうか、または安価な関税で十分かどうかを理解しようとしています。 VMの品質。



ディスクでも同様です。 スペースが不足する前に拡張しようとします。 ディスクの場合、自動化は上方向にのみ機能します。 ファイルシステムの縮小は、仮想マシンを停止する必要があるオフライン操作です。 必要に応じて、コントロールパネルからこれを行うことができます。



異なる基準に従ってASを含める可能性を共有しました。 たとえば、VM内で実行されているプロセスの速度が作業の安定性ほど重要ではなく、追加のお金を必要としない場合は、メモリ基準によって自動スケーリングを個別に有効にできますが、プロセッサに含めることはできません。 たとえば、大きなデータ配列をデータベースにアップロードしたり、他のスケジュールされた大きなデータ配列の処理など、ある種の重い長時間のプロセスが仮想マシンで定期的に起動される場合、このプロセスがいつ完了するかは重要ではありません： 1〜2時間ですが、このプロセスが原則として終了し、RAMが不足した場合にオペレーティングシステムによって誤って強制終了されないことが非常に重要です。



または、VMで実行している小さなアプリケーションがあり、追加のメモリとCPUを必要としないが、そこから絶えず蓄積するログがディスク全体を詰まらせ、重要なプロセスを停止させることを恐れている場合は、自動拡張のみを有効にすることができます運転して、拡張を許可する準備ができている最大制限を選択します。 プロセッサやメモリでスケーリングするには、料金プランのラインでリソースを変更するための上限と下限も設定する必要があります。



料金を変更したり、ドライブを拡張したりするたびに、コントロールパネルから連絡先に通知内容が送信され、何が行われたかとその理由が説明されます。 したがって、これが異常な状況であると思われる場合は、すぐにサーバーにアクセスして、負荷が増加した理由またはディスク全体が正確に詰まっている原因を把握できます。



それがどのように機能するかを詳しく見てみましょう。



したがって、この場合、 自動スケーリングはcronによって実行されるPythonスクリプトのセットです。 起動時に、以前の測定履歴を読み取り、システムの追加の必要な診断を行い、次の開始のために更新された履歴を保存し、受信したデータを評価し、必要に応じて、料金を変更するかディスクを拡張する、または単に完了するアクションを実行します。



自動スケーリングドライブ。

複数のドライブを仮想マシンに接続できます。 自動スケーリングはドライブごとに個別に有効にでき、ドライブを自動的に拡張できる制限を個別に設定できます。



制限事項：

デフォルトでは、ext4ファイルシステムは新しいディスクにインストールされますが、ユーザーは後で他のファイルシステム、パーティションテーブル、lvmなど、必要なものをディスクにインストールできます。 FSはディスク自体と同様に自動的に拡張する必要があるため（そうでなければ、ASの本質は失われます）、ディスクにインストールされているものに関して破壊的なアクションをとるリスクがあり、最も不快なケースでは、データ損失に。 したがって、標準のext4 FSでのみ動作するASの機能を制限することにしました。



また、Centos6ベースのシステムのドライブでは自動スケーリングを有効にできません。これは、古いカーネルが使用されているためです。udevは正常に動作せず、その結果、ドライブの拡張後にファイルシステムは自動的に拡張しません。



仕事のメカニズム：

cronによると、ディスク上で7分ごとに1回自動スケーリングが開始されます。 システムに接続されているすべてのドライブに関する情報は、利用可能なすべてのソースから収集されます。

1.パネルでASを設定すると、設定がjson /etc/autoscaling/autoscaling.confの形式で仮想マシンに送信されます。 このVM（それらのuid）に接続されているすべてのディスクのリスト、それらに対して自動スケーリングが有効になっているかどうか、および拡張可能な最大数に関する情報があります。

2. / sys / class / blockのVM内で、システムに表示されるすべてのディスクのリストを取得します。

3. / proc /パーティションから、ディスクのサイズを取得します。

4. / proc / mountsから、FSのタイプと、読み取り/書き込みモードでマウントされているかどうかに関する情報を抽出します。

5.出力dfから、FSのサイズに関する情報と、FSに残っている空きスペースの量を取得します。



ディスク上の必要な情報をすべて収集できた場合、適切なFS（ext4）があり、ASが有効になっている場合、チェックが実行されます：FSに残っている空き領域の割合。 この値がしきい値10％未満であることが判明した場合、API呼び出しがパネルに送信され、このディスクが増加します。 パネルは、このディスクを増やすことについて、このVMが動作しているマスターサーバーに対応するコマンドを送信します。 （また、パネルは、このイベントに関する連絡先メールに、必要なすべての詳細を記載したメールを送信します）。 ディスクを拡張するとき、ユーザーシステム内のudevはこのイベントをインターセプトし、FC（resize2fs）を拡張するプロセスを開始します。



すべてのASアクションは、仮想マシン内の/ var / log / syslogおよびパネルログに記録されます。



関税の自動スケーリング。



メモリまたはプロセッサを変更するには、別の関税への切り替えが適用されます。 json形式のAPIを介して受け取ることができる関税のラインがあります。



ご覧のとおり、近隣の関税への移行によって、パラメーターの1つ（cpu / memsize）が増加/減少しません。 たとえば、 「TINY」から「SMALL」に切り替えてもメモリ量は増加するだけで、CPUは追加されません。 CPUを「TINY」に増やすには、 「MEDIUM」に直接移動する必要があります。 これは、希望する関税を選択する際に考慮されます。



関税の自動スケーリング。 メモリ。



メモリ消費に関する情報は、 / proc / meminfoから取得されます。



パラメーター「MemTotal」、「MemFree」、「Buffers」、「Cached」、および「Shmem」に基づいて、現在使用されているメモリーの量がわかり、必要に応じて解放できません。



「使用済み」=「MemTotal」-「MemFree」-「バッファ」-「キャッシュ」+「Shmem」



「バッファ」は、小さなディスクブロックの一時ストレージに割り当てられるメモリです。 ディスクI / Oを高速化するために使用され、必要に応じてオペレーティングシステムによってこのメモリをすばやく解放できます（プロセスのいずれかが未使用メモリよりも多くのメモリを必要とする場合）。



「キャッシュ」 -ディスクから読み取られたファイルのキャッシュ。 このメモリもすぐに解放できます。



しかし、 「Shmem」もあります。これは、プロセス間通信（IPC）の最速の方法として使用される共有メモリです。 / proc / meminfoでは、 「Shmem」は「Cached」の一部ですが、プロセスのいずれかで使用されている間、メモリのこの部分はすぐに解放できません。



次に、空きメモリの割合と、オンデマンドで解放できるメモリの割合を次のように計算できます。

 ('MemTotal' - 'Used') * 100 / 'MemTotal'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または

 ('MemFree' + 'Buffers' + 'Cached' - 'Shmem') * 100 / 'MemTotal'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

より良い関税を変更する決定を下すために、毎分前にいくつかの測定を行い、そのたびに以前の測定の履歴を保持します。 過去5分間の空きメモリの平均値がしきい値20％未満である場合、ユーザーのVMは既に着実にクリティカルゾーンに移動していると考えられます。さらなる問題を回避するために、現在のメモリよりも多くのメモリがある次のタリフに料金を引き上げる時期です。 適切なAPI呼び出しを適用します。 関税はリブートせずにほぼ瞬時に変更され、システムはすぐに大幅にメモリを増やします。 ユーザーには、イベントに関する連絡先メールにメールが送信されます。



関税が変更されたときの統計収集履歴は、新しい条件での新しい測定への影響を避けるためにリセットされます。 したがって、新しい測定履歴が蓄積されるまで、次の料金変更は発生しません。



また、すべてのASアクションは/ var / log / syslogおよびパネルログに記録されます。



関税の自動スケーリング。 プロセッサー



CPU消費に関する統計は1分に1回収集され、最後の10分間の履歴が考慮されます。 CPUの統計は/ proc / statから取得されますが、メモリの場合よりも解釈がやや困難です。



実際には、リソースのより正確な割り当てのために、マスターサーバーのプロセッサの実際のコアではなく仮想マシンに配賦しますが、常にマスターサーバーの仮想マシン12コアに配賦し、cgroupsを使用して仮想マシンが消費できるコアの割合を制限します（ご存じのように、cgroupsは、プロセスまたはOSプロセスのグループのリソースの提供を制限できるLinuxカーネルテクノロジーです）。 したがって、MEDIUM料金でVMに4つのCPUコアを提供する場合、これは12の実際のコアが提供されることを意味し、cgroupsを使用するとCPU消費は1つのコアの400％に制限されます。 実際のカーネルを仮想マシンに発行し、複数のVMが1つのコアで実行されている場合、最終的にCPUコアのリソースを共有するため、このアプローチはリソースを提供する精度と柔軟性に利点があります。仮想マシンはまさに約束されたものです（ただし、マスターサーバーのプロセッサ負荷を監視し、多忙なマスターサーバー間で仮想マシンをタイムリーに移行する場合）。 また、整数のCPUコアを発行することはできませんが、たとえば、1つのコアの123％を発行します（これは使用しません）。



一方、このアプローチにはマイナス点があります。仮想マシンの所有者にとっての状況はそれほど明白ではありません。 / proc / cpuinfo 、 / proc / stat 、およびtop、htop、atopなどのすべてのユーティリティでは、12個のCPUコアが表示されます。 また、このようなユーティリティを使用して状況を正しく評価するには、これらの制限の本質をもう少し理解する必要があります（ただし、ユーザーの利便性のために、必要な情報はすべてコントロールパネルにわかりやすい形式で表示されます）。



さらに、この場合の12コアに関する情報は役に立ちません。 すべてのコアの情報を要約した最初の行で十分です。

 cpu 308468 0 155290 2087891920 139327 0 1717 323604 0 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、CPUの統計を計算するには、 / proc / statからの情報に加えて、このVMのcgroupを使用して実際に割り当てられているCPUコアの数に関する情報が必要です。 些細な方法で、VM自体の内部は認識できません。



したがって、仮想マシンに関する基本情報を提供する別のAPI呼び出しが使用されます。



スケールダウンできるようにするには、より低い関税に切り替えた場合にコアがいくつあるかを知る必要もあります。 この情報は、前述の料金表から取得されます。 パネルからの情報に対する同じリクエスト（このVMの関税とパラメーターに関する）でAPIを毎分プルしないように、この情報はキャッシュされます。 関税を変更する前に、キャッシュからの情報を関連性があると見なすことができます。 関税が変更された場合、システムが再起動した場合、または指定された時間（この場合は1日）より長く保存された場合、キャッシュはリセットされます。



/ proc / statには、システムの開始からの情報が単純な整数の時間カウンター（ほとんどのアーキテクチャでは100分の1秒）として格納されます。



そのため、過去10分間の統計を取得するだけでなく、特定の測定期間ごとに費やされたリソースの量を把握するために履歴を保存する必要があります（現在の値から前の期間の値を減算します。これらの値を「cur_user」、「cur_nice」と呼びます） 、「cur_system」など）。



したがって、 / proc / statからCPUリソースの合計量を計算できます（ 「total」と呼びましょう）。

 'total' = 'user' + 'nice' + 'system' + 'idle' + 'iowait' + 'irq' + 'softirq' + 'steal'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

現在の期間の合計CPUリソース（現在の測定の「合計」から前の測定から「合計」を減算して「cur_total」と呼びましょう）。 これは、12コアすべてのリソースです。 この場合、この仮想マシンに与えられた部分（ 'my_cur_total' ）は次と等しくなります：

 'my_cur_total' = 'cur_total' * ncpu / 12
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ncpuはVM情報（カーネルのcgroups-limit）から取得されます。



これで、このVMの現在の期間の実際の「アイドル」 （CPUアイドル時間）を計算できます（ 「my_cur_idle」と呼びましょう）。

 'my_cur_idle' = 'my_cur_total' - 'cur_user' - 'cur_nice' - 'cur_system' - 'cur_iowait' - 'cur_irq' - 'cur_softirq'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この値が/ proc / statからの「アイドル」とはほとんど関係がないことは明らかです。 そこで、この値は12コアすべてのアイドル時間を意味します。



'my_cur_idle' 、 'cur_iowait' 、 'cur_steal'などの値は、 'my_cur_total'の割合として表され、基本的にtop、atop、htopなどのユーティリティによって通常表示される値です。

それらは関税を切り替えるための基礎です。 つまり、現在の空きCPUの割合が計算され、測定履歴に記録されます。 過去10分間のこの割合の平均値がクリティカル10％を下回る場合、関税をより多くのCPUを備えた関税に切り替えます。 つまり、切り替えの理由は、過去10分間に仮想マシンで平均90％を超えるCPUが消費された状況です。



もちろん、測定期間としきい値は、たとえば、CPU全体を使い果たして数分以内に処理を完了する重いスクリプトを1回だけ起動することは、関税を切り替える正当な理由ではないという仮定から経験的に取られています。 ただし、これらのパラメーターはユーザーのフィードバックに従って調整できます（ASスクリプトと設定は、新しいバージョンがリリースされると仮想マシンで自動的に更新されます）。



自動スケーリング率を下げます。



より少ないメモリまたはより少ないCPUで以前の料金を引き下げ、システムに地獄を作らないようにするには、前の料金で現在の負荷がプロセッサとメモリの両方の利用可能なリソースに完全に収まるようにする必要があります。同時に、切り替え後すぐに低関税の状況が重大にならないように、いくらかのマージンが残ります。 これから、まず、最も近い関税のみに一度に切り替えることができます（2つの関税を切り替えることができる場合、これは2つのステップで行われます）。 そして、第二に、これは、前の料金表のパラメータに基づいて、メモリとプロセッサに対して上記のすべての計算を行う必要があることを意味します（メモリとCPUが提供される量）。 したがって、これらのパラメータは料金表から取得されます。 そして、システムの負荷の基準を取得するための上記のすべての推論は、以前の料金のこれらのパラメーターを考慮に入れて同時に実行されます。 また、履歴を保存します。 つまり、結果として、現在の負荷で特定の仮想マシンが以前の料金であった場合に計算される値を同時に取得します。



ただし、関税の絶え間ない切り替えを排除するために、切り替えのしきい値は切り替えのしきい値とわずかに異なります。

したがって、より低い関税で切り替えるには、切り替え後、使用されていないCPU（アイドル）の少なくとも20％と空きメモリ（または解放可能なメモリ-バッファとディスクキャッシュ）の少なくとも30％が必要です。 また、切り替えの理由は、1回限りの測定ではなく、最後の10回の測定の平均結果です。



PS。 すでにクライアントである場合は、コントロールパネル-bit.ly/Panel-NetAngelsで自動スケーリングに接続できます。

ここに新しいアカウントを登録するには