私たちを悩ませる問題の1つは、仕事の抽象的な（内部）側面に多くの時間を費やすことです。 過去数ヶ月にわたり、私たちは集中的に取り組んできましたが、顧客は結果をほとんど見ていません。 クラウドの内部コンポーネントに対応し、高負荷（1秒あたり数千の操作）に対応しました。

最後に、シンプルなものを手に入れました-ディスク（システムを含む）のサイズを増やす機能をインターフェイスに実装しました。

実際の作業は、ソケットで2時間、すべてが期待どおりに機能していることを確認するためにさらに数時間です。 しかし-十分な時間と手がありませんでした。 最後に、完了した時間を見つけました。

どうやってやるの？

ディスクをロックしないでください。つまり、仮想マシンから切断するか、仮想マシン自体をオフにする必要があります。 （クラウドコントロールパネルに[ズームイン]ボタンがない場合-ページを更新する-キャッシュされたJS）。

ディスクのサイズを変更するオプションは、マップされたドライブの「ディスク」セクションと、マウントされていないドライブの「マウントされていないドライブ」セクションにあります。 ディスクサイズはメガバイト単位で設定されます。 ディスクサイズの制限は1.7 TBで、マシンに接続できるディスクの合計数は15個です。

重要：ディスクはブロックデバイスとして成長します。クライアントファイルシステムにアクセスできず、パーティションのサイズを変更しません。

ディスクサイズを増やした後、次のことを行う必要があります。

パーティションテーブルの場合：

• パーティションテーブルのサイズを変更します。 たとえば、助けを借りて。 cfdisk。 システムパーティションのサイズを変更した場合は、再起動する必要があります。 さらに、スワップパーティションを削除して再作成する必要がある場合があります。
• resize2fsをデバイス名にします（例：resize2fs / dev / sda1）

lvmの場合：

• pvresize to PV（パーティションテーブルの上でLVMを使用する場合、パーティションテーブルのサイズを変更します）
• サイズ変更
• resize2fs

減って？

ああ、いや。 主な理由はいくつかあります。それは危険です。 これは非常に危険です。 あなたがディスクをカットした場合-その後、最後から。 さらに、ファイルシステムを見ることなく。 データを厳しく失う可能性があります（blktapの特性により、カットされたピースのデータは永久に失われます）。

2つ目-ファイルシステムのサイズを小さくすることは、気の弱い人（特にルートファイルシステム）の作業ではありません。さらに、ディスクに大きな負荷がかかります（コストがかかるため、ディスクの完全なコピーを2〜3作成する方が安くなります）。

フラグメンテーション？

発生しますが、私たちが使用しているLVMのPEのサイズのため、非常に重要ではありません-最小の断片の長さは4MBです。 さらに、ストレージの観点から見ると、異なるストレージロケーションへの競争力のあるリクエストがまだあるため、パフォーマンスに違いはないはずです。

お金？

デバイス自体のサイズを変更する操作は非常に簡単で、費用はかかりません。 新しいドライブは新しいサイズを考慮し始めます。 Tb *時間（実際の解像度は秒単位）の場所を考慮するため、実際には、ディスクスペースの「消費」は単に「増加」します。つまり、アカウンティングの観点からは、実際には何も変わりません。