Solo Estoy » architecture http://www.opslife.com 人生不过是一场旷日持久却又无法rollback的operation而已 Mon, 16 Jan 2012 01:34:11 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 有关DSR的网络拓扑结构和实现方法 http://www.opslife.com/dsr-implemention/ http://www.opslife.com/dsr-implemention/#comments Fri, 18 Sep 2009 13:41:55 +0000 dawnh http://opslife.com/dsr-implemention/ [...]]]> 前两天在delphij老大的blog中看到了一篇《使用DSR模式实现单IP服务冗余》，觉得很有意思，因为这个实现方式与我以往所见到的有些不同，通过关闭ARP响应来解决虚拟IP在负载均衡设备和服务器上可能冲突的问题。随即提问了一下我所熟悉方式的实现是否可行，勤恳的delphij竟然又写了一篇来解释这个问题。不过这篇的思路似乎与我原来的想法有点出入，所以仔细又思考了一下，最终决定还是要完整的阐述一下我的思路。

我虽然见过一些DSR的实现方式，然而只不过是阅读架构文档而已，想当然来的东西跟最后实际实施出来的东西肯定有差距，所以把自己认为的设计思路记录下来，看看最终是否可行。

首先是拓扑图：

DSR

介绍一下简单的信息：

  • Public VLAN直连Internet，LB和Router分别有一个网卡接口连在这里，用于承载Internet的虚拟IP自然也就是绑在LB连在Public VLAN的NIC上了，方便起见，随便起个IP: 202.96.100.100(202.96段是中国电信骨干IP段，很多坏事都是这里发生的:D)
  • Internal VLAN是放服务器集群的网段，当然就用私有地址，就用典型的192.168.1.0/24吧，这里的Server使用IP 192.168.1.101

首先从数据流角度来看（红色箭头上的标号）：

  1. 客户发起到请求： 61.152.X.X:1025 –> 202.96.100.100:80
  2. 负载均衡设备通过匹配包，发现目的IP为虚拟IP，根据Load balance算法挑选一台Server，将数据报直接路由到这台Server，不做任何修改（减TTL不算）61.152.X.X:1025 –> 202.96.100.100:80
  3. Server看到数据报的目的IP是虚拟IP，并发现虚拟IP绑定在自己的lo上，认为目的地是自己，OS派发到应用层Web Server处理Request并生成结果，结果数据包变为 202.96.100.100:80 –> 61.152.X.X:1025
  4. 数据报发往路由器，路由器看到目的地为客户IP，路由到Internet去。

这个过程与传统NAT方式的Load Balance的区别在于，LB不修改目的地址，直接将数据报通过路由的方式转发给服务器集群。然而这里的难点就在于：如果不修改目的IP，那必须让Server能够对发往虚拟IP的请求做出响应，那就必须要把虚拟IP绑定在Server端，因此虚拟IP就同时出现在了两个地方：LB和Server，解决这个冲突就是完成DSR的关键所在。对于此点引用delphij的原话：

实现DSR结构的关键是，通往Internet路由器的那个网络上，只有负载平衡设备在网络上宣示虚拟出来的那个IP的MAC地址，这样，当请求进来的时候，数据会发到负载平衡设备，而不是某一台服务器上。

Delphij采用的方法是，将服务器上网卡的ARP功能关闭，这样服务器虽然绑定了虚拟IP，但不会对外界对于虚拟IP的MAC地址解析请求做出响应，所以完美解决了IP重复的问题。缺点是ARP一关Server自己会找不到Router或者网络内的其他服务器，因此需要手工维护一个静态ARP表。

而我所采用的方式，是不将虚拟IP绑定在实际网卡上，只是绑定在Server的还回(lo)上，这样依旧可以起到缩减ARP响应域的作用。

Delphij认为这样会需要一个额外的Public IP，不过我认为如果Server放在私有地址VLAN的话，应该是不需要额外的IP，在如图的这种拓扑中应该可以完美的工作。只要LB和Server中作出如下配置（红色罗马数字）：

