前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >海量服务器安全高效管控系统设计

海量服务器安全高效管控系统设计

作者头像
鹅厂网事
发布2018-02-05 16:45:06
1.9K0
发布2018-02-05 16:45:06
举报
文章被收录于专栏:鹅厂网事鹅厂网事

"鹅厂网事"由深圳市腾讯计算机系统有限公司技术工程事业群网络平台部运营,我们希望与业界各位志同道合的伙伴交流切磋最新的网络、服务器行业动态信息,同时分享腾讯在网络与服务器领域,规划、运营、研发、服务等层面的实战干货,期待与您的共同成长。 网络平台部以构建敏捷、弹性、低成本的业界领先海量互联网云计算服务平台,为支撑腾讯公司业务持续发展,为业务建立竞争优势、构建行业健康生态而持续贡献价值!

一 背景

现代互联网企业伴随着业务的不断高速增长,服务器总数及系统维护人员也不断增加,分布在全球各地的IDC数量及类型也日益增多,因此对海量多IDC环境下的服务器集中管理将带来一系列的挑战,同时对“机器数/人”运维成本的控制也将迎来更高的要求。

公司在发展过程中,业务亦日渐增多,因此大量的运维、发布、变更等 系统也是需要同步配套建设,其实这些运维类的系统有很大的共通性,完全可以按照分层服务原则,一层一层向上提供抽象服务,然后整个公司依据这些服务实现一系列标准化平台即可。有了这些类似IAAS、PAAS的标准运维抽象服务,企业就可以整合优化各种自动化运维工具及平台,让系统代替人工操作,并逐渐规范化、高效化、并行化、智能化,最终很多重复性人工运维工作全由系统一站式自动完成。

鉴于以上种种原因,我们需要一个基于海量多数据中心基础架构系统的 分布式底层服务器管控系统,用户只需要提交最终操作服务器的目的IP,该系统帮助用户自动实现所有的管控服务请求,譬如文件推送、远程执行、配置信息同步等。

二 需求

2.1功能需求

实现服务器的状态采集、配置管理、软件发布等运维对底层通道的关键路径,主要是模板语言支持自定义逻辑组合、稳定高效传输文件、实时远程执行及回显,再辅以完善的配套运营支撑和数据分析平台搭建。

  • 模板语言支持自定义逻辑组合

通常来说要执行一个上层任务不仅仅是需要简单地登录服务器执行一条命令,而是一系列复杂的逻辑组合,譬如一个任务需要执行多条命令,下一条命令与上一条命令有依赖关系,需要根据上一条命令的结果来决定如何执行下一条,甚至涉及到跨服务器的任务协调,譬如B机器执行依赖A,A又依赖于B;这就需要在底层通道定义一种模板语言,这个模板语言支持类似编程语言的固定语法,并且里面的变量具备正则表达式的通配功能。

模板语言的语法可以定义管控任务的复杂逻辑,假设语法为“A;B;{if (B OK) 继续;否则中止任务};{[C1][C2][C3]};D”,其中分号表示自然顺序执行,{[][]}表示并发执行,里面C1、C2、C3同时执行,并有一个全部执行完毕的同步点,同步点之后将执行最后一个步骤D;正则表达式可以匹配不同的文件名,这在传输文件的特殊场景特别有用,比如用户想拉取某游戏的全部服务器日志文件,正则表达式文件变量名为gamsvr[0-9]{1,3}.log([0-9]{1,3}正则表达式表示000-999的数字编号),则使用正则表达式可以轻松拉取到想要的全部服务器上日志文件。

变量要还支持时间宏(执行时动态替换成当前的时间)、IP宏、单号宏、随机数字宏的定义,这在定义真实的任务时非常有用,譬如时间宏例子/pullbacksever/[currentday]/gamesvr.log 可以让自动拉取文件任务在文件服务器上将拉取到的文件按时间分类,比如每天自动创建2015-??-??目录,然后将拉取到的文件自动放到该目录,IP宏、单号宏和随机数字宏作用类似,不再赘述。

  • 稳定高效的文件传输

在海量的服务器运营中,通常有业务需要同时向分布在全球各地的数千台服务器下发某个配置或者更新某个文件;此时就需要稳定高效的文件传输,在某些典型的业务中,这个文件传输能力需要达到6 G bytes/s才能满足业务需求。

除了具备快速的文件分发能力,系统还要保证文件传输的可靠性,保证不误传,因此要在传输文件的源端和目的端进行文件内容校验,确保两端文件完全一样。

在实际运维或发布等业务中,对文件传输的需求形式是多样的,包括单个文件、整个目录、以及正则表达式过滤的目录的传输,在对目录进行传输时系统支持智能自动压缩,以节省网络传输带宽。

