文章目录
在上次的《运维面试，你应该知道这些（1）》中，记录了一些网络面试需要知道的知识，今天继续给大家分享我认为比较有实践意义的面试知识，也许下次我面试应聘者的时候会用上。
运维分工
运维分为：DBA运维、网站运维、虚拟化运维、监控运维、游戏运维
游戏运维又分为：
- 开发运维：是给应用运维开发运维工具和运维平台的
- 应用运维：是给业务上线、维护和做故障排除的，用开发运维开发出来的工具给业务上线、维护、做故障排查
- 系统运维：是给应用运维提供业务上的基础设施，比如：系统、网络、监控、硬件等等
如何管理300台服务器
- 设定跳板机，使用统一账号登录，便于安全与登录的考量。
- 使用salt、ansiable、puppet进行系统的统一调度与配置的统一管理。
- 建立简单的服务器的系统、配置、应用的cmdb信息管理。便于查阅每台服务器上的各种信息记录。
raid0 raid1 raid5
RAID，可以把硬盘整合成一个大磁盘，还可以在大磁盘上再分区，放数据
还有一个大功能，多块盘放在一起可以有冗余（备份）
RAID整合方式有很多，常用的：0 1 5 10
- RAID 0，可以是一块盘和N个盘组合
优点：读写快，是RAID中最好的
缺点：没有冗余，一块坏了数据就全没有了 - RAID 1，只能2块盘，盘的大小可以不一样，以小的为准
优点：100%的冗余，另一个做备份
缺点：10G+10G只有10G，浪费资源，成本高 - RAID 5 ，3块盘，容量计算10*（n-1）,损失一块盘
优点：成本在RAID 0和RAID 1之间
缺点：读写性能一般，读还好一点，写不好 - 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服务器流量莫名其妙的剧增：
- 用iftop查看有连接外网的情况
- netstat连接的外网ip和端口
- lsof -p pid可以查看到具体是那些进程，哪些文件
经查勘发现/root下有相关的配置conf.n hhe两个可疑文件，rm -rf后不到一分钟就自动生成了，由此推断是某个母进程产生的这些文件。所以找到母进程就是找到罪魁祸首 - 断掉外网访问，病毒就失去外联的能力，杀掉它就容易的多
- 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