【运维心得】运维面试，你应该知道这些（2）

在上次的《运维面试，你应该知道这些（1）》中，记录了一些网络面试需要知道的知识，今天继续给大家分享我认为比较有实践意义的面试知识，也许下次我面试应聘者的时候会用上。

运维分工

运维分为：DBA运维、网站运维、虚拟化运维、监控运维、游戏运维
游戏运维又分为：

1. 开发运维：是给应用运维开发运维工具和运维平台的
2. 应用运维：是给业务上线、维护和做故障排除的，用开发运维开发出来的工具给业务上线、维护、做故障排查
3. 系统运维：是给应用运维提供业务上的基础设施，比如：系统、网络、监控、硬件等等

如何管理300台服务器

1. 设定跳板机，使用统一账号登录，便于安全与登录的考量。
2. 使用salt、ansiable、puppet进行系统的统一调度与配置的统一管理。
3. 建立简单的服务器的系统、配置、应用的cmdb信息管理。便于查阅每台服务器上的各种信息记录。

raid0 raid1 raid5

RAID，可以把硬盘整合成一个大磁盘，还可以在大磁盘上再分区，放数据
还有一个大功能，多块盘放在一起可以有冗余（备份）
RAID整合方式有很多，常用的：0 1 5 10

1. RAID 0，可以是一块盘和N个盘组合
   优点：读写快，是RAID中最好的
   缺点：没有冗余，一块坏了数据就全没有了
2. RAID 1，只能2块盘，盘的大小可以不一样，以小的为准
   优点：100%的冗余，另一个做备份
   缺点：10G+10G只有10G，浪费资源，成本高
3. RAID 5 ，3块盘，容量计算10*（n-1）,损失一块盘
   优点：成本在RAID 0和RAID 1之间
   缺点：读写性能一般，读还好一点，写不好
4. RAID 10，又叫1+0，4块盘，先按raid 0分成两组，再分别对两组按raid 1方式镜像
   优点：兼顾冗余(提供镜像存储)和性能(数据条带形分布)
   缺点：成本高
   单项对比

对比	RAID0	RAID1	RAID5	RAID10
冗余	$	$$$$	$$	$$$
性能	$$$$	$	$$	$$$
成本	$	$$$	$$	$$$$

使用场景

	RAID0	RAID1	RAID5	RAID10
用途	数据库服务器，从库；WEB服务器	单台服务器，系统盘	数据库服务器，从库；WEB服务器	数据库服务器，主库

LVS、Nginx、HAproxy

	LVS	HAproxy	Nginx
定义	基于四层的转发	基于四层和七层的转发	可以做七层的转发
用途	只能做端口的转发	专业的代理服务器	是WEB服务器，缓存服务器，又是反向代理服务器
优点	性能最强，大并发量的	配置简单，支持Session的保持，Cookie的引导，负载均衡策略非常多	对网络稳定性的依赖非常小，理论上能ping通就能进行负载功能
缺点	对网络稳定性依赖比较大，不支持正则表达式处理，不能做动静分离	配置简单	仅能支持http、https和Email协议
适合企业	大型	中小型	中小型

Squid、Varinsh和Nginx

Squid、Varinsh和Nginx都是代理服务器

	Squid	Varinsh	Nginx
代理服务	专业的cache服务	专业的cache服务，采用了可视化页面缓存技术	反向代理/web服务器，用了插件可以做，只能缓存静态文件
内存利用		比Squid具有优势，性能要比Squid高
环境	完整的庞大的cache技术资料，和很多的应用生产环境
cache服务	优先选择	优先选择

Tomcat8005、8009、8080三个端口的含义？

8005关闭时使用
8009为AJP端口，即容器使用，如Apache能通过AJP协议访问Tomcat的8009端口
8080一般应用使用

LVS三种模式

LVS 有三种负载均衡的模式，分别是VS/NAT（nat 模式） VS/DR(路由模式) VS/TUN（隧道模式）

	VS/NAT（nat 模式）	VS/DR(路由模式)	VS/TUN（隧道模式）
