Linux运维开发工程师面试问题,持续更新中。。。

Linux面试

数据存储

文件系统

什么是VFS?

vfs:linux虚拟文件系统,为各类文件系统提供了一个统一的操作界面和应用编程接口。VFS是一个可以让系统调用不用关心底层的存储介质和文件系统类型就可以工作的粘合层。

nfs

分布式文件系统

软硬连接

  • 软硬连接的作用


软硬连接的目的是解决文件共享问题,同时还有隐藏文件路径、增加权限安全和节省存储的目的。
  • 什么是软连接,什么是硬连接,有什么区别

软连接:保存了一个指向另一个文件的路径,软连接的大小就是文件路径的字符串大小。软连接特点:

  1. 软链接,以路径的形式存在

  2. 软链接可以 跨文件系统

  3. 软链接可以对一个不存在的文件名进行链接

  4. 软链接可以对目录进行链接

硬连接:

指向同一个inode号的不同文件名,同一个文件使用多个别名

硬连接的特点:

  1. 以文件副本的形式存在,但不占用实际空间

  2. 目录无法创建硬链接

  3. 硬连接不能跨文件系统

自动挂载


如何实现自动挂载,fastab 各字段的意义:
编辑/etc/fstab文件。每一行代表一个挂载指令,在开机时由系统自动挂载
fstab各字段的意义:
第一列:要挂载的设备,是绝对路径
第二列:挂载点,即挂载到哪个目录下,也是绝对路径
第三列:文件系统类型;常见的linux文件系统类型如:ext系列、iso9660光驱、ntfs、swap等
第四列:挂载选项,常见选项:rw、ro、defaults、auto等
第五列:dump备份工具。检查一个文件系统应该以多快频率进行转储,若不需要转储就设置该字段为0
第六列:fsck文件系统扫描检查工具。

Mysql

mysql的各个工作模块

  • MySQL 的初始化模块:从系统配置文件中读取系统参数和命令行参数,并按照参数来初始化整个系统

  • 连接管理模块:处理客户端连接请求,通过C/S交互,将连接请求转发给线程管理模块

  • 线程管理模块:调用用户模块进行授权检查

  • 连接线程模块:在线程池为请求连接线程,或者创建一个新的线程

线程创建完成后,开始对请求进行处理

  • 解析和转发模块:解析器对基本的语义和语法解析,根据命令类型的不同,有些会直接处理,有些会分发给其他模块来处理。具体:如果是select类型,调用缓存模块,查看缓存是否有命中;如果没有,将继续解析,则交给其他模块

    • 如果是select语句,则交给优化器模块

    • 如果是 DML 或者是 DDL 语句,则会交给表变更管理模块

    • 如果是一些更新统计信息、检测、修复和整理则会交给表维护模块

    • 如果和复制相关,则交给复制模块

    • 如果是请求状态类,则交给状态模块

  • 访问控制模块:解析和转发模块在执行前,会通过访问控制模块,检查连接用户是否有访问目标表以及目标字段的权限;如果有,就会调用表管理模块请求相应的表,并获取对应的锁。

  • 表管理模块:判断表的存储引擎类型和其他相关信息。根据表的存储引擎类型,提交请求给存储引擎接口模块

  • 存储引擎:提供一系列 “标准”接口给表管理模块,处理请求然后将控制权交给线程模块

  • 日志模块:如果打开了日志模块,并且请求对数据库进行了变更,对应的处理模块还会调用日志处理模块将相应的变更语句以对事件进行记录

sql的四大功能

SQL的四大功能:

  1. 数据定义:DDL(data definition language),定义三大模式结构、两级映射、约束等。以CREATE、ALTER、DROP、COMMIT、TRUNCATE等为主

  2. 数据操作:DML(data manipulation language),增删改查等功能,以INSERT、UPDATE、DELETE、SELECT、LOCK等主为

  3. 数据控制:DCL(data control language ),包括对基本表和视图的授权,完整性规则的描述,事务控制等内容,以GRANT、REVOKE等为主

  4. 嵌入式SQL的使用规定:涉及到SQL语句嵌入在宿主语言程序中使用的规则。

数据库左连接右连接

存储引擎

MyISAM和InnoDB的主要区别和应用场景

