科学计算领域,集群这种计算工具有相当重要的作用,通常一个集群可以有几十、几百颗通过高速组合在一起，形成巨大的计算资源为特定的应用服务。 　　我们首先来介绍一下集群，Cluster集群可如下定义:一组相互独立的服务器在中表现为单一的系统，并以单一系统的模式加以管理。此单一系统为客户工作站提供高可靠性的服务。　　大多数模式下，集群中所有的拥有一个共同的名称，集群内任一系统上运行的服务可被所有的网络客户所使用。Cluster必须可以协调管理各分离的组件的错误和失败，并可透明地向Cluster中加入组件。　　一个Cluster包含多台(至少二台)拥有共享数据的服务器。任何一台服务器运行一个应用时，应用数据被存储在共享的数据空间内。每台服务器的和应用文件存储在其各自的本地储存空间上。　　Cluster内各节点服务器通过一内部相互通讯。当一台节点服务器发生故障时，这台服务器上所运行的将在另一节点服务器上被自动接管。当一个应用服务发生故障时，应用服务将被重新启动或被另一台服务器接管。当以上任一故障发生时，客户将能很快连接到新的应用服务上。　　由于组成集群的机器不尽相同，所以我们通常可以把集群分成两种:工作站集群和胖节点集群。　　工作站集群(COW)　　工作站集群的节点机规模一般都比较小，常常配备的示2-4颗处理器的服务器，采用通常的以太网或者InfiniBand来连接，一般采用集群操作系统来对集群进行管理。　　这种集群最常见的是PC服务器厂商的PC-Cluster集群或者刀片服务器集群，他的优点主要是价格便宜和容易部署，所以很多小的服务器厂商也可以做这种集群。在国外，很多通过一个公用的高速专用网络，将数十台的PC联在一起，用Linux集群操作系统来管理，就构成了这种集群。　　这种集群的缺点是不太稳定，不能运行大规模的商业应用。而且由于这种松散连接，使得占用的空间可能比较大，散热也成问题。　　胖节点集群　　胖节点集群的服务器节点多是8-16颗CPU的SMP服务器，其大大提高，通过专有技术用以太网或者InfiniBand连接，系统采用UNIX操作系统，应用经过优化的专用集群管理软件。常见的机器有IBM的 Cluster1600和HPQ AlphaServer SC，他的好处是节点机的性能比较稳定，系统节点不太容易出问题，这样就可以运行大型的应用程序，应用到商业或者科学计算中。它的扩展性也比较好，支持所有并行方式，但是相比于前一种，价格也要贵很多。国外和国内都有这种应用案例，当然这种价格也不是一般企业和机构可以采用的，多数是原来做商业计算或者科研。　　IBM做集群的服务器　　由于IBM
P系列的属于小型机范畴，所以拿它来做集群的自然不在少数。IBM除了上面说的IBM Cluster1600可以做集群以外，IBM System p5 505 服务器和IBM System p5 575都是比较适合做集群的。当然，也有人用IBM System p5 520或者IBM System p5 550来做集群，这主要是根据你自己的实际需求。我们在这里简单介绍一下IBM System p5 505 服务器和IBM System p5 575。　　IBM System p5 505 服务器　　IBM System p5 505 服务器可用于19 英寸1U 机架型扩展抽屉中。它是一个1 路或2 路具有1.5 GHz 或1.65GHz POWER5 处理器的对称多处理(SMP)系统，它具备为提升系统使用率和改善性能而设计的并发功能1。最多可将40 个2 路服务器安装在一个42U 19 英寸机架上。内存可以从1GB 扩展到32GB。它还提供两个PCI-X 2.0 插槽、两个千兆位以太网I/O 端口、一个光盘驱动器媒质支架和多达600GB的磁盘存储器。为了将服务器的可用性发挥到极致，可以使用能够提供几乎不间断可用性的IBM 高可用性集群软件(HACMP)将p5-505 服务器集群化。p5-505同时支持用于提供集群工作负载和应用程序的4x InfiniBand 连接。　　p5 505服务器外观　　因为他采用的是机架式安装，所以节省了很多空间，而且都放在规矩的机架中，连接调试也比较方便，包括连接存储系统。　　IBM System p5 575服务器　　IBM System p5 575集群节点专门为那些进行极高负荷计算的应用程序而设计，它们往往需要很高的计算性能和内存带宽。通过IBM System p5 575，能够实现从16到2000个CPU的不同规模计算集群。　　p5-575 节点提供两种不同的选择。8路节点包含 8 颗 1.9 GHz 的 IBM POWER5 微处理器，每个处理器具有独享的 1.9MB 的二级和 36MB 的三级高速缓存，以充分发挥高带宽计算的能力。16路节点包含16颗1.5GHz的IBM POWER5微处理器，以提供极高的CPU密度，在此下，二级和三级高速缓存被该芯片上的两颗处理器所共享。16路节点的每处理器带宽比8路节点要小，但通过增加处理器数量，能够为HPC应用提供更高的浮点运算能力。　　IBM System p5 575集群节点提供了不可思议的计算密度，它能够实现在单一系统机架中由近200颗处理器(12 个16路p5-575 集群节点)所获得的非同一般的密度。与前代产品 IBM System p5 655 相比，p5-575 提供更高计算密度和持续的高性能。　　8路节点p5-575设计旨在满足大量不但需要快速处理，而且需要快速且持续地访问大量数据的组织的需求。 在8路节点中每处理器有着超过12GBps的峰值内存带宽，非常适用于HPC 应用，如计算机辅助工程(CAE)、海洋科学研究、气象学、流体力学计算、能源研究、数据挖掘和其他传输、访问和快速分析大量数据的带宽密集型工作。　　由于采用简洁的2U机柜，模块化的p5-575允许用户在一个42U 的系统机架中安装12 个节点。8 路和16 路的p5-575 节点可以在相同的机架中混合。这种独特的封装有4 个组成模块;I/O 子系统、DC 电源变流器/盒、处理器和内存以及冷却系统。每个组件都可以定制，以满足高性能、高密度的计算的苛刻要求。可以在机柜内增减p5-575集群节点，或在集群内进行复制，以满足不断增长的工作负载需求。每个p5-575集群节点的最低配置为1GB内存，可扩展到256 GB。2个热交换的磁盘驱动器允许将磁盘存储容量从73.4GB 扩展到600GB。如果要求更大的磁盘容量，&I/O&节点选项通过机柜后面的RIO-2集线器端口仍能支持4U 的I/O 扩展抽屉。I/O 扩展抽屉最多可容纳16 个附加的磁盘支架，从而可提供2.3TB 的15K rpm磁盘存储量。两个集群节点可以共享一个I/O 扩展抽屉，每个系统机架包含5 个I/O 扩展抽屉。　　p5-575节点在一个集群内如何联接取决于使用的集群管理软件。4 Linux环境下的集群系统管理(CSM)支持以太网(10/100/1000 Mbps)或4x InfiniBand和AIX 5L 环境下的CSM，可使用以太网4x InfiniBand 或IBM System pSeries High Permance Switch(HPS)相互连接来支持HPC工作负载。　　IBM System p5 575 集群节点旨在成为一种用于超级计算机的模块。每个节点都有可能成为针对特定需求的最佳节点:具有高内存带宽的8路节点对于快速处理大量数据十分重要，而具有极高的16 路节点可在紧凑空间中提供计算能力，这对于客户满意度至关重要。p5-575 集群节点创新、紧凑的结构，可选的虚拟化引擎(具有微分区功能)以及同时运行AIX 5L 和Linux 操作系统的能力，使其能用更少的物理空间完成更多的工作。各种为AIX 5L 和Linux 操作系统设计的提供了安装和有效管理大型集群的方法。p5-575集群能够很方便地进行伸缩，所以它可以根据组织的高性能需求进行扩展。　　IBM服务器搭建集群系统　　整个集群系统主要由高性能计算机系统和存储子系统组成，如图所示，高性能计算机系统中的计算集群服务器由IBM p5-575来担当，它们之间通过HPS来连接。而集群管理服务器由IBM P5 520服务器来承担，它通过一个网络来对计算集群进行管理。计算集群又采用光纤存储来连接系统的存储设备，保证系统的高速运行。　　整个系统的网络构建示意图就是这样，当然，要想让系统正常高速的运行还要在什么安装好的管理软件。具体的软件在IBM p5-575的产品中都有，可以请有经验的系统来安装和调试。这里也就不再系统展开讲了。怎样构建一个容器集群？_服务器应用_Linux公社-Linux系统门户网站
你好，游客
怎样构建一个容器集群？
来源：dockone.io&
作者：hessen
【编者的话】本文是Google容器技术系列博客的第二篇，中大致介绍了容器，Docker，以及Kubernetes的基本概念，这篇文章中对Kubernetes进行了相对深入的介绍，作者从Kubernetes中的一些核心概念入手，介绍了Google在构建容器集群管理系统中的一些核心要素。在上周，来自&Google 云平台全球解决方案小组&的专家MilesWard为我们做了关于容器技术的系列博客的开篇，在博客中MilesWard大体介绍了关于容器，Docker以及Kubernetes的一些基本概念。如果你还没有阅读先前的文章，建议你先进行一些了解，这样而可以补充一些相关的基础知识，也将会帮助你更好的理解本文中介绍的内容。这周，我们请来了Google的高级工程师，同时也是Kubernetes项目的核心成员。他将从更深的层面上为我们介绍Google在容器技术使用过程中的一些核心技术概念。这些概念也是Kubernetes创建基的础，理解这些概念也可以帮助我们更好地理解这一系列博客的后续文章。
怎样构建一个容器集群？
最近一段时间，容器系统相关技术迅速崛起并受到了广泛关注（比如）。容器技术已经带给我们很多令人兴奋的实践。容器的打包，迁移，并且在不同的环境中运行服务的能力，可以方便地让我们管理自己的服务，从另一个角度上，这也帮助我们提高了服务的&流动性&。但是，随着用户不断将他们的服务迁移到生产环境中，新的问题也随之出现，比如具体哪个容器运行在哪台服务器上，怎样同时运行大量数目的容器，容器之间如何方便地进行跨主机通信等等，正是这些问题的出现，促使我们构建了。Kubernetes是一个来自Google的开源的工具包，可以帮助我们解决这些新出现的问题。正像我们在上一篇文章中所讨论的那样，我们认为Kubernetes是一个&容器集群管理器&。许多技术人员习惯把这个领域的项目称之为&编排系统（orchestration systems）&，他们或许是想将集群的管理工作比作是交响乐的编曲。但我从不这样理解，交响乐（Orchestral music）编曲工作通常是提前根据旋律和配乐被细致地编排好，并且在表演之前，每个表演者的任务已经被明确指定好。而Kubernetes集群的管理过程，更像是一个升级版的爵士乐即兴表演。它是一个动态的系统，可以根据输入的信息和当前系统的运行环境实时做出反应。所以，我们不禁要问，到底是哪些因素帮助我们构建了一个容器集群？ 是否可以这样描述一个集群系统：这是一个动态的系统，在系统中可以放置多个容器，这些容器的状态以及容器之间的通信都可以被系统所监控。事实的确如此，一个容器集群正是由一个监控系统和一系列计算结点（不论是物理服务器或者是虚拟机）所组成的。在这篇文章的剩余部分，我们会着重探讨三方面的话题：容器集群由什么组成，容器集群应该怎样应用到我们的实际工作中，以及组成容器集群的各个要素又是怎样在一起发生作用的。此外，基于我们已有的经验，一个容器集群还应该包含一个管理层，我们将继续探索这个管理层是如何实现的。
为何要以集群的方式运行容器?
在Google，我们所构建的容器集群需要符合一系列常见的要求：集群总是可用的，可以被打补丁并且被升级，集群按需扩展，集群相关指标容易被测量（easily instrumented）和监控等等。根据容器本身的特性，服务可以通过快速、容易地方式进行部署，并且还可以将整个服务分成许多小的部分，以进行更加细粒度的操作。虽然容器化的操作一定程度上为我们提供了方便，但是为了满足我们提出的这些目标，我们仍然需要一个系统的解决方案来管理容器集群。在Google过去的10年间，我们发现一个容器集群管理器就可以满足席上这些需求，并且这个集群管理器还可以为我们提供许多其他的好处：
通过的模式进行开发，可以使整个开发过程变得更容易管理。集群管理器可以使我们把一个完整的服务分成许多小的部分，这些小的部分可以互相分开，分别进行管理和扩展。这可以使我们在软件开发阶段，按照服务的复杂程度来组织我们的开发团队，通过指定好清晰的接口让不同的小的开发团队来协同开发。
面对故障时候的系统自我修复。当某个服务器发生故障的时候，集群管理器可以自动地在健康的服务器上重启那些之前在发生故障的服务器上运行的任务。
水平扩展变得更容易。一个容器集群可以为水平扩展提供工具，例如如果想要添加更多的计算能力，仅需要通过修改设置（重复记数）就能实现。
。Google在将服务迁移到容器上之后，极大程度地增加资源的利用率和使用效率。
集群和服务的运维团队的角色发生了改变。开发者可以将更多的精力集中在他们所提供的服务上，而并非集中在底层的基础设施的支持上。例如，Gmail的运维和开发团队（operations and development teams）几乎不用和集群的操作运维团队直接交流就可以完成他们工作，这种关注点的分离可以使运维团队发挥更大的作用。
现在，我们明白了，当前我们所做的事情还是很有意义的，所以让我们一起探索构成一个优秀的集群管理系统到底需要哪些要素，以及如果你希望认识到以集群的方式运行容器的优势，应该对哪些方面进行特别关注。
要素一：动态容器分配
想要构建一个成功的容器集群，你需要一点点&jazz即兴表演技巧&。你需要将你的工作任务任务打包成一个容器镜像并且明确地说明你的意图，说明要如何运行容器以及将要在哪里运行容器。集群管理系统最后会决定到底你的工作任务在哪里运行，我们把这个过程称为&集群调度&。这并不是意味着工作任务会被随机地分配在计算结点上。正相反，在工作量被分配的时候，需要遵循一系列严格的限制，从计算机科学的角度来将，这会使得集群调度变成一个有趣而又困难的问题（注释1）。当需要调度的时候，调度器确定要把你的工作量放到一个有足够剩余空间（例如CPU，RAM，I/O，存储）的虚拟机或者是物理服务器上。但是，为了满足可靠性的目标，调度器可能需要把一系列的任务以跨主机的形式进行分配或者按一定的顺序来排列（racks in order），以此来减少相关运行时发生故障的可能性。或者一些特殊的任务会被分配在一些有某些特殊的硬件（比如GPU，本地的SSD等等）的机器上。调度器也会根据不断变化的运行环境作出反应。并且应该在任务运行失败的时候重新对任务进行调度，增加/缩小集群规模以提高效率。为了实现这个目的，我们鼓励用户避免将一个容器固定在一个服务器上。有些时候你可能需要指定&我想让某个容器在某个机器上运行&但这种情况应该比较少见。下一个问题是：我们进行调度操作的具体对象是什么？最简单的答案就是使用单独的容器。但是在某些时候，你希望有一系列的容器在一个主机上以合作的方式在运行。例如一个数据加载器，需要一个数据库服务一起运行或者是一个log compressor/saver进程同样需要与一个服务来搭配运行。运行这些服务的容器通常需要被放在一起，并且你需要确保它们在动态配置的过程中并没有被分离开。为了实现这个目的，我们在Kubernetes中引入个一个概念：pod。一个pod是一系列容器的集合，这些容器在一起构成一个单元在服务器（也可以被称作Kubernetes结点）上被配置和调度。为了使得每次可以配置多个pod，Kubernetes采用一种可靠的方式将许多工作打包在一个结点上。
要素二:按照集合的方式进行思考
当在一个单独的物理结点上工作时，一般的工具通常不会以批量的方式对容器进行操作。但是在容器集群上进行工作的时候，你可能希望很轻易地就能实现服务的跨结点扩展。为了实现这一目标，你需要以集合的方式进行思考，而并非像之前一样按照单例模式考虑。并且你还希望这些容器集合都可以通过很容易地方式进行配置。在Kubernets中，我们引入了两个额外的概念来管理一系列pod：label以及replication controllers。Kubernets中的每一个pod都有一套key-value键值对与其相绑定，我们把这个键值对称为labels。你可以通过构建一个基于这些labels查询，来筛选出一系列pods。Kubernets没有一个所谓的组织pod的&正确的方式&。这完全取决于用户，只要是适合用户的组织方式就是合适的。用户可以根据应用程序的层来结构来组织，也可以根据地理位置来组织，或者是部署环境等等。实际上，因为labels是非层次结构的（non-hierarchical），你可以同时以多种方式组织你的pod。举例来说:比如你有一个简单的服务，这个服务同时包含前端和后端两个层次。同时你还有不同的环境：测试环境，交付环境（staging environment）以及生产环境。你可以同时利用多个标签来标记你pod，比如用于生产环境的前端pod可以标记为：env=prod、tier=fe 同时，用于生产环境后端pod可以标记为env=prod、tier=be。同理，你也可以按照类似方法来标记你在测试和交付环境中使用的pod。接下来，当用户需要对集群进行操作或者检查的时候，就可以将操作范围限制在标记为env=prod的pod中，这样就可以同时看到在生产环境中的前端和后端的pod。或者你只想查看你的前端环境，此时只需要查找标记为tier=fe的pods，这样就可以查看跨越了测试、交付和生产三个不同的环境的前端pods。随着你添加更多的层次和不同的运行环境，你也可以按照自己的方式来设想和规划，按照自己的方式定义这个系统将，使其更好地满足你的需求。
既然我们之前已经可以对拥有类似配置的物理服务器资源池进行识别和维护。我们可以参考这个功能来对容器集群进行水平扩展（即&scaling out&）。为了使这个步骤更加容易，我们在Kubernets中维护了一个helper对象，我们称其为replication controller 。它维护着一个存有pods的资源池，还有一些属性用于描述这个资源池，包括期望进行扩展的数目 replication count ，还有一个pod 模板以及一个用于进行选择/查询的label。 实际上这个对象的原理理解起来也并不困难，下面是伪代码：
object&replication_controller&{
property&num_replicas
property&template
property&label_selector
runReplicationController(num_desired_pods,&template,&label_selector)&{
loop&forever&{
& num_pods&=&length(query(label_selector))
& if&num_pods&&&num_desired_pods&{
& & kill_pods(num_pods&-&num_desired_pods)
& }&else&if&num_pods&&&num_desired_pods&{
& & create_pods(template,&num_desired_pods&-&num_pods)
对以上代码进行分析，比如，你想要使用三个pod来运行一个php前端，你可能会使用一个合适的pod模板（指向你的php容器镜像）创建一个replication controller。其中的 num_replicas的值为3。你可能会通过一个label查询 env=prod、tier=fe 来定位到一系列pod集合，之后这个replication controller对象就会对你找到的这些pod集合进行操作。通过这种方式replication controller将会很容易理解集群进行收缩/扩展之后预期的状态，它会不断对集群进行调整直至实现最后的状态。如果你希望缩小或者扩大你的服务规模，所有你需要做的仅仅是改变预期的replicaiton count，replication controller将会处理其余的问题。通过将注意力集中在系统的预期状态，我们使这个问题变得易于处理。
要素三：集群内部服务之间的连接与通信
你已经可用上面列出的几个特性做一些很有趣的事了。任何高度并行的任务分发系统（持续集成系统，视频解码等等）在工作的时候，它们的pod之间不需要做很多的交互。然而，大多数复杂的服务更多的是小型（微型）的网络服务构成的，它们的pod之间需要进行很多的交互，按照传统的应用层级划分，每一层就像是中的一个结点。一个集群管理系统需要一个命名解析系统，这个解析系统可以与上面所描述的几个要素一同进行工作。就像DNS提供的域名到IP地址的解析一样，这个命名服务可以将服务名称解析成一个目标，以及一些额外的需求。特别地，系统的运行状态发生变化的时候，这种变化应该很快地被系统所捕获，一个&服务名称&应该能解析一系列的targets，可能还有额外的关于这些target的元信息（比如 碎片任务）。对于Kubernets API ，这个工作通过 label selector 以及watch API（注释2）模式来完成。这为服务发现提供了一个很轻量级的形式。大多数的客户端将不会因为仅仅想利用新的命名API的优势就立即重写（或者从来不会被重写）大多数项目希望有一个单独的地址以及一个端口以此可以和其他层的服务进行通信，为了弥补这个不足，Kubernetse引入了服务代理的理念。这是一个简单的网络负载均衡/代理，可以为你进行名字查询并且可以以一个单独的稳定的IP/端口的形式（通过DNS）在网络上暴露给用户。当前，这个代理做简单的轮询式负载均衡跨越所有的通过label selector识别出来的后端。按照计划，Kubernets希望允许custom proxies/ambassadors ，这样可以进行更灵活的指定域的决策（关注来了解更多的细节）。事实上，MySQL也开始意识到ambassador的作用，它可以知道如何发送写信息流到master结点，并且将信息流读入read slave结点。
现在你已经了解了以上三个关于集群管理系统的关键的要素即：动态的容器配置，容器集合的方式进行思考，集群内部服务之间的连接，是如何在一起发挥作用的。在这个文章的开始我们提出了这样一个问题：&到底如何构建一个容器集群？&希望通过我们在上面文章中提出的信息和相关细节，你已经有了答案：简而言之，一个容器集群是一个动态的系统，这个系统可以存放和管理容器，容器以pod的形式组合在一起，在结点上运行，同时还包括内部用于相互连接和通信的信道。当我们开始构建Kubernetes 的时候，我们的目标是 ：使得Google对于容器的使用经验具体化。我们最初仅仅关注容器的调度以及动态配置，然而，当我们彻底明白在构建一个真正的服务时，不同的系统是完全必要的。我们立即发现，把其他的额外的要素加入进来是完全有必要的，比如：pods，labels以及replication controller。在我看来，这些绝对是构建一个可用的容器集群管理系统的最少的需要的模块。Kubernetes仍然在在不断发展，但目前的发展状态还算不错，我们刚刚推出了v0.8的版本，你可以从下载，我们仍然在添加新的功能并且重新构建那些我们已有的功能。我们还推出了， 这个项目已经开始启动，并且一个很大的正在不断成长的社区作为合作伙伴在做贡献（就像ReaHat 、VMWare、Microsoft、IBM、CoreOS等等）还有许多用户，他们在不同的环境中来使用Kubernetes。虽然我们在这个领域有很多实践经验，但是又很多问题Google也没有答案，可能在集群使用过程中有一些特殊的要求和特别需要考虑的地方我们在目前还没有意识到，考虑到这一点，请参与到我们正在建设的一些项目中来：、f、 or 。-Posted by Joe Beda, Senior Staff Engineer and Kubernetes Cofounder
注释1：这是一个传统的，在通常情况下这是一个。注释2：&Watch API 模式&是这样一种方法: 它可以从一个服务中来分发异步事件，在通常的锁服务系统中这个很常见（zookeeper等等），这个方法最初源于
的论文。客户端本质上发送并且&挂起&一个请求，直到有变化发生。客户端的请求这通常会加上版本号信息，所以客户端会对任何变化保持最新的状态。
原文链接： （翻译：王哲 ）
本文永久更新链接地址：
相关资讯 & & &
& (05月06日)
& (01月08日)
& (12/02/:00)
& (04月27日)
& (12/25/:43)
& (11/29/:11)
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款浅谈web应用的负载均衡、集群、高可用(HA)解决方案 - aokunsang - ITeye技术网站
博客分类：
声明：以下仅为个人的一些总结和随写，如有不对之处，还请看到的网友指出，以免误导。 （详细的配置方案请google，这里只说解决方案。）
1、熟悉几个组件1.1、apache
—— 它是Apache软件基金会的一个开放源代码的跨平台的网页服务器，属于老牌的web服务器了，支持基于Ip或者域名的虚拟主机，支持代理服务器，支持安全Socket层(SSL)等等，目前互联网主要使用它做静态资源服务器，也可以做代理服务器转发请求(如：图片链等)，结合tomcat等servlet容器处理jsp。1.2、ngnix
—— 俄罗斯人开发的一个高性能的 HTTP和反向代理服务器。由于Nginx 超越 Apache 的高性能和稳定性，使得国内使用 Nginx 作为 Web 服务器的网站也越来越多，其中包括新浪博客、新浪播客、网易新闻、腾讯网、搜狐博客等门户网站频道等，在3w以上的高并发环境下，ngnix处理能力相当于apache的10倍。
参考：apache和tomcat的性能分析和对比(/nginx_php_v6/)1.3、lvs
—— Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。由毕业于国防科技大学的章文嵩博士于1998年5月创立，可以实现LINUX平台下的简单负载均衡。了解更多，访问官网：http://zh.linuxvirtualserver.org/。
1.4、HAProxy
—— HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。HAProxy特别适用于那些负载特大的web站点， 这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的web服务器不被暴露到网络上.1.5、keepalived
—— 这里说的keepalived不是apache或者tomcat等某个组件上的属性字段，它也是一个组件，可以实现web服务器的高可用(HA high availably)。它可以检测web服务器的工作状态，如果该服务器出现故障被检测到，将其剔除服务器群中，直至正常工作后，keepalive会自动检测到并加入到服务器群里面。实现主备服务器发生故障时ip瞬时无缝交接。它是LVS集群节点健康检测的一个用户空间守护进程，也是LVS的引导故障转移模块（director failover）。Keepalived守护进程可以检查LVS池的状态。如果LVS服务器池当中的某一个服务器宕机了。keepalived会通过一 个setsockopt呼叫通知内核将这个节点从LVS拓扑图中移除。
Keepalived详解：https://my.oschina.net/piorcn/blog/4046441.6、memcached
—— 它是一个高性能分布式内存对象缓存系统。当初是Danga Interactive为了LiveJournal快速发展开发的系统，用于对业务查询数据缓存，减轻数据库的负载。其守护进程(daemon)是用C写的，但是客户端支持几乎所有语言(客户端基本上有3种版本[memcxMecache])，服务端和客户端通过简单的协议通信；在memcached里面缓存的数据必须序列化。1.7、terracotta
—— 是一款由美国Terracotta公司开发的著名开源Java集群平台。它在JVM与Java应用之间实现了一个专门处理集群功能的抽象层，允许用户在不改变系统代码的情况下实现java应用的集群。支持数据的持久化、session的复制以及高可用(HA)。详细参考：/blog/19116792、关键术语2.1、负载均衡（load balance） 在互联网高速发展的时代，大数据量、高并发等是互联网网站提及最多的。如何处理高并发带来的系统性能问题，最终大家都会使用负载均衡机制。它是根据某种负载策略把请求分发到集群中的每一台服务器上，让整个服务器群来处理网站的请求。公司比较有钱的，可以购买专门负责负载均衡的硬件（如：F5）,效果肯定会很好。对于大部分公司，会选择廉价有效的方法扩展整个系统的架构，来增加服务器的吞吐量和处理能力，以及承载能力。2.2、集群（Cluster） 用N台服务器构成一个松耦合的多处理器系统(对外来说，他们就是一个服务器)，它们之间通过网络实现通信。让N台服务器之间相互协作，共同承载一个网站的请求压力。2.3、高可用（HA） 在集群服务器架构中，当主服务器故障时，备份服务器能够自动接管主服务器的工作，并及时切换过去，以实现对用户的不间断服务。ps：这里我感觉它跟故障转移(failover)是一个意思，看到的网友给个解释，谢谢？2.4、session复制/共享 在访问系统的会话过程中，用户登录系统后，不管访问系统的任何资源地址都不需要重复登录，这里面servlet容易保存了该用户的会话(session)。如果两个tomcat(A、B)提供集群服务时候，用户在A-tomcat上登录，接下来的请求web服务器根据策略分发到B-tomcat，因为B-tomcat没有保存用户的会话(session)信息，不知道其登录，会跳转到登录界面。这时候我们需要让B-tomcat也保存有A-tomcat的会话，我们可以使用tomcat的session复制实现或者通过其他手段让session共享。
3、常用web集群3.1、tomcat集群方案 apache+tomcat；ngnix+tomcat；lvs+ngnix+tomcat；大家比较熟悉的是前两种。(lvs负责集群调度，nginx负责静态文件处理，tomcat负责动态文件处理[最优选择])。 以apache+tomcat集群为例，简单说一下：
1、他们之间的通信有三种方式：ajp_proxy、mod_jk链接器、http_proxy。具体参考：/developerworks/cn/opensource/os-lo-apache-tomcat/
2、apache的分发策略有4种。权重(默认)、流量(bytraffic)、请求次数(byRequests)、繁忙程度(byBusyness根据活跃请求数的多少)
3、apache支持stickysession(粘性session)，即为：访问用户访问了A-tomcat，那么他的所有请求都会转发到A-tomcat，而不会到B-tomcat。[这样的负载均衡效果不好，适用于小型网站，下面说非粘性session]
4、它们之间的架构如图1：
问题1：只有一个web服务器，明显的单点故障。如果该apache出现问题，整个网站就会瘫痪。
3.2、session复制
如果不采用stickysession(粘性session)，那么我们可以采用tomcat的session复制使所有节点tomcat的会话相同，tomcat使用组播技术，只要集群中一个tomcat节点的session发生改变，会广播通知所有tomcat节点发生改变。问题2：据网友测试，当tomcat节点数达到4个以上时候，集群性能呈线性下滑；另外当用户访问量大到一定程度，会话内容随之增多，tomcat节点相互之间通信产生大量的网络消耗，产生网络阻塞，整个集群的吞吐量不能再上升。
4、高可用(HA)和session共享(解决上面提到的两个问题)
4.1、使用lvs+keepalive实现集群高可用，达到更健壮的LB 我们可以做前端使用lvs来做负载均衡，根据lvs的8种调度算法(可设置)，分发请求到对应的web服务器集群上。lvs做双机热备，通过keepalived模块能够达到故障自动转移到备份服务器，不间断提供服务，结构如图2：
说明：据查询了解，一般在WEB端使用的负载均衡比较多的是HAProxy+keepalived+nginx；数据库mysql集群使用Lvs+keepalived+mysql实现。因为HAProxy和nginx一样是工作在网络7层之上，并且前者弥补了nginx的一些缺点如session的保持，cookie的引导等，且它本身是个负责均衡软件，处理负载均衡上面必然优于nginx；lvs比较笨重，对于比较庞大的网络应用实施比较复杂，虽然它运行在网络4层之上，仅做分发没有流量产生，但是它不能做正则处理也不能也不能做动静分离，所以一般用lvs+keepalived或heatbeat做数据库层的负载均衡。
4.2、使用terracotta或者memcached使session共享
4.2.1、terracotta是jvm级别的session共享
它基本原理是对于集群间共享的数据，当在一个节点发生变化的时候，Terracotta只把变化的部分发送给Terracotta服务器，然后由服务器把它转发给真正需要这个数据的节点，并且共享的数据对象不需要序列化。
4.2.2、通过memcached实现内存级session共享
通过memcached-session-manager（msm）插件，通过tomcat上一定的配置，即可实现把session存储到memcached服务器上。注意：tomcat支持tomcat6+，并且memcached可以支持分布式内存，msm同时支持黏性session（sticky sessions）或者非黏性session（non-sticky sessions）两种模式，在memcached内存中共享的对象需要序列化。结构如图3：
通过一定的配置，可以实现故障转移(只支持对非粘性session)。如：
&Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="n1::1211"
failoverNodes="n1"
requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
&/Context&
说明：failoverNodes：故障转移节点，对非粘性session不可用。属性failoverNodes="n1"的作用是告诉msm最好是把session保存在memcached "n2"节点上，只有在n2节点不可用的情况下才把session保存在n1节点。这样即使host2上的tomcat宕机，仍然可以通过host1上的tomcat访问存放在memcached "n1" 节点中的session。 4.2.3、其他方案通过cookie保存用户信息(一般是登录信息)，每一个请求到达web应用的时候，web应用从cookie中取出数据进行处理（这里尽量对cookie做加密处理）；另外一种是把用户信息的关键属性保存到数据库，这样就不需要session了。请求过来从数据库查询关键属性数据，做相应处理。缺点：加大了数据库的负载，使数据库成为集群的瓶颈。
下篇再讨论，。
浏览 73075
浏览: 540252 次
来自: 北京
不错，谢谢分享！推荐个参考视频内容：http://www.ro ...
完全正确，补充一下&beans:bean id=&quo ...
longToip直接用ipToLong反过来就好了 publi ...
[size=x-small]jatoolsPrinter还有破 ...