I.  Load Balancer要特别设置的地方有：

  • 需要有合适的负载均衡算法以便于把流量分发给不同的Server。
  • 对于TCP这种有状态的服务，需要使用较为宽松的状态机制来维持会话。

这里引用delphij的pf命令为例，如下，round-robin是负载均衡算法，keep-state(slopppy)是宽松状态匹配，这一点对于DSR也是尤为重要，因为DSR的特点就是从Server发回的响应不经过LB，LB看不见回去的响应包，所以Session track必须能容忍这种半吊子连接。而且这里似乎也必须修改Session的timeout时间，否则会有问题，这里无关者略过：

    FreeBSD pf规则举例：pass in on em0 route-to { em1 内网IP1, em1 内网IP2, em1 内网IP3 } round-robin proto tcp from any to 公网IP port http keep state (sloppy)

II.  Server端需要的设置：

  • 在lo上绑定虚拟IP 202.96.100.100，这样Server才会认为目的地是自己。
  • Web Server本身要使用虚拟IP作为监听IP，比如Apache配置Virtualhost的话这样用：<VirtualHost 202.96.100.100:80> ，如此以来Web server会对到虚拟IP的请求做出响应，且响应的源地址也是虚拟IP而不是自己网卡上的私有IP。
  • Server将默认网关设置为Router的IP，这样对于请求的响应就会发往Router而不会返回LB了。

III. Router上应该不需要什么特殊设置，知道把发往Internet的包路由出去就行

这样整个DSR就应该能走通了，不过这个玩法我也只是想出来而已，还没有经过实践，当初看到过F5的nPath实现，应该就是这么种玩法，不过估计实际应用时应该会有我这里没有想到得地方，所以有时间的话，最好还是找几个设备搭一下看看吧，先把设想架构放这儿，改天回来验证。说实话，delphij指出这里必须要有一个额外的公网IP才能保证知道出去的包怎么走，我这点还是没有想通。不管怎样，写出来让大家指正吧，至少在写这篇的过程中，我已经将自己以前没考虑到得一些细节补充完整了，对于自己来说，也算是不小的收获。

]]> http://www.opslife.com/dsr-implemention/feed/ 1 再论Dreamhost和overselling http://www.opslife.com/dreamhost-architecture-and-overselling/ http://www.opslife.com/dreamhost-architecture-and-overselling/#comments Tue, 08 May 2007 07:28:49 +0000 dawnh http://dawnh.net/weblog/184/dreamhost-architecture-and-overselling/ 今天看到了订阅的Michael 写的一篇《Dreamhost 服务器上的网站数量》的文章，提到了Dreamhost单台服务器网站数量以及overselling的问题，就我用过这段时间的Dreamhost的主机来看，这些地方是值得一说的。

首先关于overselling，所有主机商都在overselling，这是不可否认的事实。一方面，肯定不是所有客户能用光它的所有空间和流量额度的，从客户层面来看，只要客户在使用它的空间时，不出现还未到达额度就不能用的情况，客户就可以接受。有没有预留足够的空间那是服务商的问题。另一方面，服务商如果为每个客户预留足够配额的空间，在大多数情况下都是不必要的，这绝对是资源的浪费。因此overselling是再正常不过的了。对于主机商和用户，大可以不必关心此类问题，所剩下的只不过是道义上主机商有没有刻意隐瞒这种行为，或者把不隐瞒这种行为作为自身诚实的卖点的区别而已。

可能有人会问，如果恰好每台服务器上有很多较真的客户，非要用满空间额度，导致服务器硬盘爆了怎么办？实际这个问题从技术上也是不难解决的，例如磁盘阵列的动态扩容，逻辑卷增容等都可以实现，所要做的只不过是监控服务器资源使用情况，在将要达到临界值的时候通知sysadmin增容而已。即使系统弱智到无法扩容，不是还可以把用户站点分流到其他服务器嘛，只不过会增加一个无downtime的迁移过程而已。总之办法多的是。因此主机商采用overselling的策略，是对用户以及对其自身都有利的。