主要区别

  1. MyISAM是非事务安全型的,而InnoDB是事务安全型的。

  2. MyISAM锁的粒度是表级,而InnoDB支持行级锁定。

  3. MyISAM支持全文类型索引,而InnoDB不支持全文索引。

  4. MyISAM相对简单,所以在效率上要优于InnoDB,小型应用可以考虑使用MyISAM。

  5. MyISAM表是保存成文件的形式,在跨平台的数据转移中使用MyISAM存储会省去不少的麻烦。

  6. InnoDB表比MyISAM表更安全,可以在保证数据不会丢失的情况下,切换非事务表到事务表

应用场景

  1. MyISAM管理非事务表。它提供高速存储和检索,以及全文搜索能力。如果应用中需要执行大量的SELECT查询,那么MyISAM是更好的选择。

  2. InnoDB用于事务处理应用程序,具有众多特性,包括ACID事务支持。如果应用中需要执行大量的INSERT或UPDATE操作,则应该使用InnoDB,这样可以提高多用户并发操作的性能。

事务

innodb的事务与日志的实现方式

将一堆sql指令当作一个执行单元,要么都完成,要么都不完成。事务防止对数据表进行一些列操作时,部分操作完成部分操作失败,而导致对数据进行不可修复性更改。

一个RDBMS支持事务,指的是能够满足四种ACID测试:

  • 原子性:事务中包含的操作被看做一个逻辑单元,这个逻辑单元中的操作要么全部成功,要么全部失败。

  • 一致性:事务中包含的操作被看做一个逻辑单元,这个逻辑单元中的操作要么全部成功,要么全部失败。

  • 隔离性:事务允许多个用户对同一个数据进行并发访问,而不破坏数据的正确性和完整性。同时,并行事务的修改必须与其他并行事务的修改相互独立。

  • 持久性:事务结束后,事务处理的结果必须能够得到固化。

事务的四种隔离级别

事务的四种隔离级别:

READ UNCOMMITTED:一个事务对数据的修改,别的事务可以直接看到

READ COMMITTED:一个事务对数据修改后,提交完成,别的事务可以看到

REPEATABLE-READ:一个事务在提交前后,对数据的修改,别的事务都无法看到,但是支持两个事务同时对数据的操作。

SERIABLIZABLE:不支持事务并发,一个开启了事务,别的事务无法执行

日志

MySQL binlog的几种日志录入格式以及区别

Mysql的二进制日志格式:

基于语句:STATEMENT,对语句进行了简单的

基于行数据:ROW,有些数据在不同环境执行可能会有不同结果

混合:MIXED,musql自身提供鉴别机制,根据判断执行STATEMENT还是ROW

mysqldump

主从复制


主从复制原理:
主服务器打开二进制日志功能,将二进制日志中记录的事件,通过一个IO线程发送给从服务器;
从服务器打开自己的中继日志功能,接收主服务器的二进制日志,并保存到中继日志中,开启一个SQL线程进行重放操作,达到保存数据的目的。
这里为了保证主从服务器数据一致性,从服务器不接受任何本地的可以改变数据库数据的操作。

主从复制的意义:

  1. 为数据提供备份

  2. 提供数据库的高可用能力

  3. 异地容灾

如何判断mysql主从是否同步


Slave_IO_Running
Slave_SQL_Running

读写分离

读写分离的实现:
在mysql主从集群前有一个设备(mysql-proxy),对用户的操作进行分析,对读写操作进行分离,而且由于从服务器(提供读服务)不止一个,又要提供一个负载均衡器来进行连接分发。在主服务器上写操作,在从服务器只进行读操作,这种模型就成只为读写分离。

可提供更多能力:
缓存机制
从服务器负载均衡提供请求分发

读写分离的目的:为了缓解主服务器的读写压力,提高服务器的高可用能力,将从服务器对外开放,但是用户只可以对进行读操作。

提高安全性。

mysql负载/瓶颈

  • MySQL数据库cpu飙升到500%,怎么处理?

  • 500台db,在最快时间之内重启

  • innodb的读写参数优化

  • MySQL中InnoDB引擎的行锁是通过加在什么上完成(或称实现)的?为什么是这样子的?

  • 一个6亿的表a,一个3亿的表b,通过外间tid关联,你如何最快的查询出满足条件的第50000到第50200中的这200条数据记录。

虚拟化

Docker

为什么使用docker

docker解决了什么问题,为什么要用docker

搞定了环境依赖问题:

一个程序要跑起来,需要这么几部分:代码 + 运行环境 + 配置 + 依赖的服务。Docker image中包含了运行环境+配置,这对部署相当友好。

