运维部落

香港vps促销1G99元 点击购买 美国vps促销512M59元 点击购买 日本vps促销1G100元 点击购买

Redis 为什么变慢了?一文教你定位与排查分析

2020年11月4日 没有评论

Redis 作为内存数据库,拥有非常高的性能,单个实例的QPS能够达到10W左右。但我们在使用Redis时,经常时不时会出现访问延迟很大的情况,如果你不知道 Redis 的内部实现原理,在排查问题时就会一头雾水。
很多时候,Redis 出现访问延迟变大,都与我们的使用不当或运维不合理导致的。
这篇文章我们就来分析一下 Redis 在使用过程中,经常会遇到的延迟问题以及如何定位和分析。
使用复杂度高的命令
如果在使用Redis时,发现访问延迟突然增大,如何进行排查?
首先,第一步,建议你去查看一下Redis的慢日志。Redis提供了慢日志命令的统计功能,我们通过以下设置,就可以查看有哪些命令在执行时延迟比较大。
首先设置Redis的慢日志阈值,只有超过阈值的命令才会被记录,这里的单位是微妙,例如设置慢日志的阈值为5毫秒,同时设置只保留最近1000条慢日志记录:
# 命令执行超过5毫秒记录慢日志
CONFIG SET slowlog-log-slower-than 5000
# 只保留最近1000条慢日志
CONFIG SET slowlog-max-len 1000
设置完成之后,所有执行的命令如果延迟大于5毫秒,都会被Redis记录下来,我们执行SLOWLOG get 5查询最近5条慢日志:
127.0.0.1:6379> SLOWLOG get 5
1) 1) (integer) 32693 # 慢日志ID
2) (integer) 1593763337 # 执行时间
3) (integer) 5299 # 执行耗时(微妙)
4) 1) “LRANGE” # 具体执行的命令和参数
2) “user_list_2000″
3) “0″
4) “-1″
2) 1) (integer) 32692
2) (integer) 1593763337
3) (integer) 5044
4) 1) “GET”
2) “book_price_1000″

通过查看慢日志记录,我们就可以知道在什么时间执行哪些命令比较耗时,如果你的业务经常使用O(N)以上复杂度的命令,例如sort、sunion、zunionstore,或者在执行O(N)命令时操作的数据量比较大,这些情况下Redis处理数据时就会很耗时。
如果你的服务请求量并不大,但Redis实例的CPU使用率很高,很有可能是使用了复杂度高的命令导致的。
解决方案就是,不使用这些复杂度较高的命令,并且一次不要获取太多的数据,每次尽量操作少量的数据,让Redis可以及时处理返回。
存储 bigkey
如果查询慢日志发现,并不是复杂度较高的命令导致的,例如都是SET、DELETE操作出现在慢日志记录中,那么你就要怀疑是否存在Redis写入了bigkey的情况。
Redis在写入数据时,需要为新的数据分配内存,当从Redis中删除数据时,它会释放对应的内存空间。
如果一个key写入的数据非常大,Redis在分配内存时也会比较耗时。同样的,当删除这个key的数据时,释放内存也会耗时比较久。
你需要检查你的业务代码,是否存在写入bigkey的情况,需要评估写入数据量的大小,业务层应该避免一个key存入过大的数据量。
那么有没有什么办法可以扫描现在Redis中是否存在bigkey的数据吗?
Redis也提供了扫描bigkey的方法:
redis-cli -h $host -p $port –bigkeys -i 0.01
使用上面的命令就可以扫描出整个实例key大小的分布情况,它是以类型维度来展示的。
需要注意的是当我们在线上实例进行bigkey扫描时,Redis的QPS会突增,为了降低扫描过程中对Redis的影响,我们需要控制扫描的频率,使用-i参数控制即可,它表示扫描过程中每次扫描的时间间隔,单位是秒。
使用这个命令的原理,其实就是Redis在内部执行scan命令,遍历所有key,然后针对不同类型的key执行strlen、llen、hlen、scard、zcard来获取字符串的长度以及容器类型(list/dict/set/zset)的元素个数。
而对于容器类型的key,只能扫描出元素最多的key,但元素最多的key不一定占用内存最多,这一点需要我们注意下。不过使用这个命令一般我们是可以对整个实例中key的分布情况有比较清晰的了解。
针对 bigkey 的问题,Redis官方在4.0版本推出了lazy-free的机制,用于异步释放bigkey的内存,降低对Redis性能的影响。即使这样,我们也不建议使用bigkey,bigkey 在集群的迁移过程中,也会影响到迁移的性能,这个后面在介绍集群相关的文章时,会再详细介绍到。
集中过期
有时你会发现,平时在使用Redis时没有延时比较大的情况,但在某个时间点突然出现一波延时,而且报慢的时间点很有规律,例如某个整点,或者间隔多久就会发生一次。
如果出现这种情况,就需要考虑是否存在大量key集中过期的情况。
如果有大量的key在某个固定时间点集中过期,在这个时间点访问Redis时,就有可能导致延迟增加。
Redis 的过期策略采用主动过期+懒惰过期两种策略:
主动过期:Redis内部维护一个定时任务,默认每隔100毫秒会从过期字典中随机取出20个key,删除过期的key,如果过期key的比例超过了25%,则继续获取20个key,删除过期的key,循环往复,直到过期key的比例下降到25%或者这次任务的执行耗时超过了25毫秒,才会退出循环
懒惰过期:只有当访问某个key时,才判断这个key是否已过期,如果已经过期,则从实例中删除
注意,Redis的主动过期的定时任务,也是在Redis主线程中执行的,也就是说如果在执行主动过期的过程中,出现了需要大量删除过期key的情况,那么在业务访问时,必须等这个过期任务执行结束,才可以处理业务请求。此时就会出现,业务访问延时增大的问题,最大延迟为25毫秒。
而且这个访问延迟的情况,不会记录在慢日志里。慢日志中只记录真正执行某个命令的耗时,Redis主动过期策略执行在操作命令之前,如果操作命令耗时达不到慢日志阈值,它是不会计算在慢日志统计中的,但我们的业务却感到了延迟增大。
此时你需要检查你的业务,是否真的存在集中过期的代码,一般集中过期使用的命令是expireat或pexpireat命令,在代码中搜索这个关键字就可以了。
如果你的业务确实需要集中过期掉某些key,又不想导致Redis发生抖动,有什么优化方案?
解决方案是,在集中过期时增加一个随机时间,把这些需要过期的key的时间打散即可。
伪代码可以这么写:
这样 Redis 在处理过期时,不会因为集中删除key导致压力过大,阻塞主线程。
另外,除了业务使用需要注意此问题之外,还可以通过运维手段来及时发现这种情况。
做法是我们需要把Redis的各项运行数据监控起来,执行info可以拿到所有的运行数据,在这里我们需要重点关注expired_keys这一项,它代表整个实例到目前为止,累计删除过期key的数量。
我们需要对这个指标监控,当在很短时间内这个指标出现突增时,需要及时报警出来,然后与业务报慢的时间点对比分析,确认时间是否一致,如果一致,则可以认为确实是因为这个原因导致的延迟增大。
实例内存达到上限
有时我们把 Redis 当做纯缓存使用,就会给实例设置一个内存上限maxmemory,然后开启LRU淘汰策略。
当实例的内存达到了 maxmemory 后,你会发现之后的每次写入新的数据,有可能变慢了。
导致变慢的原因是,当Redis内存达到maxmemory后,每次写入新的数据之前,必须先踢出一部分数据,让内存维持在maxmemory之下。
这个踢出旧数据的逻辑也是需要消耗时间的,而具体耗时的长短,要取决于配置的淘汰策略:
allkeys-lru:不管key是否设置了过期,淘汰最近最少访问的key
volatile-lru:只淘汰最近最少访问并设置过期的key
allkeys-random:不管key是否设置了过期,随机淘汰
volatile-random:只随机淘汰有设置过期的key
allkeys-ttl:不管key是否设置了过期,淘汰即将过期的key
noeviction:不淘汰任何key,满容后再写入直接报错
allkeys-lfu:不管key是否设置了过期,淘汰访问频率最低的key(4.0+支持)
volatile-lfu:只淘汰访问频率最低的过期key(4.0+支持)
具体使用哪种策略,需要根据业务场景来决定。
我们最常使用的一般是 allkeys-lru或volatile-lru策略,它们的处理逻辑是,每次从实例中随机取出一批key(可配置),然后淘汰一个最少访问的key,之后把剩下的key暂存到一个池子中,继续随机取出一批key,并与之前池子中的key比较,再淘汰一个最少访问的key。以此循环,直到内存降到maxmemory之下。
如果使用的是allkeys-random或volatile-random策略,那么就会快很多,因为是随机淘汰,那么就少了比较key访问频率时间的消耗了,随机拿出一批key后直接淘汰即可,因此这个策略要比上面的LRU策略执行快一些。
但以上这些逻辑都是在访问Redis时,真正命令执行之前执行的,也就是它会影响我们访问Redis时执行的命令。
另外,如果此时Redis实例中有存储bigkey,那么在淘汰bigkey释放内存时,这个耗时会更加久,延迟更大,这需要我们格外注意。
如果你的业务访问量非常大,并且必须设置 maxmemory 限制实例的内存上限,同时面临淘汰key导致延迟增大的的情况,要想缓解这种情况,除了上面说的避免存储bigkey、使用随机淘汰策略之外,也可以考虑拆分实例的方法来缓解,拆分实例可以把一个实例淘汰key的压力分摊到多个实例上,可以在一定程度降低延迟。
fork 耗时严重
如果你的Redis开启了自动生成RDB和AOF重写功能,那么有可能在后台生成RDB和AOF重写时导致Redis的访问延迟增大,而等这些任务执行完毕后,延迟情况消失。
遇到这种情况,一般就是执行生成RDB和AOF重写任务导致的。
生成RDB和AOF都需要父进程fork出一个子进程进行数据的持久化,在fork执行过程中,父进程需要拷贝内存页表给子进程,如果整个实例内存占用很大,那么需要拷贝的内存页表会比较耗时,此过程会消耗大量的CPU资源,在完成fork之前,整个实例会被阻塞住,无法处理任何请求,如果此时CPU资源紧张,那么fork的时间会更长,甚至达到秒级。这会严重影响Redis的性能。
具体原理也可以参考我之前写的文章:Redis持久化是如何做的?RDB和AOF对比分析。
我们可以执行info命令,查看最后一次fork执行的耗时latest_fork_usec,单位微妙。这个时间就是整个实例阻塞无法处理请求的时间。
除了因为备份的原因生成RDB之外,在主从节点第一次建立数据同步时,主节点也会生成RDB文件给从节点进行一次全量同步,这时也会对Redis产生性能影响。
要想避免这种情况,我们需要规划好数据备份的周期,建议在从节点上执行备份,而且最好放在低峰期执行。如果对于丢失数据不敏感的业务,那么不建议开启AOF和AOF重写功能。
另外,fork的耗时也与系统有关,如果把Redis部署在虚拟机上,那么这个时间也会增大。所以使用Redis时建议部署在物理机上,降低fork的影响。
绑定 CPU
很多时候,我们在部署服务时,为了提高性能,降低程序在使用多个CPU时上下文切换的性能损耗,一般会采用进程绑定CPU的操作。
但在使用Redis时,我们不建议这么干,原因如下。
绑定CPU的Redis,在进行数据持久化时,fork出的子进程,子进程会继承父进程的CPU使用偏好,而此时子进程会消耗大量的CPU资源进行数据持久化,子进程会与主进程发生CPU争抢,这也会导致主进程的CPU资源不足访问延迟增大。
所以在部署 Redis 进程时,如果需要开启RDB和AOF重写机制,一定不能进行CPU绑定操作!
AOF配合不合理
上面提到了,当执行AOF文件重写时会因为fork执行耗时导致Redis延迟增大,除了这个之外,如果开启AOF机制,设置的策略不合理,也会导致性能问题。
开启AOF后,Redis会把写入的命令实时写入到文件中,但写入文件的过程是先写入内存,等内存中的数据超过一定阈值或达到一定时间后,内存中的内容才会被真正写入到磁盘中。
AOF为了保证文件写入磁盘的安全性,提供了3种刷盘机制:
appendfsync always:每次写入都刷盘,对性能影响最大,占用磁盘IO比较高,数据安全性最高
appendfsync everysec:1秒刷一次盘,对性能影响相对较小,节点宕机时最多丢失1秒的数据
appendfsync no:按照操作系统的机制刷盘,对性能影响最小,数据安全性低,节点宕机丢失数据取决于操作系统刷盘机制
当使用第一种机制appendfsync always时,Redis每处理一次写命令,都会把这个命令写入磁盘,而且这个操作是在主线程中执行的。
内存中的的数据写入磁盘,这个会加重磁盘的IO负担,操作磁盘成本要比操作内存的代价大得多。如果写入量很大,那么每次更新都会写入磁盘,此时机器的磁盘IO就会非常高,拖慢Redis的性能,因此我们不建议使用这种机制。