貌似Dreamhost的overselling被指责更多是多用户站点并存导致的负载以及不稳定因素，而不是空间或者流量overselling问题。下面再讲讲这一点，因为貌似Dreamhost在这里主机架构与其它一些传统厂商有很大不同。

在前面提到的文章里，介绍了通过截passwd来断定一台服务器上有多少帐号的方法，此方法确实能大致估算出一台服务器上有多少站点。但这里有一个问题，就是你shell帐号所在的主机真的就是你web访问的主机吗？从一个shell帐号本身所具有的权限我们来一步一步推断这个问题：

首先不知有没有人注意，在后台panel创建的不同的domain可能会有不同的IP，甚至在同一domain使用了一段时间后，再删除重建也可能会更换IP（非常少见）。这就说明，dreamhost的系统首先对于每个IP上容载的vhost数目有其自身的一个分配机制。也就是说：每IP上的站点数目对于dreamhost是可控的，并且这个数目应当是小于物理服务器上站点数目的。这个机制就能解决站点添加独立IP的问题，以及对IP实现的流控或访问量问题，也就做到了初步客户访问层面的隔离。比如说可能一个IP出问题，影响的也就仅仅是这个IP上的站点了。当然貌似大多数的downtime不太可能是这种情况。

然后深入分析一下。一个典型的站点，大体服务层次可以分为基于IP+头名的客户访问层次（就是上面一段的内容），应用服务器层次（Application Server，比较容易混淆的概念），文件存储层次（ftp，ssh所管理的文件），附加服务层次（mysql，dns，email等）。对于传统主机商，最典型的情况是所有这些服务都由同一台物理服务器完成的，或者是少量附加服务分离，例如数据库单独运行在别的服务器上，而对于dreamhost，显然不是这样。就我目前所能了解到的东西来看，dreamhost的web前端，dns，email是分离的，至少没在同一个IP上，这个可以从不同的子域名解析看出来。但web前端的IP和ftp，ssh帐号登陆的IP是同一个，这似乎说明这些服务似乎也是运行在一台物理服务器上的。但有一个命令似乎能提供出不同的论点，就是mount，输入这个会发现列出的挂载点中有很多nfs挂在过来的文件系统，而这些系统恰恰是放客户数据的/home下的不同目录。而且从具体/home里的内容可以看到有很多更为复杂的符号链接，有多个用户的家目录会挂在同一个mount点下。不妨设想，这是通过nfs提供的文件存储服务器，一台用于前端web访问的服务器，后面挂了多台nfs server，这些nfs server，才是具体存放用户数据的服务器。

所以这里就明朗了，dreamhost在同一台服务器上放置数千个站点，实际上这些站点的文件是存储在不同的后端nfs server上的。因此其overselling并不是想象得那么夸张。再加上无法断定的是否对于多个不同IP也处于不同物理服务器分担（ifconfig netstat无权执行），apache本身配置未知，应用服务配置（fastcgi等，这些没必要追究得太细，估计也没人关心）等情况，往好一点的方面想dreamhost可能会有更细致的分布式设计，因此一台双Operton跑数千个站点数T空间从技术上也可以大致讲通了。

大体也就写这么多了吧，以前本打算悉心研究一下dreamhost的底层架构来的，可惜一直没时间，最近由由于速度问题退掉了原有的dreamhost选择了hostmonster，因此也只能分析到如此程度了。但用起cpanel以后的系统才发现，dreamhost本身的架构设计以及panel考量还是很优秀的，比起这些老前辈来说，可以算是十分有特点了。Dreamhost如此出名不是没道理的。

]]> http://www.opslife.com/dreamhost-architecture-and-overselling/feed/ 5