更轻量的虚拟化,节省了虚拟机的性能损耗。docker的启动是毫秒级的,而且面向服务,Docker使用Linux的namespace和cgroup机制,实现了对cpu、内存、等资源的管理

Docker 镜像、容器、仓库

Docker镜像:类似于虚拟机的镜像,是一个面向Docker引擎的只读模板,包含了文件系统。

Docker容器:通过Docker镜像实例化的一个可运行的简易版的Linux系统环境。

Docker仓库:是Docker集中存放镜像文件的场所。

Dcoker镜像的构建

Docker镜像构建的意义:

构建镜像,可以保存对容器的设置、修改,并可移植化的使用;提供了自定义镜像的能力,以软件的形式打包并奋发服务及运行环境

构建镜像的方法:

docker commit:通过容器构建

docker build:通过Dockerfile文件构建

Dockerfile指令

FROM <image>:基础镜像,这个是Dockerfile的开始

MAINTAINER :作者信息

RUN:指定当前镜像中运行的命令

EXPOSE:指定运行该镜像开启的端口号

CMD:指定容器运行的行为

ADD:将文件或者目录复制到docker容器中,包含解压缩功能

COPY:将文件或者目录复制到docker容器中,单纯的复制

VOLUME:向基于镜像的容器添加卷,可以存在于一个或者多个目录,可以绕过联合文件系统,提供共享数据或者数据持久化的功能

WORKDIR:在容器内部设置工作目录

ENV:设置环境变量

USER:指定镜像以什么用户身份运行,默认是root

docker四中网络模式


1 host模式
众所周知,Docker使用了Linux的Namespaces技术来进行资源隔离,如PID Namespace隔离进程,Mount
Namespace隔离文件系统,Network Namespace隔离网络等。一个Network Namespace提供了一份独立的网络环境,包括网卡、路由、Iptable规则等都与其他的Network Namespace隔离。一个Docker容器一般会分配一个独立的Network
Namespace。但如果启动容器的时候使用host模式,那么这个容器将不会获得一个独立的Network Namespace,而是和宿主机共用一个Network Namespace。容器将不会虚拟出自己的网卡,配置自己的IP等,而是使用宿主机的IP和端口。
例如,我们在10.10.101.105/24的机器上用host模式启动一个含有web应用的Docker容器,监听tcp80端口。当我们在容器中执行任何类似ifconfig命令查看网络环境时,看到的都是宿主机上的信息。而外界访问容器中的应用,则直接使用10.10.101.105:80即可,不用任何NAT转换,就如直接跑在宿主机中一样。但是,容器的其他方面,如文件系统、进程列表等还是和宿主机隔离的。
 2 container模式
在理解了host模式后,这个模式也就好理解了。这个模式指定新创建的容器和已经存在的一个容器共享一个Network
Namespace,而不是和宿主机共享。新创建的容器不会创建自己的网卡,配置自己的IP,而是和一个指定的容器共享IP、端口范围等。同样,两个容器除了网络方面,其他的如文件系统、进程列表等还是隔离的。两个容器的进程可以通过lo网卡设备通信。
 3 none模式
这个模式和前两个不同。在这种模式下,Docker容器拥有自己的Network Namespace,但是,并不为Docker容器进行任何网络配置。也就是说,这个Docker容器没有网卡、IP、路由等信息。需要我们自己为Docker容器添加网卡、配置IP等。
 4 bridge模式
bridge模式是Docker默认的网络设置,此模式会为每一个容器分配Network Namespace、设置IP等,并将一个主机上的Docker容器连接到一个虚拟网桥上。下面着重介绍一下此模式。host模式
使用Docker run时使用–net=host指定 Docker使用的网络实际上和宿主机一样,在容器内看到的网卡ip是宿主机上的ip。

docker常用命令


1. docker version  查看docker的版本号,包括客户端、服务端、依赖的Go等
2. docker info  查看系统(docker)层面信息,包括管理的images, containers数等
3. docker search <image>在docker index中搜索image 
4. docker pull <image>从docker registry server 中下拉image 
5. docker push <image|repository>推送一个image或repository到registry 
6. docker push <image|repository>:TAG  同上,指定tag  
7. docker inspect <image|container>查看image或container的底层信息
8. docker images  查看本机images 
9. docker images –a  列出所有的images 
10. dockerps默认显示正在运行中的container 

