Skip to main content

ストレージ容量の増加

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

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

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

要件と推奨事項

Note

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

ユーザー ライセンスx86-64 vCPUsメモリルート ストレージアタッチされた (データ) ストレージ
トライアル、デモ、あるいは10人の軽量ユーザ432 GB200 GB150 GB
10-3000848 GB200 GB300 GB
3000-50001264 GB200 GB500 GB
5000-80001696 GB200 GB750 GB
8000-10000+20160 GB200 GB1000 GB

ルート ストレージとは、インスタンスのルート ディスクの合計サイズを指します。 ルート ファイルシステムで利用可能な領域は、ルート ディスクで利用可能なストレージの合計の 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. 大きなルートディスクを持つ新しいアプライアンスにデータディスクをアタッチします。

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

Warning

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

  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 mkfs.ext4 -L fallback /dev/xvdg2
    
  7. アプライアンスをシャットダウンします。

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

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

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

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