ストレージ容量の増加

新しいシステムリソースを割り当てるプロセスは、仮想化プラットフォームとリソースの種類によって異なります。重要なシステムリソースのモニタリングとアラートは、必ず設定しておいてください。詳しくは、「インスタンスを監視する」を参照してください。

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

要件と推奨事項

Note

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

最小推奨要件

ユーザーライセンス	x86-64 vCPUs	メモリ	ルートストレージ	アタッチされた (データ) ストレージ
トライアル、デモ、あるいは10人の軽量ユーザ	4	32 GB	200 GB	150 GB
10-3000	8	48 GB	200 GB	300 GB
3000-5000	12	64 GB	200 GB	500 GB
5000-8000	16	96 GB	200 GB	750 GB
8000-10000+	20	160 GB	200 GB	1000 GB

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

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

仮想化プラットフォームのツールを使用して、既存のユーザーボリュームのディスクのサイズを変更します。
お使いの GitHub Enterprise Server インスタンスに SSH で接続します。インスタンスが複数のノードで構成されている場合は (高可用性や geo レプリケーションが構成されている場合など)、プライマリノードに SSH 接続します。クラスターを使用する場合は、任意のノードに SSH 接続できます。 HOSTNAME をインスタンスのホスト名、またはノードのホスト名または IP アドレスに置き換えます。詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。
Shell
```
ssh -p 122 admin@HOSTNAME
```
```
ssh -p 122 admin@HOSTNAME
```
アプライアンスをメンテナンスモードにしてください。詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。
アプライアンスを再起動して、新しいストレージ割り当てを検出します。
```
sudo reboot
```
ghe-storage-extend コマンドを実行して、/data/user ファイルシステムを拡張します。
```
ghe-storage-extend
```
システムサービスが正しく機能していることを確認してから、メンテナンスモードを終了します。詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。

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

現在のアプライアンスと同じバージョンを使用して、より大きなルートディスクで新たな GitHub Enterprise Server をセットアップします。詳しくは、「GitHub Enterprise Server インスタンスをセットアップする」を参照してください。
現在のアプライアンスをシャットダウンします。
```
sudo poweroff
```
使用している仮想化プラットフォームのツールを使い、現在のアプライアンスからデータディスクをデタッチします。
大きなルートディスクを持つ新しいアプライアンスにデータディスクをアタッチします。

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

Warning

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

GitHub Enterprise Server アプライアンスに新しいディスクを取り付けます。
新しいディスクのデバイス名を確認するには、lsblk コマンドを実行します。
ディスクをフォーマットするには、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%
```
アプライアンスが高可用性または geo レプリケーション用に構成されている場合、レプリケーションを停止するには、各レプリカノード上で ghe-repl-stop コマンドを実行します。
```
ghe-repl-stop
```
新しくパーティション分割されたディスクに 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
```
アプライアンスをシャットダウンします。
```
sudo poweroff
```
ハイパーバイザーで、古いルートディスクを取り外し、古いルートディスクと同じ場所に新しいルートディスクを取り付けます。
アプライアンスを起動します。
システムサービスが正しく機能していることを確認してから、メンテナンスモードを終了します。詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。

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