010-68421378
sales@cogitosoft.com
产品分类
AddFlow  AmCharts JavaScript Stock Chart AmCharts 4: Charts Aspose.Total for Java Altova SchemaAgent Altova DatabaseSpy Altova MobileTogether Altova UModel  Altova MapForce Altova MapForce Server Altova Authentic Aspose.Total for .NET Altova RaptorXML Server ComponentOne Ultimate Chart FX for SharePoint Chart FX CodeCharge Studio ComponentOne Enterprise combit Report Server Combit List & Label 22 Controls for Visual C++ MFC Chart Pro for Visual C ++ MFC DbVisualizer version 12.1 DemoCharge DXperience Subscription .NET DevExpress Universal Subscription Essential Studio for ASP.NET MVC FusionCharts Suite XT FusionCharts for Flex  FusionExport V2.0 GrapeCity TX Text Control .NET for WPF GrapeCity Spread Studio Highcharts Gantt Highcharts 10.0 版 HelpNDoc Infragistics Ultimate  ImageKit9 ActiveX ImageKit.NET JetBrains--Fleet JetBrains-DataSpell JetBrains--DataGrip jQuery EasyUI jChart FX Plus OPC DA .NET Server Toolkit  OSS ASN.1/C Oxygen XML Author  OSS 4G NAS/C, C++ Encoder Decoder Library OSS ASN.1 Tools for C with 4G S1/X2 OSS ASN.1/C# OSS ASN.1/JAVA OSS ASN.1/C++ OPC HDA .NET Server Toolkit OPC DA .Net Client Development Component PowerBuilder redgate NET Developer Bundle Report Control for Visual C++ MFC  Sencha Test SPC Control Chart Tools for .Net Stimulsoft Reports.PHP Stimulsoft Reports.JS Stimulsoft Reports.Java Stimulsoft Reports. Ultimate Stimulsoft Reports.Wpf Stimulsoft Reports.Silverlight SlickEdit Source Insight Software Verify .Net Coverage Validator Toolkit Pro for VisualC++MFC TeeChart .NET Telerik DevCraft Complete Altova XMLSpy Zend Server

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。

 

 

快速导航

                               

 京ICP备09015132号-996网络文化经营许可证京网文[2017]4225-497号 | 违法和不良信息举报电话:4006561155

                                   © Copyright 2000-2023 北京哲想软件有限公司版权所有 | 地址:北京市海淀区西三环北路50号豪柏大厦C2座11层1105室

                         北京哲想软件集团旗下网站:哲想软件 | 哲想动画

                            华滋生物