Enterprise Server 3.15 は、現在リリース候補として使用できます。

ストレージ容量の増加

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

この記事の内容

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

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

要件と推奨事項

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

ユーザー ライセンス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. システム サービスが正しく機能していることを確認してから、メンテナンス モードを終了します。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。

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

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

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

    sudo poweroff

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

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

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

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

  1. GitHub Enterprise Server アプライアンスに新しいディスクを取り付けます。

  2. 新しいディスクのデバイス名を確認するには、lsblk コマンドを実行します。

  3. ディスクをフォーマットするには、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%

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

    ghe-repl-stop

  5. 新しくパーティション分割されたディスクに 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

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

    sudo poweroff

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

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

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

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