与第一种机制对比,appendfsync everysec会每隔1秒刷盘,而appendfsync no取决于操作系统的刷盘时间,安全性不高。因此我们推荐使用appendfsync everysec这种方式,在最坏的情况下,只会丢失1秒的数据,但它能保持较好的访问性能。

当然,对于有些业务场景,对丢失数据并不敏感,也可以不开启AOF。

使用 Swap
如果你发现Redis突然变得非常慢,每次访问的耗时都达到了几百毫秒甚至秒级,那此时就检查Redis是否使用到了Swap,这种情况下Redis基本上已经无法提供高性能的服务。

我们知道,操作系统提供了Swap机制,目的是为了当内存不足时,可以把一部分内存中的数据换到磁盘上,以达到对内存使用的缓冲。

但当内存中的数据被换到磁盘上后,访问这些数据就需要从磁盘中读取,这个速度要比内存慢太多!

尤其是针对Redis这种高性能的内存数据库来说,如果Redis中的内存被换到磁盘上,对于Redis这种性能极其敏感的数据库,这个操作时间是无法接受的。

我们需要检查机器的内存使用情况,确认是否确实是因为内存不足导致使用到了Swap。

如果确实使用到了Swap,要及时整理内存空间,释放出足够的内存供Redis使用,然后释放Redis的Swap,让Redis重新使用内存。

释放Redis的Swap过程通常要重启实例,为了避免重启实例对业务的影响,一般先进行主从切换,然后释放旧主节点的Swap,重新启动服务,待数据同步完成后,再切换回主节点即可。

可见,当Redis使用到Swap后,此时的Redis的高性能基本被废掉,所以我们需要提前预防这种情况。

我们需要对Redis机器的内存和Swap使用情况进行监控,在内存不足和使用到Swap时及时报警出来,及时进行相应的处理。

网卡负载过高
如果以上产生性能问题的场景,你都规避掉了,而且Redis也稳定运行了很长时间,但在某个时间点之后开始,访问Redis开始变慢了,而且一直持续到现在,这种情况是什么原因导致的?
之前我们就遇到这种问题,特点就是从某个时间点之后就开始变慢,并且一直持续。这时你需要检查一下机器的网卡流量,是否存在网卡流量被跑满的情况。
网卡负载过高,在网络层和TCP层就会出现数据发送延迟、数据丢包等情况。Redis的高性能除了内存之外,就在于网络IO,请求量突增会导致网卡负载变高。
如果出现这种情况,你需要排查这个机器上的哪个Redis实例的流量过大占满了网络带宽,然后确认流量突增是否属于业务正常情况,如果属于那就需要及时扩容或迁移实例,避免这个机器的其他实例受到影响。
运维层面,我们需要对机器的各项指标增加监控,包括网络流量,在达到阈值时提前报警,及时与业务确认并扩容。
总结
以上我们总结了Redis中常见的可能导致延迟增大甚至阻塞的场景,这其中既涉及到了业务的使用问题,也涉及到Redis的运维问题。
可见,要想保证Redis高性能的运行,其中涉及到CPU、内存、网络,甚至磁盘的方方面面,其中还包括操作系统的相关特性的使用。
作为开发人员,我们需要了解Redis的运行机制,例如各个命令的执行时间复杂度、数据过期策略、数据淘汰策略等,使用合理的命令,并结合业务场景进行优化。
作为DBA运维人员,需要了解数据持久化、操作系统fork原理、Swap机制等,并对Redis的容量进行合理规划,预留足够的机器资源,对机器做好完善的监控,才能保证Redis的稳定运行。

