Kerberos 是一种网络认证协议，其设计目标是通过密钥系统为客户端、服务器端的应用程序提供强大的认证服务。
作为一种可信任的第三方认证服务，Kerberos是通过传统的密码技术（如：共享密钥）执行认证服务的，被Client和Server同时信任。KDC是对该协议中第三方认证服务的一种具体实现，一直以来都是美团数据平台的核心服务之一，在Hive、HDFS、YARN等开源组件的权限认证方面有着广泛的应用。该服务将认证的密钥事先部署在集群的节点上，集群或者新节点启动时，相应节点使用密钥得到认证。只有被认证过节点才能被集群所接纳。企图冒充的节点由于没有相关密钥信息，无法与集群内部的节点通信，从而有效的确保了数据的安全性、节点的可信赖性。
但随着平台业务的快速增长，当前线上KDC的处理能力不足和不能可靠监控的问题被凸显的日益严重：线上单台KDC服务器最大承受QPS是多少？哪台KDC的服务即将出现压力过大的问题？为什么机器的资源非常空闲，KDC的压力却会过大？如何优化？优化后瓶颈在哪儿？如何保证监控指标的全面性、可靠性和准确性？这都是本文需要回答的问题。从本次优化工作达成的最终结果上来看，单台服务器每秒的处理性能提升16倍左右，另外通过共享内存的方式设计了一个获取KDC各项核心指标的接口，使得服务的可用性进一步提升。
为方便大家，表1总结并解释了本文中后续会涉及到一些专业名词的简称：
图1为美团数据平台KDC当前服务架构，目前整个KDC服务部署在同一个IDC。
Client、 KDC和Server在认证阶段主要有Client和KDC的AS、Client和KDC的TGS以及Client和Server的交互三个过程，下文将详细介绍三个过程的交互，其中图2中的步骤1和2、3和4、5和6分别对应下文的A、B、C三部分：
通过对KDC原理的分析，很容易判断只有前两部分才可能直接给KDC服务带来压力，因此本文涉及到的工作都将围绕上一部分的前两个环节展开分析。本次优化工作采用Grinder这一开源压测工具，分别对AS、TGS两个请求过程，采用相同机型（保证硬件的一致性）在不同场景下进行了压力测试。
优化之前，线上KDC服务启动的单进程；为最低风险的完成美团和点评数据的融合，KDC中keytab都开启了PREAUTH属性；承载KDC服务的部分服务器没有做RAID。KDC服务出现故障时，机器整体资源空闲，怀疑是单进程的处理能力达到上限；PREAUTH属性进一步保证提升了KDC服务的安全性，但可能带来一定的性能开销；如果线上服务器只加载了少量的keytab信息，那么没有被加载到内存的数据必然读取磁盘，从而带来一定的IO损耗。
因此本文中，对以下三个条件进行变动，分别进行了测试：
表2为AS压测的一组平均水平的测试数据，使用的物理机有40核，因此多进程测试启动40个进程。
分析表2中的数据，很容易提出如下问题从而需要进一步探索：
1. 比较表2中第一行和第二行、第三行和第四行，主机做不做RAID为什么对结果几乎无影响？
该四组（测试结果为49、53、100和104所在表2中的行）数据均在达到处理能力上限一段时间后产生认证失败，分析机器的性能数据，内存、网卡、磁盘资源均没有成为系统的瓶颈，CPU资源除了某个CPU偶尔被打满，其他均很空闲。分析客户端和服务端的认证日志，服务端未见明显异常，但是客户端发现大量的Socket Timeout错误（测试设置的Socket超时时间为30s）。由于测试过程中，客户端输出的压力始终大于KDC的最大处理能力，导致KDC端的AS始终处于满负荷状态，暂时处理不了的请求必然导致排队；当排队的请求等待时间超过设置的30s后便会开始超时从而认证出错，且伴随机器某一CPU被打满（如图3）。 显然KDC单进程服务的处理能力已经达到瓶颈且瓶颈存在单核CPU的处理能力，从而决定向多进程方向进行优化测试。
图4为本次压力测试的一个通用模型，假设KDC单位时间内的最大处理能力是A，来自客户端的请求速率稳定为B且 B>A ；图中黄色区域为排队的请求数，当某一请求排队超过30s，便会导致Socket Timedout错误。
2. 比较表2中第1和3行、第2和4行、第7和8行相比，为什么有PREAUTH属性的认证QPS大致是无该属性处理能力的一半？
如果Client的keytab在KDC的库中不带有PREAUTH这一属性，Client发送请求，KDC的AS模块验证其合法性之后返回正确的结果；整个过程只需要两次建立链接进行交互便可完成。如果带有PREAUTH属性，意味着该keytab的认证启动了Kerberos 5协议中的 pre-authentication概念：当AS模块收到Client的请求信息后；故意给Client返回一个错误的请求包，Client会“领悟到”这是KDC的AS端需要进行提前认证；从而Client获取自己服务器的时间戳并用自己的密钥加密发送KDC，KDC解密后和自身所在服务器的时间进行对比，如果误差在能容忍的范围内；返回给Client正确的TGT响应包；过程如图5所示。
3. 根据对问题2的分析，表2中第5和7行的值的比例应该近似为1:2，为什么第5行的值只有115，结果和理论差距如此之大？
KDC的库中对客户端的keytab开启PREAUTH属性，客户端每认证一次，KDC需要将该次认证的时间戳等信息写到本次磁盘的BDB数据库的Log中；而关闭PREAUTH属性后，每次认证只需要从库中读取数据，只要给BDB数据库分配的内存足够大，就可以最大程度的减少和本次磁盘的交互。KDC40进程且开启PRAUTH，其AS处理能力的QPS只有115，分析机器性能的相关指标，发现瓶颈果然是单盘的IO，如图6所示。使用BDB提供的工具，查看美团数据平台KDC服务的BDB缓存命中率为99%，如图7所示：
4. KDC AS处理能力在多进程做RAID条件下，有无preauth属性，KDC服务是否有瓶颈？如果有在哪里？
经多次实验，KDC的AS处理能力受目前物理机CPU处理能力的限制，图8为有PREAUTH属性的CPU使用情况截图，无PREAUTH结果一致。
表3为TGS压测的一组平均水平的测试数据：
分析表3中的数据，可以发现KDC对TGS请求的处理能力和主机是否做RAID无关,结合KDC中TGS的请求原理，就较容易理解在BDB缓存命中率足够高的条件下，TGS的请求不需要和本次磁盘交互；进一步做实验，也充分验证了这一点，机器的磁盘IO在整个测试过程中，没有大的变化，如图9所示，操作系统本身偶尔产生的IO完全构不成KDC的服务瓶颈。KDC单进程多进程的对比，其处理瓶颈和AS一致，均受到CPU处理能力的限制（单进程打满某一CPU，多进程几乎占用整台机器的CPU资源）。从Kerberos的设计原理分析，很容易理解，无论KDC库中的keytab是否带有PREAUTH属性，对TGS的处理逻辑几乎没有影响，压测的数据结果从实际角度验证了这一点。
Client和KDC的交互，支持TCP和UDP两种协议。在网络环境良好的情况下，两种协议的KDC的测试结果理论上和实际中几乎一致。但是在原生代码中，使用TCP协议，在客户端给KDC造成一定压力持续6s左右，客户端开始认证出错，在远未达到超时时限的情况下，Client出现了socket reset类的错误。KDC查看内核日志，发现大量possible SYN flooding on port 8089(KDC的服务端口). Sending cookies，且通过netstat -s发现机器的xxxx times the listen queue of a socket overflowed异常增高，种种现象表明可能是服务端的半连接队列、全连接队列中的一个或者全部被打满。主要原理如图10所示：
发现KDC服务所在服务器：半队列/proc/sys/net/ipv4/tcp_max_syn_backlog为2048。
全队列：1）系统参数/proc/sys/net/core/somaxconn＝65535，查看代码listen()函数的传入值为5。
故而判断TCP的瓶颈在于全队列，因此目标为将listen函数的第二个backlog参数变成可控可传入。
开源社区对Kerberos实现的KDC完全没有对外暴露可监控的接口，最初线上的场景主要通过检索Log进行相关指标的监控，在统计服务QPS、各种错误的监控等方面，存在准确准确监控难的尴尬局面。为了实现对KDC准确、较全面的监控，对KDC进行了二次开发，设计一个获取监控指标的接口。对监控的设计，主要从以下三个方面进行了考虑和设计。
任何指标的采集都是随着需求进行变更的，如果程序设计上不具有良好的扩展性，会后续的指标扩展带来很大的困扰。第一版KDC监控指标的采集只区分请求的成功与失败两种类型，美团数据平台KDC库中所有的keytab都具有PREAUTH属性。根据上文可知，去掉PREAUTH属性后，AS请求的QPS能够提升一倍。后续随着服务规模的进一步增长，如果AS请求的处理能力逐步成为瓶颈，会考虑去掉PREAUTH属性。为了准确监控去掉PREAUTH属性这一过程是否有、有多少请求出现错误，需要扩展一个监控指标，因此有了KDC监控的第二版。整个过程只需要修改三个地方，完成两个功能的实现：
整个修改过程简单明了，因此，该KDC监控程序的设计具有非常好的扩展性。图12为监控指标的罗列和注释：
获取KDC监控指标的接口工具主要分为两种：
通过本次对KDC服务的压测实验和分析，总结出KDC最优性能的调整方案为：
相比原来线上单进程的处理能力，目前单台服务器的处理性能提升10+倍以上。本次工作没有详细的论述TCP协议中半队列、全队列的相关参数应该如何设定才能达到最优，和服务本身结合到一起，每个参数的变更带来的影响具体是啥？考虑到TCP本身的复杂性，我们将在未来的文章中详细讨论这个问题。
如果你对如何保证海量数据服务的稳定性、海量服务器大规模运维感兴趣，想亲历互联网大数据的爆发式增长，请和我们一起。欢迎加入美团数据平台大数据SRE组。有兴趣的同学可以发送简历到：chenpengfei#meituan.com。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。