KVM

网络管理

OSI模型

OSI模型把网络通信的工作分为7层,分别是物理层数据链路层、网络层、传输层会话层表示层应用层

具体7层 份额封装 功能与连接方式 典型设备 应用
应用层 Application 数据Data 网络服务与使用者应用程序间的一个接口 终端设备(PC、手机、平板等) 具体应用
表示层 Presentation 数据Data 数据表示、数据安全、数据压缩 终端设备(PC、手机、平板等) 加密压缩等
会话层 Session 数据Data 会话层连接到传输层的映射;会话连接的流量控制;数据传输;会话连接恢复与释放;会话连接管理、差错控制 终端设备(PC、手机、平板等)
传输层 Transport 数据组织成数据段Segment 用一个寻址机制来标识一个特定的应用程序(端口号) 终端设备(PC、手机、平板等) 封装端口
网络层 Network 分割和重新组合数据包Packet 基于网络层地址(IP地址)进行不同网络系统间的路径选择 网关、路由器 封装IP
数据链路层 Data Link 将比特信息封装成数据帧Frame 在物理层上建立、撤销、标识逻辑链接和链路复用 以及差错校验等功能。通过使用接收系统的硬件地址或物理地址来寻址 网桥、交换机 封装MAC
物理层Physical 传输比特(bit)流 建立、维护和取消物理连接 光纤、同轴电缆、双绞线、网卡、中继器、集线器 封装前导码

TCP

TCP模型

对应OSI模型 对应网络协议
应用层 应用层,表示层,绘话层 HTTP、TFTP, FTP, NFS, WAIS、SMTP ,Telnet, Rlogin, SNMP, Gopher, SMTP, DNS
传输层 传输层 TCP, UDP
网际互联层 网络层 IP, ICMP, ARP, RARP, AKP, UUCP
网络接入层 数据链路层,物理层 FDDI, Ethernet, Arpanet, PDN, SLIP, PPP, IEEE 802.1A, IEEE 802.2到IEEE 802.11

TCP三次握手四次挥手

  • TCP 协议三次握手,四次挥手,为什么握手是三次,挥手是四次


为什么三次握手:三次握手是既保证节约资源开销,又对连接提供最好保障的次数。之所以不能是两次或者更少,是为了防止已经失效的连接请求报文段突然又传到服务端,因而产生错误。如果是两次握手,客户端发起请求,服务器确认请求,连接建立;这样,如果因为网络延迟,客户端的请求失效后才到达服务端,服务端确认后就一直等待,这样会形成一个死锁现象。
为什么是四次挥手:四次是既保证完全断开,又不会有资源浪费的最佳次数。tcp是全双工模式,客户端第一次挥手,发送FIN报文,表示自己不再发数据,但是可以接受数据;服务器返回ACK表示自己知道了客户端不会再发数据,但是服务器还要向客户端发送FIN报文,表示自己也没有要发的数据了,客户端最后确认断开,挥手结束

MAC表,ARP表,路由表

DHCP


DHCP工作原理:工作唉udp67、68端口、ipv6也有一个端口
客户端从服务端获取IP的四个租约过程:客户机请求ip,服务器相应请求,客户机选择ip,服务器确定租约。
客户机请求ip:客户端通过MAC广播,寻找DHCP服务器,请求分配IP。
服务器相应请求:DHCP服务器得到请求消息,通过广播回应,(有可能有多个DHCP同时响应,原则上谁响应的快,客户端得到谁的)。
客户机选择ip:客户端得到IP后,通过广播通知所有端口已经得到IP。
服务器确定租约:分配IP的DHCP服务器广播回应确认,并以单播方式确定租约。

DNS


DNS工作原理:工作在tcp和udp的53端口上

本地系统先在本地hosts文件中查找ip映射关系,如果没有,则查找本地DNS缓存器缓存,如果没有,则向自己设定的首选DNS服务器发起请求。

客户端向本地域名服务器的查询一般都是采用递归查询;如果主机所询问的本地域名服务器不知道被查询的域名的IP地址,那么本地域名服务器就以DNS客户的身份,向其它根域名服务器继续发出查询,而不是让客户端自己进行下一步查询。
客户端向本地域名服务器进行查询:如果本地域名服务器有缓存,则直接返回FQDN
否则:
本地域名服务器向根域名服务器的查询的迭代查询:当根域名服务器收到本地域名服务器发出的迭代查询请求时,要么给出所要查询的IP地址,要么告诉本地服务器应当继续寻找哪个域名服务器继续查询。此过程重复,直到找到对应的IP地址,或者报错。整个过程都时本地域名服务器在做查询操作。