在DB备份数据同步等业务中,几百G甚至上T的单个文件传输很正常,因此本系统传输的文件或目录大小不应受程序限制,只受限于实际接收端磁盘的容量大小。

  • 实时远程执行及结果回显

服务器分多种操作系统,典型的为linux和windows两大类,linux和windows在可执行程序的管理上有着很大的区别,linux是使用文件属性来标识,windows是使用文件后缀来标识。常见的linux执行程序有elf、sh、phython、perl等、常见的windows执行程序后缀有exe、bat、psl等,如果windows安装了cygwin环境,也可以执行linux的sh等脚本。

本系统应该支持服务器操作系统的所有类型的程序的远程执行,用户执行程序时只需要输入文件名,不再需要指定操作系统名称,系统能够自动甄别并调用相应的方式远程执行。

程序执行一般有屏幕输出和返回码,本系统支持将远程执行的屏幕回显及返回码传送回用户,为了有良好的交互体验,要求屏幕回显是实时传回,而不是一个小时执行完毕后一次性传回。

和文件传输功能需求一样,本功能也要求高度并发执行,可以高效地在分布在全球各地的数千台服务器快速远程执行某命令,然后实时传回这些任务的执行结果。

远程程序执行还要求64位系统能对32位程序进行兼容,这个是由操作系统来保证的,目前所有的64位linux和64位windows系统都是可以兼容32位程序执行的。

  • 完善的运营支撑系统及数据分析

本系统作为通用的底层管控服务平台,整个公司内任何用户和业务均可以无差别地调用相关服务,来实现对服务器的控制,因此每天产生的数据类型较多,数据量亦相当可观,估计达几十G bytes/天,里面蕴含着丰富的商业价值,对这些海量数据进行深层次的数据挖掘和分析,对服务器运营的决策有着重要的意义。

同时,为了对平台自身实现更为完善的运营管理,也需要一个完备的运营支撑平台,以实现全面的运营管理,包括统计、趋势分析、容量管理、监控告警、自动化变更、平台自身管理等基础性平台功能,为平台的长期持续稳定运营作基础。

2.2质量需求安全性

近年来互联网公司总是成为不法分子攻击的首要目标,地下产生了一系列完整的黑产利益链条,近几年更是频繁爆发出各种与互联网公司相关的安全事件,比如用户密码库泄露、DDOS攻击、域名劫持、网上诈骗等,这些都直接影响了广大民众上网的用户体验、线上交易以及个人隐私和财产的安全。因此,本系统的安全性成为首要的质量需求。

整个外层通信链路要进行数据加密,以防止数据在传输中被窃取,对于关键的信息,如机器密码等需要在外层加密下进行二次加密,以提高破解难度。

系统需要严格的无安全漏洞的鉴权模式,相应的用户具备相应的权限,比如user00用户只能查看/home/user00目录,绝对不能查看/ root目录,在linux上如果文件不具备可执行权限,本系统也是不可以执行的。

除此以外,系统还支持完整数据对帐、进程模块不可伪造、数据包不可代理、操作指令时效性控制、实时安全监控等安全特性的实现。

可靠性

系统所有重要节点机器完全本地和异地双保险容灾设计,在单机故障时能迅速切换到本地的备份机器上,即使在发生地震、火山等不可抗力自然灾害导致整个机房不可用的情况下,亦能快速切换到异地城市备份系统继续提供服务。

整个系统具备很强的容错能力,保证后台进程不会因为各种错误数据输入、机器环境突然变化、硬件故障导致数据混乱和服务长期不可用。

除此以外,还要求后台进程能长期稳定地健壮运行,无性能衰减或衰减缓慢;为了以防万一,系统还要具备快速重启能力,以应付突发事件。

高性能

考虑到本系统的集群规模,为了在规模和成本之间取得较好的平衡和收益,系统必须具备很高的性能,否则失去竞争力和存在的意义。

本系统设计的管理机器数可达100万级,单任务可以高效并发操作几万个ip,并且在几秒内返回结果。

系统完全具备多任务并行处理,日处理操作数能力达10亿次,日均传输文件能力达3P bytes。

系统还要具备良好的使用效率,充分利用模块混搭策略,最大化利用机器的CPU、内存、硬盘、IO等资源,以总体控制机器数成本。

可升缩、可扩展

可升缩性是分布式系统设计的基本要求,本系统作为超大规模的海量分布式系统,可升缩性更彰显重要。

系统完全基于scale out思想设计,弹性升缩,可以根据业务需求动态上线、下线集群节点机器扩缩容,系统容量和集群机器数量成正比,理论容量几乎无极限。

我们还应从成本、效率上考虑,本系统的升缩能力具备低成本、反应迅速的特点,在紧急增加或减少大量集群节点机器时,只需要运维人员做少量配置即可快速完成,不需要发布部署、数据库变更等重量级操作。

