Linux集群技术研究：关键问题与解决方案

建立Linux集群运维平台用户权限管理及日志审计系统，其主要面临并需要研究和解决的关键问题如下。

（一）LDAP Kerberos认证的单点问题解决

Linux集群认证服务的高可用性依赖于LDAP认证服务器和KDC认证服务器的高可用性。笔者认为，可以通过LDAP、KDC服务器的负载均衡来保障认证服务的高可用性。认证服务器的负载均衡策略，最少需要两台物理机器部署负载均衡软件来实现。

使用负载均衡技术的主要目的是保障系统的高可用性。当组成系统的单台机器出现宕机、断网等物理故障时，使用该技术建立的系统不仅不会影响整个系统的可用性，依然还可以使该系统提供正常的服务；在云主机、大规模互联网应用集群的系统可扩展性，即在用户访问数和流量迅速增加时，系统需要扩容来应对这种快速增长；对于互联网网站，其对可扩展性的基本要求就是在保证业务不中断、用户体验不受影响的情况下，透明的扩充容量，整个扩容过程对用户透明，用户不会感知扩容操作。类似的扩容操作可能包括交换机带宽扩充、服务器增减、存储容量增加、服务器内存大小扩充等。

负载均衡服务器之间需要保证每台服务器提供的服务是完全一致的，因此，我们可以通过某种控制策略将用户的访问按照规则分派至不同的服务器，从而保证每个物理机的负载都在比较合理的范围。当整个系统的容量趋于饱和时，通过增加一台同构的物理服务器来解决这个麻烦。增加物理服务器之后，系统的负载情况将重新在所有集群的物理服务器之间按照指定的策略达到新的均衡。

一个完整的负载均衡项目，需要由虚拟服务、故障隔离、失败自动切换三个功能框架来实现。虚拟服务这个名词的得来是从用户的角度看来，似乎是只有一个服务器在提供服务。虚拟服务最主要的功能是实现包转发和负载均衡，这个功能可以通过编写LVS-ipvsadm脚本来实现。一方面故障隔离是指在负载均衡集群中某个真实物理服务器发生故障时，系统需要自动将失效的服务器从转发队列中清理出去，以保证用户访问的正确性；另一方面，在物理服务器故障恢复之后，系统需要自动把它加回转发队列。失败切换是负载均衡器需要实现的策略，在有两台物理服务器提供负载均衡服务的应用场景，当主服务器（一般称为Master Server）失效或者出现故障的情况下，备份服务器（一般称为Slave Server）将自动接管Master Server的工作，在主服务器恢复正常的时候，Master-Slave的对应关系也将自动恢复初始状态。

从技术上实现虚拟服务、故障隔离、失败自动切换，需要配置和使用两个开源工具：LVS和Keepalived。LVS的核心是IPVS（IP Virtual Server），IPVS在大部分Linux发行版本上都是默认安装的，这是整个负载均衡设备的基础。LVS的客户端是指负载均衡系统中的真实物理服务器，通过LVS体系，可以实现的负载均衡策略有直接路由DR模式、网络地址转换NAT模式、隧道模式TUN三种。LVS客户端的配置根据选择的负载均衡策略不同而各不相同。

Keepalived是运行在LVS之上的，主要功能是实现故障服务器的隔离及负载均衡服务器间的失败切换。LVS结合Keepalived，就可以实现4层和7层交换机的基本功能。Keepalived作为LVS的扩展项目，与LVS之间具备良好的兼容性，因此与其他负载均衡软件（如Heartbeat）相比，Keepalived的配置和部署都是最简单的。Keepalived是通过对服务器池对象的实时监控检测，实现对失效机器或服务的故障隔离。负载均衡器之间的失败自动切换，是通过VRRPv2（Virtual Router Redundancy Protocol）Stack实现的。

Keepalived内部结构中，IPVS和NETLINK属于内核空间，Netlink提供高级路由及其他相关的网络功能。如果在负载均衡器上启用Netfilter或者Iptables，会直接影响Netlink的性能。上端属于用户空间，Watchdog负责监控Checkers和VRRP进程的状态，Checkers模块负责检查物理服务器的监控状态，VRRP Stack负责负载均衡器之间的失败切换，IPVSwrapper用来发送设定的规则到内核Ipvs代码，Netlink reflector用来设置虚拟IP地址和管理虚拟IP。

