このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となりました: 2024-03-26. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise サーバーにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください。

CPUあるいはメモリリソースの増加

お使いの GitHub Enterprise Server インスタンス を実行する仮想マシン (VM) の CPU またはメモリ リソースを増やすことができます。

この記事の内容

CPU またはメモリ リソースの増加について

VM の CPU またはメモリ リソースを増やすことで、お使いの GitHub Enterprise Server インスタンス その他のリソース集中型ワークロードに対応できます。

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

インスタンスをサイズ変更すれば、いつでも CPU やメモリをスケールアップできます。 インスタンスで使用できるリソースを変更するには、ユーザーのダウンタイムが必要であるため、GitHub では、スケーリングを考慮してリソースを過剰プロビジョニングすることをおすすめします。

AWS での CPU またはメモリ リソースの追加

AWS 上のインスタンスの CPU またはメモリ リソースを追加するには、インスタンスの種類を変更する必要があります。 会社の AWS インフラストラクチャにアクセスできる必要があり、AWS 管理コンソールまたは aws ec2 コマンド ライン インターフェイスを使用して EC2 インスタンスを管理する方法について理解している必要があります。 詳細については、AWS のドキュメントの「インスタンスの種類の変更」を参照してください。

サイズ変更に関する考慮事項をレビューしたり、サポートされているインスタンスの種類を確認したり、AWS でインスタンスのサイズを変更する方法を確認したりできます。

AWS のサイズ変更に関する考慮事項

お使いの GitHub Enterprise Server インスタンス で CPU またはメモリ リソースを増やす前に、次の推奨事項を確認してください。

  • CPU でメモリをスケールアップまたはスケールダウンします。 CPU リソースを増やす場合、GitHub は、インスタンスにプロビジョニングする各 vCPU ごとに少なくとも6.5GBのメモリを追加する（最大16vCPUまで）ことをおすすめします。 16以上のvCPUを使う場合は、各vCPUごとに6.5GBのメモリを追加する必要はありませんが、インスタンスが十分なメモリを持っているかをモニターするべきです。
  • インスタンスにエラスティック IP アドレスを割り当てます。 Elastic IP が割り当てられていない場合は、パブリック IP アドレスでの変更を考慮して、再起動後に GitHub Enterprise Server ホストの DNS A レコードを調整する必要があります。 インスタンスがVPC内で起動していれば、インスタンスが再起動してもElastic IP（EIP）は自動的に保持されます。 インスタンスがEC2-Classic内で起動されていれば、Elastic IPは手動で際割り当てが必要です。

AWS でサポートされているインスタンスの種類

アップグレードするインスタンスタイプは、CPU とメモリの仕様に基づいて決定しなければなりません。

GitHubは、GitHub Enterprise Serverにメモリ最適化されたインスタンスをおすすめします。 詳細については、Amazon EC2 Web サイトの「Amazon EC2 Instance Types (Amazon EC2 インスタンス タイプ)」を参照してください。

AWS でのインスタンスのサイズ変更

AWS 上の GitHub Enterprise Server インスタンスで使用できるリソースを増やすには、インスタンスをシャットダウンし、インスタンスの種類を変更してから、インスタンスを再起動する必要があります。

  1. EC2-Classic でインスタンスが実行された場合は、そのインスタンスに関連付けられている Elastic IP アドレスと、そのインスタンスの ID の両方を書き留めておいてください。

  2. 今後のダウンタイムをユーザーに伝え、メンテナンス モードを有効にします。 詳細については、次の記事を参照してください。

  3. このインスタンスを停止するには、SSH 接続でインスタンスにログインして次のコマンドを実行します。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。

    sudo poweroff

  4. AWS で、インスタンスの種類を変更します。

  5. インスタンスを起動します。

  6. インスタンスが EC2-Classic で実行されている場合は、インスタンスを再起動した後、Elastic IP アドレスをもう一度関連付けます。

  7. インスタンスが完全に再起動し、アクセスできるようになったら、新しいリソース構成が認識されていることを確認してください。 SSH 接続でインスタンスにログインして次のコマンドを実行します。

    ghe-system-info

  8. 必要に応じて変更点を確認するには、指定されたIP アドレスからのアクセスを許可するように IP 例外リストを構成します。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。

  9. ユーザー メッセージを設定した場合は、メッセージを削除します。

  10. メンテナンス モードを無効にします。

