python 搭建web应用程序_基于python的web应用（五）

7.8  Mogodb sharding常见管理操作：

查看sharding状态：

>printShardingStatus()

>sh.status()

查看数据库状态：

>db.dbname.stats

>db.stats()，查看当前db的一些概况：数据集、大小、索引相关，ok=1表示状态OK了。

>db.serverStatus()，查看更加详细的信息：全局锁、容量、连接数、异常信息、索引信息等，这里可以看当前连接数和可用连接数

7.9  Mongodb运行监控：

说明：

inserts/s 每秒插入次数

query/s每秒查询次数

update/s每秒更新次数

delete/s每秒删除次数

getmore/s每秒执行getmore次数

command/s每秒的命令数，比以上插入、查找、更新、删除的综合还多，还统计了别的命令

vsize虚拟内存使用量，单位MB

res物理内存使用量，单位MB

faults/s每秒访问失败数(只有Linux有)，数据被交换出物理内存，放到swap。不要超过100，否则就是机器内存太小，造成频繁swap写入。此时要升级内存或者扩展

netin进流量

Netout 出流量

conn当前连接数

time时间戳

Mongodb自带了Web控制台，默认和数据服务一同开启。他的端口在Mongodb数据库服务器端口的基础上加1000，如果不需要开启可以在配置文件中加上参数nohttpinterface=true

查看本机监听端口也可以看到：

通过http访问：

查看replication set副本集：

可以看到健康检查

这里把10.15.62.203的shard1停掉再看：

在监控也能看到停掉了

8 Keepalive,lvs实现mongos路由冗余

8.1负载均衡的算法：

一、轮询(round robin, rr),加权轮询(Weighted round robin, wrr)新的连接请求被轮流分配至各RealServer；算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。轮叫调度算法假设所有 服务器处理性能均相同，不管服务器的当前连接数和响应速度。该算法相对简单，不适用于服务器组中处理性能不一的情况，而且当请求服务时间变化比较大时，轮 叫调度算法容易导致服务器间的负载不平衡。

二、目标地址散列调度(Destination Hashing，dh)

算法也是针对目标IP地址的负载均衡，但它是一种静态映射算法，通过一个散列(Hash)函数将一个目标IP地址映射到一台服务器。目标地址散列调度算法先 根据请求的目标IP地址，作为散列键(Hash Key)从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

三、源地址散列调度(Source Hashing，sh)

算法正好与目标地址散列调度算法相反，它根据请求的源IP地址，作为散列键(Hash Key)从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。它采用的散列函数与目标地址散列调度算法 的相同。除了将请求的目标IP地址换成请求的源IP地址外，它的算法流程与目标地址散列调度算法的基本相似。在实际应用中，源地址散列调度和目标地址散列 调度可以结合使用在防火墙集群中，它们可以保证整个系统的唯一出入口。

四、最少连接(least connected, lc)，加权最少连接(weighted least connection, wlc)

新的连接请求将被分配至当前连接数最少的RealServer；最小连接调度是一种动态调度算法，它通过服务器当前所活跃的连接数来估计服务器的负载情 况。调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1；当连接中止或超时，其连接数减一。

算法：lc：256*A+I=当前连接数  wlc：(256*A+I)/W=当前连接数   【A：活动连接数  I:非活动连接数 W：权重值】

五、基于局部性的最少链接调度(Locality-Based Least Connections Scheduling，lblc)

针对请求报文的目标IP地址的负载均衡调度，目前主要用于Cache集群系统，因为在Cache集群中客户请求报文的目标IP地址是变化的。这里假设任何 后端服务器都可以处理任一请求，算法的设计目标是在服务器的负载基本平衡情况下，将相同目标IP地址的请求调度到同一台服务器，来提高各台服务器的访问局 部性和主存Cache命中率，从而整个集群系统的处理能力。LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是 可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于其一半的工作负载，则用“最少链接”的原则选出一个可用的服务 器，将请求发送到该服务器。

六、带复制的基于局部性最少链接调度(Locality-Based Least Connections with Replication Scheduling，lblcr)

也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射，而 LBLC算法维护从一个目标IP地址到一台服务器的映射。对于一个“热门”站点的服务请求，一台Cache 服务器可能会忙不过来处理这些请求。这时，LBLC调度算法会从所有的Cache服务器中按“最小连接”原则选出一台Cache服务器，映射该“热门”站 点到这台Cache服务器，很快这台Cache服务器也会超载，就会重复上述过程选出新的Cache服务器。这样，可能会导致该“热门”站点的映像会出现 在所有的Cache服务器上，降低了Cache服务器的使用效率。LBLCR调度算法将“热门”站点映射到一组Cache服务器(服务器集合)，当该“热 门”站点的请求负载增加时，会增加集合里的Cache服务器，来处理不断增长的负载；当该“热门”站点的请求负载降低时，会减少集合里的Cache服务器 数目。这样，该“热门”站点的映像不太可能出现在所有的Cache服务器上，从而提供Cache集群系统的使用效率。LBLCR算法先根据请求的目标IP 地址找出该目标IP地址对应的服务器组；按“最小连接”原则从该服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载；则按 “最小连接”原则从整个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服 务器从服务器组中删除，以降低复制的程度。