本系统提供原子的、可编程化的接口,接口内容包括文件推送拉取、远程执行及相关组合,提供 CMD和RESTFUL多种风格,且完全开放。上层运维、发布、自动化编译等平台可基于本系统接口直接进行业务场景开发,上手容易且大幅节约开发成本。

本系统架构上预留一系列扩展点,后期扩展新功能容易,只需要对代码作少量修改即可。

跨平台、用户体验良好

支持当前各种主流的linux、windows版本操作系统,包括32位和64位系统。 对于linux和windows,支持二进制兼容,同类型的操作系统一次编译,任意部署。

系统在架构时充分考虑跨平台性,在其它如MAC OS、AIX等类unix操作系统上重新编译agent源程序即可支持。

系统对用户屏蔽一切调度及路由复杂性,最终用户只需要输入“操作IP+做什么”即可,不用关心其它细节。系统的任务预处理、智能调度及路由计算均由程序自动计算完成,服务器上的agent程序以及全局静态路由配置由系统运维人员维护,这些都对用户完全透明,用户在任一一台交付的服务器上都是可以直接使用的。

三 实现难点及解决方法

3.1安全实现

作为互联网公司的底层的管控服务平台,直接掌管互联网公司数十万台机器的安全命脉,因此安全是设计目标的重中之中,系统安全设计必须混合多种安全策略,在多个维度保证系统绝对安全。

系统安全设计时,应该采取不信任原则,每个节点都考虑了被监听,被代理,被劫持,被伪装请求的可能性。

同时,本系统设计时还采取权限最小化原则,刚上线的系统各种安全权限是最小的,随着实际的线上运营才逐渐将安全权限放宽,并且中间扩容要通过严格的审批流程。

系统具备整个数据流上的完整数据对账能力,并实时监控数据对账的异常;系统还对所有的节点进行实时安全监控,譬如用户在接入机提交的任务有无rm危险字符、 agent接收到的任务指令有无reboot危险字符等、黑客攻击行为实时分析等。

在数据链路的设计上,整个外层通道都使用SSL加密,对主机密码等敏感字段使用3des+自定义算法混合进行高强度的二次加密,对主机进行鉴权时默认使用OS自带的鉴权模块,linux使用大多数发行版都支持的pam增强鉴权模块,windows使用原生winlogon技术,除此以外还要考虑一定的灵活性,可以以插件形式支持LDAP等更严格的验证方式,以增强鉴权的安全性。考虑到互联网公司的实际情况,建议使用linux+openssl实现外层通道的ssl加密。

linux系统鉴权与传统的unix安全系统类似,一句话,我的系统我作主,没有我的密码,即使目标机器被植入了 agent,什么事情也干不了,即使知道了机器的一个低权限的用户名和密码,还是无法使用这个通用底层操控通道(如果是非法用户,只能绑架超级管理员才可以)删除/root下的文件,它是属于root的。

Windows鉴权也保持与Windows权限系统的一致性,在不同的安全配置、文件系统上,如UAC(User Account Control,用户账户控制)、FAT32文件系统、NFTS文件系统都与windows系统有着一致的安全鉴权行为。

3.2网络环境复杂

大型互联网公司的内部网络结构非常复杂,分布全球各地的各个机房,有自建的,有租用的,有实体的,甚至还有虚拟的,如aws虚拟IDC等。各种风格迥异的网络技术架构,各种网络连接和数据中转技术的应用,如专线租用和V**隧道等,各种防火墙策略和安全屏障的设置,太多的多元化形态呈现在我们面前,这对我们要统一集中管理这些网络上的服务器带来了巨大的挑战。

理想的网络是扁平化的,就算百万级别节点的集群也是任意两点之间都是相通而且宽带均等的,但是缘于网络技术实现的难度以及各公司为了安全和管理的需要,总是人为地将大网络分割成多个子区域,并且设置各种安全屏障,因此考虑到实际应用价值,本系统需要完全支持非扁平化网络的集中管理。

因此我们需要将不同类型和安全防护级别的机房用一树形拓扑集中管理;支持级联管理;支持内网和外网等多种模式组网;支持堡垒机及跳板机穿透;支持特殊机房的管理; 支持跨越不同运营商外网时传输加速。

级联管理其实就是同样是agent属性的机器管理其它agent机器,可以多层嵌套管理。为了支持这种级联的自管理,每个agent除了充当业务agent角色外,本身还是一个代理程序,可以将数据包转发给其他agent;在底层连接协议中,应该支持对一个IP链表的连接,比如CONN IP1:IP2:IP3,在连上IP1以后,自动修改连接串为CONN IP2:IP3,依此类推,直至最后一个IP连接成功。

3.3集群规模

现代互联网公司服务器规模一般介于10-100万之间,为了降低服务器管理成本需要集中统一管理,因此本系统本质上就是建设一个超大规模的集群系统。