CDN

CDN的作用


CDN加速简单的来说,就是把原服务器上数据复制到其他服务器上,用户访问时,那台服务器近访问到的就是那台服务器上的数据。CDN加速优点是成本低,速度快。可以用CDN best的CDN进行加速,免费,可部署私有,公有CDN系统。可以实现宕机检测,自动切换ip,分线路,分组解析。也就是
CDN加速
的主要作用就是保证网站的正常访问,及加快网站访问速度和响应速度,防止网站因******,DNS解析劫持故障等导致的网站服务器的宕机状况的出现。

网络访问整个流程

如:在浏览器中输入www.baidu.com后执行的全部过程

域名解析

为了将消息从 客户端 上传到服务器上, 需要用到 IP 协议、 ARP 协议和 OSPF 协议。

发起 TCP 的 3 次握手

建立 TCP 连接后发起 http 请求

服务器响应 http 请求

浏览器解析 html 代码, 并请求 html 代码中的资源(如 js、 css、 图片等)

发起TCP的四次挥手,断开 TCP 连接

防火墙

web

http 工作原理


http工作原理:
客户端与服务器建立连接后,发送一个请求给服务器,请求格式为:统一资源标识符、协议版本号。服务器收到请求的信息(包括请求行,请求头,请求体)。服务器接收到请求后,给予相应的响应信息,格式为一个状态行(包括响应行,响应头,响应体)。
在internet上,http通讯通常发生在TCP/IP连接之上。缺省端口是TCP的80端口。基于HTTP协议的客户/服务器模式的信息交换过程,分为四个过程:建立连接、发送请求信息、发送响应信息、关闭连接。服务器可能同时接受多个请求,这时就会产生多个sessoin,每个session分别处理各自的请求。

HTTP的工作过程:

  1. 地址解析:包括协议名、主机名、端口、对象路径等部分

  2. 封装HTTP请求数据包:把以上部分结合本机自己的信息,封装成一个HTTP请求数据包

  3. 封装成TCP包,建立TCP连接:TCP的三次握手

  4. 客户机发送请求命令:建立连接后,客户机发送一个请求给服务器,请求方式的格式为:统一资源标识符(URL)、协议版本号,后边是MIME信息包括请求修饰符、客户机信息和可内容。

  5. 服务器响应:服务器接到请求后,给予相应的响应信息,其格式为一个状态行,包括信息的协议版本号、一个成功或错误的代码,后边是MIME信息包括服务器信息、实体信息和可能的内容。

  6. 服务器关闭TCP连接

nginx工作原理

nginx、apache 各自的优缺点

Apache与Nginx的优缺点比较

nginx相对于apache的优点:

  1. 轻量级,同样起web 服务,比apache 占用更少的内存及资源

  2. 抗并发,nginx 处理请求是异步非阻塞的,而apache 则是阻塞型的,在高并发下nginx 能保持低资源低消耗高性能 ,从而解决C10K问题;apache是同步多进程模型,一个连接对应一个进程,nginx是异步的,多个连接(万级别)可以对应一个进程

  3. 高度模块化的设计,编写模块相对简单

  4. 社区活跃,各种高性能模块出品迅速啊

  5. 可以做反向代理服务器、负载均衡服务器,

apache 相对于nginx 的优点:

  1. rewrite 能力比nginx强大

  2. 模块超多,基本想到的都可以找到

  3. 稳定,少bug ,nginx 的bug 相对较多

  4. nginx几乎没有处理动态请求的能力

总结:需要性能的web服务,用nginx 。如果不需要性能只求稳定,那就apache

集群

HA

Keepalived

keepalive的工作原理和如何做到健康检查


