Simulating WAN network delay

Motivation

When testing the version of AutoFS from RHEL-3, Update 4 in a global WAN environment I discovered an interesting bug. When logged into a client machine in London, every now & attempts to access a mount from an NFS server in Boston would fail perhaps 25% of the time. The server was clearly online, since mounts from other clients would work fine, and there were no obvious errors in the logs from either the client or server. After a little more testing I discovered that mounts between London and LA would fail 100% reliably [sic]. This led me to believe that there was some part of the AutoFS mount process which was sensitive to network round trip time. Sure enough, there was a piece of code which checked for ‘livliness’ of the server by sending an RPC ping and had a fixed timeout of 100ms. Well on my particuarly WAN, ping times between London and Boston were 100ms +/- 5ms – no wonder it failed seemingly at random. Once identified the bug itself was trivially fixable by letting the code fallback to a longer timeout, if no server being tested had replied within the short timeout. I then got on to thinking about how you might build a system under which AutoFS could be reliably tested in a lab, without requiring co-location of part of the system half-way around the globe.

Planned solution

The obvious solution is to figure out a way to introduce arbitrary network packet delay between two hosts on the same subnet. I considered two possibilities

1. Setup a virtual interface on one of the hosts using the tun driver, and have the usre space daemon processing it queue up packets for Xms before sending them out. A few routing table entries and IPtables rules could then be used to redirect traffic on eth0 via the take tun0 interface.
2. Use the IPtables QUEUE target to intercept traffic on the actual network interface, redirecting to a userspace program to delay them

In the end I chose the second one since it seem to potentially require less work to implement and setup.

Implementation

CPAN has a Perl module IPQueue.pm which backends onto the libipq.so library which is part of IPTable codebase. With this, the Perl userspace daemon becomes obscenely easy to write. In pseudo-code

forever
  foreach queued packet
     if queue time > requested delay
        accept packet

  wait for an incoming packet

  add packet to queue

The actual code is in the script delay-net.pl.

Running it

The first task is to load up the neccessary iptables kernel modules

modprobe iptable_filter
modprobe ip_queue
modprobe ipt_ttl

Now start the daemon – its important we do this before adding the IPTables rules to QUEUE traffic, otherwise you’ll potentially lock yourself out of the machine! It takes the number of milliseconds delay its only command line argument, so lets delay for 300 milliseconds

./delay-net.pl 300

Then add a rule to redirect incoming traffic from either the entire network, or better, from a particular host.

iptables -A INPUT --source 192.168.16.4 -j QUEUE

If you now run ‘ping’ from the host mentioned in the iptables rule, you should see an nice (approximate) 300ms delay.

Downloads

For convenience here are downloads of the various packages required to run on a RHEL-3 system

• Source RPM for perl-ipq (aka IPQueue.pm module)
• Binary RPM for perl-ipq
• IPTables devel RPM (required for re-building perl-ipq RPM)
• net-delay.pl (the Perl userspace daemon)

新域名 http://www.cnadn.net

新RSS聚合地址 http://feed.feedsky.com/cnadn

原始RSS地址 http://www.cnadn.net/feed

原RSS聚合地址将在30日后被删除，30日内原聚合地址可以自动转向到原始RSS地址，建议您使用新RSS聚合地址

原域名存在一些商标歧义，带来不便，还请谅解。

1.配置login page 强制功能时，被强制的页面一定要在allowed url中明确定义，否则会出现奇怪的结果。
定义allowed url，这url就是希望被强制的页面
定义login url ，需正确的判断成功的条件
定义login page setting，设置被强制的url或设置超时时间

2.配置navigation parameters时，定义的参数如果是for any url path的，那么用到这个参数的所有url都要在allowed url中明确定义，否则会被阻拦。

3.XFF TRUST, 默认没开启，即ASM不以http header中的x-forwarded-for作为源地址。开启后，asm总是以最后一个x-forwarded-for值为准，即：
a。如果有多行x-forwarded-for，则取最后一行，最后一行如果为空值，则以ip包源地址为准
b.如果一个x-forwarded-for头中有多个值，以最后一个IP为准。
c。如果x-forwarded-for头的值ASM无法分析（例如不是以逗号分隔ip，或者值为非ip），则以ip包源地址为准
d.如果vs的http profile开启了x-forwarded-for将导致ASM取得是ip包源地址

