Foxpass LDAP

LDAP：带分区的大规模 LDAP

介绍

LDAP是一个常见的目录信息源；该协议的第一个版本是在1993年编纂的。它通常用于各种应用，包括管理Linux实例的用户/组信息，以及控制VPN和传统应用的认证。

传统上，公司的LDAP服务器是在内部运行的；通常是微软的Active Directory的一部分，或者是开放源码OpenLDAP项目的一个部署。 现在，SaaS供应商可以提供LDAP支持；包括Foxpass，它是第一个从头开始建立一个多用户、以云为中心的LDAP实施的云LDAP供应商。

简单介绍一下：LDAP通常有以下基元：绑定、搜索、比较和添加。在创建一个TCP连接后，应用程序首先需要通过发送一个用户名和密码进行绑定。一旦绑定成功，客户端将向LDAP服务器发出命令；通常是与过滤器一起的搜索命令。TCP连接一直保持到客户端或服务器断开连接。

Foxpass 的 LDAP

在 Foxpass，我们的 LDAP 服务是在 Twisted 之上编写的，Twisted 是一种流行的基于事件的 Python 服务框架。 该服务托管在 AWS 的 ECS 平台上，运行在数十个容器（节点）上。 由于 LDAP 连接是持久的，因此集群必须能够同时维护数十万个 TCP 会话。

我们将客户的数据保存在 RAM 中。 这样做的原因是多方面的。 首先，数据集相对较小，即使对于大客户也是如此。 其次，LDAP 查询语言允许搜索任意字段（这很重要，因为 Foxpass 允许自定义字段）。 这意味着传统的 RDBMS 系统将无法构建有效的索引，我们必须将数据转换为不同的内存表示形式。 第三，将数据保存在 RAM 中可以实现最快的响应时间：延迟通常在 100 毫秒左右（见图 a）。

图 a：“搜索”命令的第 95 个百分位响应时间

 

这种方法的一个缺点是缓存失效。 当客户的数据发生变化时（例如，添加或删除用户），LDAP 节点必须从我们的主 RDBMS 刷新它们的数据。 在我们之前的架构中，这是一个相对昂贵的操作； 当每个节点刷新同一家公司的数据时，它可能会导致 LDAP 延迟和后备存储负载出现明显的峰值。

延迟敏感性挑战

如上所述，由于延迟要求，每个容器都将所有客户的数据存储在内存中（见图 a）。 当请求到达一个节点时（如果它尚未存在），数据将按需获取，然后只要来自该客户的至少一个连接存在，数据就会一直存在。

由于传入的连接请求可以到达任何容器（通过负载均衡器），因此提供查询的容器也会加载和存储客户的所有数据。 随后，容器向 redis pubsub 服务注册以接收失效消息。 当公司数据发生更新时，将广播无效信号，接收节点会清除该公司的数据缓存，并转到数据库重新获取公司数据。 随着我们不断发展并将新客户添加到我们的系统中，这对扩展我们的 LDAP 服务提出了以下挑战：

• 跨所有节点 (N) 的客户 (M) 的所有数据都需要在失效时重新加载。 尽管实际上并非每个节点都承载来自每个客户的连接，但在最坏的情况下，会对数据库进行 MxN 次调用以刷新数据。 随着更多客户的添加 (M)，数据库提取的数量会增加 N 倍。这也意味着，为了不让数据库机器不堪重负，需要额外的数据库读取器实例来处理请求的激增。
• 由于跨客户 (M) 的所有数据都存储在跨多个节点 (N) 的内存中，因此所有节点的内存继续增加，并与客户数量 (M) 成比例。 这也意味着容器的内存需求必须增长以容纳内存中的所有数据，这反过来又增加了整体基础设施成本。

上述挑战非常明显，让我们倾向于跨节点分布客户数据，而不是在每个节点上复制所有客户的数据。 这使我们找到了分布式缓存管理解决方案。

图a

                 

分布式缓存管理

我们在 LDAP 服务中引入了一个智能路由层，如果连接所在的容器未托管数据，该层会将请求转发到托管客户数据的节点。 为实现这一目标，我们缩小了路由层的以下设计要求：

• 客户需要在添加时动态分布在节点之间。
• 客户的数据需要随着节点收缩、扩展和节点故障而动态分布
• 能够增加和减少特定客户的分区数量，以便流量不平衡不会压倒任何单个节点。

我们引入了 Apache Helix，它可以跨实例分配资源。 Helix 控制器是 helix 生态系统的大脑。 当添加或删除节点或客户时，它会跨节点做出资源分配决策。 我们对 Apache Helix 控制器、Rest 服务器进行了 docker 化，并将其部署在 ECS 上。 Helix 控制器依赖于 Zookeeper 来监听集群的变化。 我们实施了一种在 ECS 上部署 Zookeeper 的可靠方法。 Helix 和 Zookeeper 的整个基础架构都运行在 ECS 上。

每个 LDAP 节点都与 Zookeeper 交互以注册自己以加入集群。 每个 LDAP 实例作为 Helix 参与者出现，参与集群以由 Helix 控制器进行客户到节点的分配。 当 LDAP 节点动态创建新客户时，该客户的分区数（每个分区代表一个托管数据的节点）根据用户数确定。 通过这种集成，我们的 LDAP 节点可以了解集群中发生的事件，即添加新客户或可用节点集发生变化时。

有了这种集群意识，我们 LDAP 服务中的路由层提供了节点和客户之间的映射。 现在每个传入连接都将通过路由层来决定连接必须路由到哪个节点。 这样，客户的数据就会分配给特定的节点（见图 b）。 

图b

 

路由层托管一个缓存，其中包含客户和节点的路由信息。 路由层监视任何客户到节点的分配更改，并在检测到更改时立即更新。 这样，每个 LDAP 节点都会在客户到节点的更改发生时立即意识到它们。 通过上述缓存管理解决方案，解决了延迟敏感性挑战部分中提到的可扩展性挑战：

• 我们现在的客户分布在各个节点上。 每个节点将仅托管一部分客户，并负责在收到 pubsub 无效时仅获取一部分客户数据。 这显着减少了对数据库的读取次数，无需添加数据库读取器节点来处理大量数据库读取。 LDAP 集群现在比以前减少了 75% 的数据库读取。
• 我们还提高了内存效率，因为我们没有将所有客户 (M) 数据存储在所有节点 (N) 的内存中。 这种架构提供了水平扩展的能力，而无需增加实例大小。 每个 LDAP 节点现在消耗的内存比以前减少了 40%。

 

 

当前的挑战

对于上述实现，挑战之一是节点接收到不相等数量的 TCP 连接。 与其他节点相比，这种分布不平衡会导致某些节点（热节点）上的 CPU 使用率更高。 但是与以前相比，节点间的平均整体 CPU 利用率仍然保持不变。

致谢

感谢整个团队。 特别值得一提的是 Bryan Bojorque，他帮助我们容器化和构建了 Helix 和 Zookeeper 集群，并将这些集群中的指标带到了 Datadog。