ドキュメント
Amazon EC2: 既存のルートボリュームのサイズを拡大する方法
注意:
- 2019年以降、根本量の大きさを上げたい場合は、推奨パスです。 初期のスナップショットをサーバーを停止するのがベストプラクティスです。しかし、厳密には必要としないと話します。
- もしくは、お見合いください。 旧文書 データを新しいインスタンスに移行する(より大きいボリュームを持つ)。 それでも関連性があるはずです。
- このページはEBS が AWS EC2 インスタンスをバックアップするだけに関連しています。インスタンスが "インスタンスストレージ"* の場合、代わりに考慮することをお勧めします。 ファイルをインスタンスストレージに移行する.
* - "Instance storage" は、古い AWS インスタンスサイズでのみ利用可能です。 TurnKey および/または古い AWS インスタンスサイズの古いバージョン。 v14.2+ TurnKeyサーバをお持ちの方は、EBS がバックアップされているのはほぼ確実です。 v13.0 が返される EBS が、AWS コンソール内でのダブルチェックが確実に行われるか、 または に投稿してください。 フォーラム TurnKeyバージョンとAWSインスタンスサイズ/タイプを固定します。
問題: ルートファイルシステムがスペースから実行されている
問題を説明する例を示します。Alon は TurnKey Hub 経由でマイクロサーバを起動します。 数ヶ月後に、Alonは10GBのルートファイルシステム上のスペースがほぼ実行されていることを通知します。
# df -h Filesystem Size Used Avail Use% Mounted on udev 486M 0 486M 0% /dev tmpfs 100M 4.1M 96M 5% /run /dev/xvda2 9.8G 9.8G 19M 100% / tmpfs 498M 0 498M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 498M 0 498M 0% /sys/fs/cgroup
問題は、サーバーのルートファイルシステムに10GBしか存在しないということです。
そのため、アロンはストレージサイズを増加させる方法は?
AWS Console でルートボリュームサイズを増加
所要時間:40分～1時間
これらの命令は、サーバーがサーバーが実行されていることを仮定します 名称: TurnKey Hub, しかし、彼らはまた、使用を必要としています AWSコンソール. ハブ(またはその問題のTurnKey)を使用しない場合、一般的に関連性が求められるが、相談したいと思われる AWS ドキュメント AWS Console に厳密に関連した詳細を詳細に使用します。
サーバのダウンタイムを少々余裕が取れる限り、これを解決する最善の方法は、AWSコンソールでルートボリュームを拡大することです。 ダウンタイムが余裕がないなら、これはライブをすることができますが、ダウンタイムの数分がマインドの部分の価値があると私は主張します。
準備が整う
最初に行うことは、バックアップを作成することです。この場合はTKLBAMを使うことができますが、この場合は「スナップショット」を撮ることをお勧めします(よく?)。 スペースに非常に短い場合は、TKLBAM はオプションではないかもしれません。 スナップショットは、あなたが今より速く、より少ない手間で、あなたがすぐにどこにいるかを正確に戻すことを可能にします(新しいサーバーを始める必要はありません)。
バックアップの目的で、サーバーの実行中のスナップショットを撮ることができるのは、Amazon は、停止サーバーのスナップショットを撮ることをお勧めします。 実行中のサーバーのスナップショットを撮るときにデータ破損の(非常にスリム)チャンスがあるので、これはです。 そのため、ダウンタイムの数分が問題になる(そしてそれも)、そのアドバイスに従うためのブレンダーは全くないようです。
サーバを停止している場合、ハブのハブから サーバーページ, サーバを選択して、完全な情報がロールダウンして、停止をクリックします。
スナップショットを撮る準備ができたら、ハブサーバーページではまだ「xスナップショット」というテキストリンクを探します('x'は既に撮影したスナップショットの数です)。 前に取らなければ「0」になります。 開いたページと、クリックして「スナップショットを作成」ボタンを押します。 当初は「0%」を表示し、分か2分かかります。 進行が見つからない場合は、ページをさっぱりとさっぱりとしてください。完了したら、緑の円が見えるはずです。
AWSコンソールでTurnKeyサーバーを探す
Hub の Servers ページの (必要に応じてサーバー情報をもう一度読みます) に戻り、地域と注意を言う場所を探します。 今度は、新しいブラウザタブ/ウィンドウでAmazon ConsoleをAmazonコンソールに開き、 EC2 - インスタンスページ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AWSコンソールでは、トップバーの右上(ユーザー名を表示している間、サポート)の右上にある「AWSコンソール」でドロップダウンをクリックして、この領域がその領域にマッチすることを確認します。 Hub サーバが (もし既にある場合は、そのステップをスキップ) になっている。
サーバ/インスタンスを一回だけ停止している場合(または、どのサーバで動作するかを正確に確認する)、次のステップをスキップできます。 ですが、2つ以上のインスタンスがある場合、正しいインスタンスで動作していることを確認するには、「検索」をすることをお勧めします。
これを行うには、ハブのサーバーページに戻り、EC2インスタンスIDをコピーします(私の場合は「i-0c04e369a3d987199」です)。 リストバーにAWSコンソールタブ/ページ上部に貼り付けます(デフォルトでは、検索バーには「タグと属性によるフィルタやキーワードで検索」というテキストが含まれます)。 サーバ/インスタンスIDを貼り付け、入力を押します。
ボリュームサイズを増加させる
たった1つのインスタンスが、AWS Console に表示されている状態に残ります。 結果が取得しない場合は、正しい領域を選択し、正しいAWSアカウントに署名されていることを二重にチェックします(複数のアカウントを使用する場合)。 サーバの詳細は下ペインで有効である必要があります。この画面をスクロールして「ルートデバイス」を見ると、/dev/xvda が表示される可能性があります。
デバイス(例:/dev/xvda)と小さな黒いポップアップは、EBSのボリュームに関するいくつかの情報が表示されます。 EBS ID ( "vol-02110c92a873ad915") をクリックし、AWS Console - Volumes ページにリダイレクトされ、必要なボリュームのみが表示されます。
ボリュームを右クリックし、「ボリュームを修正」を選択します。 ポップアップが開くはずです。 「サイズ」と表示されている場所を探します。 鉱山は現在「10」です。 必要なボリュームサイズ(GB)にその番号を増やします。 私は20GBを鉱山にしようとしています。 次に、「修正」ボタンをクリックしてください。 次の画面で「はい」をクリックします。 「ボリュームリクエストを成功させる」というグリーンメッセージで挨拶をする必要があります。 ほぼ瞬時に起こるはずですが、AWSコンソールをリフレッシュして、目的のサイズ(例:私の場合20 GiB)でボリューム表示を確認する必要があります。 いない場合は、もう一度さっぱりとお試しください。
Hub に戻る: サーバを再起動 (停止した場合) より大きいボリュームを確認します。
つまり、AWSコンソールが必要だからログアウトしてシャットすることができます。サーバーを停止すると、Hubのサーバーページに戻ります。 サーバ上で「スタート」をクリックして、命に戻りましょう。通常どおり、しばらくお待ちください。 ほとんどのサーバーでは、これは数分間しかかかりません(5 ほとんどの)。
サーバが実行されると(または停止しなかった場合は、直進)、SSH経由でログオンします。 dfコマンドを再度実行したい場合は、何も変更されていないことに気づくでしょう。 つまり、ボリュームサイズが増加しただけなので。 必要に応じて、ボリュームが確かに大きく、gdiskで確認することができます。
# gdisk -l /dev/xvda GPT fdisk (gdisk) version 1.0.1 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/xvda: 41943040 sectors, 20.0 GiB Logical sector size: 512 bytes Disk identifier (GUID): 8A333A04-DB02-4249-870C-EC5665D405BF Partition table holds up to 128 entries First usable sector is 34, last usable sector is 20971486 Partitions will be aligned on 2048-sector boundaries Total free space is 4029 sectors (2.0 MiB) Number Start (sector) End (sector) Size Code Name 1 2048 6143 2.0 MiB EF02 grub 2 6144 20969471 10.0 GiB 8300 rootfs
「Disk /dev/xvda: 41943040」の20.0 GiBの2つのセクターに注意して下さい。
仕切りテーブルを固定し、仕切りをサイズ変更して下さい
次にパーティションテーブル(GPT)を固定し、パーティションを拡張して新しい空きスペースを使用する必要があります。 ファイル拡張子が、ファイルシステム(GPTを修正)であるために、parted(v15.xサーバーのデフォルトでインストールする必要があります)を使用します。 'parted"コマンドで起動します。
# parted GNU Parted 3.2 Using /dev/xvda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted)
まず、'print' コマンドを使用して、既存の情報(再び)をダブルチェックします。 これにより、すべてのスペースが使用されることの警告が現れ、それを修正するオプションが現れます。
(parted) print
Warning: Not all of the space available to /dev/xvda appears to be used, you can fix the GPT to use all of the
space (an extra 20971520 blocks) or continue with the current setting?
Fix/Ignore?
修正を('f' を入力して入力して入力)できるようにします。 以前実行した df チェックに類似した情報を表示するようになりました。 ギギギギュバイト(1バイト×1000×1000)をGigiBytes(1バイト×1024×1024)と反対すると表示されているので、数字が一致しない場合はアラームが鳴らされないことに注意してください。 ケースでは、21.5GB(20GiB)を表示しています。
Fix/Ignore? f Model: Xen Virtual Block Device (xvd) Disk /dev/xvda: 21.5GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 3146kB 2097kB grub bios_grub 2 3146kB 10.7GB 10.7GB ext4 rootfs (parted)
パーティションのサイズを変更するには、'resizepart' コマンドを使用します。 デフォルト設定では、パーティション2をリサイズしたいが、出力を2倍にチェックして、マッチするかどうかを確認します。 使用するパーティションを変更することに対する警告を無視しました。また、すべての空き領域(つまりディスクの最終サイズに行きました:21.5GB)を使用していたことに注意
(parted) resizepart Partition number? 2 Warning: Partition /dev/xvda2 is being used. Are you sure you want to continue? Yes/No? y End? [10.7GB]? 21.5GB (parted)
'print' で期待どおりに機能したのは、ダブルチェックです。何かが正しく見えない場合は、再度「resizepart」コマンドを実行できます。しかし、鉱山はうまく見えます。
(parted) print Model: Xen Virtual Block Device (xvd) Disk /dev/xvda: 21.5GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 3146kB 2097kB grub bios_grub 2 3146kB 21.5GB 21.5GB ext4 rootfs (parted)
ほぼ完了; ファイル拡張子ファイルシステムと終了
それでも、partedを終了してdfの出力を再度チェックすると、追加の新しいスペースがまだ見られない。 つまり、最終ステップは、パーティションを埋めるためにファイルシステムを拡張することです。 一部バージョンのPartedも、(IIRC コマンドは'resizefs') であるが、その能力がなかったので、Parted から出ている('quit')。 /etc/fstabについての情報を安全に無視できます
(parted) quit Information: You may need to update /etc/fstab.
それからパーティションの 'resize2fs' を実行します。
# resize2fs /dev/xvda2
df を今チェックすると、空き容量が利用可能になったことが表示されます。
# df -h Filesystem Size Used Avail Use% Mounted on udev 486M 0 486M 0% /dev tmpfs 100M 4.1M 96M 5% /run /dev/xvda2 20G 9.8G 10.2G 48% / tmpfs 498M 0 498M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 498M 0 498M 0% /sys/fs/cgroup
YAY! 完了! :)
最終クリーンアップ
個人的には、スナップショットを外す前に、数日で解決するのが好きです。 つまり、何かがかなり正しいとは言えないでしょうが、すぐに表示されません。 とはいえ、以前は必要としないんです。それでも、AWSをもう少し心に与えてくれました。 自信があると感じたら、必要に応じてスナップショットを削除できます。スナップショットを最初の部分と作成、削除の代わりに見つけてください。