原理	就是把客户端发来的数据包的IP头的目的地址，在负载均衡器上换成其中一台RS的IP地址并发至此RS来处理,RS处理完后把数据交给负载均衡器,负载均衡器再把数据包原IP地址改为自己的IP将目的地址改为客户端IP地址即可期间,无论是进来的流量,还是出去的流量,都必须经过负载均衡器	首先要知道，互联网上的大多Internet服务的请求包很短小，而应答包通常很大那么隧道模式就是，把客户端发来的数据包，封装一个新的IP头标记(仅目的IP)发给RS，RS收到后,先把数据包的头解开,还原数据包,处理后,直接返回给客户端,不需要再经过负载均衡器。注意,由于RS需要对负载均衡器发过来的数据包进行还原,所以说必须支持IPTUNNEL协议，所以,在RS的内核中,必须编译支持IPTUNNEL这个选项	负载均衡器和RS都使用同一个IP对外服务但只有DR对ARP请求进行响应,所有RS对本身这个IP的ARP请求保持静默也就是说,网关会把对这个服务IP的请求全部定向给DR,而DR收到数据包后根据调度算法,找出对应的RS,把目的MAC地址改为RS的MAC（因为IP一致）,并将请求分发给这台RS这时RS收到这个数据包,处理完成之后，由于IP一致，可以直接将数据返给客户,则等于直接从客户端收到这个数据包无异,处理后直接返回给客户端,由于负载均衡器要对二层包头进行改换,所以负载均衡器和RS之间必须在一个广播域,也可以简单的理解为在同一台交换机上
优点	集群中的物理服务器可以使用任何支持TCP/IP操作系统，只有负载均衡器需要一个合法的IP地址	负载均衡器只负责将请求包分发给后端节点服务器，而RS将应答包直接发给用户，所以，减少了负载均衡器的大量数据流动，能处理很巨大的请求量，这种方式，一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。	和TUN（隧道模式）一样，负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户端,与VS-TUN相比，VS-DR这种实现方式不需要隧道结构，因此可以使用大多数操作系统做为物理服务器。
缺点	扩展性有限。当服务器节点（普通PC服务器）增长过多时,负载均衡器将成为整个系统的瓶颈。当服务器节点过多时大量的数据包都交汇在负载均衡器那，速度就会变慢	隧道模式的RS节点需要合法IP，这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议，服务器可能只局限在部分Linux系统上	要求负载均衡器的网卡必须与物理网卡在一个物理段上

发现病毒文件删了又自动创建怎么解决

公司的内网某台linux服务器流量莫名其妙的剧增：

1. 用iftop查看有连接外网的情况
2. netstat连接的外网ip和端口
3. lsof -p pid可以查看到具体是那些进程，哪些文件
   经查勘发现/root下有相关的配置conf.n hhe两个可疑文件，rm -rf后不到一分钟就自动生成了，由此推断是某个母进程产生的这些文件。所以找到母进程就是找到罪魁祸首
4. 断掉外网访问，病毒就失去外联的能力，杀掉它就容易的多
5. ps aux一个个排查，查看用户和和系统相似而又不是的冒牌货，果然，看到了如下进程可疑，/usr/bin/.sshd，杀掉所有.sshd相关的进程，然后直接删掉.sshd这个可执行文件，然后才删掉了文章开头提到的自动复活的文件

总结，遇到这种问题，如果不是太严重，尽量不要重装系统
一般就是先断外网，然后利用iftop,ps,netstat,chattr,lsof,pstree这些工具顺藤摸瓜。但是如果遇到诸如此类的问题
/boot/efi/EFI/redhat/grub.efi: Heuristics.Broken.Executable FOUND，个人觉得就要重装系统了

写脚本，实现判断192.168.1.0/24网络里，当前在线的IP有哪些，能ping通则认为在线

!/bin/bash
for ip in seq 1 255
do
{
	ping -c 1 192.168.1.$ip > /dev/null 2>&1
	if [ $? -eq 0 ]; then
		echo 192.168.1.$ip UP
	else
		echo 192.168.1.$ip DOWN
	fi
}&done
wait

每晚12 点，打包站点目录/var/www/html 备份到/data 目录下（最好每次备份按时间生成不同的备份包）

cat a.sh
/bin/bash
cd /var/www/ && /bin/tar zcf /data/html-
date +%m-%d%H
.tar.gz html/

crontab –e
00 00 * * * /bin/sh /root/a.sh