七、最短的期望的延迟(Shortest Expected Delay Scheduling ,sed)

sed: (A+1)/w=当前连接数

八、最少队列调度(Never Queue Scheduling ,nq)

无需队列。如果有台realserver的连接数＝0就直接分配过去，不需要在进行sed运算

说明：如果LVS放置于多防火墙的网络中，并且每个防火墙都用到了状态追踪的机制，那么在回应一个针对于LVS的连接请求时必须经过此请求连接进来时的防火墙，否则，这个响应的数据包将会被丢弃。

使用最多的算法是rr,wrr,lc,wlc

LVS中应注意的地方：

默认情况下，ipvsadm在输出主机信息时使用其主机名而非IP地址，因此，Director需要使用名称解析服务。如果没有设置名称解析服务、服务不可用或设置错误，ipvsadm将会一直等到名称解析超时后才返回。当然，ipvsadm需要解析的名称仅限于RealServer，考虑到DNS提供名称解析服务效率不高的情况，建议将所有RealServer的名称解析通过/etc/hosts文件来实现；如果LVS放置于多防火墙的网络中，并且每个防火墙都用到了状态追踪的机制，那么在回应一个针对于LVS的连接请求时必须经过此请求连接进来时的防火墙，否则，这个响应的数据包将会被丢弃。

8.2LVS目前有三种IP负载均衡技术

Virtual Server via Network Address Translation(VS/NAT)通过网络地址转换，调度器重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器；真实服务器的响应报文通过调度器时，报文的源地址被重写，再返回给客户，完成整个负载调度过程(调度器的处理能力是瓶颈)。

Virtual Server via IP Tunneling(VS/TUN)采用NAT技术时，由于请求和响应报文都必须经过调 度器地址重写，当客户请求越来越多时，调度器的处理能力将成为瓶颈。为了解决这个问题，调度器把请求报文通过IP隧道转发至真实服务器，而真实服务器将响 应直接返回给客户，所以调度器只处理请求报文。由于一般网络服务应答比请求报文大许多，采用 VS/TUN技术后，集群系统的最大吞吐量可以提高10倍。

Virtual Server via Direct Routing(VS/DR)VS/DR通过改写请求报文的MAC地址，将请求 发送到真实服务器，而真实服务器将响应直接返回给客户。同VS/TUN技术一样，VS/DR技术可极大地提高集群系统的伸缩性。这种方法没有IP隧道的开 销，对集群中的真实服务器也没有必须支持IP隧道协议的要求，但是要求调度器与真实服务器都有一块网卡连在同一物理网段上。

8.3架构：

这里以10.15.62.202为master，10.15.62.203为backup

8.4安装ipvsadm：

(master和back均安装)

由于缺乏这个debian版本的内核文件，在编译ipvsadm的时候需要读取内核的一些head文件，所以这里采用apt-get安装

8.4.1 Ipvsadm软件安装

#apt-get install ipvsadm

安装完成以后会生成文件 /etc/default/ipvsadm

8.4.2 配置文件修改

修改成以下内容：(开机启动就加载此模块)

8.4.3查看系统是否加载此模块：

8.5安装keepalived：

(master和back均执行如下操作)

8.5.1 安装keepalived所依赖的一些库文件：

#apt-get install libssl-dev

#apt-get install openssl

#apt-get install libpopt-dev

8.5.2 选择合适的keepalived版本

由于keepalived的版本不同，系统对相应模块支持得也有所不通，在debian下使用1.2.2的版本的时候发现keepalived不支持ip_vs模块，同时版本的更新也扩展了不同的功能和对以往bug的修复，这里使用最新的版本：keepalived-1.2.9.tar.gz

8.5.3 安装程序

#tar -zxvf keepalived-1.2.9.tar.gz

#cd keepalived-1.2.9

#./configure --prefix=/opt/keepalived

确保keepalived对ip_vs模块的支持，如下：

#make;make install

说明：

8.5.4 修改启动脚本

/opt/keepalived/sbin/keepaived 为可执行程序

/opt/keepalived/etc/rc.d/init.d/keepalived 是可以作为service的脚本文件,复制到/etc/init.d目录下

#cp /opt/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/

修改此文件的四个地方：