4.

*当策略为transparent，如果一个wildcard策略对象同时处在staging 和tightening阶段，此时asm的日志文件中不会记录该请求日志。

**当策略为blocking，如果一个wildcard策略对象同时处在staging和tightening阶段（v11.1测试无需同时处于该两个阶段，只需处于tightening阶段即可），此时促发violation的请求不会被block。例如parameter当前有一个处于tightening的wildcard对象，然后通过它新学到一个全新的parameter，此时新的parameter自动处于staging阶段，针对该新parameter ASM是不阻拦的。

logging profile ,控制是否记录request log到report–requesting里，不控制是否记录到asm.log。
blocking setting中的alarm控制是否写日志到asm.log中
blocking setting中的learn控制是否记录violation到 manual policy building中 （数据库PLC.LRN_REQUESTS）

5.

Tightening is using wildcards to learn the entities (file types, URLs,
parameters, and cookies). Staging is learning the attributes of an entity
(wildcard or explicit), providing additional granularity over tightening.

6.

F5 Networks recommends against using both tightening and
staging at the same time on the same wildcard entity.

7.选择production的方式建立一个fundamental type的策略，设置后的策略并检测到流量后开始进入自动学习模式：

（1）策略处于blocking模式，signature处于staging模式

（2）学习周期7天

（3）file type会自动增加一个wildcard 并置为tightening模式，可以自动将学习到的文件类型放入策略列表中（但也不是全部）

（4）url自动创建2个wildcard，但不处于学习状态，即不学习url

（5）parameters 自动创建wildcard，处于staging阶段，不能自动将参数放入策略列表中

（6）header-cookie,自动创建wildcard，不学习

7.1如果将fundamental type改为enhanced type 则parameters 进入tightening状态自动将学习到的条目加入策略列表，cookie也进入tightening状态。–似乎也不是所有条目都能自动放入到策略列表中。cookie学习到的还得等待手工accept。

7.2如果将enhaced type改为complete type 则又会增加URI进入tightening状态来自动将学习到的条目加入到列表。—-似乎也不是所有条目都能自动放入到策略列表中

（其实这些差别可以在自动策略学习设置界面中的“

部分看到”）

8.建立策略的时候 选择 production site 和QA lab 两种模式，对策略的学习到底有何不同的影响？

QA自动认为所有请求都来自合法用户，QA会将学习到的所有项目都列入策略作为合法条目，即staging-tightening summary界面的“have suggestions”会很少，但不是没有。

production缺省认为请求不是来自合法用户，需要手工设置trust ip，此模式下从非信任IP上学习到的项目部分能自动进入策略列表，但也有很多等待手工确认。 没太明白这里。

动态应用，是相对于网站静态内容而言，是指以c/c++、php、Java、perl、.net等服务器端语言开发的网络应用软件，比如论坛、网络相册、交友、BLOG等常见应用。动态应用系统通常与数据库系统、缓存系统、分布式存储系统等密不可分。

大型动态应用系统平台主要是针对于大流量、高并发网站建立的底层系统架构。大型网站的运行需要一个可靠、安全、可扩展、易维护的应用系统平台做为支撑，以保证网站应用的平稳运行。

大型动态应用系统又可分为几个子系统：

1）Web前端系统

2）负载均衡系统

3）数据库集群系统

4）缓存系统

5）分布式存储系统

6）分布式服务器管理系统

7）代码分发系统

Web前端系统

结构图：

为了达到不同应用的服务器共享、避免单点故障、集中管理、统一配置等目的，不以应用划分服务器，而是将所有服务器做统一使用，每台服务器都可以对多个应用提供服务，当某些应用访问量升高时，通过增加服务器节点达到整个服务器集群的性能提高，同时使他应用也会受益。该Web前端系统基于Apache/Lighttpd/Eginx等的虚拟主机平台，提供PHP程序运行环境。服务器对开发人员是透明的，不需要开发人员介入服务器管理

负载均衡系统

结构图：

负载均衡系统分为硬件和软件两种。硬件负载均衡效率高，但是价格贵，比如F5等。软件负载均衡系统价格较低或者免费，效率较硬件负载均衡系统低，不过对于流量一般或稍大些网站来讲也足够使用，比如lvs, nginx。大多数网站都是硬件、软件负载均衡系统并用。