综上所述，为了实现Linux集群运维平台LDAP/Kerberos认证的高可用性，我们至少需要两台物理服务器，通过LVS技术配置虚拟IP，通过Keepalived技术将这个虚拟IP在两台物理服务器之间，任意一台服务器LDAP/Kerberos服务发生故障、服务器宕机或网络故障发生时，均不会影响Linux集群运维平台用户权限管理服务的高可用性。

（二）用户权限认证系统的安全性问题解决

业界流行的LDAP/Kerberos认证方案没有关注认证日志的统一收集分析，认证结果都是存贮于各个客户端服务器本机，这样的设计无法满足认证系统安全性验证和监控的需求。如果能把每台机器的LDAP认证日志和其他相关登录和用户权限的系统日志统一收集到一个关系型数据库，就可以基于数据库进行实时数据监控和可视化展现。

在大多数情况下，LDAP认证日志和系统日志都是保存于本机的文本文件中。这种方式也有优势，存储速度很快，不会存在性能问题。但是，这种本机存储文本文件的方式，显然不能支持日志实时展现和分析监控。为了实时展现及分析，最好的方法就是将数据汇总至中央的关系型数据库。将系统认证日志导入集中的关系型数据库有各种各样的方法，如编写脚本程序，实时读取系统认证日志，并通过TCP/IP协议将数据写入数据库。经过调研，笔者认为可以在Linux集群中每台Linux客户机上部署rsyslogd服务，实时收集LDAP认证日志和认证相关的系统日志，并存入一个集中的Mysql数据库中。Rsyslogd支持多种数据库，考虑到安装配置方便和性能问题，选择Mysql最为合适。

当然，Rsyslogd+Mysql这种收集存储方式也不是完全没有问题，在用户权限验证的请求量持续增加的情况下，Mysql的I/O性能可能会成为瓶颈。数据库的I/O与传统的文本文件单机I/O相比，效率肯定有一定的差别。在Rsyslog收集方案具体实现时，需要考虑使用I/O性能强劲的大磁盘物理机部署中央Mysql，同时上线运行之后，需要根据运行情况对中央Mysql数据库进行性能调优。

Linux集群运维平台用户权限认证服务的安全性，准备通过日志实时分析和监控来保证；计划配置一台Rsyslogd服务器，上面运行Rsyslogd程序以及中央Mysql数据库，客户端所有Linux服务器都配置Rsyslogd服务来替换Linux系统自带的Syslogd服务，将LDAP认证日志和系统其他Syslogd汇总上报至中央Rsyslogd服务器，并在中央服务器上开发实时监控程序及日志汇总展现工具。

（三）海量日志分析的实时性问题解决

海量日志分析有很多难点，主要体现在如下几个方面。

海量日志分散在多台负载均衡服务器、应用服务器、硬件负载均衡设备、防火墙等网络设备上，在Linux集群运维平台日志审计系统中，需要实现对全网日志的统一采集、集中存储和日志分析管理。(www.xing528.com)

日志格式转换问题：常见的日志格式中对于每一条日志应含有的信息包括日期、时间、日志级别、代码位置、日志内容、错误码等信息。由于，各种应用和硬件的日志格式均不统一，如何将各类日志进行统一格式存储，也是需要解决的实时性问题之一。

日志数据深度挖掘问题：在互联网应用每天产生的大量原始日志数据中，大部分是属于非关键性的信息，如何对信息进行整理过滤并提取出有价值的事件信息，并以标准的格式进行汇总，这些都是本书重点研究的问题之一。

日志量巨大，关系型数据库的插入、查询性能已经不能满足实时查询的需求，单机进行grep/awk等日志脚本查询也很难在短时间得到结果。

针对海量日志来源分散且日志格式各异的问题，需要采用一套统一的收集框架，支持各种日志来源和日志格式，比如使用开源软件Fluentd进行日志收集（GITHUB地址github.com/fluent）。Fluentd是一套开源的日志收集系统，它的特点是各部分均可定制，包括输入层插件、过滤层插件、输出层插件；可以方便地基于Fluentd系统进行插件开发，针对负载均衡服务器、应用服务器、安全类日志进行Fluentd输入插件开发，将日志以各种输入形式传入Fluentd中；针对各种类型的日志，不同的过滤方式也需要二次开发，针对性地选择需要关注的日志字段，丢弃无保存价值的原始日志；Fluentd默认会将数据打包为JSON格式，输出至指定的数据存储后台。