分类: Linux 标签:

一文理解 Linux 平均负载,附排查工具(转)

2020年10月4日 没有评论

什么是平均负载

平均负载可以对于我们来说及熟悉又陌生,但我们问平均负载是什么,但大部分人都回答说平均负载不就是单位时间内CPU使用率吗?其实并不是这样的,如果可以的话,可以 man uptime 来了解一下平均负载的详细信息。

简单的说平均负载是指单位时间内,系统处于可运行状态和不可中断状态的平均进程数,也就是说平均活跃进程数,它和CPU使用率并没有直接关系。这里解释一下可运行状态和不可中断这两个词。

可运行状态:

  • 指正在使用CPU或者正在等待CPU的进程,我们使用ps命令查看处于R状态的进程

不可中断状态:

  • 进程则是正处于内核态关键流程中的进程,并且这些流程是不可中断的。例如:常见的等待硬件设备I/O的响应,也就是我们在ps命令查看处于D状态的进程

比如,当一个进程向磁盘读写数据时,为了保证数据的一致性,在得到磁盘回复前,它是不能被其他进程中断或者打断的,这个时候的进程处于不可中断状态,如果此时的进程被打断了,就容易出现磁盘数据和进程数据不一致的问题。

所以,不可中断状态实际上是系统进程和硬件设备的一种保护机制。

因此,你可以简单理解为,平均负载就是平均活跃进程数。平均活跃进程数,直观上的理解就是单位时间内的活跃进程数,但它实际上是活跃进程数的指数衰减平均值。既然是平均活跃进程数,那么理想状态,就是每个CPU上都刚好运行着一个进程,这样每个CPU都会得到充分的利用。例如平均负载为2时,意味着什么呢?

  • 在只有2个CPU的系统上,意味着所有的CPU刚好被完全占用
  • 在4个CPU的系统上,意味着CPU有50%的空闲
  • 而在只有1个CPU的系统上,则意味着有一半的进程竞争不到CPU

平均负载和CPU使用率

现实工作中,我们经常容易把平均负载和CPU使用率混淆,所以在这里,我也做一个分区。

可能你会疑惑,既然平均负载代表的是活跃进程数,那平均负载高了,不就意味着CPU使用率高吗?

我们还是要回到平均负载的含义上来,平均负载是指单位时间内,处于可运行状态和不可中断状态的进程数,所以,它不仅包括了正常使用CPU的进程,还包括了等待CPU和等待I/O的进程。

而CPU使用率,是单位时间内CPU的繁忙情况的统计,跟平均负载并不一定完全对应,例如:

  • CPU密集型进程,使用大量CPU会导致平均负载升高,此时这两者是一致的
  • I/O密集型进程,等待I/O也会导致平均负载升高,但CPU使用率不一定很高
  • 大量等待CPU的进程调度也会导致平均负载升高,此时的CPU使用率会很高

平均负载案例

这里我们需要安装几个工具sysstat、stress、stress-ng

这里Centos的sysstat版本会老一点,最好升级到最新版本。手动rpm安装或者源码安装

场景一、CPU密集型

1、运行一个stress命令,模拟一个CPU使用率100%场景

$ stress --cpu 1 --timeout 600

2、开启第二个终端,uptime查看平均负载的变化情况

$ watch -d uptime 09:40:35 up 80 days, 18:41, 2 users, load average: 1.62, 1.10, 0.87

3、开启第三个终端,mpstat 查看CPU使用率的变化情况

$ mpstat -P ALL 5 2010:06:37 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle10:06:42 AM all 31.50 0.00 0.35 0.00 0.00 0.00 0.00 0.00 0.00 68.1510:06:42 AM 0 1.20 0.00 0.80 0.00 0.00 0.00 0.00 0.00 0.00 98.0010:06:42 AM 1 7.21 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 92.3810:06:42 AM 2 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.0010:06:42 AM 3 17.43 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 82.36# -P ALL 表示监控所有CPU,后面数字5 表示间隔5秒输出一次数据

从第二个终端可以看到,1分钟平均负载增加到1.62,从第三个终端我们可以看到有一个CPU使用率100%,但iowait为0,这说明平均负载的升高正式由CPU使用率为100%

那我们查看是那个进程导致了CPU使用率为100%呢?我们可以使用pidstat来查看:

#每5秒输出一次数据$ pidstat -u 5 1 10:08:41 AM UID PID %usr %system %guest %wait %CPU CPU Command10:08:46 AM 0 1 0.20 0.00 0.00 0.00 0.20 0 systemd10:08:46 AM 0 599 0.00 1.00 0.00 0.20 1.00 0 systemd-journal10:08:46 AM 0 1043 0.60 0.00 0.00 0.00 0.60 0 rsyslogd10:08:46 AM 0 6863 100.00 0.00 0.00 0.00 100.00 3 stress10:08:46 AM 0 7303 0.20 0.20 0.00 0.00 0.40 2 pidstat

从这里我们可以看到是stress这个进程导致的。

场景二、I/O密集型进程

1、我们使用stress-ng命令,但这次模拟I/O压力,既不停执行sync:

#--hdd表示读写临时文件 #-i 生成几个worker循环调用sync()产生io压力 $ stress-ng -i 4 --hdd 1 --timeout 600

2、开启第二个终端运行uptime查看平均负载情况

$ watch -d uptime 10:30:57 up 98 days, 19:39, 3 users, load average: 1.71, 0.75, 0.69

3、开启第三个终端运行mpstat查看CPU使用率

 

$ mpstat -P ALL 5 2010:32:09 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle10:32:14 AM all 6.80 0.00 33.75 26.16 0.00 0.39 0.00 0.00 0.00 32.9010:32:14 AM 0 4.03 0.00 69.57 19.91 0.00 0.00 0.00 0.00 0.00 6.4910:32:14 AM 1 25.32 0.00 9.49 0.00 0.00 0.95 0.00 0.00 0.00 64.2410:32:14 AM 2 0.24 0.00 10.87 63.04 0.00 0.48 0.00 0.00 0.00 25.3610:32:14 AM 3 1.42 0.00 36.93 14.20 0.00 0.28 0.00 0.00 0.00 47.16

 

从这里可以看到,1分钟平均负载会慢慢增加到1.71,其中一个CPU的系统CPU使用率升到63.04。这说明,平均负载的升高是由于iowait升高。

那么我们到底是哪个进程导致的呢?我们使用pidstat来查看:

$ pidstat -u 5 1Average: UID PID %usr %system %guest %wait %CPU CPU CommandAverage: 0 1 0.00 0.19 0.00 0.00 0.19 - systemdAverage: 0 10 0.00 0.19 0.00 1.56 0.19 - rcu_schedAverage: 0 599 0.58 1.75 0.00 0.39 2.33 - systemd-journalAverage: 0 1043 0.19 0.19 0.00 0.00 0.39 - rsyslogdAverage: 0 6934 0.00 1.56 0.00 1.17 1.56 - kworker/2:0-events_power_efficientAverage: 0 7383 0.00 0.39 0.00 0.78 0.39 - kworker/1:0-events_power_efficientAverage: 0 9411 0.00 0.19 0.00 0.58 0.19 - kworker/0:0-eventsAverage: 0 9662 0.00 97.67 0.00 0.19 97.67 - kworker/u8:0+flush-253:0Average: 0 10793 0.00 0.97 0.00 1.56 0.97 - kworker/3:2-mm_percpu_wqAverage: 0 11062 0.00 21.79 0.00 0.19 21.79 - stress-ng-hddAverage: 0 11063 0.00 1.95 0.00 1.36 1.95 - stress-ng-ioAverage: 0 11064 0.00 2.72 0.00 0.39 2.72 - stress-ng-ioAverage: 0 11065 0.00 1.36 0.00 1.75 1.36 - stress-ng-ioAverage: 0 11066 0.00 2.72 0.00 0.58 2.72 - stress-ng-io

