1、系统无法执行su操作问题现象:

su: warning: cannot change directory to / home/user: Permission denied
su: /bin/bash: Permission denied
解决思路:
从上面错误提示可知是权限出现了问题，那么可以从权限入手进行排查，基本思路如下:

ll /home/user
ls -al /home/user

su程序执行权限问题程序依赖的共享库权限问题

ll /bin/su
ldd /bin/su 查看库依赖

selinux问题导致

more /etc/selinux/config or get enforce
setenforce 0

系统根空间问题

df -h 空间有没有满

查看完都没有问题，根据报错就是权限的问题，仔细分析发现时根目录权限的问题

stat / 查看根目录的详细状态结果为666
chmod 755 / 修改后正常

2、”Read-only file system”

问题分析与解决问题现象:客户说网站无法添加内容了。
df -h 发现磁盘未满
解决思路:
网站程序可能出现问题了
服务器磁盘故障
mkdir 尝试发现创建不了文件
图片.png
umount /boot
卸载分区，发现分区繁忙，说明在使用中

fuserr /boot
查看占用该分区的进程其中41712是PID

查看这个pid是哪个进程
ps -ef | grep 41712

原来是当前bash在root目录下执行命令造成占用切换目录 cd / 再fuser /boot 发现不再占用
umount /boot
fsck 进行磁盘修复因为之前是dev/sda1 挂载到/boot 的所以
fsck -y /dev/sda1 # -y 参数表示发现磁盘有损坏就自动修复不再询问
图片.png
修复完成，重新挂载磁盘
mount /dev/sda1 /boot
问题解决

3、基于动态、静态内容结合的网站优化案例

硬件环境:DELLR7103台、32GB内存、CPU2颗8核、磁盘SATA 600GB+2TB
软件环境:nginx+tomcat架构，通过nginx做负载均衡。
现象描述:平时访问量小时,网站正常,当访问量稍大时，网站访问很慢，网站搞活动
时，基本处于无法打开状态,而nginx服务器带宽占最高在30M左右，后端2个tomcat
服务器占用带宽占用也在30M左右。

分析问题:
(1)硬件、系统方面
(2)网络方面
nginx占用带宽和tomcat一样，说明静态请其也被ngix转个了 tomcat处理。
(3)软件架构方面
(4)程序配置方面

解决问题:
(1)架构方面调整
upstream myserver {
ip_hash;
server 172.16.100.11:8080 weight=1 max_fails=2 fail_timeout=10s;
server 172.16.100.12:8080 weight=3 max_fails=2 fail_timeout=10s;
server 172.16.100.13:8080 weight=2 max_fails=2 fail_timeout=10s;
server 172.16.100.14:8080 weight=2 max_fails=2 fail_timeout=10s;
}
(2)网站动、静分离
~不区分大小写
location~.(gif|jpg|pngljs|css)${
root /data/static/images/ROOT;
}
Nginx中location匹配规则:
首先匹配=，其次匹配^~,然后是按文件中顺序的正则匹配，
最后是交给/通用匹配。当有匹配成功时候，停止匹配，按当前匹配规则处理请求。
(3)Tomcat JVM参数优化
优化参数:
32G内存
-server-Xms3550m
-Xmx3550m-Xmn1g
-XX:PermSize=256M
-XX:MaxPermSize=512m
整个堆内存大小=年轻代大小+年老代大小+持久代大小
-Xmx3550m:设置JVM最大堆内存为3550M
-Xms3550m:设置JVM初始堆内存为3550M
-Xmn2g:设置堆内存年轻代大小为2G。整个堆内存大小=年轻代大小+年老代大小+持久代大小
持久代一般固定大小为64m,所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大
-XX:PermSize= 256M:设置堆内存持久代初始值为256M
-XX:MaxPermSize=512M:设置持久代最大值为512M。

4、企业集群平台架构设计与实现

通过piranha搭建LVS高可用性集群

piranha是REDHAT提供的一个基于Web的LVS配置软件,通过piranha可以省去手工配置LVS的繁琐工作;同时，piranha也可以单独提供集群功能,例如，可以通过piranha激活DirectorServer的备用主机。这里利用piranha来配置Director Server的双机热备功能。

1.安装与配置piranha

通过yum命令直接在线安装，过程如下:

[root@host236~]# yum install ipvsadm modduster piranha system-config-cluster php php-cli php-common

