自我整理

apache

安装

yum -y install gcc gcc-c++

tar -jxvf apr-1.5.1.tar.bz2

cd apr-1.5.1

./configure --prefix=/usr/local/apr && make && make install

tar -jxvf apr-util-1.5.2.tar.bz2

cd apr-util-1.5.2 ./configure --with-apr=/usr/local/apr/ --prefix=/usr/local/apr-util make && make install

tar -zxvf pcre-8.32.tar.gz cd pcre-8.32 ./configure --help ./configure --prefix=/usr/local/pcre make && make install

tar -zxvf httpd-2.4.41.tar.gz cd httpd-2.4.41 ./configure --with-apr=/usr/local/apr --with-apr-util=/usr/local/apr-util --with-pcre=/usr/local/pcre --prefix=/usr/local/apache2 --enable-so

make && make install

tomcat

安装

tar -zxvf apache-tomcat-8.5.40.tar.gz #解压 mv apache-tomcat-8.5.40 /opt/tomcat #移动 tar -zxvf jdk-8u201-linux-x64.tar.gz -C /usr/local/

vim /etc/profile export JAVA_HOME=/data/server/jdk1.8 #修改环境变量 export CLASSPATH=.:JAVA_HOME/lib/dt.jar:$JAVA_HOME/jib/tools.jar export PATH=$PATH:$JAVA_HOME/bin

source /etc/profile #使配置文件生效

/data/server/tomcat8/bin/startup.sh #开启服务

单机多实例 1.安装tomcat

再复制一份tomcat即可，修改端口别冲突就可以 vim /opt/tomcat/conf/server.xml 8005/8080/8009

将tomcat托管给superviosr管理 yum -y install epel-release yum -y install supervisor

vim /etc/supervisord.conf

[program:tomcat1] command=/opt/tomcat1/bin/catalina.sh run

[program:tomcat2] command=/opt/tomcat2/bin/catalina.sh run

启动supervisord service supervisord start

查看tomcat1和tomcat2的监听端口，可以看到一整正在监听 ss -ntl | grep 8080 ss -ntl | grep 8081

Apache和Tomcat动静分离

 

LVS内容来自51CTO博客作者flfteym34431整理

如有需要请自行查看   https://blog.51cto.com/13501622/2147291

LVS

集群采用三层结构

1：负载调度层：他是整个集群对外面的前端机。负责将客户的请求发送到一组服务器上执行。

2：服务器池：是一组真正执行客户请求的服务器

3：共享存储：他为服务器池提供一个共享的存储区，这样使服务器吃拥有相同的内容

组成

IPVS和ipvsadm

IPVS工作在内核空间，真正的调度由它完成。

我们借助工作在用户空间管理工具ipvsadm来管理IPVS。负责为ipvs内核框架编写规则，定义虚拟服务器，定义后端真实服务器。定义工作模式和调度算法。

ipvsadm

-C 清除表中所有的记录 -A --add-service在服务器列表中新添加一条新的虚拟服务器记录

-t 表示为tcp服务 -u 表示为udp服务ipvsadm基本命令参数如下：

-t 指定虚拟服务器的IP地址和端口

-s 指定调度算法，ss为轮询，wrr为加权轮询，dh为目标地址散列，sh为源地址散列，lc为最少链接等

-a 在对应的VIP下添加RS节点

-g 指定LVS的工作模式为DR模式

-l 指定LVS的工作模式为tunnel模式

-m 指定LVS的工作模式为NAT模式

术语

DS：Director Server。前端负载均衡器节点

RS：Real Server。 后端真实工作服务器

LB：Load Balancer 前端的负载均衡器

DIP: Director IP

VIP: Director Virtual IP

CIP: Client IP

RIP: Realserver IP

工作模式：

NAT 网络地址转换

通过修改请求报文的目标IP地址（同时可能修改目标端口）至挑选出某RS的RIP实现地址转发。

原理：

请求报文：

• 用户对director发起请求, 这时在三层的首部中, 源地址是CIP, 目标地址是VIP;