可以发现是stress-ng导致的

场景三、大量进程的场景

当系统中运行进程超出CPU运行能力时,就会出现等待CPU的进程。

比如:我们使用stress,但这次模拟8个进程:

$ stress -c 8 --timeout 600

我们的系统只有4颗CPU,这时候要运行8个进程,是明显不够的,系统的CPU后严重过载,这时候负载值达到了4点多:

$ uptime 10:56:22 up 98 days, 20:05, 3 users, load average: 4.52, 2.82, 2.67

接着我们运行pidstat来查看一下进程的情况:

$ pidstat -u 5 1Linux 5.0.5-1.el7.elrepo.x86_64 (k8s-m1) 07/11/2019 _x86_64_ (4 CPU) 10:57:33 AM UID PID %usr %system %guest %wait %CPU CPU Command10:57:38 AM 0 1 0.20 0.00 0.00 0.00 0.20 1 systemd10:57:38 AM 0 599 0.00 0.99 0.00 0.20 0.99 2 systemd-journal10:57:38 AM 0 1043 0.60 0.20 0.00 0.00 0.79 1 rsyslogd10:57:38 AM 0 12927 51.59 0.00 0.00 48.21 51.59 0 stress10:57:38 AM 0 12928 44.64 0.00 0.00 54.96 44.64 0 stress10:57:38 AM 0 12929 45.44 0.00 0.00 54.56 45.44 2 stress10:57:38 AM 0 12930 45.44 0.00 0.00 54.37 45.44 2 stress10:57:38 AM 0 12931 51.59 0.00 0.00 48.21 51.59 3 stress10:57:38 AM 0 12932 48.41 0.00 0.00 51.19 48.41 1 stress10:57:38 AM 0 12933 45.24 0.00 0.00 54.37 45.24 3 stress10:57:38 AM 0 12934 48.81 0.00 0.00 50.99 48.81 1 stress10:57:38 AM 0 13083 0.00 0.40 0.00 0.20 0.40 0 pidstat

可以看出,8个进程抢占4颗CPU,每个进程等到CPU时间(%wait)高达50%,这些都超出CPU计算能力的进程,最终导致CPU过载。

分类: Linux 标签:

一文详解负载均衡和反向代理的真实区别(转)

2020年9月25日 没有评论

一、SLB 产生背景

 

SLB(服务器负载均衡):在多个提供相同服务的服务器的情况下,负载均衡设备存在虚拟服务地址,当大量客户端从外部访问虚拟服务IP地址时,负载均衡设备将这些报文请求根据负载均衡算法,将流量均衡的分配给后台服务器以平衡各个服务器的负载压力,避免在还有服务器压力较小情况下其他服务达到性能临界点出现运行缓慢甚至宕机情况,从而提高服务效率和质量。
因此对客户端而言,RS(real server 实际服务器)的IP地址即是负载均衡设备VIP(虚拟服务地址IP)地址,真正的RS服务器IP地址对于客户端是不可见的。

 

二、SLB 的三种传输模式

 

七层SLB和四层SLB的区别:
四层SLB:配置负载均衡设备上服务类型为tcp/udp,负载均衡设备将只解析到4层,负载均衡设备与client三次握手之后就会和RS建立连接;
七层SLB:配置负载均衡设备服务类型为 http/ftp/https 等,负载均衡设备将解析报文到7层,在负载均衡设备与client三次握手之后,只有收到对应七层报文,才会跟RS建立连接。
在负载均衡设备中,SLB主要工作在以下的三种传输模式中:

 

  • 反向代理模式
  • 透传模式
  • 三角模式

 

根据不同的模式,负载均衡设备的工作方式也不尽相同,但无论在哪种模式下,客户端发起的请求报文总是需要先到达负载均衡设备进行处理,这是负载均衡设备正常工作的前提。模拟网络拓扑环境:

 

  • Client:10.8.21.40
  • 负载均衡设备:172.16.75.83
  • VIP:172.16.75.84
  • RS1IP:172.16.75.82
  • RS2IP:172.16.75.85

 

在整个报文交互过程中,采用 Tcpdump 和 Wireshark 分别在 RS 和 Client 处抓包,然后使用 Wireshark 进行报文解析。

 

三、 反向代理模式

 

反向代理:普通的代理设备是内网用户通过代理设备出外网进行访问,而工作在这种模式下的负载均衡设备,则是外网用户通过代理设备访问内网,因此称之为反向代理。
在反向代理模式下:
当负载均衡设备收到客户端请求后,会记录下此报文( 源IP地址、目的IP地址、协议号、源端口、目的端口,服务类型以及接口索引),将报文目的地址更改为优选后的RS设备的IP地址,目的端口号不变,源地址修改为负载均衡设备下行与对应RS设备接口的IP地址,源端口号随机发送给RS;
当RS收到报文后,会以源为RS接口IP地址,目的IP设备地址回复给负载均衡设备,负载均衡设备将源修改为VIP,目的端口号修改为客户端的源端口号,目的IP修改为Client的源IP回复报文。
查看报文解析结果:
配置完成后,Client 访问 RS 服务器,返回成功,整个报文交互过程如下 :
Client和负载均衡设备之间的报文交互过程
RS和负载均衡设备之间报文交互过程
结果分析
分析整个报文交互过程:
TCP握手过程:首先Client向负载均衡设备发送TCP SYN报文请求建立连接,源IP为Client的IP 10.8.21.40,源端口号50894,目的IP为VIP地址172.16.75.84,目的端口号80;
收到请求报文后,负载均衡设备会以源IP为VIP地址172.16.75.84,端口号80,目的IP 10.8.21.40,目的端口号50894回应SYN ACK报文;
Client收到报文后回复ACK报文,TCP三次握手成功。
HTTP报文交互过程:
当负载均衡设备与client完成三次握手后,因为配置的七层SLB,如果收到HTTP请求,就会根据负载均衡算法和服务器健康状态优选出对应的RS(在这次过程中选择的RS设备为172.16.75.82),然后与RS建立TCP连接:
负载均衡设备发送 TCP SYN 报文请求连接,源IP为负载均衡设备与RS相连接口IP 172.16.75.83,源端口号随机4574,目的IP为RS的IP 172.16.75.82,目的端口号80;
RS 收到报文后,以源 IP 172.16.75.82,端口号80,目的IP 172.16.75.83,目的端口号4574回复SYN ACK报文,负载均衡设备回复ACK报文建立三次握手;
之后,负载均衡设备再将收到的HTTP报文源IP修改为与RS相连下行接口IP地址172.16.75.83,源端口号为随机端口号,将报文发送给RS;当RS收到报文后,使用源为本地IP 172.16.75.82,目的IP为172.16.75.83进行回复,所以报文直接回复给负载均衡设备;
当负载均衡设备收到RS的回应报文后,将报文的源修改为VIP地址172.16.75.84,目的IP为10.8.21.40发送回 Client,再将目的端口号修改为HTTP请求报文中的源端口号,服务器访问成功。
由上述的过程可以看出,在RS端上,client的真实IP地址被负载设备修改成与RS相连接口的IP地址,所以RS无法记录到Client的访问记录,为了解决这个问题,可以采用在HTTP报文头中添加X-Forwarded-For字段,本文不做赘述,可以自行查询。

 

四、透传模式

 

