06、尚硅谷-Linux云计算-集群-LVS工作模式-1

大家好，欢迎大家继续收看上硅谷云计算视频，我是弯腰老师。那我们接下来继续往后看iOS的工作方式。那首先呢，我们先处理的是iOS工作层级的这么一部分的划分，那对于我们整个操作系统来说，我们可以分为我们的用户空间和内核空间。两个部分。内核空间里面呢，更贴近我们的硬件，用户空间更贴近用户。那这个还是需要我们去了解一下的，那比如我们的内核就是工作啊，比如我们的一些呃驱动就是工作在我们的内核空间的，那比如我们的操作系统那个空间，对吧？那比如我们的QQ啊，微信啊，都工作在用户空间的，这里是需要我们去了解一下的。那自然而然的iOS是从这里去划分的话，可以分为两个部分，一个是我们的IPS，一个是我们的IPSIDM模块。IPS呢？大家可以理解为它才是真正的iOS的核心组件。

它已经被集成到我们的Linux内核之中，对吧？所以我们是不需要去安装的，你只需要去考虑到底有没有被引导起来即可。那到时候我们也会输入对应的命令去判断是否已经加载。那对于我们整个iOS的安装来说，其实就分为了一部分对吧，就是安装我们的IPVIDM。那它是一个命令行管理工具，因为我们没办法直接对我们的内核里面的配置文件进行修改。所以我们需要借助一个。命令行管理工具去触发类似于我们之前给大家修改的什么ETC下的C ctrl.com复里面的IP forward，对吧？开启路由转发也是同样的原理。好。那我们大致可以分为三个部分，三种模式，那第一种叫nut，第二种叫创，第三种叫DR模式。这里需要注意一下，我们第四种模式正在开发，这是从getup上我们去看到的结果，也就是提交了一个新的支点。

那但是到今天为止呢，它依然没有进行我们所谓的公测，所以在不久的将来，或者是在呃，过个几年，可能第四种模式会诞生出来，但现在来说，我们还是三种模式需要大家注意。那我们一个一个去讲，我们先看第一种模式叫nat模式。这里呢，是我们的用户，这是我们的iOS负载路器，这是我们的真实服务器。你会发现。负载调度器位于我们的正式服务器与客户端之间。并且它这里连接了一个叫公网。也就意味着，对于iOS来说，它应该配两块网卡，一个是公网IP，一个是内网IP。内网IP比较容易去理解，对吧，他需要跟后端的真实服务器建立所谓的数据传输，他们必须要能相互通讯，所以这个一定是我们内网地址没问题。

那公网地址在这里呢？它起到一个跟用户去连接的作用，俩部分需要注意，这个拓扑环境还是比较比较有特点的。好，那我们看第二种模式，也就是我们的创模式。那在这里呢？这是我们的iOS载路器，这是我们的客户以及我们的真实服务器，你会发现他们之间通过相连的都是公网，都是通过公网相连，并不像刚才这里，对吧？这里是不是通过我们的丝网与我们的负载器相连，这里全是公网。比较特殊，也就意味着当我的服务器散落在全国各个不同的角落的时候，我可以通过我们的创模式把它们给组合起来，构建一个完整的集群。当然这种模式比较特殊，对吧，所以一般来说用途不是那么广泛，那这里需要注意一下，那我们再看最后一种DR模式，那这里呢是我们的路由器，这是我们的交换，那这是我们的真实服务器，我们一般把它叫RS，那这是我们的负载容器，我们把它叫D，这是我们的客户端C。

那也就意味着在这种模式下，我们可以看到负载调器，以我们的真实服务器，它们之间都是处于同一个广播域之中，需要注意跟前面两种是不是都不一样了。那如果外网用户想访问电脑的话，需要借助一个真正的物理的路由器进行跳转，大家能发现对吧？好，那这种模式呢，是我们整个环境中它的负载量最高的一种方式。也是我们企业比较容易去选择的一种方式，所以它非常重要，大家后面的课程一定要好好的去把它给了解掌握。好，那这个呢，就是我们的三个不同集群的分类，那接着我们继续去往后看看我们的第一种集群，也就是我们的nat模式。