• 报文从director的配置了VIP这种网卡进入被PREROUTING链捕获, 本应该交由FORWARD链, 但此时IPVS强行修改路径将数据包从PREROUTING链转发至INPUT链上; 并且将目标地址改为RIP, 将报文交由POSTROUTING链;

• 然后从配置了DIP这张网卡出去, 交给后端的RealServer(通过挑选算法.)

• RealServer收到请求后, 将响应报文封装, 此时数据包的目标地址是CIP, 源地址是RIP;

• 数据包被发送至Director, 从配置了DIP的网卡进入, 交由PREROUTING链, 然后转发至INPUT链, 这时数据包的目标地址不变, 仍然是CIP, 而源地址被修改为VIP;

• 然后交由POSTROUTING链, 从配置了VIP的网卡出去, 通过路由器发送给互联网的Client.

配置lvs-nat的注意事项:

• RS和DIP应该使用私网地址, 且RS的网关要指向DIP.

• 请求和响应报文都要经由director转发; 极高负载的场景中, director可能会成为系统瓶颈.

• 支持端口映射.

• RS可以使用任意OS.

• RS的RIP和director的DIP必须在同一IP的网络.

DR 直接路由

它通过修改报文的目标MAC地址进行转发.

原理：

请求报文流程图:

• Clint对director发起请求, 这时在三层的首部中, 源地址是CIP, 目标地址是VIP; 在二层的首部中源mac是CIP-MAC, 目标mac是VIP-MAC;

• VIP配置在网卡ens33的别名上(ens33:0); 数据包从ens33:0进入, 在到达INPUT链后;

• 此时源IP和目标IP均未修改, IPVS只是修改了源MAC为DIP-MAC, 目标MAC为RIP-MAC;

• 由于DIP和RIP处于同一个网络中, 所以是通过二层传输; POSTROUTING链检查目标MAC为RIP-MAC, 便将数据包交由配置了DIP的网卡ens33发送至后端的RealServer上(通过挑选算法).

• 数据包从RIP进入RealServer, 然后被交给绑定了VIP的lo:0(lo的别名), lo:0将数据包解包后将请求报文交给用户空间的应用获取Client请求的资源.

响应报文流程图:

• lo:0获取请求报文后, 此时目标地址为CIP, 源地址为VIP; 目标MAC被修改CIP-MAC, 源MAC被修改为VIP-MAC;

• lo:0将数据包发送给配置了RIP的网卡(ens33), 此时数据包将被通过互联网路由发回给Client.

配置lvs-dr的注意事项:

• 保证前端路由器将目标IP为VIP的请求报文发送给director:

  • 静态绑定

  • arptables

  • 修改RS主机内核参数

• RS的RIP可以使用私有地址, 也可以使用公网地址;

• RS跟Director必须在同一物理网络中;

• 请求报文经由Director调度, 但响应报文一定不能经由Director;

• 不支持端口映射;

• RS可以是大多数OS;

• RS的网关不能指向DIP.

TUN 隧道模式

不修改请求报文的IP首部, 而是通过在原有IP首部(cip <--> vip)之外, 在封装一个首部(dip <--> rip).

请求报文流程图:

• 当用户请求到达Director时, 请求的数据报文会被绑定了vip的网卡交由PREROUTING链后转交给INPUT链, 此时源IP为CIP, 目标IP为VIP;

• 此时IPVS会在原来的数据报文的首部在封装一层IP报文, 封装源IP为DIP, 目标IP为RIP, 并且将重新封装后的数据包交由POSTROUTING链, 然后在从绑定了DIP的网卡发送给后端的RS.

• RS接受到数据包, 解包后发现里面还有一层IP首部, 而且目标IP是回环接口的VIP(lo:0), 就将数据包转发给回环接口, 回环接口接到数据包并解包, 将请求报文发给用户空间的APP获取相应的资源.

响应报文流程图:

• 回环接口获取响应报文后, 将报文封装通过本机的物理网卡发送出去, 此时数据包首部的源IP为VIP, 目标IP为CIP;