当负载均衡设备工作在透传模式中时,RS无法感知到负载均衡设备的存在,对于Client来说,RS的IP地址就是负载均衡设备的VIP地址。
在这种模式下,当负载均衡设备收到源为 Client 的 IP,目的 IP 为本地 VIP 地址的报文时,会将报文根据负载均衡策略和健康状况发送给最优的 RS 设备上,继而RS设备会收到目的为本地IP,源为Client实际IP的请求报文;
然后RS将会直接回应此请求,报文的目的 IP 地址为 Client 的 IP 地址,当负载均衡设备收到此报文后,将源 IP 地址修改为 VIP 地址,然后将报文发送给 Client。
报文解析结果:
同样在 RS 端和 Client 端抓取交互报文:
Client 和负载均衡设备之间的报文交互过程

 

RS和负载均衡设备之间的报文交互过程

结果分析:

TCP握手过程:同反向代理模式交互过程

HTTP报文交互过程:

Client向负载均衡设备的VIP地址172.16.75.84以源IP 10.8.21.40发送HTTP请求,当负载均衡设备收到报文后,与优选后的RS进行TCP三次握手,过程同反向代理模式,然后将收到的HTTP报文,不改变报文的源IP地址和源/目的端口号,只修改目的IP修改为优选后的RS地址172.16.75.82;

当RS收到源来自IP 10.8.21.40的报文后,回复报文给IP地址10.8.21.40,此时要注意,必须在RS上配置回复报文经过负载均衡设备,负载均衡设备会将源IP修改为VIP地址172.16.75.84,然后转发给Client,否则Client将会收到源IP为172.16.75.82的HTTP报文,服务器访问失败。

 

 

五、 三角模式

 

在三角模式下,当客户端发送请求到负载设备上时,负载均衡设备会计算出最优RS,然后直接根据MAC地址将报文转发给RS,在RS上配置报文的源IP为VIP地址(一般配置在loopback口上),因此在这种情况下,RS会直接将报文发送给Client,即使回复报文经过负载均衡设备,此设备不做任何处理。由于报文在整个过程中传输途径类似于三角形,因此称之为三角模式。
报文解析结果
分别在Client端和RS端抓包,内容如下:
Client和负载均衡设备之间的报文交互过程
RS 和负载均衡设备之间的报文交互过程

 

结果分析

 

TCP握手过程:
由于采用了4层SLB,所以在TCP握手过程中与上述的7层SLB有些不同,当Client和RS完成三次握手之后,此时负载均衡设备会直接选择RS,然后跟RS建立TCP三次握手;
在三角模式环境中,由于RS的Loopback口和负载均衡设备上都存在着VIP地址172.16.75.84,当负载均衡设备经过负载均衡算法选择出对应的RS后,会根据实际配置的RS的IP地址对应的mac地址,将报文以目的mac为RS,目的IP为VIP的方式建立TCP连接。
HTTP报文交互过程:
首先Client向负载均衡设备的VIP发送HTTP请求,源为10.8.21.40,当负载均衡设备收到报文后,将报文直接转发给RS,当RS收到源IP为10.8.21.40,目的IP为本地Loopback口IP地址172.16.75.84的报文后,直接将报文回复给10.8.21.40,同样源为IP地址172.16.75.84,由此访问服务器成功。
在三角模式中,由于回复报文负载均衡设备不做任何处理,所以非常适合于RS到Client方向流量较大或者连接数目较多的组网环境。
采用三角模式时,必须注意RS有路由可以到达Client,并且在RS的Loopback接口上必须有负载均衡设备的VIP地址,否则即使RS设备收到Client的请求报文也会直接丢弃报文,不作回应。

 

六、总结

 

由于反向代理模式中在RS侧只能收到源为负载均衡设备IP的报文,因此可以使用防火墙增加安全性,只允许源IP为负载均衡设备的IP地址的报文通过,同时增加X-Forwarded-For字段也可以让RS只允许有此字段的报文进行访问,因此安全性相对较高。
作者:蹦蹦啪
链接:https://www.zhihu.com/question/20553431/answer/130698230

 

cisco 2960升级iso步骤

2020年8月3日 没有评论

手上有一台老的WS-C2960-48TT-L 交换机。要配置一些策略。还有ssh2、acl,发现无法进行命令不支持。查了下。原因是自己的iso太旧。不带k9的rom是不支持更多指令和相关功能的。

决定升级iso。步骤记录下来了。希望对大家有帮助。要用到一个工具。网上也有的下。主要就是bin的iso文件比较麻烦。

找了下,还是有好心人存了百度网盘。共享给大家:

https://yun.baidu.com/s/1gdCpCXX?errno=0&errmsg=Auth%20Login%20Sucess&&bduss=&ssnerror=0&traceid=

工具Cisco TFTP Server 建议在win7 win2008 win2012下使用。win10不支持

1、 配置IP地址好上传iOS和config.text文件

Switch#conf t

Switch(config)#int vlan 1

Switch(config)#ip add 192.168.0.254 255.255.0.0

Switch(config)#no shut

Switch(config)#end

Switch#ping 192.168.0.100 //电脑上配置的IP,要和上面的地址在一个网段

//ping通后说明网络没问题了,可以上传iOS和配置文件了

//把网线插入交换机的任意口,因为默认都在vlan1里

2、 上传iOS和配置文件

Switch#copy tftp: flash:

提示输入远程主机 192.168.0.100

提示输入要传的文件名(要注意带上后缀)c2960-lanbasek9-mz.122-50.SE10.bin

提示目的地文件名c2960-lanbasek9-mz.122-50.SE10.bin

传输开始,同上在把config.text文件也上传

3、 修改引导镜像

Switch#config t

Switch(config)#boot system flash: c2960-lanbasek9-mz.122-50.SE10.bin

Switch(config)#end

Switch#wr

Switch#reload

重启后进入查看是否启动新iOS,show version

确认后,copy flash:config.text system:running-config

Wr保存,至此升级和跟新配置完毕

分类: 解决方案 标签: ,

ubuntu18.04配置静态ip

2020年7月10日 没有评论

注意: 18.04和16.04不一样了,配置静态ip的方法有很大差异!

查找netplan目录下默认的网络配置文件,文件后缀为.yaml,我的是叫01-network-manager-all.yaml的文件。如果没有可以使用sudo gedit 01-network-manager-all.yam自己创建。

编辑网络配置文件01-network-manager-all.yaml,内容如下:
# Let NetworkManager manage all devices on this system
network:
version: 2
renderer: NetworkManager
ethernets:
enp3s0: #配置的网卡名称,使用ifconfig -a查看得到
dhcp4: no #dhcp4关闭
addresses: [192.168.202.36/24] #设置本机IP及掩码
gateway4: 192.168.202.1 #设置网关
nameservers:
addresses: [192.168.202.1] #设置DNS

使用命令,使静态ip生效。
$ sudo netplan apply

误删/usr文件夹解决办法

2020年6月10日 没有评论

几个参考资料:

http://blog.chinaunix.net/uid-2623904-id-3044156.html

http://blog.csdn.net/xyw_blog/article/details/12996969

一般用光盘的救援模式解决,救援模式有什么作用:

◆可以更改root密码;
◆恢复硬盘、文件系统操作;
◆系统启动不来的时候,只能通过救援模式来启动;

进入resume模式。在进入resume模式过程中,会提示你的系统挂载在哪个位置。
一般挂载在/mnt/sysimage目录下。在/mnt/sysimage下有你系统的所有目录和文件,你可以根据你的需要将这些数据拷贝下来。

最后,进入bash模式.由于我是覆盖了我usr下得数据,我只需要覆盖/mnt/sysimage/下得usr目录即可。
cp -r /usr/ /mnt/sysimage/
ls /mnt/sysimage/usr (查看是否复制成功)
重启虚拟机,设置启动顺序。系统就成功修复了。(能使用基本命令)

