linux运维面试题目精选

1)你平时在公司主要做什么?

1、公司服务器的日常维护,常见服务器部署搭建及维护

2、Mysql数据库的日常运维工作,主从同步搭建,数据备份。

3、监控系统的搭建和维护,为新上线的服务写自定义监控脚本

4、处理线上服务紧急故障,保证线上服务7*24稳定运行。

5、日常技术文档编写

2)你们原来公司的网站架构是怎样的?

3)你对那一块比较熟悉或者精通?

nginx shell 自动化运维比较熟悉

4) Squid、varnish等缓存服务器维护过吗?squid缓存代理的原理是什么?缓存命中率怎么查看及清空缓存?

5)LVS的工作原理是什么?有哪些算法?

1、当客户端的请求到达负载均衡器的内核空间时,首先会到达PREROUTING链。

2、当内核发现请求数据包的目的地址是本机时,将数据包送往INPUT链。

3、LVS由用户空间的ipvsadm和内核空间的IPVS组成,ipvsadm用来定义规则,IPVS利用ipvsadm定义的规则工作,IPVS工作在INPUT链上,当数据包到达INPUT链时,首先会被IPVS检查,如果数据包里面的目的地址及端口没有在规则里面,那么这条数据包将经过INPUT链送至用户空间,交给用户空间的进程来处理。

4、如果数据包里面的目的地址及端口在规则里面,那么这条数据报文将被修改目的地址为事先定义好的后端服务器,并送往POSTROUTING链。
5、最后经由POSTROUTING链发往后端服务器。
rr wrr lc wlc  LBLC 基于局部性的最少连接 LBLCR 基于局部性的带复制功能的最少 sh 源地址hash dh 目标地址散列

6)Nginx日常的优化参数有哪些?Nginx动静分离做过吗?描述简单的步骤?

1. worker_processes 8;nginx 进程数,建议按照cpu 数目来指定,一般为它的倍数 (如,2个四核的cpu计为8)。

2. worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;为每个进程分配cpu,上例中将8 个进程分配到8 个cpu,当然可以写多个,或者将一个进程分配到多个cpu。

3. worker_rlimit_nofile 65535;

这个指令是指当一个nginx 进程打开的最多文件描述符数目,理论值应该是最多打开文
件数(ulimit -n)与nginx 进程数相除,但是nginx 分配请求并不是那么均匀,所以最好与ulimit -n 的值保持一致。

现在在linux 2.6内核下开启文件打开数为65535,worker_rlimit_nofile就相应应该填写65535。

这是因为nginx调度时分配请求到进程并不是那么的均衡,所以假如填写10240,总并发量达到3-4万时就有进程可能超过10240了,这时会返回502错误。

使用epoll的I/O模型

5. worker_connections 65535;

每个进程允许的最多连接数, 理论上每台nginx 服务器的最大连接数为worker_processes*worker_connections。

6. keepalive_timeout 60;

keepalive 超时时间。

7)linux内核优化,你都有优化哪些参数?

8)你在维护网站的过程中共,曾经遇到过什么重大问题?怎样解决的?

9)shell变成熟悉吗?编写一个自动化备份Mysql数据库的脚本?

10)Mysql主从架构的原理是什么?如果主从不同步,报错了,怎么恢复?

mysql配置优化  1)慢查询日志 

11)如果备份大数据Mysql数据文件?Mysql优化有哪些步骤?

12)FTP主被动模式的区别是什么?

ftp有两种登录方式:匿名登录和授权登录.使用匿名登录时,用户名为:anonymous,密码为:任何合法email地址;使用授权登录时,用户名为用户在远程系统中的用户帐号,密码为用户在远程系统中的用户密码.

区别:使用匿名登录只能访问ftp目录下的资源,默认配置下只能下载;而授权登录访问的权限大于匿名登录,且上载、下载均可.

(2)ftp文件传输有两种文件传输模式:ASCII模式和binary模式.ASCII模式用来传输文本文件,其他文件的传输使用binary模式.

(3)常用的ftp文件传输命令为:bin、asc、put、get、mput、mget、prompt、bye

13) Apache两种工作模式的区别及优化?

prefork模式:这个多路处理模块(MPM)实现了一个非线程型的、预派生的web服务器,它的工作方式类似于Apache 1.3。它适合于没有线程安全库,需要避免线程兼容性问题的系统。它是要求将每个请求相互独立的情况下最好的MPM,这样若一个请求出现问题就不会影响到其他请求。