keepalived是以VRRP协议为实现基础的,VRRP全称Virtual Router Redundancy Protocol,即虚拟路由冗余协议。
虚拟路由冗余协议,可以认为是实现路由器高可用的协议,即将N台提供相同功能的路由器组成一个路由器组,这个组里面有一个master和多个backup,master上面有一个对外提供服务的vip(该路由器所在局域网内其他机器的默认路由为该vip),master会发组播,当backup收不到vrrp包时就认为master宕掉了,这时就需要根据VRRP的优先级来选举一个backup当master。这样的话就可以保证路由器的高可用了。
keepalived主要有三个模块,分别是core、check和vrrp。core模块为keepalived的核心,负责主进程的启动、维护以及全局配置文件的加载和解析。check负责健康检查,包括常见的各种检查方式。vrrp模块是来实现VRRP协议的。
Keepalived健康检查方式配置
HTTP_GET|SSL_GET
HTTP_GET | SSL_GET
{
url {
path /# HTTP/SSL 检查的url可以是多个
digest <STRING> # HTTP/SSL 检查后的摘要信息用工具genhash生成
status_code 200# HTTP/SSL 检查返回的状态码
}
connect_port 80 # 连接端口
bindto<IPADD>
connect_timeout 3 # 连接超时时间
nb_get_retry 3 # 重连次数
delay_before_retry 2 #连接间隔时间
}

LB

解决高并发问题的几种思路

  1. DNS负载均衡

    
    原理:DNS服务器将一个域名解析成多个IP,实现负载均衡
    优点:简单
    缺点:DNS更新慢,如果某个IP下线,会降低服务稳定性;而且DNS有缓存机制(cdn),会使负载均衡能力不明显;请求无法均匀分配给服务器
  2. 七层负载均衡

    
    原理:在RS前配置一个DS,如haproxy、nginx。利用nginx的rewrite模块实现请求转发,属于应用层
    优点:可以对RS进行隐藏,扩展性强
    缺点:DS可能成为服务性能瓶颈,DS的TCP请求(句柄)负载翻倍,因为DS要同时和RS和客户端通信

    Nginx负载的优点是:

    1. 工作在网络七层,可以对http应用做分流策略。比如针对域名、目录结构等

    2. Nginx对网络稳定性的依赖非常小,理论上能ping通就就能进行负载功能

    3. Nginx安装和配置比较简单,测试起来比较方便,它基本能把错误用日志打印出来

    4. Nginx可以通过端口检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等

    Nginx的缺点:

    1. 只支持通过端口来检测,不支持通过url来检测

    2. Nginx仅能支持http、https和Email协议,只能对http和email服务进行负载均衡,在适用范围上面小

  3. 四层负载均衡

    
    原理:在RS前配置一个DS,如LVS。利用内核的TCP/IP协议栈进行转发(postrouting链),不经过用户层面,属于传输层
    优点:相对七层负载,并发更高,适用于电商
  4. 动态分配接入点

    
    原理:服务端提供一个"ticket服务器",存放所有RS地址信息,根据一定算法,返回给客户端一个RS的IP地址,让其自己去访问
    优点:缓解DS的负载瓶颈s

lvs的负载均衡模型

LVS的优缺点

LVS的优点:

  • 抗负载能力强、是工作在网络4层之上仅作分发之用,没有流量的产生,这个特点也决定了它在负载均衡软件里的性能最强的,对内存和cpu资源消耗比较低。

  • 配置性比较低,这是一个缺点也是一个优点,因为没有可太多配置的东西,所以并不需要太多接触,大大减少了人为出错的几率。

  • 工作稳定,因为其本身抗负载能力很强,自身有完整的双机热备方案,如LVS+Keepalived

  • 无流量,LVS只分发请求,而流量并不从它本身出去,这点保证了均衡器IO的性能不会收到大流量的影响。

  • 应用范围比较广,因为LVS工作在4层,所以它几乎可以对所有应用做负载均衡

LVS的缺点:

  • 软件本身不支持正则表达式处理,不能做动静分离

  • 不足:网站不是特别大,做lvs+keepalived比较复杂

DR

原理:负载均衡器和RS都使用同一个IP对外服务但只有DR对ARP请求进行响应,所有RS对本身这个IP的ARP请求保持静默也就是说,网关会把对这个服务IP的请求全部定向给DR,而DR收到数据包后根据调度算法,找出对应的RS,把目的MAC地址改为RS的MAC(因为IP一致)并将请求分发给这台RS这时RS收到这个数据包,处理完成之后,由于IP一致,可以直接将数据返给客户,则等于直接从客户端收到这个数据包无异,处理后直接返回给客户端由于负载均衡器要对二层包头进行改换,所以负载均衡器和RS之间必须在一个广播域,也可以简单的理解为在同一台交换机上
  