Microsoft Azure での CPU またはメモリ リソースの追加

Microsoft Azure 上のインスタンスの CPU またはメモリ リソースを追加するには、インスタンスのサイズを変更する必要があります。 会社の Microsoft Azure インフラストラクチャにアクセスできる必要があり、Azure インスタンスを管理するには、Azure Portal、Azure CLI、または Azure PowerShell に精通している必要があります。 詳しくは、Microsoft Learn の「仮想マシンのサイズの変更」を参照してください。

サイズ変更に関する考慮事項をレビューしたり、サポートされているインスタンスの種類を確認したり、Microsoft Azure でインスタンスのサイズを変更する方法を確認したりできます。

Microsoft Azure のサイズ変更に関する考慮事項

お使いの GitHub Enterprise Server インスタンス で CPU またはメモリ リソースを増やす前に、次の推奨事項を確認してください。

  • CPU でメモリをスケールアップまたはスケールダウンします。 CPU リソースを増やす場合、GitHub は、インスタンスにプロビジョニングする各 vCPU ごとに少なくとも6.5GBのメモリを追加する（最大16vCPUまで）ことをおすすめします。 16以上のvCPUを使う場合は、各vCPUごとに6.5GBのメモリを追加する必要はありませんが、インスタンスが十分なメモリを持っているかをモニターするべきです。
  • インスタンスに静的 IP アドレスを割り当てます。 静的 IP を割り当てていない場合は、IP アドレスでの変更を考慮して、再起動後に GitHub Enterprise Server ホストの DNS A レコードを調整する必要があります。

Microsoft Azure でサポートされているインスタンスの種類

アップグレードするインスタンスタイプは、CPU とメモリの仕様に基づいて決定しなければなりません。

GitHub Enterprise Server アプライアンスは、プレミアムストレージのデータディスクを必要としており、プレミアムストレージをサポートするあらゆる Azure VM でサポートされます。 s サフィックスが付いた Azure VM の種類では、Premium Storage がサポートされます。 詳細については、「Azure で利用できるディスクの種類」 および Azure ドキュメントの「Azure Premium Storage: 高パフォーマンス用に設計する」を参照してください。

GitHub は、GitHub Enterprise Server にメモリ最適化された VM を推奨しています。 詳細については、Azure ドキュメントの「メモリ最適化済み仮想マシンのサイズ」を参照してください。

GitHub Enterprise Server は、VM タイプをサポートするあらゆる地域をサポートします。 各 VM でサポートされているリージョンの詳細については、Azure の「リージョン別の利用可能な製品」を参照してください。

Microsoft Azure でのインスタンスのサイズ変更

Microsoft Azure の GitHub Enterprise Server インスタンスで使用できるリソースを増やすには、VM のサイズを変更する必要があります。 VM のサイズを変更すると、VM が再起動されます。 場合によっては、先に VM の割り当てを解除する必要があります。 現在 VM をホストしているハードウェア クラスターで目的のサイズが使用できない場合、VM の割り当てを解除する必要があります。

  1. 今後のダウンタイムをユーザーに伝え、メンテナンス モードを有効にします。 詳細については、次の記事を参照してください。

  2. このインスタンスを停止するには、SSH 接続でインスタンスにログインして次のコマンドを実行します。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。

    sudo poweroff

  3. Azure で VM のサイズを変更するには、Microsoft Learn の「仮想マシンのサイズを変更する」の手順に従います。

  4. インスタンスが完全に再起動し、アクセスできるようになったら、新しいリソース構成が認識されていることを確認してください。 SSH 接続でインスタンスにログインして次のコマンドを実行します。

    ghe-system-info

  5. 必要に応じて変更点を確認するには、指定されたIP アドレスからのアクセスを許可するように IP 例外リストを構成します。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。

  6. ユーザー メッセージを設定した場合は、メッセージを削除します。

  7. メンテナンス モードを無効にします。