通过WEB界面配置Piranha服务需要设置下面步骤。
#/usr/sbin/piranha-passwd //设置密码,请设置你的piranha服务WEB配置登陆密码.
http://192.168.12.130:3636/ 输入用户名:piranha及刚才设置的密码登陆.
/etc/sysconfig/ha/lvs.cf //由http://ip:3636 web界面配置的配置文件写入此文件.
/etc/init.d/piranha-gui start //启动piranha服务的-WEB配置界面
/etc/init.d/pulse //启动piranha服务读取的就是/etc/sysconfig/ha/lvs.cf.
piranha安装完毕后,会产生/etc/sysconfig/ha/lvs.cf配置文件。可以通过piranha提供的Web界面配置此文件,也可以直接手动编辑此文件。编辑好的lvs.cf文件内容类似如下所示

[root@host236 ~]# more /etc/sysconfig/ha/lvs.cf
serial_no = 18    #序号I
primary = 192.168.60.130    #指定主用Director Server的真实IP地址
service = lvs    #指定双机的服务名
backup_active = 1    #是否激活备用Director Server。“O”表示不激活,“1”表示激活。
                                    #这里选择激活方式
backup = 192.168.12.131 #这里指定备用Director Server的真实IP地址，如果没有备用    Director Server,可以用“0.0.0.0”代替
heartbeat = 1        #是否开启心跳,1表示开启，0表示不开启
heartbeat_port = 539     #指定心跳的UDP通信端口
keepalive = 6            #心跳间隔时间，单位是秒
deadtime = 18        #如果主Director Server在deadtime(秒)后没有响应，那么备份
                                #Director Server就会接管主Director Server的服务
network = direct            #指定LVS的工作模式,direct表示DR模式,nat表示NAT模式,tunnel表示TUN模式
debug_level = NONE                #定义debug调试信息级别
virtual [server_name] {        #server_name 指定虚拟服务的名称
  active =0            #是否激活此服务
  address £0.0.0.0 etho:1  #虚拟服务绑定的虚拟IP及网络设备名
  port=80  #虚拟服务的端口
  send = "GET / HTTP/1.O\r\n\r\n" ”#向real server发送的验证字符串
  expect="HTTP"#服务器正常运行时应该返回的文本应答信息，用来判断Real Server是否工作正常
  use_regex =0 #expect选项中是否使用正则表达式, 0表示不使用,1表示使用。
  load_monitor = none #LVS中的Director Server能够使用rup或ruptime来监视各个Real Server的负载状态。该选项有3个可选值,rup、ruptime和none,如果选择rup,每个Real Server就必须运行rstatd服务。如果选择了
  scheduler = wlc
  protocol = tcp
  timeout = 6
  reentry = 15
  quiesce_server = 0
}

2.启动通过piranha配置的LVS集群系统

将编辑好的Ivs.cf从Director Server的主节点复制到备用节点，然后在主、备节点分别
启动pulse服务，即启动LVS服务，过程如下:
[root@DR1~]#service pulse start
接下来,还要在主、备节点启用系统的包转发功能(其实只有在NAT模式下需要)，命令如下:
[root@DRI ~]#echo”1” >/proc/sys/net/ipv4/ip_forward
最后，在两个Real server节点上执行Ivsrs脚本，命令如下:
[root@rs1~]#/etc/init.d/lvsrs start
到此为止，利用piranha工具搭建的高可用LVS集群系统已经运行起来了。

通过Keepalived搭建LVS高可用性集群系统

LVS 支持 400万并发 > HAproxy > Nginx支持 3万并发

1、安装keepalived+ipvsadm环境

[root@host236~]#yum install ipvsadm keepalived

2、配置Keepalived

Keepalived的配置非常简单，仅需要一个配置文件即可完成对HA cluster和LVS服务节点监控。Keepalived的安装已经在前面介绍过,在通过Keepalived搭建高可用的LVS集群实例中，主、备Director Server都需要安装Keepalived软件，安装成功后，默认的配置文件路径为/etc/Keepalived/Keepalived.conf。一个完整的keepalived配置文件由三个部分组成，分别是全局定义部分、vrrp实例定义部分以及虚拟服务器定义部分，下面详细介绍这个配置文件中每个选项的详细含义和用法。
如果配置文件有问题，不会报错..