①. /etc/rc.d/init.d/functions 修改为：

. /lib/lsb/init-functions

②. /etc/sysconfig/keepalived  修改为：

. /opt/keepalived/etc/sysconfig/keepalived

③daemon keepalived ${KEEPALIVED_OPTIONS} 修改为：

# daemon keepalived ${KEEPALIVED_OPTIONS}

daemon ${keepalived} start

④增加配置：(修改可执行文件的路径)

#exec file

keepalived=/opt/keepalived/sbin/keepalived

说明：1，2两步修改是因为redhat之外的Linux没有上面两处目录

3  修改启动执行的命令

4  指明调用可执行文件的路径

修改后即为：

当然可以根据实际情况修改：

8.5.5 启动服务，测试：

新建lock目录：

#mkdir -p /var/lock/subsys

将keepalived加入到系统启动服务：

#update-rc keepalived defaults

启动服务：

#service  keepalived start

查看是否正常启动：

表明程序安装已经正常了

8.6 修改配置文件满足负载均衡和HA

以下只针对master操作，backup操作类似

#mkdir /etc/keepalived/

说明： 从keepalived的启动脚步中可以看到keepalived加载配置的文件的目录为/etc/keepalived

使用安装以后的配置模版文件并修改：

#cp /opt/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/

修改配置文件(修改为红色部分)

! Configuration File for keepalived

global_defs {

notification_email {

524116195@qq.com

}

notification_email_from 524116195@qq.com

smtp_server 163.177.65.211

smtp_connect_timeout 30

router_id LVS_DEVEL

}

vrrp_instance VI_1 {

state MASTER

interface eth0

virtual_router_id 51

priority 100

advert_int 1

authentication {

auth_type PASS

auth_pass yxm@2013

}

virtual_ipaddress {

10.15.62.222

}

}

virtual_server 10.15.62.222 30000 {

delay_loop 6

lb_algo rr

lb_kind DR

persistence_timeout 50

protocol TCP

real_server 10.15.62.202 30000 {

weight 10

TCP_CHECK {

connect_timeout 5    #5秒无响应超时

nb_get_retry 3       #重试次数

delay_before_retry 3   #重试间隔

connect_port 30000      #连接端口

}

}

real_server 10.15.62.203 30000 {

weight 10

TCP_CHECK {

connect_timeout 5    #5秒无响应超时

nb_get_retry 3       #重试次数

delay_before_retry 3   #重试间隔

connect_port 30000      #连接端口

}

}

real_server 10.15.62.205 30000 {

weight 10

TCP_CHECK {

connect_timeout 5    #5秒无响应超时

nb_get_retry 3       #重试次数

delay_before_retry 3   #重试间隔

connect_port 30000      #连接端口

}

}

}

说明：从服务器与主服务器基本相同，只要改二个地方就行了，priority的权重调小一点，state改成BACKUP

8-7 查看启动过程和测试负载情况

对配置文件修改后重启程序

#service keepalived restart

8-7-1查看启动日志：

#tail -f /var/log/message

Nov 22 17:03:41 debian Keepalived_vrrp[8113]: VRRP_Instance(VI_1) sending 0 priority

Nov 22 17:03:41 debian Keepalived_healthcheckers[8112]: Removing service [10.15.62.202]:30000 from VS [10.15.62.222]:30000

Nov 22 17:03:41 debian Keepalived_healthcheckers[8112]: Removing service [10.15.62.203]:30000 from VS [10.15.62.222]:30000

Nov 22 17:03:41 debian kernel: [ 9715.642476] IPVS: __ip_vs_del_service: enter

Nov 22 17:03:41 debian Keepalived_vrrp[8593]: Registering Kernel netlink reflector

Nov 22 17:03:41 debian Keepalived_vrrp[8593]: Registering Kernel netlink command channel

Nov 22 17:03:41 debian Keepalived_vrrp[8593]: Registering gratuitous ARP shared channel

加载配置文件：

Nov 22 17:03:41 debian Keepalived_vrrp[8593]: Opening file '/etc/keepalived/keepalived.conf'.

Nov 22 17:03:41 debian Keepalived_vrrp[8593]: Configuration is using : 63140 Bytes

Nov 22 17:03:41 debian Keepalived_healthcheckers[8592]: Registering Kernel netlink reflector

Nov 22 17:03:41 debian Keepalived_vrrp[8593]: Using LinkWatch kernel netlink reflector...

Nov 22 17:03:41 debian Keepalived_healthcheckers[8592]: Registering Kernel netlink command channel

Nov 22 17:03:41 debian Keepalived_healthcheckers[8592]: Opening file '/etc/keepalived/keepalived.conf'.