在另一台与机器A相同的机器B上,使用tar命令将/usr目录打包。然后通过scp传给机器A,在A上将其解压,删除之前用Rescue模式拷贝进来的/usr目录,使用传递过来的usr目录,重启系统,现在可以正常进入系统了。但是存在的问题是,之前在系统中安装的软件需要重新编译安装。

分类: Linux, 解决方案 标签: ,

宝塔等Nginx环境添加允许跨域Header头问题补充

2020年5月2日 没有评论

宝塔等Nginx环境添加允许跨域Header头

我已宝塔面板为例:
点击站点修改
点击配置文件
在 39 行下面添加
add_header ‘Access-Control-Allow-Origin’ ‘*’;
add_header ‘Access-Control-Allow-Credentials’ ‘true’;
add_header ‘Access-Control-Allow-Methods’ ‘GET, POST, OPTIONS’;
然后重启 nginx.
下面是通用 nginx 添加允许跨域header头

使用ngx_http_headers_module中的add_header指令,在响应头中添加允许跨域。

Syntax: add_header name value [always];
Default: —
Context: http, server, location, if in location
一般地,我们把允许跨域的头加在动态接口后面,比如 php,就加在解析 php 后面

add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Headers X-Requested-With;
add_header Access-Control-Allow-Methods GET,POST;
注意,在实际中 Allow-Origin 不要指定为*,要设置为允许访问的域名,比如 http://abc.com

nginx通过CORS实现跨域

2020年4月10日 没有评论

1.CORS是一个W3C标准,全称是跨域资源共享(Cross-origin resource sharing)。它允许浏览器向跨源服务器,发出XMLHttpRequest请求,从而克服了AJAX只能同源使用的限制。
当前几乎所有的浏览器(Internet Explorer 8+, Firefox 3.5+, Safari 4+和 Chrome 3+)都可通过名为跨域资源共享(Cross-Origin Resource Sharing)的协议支持AJAX跨域调用。
Chrome,Firefox,Opera,Safari都使用的是XMLHttpRequest2对象,IE使用XDomainRequest。
简单来说就是跨域的目标服务器要返回一系列的Headers,通过这些Headers来控制是否同意跨域。跨域资源共享(CORS)也是未来的跨域问题的标准解决方案。
CORS提供如下Headers,Request包和Response包中都有一部分。

2.HTTP Response Header

Access-Control-Allow-Origin
Access-Control-Allow-Credentials
Access-Control-Allow-Methods
Access-Control-Allow-Headers
Access-Control-Expose-Headers
Access-Control-Max-Age
HTTP Request Header

Access-Control-Request-Method
Access-Control-Request-Headers
其中最敏感的就是Access-Control-Allow-Origin这个Header, 它是W3C标准里用来检查该跨域请求是否可以被通过。(Access Control Check)。如果需要跨域,解决方法就是在资源的头中加入Access-Control-Allow-Origin 指定你授权的域。
启用CORS请求

假设您的应用已经在example.com上了,而您想要从www.example2.com提取数据。一般情况下,如果您尝试进行这种类型的AJAX调用,请求将会失败,而浏览器将会出现源不匹配的错误。利用CORS后只需www.example2.com 服务端添加一个HTTP Response头,就可以允许来自example.com的请求。

将Access-Control-Allow-Origin添加到某网站下或整个域中的单个资源

Access-Control-Allow-Origin: http://example.com
Access-Control-Allow-Credentials: true (可选)
将允许任何域向您提交请求

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true (可选)
3.提交跨域请求

如果服务器端已启用了CORS,那么提交跨域请求就和普通的XMLHttpRequest请求没什么区别。例如现在example.com可以向www.example2.com提交请求。

var xhr = new XMLHttpRequest();
// xhr.withCredentials = true; //如果需要Cookie等
xhr.open(‘GET’, ‘http://www.example2.com/hello.json’);
xhr.onload = function(e) {
var data = JSON.parse(this.response);

}
xhr.send();选)
对于简单请求,如GET,只需要在HTTP Response后添加Access-Control-Allow-Origin。
对于非简单请求,比如POST、PUT、DELETE等,浏览器会分两次应答。第一次preflight(method: OPTIONS),主要验证来源是否合法,并返回允许的Header等。第二次才是真正的HTTP应答。所以服务器必须处理OPTIONS应答。
流程如下

首先查看http头部有无origin字段;
如果没有,或者不允许,直接当成普通请求处理,结束;
如果有并且是允许的,那么再看是否是preflight(method=OPTIONS);
如果是preflight,就返回Allow-Headers、Allow-Methods等,内容为空;
如果不是preflight,就返回Allow-Origin、Allow-Credentials等,并返回正常内容。
用伪代码表示

location /pub/(.+) {
if ($http_origin ~ <允许的域(正则匹配)>) {
add_header ‘Access-Control-Allow-Origin’ “$http_origin”;
add_header ‘Access-Control-Allow-Credentials’ “true”;
if ($request_method = “OPTIONS”) {
add_header ‘Access-Control-Max-Age’ 86400;
add_header ‘Access-Control-Allow-Methods’ ‘GET, POST, OPTIONS, DELETE’;
add_header ‘Access-Control-Allow-Headers’ ‘reqid, nid, host, x-real-ip, x-forwarded-ip, event-type, event-id, accept, content-type’;
add_header ‘Content-Length’ 0;
add_header ‘Content-Type’ ‘text/plain, charset=utf-8′;
return 204;
}
}
# 正常nginx配置
……
}
Nginx配置实例
实例一:允许example.com的应用在www.example2.com上跨域提取数据

在nginx.conf里找到server项,并在里面添加如下配置

location /{

add_header ‘Access-Control-Allow-Origin’ ‘http://example.com’;
add_header ‘Access-Control-Allow-Credentials’ ‘true’;
add_header ‘Access-Control-Allow-Headers’ ‘Authorization,Content-Type,Accept,Origin,User-Agent,DNT,Cache-Control,X-Mx-ReqToken,X-Requested-With’;
add_header ‘Access-Control-Allow-Methods’ ‘GET,POST,OPTIONS’;

}
如果需要允许来自任何域的访问,可以这样配置

add_header Access-Control-Allow-Origin *;
注释如下

第一条指令:授权从example.com的请求(必需)

第二条指令:当该标志为真时,响应于该请求是否可以被暴露(可选)

第三条指令:允许脚本访问的返回头(可选)

第四条指令:指定请求的方法,可以是GET, POST, OPTIONS, PUT, DELETE等(可选)

重启Nginx

$ service nginx reload
测试跨域请求

$ curl -I -X OPTIONS -H “Origin: http://example.com” http://www.example2.com
成功时,响应头是如下所示

HTTP/1.1 200 OK
Server: nginx
Access-Control-Allow-Origin: example.com
实例二:Nginx允许多个域名跨域访问

由于Access-Control-Allow-Origin参数只允许配置单个域名或者 * ,当我们需要允许多个域名跨域访问时可以用以下几种方法来实现。

方法一
如需要允许用户请求来自www.example.com、m.example.com、wap.example.com访问www.example2.com域名时,返回头Access-Control-Allow-Origin,具体配置如下

在nginx.conf里面,找到server项,并在里面添加如下配置

map $http_origin $corsHost {
default 0;
“~http://www.example.com” http://www.example.com;
“~http://m.example.com” http://m.example.com;
“~http://wap.example.com” http://wap.example.com;
}

server
{
listen 80;
server_name www.example2.com;
root /usr/share/nginx/html;
location /
{
add_header Access-Control-Allow-Origin $corsHost;
}
}
方法二
如需要允许用户请求来自localhost、www.example.com或m.example.com的请求访问xxx.example2.com域名时,返回头Access-Control-Allow-Origin,具体配置如下

在Nginx配置文件中xxx.example2.com域名的location /下配置以下内容

set $cors ”;
if ($http_origin ~* ‘https?://(localhost|www\.example\.com|m\.example\.com)’) {
set $cors ‘true’;
}