!Configuration File for keepalived
#全局定义部分============================================
global_defs{
notification_email{
  dba.gao@gmail.com #设置报警邮件地址，可以设置多个,每行一个。注意,如果要开启邮件报警,需要开启本机的Sendmail服务
  ixdba@163.com
}
notification_email_from Keepalived@localhost  #设置邮件的发送地址
smtp_server 192.168.200.1  #设置smtpserver地址
smtp_connect_timeout 30  #设置连接smtpserver的超时时间
router_idLVS_DEVEL  #表示运行Keepalived服务器的一个标识。发邮件时显示在邮件主题中的信息
#vrrp实例定义部分========================================
vrrp_instance VI_1{
  state MASTER  #指定Keepalived的角色，MASTER表示此主机是主服务器，BACKUP表示此主机是备用服务器
  interface etho  #指定HA监测网络的接口
  virtual_router_id 51  #虚拟路由标识，这个标识是一个数字,同一个vmp实例使用唯一的标识,即同一个vrrp_instance下,MASTER和BACKUP必须是一致的
  priority 100定义优先级,数字越大,优先级越高,在一个vrrp_instance下，MASTER的优先级必须大于BACKUP的优先级
  advert_int 1  #设定MASTER与BACKUP负载均衡器之间同步检查的时间间隔，单位是秒
  authentication{        #设定验证类型和密码
  auth_type PASS    #设置验证类型，主要有PASS和AH两种
  auth_pass 1111    #设置验证密码，在一个vrrp_instance下,MASTER与BACKUP必须使用相同的密码才能正常通信
    }
virtual_ipaddress#设置虚拟IP地址,可以设置多个虚拟IP地址,每行一个。
192.168.12.200
}
#虚拟服务器定义部分==========================================
virtual_server 192.168.12.200 80{  #设置虚拟服务器，需要指定虚拟IP地址和服务端口，IP与端口之间用空格隔开
  delay_loop 6    #设置健康检查的时间间隔,单位是秒
  Ib_algorr    #设置负载调度算法,这里设置为rr,即轮询算法
  Ib_kind DR    #设置LVS实现负载均衡的机制，有NAT、TUN和DR三个模式可选
  persistence_timeout 50    #会话保持时间，单位是秒。这个选项对动态网页是非常有用的,为集群系统中的session共享,提供了一个很好的解决方案，有了这个绘画保持功能,用户的请求会被一直分发到某个服务节点,直到超过这个会话的保持时间。需要注意的是,这个会话保持时间是最大无响应超时时间,也就是说,用户在操作动态页面时，如果在50秒内没有执行任何操作，那么接下来的操作会被分发到另外节点,但是如果用户一直在操作动态页面，则不受50秒的时间限制
  protocol TCP    #指定转发协议类型，有TCP和UDP两种
  real_server 192.168.12.132 80{    #配置服务节点1，需要指定real server的真实IP地址和端口，IP与端口之间用空格隔开
    weight 3    #配置服务节点的权值，权值大小用数字表示,数字越大，权值越高,设置权值的大小可以为不同性能的服务器分配不同的负载，可以为性能高的服务器设置较高的权值,而为性能较低的服务器设置相对较低的权值，这样才能合理地利用和分配了系统资源
    TCP_CHECK{    #realserve的状态检测设置部分,单位是秒
      connect_timeout 3    #表示3秒无响应超时
      nb_get_retry 3    #表示重试次数
      delay_before_retry 3    #表示重试间隔
    }
  }
  real_server 192.168.12.133 80{    #配置服务节点2
    weight 1
    TCP_CHECK{
      connect_timeout3
      nb_get_retry 3
      delay_before_retry 3
    }
  }
}

在配置Keepalived.conf时，需要特别注意配置文件的语法格式，因为Keepalived在启动时并不检测配置文件的正确性，即使没有配置文件,Keepalived也照样能够启动，所以一定要保证配置文件正确。    在默认情况下，Keepalived在启动时会查找/etc/Keepalived/Keepalived.conf 配置文件，如果配置文件放在了其他路径下，可以通过“Keepalived -f”参数指定配置文件的路径即可。<br />    Keepalived.conf配置完毕后，将此文件复制到备用Director Server对应的路径下，然后进行两个简单的修改即可。

将“state MASTER”更改为“state BACKUP”
将priority100更改为一个较小的值，这里改为“priority 80”
3、配置Realserver节点
与heartbeat+LVS类似,Keepalived+LVS也需要为Real server节点配置相关的脚本,
以达到与Director Server相互通信的目的，脚本的内容已经在前面介绍过，这里不在讲述。
4、启动Keepalived+LVS集群系统
在主、备Director Server上分别启动Keepalived服务，可以执行如下操作:
[root@DR1 ~]#/etc/init.d/Keepalived start
接着在两个Realserver上执行如下脚本:
[root@rs1~]#/etc/init.d/Ivsrs start
至此,Keepalived+LVS高可用的LVS集群系统已经运行起来了。
5、知识扩展
Master和Backup角色选举策略
在Keepalived集群中，其实并没有严格意义上的主、备节点，虽然可以在Keepalived配置文件中设置“state”选项为“MASTER”状态，但是这并不意味着此节点一直就是Master角色。控制节点角色的是Keepalived配置文件中的“priority”值，但并它并不控制所有节点的角色，另一个能改变节点角色的是在vrrp_script模块中设置的“weight”值，这两个选项对应的都是一个整数值，其中“weight”值可以是个负整数，一个节点在集群中的角色就是通过这两个值的大小决定的。

在一个一主多备的Keepalived集群中，“priority”值最大的将成为集群中的Master节点，而其他都是Backup节点。在Master节点发生故障后，Backup节点之间将进行“民主选举”，通过对节点优先级值“priority”和““weight”的计算，选出新的Master节点接管集群服务。

在vrrp_script模块中，如果不设置“weight”选项值，那么集群优先级的选择将由Keepalived配置文件中的“priority”值决定，而在需要对集群中优先级进行灵活控制时，可以通过在vrrp_script模块中设置“weight”值来实现。下面列举一个实例来具体说明。

假定有A和B两节点组成的Keepalived集群，在A节点keepalived.conf文件中，设置“priority”值为100，而在B节点keepalived.conf文件中，设置“priority”值为80，并且A、B两个节点都使用了“vrrp_script”模块来监控mysql服务，同时都设置“weight”值为10，那么将会发生如下情况。

在两节点都启动Keepalived服务后，正常情况是A节点将成为集群中的Master节点，而B自动成为Backup节点，此时将A节点的mysql服务关闭，通过查看日志发现，并没有出现B节点接管A节点的日志，B节点仍然处于Backup状态，而A节点依旧是Master状态，在这种情况下整个HA集群将失去意义。

下面就分析一下产生这种情况的原因，这也就是Keepalived集群中主、备角色选举策略的问题。下面总结了在Keepalived中使用vrrp_script模块时整个集群角色的选举算法，由于“weight”值可以是正数也可以是负数，因此，要分两种情况进行说明。

“weight”值为正数时

在vrrp_script中指定的脚本如果检测成功，那么Master节点的权值将是“weight值与”priority“值之和，如果脚本检测失败，那么Master节点的权值保持为“priority”值，因此切换策略为：

Master节点“vrrp_script”脚本检测失败时，如果Master节点“priority”值小于Backup节点“weight值与”priority“值之和，将发生主、备切换。

Master节点“vrrp_script”脚本检测成功时，如果Master节点“weight”值与“priority”值之和大于Backup节点“weight”值与“priority”值之和，主节点依然为主节点，不发生切换。

“weight”值为负数时

在“vrrp_script”中指定的脚本如果检测成功，那么Master节点的权值仍为“priority”值，当脚本检测失败时，Master节点的权值将是“priority“值与“weight”值之差，因此切换策略为：

Master节点“vrrp_script”脚本检测失败时，如果Master节点“priority”值与“weight”值之差小于Backup节点“priority”值，将发生主、备切换。

Master节点“vrrp_script”脚本检测成功时，如果Master节点“priority”值大于Backup节点“priority”值时，主节点依然为主节点，不发生切换。

在熟悉了Keepalived主、备角色的选举策略后，再来分析一下刚才实例，由于A、B两个节点设置的“weight”值都为10，因此符合选举策略的第一种，在A节点停止Mysql服务后，A节点的脚本检测将失败，此时A节点的权值将保持为A节点上设置的“priority”值，即为100，而B节点的权值将变为“weight”值与“priority”值之和，也就是90（10+80），这样就出现了A节点权值仍然大于B节点权值的情况，因此不会发生主、备切换。

对于“weight”值的设置，有一个简单的标准，即“weight”值的绝对值要大于Master和Backup节点“priority”值之差。对于上面A、B两个节点的例子，只要设置“weight”值大于20即可保证集群正常运行和切换。由此可见，对于“weight值的设置，要非常谨慎，如果设置不好，将导致集群角色选举失败，使集群陷于瘫痪状态。