work模式:此多路处理模块(MPM)使网络服务器支持混合的多线程多进程。由于使用线程来处理请求,所以可以处理海量请求,而系统资源的开销小于基于进程的MPM。但是,它也使用了多进程,每个进程又有多个线程,以获得基于进程的MPM的稳定性

14)Nagios、cacti维护过吗?平时都监控些什么?

Cacti比较着重于直观数据的监控,易于生成图形,用来监控网络流量、cpu使用率、硬盘使用率等

Nagios则比较注重于主机和服务的监控,并且有很强大的发送报警信息的功能

cacti偏重于网络流量,系统负载方面的监控。而 nagios偏重于系统服务方面的监控,你可以在被监控的机器上写自己的程序(shell,c 或 perl都可以) 。nagios则通过这些脚本来对服务进行监控。nagios可以和短信发送机配合用来监控规模较大的网站。

15)你们公司的网络出口带宽是多少?每天网站的PV、UV是多少?

pv:50W UV:6-8w 带宽 50w/(24*60*60) 50M带宽

16) 你觉得Linux运维工程师的职责是什么?

17)你为什么离职,离职的原因是什么?

18)你未来5-10年的职业规划是什么样的?

19)keepalived的工作原理?

Keepalived是Linux下一个轻量级别的高可用解决方案,
Keepalived是Linux下一个轻量级别的高可用解决方案。高可用(High Avalilability,HA),其实两种不同的含义:广义来讲,是指整个系统的高可用行,狭义的来讲就是之主机的冗余和接管, 它与HeartBeat RoseHA 实现相同类似的功能,都可以实现服务或者网络的高可用,但是又有差别,HeartBeat是一个专业的、功能完善的高可用软件,它提供了HA 软件所需的基本功能,比如:心跳检测、资源接管,检测集群中的服务,在集群节点转移共享IP地址的所有者等等。HeartBeat功能强大,但是部署和使用相对比较麻烦, 与HeartBeat相比,Keepalived主要是通过虚拟路由冗余来实现高可用功能,虽然它没有HeartBeat功能强大,但是Keepalived部署和使用非常的简单,所有配置只需要一个配置文件即可以完成, 原理:
Keepalived工作在TCP
/IP 参考模型的 三层、四层、五层,也就是分别为:网络层, 传输层和应用层,根据TCP、IP参数模型隔层所能实现的功能,Keepalived运行机制如下: 在网络层:我们知道运行这4个重要的协议,互联网络IP协议,互联网络可控制报文协议ICMP、地址转换协议ARP、反向地址转换协议RARP,在网络层Keepalived在网络层采用最常见的工作方式是通过ICMP协议向服务器集群中的每一个节点发送一个ICMP数据包(有点类似与Ping的功能),如果某个节点没有返回响应数据包,那么认为该节点发生了故障,Keepalived将报告这个节点失效,并从服务器集群中剔除故障节点。 在传输层:提供了两个主要的协议:传输控制协议TCP和用户数据协议UDP,传输控制协议TCP可以提供可靠的数据输出服务、IP地址和端口,代表TCP的一个连接端,要获得TCP服务,需要在发送机的一个端口和接收机的一个端口上建立连接,而Keepalived在传输层里利用了TCP协议的端口连接和扫描技术来判断集群节点的端口是否正常,比如对于常见的WEB服务器80端口。或者SSH服务22端口,Keepalived一旦在传输层探测到这些端口号没有数据响应和数据返回,就认为这些端口发生异常,然后强制将这些端口所对应的节点从服务器集群中剔除掉。 在应用层:可以运行FTP,TELNET,SMTP,DNS等各种不同类型的高层协议,Keepalived的运行方式也更加全面化和复杂化,用户可以通过自定义Keepalived工作方式,例如:可以通过编写程序或者脚本来运行Keepalived,而Keepalived将根据用户的设定参数检测各种程序或者服务是否允许正常,如果Keepalived的检测结果和用户设定的不一致时,Keepalived将把对应的服务器从服务器集群中剔

 

20.什么是符号链接,什么是硬链接?符号链接与硬链接的区别是什么?

链接分硬链接和符号链接.
符号链接可以建立对于文件和目录的链接.符号链接可以跨文件系统,即可以跨磁盘分区.符号链接的文件类型位是l,链接文件具有新的i节点.
硬链接不可以跨文件系统.它只能建立对文件的链接,硬链接的文件类型位是-,且硬链接文件的i节点同被链接文件的i节点相同.

