web-dev-qa-db-ja.com

複数の無関係なドメイン名に対してHTTPSを提供するが、単一のWebサーバークラスターに分散するLinux HAソフトウェアロードバランサーはありますか？

クラウドベース（Amazon AWS、Rackspaceなど）のマルチテナントSaaSアプリケーションがあり、関連のない複数のテナントドメインのHTTPS通信をサポートする必要があります。

説明のための例として、SaaSが次の場所で利用可能であるとしましょう。

https://foo.com

テナントは、次の方法でテナント固有のUIおよびサービスエンドポイントにアクセスできます。

https://tenantA.foo.com
https://tenantB.foo.com
...

これは、1つのワイルドカードSSL証明書で今日簡単にサポートできます。

ただし、SaaSを使用すると、テナントはUIを（ただし、ブランド化して）直接自分のユーザーに公開したい場合があります。

これにより問題が発生します。たとえば、JohnSmithがtenantAの既存の顧客であり、foo.comの知識がないとします。ジョン・スミスがhttps://tenantA.foo.comに誘導された場合、彼らは簡単に混乱する可能性があります（たとえば、「一体誰がfoo.comですか？なぜ私はここにいますか？私はハッキングされていますか？ああ！」）。

この問題を回避するために、テナントは次のようなサブドメインを設定します。

https://foo.tenantA.com

これにより、エンドユーザーの混乱を避けることができます。tenantAのユーザーは、tenantAが所有していると認識したURLを確認でき、アプリをより簡単に使用できます。しかし、tenantAは、アプリに関するすべてをホストすることを望んでいます。つまり、foo.comのインフラストラクチャはSSL接続を提供する必要があります。

そのために、以下をサポートしたいと思います。

  1. テナントがfoo.tenantA.comのSSL証明書+キーをアップロードします。
  2. そのSSL証明書を取得し、それを高可用性負荷分散クラスター（2つ以上のLBノード）に動的にインストールします。このクラスターは、SaaSアプリケーションWebエンドポイントへの要求を負荷分散します。
  3. テナントはDNSを更新して、foo.tenantA.comがtenantA.foo.comへのCNAMEリダイレクトになるようにします。

このようにして、ロードバランサープールはfoo.tenantA.comへのすべてのHTTPS通信を提供/終了し、すべてのリクエストはSaaS Webサーバークラスターに負荷分散されます。

これは、SSL証明書をLBプールに追加したりLBプールから削除したりできる必要があることを意味します実行時。変更によって、既存または新規のHTTPS要求を処理する機能が中断されることはありません。

また、Linuxを使用して仮想化ハードウェア（EC2など）にデプロイするため、ハードウェア/データセンターにアクセスできません。これは、Linuxで実行できるソフトウェアベースのソリューションである必要があります。また、高可用性（2つ以上のLB 'ノード'）である必要があります。

誰かが具体的な解決策を知っていますか？たとえば、これをサポートするようにNginx、HAProxy、Squid（またはその他）を設定できますか？文書化され適切な「レシピ」または既存のソリューションはありますか？

P.S. AmazonのElasticLoad Balancer（執筆時点）は、このニーズを実用的に満たすことができませんeachテナントドメイン用のAmazonELBが必要になります。すべてのELBがWebサーバーに「ping」する必要があるため、500のテナントがある場合、500のELBがSaaS Webサービスエンドポイントにpingを実行します。これは無視できないほどのパフォーマンスへの悪影響です。

sslload-balancinghttpssaasmulti-tenancy
5
Les Hazlewood

更新2017-09-13：SNIは現在、主流のブラウザーで十分に普及しているため、おそらく要求に対処するために使用できます。この回答は古くなっていると見なされます。

これをサポートする唯一の方法は、クライアントごとにIPを用意することです。 https経由で接続すると、接続はすぐに暗号化されます、ブラウザが「foo.tenantA.comのためにここにいます」と言う機会はありません。したがって、サーバーが接続の暗号化に使用するSSL証明書を知る唯一の方法は、接続が行われたIPに基づいています。

今でもこれは可能ですが、それはあなたがたくさんのIPを必要とすることを意味します。私たちは実際に私の仕事でこの正確なセットアップを行います。 2つのアクティブ/アクティブロードバランサーがあり、一方のバランサーに半分のIPがあり、もう一方のバランサーに残りの半分があります（合計で約500 IP）。次に、すべての接続を取得する複数のWebサーバーがバックエンドにあります。すべてのWebサーバーに障害が発生する可能性があり、ロードバランサーはサーバーへの接続の送信を停止します。または、ロードバランサー自体に障害が発生し、他のロードバランサーがすべてのIPを取得する可能性があります。
これを行う負荷分散ソフトウェアは Pacemaker および ldirectord です（どちらも主流のプロジェクトであり、実行するディストリビューションはすべてリポジトリに格納する必要があります）。 Linuxカーネル自体が実際に負荷分散を行うものであり、ソフトウェアはフェイルオーバーの処理を担当します。

注：負荷分散については、 keepalived や surealived など、ldirectordの代替手段がたくさんあります。実際のロードバランサーフェイルオーバーソフトウェアの場合でも、ペースメーカーを使用する必要があります。

基本ガイド：

  • This ペースメーカーを構成するための基本的な手順を提供します。 CMANがその代替であるため、以前のものをすべてスキップできます。ガイドのその時点に到達するために必要なことは、ペースメーカーとその依存関係をインストールすることだけです。セクション8.2.4で停止します。セクション8.3に進む必要はありません。それは、あなたがしていることに関係がないからです。

  • ペースメーカーが機能するようになると、 this は、httpサーバーの負荷を分散するための非常に基本的な構成を提供します。

  • this および this もご覧ください。ペースメーカーのより高いレベルの概要、それが何をするか、そしてそれをどのように使用するか。

5
Patrick

クライアントが自分で薄いラッパーを配置することを推奨するのはどうですか？このようなもの：

  1. エンドユーザーがhttps://api.tenantA.comにリクエストを送信します
  2. api.tenantA.comはリクエストをhttps://tenanta.foo.comに転送するだけです
  3. その後、応答は同じ方法でフィルタリングされます。

これがエッジケースである限り、問題なく動作するはずだと思います。

0
Kyle