Les*_*ood 5 ssl https load-balancing saas multi-tenancy
我有一个基于云的（Amazon AWS、Rackspace 等）多租户 SaaS 应用程序，我需要支持多个不相关租户域的 HTTPS 通信。
作为说明性示例，假设我们的 SaaS 可在以下位置获得：
https://foo.com
租户可以通过以下方式访问其租户特定的 UI 和服务端点：
https://tenantA.foo.com
https://tenantB.foo.com
...
这在今天很容易通过一个通配符 SSL 证书来支持。
然而，使用我们的 SaaS，我们的租户可能希望直接向他们自己的用户公开我们的 UI（但为他们打上品牌）。
这会导致一个问题：假设 John Smith 是 的现有客户tenantA（并且不知道foo.com）。如果 John Smith 被定向到https://tenantA.foo.com，他们很容易混淆（例如“谁他妈的是 foo.com？我为什么在这里？我被黑客入侵了吗？啊哈！”）。
为了避免这个问题，我们的租户会设置一个子域，如：
https://foo.tenantA.com
这避免了许多最终用户的困惑：tenantA的用户可以看到他们认为拥有的 URL，tenantA并且将更容易使用该应用程序。但是tenantA希望我们托管有关应用程序的所有内容，这意味着foo.com的基础架构需要为 SSL 连接提供服务。
为此，我们希望支持以下内容：
foo.tenantA.com。foo.tenantA.com为 CNAME 重定向到tenantA.foo.com.这样，我们的负载均衡器池将提供/终止所有 HTTPS 通信，foo.tenantA.com并且所有请求都将负载均衡到我们的 SaaS Web 服务器集群。
这意味着 SSL 证书应该能够在运行时从 LB 池中添加和删除。更改不能中断为现有或新 HTTPS 请求提供服务的能力。
此外，由于我们将在使用 Linux 的虚拟化硬件（例如 EC2）上进行部署，因此我们无法访问硬件/数据中心。这必须是可以在 Linux 中运行的基于软件的解决方案。它还必须是高度可用的（2 个或更多 LB“节点”）。
有谁知道具体的解决方案？例如，是否可以设置 Nginx、HAProxy 或 Squid（或其他任何东西）来支持这一点？是否有记录在案且合适的“配方”或现有解决方案？
PS Amazon 的 Elastic Load Balancer（在撰写本文时）无法切实满足这种需求 -每个租户域都需要一个 Amazon ELB 。由于每个 ELB 都需要“ping”Web 服务器，如果您有 500 个租户，那么您将有 500 个 ELB ping SaaS Web 服务端点——这是一个不可忽视的负面性能影响。
2017 年 9 月 13 日更新： SNI 现在在主流浏览器中已经足够流行，它可能可以用来解决请求，这个答案应该被认为是过时的。
支持这一点的唯一方法是为您的每个客户拥有一个 IP。当您通过 https 连接时，连接会立即加密，浏览器不会说“我在这里是为了 foo.tenantA.com”。因此，服务器知道应该使用哪个 SSL 证书来加密连接的唯一方法是基于连接的 IP。
现在这仍然是可能的，但这意味着您将需要大量 IP。我们实际上在我的工作中做了这个精确的设置。我们有 2 个主动/主动负载均衡器，一半的 IP 位于一个均衡器上，另一半位于另一个均衡器上（总共约 500 个 IP）。然后我们在后端有几个 Web 服务器，它们接受所有连接。任何 Web 服务器都可能出现故障，负载均衡器将停止向其发送连接。或者负载平衡器本身可能会失败，而另一个会占用它的所有 IP。
执行此操作的负载平衡软件是Pacemaker和ldirectord（两者都是主流项目，您运行的任何发行版都应该将它们放在其存储库中）。Linux 内核本身是真正进行负载平衡的内核，软件只负责处理故障转移。
注意：对于负载平衡，ldirectord 有很多替代方案，例如keepalived和surealived。尽管对于实际的负载平衡器故障转移软件，您应该使用起搏器。
基本指南：
这将提供配置起搏器的基本说明。您可以跳过之前的所有内容，因为 CMAN 是它的替代品。要达到指南中的这一点，您唯一需要做的就是安装起搏器及其依赖项。停在第 8.2.4 节。您不需要继续阅读第 8.3 节，因为这与您正在做的事情无关。
一旦您让起搏器工作，这将提供一个非常基本的配置来平衡 http 服务器的负载。
| 归档时间： |
|
| 查看次数： |
1190 次 |
| 最近记录： |