优点:和TUN(隧道模式)一样,负载均衡器也只是分发请求,应答包通过单独的路由方法返回给客户端。与VS-TUN相比,VS-DR这种实现方式不需要隧道结构,因此可以使用大多数操作系统做为物理服务器。
  
缺点:要求负载均衡器的网卡必须与物理网卡在一个物理段上。

NAT

原理:就是把客户端发来的数据包的IP头的目的地址,在负载均衡器上换成其中一台RS的IP地址,并发至此RS来处理,RS处理完成后把数据交给经过负载均衡器,负载均衡器再把数据包的原IP地址改为自己的IP,将目的地址改为客户端IP地址即可期间,无论是进来的流量,还是出去的流量,都必须经过负载均衡器
  
优点:集群中的物理服务器可以使用任何支持TCP/IP操作系统,只有负载均衡器需要一个合法的IP地址。
  
缺点:扩展性有限。当服务器节点(普通PC服务器)增长过多时,负载均衡器将成为整个系统的瓶颈,因为所有的请求包和应答包的流向都经过负载均衡器。当服务器节点过多时,大量的数据包都交汇在负载均衡器那,速度就会变慢!

TUN

原理:首先要知道,互联网上的大多Internet服务的请求包很短小,而应答包通常很大。那么隧道模式就是,把客户端发来的数据包,封装一个新的IP头标记(仅目的IP)发给RS,RS收到后,先把数据包的头解开,还原数据包,处理后,直接返回给客户端,不需要再经过负载均衡器注意,由于RS需要对负载均衡器发过来的数据包进行还原,所以说必须支持IPTUNNEL协议所以,在RS的内核中,必须编译支持IPTUNNEL这个选项
  
优点:负载均衡器只负责将请求包分发给后端节点服务器,而RS将应答包直接发给用户。所以,减少了负载均衡器的大量数据流动,负载均衡器不再是系统的瓶颈,就能处理很巨大的请求量,这种方式,一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。
  
缺点:隧道模式的RS节点需要合法IP,这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议,服务器可能只局限在部分Linux系统上。

lvs的负载均衡算法


RR、WRR、SH、DH

LC、WLC、SED、NQ、LBLC、LBLCR

静态调度算法:

  • Round Robin:轮叫,轮询

  • Weight Round Robin:加权轮询

  • Source Hashing:源地址hash实现会话绑定

  • Destination Hashing:目标地址hash

动态调度算法:

  • Least-Connection Scheduling:最少连接

  • Weighted Least-Connection Scheduling:加权最少连接,(active*256+inactive)/weight(谁的小,挑谁)

  • shortest expected delay scheduling:最少期望延迟,(active+1)*256/weight (谁的小选谁)

  • Never Queue Scheduling:永不排队

  • Locality-Based Least Connections:基于局部性的最少连接

  • Locality-Based Least Connections with Replication:基于局部性的带复制功能的最少连接

lvs 负载均衡的性能如何测试?

lvs负载均衡的性能测试包括:

  1. 基本功能测试

    • 通过Director的vip对后端RS的基本访问,包括使用的调度算法正确实现

  2. 流量压力测试

    • 流量峰值测试:流量达到一定值后的CPU,网卡IO,软中断情况等

    • 连接数峰值测试:连接数达到一定值后,内存,CPU的情况等

  3. 响应时间测试

    • 在增加LVS前后相应时间对比

  4. 配置正确性测试

    • RR算法的预期值(基本功能)

    • 多配置情况下的性能:添加上万条规则后,转发性能是否有影响

  5. 灾难恢复测试

    • 配置导出导入测试

性能优化

怎么查看磁盘IO


iostat可以提供丰富的IO状态数据,是 sysstat 工具集的一个工具。
使用iotop命令

查看网络流量的命令


watch -n 1 "/sbin/ifconfig br0 | grep bytes"
br0为网络设备名

监控

shell编程

写一个脚本,实现批量添加20个用户,用户名为:user1-20,密码为user后面跟着5个随机字符或数字


#!/bin/bash
name="user"
for number in $(seq 1 20)
do
   password=$(cat /dev/urandom | head -1 | md5sum | head -c 5)
   useradd $name$number
   echo "user$password" | passwd --stdin user$number &> /dev/null
   echo "$name$number user$password" >> userinfo.txt
done

如何向脚本传递参数 ?


猜你喜欢

转载自blog.csdn.net/fsx2550553488/article/details/80603497