海量日志实时分析对数据存储后端提出了很多要求：数据读写速度必须保持很低的延迟，否则最新产生的日志无法得到实时处理；能够支持海量的数据和流量，单台服务器每天处理的日志量可能会在10TB以上；存储后端能够方便的水平扩展，在不投入大量硬件成本和人力维护成本的前提下满足业务需求的快速变化和流量及数据量的快速增长。

日志导入关系型数据库可以方便地进行模糊查询、计数、去重等统计操作，但在海量日志实时分析的应用场景，传统的关系型数据库性能存在瓶颈，需要大量空间建立索引才能满足查询的性能需求，这对硬件资源有限的互联网公司来说是一大挑战。关系型数据库虽然已经在业界的数据存储方面占据了不可动摇的地位，但由于其自有的几个限制，在海量日志实时分析这个应用上已经存在明显缺陷。关系型数据库的扩展比较困难，由于存在类似Join这样的多表查询机制，使数据库很难水平扩展；在数据量达到一定规模时，关系型数据库的系统逻辑会非常复杂，比较容易出现死锁等并发的相关问题，导致关系型数据库的读写速度迅速下滑；成本高昂，企业级数据库解决方案的License价格也非常惊人，对互联网公司这类流量和规模增长迅速的公司而言，很难每年留出足够预算做数据库License和硬件的采购。

业界为了解决上文提出的问题和需求，已经推出了多款新型的数据库，在设计上和传统的关系型SQL数据库相比有很大的不同，它们被统称为“NOSQL”数据库。总体上，它们非常关注数据高并发读写和对海量数据的存储等；与关系型数据库相比，它们在架构和数据模型方面做了减法，在扩展和并发方便做了优化。主流的NOSQL数据库有BIGTABLE、HBASE、Cassandra、CouchDB、MongoDB和Redis等。

我们在选择使用Fluentd/Mongodb作为海量日志实时分析处理的解决方案之前，首先选择的是SHELL脚本进行本机分析，分析后将计算结果统一入库的方案。Linux环境下的SHELL脚本、grep命令、AWK脚本、sed脚本等均是传统的Linux管理员进行日志分析的利器。这个方案的优点是实现快，运维工程师们都有着良好的SHELL脚本编程基础，对单机日志进行分析的脚本几小时就可以开发完成，一周内就可以完成日志实时分析平台的上线。但这个方案的致命缺点是不够灵活。

Fluentd过滤出的JSON格式数据可以不经过处理直接存入Mongodb，这样收集端和存储端可以无缝结合。而且Mongodb的cappedcollection特性也为我们对过期数据的清理提供了自动解决方案。

（四）海量日志安全性审计方案确定

互联网行业如果Linux集群分布在多个IDC机房，机房之间互联互通的网络结构也会比较复杂；在考虑集中式的数据分析背景下，业务需求的集中带动数据和应用部署的集中，数据中心的应用系统和数据规模会越来越大，运维管理的复杂度也会越来越高，尤其对于安全管理人员来说，需要定期分析各种设备、各种应用所产生的日志，在实际操作中会遇到很多问题。

日志采集问题：Linux集群中各类硬件设备种类繁多，每天都会产生海量的日志，且分散在各地IDC系统中，如何有效采集这些原始日志并集中管理、分析是其核心问题。

安全决策问题：对于众多日志信息，除了日志记录的汇总之外，如何对安全性日志进行分析和挖掘，并在日志分析的基础上建立安全性监控指标，辅助决策符合内部外部审计需求问题；对海量日志如何进行有效管理，以利于事后事件分析，审计取证，满足互联网行业监管的合规要求。

海量的日志靠安全管理员人工的审计已经不切实际，个人能力再强、工作再努力，也不可能一项一项地对日志进行检查，更别说进行安全性审计分析。而且随着互联网行业技术方面的飞速发展，高水平的黑客数量也越来越多，系统本地的日志很有可能是被黑客篡改的甚至直接删除的。Linux集群运维平台中的日志审计系统就迫切需要解决这个问题。

安全管理员需要一个高度集中统一管理的日志审计平台。这个平台必须能在复杂的网络和系统环境中高效收集和管理各类设备的日志，让运维安全管理员方便且直观地看到网络和系统目前的运行状态，是否存在入侵和安全漏洞。当黑客攻击发生时，日志审计系统能够及时地发现。

针对安全日志审计的需求，我们首先需要建立安全日志过滤机制，将无关安全性的日志过滤之后，对可能与安全相关的日志进行详细的分析，并定期根据收集分析的结果调整过滤方案。