クラスタのネットワーク設定

ネットワークに関する考慮事� �

クラスタリングのための最もシンプルなネットワーク設計は、ノード群を単一のLANに置くことです。クラスタがサブネットワークにまたがる必要がある� �合は、ネットワーク間にファイアウォールルールを設定することはお勧めしません。ノード間の遅延は 1 ミリ秒未満である必要があります。

高可用性を実現するには、アクティブノードを備えたネットワークとパッシブノードを備えたネットワーク間の待ち時間が 70 ミリ秒未満である必要があります。 2 つのネットワーク間にファイアウォールを設定することはお勧めしません。

エンドユーザーのためのアプリケーションポート

アプリケーションのポートは、エンドユーザーにWebアプリケーションとGitへのアクセスを提供します。

Port	説明	Encrypted
22/TCP	Git over SSH	Yes
25/TCP	SMTP	STARTTLSが必要
80/TCP	HTTP	No (SSL が有効になっている� �合、このポートは HTTPS にリダイレクトされます)
443/TCP	HTTPS	Yes
9418/TCP	単純な Git プロトコルポート (プライベートモードでは無効)	No

管理ポート

管理ポートは、エンドユーザが基本的なアプリケーションを利用するためには必要ありません。

Port	説明	Encrypted
ICMP	ICMP Ping	No
122/TCP	管理SSH	Yes
161/UDP	SNMP	No
8080/TCP	Management Console HTTP	No (SSL が有効になっている� �合、このポートは HTTPS にリダイレクトされます)
8443/TCP	Management Console HTTPS	Yes

クラスタ通信ポート

ネットワークレベルのファイアウォールがノード間にある� �合は、これらのポートがアクセス可能である必要があります。ノード間の通信は暗号化されていません。これらのポートは外部からアクセスできません。

Port	説明
1336/TCP	内部 API
3033/TCP	内部 SVN アクセス
3037/TCP	内部 SVN アクセス
3306/TCP	MySQL
4486/TCP	Governor アクセス
5115/TCP	ストレージバックエンド
5208/TCP	内部 SVN アクセス
6379/TCP	Redis
8001/TCP	Grafana
8090/TCP	内部 GPG アクセス
8149/TCP	GitRPC ファイルサーバーアクセス
8300/TCP	Consul
8301/TCP	Consul
8302/TCP	Consul
9000/TCP	Git デーモン
9102/TCP	Pages ファイルサーバー
9105/TCP	LFS サーバー
9200/TCP	Elasticsearch
9203/TCP	セマンティックコードサービス
9300/TCP	Elasticsearch
11211/TCP	Memcache
161/UDP	SNMP
8125/UDP	Statsd
8301/UDP	Consul
8302/UDP	Consul
25827/UDP	Collectd

ロードバランサの設定

ノード間のトラフィックの分配には、PROXY プロトコルをサポートする TCP ベースの外部ロードバランサをおすすめします。以下のロードバランサ設定を検討してく� さい:

TCP ポート (以下に示す) は、web-server サービスを実行しているノードに転送する必要があります。これらは、外部クライアント要求を処理する唯一のノードです。
スティッキーセッションは有効化してはなりません。

警告: ロードバランサーの HTTPS 接続を終了する� �合、ロードバランサーから GitHub Enterprise Server への要求も HTTPS を使用する必要があります。接続の HTTP へのダウングレードはサポートされません。

クライアントの接続情� �の処理

クラスタへのクライアント接続はロードバランサから行われるため、クライアントの IP アドレスが失われる可能性があります。クライアント接続情� �を正しく取り込むには、追� の検討が必要です。

使用しているロードバランサがサポートできるなら、PROXYプロトコルの利用を強くおすすめします。 PROXY サポートが利用できない� �合でも、X-Forwarded-For ヘッダーを使って HTTP および HTTPS ポートを� 荷分散できます。

セキュリティの警告: PROXY サポートあるいは HTTP フォワーディングが有効化されている� �合、外部のトラフィックが直接 GitHub Enterprise Server アプライアンスに到達できないことが重要です。外部トラフィックが適切にブロックされていない� �合、ソース IP アドレスが偽� されるかもしれません。

GitHub Enterprise Serverでの PROXY サポートの有効化

インスタンスとロードバランサの双方でPROXYサポートを有効化することを強くおすすめします。

注: GitHub Enterprise Server は、AWS ネットワークロードバランサーと互換性のない PROXY プロトコル V1 をサポートしています。 GitHub Enterprise Server で AWS ネットワークロードバランサーを使用する� �合は、PROXY サポートを有効にしないでく� さい。

インスタンスにはこのコマンドを使用してく� さい:

$ ghe-config 'loadbalancer.proxy-protocol' 'true' && ghe-cluster-config-apply

ロードバランサでは、ベンダーから提供された手� �書に従ってく� さい。

PROXYプロトコルのTCPポートマッピング

送信元ポート	宛先ポート	サービスの説明
22	23	Git over SSH
80	81	HTTP
443	444	HTTPS
8080	8081	Management Console HTTP
8443	8444	Management Console HTTPS
9418	9419	Git

GitHub Enterprise Serverでの X-Forwarded-For サポートの有効化

X-Forwarded-For プロトコルは、PROXY プロトコルが使用できない� �合にのみ使用します。 X-Forwarded-For ヘッダーは HTTP と HTTPS でのみ機能します。 SSH経由のGit接続で示されるIPアドレスは、ロードバランサのIPを示します。

X-Forwarded-For ヘッダーを有効にするには、次のコマンドを使用します。

$ ghe-config 'loadbalancer.http-forward' 'true' && ghe-cluster-config-apply

PROXYサポートなしで使うプロトコルのTCPポートマッピング

送信元ポート	宛先ポート	サービスの説明
22	22	Git over SSH
25	25	SMTP
80	80	HTTP
443	443	HTTPS
8080	8080	Management Console HTTP
8443	8443	Management Console HTTPS

ヘルスチェックの設定

ロードバランサは健全性チェックによって、事前に設定されたチェックが失敗するようになったノードがあれば、反応しなくなったノードへのトラフィックの送信を止めます。クラスタのノードに障害が起きた� �合、冗長なノードと組み合わさったヘルスチェックが高可用性を提供してくれます。

以下のURLのいずれかをチェックするようにロードバランサを設定してく� さい。

https://HOSTNAME/status HTTPS が有効な� �合 (既定)
http://HOSTNAME/status HTTPS が無効な� �合

ノードが正常でエンドユーザーからの要求に応えられる� �合、このチェックによって状態コード 200 (OK) が返されます。

注: アプライアンスがメンテナンスモードの� �合、https://HOSTNAME/status URL は状態コード 503 (サービス利用不可) を返します。詳細については、「メンテナンスモードの有効化とスケジューリング」を参照してく� さい。

DNS の要件

GitHub Enterprise Serverのホスト名に対するDNSルックアップは、ロードバランサに解決されなければなりません。 Subdomain Isolationを有効化することをおすすめします。サブドメイン分離が有効化されている� �合、追� のワイルドカードレコード (*.HOSTNAME) もロードバランサーに解決されなければなりません。詳細については、「サブドメイン分離の有効化」を参照してく� さい。

この記事では、次の� �目が扱われます。