ストレージ容量の増加

Gitリポジトリ、データベース、検索インデックス、その他の恒久的なアプリケーションデータに利用できるストレージの量は、追加あるいは変更できます。

この記事で

データ 再利用可能.エンタープライズ_インストール.物理リソースのアップグレードに関する警告 %}

お使いの GitHub Enterprise Server インスタンス に参加するユーザーが増えるにつれて、ストレージ ボリュームのサイズを変更する必要があるかもしれません。 ストレージのリサイズに関する情報については、使用している仮想化プラットフォームのドキュメンテーションを参照してください。

要件と推奨事項

メモ

ストレージ ボリュームのサイズを変更するには、インスタンスをメンテナンス モードにします。 変更点を確認するには、指定されたIP アドレスからのアクセスを許可するように IP 例外リストを構成します。 詳しくは、「メンテナンスモードの有効化とスケジューリング」をご覧ください。

警告

Azure ディスクのディスク キャッシュ設定を変更すると、ターゲット ディスクがデタッチされて再アタッチされます。 ディスクが使用中の場合、実行中のサービスが中断され、データが破損する可能性があります。 ストレージ容量を増やしながらディスク キャッシュ設定を変更する場合は、アプライアンスを必ずシャットダウンしてください。

ユーザー ライセンスx86-64 vCPUsメモリルート ストレージアタッチされた (データ) ストレージIOPS
トライアル、デモ、あるいは10人の軽量ユーザ432 GB400 GB500 GB600
最大 1,000848 GB400 GB500 GB3000
1,000 から 3,0001664 GB400 GB1000 GB6000
3,000 から 5,00032128 GB400 GB1500 GB9000
5,000 から 8,00048256 GB400 GB3000 GB12000
8000-10000+64512 GB400 GB5000 GB15000

ルート ストレージとは、インスタンスのルート ディスクの合計サイズを指します。 ルート ファイルシステムで利用可能な領域は、ルート ディスクで利用可能なストレージの合計の 50% です。 詳しくは、「システムの概要」をご覧ください。

データパーティションサイズの増加

  1. 仮想化プラットフォームのツールを使用して、既存のユーザーボリュームのディスクのサイズを変更します。

  2. お使いの GitHub Enterprise Server インスタンス に SSH で接続します。 インスタンスが複数のノードで構成されている場合は (高可用性や geo レプリケーションが構成されている場合など)、プライマリ ノードに SSH 接続します。 クラスターを使用する場合は、任意のノードに SSH 接続できます。 HOSTNAME をインスタンスのホスト名、またはノードのホスト名または IP アドレスに置き換えます。 詳しくは、「管理シェル (SSH) にアクセスする」をご覧ください。

    Shell
    ssh -p 122 admin@HOSTNAME

  3. アプライアンスをメンテナンスモードにしてください。 詳しくは、「メンテナンスモードの有効化とスケジューリング」をご覧ください。

  4. アプライアンスを再起動して、新しいストレージ割り当てを検出します。

    sudo reboot

  5.        `ghe-storage-extend` コマンドを実行して、`/data/user` ファイル システムを拡張します。

    ghe-storage-extend

  6. システム サービスが正しく機能していることを確認してから、メンテナンス モードを終了します。 詳しくは、「メンテナンスモードの有効化とスケジューリング」をご覧ください。