数据库集群系统

结构图：

由于Web前端采用了负载均衡集群结构提高了服务的有效性和扩展性，因此数据库必须也是高可靠的，才能保证整个服务体系的高可靠性，如何构建一个高可靠的、可以提供大规模并发处理的数据库体系？

我们可以采用如上图所示的方案：

1) 使用 MySQL 数据库，考虑到Web应用的数据库读多写少的特点，我们主要对读数据库做了优化，提供专用的读数据库和写数据库，在应用程序中实现读操作和写操作分别访问不同的数据库。

2) 使用 MySQL Replication 机制实现快速将主库（写库）的数据库复制到从库（读库）。一个主库对应多个从库，主库数据实时同步到从库。

3) 写数据库有多台，每台都可以提供多个应用共同使用，这样可以解决写库的性能瓶颈问题和单点故障问题。

4) 读数据库有多台，通过负载均衡设备实现负载均衡，从而达到读数据库的高性能、高可靠和高可扩展性。

5) 数据库服务器和应用服务器分离。

6) 从数据库使用BigIP做负载均衡。

缓存系统

结构图：

缓存分为文件缓存、内存缓存、数据库缓存。在大型Web应用中使用最多且效率最高的是内存缓存。最常用的内存缓存工具是Memcached。使用正确的缓存系统可以达到实现以下目标：

1）使用缓存系统可以提高访问效率，提高服务器吞吐能力，改善用户体验。

2）减轻对数据库及存储集服务器的访问压力。

3）Memcached服务器有多台，避免单点故障，提供高可靠性和可扩展性，提高性能。

分布式存储系统

结构图：

Web系统平台中的存储需求有下面两个特点：

1) 存储量很大，经常会达到单台服务器无法提供的规模，比如相册、视频等应用。因此需要专业的大规模存储系统。

2) 负载均衡cluster中的每个节点都有可能访问任何一个数据对象，每个节点对数据的处理也能被其他节点共享，因此这些节点要操作的数据从逻辑上看只能是一个整体，不是各自独立的数据资源。

因此高性能的分布式存储系统对于大型网站应用来说是非常重要的一环。（这个地方需要加入对某个分布式存储系统的简单介绍。）

分布式服务器管理系统

结构图：

随着网站访问流量的不断增加，大多的网络服务都是以负载均衡集群的方式对外提供服务，随之集群规模的扩大，原来基于单机的服务器管理模式已经不能够满足我们的需求，新的需求必须能够集中式的、分组的、批量的、自动化的对服务器进行管理，能够批量化的执行计划任务。

在分布式服务器管理系统软件中有一些比较优秀的软件，其中比较理想的一个是Cfengine。它可以对服务器进行分组，不同的分组可以分别定制系统配置文件、计划任务等配置。它是基于C/S 结构的，所有的服务器配置和管理脚本程序都保存在Cfengine Server上，而被管理的服务器运行着 Cfengine Client 程序，Cfengine Client通过SSL加密的连接定期的向服务器端发送请求以获取最新的配置文件和管理命令、脚本程序、补丁安装等任务。

有了Cfengine这种集中式的服务器管理工具，我们就可以高效的实现大规模的服务器集群管理，被管理服务器和 Cfengine Server 可以分布在任何位置，只要网络可以连通就能实现快速自动化的管理。

代码发布系统

结构图：

随着网站访问流量的不断增加，大多的网络服务都是以负载均衡集群的方式对外提供服务，随之集群规模的扩大，为了满足集群环境下程序代码的批量分发和更新，我们还需要一个程序代码发布系统。

这个发布系统可以帮我们实现下面的目标：

1) 生产环境的服务器以虚拟主机方式提供服务，不需要开发人员介入维护和直接操作，提供发布系统可以实现不需要登陆服务器就能把程序分发到目标服务器。

2) 我们要实现内部开发、内部测试、生产环境测试、生产环境发布的4个开发阶段的管理，发布系统可以介入各个阶段的代码发布。

3) 我们需要实现源代码管理和版本控制，SVN可以实现该需求。

这里面可以使用常用的工具Rsync，通过开发相应的脚本工具实现服务器集群间代码同步分发。

http://www.isn8.com/blog/?p=857

startup :

put script in

/config/startup

failover:

put script in

/config/failover/acitve

or

/config/failover/standby