标签：水平 开始 行业 进入 磁盘 访问控制 批量管理 开源软件 跳板
由于要申请运维管理机器资源，应领导要求要写一个方案出来，今天就分享一下我写的一篇运维管理架构方案，很多内容都是来自官网和网上找的，不过还好公司领导已经通过了。由于以前从来没写过运维方面的方案，自认为文字水平也很一般，所以写的不好请见谅，希望大家能多给些建议，共同提高！传统运维管理方式即是对服务器的操作全部都是手动，手动安装系统、手动部署应用、手动更新等，随着信息化科技的不断发展，各种应用系统的不断推出，服务器数量的不断增加，运维人员的良莠不齐，从而暴发出越来越多运维管理上的缺陷，导致运维事故频发，主要存在以下问题：
（1）用户身份不唯一，运维人员通过统一的账号和密码登陆设备（服务器），无法准确识别用户的身份。
（2）缺乏严格的访问控制，任何人登陆到其中一台设备后，就可以访问所有设备。
（3）大量账号和密码的管理工作，大大降低了工作效率的同时，运维人员的流动还会存在密码外泄的风险。
（4）无法管控运维人员登陆到设备后的操作权限。
（5）无法知道运维人员的操作是否违规、是否存在风险，缺乏有效的技术手段来监管运维人员的操作。
（6）操作无审计，事故发生后无法快速定位事故原因和责任人。
（7）账号和密码存在安全隐患，×××/恶意访问有可能获取到系统权限，从而造成不可估量的损失。
（8）成百上千台服务器，通过手动方式一台一台部署、更新，运维效率大打折扣。
（9）服务器发生故障或者业务系统出现问题，运维人员无法第一时间知道，从而无法快速排查问题、快速处理故障、快速恢复业务。
（10）以传统的方式登陆到服务器上查看应用日志，效率低下不说，还无法对日志做出有效的处理和分析。
运维操作不规范，运维操作不透明，运维操作不可控，运维工作效率低下，一次又一次地将运维人员推向风口浪尖。
由于上述问题的不断出现，各大中小型企业对运维管理逐渐的重视起来，之后cacti、nagios、zabbix等开源监控工具出来了，2000年左右跳板机概念出现在了人们眼前，2005年前后在跳板机的基础上应运而生了堡垒机概念，然后伴随着saltstack、ansible等自动化运维管理工具的出现，使运维管理工作向自动化迈进。此时各大企业纷纷在saltstack、ansible等工具的基础上进行二次开发，推出自己的自动化运维管理平台，运维管理工作正式进入自动化时代。
如何让运维操作规范、可控、透明化？-堡垒机/跳板机系统
如何第一时间发现故障问题，从而快速排查处理问题？-监控报警系统
如何管理大批量服务器，实现批量分发、批量部署、批量更新？-自动化运维管理工具
如何集中管理服务器日志，并对日志进行可视化分析、检索？-集中式日志分析平台
什么是堡垒机？什么是跳板机？为什么要部署堡垒机/跳板机？
跳板机：跳板机属于内控堡垒机范畴，是一种用于单点登陆的主机应用系统。2000年左右，高端行业用户为了对运维人员的远程登录进行集中管理，会在机房里部署跳板机。跳板机就是一台服务器，维护人员在维护过程中，首先要统一登录到这台服务器上，然后从这台服务器再登录到目标设备进行维护。但跳板机并没有实现对运维人员操作行为的控制和审计，使用跳板机过程中还是会有误操作、违规操作导致的操作事故，一旦出现操作事故很难快速定位原因和责任人。此外，跳板机存在严重的安全风险，一旦跳板机系统被攻入，则将后端资源风险完全暴露无遗。同时，对于个别资源（如telnet）可以通过跳板机来完成一定的内控，但是对于更多更特殊的资源（ftp、rdp等）来讲就显得力不从心了。
堡垒机：人们逐渐认识到跳板机的不足，需要更新、更好的安全技术理念来实现运维操作管理，需要一种能满足角色管理与授权审批、信息资源访问控制、操作记录和安全审计、系统变更和维护控制要求，并生成一些统计报表配合管理规范来不断提升IT内控的合规性的产品。在这些理念的指导下，2005年前后，在跳板机的基础上应运而生了堡垒机概念，运维堡垒机开始以一个独立的产品形态被广泛部署，有效地降低了运维操作风险，使得运维操作管理变得更简单、更安全。
Jumpserver 是全球首款完全开源的堡垒机，使用 GNU GPL v2.0 开源协议，是符合 4A 的专业运维审计系统。
Jumpserver 使用 Python / Django 进行开发，遵循 Web 2.0 规范，配备了业界领先的 Web Terminal 解决方案，交互界面美观、用户体验好。
Jumpserver 采纳分布式架构，支持多机房跨区域部署，中心节点提供 API，各机房部署登录节点，可横向扩展、无并发访问限制。
为什么选择Jumpserver？
混合云下更好用的堡垒机：
1. 分布式架构设计无限扩展，轻松对接混合云资产；
2. 支持使用云存储（AWS S3, ES等）存储录像、命令；
颠覆传统堡垒机：
1. 无主机和并发数量限制，支持水平扩容；
2. FIT2CLOUD提供完备的商业服务支持，用户无后顾之忧；
极致的用户体验：
1. 极致UI体验，完胜传统堡垒机；
2. 容器化的部署方式，部署过程方便快捷，可持续升级；
Jumpserver完全免费，只需要一台云主机的费用即可。
l CPU：4核
l 内存：8G
l 硬盘：200G
l 网卡：千兆双网卡
l 操作系统：CentOS 7 64位
运维人员统一通过堡垒机入口登陆服务器，避免了直接登陆服务器带来的安全隐患。
可对用户实行分组、分权限管理方式，在分配资产权限的时候，针对某个用户组下的所有用户，可以为一个用户分配多个用户组。
可自动获取服务器资产的硬件等信息，可以对资产创建标签，还可以给用户分配登陆服务器的系统账号等。
授权用户可以登陆的主机组、主机。
日志审计很重要，会自动记录下用户登陆服务器后执行的所有命令，运维人员操作违规、误操作等一目了然。
Jumpserver提供两种登陆方式：1、web终端 2、命令行登陆
运维人员通过浏览器访问Jumpserver主页，会话管理-web终端里可登陆自己名下的服务器，参见下图，此时已经登陆到192.168.2.249这台windows服务器。
注意：命令行方式不支持windows，只能登陆Linux主机。
$ ssh -p端口 堡垒机账号@堡垒机IP
$ ssh -p2222 xuad@192.168.2.164
输入密码回车，登陆成功后会看到如下页面
按照提示可以登陆自己名下的服务器。
$ sftp -P2222 xuad@192.168.2.164 # FTP登陆方式
2.6.2.2. Xshell登陆方式
$ ssh 堡垒机账号@堡垒机IP 端口
$ ssh xuad@192.168.2.164 2222
$ sftp xuad@192.168.2.164 2222 # FTP登陆方式
基于Web界面的分布式系统监控的企业级开源软件。可以监控各种系统与设备，网络参数，保证服务器设备安全运营；提供灵活的通知机制。
为什么选择zabbix？
相比与cacti、nagios等监控软件，zabbix具有分布式监控、自动化功能、自定义监控项方便、支持多种监控方式、提供api功能等优势。具体监控项目如下：
系统监控：
可监控linux和windows主机，例如CPU的负载、上下文切换、内存使用率、磁盘读写、磁盘使用率、磁盘inode节点等。
服务监控：
可监控服务进程的存活、心跳等，通过apache/nginx的status获取并发数、访问量等参数监控，还可以监控mysql的相关参数等。
网络监控：
可以监控机房网络流量、机器内外网卡流量、网络I/O等。
业务监控：
业务层面这块的监控需要与开发对接，监控比较重要，如API等。开发需要开放程序相关的接口，然后通过简单的脚本就可以实现监控。
mysql监控：
可监控mysql端口、进程状态、进程心跳等，还可以监控mysql的参数，例如最大连接数、索引大小、打开表的数量、使用内存大小、IO读线程的数量、IO写线程的数量等等。
zabbix完全免费，只需要一台云主机费用即可。
l CPU：8核
l 内存：16G
l 硬盘：500G
l 网卡：千兆双网卡
l 操作系统：CentOS 7 64位
考虑到zabbix监控数据日后会逐渐越来越大，另外Jumpserver和zabbix共用一个mysql实例，故此硬盘空间需求500G以上。
zabbix服务器通过自己的agent客户端程序获取要监控的数据，不需要安装第三方协议，例如snmp等。
zabbix的报警方式主要有桌面报警、邮件报警、短信报警等，桌面报警即是在zabbix登陆后仪表板首页会显示有问题的监控项和所对应的设备，邮件报警即是把有问题的设备和监控项信息以邮件的形式发送到运维人员的邮箱，短信报警即是以短信的形式发送到运维人员的手机上。
CPU负载：
磁盘使用率：
内存使用情况：
网卡流量：
nginx并发情况：
apache并发情况：
ansible是新出现的自动化运维工具，基于Python开发，集合了众多运维工具（puppet、cfengine、chef、func、fabric）的优点，实现了批量系统配置、批量程序部署、批量运行命令等功能。
ansible是基于模块工作的，本身没有批量部署的能力。真正具有批量部署的是ansible所运行的模块，ansible只是提供一种框架。主要包括：
(1)、连接插件connection plugins：负责和被监控端实现通信；
(2)、host inventory：指定操作的主机，是一个配置文件里面定义监控的主机；
(3)、各种模块核心模块、command模块、自定义模块；
(4)、借助于插件完成记录日志邮件等功能；
(5)、playbook：剧本执行多个任务时，非必需可以让节点一次性运行多个任务。
为什么选择ansible？
相比于saltstack而言，ansible属于轻量级自动化运维工具，无需在管理节点安装agent客户端，便能实现saltstack批量管理服务器的能力。对于服务器数量不多的情况下，例如100台服务器以下规模，对于中小型企业而言，ansible无疑是最好的选择。
ansible完全免费，只需要一台云主机费用即可。
l CPU：4核
l 内存：8G
l 硬盘：200G
l 网卡：千兆双网卡
l 操作系统：CentOS 7 64位
运维人员通过堡垒机登陆到ansible服务器上，通过playbook作业执行批量部署、批量更新、批量运行命令等操作。
要执行一条命令的话只需要一条语句即可，要执行多条命令的话可创建playbook作业实现批量运行多条命令，相当于批量运行一个shell脚本的功能。
我们先在hosts文件里定义一个web_server主机组，下面共有三台主机。
实例1：查看web_server主机组下所有主机的磁盘信息。
$ ansible web_server -a "df -h" # 一条语句就行了
实例2：将控制机上的/etc/ansible/yml_20180525.tar.gz文件拷贝至web_server主机组下的所有主机的/tmp目录下并解压，yml_20180525.tar.gz共包含nginx.yml和docker.yml两个文件。
首先我们先创建一个playbook,命名为tarcopy.yml，内容如下：
然后运行这个playbook
$ ansible-playbook tarcopy.yml
从上图中我们可以看到命令已经执行成功了，接下来我们登陆到节点主机上看一下结果吧。
很显然是我们想要的结果，yml_20180525.tar.gz已经成功拷贝过来并解压了。
首先创建一个playbook，然后执行它就可以了，内容如下：
$ ansible-playbook nginx.yml -t start_nginx # 启动 $ ansible-playbook nginx.yml -t stop_nginx #停止 $ ansible-playbook nginx.yml -t restart_nginx #重启
只需要创建一个简单的playbook，就可以完成批量执行任务，用ansible管理服务器真的很方便。
ELK是三款开源软件的缩写，即：ElasticSearch + Logstash + Kibana。这三个工具组合形成了一套实用、易用的监控架构，可抓取系统日志、apache日志、nginx日志、mysql日志等多种日志类型，目前很多公司用它来搭建可视化的集中式日志分析平台。
ElasticSearch：是一个分布式的RESTful风格的搜索和数据分析引擎，同时还提供了集中存储功能，它主要负责将logstash抓取来的日志数据进行检索、查询、分析等。
Logstash：日志处理工具，负责日志收集、转换、解析等，并将解析后的日志推送给ElasticSearch进行检索。
Kibana：Web前端，可以将ElasticSearch检索后的日志转化为各种图表，为用户提供数据可视化支持。
Filebeat：轻量型日志采集器，负责采集文件形式的日志，并将采集来的日志推送给logstash进行处理。
Winlogbeat：轻量型windows事件日志采集器，负责采集wondows的事件日志，并将采集来的日志推送给logstash进行处理。
为什么选择ELK？
ELK是目前比较流行的集中式日志分析平台，能够安全可靠地获取任何来源、任何格式的日志数据，并且能够实时地对数据进行搜索、分析和可视化。相比于其他日志管理工具如logzilla等，ELK具有分布式搜索、各功能独立（方便部署）、水平扩展、可视化、高可用和管理便捷等诸多优势。
ELK完全免费，只需要一台云主机费用即可。
l CPU：8核
l 内存：16G
l 硬盘：500G
l 网卡：千兆双网卡
l 操作系统：CentOS 7 64位
运维人员和开发人员通过通过浏览器访问ELK主页，查看各应用服务器的日志。
Linux服务器日志：
windows服务器日志：
标签：水平 开始 行业 进入 磁盘 访问控制 批量管理 开源软件 跳板
原文地址：http://blog.51cto.com/andyxu/2140283