警告

          `ghe-storage-extend` コマンド (または以前の自動チェック) で`ghe_user_data contains a file system with errors`報告された場合は、サイズ変更を再試行する前にファイルシステムを修復する必要があります。 チェックが正常に完了するまで、 `ghe-storage-extend` を再実行しないでください。 回復手順については、 [ファイルシステムエラーの修復を](#repairing-filesystem-errors)参照してください。

ファイルシステム エラーの修復

          `ghe-storage-extend`中にファイルシステムのチェックが失敗した場合は、次の手順に従って修復します。

アプライアンスがメンテナンス モードであり、バックグラウンド ジョブが実行されていないことを確認します。

Shell
ghe-maintenance -s
ghe-resque-info

  1. ユーザー ボリュームを停止してアクティブ化してから、強制ファイルシステム チェックを実行します (自動応答はい)。

    Shell
    sudo systemctl stop ghe-user-disk
VGNAME=$(sudo lvs --noheadings -o vg_name | grep ghe_storage_ | awk '{ print $1 }')
sudo vgchange -ay "$VGNAME"
sudo vgscan --mknodes
sudo fsck -fy /dev/mapper/${VGNAME}-ghe_user_data

  2. サイズ変更を再試行します。

    Shell
    ghe-storage-extend

  3. 新しいサイズを再マウントして確認します。

    Shell
    sudo systemctl start ghe-user-disk
df -h /data/user

  4. 再起動して確認します。

    Shell
    sudo reboot
df -h /data/user

新しいアプライアンスを使用したルートパーティションサイズの増加

  1. 現在のアプライアンスと同じバージョンを使用して、より大きなルートディスクで新たな GitHub Enterprise Server をセットアップします。 詳しくは、「GitHub Enterprise Server インスタンスの設定」をご覧ください。

  2. 現在のアプライアンスをシャットダウンします。

    sudo poweroff

  3. 使用している仮想化プラットフォームのツールを使い、現在のアプライアンスからデータディスクをデタッチします。

  4. 大きなルートディスクを持つ新しいアプライアンスにデータディスクをアタッチします。

既存のアプライアンスを使用したルートパーティションサイズの増加

警告

ルート パーティション サイズを拡張するには、インスタンスをメンテナンス モードにする必要があります。 詳しくは、「メンテナンスモードの有効化とスケジューリング」をご覧ください。

ルート パーティションのサイズを変更する前に、アプライアンスに GUID パーティション テーブルがあるかどうかを確認します。

GHES リリース 3.14 以降で作成されたインスタンスでは、「GUID パーティション テーブルのルート パーティション サイズを増やす」の手順に従います。

3.14 より前の GHES リリースから作成されたインスタンスでは、「レガシ パーティション テーブルのルート パーティション サイズを増やす」の手順に従います。

パーティション テーブルの種類を確認するには、次のコマンドを実行します。 結果は gpt または msdos である必要があります。

sudo lsblk -no pttype $(findmnt -no source /)
  1. GitHub Enterprise Server アプライアンスに新しいディスクを取り付けます。
  2. 新しいディスクのデバイス名を確認するには、lsblk コマンドを実行します。

GUID パーティション テーブルのルート パーティション サイズを増やす

  1. 既存の EFI ブート パーティションをバックアップします:

    sudo dd if=/dev/disk/by-label/EFIBOOT of=EFIBOOT.bak bs=1M

  2. ディスクをフォーマットするには、parted コマンドを実行します。/dev/xvdg を自分のデバイス名に置き換えます。

    sudo parted /dev/xvdg mklabel gpt
sudo parted -a optimal /dev/xvdg mkpart bios fat32 1MiB 2MiB
sudo parted /dev/xvdg set 1 bios_grub on
sudo parted -a optimal /dev/xvdg mkpart efi fat32 2MiB 512MiB
sudo parted /dev/xvdg set 2 esp on
sudo parted -a optimal /dev/xvdg mkpart primary 512MiB 50%
sudo parted /dev/xvdg set 3 boot off
sudo parted /dev/xvdg set 3 esp off
sudo parted -a optimal /dev/xvdg mkpart primary 50% 100%

  3. アプライアンスが高可用性または geo レプリケーション用に構成されている場合、レプリケーションを停止するには、各レプリカ ノード上で ghe-repl-stop コマンドを実行します。

    ghe-repl-stop

  4. 新しくパーティション分割されたディスクに GitHub Enterprise Server ソフトウェアをインストールするには、ghe-upgrade コマンドを実行します。 PACKAGE-NAME.pkg は、アプライアンスで既に実行されている GitHub Enterprise Server のバージョンと一致するプラットフォーム固有のアップグレード パッケージへのパスに置き換える必要があります。 github-enterprise-2.11.9.hpkg などのユニバーサル ホットパッチ アップグレード パッケージを使用することはできません。 ghe-upgrade コマンドが完了すると、アプリケーション サービスは自動的に終了します。

    ghe-upgrade PACKAGE-NAME.pkg -s -t /dev/xvdg3

  5. 新しく追加されたディスクのセカンダリ パーティション上で次のコマンドを実行します:

    sudo dd if=/dev/disk/by-label/EFIBOOT of=/dev/xvdg2 bs=1M
sudo mkfs.ext4 -L fallback /dev/xvdg4

  6. アプライアンスをシャットダウンします。

    sudo poweroff

  7. ハイパーバイザーで、古いルートディスクを取り外し、古いルートディスクと同じ場所に新しいルートディスクを取り付けます。

  8. アプライアンスを起動します。

  9. システム サービスが正しく機能していることを確認してから、メンテナンス モードを終了します。 詳しくは、「メンテナンスモードの有効化とスケジューリング」をご覧ください。

アプライアンスが高可用性または geo レプリケーション用に構成されている場合は、すべてのノードのストレージがアップグレードされた後で、ghe-repl-start を使用して各レプリカ ノードでレプリケーションを開始してください。

レガシ パーティション テーブルのルート パーティション サイズを増やす

  1. ディスクをフォーマットするには、parted コマンドを実行します。/dev/xvdg を自分のデバイス名に置き換えます。

    sudo parted /dev/xvdg mklabel msdos
sudo parted /dev/xvdg mkpart primary ext4 0% 50%
sudo parted /dev/xvdg mkpart primary ext4 50% 100%

  2. アプライアンスが高可用性または geo レプリケーション用に構成されている場合、レプリケーションを停止するには、各レプリカ ノード上で ghe-repl-stop コマンドを実行します。

    ghe-repl-stop

  3. 新しくパーティション分割されたディスクに GitHub Enterprise Server ソフトウェアをインストールするには、ghe-upgrade コマンドを実行します。 PACKAGE-NAME.pkg は、アプライアンスで既に実行されている GitHub Enterprise Server のバージョンと一致するプラットフォーム固有のアップグレード パッケージへのパスに置き換える必要があります。 github-enterprise-2.11.9.hpkg などのユニバーサル ホットパッチ アップグレード パッケージを使用することはできません。 ghe-upgrade コマンドが完了すると、アプリケーション サービスは自動的に終了します。

    ghe-upgrade PACKAGE-NAME.pkg -s -t /dev/xvdg1

  4. 新しく追加されたディスクのセカンダリ パーティション上でコマンドを実行します:

    sudo mkfs.ext4 -L fallback /dev/xvdg2

  5. アプライアンスをシャットダウンします。

    sudo poweroff

  6. ハイパーバイザーで、古いルートディスクを取り外し、古いルートディスクと同じ場所に新しいルートディスクを取り付けます。

  7. アプライアンスを起動します。

  8. システム サービスが正しく機能していることを確認してから、メンテナンス モードを終了します。 詳しくは、「メンテナンスモードの有効化とスケジューリング」をご覧ください。

アプライアンスが高可用性または geo レプリケーション用に構成されている場合は、すべてのノードのストレージがアップグレードされた後で、ghe-repl-start を使用して各レプリカ ノードでレプリケーションを開始してください。