OpenStack KVMでのCPUあるいはメモリリソースの追加

OpenStack KVM 上の GitHub Enterprise Server インスタンスで使用できるリソースを増やすには、会社の OpenStack KVM インフラストラクチャにアクセスできる必要があります。VM を停止してから、新しいインスタンス フレーバーを選択する必要があります。

CPU リソースを増やす場合、GitHub は、インスタンスにプロビジョニングする各 vCPU ごとに少なくとも6.5GBのメモリを追加する（最大16vCPUまで）ことをおすすめします。 16以上のvCPUを使う場合は、各vCPUごとに6.5GBのメモリを追加する必要はありませんが、インスタンスが十分なメモリを持っているかをモニターするべきです。

  1. OpenStack KVM を使用して、現在のインスタンスのスナップショットを取ります。

  2. 今後のダウンタイムをユーザーに伝え、メンテナンス モードを有効にします。 詳細については、次の記事を参照してください。

  3. このインスタンスを停止するには、SSH 接続でインスタンスにログインして次のコマンドを実行します。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。

    sudo poweroff

  4. OpenStack KVM で、希望する CPU やメモリ リソースを持つ新しいインスタンス フレーバーを選択します。

  5. インスタンスが完全に再起動し、アクセスできるようになったら、新しいリソース構成が認識されていることを確認してください。 SSH 接続でインスタンスにログインして次のコマンドを実行します。

    ghe-system-info

  6. 必要に応じて変更点を確認するには、指定されたIP アドレスからのアクセスを許可するように IP 例外リストを構成します。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。

  7. ユーザー メッセージを設定した場合は、メッセージを削除します。

  8. メンテナンス モードを無効にします。

VMware ESXi の CPU またはメモリ リソースの追加

VMware 上の GitHub Enterprise Server インスタンスで使用できるリソースを増やすには、会社の VMware インフラストラクチャにアクセスできる必要があります。VM を停止してから、VMWare ESXi 内のリソースを調整する必要があります。

CPU リソースを増やす場合、GitHub は、インスタンスにプロビジョニングする各 vCPU ごとに少なくとも6.5GBのメモリを追加する（最大16vCPUまで）ことをおすすめします。 16以上のvCPUを使う場合は、各vCPUごとに6.5GBのメモリを追加する必要はありませんが、インスタンスが十分なメモリを持っているかをモニターするべきです。

  1. 今後のダウンタイムをユーザーに伝え、メンテナンス モードを有効にします。 詳細については、次の記事を参照してください。

  2. このインスタンスを停止するには、SSH 接続でインスタンスにログインして次のコマンドを実行します。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。

    sudo poweroff

  3. vSphere Client を使用して VMware ESXi ホスト上の VM を設定するには、VM を選択し、Edit Settings をクリックします。

  4. Hardware で、必要に応じて、VM に割り当てられた CPU とメモリ リソースを調整します。

  5. 仮想マシンを起動するには、 [OK] をクリックします。

  6. インスタンスが完全に再起動し、アクセスできるようになったら、新しいリソース構成が認識されていることを確認してください。 SSH 接続でインスタンスにログインして次のコマンドを実行します。

    ghe-system-info

  7. 必要に応じて変更点を確認するには、指定されたIP アドレスからのアクセスを許可するように IP 例外リストを構成します。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。

  8. ユーザー メッセージを設定した場合は、メッセージを削除します。

  9. メンテナンス モードを無効にします。