营销型网站是通过对网,wordpress与saas,wordpress 微信发布文章,html5视频教程背景 Kerberos 是一种网络认证协议#xff0c;其设计目标是通过密钥系统为客户端、服务器端的应用程序提供强大的认证服务。 作为一种可信任的第三方认证服务#xff0c;Kerberos是通过传统的密码技术#xff08;如#xff1a;共享密钥#xff09;执行认证服务的#xff… 背景 Kerberos 是一种网络认证协议其设计目标是通过密钥系统为客户端、服务器端的应用程序提供强大的认证服务。 作为一种可信任的第三方认证服务Kerberos是通过传统的密码技术如共享密钥执行认证服务的被Client和Server同时信任。KDC是对该协议中第三方认证服务的一种具体实现一直以来都是美团数据平台的核心服务之一在Hive、HDFS、YARN等开源组件的权限认证方面有着广泛的应用。该服务将认证的密钥事先部署在集群的节点上集群或者新节点启动时相应节点使用密钥得到认证。只有被认证过节点才能被集群所接纳。企图冒充的节点由于没有相关密钥信息无法与集群内部的节点通信从而有效的确保了数据的安全性、节点的可信赖性。 但随着平台业务的快速增长当前线上KDC的处理能力不足和不能可靠监控的问题被凸显的日益严重线上单台KDC服务器最大承受QPS是多少哪台KDC的服务即将出现压力过大的问题为什么机器的资源非常空闲KDC的压力却会过大如何优化优化后瓶颈在哪儿如何保证监控指标的全面性、可靠性和准确性这都是本文需要回答的问题。从本次优化工作达成的最终结果上来看单台服务器每秒的处理性能提升16倍左右另外通过共享内存的方式设计了一个获取KDC各项核心指标的接口使得服务的可用性进一步提升。 为方便大家表1总结并解释了本文中后续会涉及到一些专业名词的简称 图1为美团数据平台KDC当前服务架构目前整个KDC服务部署在同一个IDC。 KDC原理介绍 Client、 KDC和Server在认证阶段主要有Client和KDC的AS、Client和KDC的TGS以及Client和Server的交互三个过程下文将详细介绍三个过程的交互其中图2中的步骤1和2、3和4、5和6分别对应下文的A、B、C三部分 A. Client和AS的交互 用户以明文的形式发送自己的信息、以及想要申请的TGT Principal默认为KDC的TGTkrbtgt/REALMREALM等信息给AS服务AS服务验证该用户信息存在数据库中后给客户端返回两大块信息 使用用户的密钥加密其申请的TGT和一个Session Key返回用户,用户得到加密信息后使用自己密钥解密得到其申请的TGT和Session Key后续都简称 SKCandK。以KDC自身密钥加密用户申请的TGT、SKCandK、用户自己信息等简称{TGT}Ktgs该部分信息被Client保存在本地。B. Client和TGS的交互 Client访问TGS获取访问网路中某一Server的ticket请求。Client端会把第一部分中保存在本地的{TGT}Ktgs和用SKCandK加密的客户端信息发送KDC的TGS模块TGS收到请求后检查请求Server存在数据库中后用自己的密钥解密得到TGT中的SKCandK然后便可以解密得到用户的信息并验证其合法性通过后TGS会生成一个新的Session Key简称SKCandS同时返回两部分信息 用SKCandK加密的SKCandS、能够访问Service的ticket等信息。用Service密钥加密的Client info、SKCandS等信息简称{ TService }KService。C. Client和Server的交互 Client拿到访问Service的ticket后向Service发起请求同时将两部分信息发送给Server1通过SKCandS加密的Client info等信息。2第二部分TGS返回客户端的{ TService }K Service 1Server端收到Client的请求信息后用自己的密钥解密获取到TService信息就能够解密SKCandS加密的客户端信息和TService中的客户端信息进行对比通过后整个KDC认证过程结束Client和Service进行正常的服务通信。主要优化工作 通过对KDC原理的分析很容易判断只有前两部分才可能直接给KDC服务带来压力因此本文涉及到的工作都将围绕上一部分的前两个环节展开分析。本次优化工作采用Grinder这一开源压测工具分别对AS、TGS两个请求过程采用相同机型保证硬件的一致性在不同场景下进行了压力测试。 优化之前线上KDC服务启动的单进程为最低风险的完成美团和点评数据的融合KDC中keytab都开启了PREAUTH属性承载KDC服务的部分服务器没有做RAID。KDC服务出现故障时机器整体资源空闲怀疑是单进程的处理能力达到上限PREAUTH属性进一步保证提升了KDC服务的安全性但可能带来一定的性能开销如果线上服务器只加载了少量的keytab信息那么没有被加载到内存的数据必然读取磁盘从而带来一定的IO损耗。 因此本文中对以下三个条件进行变动分别进行了测试 对承载KDC服务的物理机型是否做RAID10请求的keytab在库中是否带有PRAUTH属性KDC是否启动多进程多进程设置数目和物理机核数一致。实际测试工作中进行了多次测试A. Client和AS交互过程的压测 表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且 BA 图中黄色区域为排队的请求数当某一请求排队超过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获取自己服务器的时间戳并用自己的密钥加密发送KDCKDC解密后和自身所在服务器的时间进行对比如果误差在能容忍的范围内返回给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结果一致。 B. Client和TGS交互过程的压测 表3为TGS压测的一组平均水平的测试数据 分析表3中的数据可以发现KDC对TGS请求的处理能力和主机是否做RAID无关,结合KDC中TGS的请求原理就较容易理解在BDB缓存命中率足够高的条件下TGS的请求不需要和本次磁盘交互进一步做实验也充分验证了这一点机器的磁盘IO在整个测试过程中没有大的变化如图9所示操作系统本身偶尔产生的IO完全构不成KDC的服务瓶颈。KDC单进程多进程的对比其处理瓶颈和AS一致均受到CPU处理能力的限制单进程打满某一CPU多进程几乎占用整台机器的CPU资源。从Kerberos的设计原理分析很容易理解无论KDC库中的keytab是否带有PREAUTH属性对TGS的处理逻辑几乎没有影响压测的数据结果从实际角度验证了这一点。 C. 其他问题 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/somaxconn65535查看代码listen()函数的传入值为5。 故而判断TCP的瓶颈在于全队列因此目标为将listen函数的第二个backlog参数变成可控可传入。 KDC可监控的设计和实现 开源社区对Kerberos实现的KDC完全没有对外暴露可监控的接口最初线上的场景主要通过检索Log进行相关指标的监控在统计服务QPS、各种错误的监控等方面存在准确准确监控难的尴尬局面。为了实现对KDC准确、较全面的监控对KDC进行了二次开发设计一个获取监控指标的接口。对监控的设计主要从以下三个方面进行了考虑和设计。 A. 设计上的权衡 监控的设计无论在什么场景下都应该尽可能的不去或者最小程度的影响线上的服务本文最终采用建立一块共享内存的方式记录各个KDC进程的打点信息实现的架构如图11所示。每个KDC进程对应共享内存中的一块区域通过n个数组来存储KDC n个进程的服务指标当某个KDC进程处理一个请求后该请求对监控指标的影响会直接打点更新到其对应的Slot 数组中。更新的过程不受锁等待更新的影响KDC对监控打点的调用仅仅是内存块中的更新对服务的影响几乎可以忽略不计。相比其他方式在实现上也更加简单、易理解。纪录每个KDC进程的服务情况便于准确查看每个进程的对请求的处理情况有助于定位问题多种情况下出现的异常缩短故障的定位时间。例如能够准确的反应出每个进程的请求分布是否均匀、请求处理出现异常能够定位到具体是某个进程出现异常还是整体均有异常。 B. 程序的可扩展性 任何指标的采集都是随着需求进行变更的如果程序设计上不具有良好的扩展性会后续的指标扩展带来很大的困扰。第一版KDC监控指标的采集只区分请求的成功与失败两种类型美团数据平台KDC库中所有的keytab都具有PREAUTH属性。根据上文可知去掉PREAUTH属性后AS请求的QPS能够提升一倍。后续随着服务规模的进一步增长如果AS请求的处理能力逐步成为瓶颈会考虑去掉PREAUTH属性。为了准确监控去掉PREAUTH属性这一过程是否有、有多少请求出现错误需要扩展一个监控指标因此有了KDC监控的第二版。整个过程只需要修改三个地方完成两个功能的实现 添加指标 打点逻辑的添加。整个修改过程简单明了因此该KDC监控程序的设计具有非常好的扩展性。图12为监控指标的罗列和注释 C. 接口工具kstat的设计 获取KDC监控指标的接口工具主要分为两种 获取当前每个KDC进程对各个指标的累积值该功能是为了和新美大的监控平台Falcon结合方便实现指标的上报实现累加值和分钟级别速率值的处理获取制定次数在制定时间间隔内每个进程监控指标的瞬时速率最小统计间隔可达秒级方便运维人员登陆机器无延迟的查看当前KDC的服务情况使其在公司监控系统不可用的情况下分析服务的当前问题。具体使用见图13 。 总结 通过本次对KDC服务的压测实验和分析总结出KDC最优性能的调整方案为 KDC服务本身需要开启多进程和以充分利用多核机器的CPU资源同时确保BDB的内存资源足够保证其缓存命中率达到一定比例越高越好否则查询库会带来大量的磁盘读IO选择的物理机要做RAID否则在库中keytab带有PREAUTH属性的条件下会带来大量的写容易导致磁盘成为KDC的性能瓶颈。通过建立一块共享内存无锁的实现了KDC多进程指标的收集加上其良好的扩展性和数据的精确性极大的提高了KDC服务的可靠性。相比原来线上单进程的处理能力目前单台服务器的处理性能提升10倍以上。本次工作没有详细的论述TCP协议中半队列、全队列的相关参数应该如何设定才能达到最优和服务本身结合到一起每个参数的变更带来的影响具体是啥考虑到TCP本身的复杂性我们将在未来的文章中详细讨论这个问题。 参考文档 http://blog.csdn.net/m1213642578/article/details/52370705http://grinder.sourceforge.net/http://www.cnblogs.com/Orgliny/p/5780796.htmlhttp://www.zeroshell.org/kerberos/Kerberos-operation/http://blog.csdn.net/wulantian/article/details/42418231作者简介 鹏飞美团基础数据部数据平台大数据SRE组离线计算组SRE负责人2015年11月加入美团。招聘信息 如果你对如何保证海量数据服务的稳定性、海量服务器大规模运维感兴趣想亲历互联网大数据的爆发式增长请和我们一起。欢迎加入美团数据平台大数据SRE组。有兴趣的同学可以发送简历到chenpengfei#meituan.com。