• 数据包经过重重路由后发送至Client.

lvs-tun模型的注意事项:

• RIP, DIP, VIP全得是公网地址;

• RS的网关不能指向DIP

• 请求报文必须经由director调度, 但响应报文必须不能经由director;

• 不支持端口映射;

• RS的OS必须支持隧道功能.

转载https://blog.51cto.com/13501622/2147289

Memcache

Memcache用到了libevent这个库用于Socket的处理，所以需要安装libevent

wget http://www.monkey.org/~provos/libevent-1.4.14b-stable.tar.gz

1）、安装libevent

# tar xzvf libevent-1.4.14b-stable.tar.gz

# cd libevent-1.4.14b-stable

# ./configure --prefix=/usr

# make && make install

# cd ..

# ls -al /usr/lib | grep libevent （查看是否安装成功）

wget http://memcached.googlecode.com/files/memcached-1.4.5.tar.gz

2）、安装memcache

yum -y install libevent-devel

# tar xzvf memcached-1.4.5.tar.gz

# cd memcached-1.4.5

# ./configure --prefix=/usr/local/memcache

# make && make test

make install

Memcached命令的运行：

$ /usr/local/memcached/bin/memcached -h                           命令帮助

注意：如果使用自动安装 memcached 命令位于 /usr/local/bin/memcached。

启动选项：

• -d是启动一个守护进程；

• -m是分配给Memcache使用的内存数量，单位是MB；

• -u是运行Memcache的用户；

• -l是监听的服务器IP地址，可以有多个地址；

• -p是设置Memcache监听的端口，，最好是1024以上的端口；

• -c是最大运行的并发连接数，默认是1024；

• -P是设置保存Memcache的pid文件。

（1）作为前台程序运行：

从终端输入以下命令，启动memcached:

/usr/local/memcached/bin/memcached -p 11211 -m 64m -vv
​
slab class   1: chunk size     88 perslab 11915
​
slab class   2: chunk size    112 perslab  9362
​
slab class   3: chunk size    144 perslab  7281
​
中间省略
​
slab class  38: chunk size 391224 perslab     2
​
slab class  39: chunk size 489032 perslab     2
​
<23 server listening
​
<24 send buffer was 110592, now 268435456
​
<24 server listening (udp)
​
<24 server listening (udp)
​
<24 server listening (udp)
​
<24 server listening (udp)

这里显示了调试信息。这样就在前台启动了memcached，监听TCP端口11211，最大内存使用量为64M。调试信息的内容大部分是关于存储的信息。

（2）作为后台服务程序运行：

# /usr/local/memcached/bin/memcached -p 11211 -m 64m -d

或者

/usr/local/memcached/bin/memcached -d -m 64M -u root -l 192.168.0.200 -p 11211 -c 256 -P /tmp/memcached.pid

redis

Redis（全称：Remote Dictionary Server 远程字典服务）是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）

当第一次读取数据的时候，读取 Redis 的数据就会失败，此时就会触发程序读取数据库，把数据读取出来，并且写入 Redis 中；

当第二次以及以后需要读取数据时，就会直接读取 Redis，读到数据后就结束了流程，这样速度就大大提高了。

安装 Redis

tar -zxvf redis-5.0.6.tar.gz cd redis-5.0.6 make && make install

配置redis文件

cp redis.conf /etc/ vim /etc/redis.conf

修改内容 bind : 监控IP #0.0.0.0监控所有端口

daemonize yes #开启守护进程

replicaof <masterip> <masterport> #配置主从架构

requirepass “foobared” #配置密码 默认无

Redis 客户端的基本语法为：

$ redis-cli

实例

以下实例讲解了如何启动 redis 客户端：

启动 redis 客户端，打开终端并输入命令 redis-cli。该命令会连接本地的 redis 服务。

$redis-cli
redis 127.0.0.1:6379>
redis 127.0.0.1:6379> PING
​
PONG

在远程服务上执行命令

