「パブリックからプライベート (Public-to-private)」ロード・バランサー

ロード・バランサー・サービス・インスタンスには、パブリックにアクセス可能な完全修飾ドメイン・ネームが割り当てられます。 ロードバランサーサービスの後ろでホストされているアプリケーションにアクセスするには、このドメイン名を使います。 このドメイン・ネームには、1 つ以上のパブリック IP アドレスを登録できます。 パブリック IP アドレスとその数は、ユーザーには認識されないメンテナンスとスケーリングのアクティビティーに基づいて、時間の経過と共に変化する可能性があります。 アプリケーションをホストするバックエンドのコンピュート・インスタンスは、 IBM Cloud Private ネットワーク上になければならない。

良い慣例として、直接のパブリック接続を必要としている場合を除いて、バックエンド・サーバーをprivate-onlyとしてプロビジョンすることをお勧めします。 この慣例は、セキュリティーの向上に役立ち、ユーザーのパブリック IP アドレスを保護します。 これらのバックエンド・サーバーでホストされているアプリケーションはロード・バランサーを使用してパブリック・ネットワーク経由でアクセス可能であることに変わりはありません。

ロード・バランサーにパブリック IP アドレスを割り当てる方法は 2 つあります。

• IBM システムプールから割り当てる： デフォルトの方法。 この方式では、IBM システム・プールから IP アドレスを割り振ります。

• このアカウント内のパブリック・サブネットから割り振る (Allocate from a public subnet in this account): この方式では、ご使用のアカウントのパブリック・サブネットから IP アドレスを割り当てます。 デフォルトでは、サブネットの選択は自動的に行われます。 API を使用している場合は、注文を実行するときにパブリック・サブネット ID を渡すことによって、特定のサブネットを選択できます。

「プライベートからパブリック」ロード・バランサー

内部ロード・バランサーは IBM Cloud プライベート・ネットワーク内でのみアクセス可能です。

「パブリックからプライベート (public-to-private)」ロード・バランサー同様、内部ロード・バランサーのサービス・インスタンスにも完全修飾ドメイン・ネームが割り当てられます。 ただし、このドメイン・ネームには 1 つ以上のプライベート IP アドレスが登録されます。

パブリックのロードバランサーと同様に、プライベートIPアドレスとその番号は、メンテナンスやスケーリング活動に基づいて時間と共に変更される可能性があり、これはユーザーには透過的である。

アプリケーションをホストするバックエンド・コンピュート・インスタンスも、IBM Cloud プライベート・ネットワーク上になければなりません。

パブリック間のロード・バランサー

パブリック間のロード・バランサーは、パブリックにアクセス可能です。

他のタイプのロード・バランサー同様、パブリック間のロード・バランサーのサービス・インスタンスにも完全修飾ドメイン・ネームが割り当てられます。 このドメイン・ネームには、1 つ以上のパブリック IP アドレスを登録できます。

ロードバランサがプロビジョニングされると、サーバテーブルのコンテキストにある メンバーのパブリックIPアドレスだけが見えるようになります。 これは、レイヤー 4 およびレイヤー 7 のロード・バランサー・メンバーの両方に適用されます。

パブリックIPアドレスとその番号は、メンテナンスとスケーリング活動に基づいて時間の経過とともに変更される可能性があり、これはユーザーには透過的である。

アプリケーションをホスティングするバックエンド・コンピュート・インスタンスは、IBM Cloud のパブリック・ネットワーク上になければなりません。

フロントエンド・アプリケーションおよびバックエンド・アプリケーションのポート/プロトコル

最大 10 個のフロントエンド・アプリケーションのポート (プロトコル) を定義し、それらをバックエンド・アプリケーション・サーバー上の各ポート (プロトコル) にマップすることができます。 ロード・バランサー・サービス・インスタンスに割り当てられている完全修飾ドメイン・ネームとフロントエンド・アプリケーションのポートは、外部の世界に公開されます。 着信ユーザー要求は、これらのポートで受信されます。

バックエンドのポートは内部でのみ知られている。 これらのバックエンド・ポートは、フロントエンド・ポートと同じ場合もあれば同じでない場合もあります。 例えば、ロード・バランサーは、フロントエンド・ポート 80 で着信 Web/HTTP トラフィックを受信するよう構成され、一方でバックエンド・サーバーは、カスタム・ポート 81 で listen している場合があります。