if ($cors = ‘true’) {
add_header ‘Access-Control-Allow-Origin’ “$http_origin”;
add_header ‘Access-Control-Allow-Credentials’ ‘true’;
add_header ‘Access-Control-Allow-Methods’ ‘GET, POST, PUT, DELETE, OPTIONS’;
add_header ‘Access-Control-Allow-Headers’ ‘Accept,Authorization,Cache-Control,Content-Type,DNT,If-Modified-Since,Keep-Alive,Origin,User-Agent,X-Mx-ReqToken,X-Requested-With’;
}

if ($request_method = ‘OPTIONS’) {
return 204;
}
方法三
如需要允许用户请求来自*.example.com访问xxx.example2.com域名时,返回头Access-Control-Allow-Origin,具体配置如下

在Nginx配置文件中xxx.example2.com域名的location /下配置以下内容

if ( $http_origin ~ http://(.*).example.com){
set $allow_url $http_origin;
}
#CORS(Cross Orign Resource-Sharing)跨域控制配置
#是否允许请求带有验证信息
add_header Access-Control-Allow-Credentials true;
#允许跨域访问的域名,可以是一个域的列表,也可以是通配符*
add_header Access-Control-Allow-Origin $allow_url;
#允许脚本访问的返回头
add_header Access-Control-Allow-Headers ‘x-requested-with,content-type,Cache-Control,Pragma,Date,x-timestamp’;
#允许使用的请求方法,以逗号隔开
add_header Access-Control-Allow-Methods ‘POST,GET,OPTIONS,PUT,DELETE’;
#允许自定义的头部,以逗号隔开,大小写不敏感
add_header Access-Control-Expose-Headers ‘WWW-Authenticate,Server-Authorization’;
#P3P支持跨域cookie操作
add_header P3P ‘policyref=”/w3c/p3p.xml”, CP=”NOI DSP PSAa OUR BUS IND ONL UNI COM NAV INT LOC”‘;
方法四
如需要允许用户请求来自xxx1.example.com或xxx1.example1.com访问xxx.example2.com域名时,返回头Access-Control-Allow-Origin,具体配置如下

在Nginx配置文件中xxx.example2.com域名的location /下配置以下内容

location / {

if ( $http_origin ~ .*.(example|example1).com ) {
add_header Access-Control-Allow-Origin $http_origin;
}
}
实例三:Nginx跨域配置并支持DELETE,PUT请求

默认Access-Control-Allow-Origin开启跨域请求只支持GET、HEAD、POST、OPTIONS请求,使用DELETE发起跨域请求时,浏览器出于安全考虑会先发起OPTIONS请求,服务器端接收到的请求方式就变成了OPTIONS,所以引起了服务器的405 Method Not Allowed。

解决方法

首先要对OPTIONS请求进行处理

if ($request_method = ‘OPTIONS’) {
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Methods GET,POST,PUT,DELETE,OPTIONS;
#其他头部信息配置,省略…
return 204;
}
当请求方式为OPTIONS时设置Allow的响应头,重新处理这次请求。这样发出请求时第一次是OPTIONS请求,第二次才是DELETE请求。

# 完整配置参考
# 将配置文件的放到对应的server {}里

add_header Access-Control-Allow-Origin *;

location / {
if ($request_method = ‘OPTIONS’) {
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Methods GET,POST,PUT,DELETE,OPTIONS;
return 204;
}
index index.php;
try_files $uri @rewriteapp;
}
实例四:更多配置示例

示例一

The following Nginx configuration enables CORS, with support for preflight requests.

#
# Wide-open CORS config for nginx
#
location / {
if ($request_method = ‘OPTIONS’) {
add_header ‘Access-Control-Allow-Origin’ ‘*’;
add_header ‘Access-Control-Allow-Methods’ ‘GET, POST, OPTIONS’;
#
# Custom headers and headers various browsers *should* be OK with but aren’t
#
add_header ‘Access-Control-Allow-Headers’ ‘DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type’;
#
# Tell client that this pre-flight info is valid for 20 days
#
add_header ‘Access-Control-Max-Age’ 1728000;
add_header ‘Content-Type’ ‘text/plain charset=UTF-8′;
add_header ‘Content-Length’ 0;
return 204;
}
if ($request_method = ‘POST’) {
add_header ‘Access-Control-Allow-Origin’ ‘*’;
add_header ‘Access-Control-Allow-Methods’ ‘GET, POST, OPTIONS’;
add_header ‘Access-Control-Allow-Headers’ ‘DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type’;
}
if ($request_method = ‘GET’) {
add_header ‘Access-Control-Allow-Origin’ ‘*’;
add_header ‘Access-Control-Allow-Methods’ ‘GET, POST, OPTIONS’;
add_header ‘Access-Control-Allow-Headers’ ‘DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type’;
}
}
示例二

if ($request_method = ‘OPTIONS’) {
add_header ‘Access-Control-Allow-Origin’ ‘https://docs.domain.com’;
add_header ‘Access-Control-Allow-Credentials’ ‘true’;
add_header ‘Access-Control-Allow-Methods’ ‘GET, POST, PUT, DELETE, PATCH, OPTIONS’;
add_header ‘Access-Control-Allow-Headers’ ‘DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization,token’;
return 204;
}
if ($request_method = ‘POST’) {
add_header ‘Access-Control-Allow-Origin’ ‘https://docs.domain.com’;
add_header ‘Access-Control-Allow-Credentials’ ‘true’;
add_header ‘Access-Control-Allow-Methods’ ‘GET, POST, PUT, DELETE, PATCH, OPTIONS’;
add_header ‘Access-Control-Allow-Headers’ ‘DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization,token’;
}
if ($request_method = ‘GET’) {
add_header ‘Access-Control-Allow-Origin’ ‘https://docs.domain.com’;
add_header ‘Access-Control-Allow-Credentials’ ‘true’;
add_header ‘Access-Control-Allow-Methods’ ‘GET, POST, PUT, DELETE, PATCH, OPTIONS’;
add_header ‘Access-Control-Allow-Headers’ ‘DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization,token’;
}
其它技巧
Apache中启用CORS

在httpd配置或.htaccess文件中添加如下语句

SetEnvIf Origin “^(.*\.example\.com)$” ORIGIN_SUB_DOMAIN=$1
Header set Access-Control-Allow-Origin “%{ORIGIN_SUB_DOMAIN}e” env=ORIGIN_SUB_DOMAIN
PHP中启用CORS

通过在服务端设置Access-Control-Allow-Origin响应头

允许所有来源访问

header("Access-Control-Allow-Origin: *");
?>
允许来自特定源的访问

header('Access-Control-Allow-Origin: '.$_SERVER['HTTP_ORIGIN']);
?>
配置多个访问源
由于浏览器实现只支持了单个origin、*、null,如果要配置多个访问源,可以在代码中处理如下

$allowed_origins = array(
"http://www.example.com" ,
"http://app.example.com" ,
"http://cms.example.com" ,
);
if (in_array($_SERVER['HTTP_ORIGIN'], $allowed_origins)){
@header("Access-Control-Allow-Origin: " . $_SERVER['HTTP_ORIGIN']);
}
?>
HTML中启用CORS

CentOS6.x升级到7

2020年3月13日 没有评论

1、查看当前CentOS版本
cat /etc/redhat-release

2、更新源
vim /etc/yum.repos.d/upgrade.repo 并输入以下内容:
[upgrade]
name=upgrade
baseurl=https://buildlogs.centos.org/centos/6/upg/x86_64/
enable=1
gpgcheck=0

3、卸载6.x自带的较新的助手,并安装老版[否则会报错]
yum erase openscap -y
yum install http://dev.centos.org/centos/6/upg/x86_64/Packages/openscap-1.0.8-1.0.1.el6.centos.x86_64.rpm -y

4、安装助手
yum install redhat-upgrade-tool preupgrade-assistant-contents -y

5、检测版本升级的风险,如果控制台输出了错误信息,则需要查询下解决方案并解决
preupg -s CentOS6_7

6、导入CentOS7的key
rpm –import http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-7