如果需要在远程 redis 服务上执行命令，同样我们使用的也是 redis-cli 命令。

语法

$ redis-cli -h host -p port -a password

实例

以下实例演示了如何连接到主机为 127.0.0.1，端口为 6379 ，密码为 mypass 的 redis 服务上。

$redis-cli -h 127.0.0.1 -p 6379 -a "mypass"
redis 127.0.0.1:6379>
redis 127.0.0.1:6379> PING
​
PONG

redis的哨兵模式

配置1主2从集群 只需在从上添加： replicaof IP PORT

配置哨兵 1.为哨兵添加配置文件 cp sentinel.conf /etc/ vim /etc/sentinel.conf

修改如下配置 ​ protected-mode no 关闭保护模式 ​ sentinel monitor mymaster 192.168.189.162 6379 2 哨兵监控的master的ip和端口 2是接受到多少票后为客观下线，然后开始执行主的切换 验证看自动切换效果

haproxy

HAProxy实现了一种事件驱动, 单一进程模型，此模型支持非常大的并发连接数。多进程或多线程模型受内存限制 、系统调度器限制以及无处不在的锁限制，很少能处理数千并发连接。事件驱动模型因为在有更好的资源和时间管理的用户空间(User-Space) 实现所有这些任务，所以没有这些问题。此模型的弊端是，在多核系统上，这些程序通常扩展性较差。这就是为什么他们必须进行优化以 使每个CPU时间片(Cycle)做更多的工作。

安装

tar zxvf haproxy-1.4.8.tar.gz

cd haproxy-1.4.8

uname -a //查看linux内核版本

make target=linux26 prefix=/usr/local/haproxy

make install prefix=/usr/local/haproxy

启动

#启动haproxy

/usr/local/haproxy/haproxy -f

配置

haproxy 的配置文件由两部分组成：全局设定和对代理的设定，共分为五段：global，defaults，frontend，backend，listen。

配置HAProxy Session亲缘性的三种方式

haproxy负载均衡保持客户端和服务器Session亲缘性的三种方式:

1 用户IP 识别

haproxy 将用户IP经过hash计算后 指定到固定的真实服务器上（类似于nginx 的IP hash 指令）

配置指令 balance source

2 cookie 识别

haproxy 将WEB服务端发送给客户端的cookie中插入(或添加前缀)haproxy定义的后端的服务器COOKIE ID。

配置指令例举 cookie SESSION_COOKIE insert indirect nocache

用firebug可以观察到用户的请求头的cookie里 有类似" Cookie jsessionid=0bc588656ca05ecf7588c65f9be214f5; SESSION_COOKIE=app1" SESSION_COOKIE=app1就是haproxy添加的内容

3 session 识别

haproxy 将后端服务器产生的session和后端服务器标识存在haproxy中的一张表里。客户端请求时先查询这张表。

配置指令例举 appsession JSESSIONID len 64 timeout 5h request-learn

配置举例：

#vi /usr/local/haproxy/haproxy.cfg

backend COOKIE_srv

用户IP
mode http
​
cookie SESSION_COOKIE insert indirect nocache
​
server REALsrv_70 184.82.239.70:80 cookie 11 check inter 1500 rise 3 fall 3 weight 1
​
server REALsrv_120 220.162.237.120:80 cookie 12 check inter 1500 rise 3 fall 3 weight 1
​
backend SOURCE_srv

cookie
mode http
​
balance source
​
server REALsrv_70 184.82.239.70:80 cookie 11 check inter 1500 rise 3 fall 3 weight 1
​
server REALsrv_120 220.162.237.120:80 cookie 12 check inter 1500 rise 3 fall 3 weight 1
​
backend APPSESSION_srv

session
mode http
​
appsession JSESSIONID len 64 timeout 5h request-learn
​
server REALsrv_70 184.82.239.70:80 cookie 11 check inter 1500 rise 3 fall 3 weight 1
​
server REALsrv_120 220.162.237.120:80 cookie 12 check inter 1500 rise 3 fall 3 weight 1 [2]