当集群规模达到100万时,显然不能用常规的master-slave两层设计思想,必须使用master-zone_master-slave的三层分区管理设计,甚至四层或更多,还要融合级联的管理能力。

使用这种类似“中央-省-县”行政区域的管理模式带来一系列好处,zone_master大多数事务是自治的,自行管理和决策,只是很重要的信息才上报给master;反之master也只给zone_master下达任务描述等很关键的信息,任务执行后,各zone_master只需要向master报告总体的任务执行情况即可,这样设计可以大幅减少网络通信传输,提升了整个系统控制能力。

3.4调度算法复杂

对于如此超大规模的集群系统,必然伴随着各种信令、数据的分发及流向,对于不同的信令和数据我们又要兼顾不同的实时性、吞吐量及可靠性。

信令本系统中的信令主要用于控制系统自身,比如上报节点的版本、存活信息,调整服务权重、广播各节点配置信息等。信令分不可丢失信令和可丢失信令两种,信令的特性是数据量小,但是实时性要求高,要尽快送到目标。对于可丢失信令,可以多次重复发送,最终目标端将收到该信令。化整为零平摊算法直接将针对全网的控制信令拆分到IDC内部的jobsvr,由所有jobsvr共同分摊执行信令,因此执行响应迅速。

数据本系统中的数据主要用于下发任务及返回任务的执行结果,数据传输量很大,但是实时性要求不高,数据不可丢失,要保证一定送达。加权最优算法因为网络不是扁平的,任务执行时依赖条件较多,当一个任务里的一批机器能被多个jobsvr同时调度时,系统总是选取最优秀的jobsvr执行任务;如果一个合乎执行条件的jobsvr也没有,应该报执行失败的错。

自动拆单算法当用户提交的任务单直接包括多个IDC时,是无法被同一个jobsvr执行的,系统应该自动拆成多个子单处理,此过程对应用编程接口、对用户完全透明。

3.5路由管理

大型互联网企业IDC管理网络(全局视点)是一个超级复杂、内外网混合、多种安全策略应用、需多次穿透代理等的立体式网状网络。

IP路由技术不能解决本系统所面临的困境,我们必须在软件应用层面想办法解决这个问题。

设计上可以使用DB持久化存储网络拓扑关系,并使用读cache缓存网络拓扑关系提高性能。同时采用预先申明路由策略与自动路由信息探测相结合的方法管理网络拓扑结构。Master负载均衡时以预先申明路由信息为主,同时考虑实时路由信息权值进行下发任务。

这种动静结合的方式能很好地解决超复杂的树形网络的管理及路由分发问题,同时又使得系统拓扑处于绝对地可控状态,不会引发泛洪、雪崩等非中心化集群系统可能存在的风险。

四 腾讯实践

腾讯公司根据自身的需求,于几年前启动了Tencent System Controller(简称TSC)项目,通过几年的优化及运营,基本实现了上述系统的各个设计目标。

TSC是一个面向海量多数据中心服务器的基础架构系统(IAAS)、且通用、开放、易扩展、高效及稳定的分布式底层操控通道,使用了诸多如多层分布式、企业服务总线、任务抽象、并行处理、业务描述语言等业界流行的、前沿的设计技术。操控的设计目标以X86服务器主机为主,包括公司的各种Linux、Windows平台。

TSC已稳定运营多年,直接为腾讯公司内各个基础架构平台、自动化作业平台、自动化运维及编译发布平台等提供了大量高效稳定的基础管控服务,为服务器变更的安全保驾护航,大量的一线运维人员直接使用TSC工具批量运维自己名下机器,也极大地提升了运维生产力。

注1:凡注明来自“鹅厂网事”的文字和图片等作品,版权均属于“深圳市腾讯计算机系统有限公司”所有,未经官方授权,不得使用,如有违反,一经查实,将保留追究权利; 注2:本文图片部分来至互联网,如涉及相关版权问题,请联系judithliu@tencent.com

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2015-06-03,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 鹅厂网事 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一 背景
  • 二 需求
    • 2.1功能需求
      • 2.2质量需求安全性
        • 可靠性
        • 高性能
        • 可升缩、可扩展
        • 跨平台、用户体验良好
        • 3.1安全实现
    • 三 实现难点及解决方法
      • 3.2网络环境复杂
        • 3.3集群规模
          • 3.4调度算法复杂
            • 3.5路由管理
            • 四 腾讯实践
            相关产品与服务
            负载均衡
            负载均衡(Cloud Load Balancer,CLB)提供安全快捷的流量分发服务,访问流量经由 CLB 可以自动分配到云中的多台后端服务器上,扩展系统的服务能力并消除单点故障。负载均衡支持亿级连接和千万级并发,可轻松应对大流量访问,满足业务需求。
            领券
            问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档