首先呢，这里有一张示意图，IOS的nat模式的示意图，对吧，这里有公网地址，客户端的公网地址10.11.12.13，那我们的负载周期呢，有两块网卡。DY网卡它对应的地址是11121314，第二块它的地址对应的是192168.1.10。那以及后面三个不同的真实服务器，那这里我们假设它是一个阿帕奇服务器，对应的默认端口，也就是八零，那它的地址是192.16 8.1.11，幺二以及幺三，你会发现他们是处于同一滚播域之中的，对吧？我这里没有加路由器啊，没有加交换机，需要大家注意一下。好，那当我用户想去访问我的整个外部服务器的时候，可能会发送这么一个数据包，原地是10.11.12.13，当然这里的端口我没有写A1是这一个水滴端口，对吧？目标地址是12121314，冒号八零，也就是访问的是我们的负载调度器的八零端口。

那数据包经过我们的供应商的交换以及路由的传输，自然而然会到达我们的负载流动器，这是完全没有问题的。那负载电路器为了能将这个数据包传递给我们后端的真实服务器，所以要经过自己的算法去选择，将我们的目标目标地址，也就是目的地址改为后面的正式服务器的其中一个地址。怎么去确定他们三个其中哪一个呢是根据算法去决定的，那后面我们会给大家去提供一下算法的讲解。好，那就意味着数据包被我选择完了以后，比如选择的是幺幺这台服务器，它会把目标地址啊的地址改为192.168.1.1的八零端口。

那这里使用的其实是一个我们比较常见的技术啊，也就是我们的低钠的技术，叫目标地址转换，讲白了就是目的地址进行更改，就这么一个东西。好，那这样的话呢，我们就能够把数据报文，当然当然前提是这里要开启所谓的路由转发，对吧，那我们就能把报文传递给R1服务器，R1服务器肯定是能够接收到的，因为这个数据报文的格式完完全没有任何问题，对吧？那它处理完成以后呢，就会去返回一个数据报文。数据报文呢？如果我们的RS真实服务器把网关指向了我们的负载周器，那这个数据报文肯定是能够被传回我们的负载周器的。负载器接收以后，如果这里开启了路由转发，对吧，这个非常重要，我一直在强调对吧，那开启路由转发的话，它会把它通过我们的公网地址传出去，传给我们的客户。

这个流程肯定都是没有完完全没有任何问题的，因为我们的数据报完，虽然它原地址是一个私有地址，但是我在公网中寻找路径的话，我看的是一个物理地址，对吧？这是完全没有问题的一个格式，也就意味着我们需要考虑的第一个问题，数据包能够到达客户端吗？肯定是没有任何问题的，绝对能够到达。那第二个问题就是客户与之能够建立相关的联系吗？连接吗？肯定不行。这个我们之前也说过，对吧，原因是什么。这里的语言是1213，目标是11314，结果这里的语言变成了1.1。他跟我的不匹配，我应该是11.12.13.14，你怎么给了我这一个东西。我去订购了一件衣服，结果张三过去以后，他把我订购的衣服给张三了，你觉得这样合适吗？

肯定不行，对吧。所以呢。我们要在这里进行转换，所以我们往后退。推到这里，那怎样才行呢？只有当发出的数据报文，它的格式是言是11121314，目标是10111213的时候，这个数据报文才能够被到达我们的客户端。那这个怎样去转换呢。这里转换的是目的对吧，这里转换的是原地址，所以这里走了一个是S纳的转换，S纳转换也比较容易理解，对吧，叫原地址转换，源地址转换。转换完成以后呢，再发给我们的客户端。那这样的话，自然而然是能够进行连接的。好，那这个呢，就是我们的娜塔模式的整个流程。那我们接着我继续往后看。