21 简述DNS进行域名解析的过程.
,客户端发出DNS请求翻译IP地址或主机名.DNS服务器在收到客户机的请求后:
(1)检查DNS服务器的缓存,若查到请求的地址或名字,即向客户机发出应答信息;
(2)若没有查到,则在数据库中查找,若查到请求的地址或名字,即向客户机发出应答信息;
(3)若没有查到,则将请求发给根域DNS服务器,并依序从根域查找顶级域,由顶级查找二级域,二级域查找三级,直至找到要解析的地址或名字,即向客户机所在网络的DNS服务器发出应答信息,DNS服务器收到应答后现在缓存中存储,然后,将解析结果发给客户机.
(4)若没有找到,则返回错误信息.4.系统管理员的职责包括那些?管理的对象是什么?

22.请描述Linux系统优化的12个步骤。

⑴登录系统:不使用root登录,通过sudo授权管理,使用普通用户登录。

⑵禁止SSH远程:更改默认的远程连接SSH服务及禁止root远程连接。

⑶时间同步:定时自动更新服务器时间。

⑷配置yum更新源,从国内更新下载安装rpm包。

⑸关闭selinux及iptables(iptables工作场景如有wan ip,一般要打开,高并发除外)

⑹调整文件描述符数量,进程及文件的打开都会消耗文件描述符。

⑺定时自动清理/var/spool/clientmquene/目录垃圾文件,防止节点被占满(c6.4默认没有sendmail,因此可以不配。)

⑻精简开机启动服务(crond、sshd、network、rsyslog)

⑼Linux内核参数优化/etc/sysctl.conf,执行sysct -p生效。

更改字符集,支持中文,但是还是建议使用英文,防止乱码问题出现。

⑾锁定关键系统文件(chattr +i /etc/passwd /etc/shadow /etc/group /etc/gshadow /etc/inittab 处理以上内容后,把chatter改名,就更安全了。)

⑿清空/etc/issue,去除系统及内核版本登陆前的屏幕显示。

23.描述Linux系统从开机到登陆界面的启动过程

⑴开机BIOS自检,加载硬盘。

⑵读取MBR,MBR引导。

⑶grub引导菜单(Boot Loader)。

⑷加载内核kernel。

⑸启动init进程,依据inittab文件设定运行级别

⑹init进程,执行rc.sysinit文件。

⑺启动内核模块,执行不同级别的脚本程序。

⑻执行/etc/rc.d/rc.local

⑼启动mingetty,进入系统登陆界面。

24.生产场景如何对linux系统进行合理规划分区?

分区的根本原则是简单、易用、方便批量管理。根据服务器角色定位建议如下:

①单机服务器:如8G内存,300G硬盘

分区:  /boot 100-200M,swap 16G,内存大小8G*2,/ 80G,/var 20G(也可不分),/data 180G(存放web及db数据)

优点:数据盘和系统盘分开,有利于出问题时维护。

RAID方案:视数据及性能要求,一般可采用raid5折中。 

②负载均衡器(如LVS等) 

分区:/boot 100-200M,swap 内存的1-2倍,/  ,

优点:简单方便,只做转发数据量很少。 

RAID方案:数据量小,重要性高,可采用RAID1 

③负载均衡下的RS server

分区: /boot 100-200M,swap 内存的1-2倍,/  

优点:简单方便,因为有多机,对数据要求低。 

RAID方案:数据量大,重要性不高,有性能要求,数据要求低,可采用RAID0 

④数据库服务器mysql及oracle如16/32G内存

分区:/boot 100-200M,swap 16G,内存的1倍,/ 100G,/data 剩余(存放db数据) 

优点:数据盘和系统盘分开,有利于出问题时维护,及保持数据完整。 

RAID方案:视数据及性能要求主库可采取raid10/raid5,从库可采用raid0提高性能(读写分离的情况下。)

⑤存储服务器

分区:/boot 100-200M,swap 内存的1-2倍,/ 100G,/data(存放数据) 

优点:此服务器不要分区太多。只做备份,性能要求低。容量要大。 

RAID方案:可采取sata盘,raid5 

⑥共享存储服务器(如NFS) 

分区:/boot 100-200M,swap 内存的1-2倍,/ 100G,/data(存放数据) 

优点:此服务器不要分区太多。NFS共享比存储多的要求就是性能要求。 

RAID方案:视性能及访问要求可以raid5,raid10,甚至raid0(要有高可用或双写方案) 

⑦监控服务器cacti,nagios 

分区:/boot 100-200M,swap 内存的1-2倍,/ 

优点:重要性一般,数据要求也一般。 

RAID方案:单盘或双盘raid1即可。三盘就RAID5,看容量要求加盘即可。

原文地址:https://www.cnblogs.com/legenidongma/p/10858479.html