Nov 22 17:03:41 debian Keepalived_healthcheckers[8592]: Configuration is using : 16767 Bytes

Nov 22 17:03:41 debian Keepalived_healthcheckers[8592]: Using LinkWatch kernel netlink reflector...

健康检查

Nov 22 17:03:41 debian Keepalived_healthcheckers[8592]: Activating healthchecker for service [10.15.62.202]:30000

Nov 22 17:03:41 debian Keepalived_healthcheckers[8592]: Activating healthchecker for service [10.15.62.203]:30000

Nov 22 17:03:41 debian Keepalived_healthcheckers[8592]: Activating healthchecker for service [10.15.62.205]:30000

Vrrp主备选举检查

Nov 22 17:03:41 debian Keepalived_vrrp[8593]: VRRP_Instance(VI_1) Transition to MASTER STATE

Nov 22 17:03:42 debian Keepalived_vrrp[8593]: VRRP_Instance(VI_1) Entering MASTER STATE

Nov 22 17:03:43 debian Keepalived_healthcheckers[8592]: TCP connection to [10.15.62.205]:30000 failed !!!

Nov 22 17:03:43 debian Keepalived_healthcheckers[8592]: Removing service [10.15.62.205]:30000 from VS [10.15.62.222]:30000

邮件地址配置smtp连接503是由于本地MTA故障(未开启sendmail或者postfix邮件服务)

Nov 22 17:03:43 debian Keepalived_healthcheckers[8592]: Remote SMTP server [163.177.65.211]:25 connected.

Nov 22 17:03:44 debian Keepalived_healthcheckers[8592]: Error processing MAIL cmd on SMTP server [163.177.65.211]:25. SMTP status code = 503

Nov 22 17:03:44 debian Keepalived_healthcheckers[8592]: Can not read data from remote SMTP server [163.177.65.211]:25.

此时看到负载连接情况结果如下：

接下来在启动10.15.62.205的mongos服务

查看日志发现如下：

Nov 22 17:27:54 debian Keepalived_healthcheckers[2002]: TCP connection to [10.15.62.205]:30000 success.

Nov 22 17:27:54 debian Keepalived_healthcheckers[2002]: Adding service [10.15.62.205]:30000 to VS [10.15.62.222]:30000

已经正常连接10.15.62.205 30000端口了

Nov 22 17:27:54 debian Keepalived_healthcheckers[2002]: Remote SMTP server [163.177.65.211]:25 connected.

Nov 22 17:27:54 debian Keepalived_healthcheckers[2002]: Error processing MAIL cmd on SMTP server [163.177.65.211]:25. SMTP status code = 503

Nov 22 17:27:54 debian Keepalived_healthcheckers[2002]: Can not read data from remote SMTP server [163.177.65.211]:25.

命令查看负载连接情况：

8-7-2宕机测试

现在宕掉master的keepalived观察bakcup是否会变为master

可以很明显到backup 变为master了

然后在恢复master的服务观察是否重新选举master

由于master的优先级为100，所以当健康监测以后master接收用户请求

8-8  后端真实服务器进行网络设置并对外提供服务

①在提供真实服务的realserver执行如下脚本：

#!/bin/bash

VIP=10.15.62.222

. /lib/lsb/init-functions

case "$1" in

start)

/sbin/ifconfig lo:0 $VIP netmask 255.255.255.255 broadcast $VIP up

/sbin/route add -host $VIP dev lo:0

echo "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore

echo "2" > /proc/sys/net/ipv4/conf/lo/arp_announce

echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore

echo "2" > /proc/sys/net/ipv4/conf/all/arp_announce

sysctl -p >/dev/null 2>&1

echo "RealServer Start Ok"

;;

stop)

/sbin/ifconfig lo:0 down

/sbin/route del $VIP >/dev/null 2>&1

echo "0" > /proc/sys/net/ipv4/conf/lo/arp_ignore

echo "0" > /proc/sys/net/ipv4/conf/lo/arp_announce

echo "0" > /proc/sys/net/ipv4/conf/all/arp_ignore

echo "0" > /proc/sys/net/ipv4/conf/all/arp_announce

echo "RealServer stoped"

;;

*)

echo "useage $0{start|stop}"

exit 1

esac

exit 0

②接下来修改/etc/sysctl.conf将net.ipv4.ip_forward = 1打开路由转发

#sysctl -p  (修改生效)

③然后在realserver上执行的realserver.sh至此Realserver上操作已完成

说明：此脚本主要是在换回接口lo上开启一个VIP(环回接口可以隔离广播)，关闭arp抑制

④然后使用VIP登录mongodb发现一切正常，查看连接状态为：

目前就写到这，关于mongo备份，监控，将和varinsh，nginx，tornado监控一起完成！