文章目录
在上次的《运维面试,你应该知道这些(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