总结。第一个集训链处于同一个网络环境中，需要注意一下哈。我们看一下这张图，我们再回过来看这张图。首先R1 R2、S三都必须将我们的网关指向到我们的负载调度器，原因是我需要在负载调度器进行对应的d net以及s net转换。这个相信大家都能理解对吧。你不经过我的话，我怎么给你转换呢。那如果有一天我添加了一个正式服务器。它处于我们的。我们整个环境的外部。我数据报文的发送以及接收都不止我们的负载容器。那这怎么能够进行连接呢？很好理解。好。第二个真实服务器必须将网关指向负载登陆器。这个其实刚才我已经给大家强调过了，对吧。他如果不把网关指向负载器，而是指向我们生态环境中还有一个真实路由器，它可能与客户也能直接相连，那我数据包从这里发送过去，出去的时候，其实这是不是发送就是这个数据报文了，这个数据报文咱们刚才是不是已经验证过了？

跟客户端是不是没办法进行直接的连接啊。所以还是那句话，所有的数据报文必须要经过我们的负载流器，它才能进行所谓的d net以及S的转换的处理。能理解我的意思吧，这个还是非常重要的。第三个。RIP通常是私有IP，仅用于各个节点通讯，这个应该都没有问题了，对吧？那如果你配上公网IP的话，反而会不行，原因是如果你配上公网IP以后，它都有各自的网关，并不会再把数据报文发送至我们的分路器，跟刚才我们讲的其实都有一点重复了，对吧？好，那下一个负载漏器必须位于我们的R与DS之间，也就是我们的。

呃，客户以及我们的真实服务器之间充当网关，好，下一个支持端口映射，这个我需要给大家强调一下。什么叫支持端口映射啊？假设现在用户发送的数据报文是八零端口，结果我R1也就真实服务器，它的端口可能是8080，它可能是8081，他可能是808，那这个集群我们还能建立吗？在那的模式中，这种方式是完全没有问题的，原因是什么呢？因为DNA的在转换的时候，其实我们不仅可以转换它的目标地址，连目标端口也可以转换。只要你在iOS里把对应的真实服务器的IP与端口的对应关系写清楚即可。也就意味着在这里转换的时候，其实只是加了一步，把它转换成8080。也就是目标地址和目标端口都会发生变化，回来的时候也一样。端口映射非常重要的一个概念。

下一个负载器必须是零六操作系统，那有些同学可能会遗忘了，哎，为什么我不用Windows的不行吗？咱们也说了对吧，IOS iOS叫Linux v server叫Linux虚拟服务技术，它不叫Windows虚拟服务技术，很好理解吧，大家这样去记对吧，那对于正式服务器来说，我们就可以随意去选择了，这个并没有什么所谓的固定的要求。随便你不管是恩尼也好啊，阿帕奇也好啊，还是所谓的什么Tom看也好啊，随便你只要他能够提供我们真正的外部服务的能力，对吧，端口也随便，八零啊，8081啊都可以。好，那下一个进出数据包文都要经过负载调度器的机器压力较大，这也是最后的一个非常大的特点。那我们可以看到这张图，我给大家换下数据包的流向对吧？数据包文进来到我们的真实服务器出去，那假设这是第一台的对吧？第一次连接结果第二次连接可能分到这里了，进来到第二台出去。

那如果同时有两个用户一起发送连接，是不是就成为这种情况了？也就意味着不管流量的入还是流量出，都是有负载容器去处理的。当然我这里说的处理是LS的处理，包括数据报文传输的处理都跟它有关。需要大家注意一下对吧，好，那所以它的压力还是比较大的，那这个呢，就是我们的iOS的nat模式给大家做了一个总结。我希望大家在听完总结以后，回到这张图，回到这张图。把它暂停了，在暂停到这里。自己在自己脑海中把这个整个流程给过一遍。这个原理还是非常重要的，有利于我们后期的构建。