サポートされるフロントエンドのポート/プロトコルは HTTP、HTTPS、および TCP です。 サポートされるバックエンドのポート/プロトコルも HTTP、HTTPS、および TCP です。 バックエンド・サーバーとのプレーン・テキスト HTTP 通信を可能にするには、着信 HTTPS トラフィックをロード・バランサーで終了する必要があります。 バックエンド・プロトコルが HTTPS の場合、トラフィックはロード・バランサーとバックエンド・サーバーの間で暗号化されます。

ロード・バランシング方式

バックエンド・アプリケーション・サーバー間でトラフィックを分散するために、以下の 3 つのロード・バランシング方式が使用可能です。

• ラウンドロビン - ラウンドロビンは、デフォルトのロード・バランシング方式です。 この方式では、ロード・バランサーは、着信クライアント接続をラウンドロビン形式でバックエンド・サーバーに転送します。 その結果として、すべてのバックエンド・サーバーは、ほぼ同数のクライアント接続を受信します。

• 重み付きラウンドロビン - この方式では、ロード・バランサーは、バックエンド・サーバーに割り当てられた重みに比例して、着信クライアント接続をバックエンド・サーバーに転送します。 各サーバーには、デフォルトの重み 50 が割り当てられます。この重みは、0 から 100 までの範囲の任意の値にカスタマイズできます。

  例えば、3 台のアプリケーション・サーバー A、B、および C があり、それらの重みがそれぞれ 60、60、および 30 にカスタマイズされている場合、サーバー A と B は同数の接続を受信し、サーバー C はその半数の接続を受信します。

  サーバーの重みを 0 にリセットするということは、そのサーバーには新しい接続が転送されず、既存のトラフィックはすべて、アクティブである限りフローし続けることを意味します。 重み 0 は、サーバーを正常に終了させ、サービス・ローテーションからそのサーバーを除外したい場合に使用すると役に立ちます。

  サーバーの重みの値は、重み付きラウンドロビン方式でのみ利用可能です。 サーバーのウェイト値は、ラウンドロビン方式と最小接続負荷分散方式では無視されます。

• 最小接続 - この方式では、指定された時間に最も少ない数の接続にサービス提供しているサーバー・インスタンスが次のクライアント接続を受信します。

水平スケーリング

ロード・バランサーは、負荷に応じて自動的にその容量を調整します。 調整が行われるときに、ロード・バランサーの DNS 名に関連付けられている IP アドレスの数が変わるのが分かることもあります。

マルチゾーン地域の要件

マルチゾーンリージョン(MZR)は、ロードバランサーアプライアンスを複数のデータセンターに配置することで、高可用性を保証します。 ロードバランサーを作成するとき、デプロイするサブネットを選択します。 データセンターがMZRの一部である場合、1つのアプライアンスは選択したデータセンターに展開され、もう1つのアプライアンスは同じリージョン内の別のデータセンターに展開されます。

例えば、Dallas (us-south) は、データセンター dal10、 dal12、 dal13 を含むMZRである。 サブネットAは dal10、サブネットBとCは dal12、サブネットDとEは dal13。 dal13 データセンターにロードバランサーを作成する場合、最初のアプライアンスは dal13 にデプロイされ、2 番目のアプライアンスは dal10 または dal12 データセンター間の利用可能な IP が最も多いサブネットにデプロイされます。

現在 Cloud Load Balancer サービスは Classic infrastructureに 記載されているデータセンターで利用できる。

MZR には、以下の要件があります。

• 選択したデータセンターはMZRの一部でなければならない。
• VLAN スパンニングまたは VRF がアカウントで有効になっている必要があります。
• MZR のデータ・センターで、アカウントにプライベート・サブネットが存在する必要があります。 データ・センターにコンピュート・デバイスを作成すると、プライベート・サブネットがインスタンス化されます。

選択したデータセンターがMZRの一部でない場合、またはアカウントでVLANスパニングまたはVRFが有効になっていない場合、ロードバランサーは元のデプロイ動作に従って、指定したデータセンターですべてのノードがインスタンス化された状態で作成されます。

マルチゾーン・リージョンの詳細については、 IBM Cloud リソース配置のためのリージョンとデータセンターの場所を 参照してください。 リージョンとゾーンのマッピングについては、 アカウントごとのゾーンマッピングを 参照してください。