ストレージ容量の増加

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

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

要件と推奨事項

Note

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

最小推奨要件

ユーザーライセンス	x86-64 vCPUs	メモリ	ルートストレージ	アタッチされた (データ) ストレージ	IOPS
トライアル、デモ、あるいは10人の軽量ユーザ	4	32 GB	400 GB	500 GB	600
最大 1,000	8	48 GB	400 GB	500 GB	3000
1,000 から 3,000	16	64 GB	400 GB	1000 GB	6000
3,000 から 5,000	32	128 GB	400 GB	1500 GB	9000
5,000 から 8,000	48	256 GB	400 GB	3000 GB	12000
8000-10000+	64	512 GB	400 GB	5000 GB	15000

ルートストレージとは、インスタンスのルートディスクの合計サイズを指します。ルートファイルシステムで利用可能な領域は、ルートディスクで利用可能なストレージの合計の 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 mkfs.ext4 -L fallback /dev/xvdg2
```
アプライアンスをシャットダウンします。
```
sudo poweroff
```
ハイパーバイザーで、古いルートディスクを取り外し、古いルートディスクと同じ場所に新しいルートディスクを取り付けます。
アプライアンスを起動します。
システムサービスが正しく機能していることを確認してから、メンテナンスモードを終了します。詳しくは、「メンテナンスモードの有効化とスケジューリング」をご覧ください。

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