7、开始升级
centos-upgrade-tool-cli –network 7 –instrepo=http://vault.centos.org/centos/7.2.1511/os/x86_64/

8、国内服务器需经过漫长的等待

8、更新完后,重启服务器
reboot

升级完成后遇到的问题:

1、ssh、yum不可用问题:
vi /root/start.sh #输入以下内容:
#!/bin/bash
ln -s /usr/lib64/libsasl2.so.3.0.0 /usr/lib64/libsasl2.so.2
ln -s /usr/lib64/libpcre.so.1.2.0 /usr/lib64/libpcre.so.0
service sshd restart
rm -rf /etc/rc.d/rc.local?
mv /etc/rc.d/rc.local.bak /etc/rc.d/rc.local #恢复原始文件
rm -rf /root/start.sh #删除自身

#执行以下命令
chmod +x start.sh
chmod +x /etc/rc.d/rc.local
cp /etc/rc.d/rc.local /etc/rc.d/rc.local.bak #创建备份
echo ‘bash /root/start.sh’ >>/etc/rc.d/rc.local #添加脚本为开机自启动

#重启,后看下ssh是否可以正常连接
reboot

2、 ps工具不可用问题:
yum upgrade -y
yum downgrade grep
yum upgrade python
yum update

分类: Linux, 解决方案 标签: ,

CentOS 7 下搭建高可用集群(转)

2020年2月27日 没有评论

一、安装集群软件
必须软件pcs,pacemaker,corosync,fence-agents-all,如果需要配置相关服务,也要安装对应的软件。

二、配置防火墙
1、禁止防火墙和selinux
# systemctl disable firewalld
# systemctl stop firewalld
2、设置防火墙规则
# firewall-cmd –permanent –add-service=high-availability
# firewall-cmd –add-service=high-availability
三、各节点之间主机名互相解析
分别修改2台主机名分别为node1和node2,在CentOS 7中直接修改/etc/hostname加入本机主机名和主机表,然后重启网络服务即可。

#vi /etc/hostname
node1
#systemctl restart network.service
#hostname
node1
配置2台主机的主机表,在/etc/hosts中加入

192.168.122.168 node1
192.168.122.169 node2
四、各节点之间时间同步
在node1和node2分别进行时间同步,可以使用ntp实现。

[root@node1 ~]# ntpdate 172.16.0.1 //172.16.0.1 为时间服务器
五、各节点之间配置ssh的无密码密钥访问
下面的操作需要在各个节点上操作。

# ssh-keygen -t rsa -P ‘’ #这个生成一个密码为空的公钥和一个密钥,把公钥复制到对方节点上即可
# ssh-copy-id -i /root/.ssh/id_rsa.pub root@node2 #对方主机名用登录用户名
两台主机都要互相可以通信,所以两台主机都得互相生成密钥和复制公钥,相互的节点上的hosts文件是都要解析对方的主机名, 192.168.122.168 node1 192.168.122.169 node2

# ssh node2 ‘date’;date #测试一下是否已经互信
六、通过pacemaker来管理高可用集群
1、创建集群用户
为了有利于各节点之间通信和配置集群,在每个节点上创建一个hacluster的用户,各个节点上的密码必须是同一个。

# passwd hacluster

Changing password for user hacluster.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
2、设置pcsd开机自启动
# systemctl start pcsd.service
# systemctl enable pcsd.service
3、集群各节点之间进行认证
# pcs cluster auth node1 node2Username: hacluster Password: node1: Authorized node2: Authorized
4、创建并启动集群
[root@z1 ~]# pcs cluster setup –start –name my_cluster node1 node2

node1: Succeeded
node1: Starting Cluster…
node2: Succeeded
node2: Starting Cluster…
5、设置集群自启动
# pcs cluster enable –all
6、查看集群状态信息
[root@z1 ~]# pcs cluster status
7、设置fence设备
这个可以参考
corosync默认启用了stonith,而当前集群并没有相应的stonith设备,因此此默 认配置目前尚不可用,这可以通过如下命令验证:

#crm_verify -L -V
可以通过如下面命令禁用stonith:

#pcs property set stonith-enabled=false(默认是true)
8、配置存储
高可用集群既可以使用本地磁盘来构建纯软件的镜像型集群系统,也可以使用专门的共享磁盘装置来构建大规模的共享磁盘型集群系统,充分满足客户的不同需求。
共享磁盘主要有iscsi或DBRD。本文并没有使用共享磁盘

9、配置浮点ip
不管集群服务在哪运行,我们要一个固定的地址来提供服务。在这里我选择192.168.122.101作为浮动IP,给它取一个好记的名字 ClusterIP 并且告诉集群 每30秒检查它一次。

# pcs resource create VIP ocf:heartbeat:IPaddr2 ip=192.168.122.170 cidr_netmask=24 op monitor interval=30s
# pcs update VIP op monitor interval=15s
10、配置apache服务
在node1和node2上安装httpd ,确认httpd开机被禁用。

# systemctl status httpd.service;
配置httpd监控页面(貌似不配置也可以通过systemd监控),分别在node1和node2上执行。

# cat > /etc/httpd/conf.d/status.conf << EOF
SetHandler server-status
Order deny,allow
Deny from all
Allow from localhost
EOF
首先我们为Apache创建一个主页。在centos上面默认的Apache docroot是/var/www/html,所以我们在这个目录下面建立一个主页。
node1节点修改如下:

[root@node1 ~]# cat

Hello node1

END
node2节点修改如下:

[root@node2 ~]# cat

Hello node2

END
下面语句是将httpd作为资源添加到集群中:

#pcs resource create WEB apache configfile=”/etc/httpd/conf/httpd.conf” statusurl=”http://127.0.0.1/server-status”
11、创建group
将VIP和WEB resource捆绑到这个group中,使之作为一个整体在集群中切换(此配置为可选)。

# pcs resource group add MyGroup VIP
# pcs resource group add MyGroup WEB
12、配置服务启动顺序
以避免出现资源冲突,语法:(pcs resource group add的时候也可以根据加的顺序依次启动,此配置为可选)。

# pcs constraint order [action] then [action]
# pcs constraint order start VIP then start WEB
13、指定优先的 Location (此配置为可选)
Pacemaker 并不要求你机器的硬件配置是相同的,可能某些机器比另外的机器配置要好。这种状况下我们会希望设置:当某个节点可用时,资源就要跑在上面之类的规则。为了达到这个效果我们创建location约束。同样的,我们给他取一个描述性的名字(prefer-node1),指明我们想在上面跑WEB 这个服务,多想在上面跑(我们现在指定分值为50,但是在双节点的集群状态下,任何大于0的值都可以达到想要的效果),以及目标节点的名字:

# pcs constraint location WEB prefers node1=50
# pcs constraint location WEB prefers node2=45
这里指定分值越大,代表越想在对应的节点上运行。

14、资源粘性(此配置为可选)
一些环境中会要求尽量避免资源在节点之间迁移,迁移资源通常意味着一段时间内无法提供服务,某些复杂的服务,比如Oracle数据库,这个时间可能会很长。为了达到这个效果,Pacemaker 有一个叫做“资源粘性值”的概念,它能够控制一个服务(资源)有多想呆在它正在运行的节点上。
Pacemaker为了达到最优分布各个资源的目的,默认设置这个值为0。我们可以为每个资源定义不同的粘性值,但一般来说,更改默认粘性值就够了。资源粘性表示资源是否倾向于留在当前节点,如果为正整数,表示倾向,负数则会离开,-inf表示负无穷,inf表示正无穷。

# pcs resource defaults resource-stickiness=100
常用命令汇总:
查看集群状态:#pcs status

查看集群当前配置:#pcs config

开机后集群自启动:#pcs cluster enable –all

启动集群:#pcs cluster start –all

查看集群资源状态:#pcs resource show

验证集群配置情况:#crm_verify -L -V

测试资源配置:#pcs resource debug-start resource

设置节点为备用状态:#pcs cluster standby node1

分类: Linux, 解决方案 标签: ,