LVS/Tun 成功案例

2024-04-30 15:32
文章标签 案例 成功 lvs tun

本文主要是介绍LVS/Tun 成功案例,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

前阵子在LVS中文站找资料,发现很多人反应LVS的TUN模式搭建不成功,很多人反应网上的资料很混杂,但是照着做都没做成功,稍微有点郁闷。这里分享一个成功的案例,希望能帮到有需要的朋友。

     本文将介绍IPIP协议,LVS/TUN 搭建,以及在TUN模式下通过iptables实现端口转发等内容。

     之前看了很多网上的资料都说企业中用的最多的是DR模式,因为DR相比于TUN不用额外的开销之类的,但是DR是不是真的就那么完美呢?其实不是的,当服务器的规模一大,问题就出来了,我们知道DR模式下的Director和RealServer必须是同一网段的,那么当服务器足够多的时候,就会出现问题。假设机房给了你一整个C网段的IP地址,而你的真实服务器有成千上万台,这种情况下,DR的局限性就出来了,而TUN模式是可以跨网段,跨地域通信的, 不存在这方面的顾虑。


一、IP Tunnel 原理

   IP Tunnel,又叫IPIP,是一种将一个IP封装到另外一个IP中进行传输的技术。通常需要两个部件:封装部件和解包部件,两端各需要一个IP地址,且两个IP地址能够直接通信。它的工作原理是:在封装部件将一个IP封装到封装部件地址(隧道端的IP)上,并以解包部件地址(IP隧道另一端的地址)为目标地址进行转发。解包部件接受到封装好的数据包后,先进行解包,对数据报进行还原,再以数据报原目标地址为目标地址转发数据报,从而实现通信。用一句话总结就是:将两个无法直接通信的IP,封装在两个能够直接通信的IP,借助IP Tunnel 进行传输、通信。此时,隧道两端的IP地址便是一个载体,提供传输的功能。完整的封包结构如下所示:

wKioL1M4HgWxAyBfAABy6AIJ85g316.jpg

   说了这么多,是不是对概念还不太清晰?没关系,接着看下面的实验,做完实验再回头看原理,或许会有另外的收获。


二、IP Tunnel实验

IP 分配

node1     10.1.1.101/24           192.168.1.1/24

node2      10.1.1.103/24            192.168.2.1/24


在不做任何配置的情况下,10.1.1.101/24能够直接与10.1.1.103/24 通信,而192.168.1.1/24 不能直接与192.168.2.1/24 进行通信。

wKiom1M4Hrbh6uCVAADuhm88d9A108.jpg



wKioL1M4Ho7RGhLPAABumzDrim0694.jpg


node1 配置

root@node1:~# modprobe ipip

root@node1:~# modprobe ip_gre

root@node1:~# ip tunnel add tun0 mode gre remote 10.1.1.103 local 10.1.1.101 ttl 64

root@node1:~# ip link set tun0 up

root@node1:~# ip addr add 192.168.1.1 peer 192.168.2.1 dev tun0

root@node1:~# ip route add 192.168.2.0/24 dev tun0


node2 配置

root@node2:~# modprobe ipip

root@node2:~# modprobe ip_gre

root@node2:~# ip tunnel add tun0 mode gre remote 10.1.1.101 local 10.1.1.103 ttl 64

root@node2:~# ip link set tun0 up

root@node2:~# ip addr add 192.168.2.1 peer 192.168.1.1 dev tun0

root@node2:~# ip route add 192.168.1.0/24 dev tun0


再次在node1 上ping node2可以发现192.168.1.1/24和 192.168.2.1/24 两个网段能够通信。

wKioL1M4Hs_gh87aAAHiH8VaFX4060.jpg

http://blog.sina.com.cn/s/blog_9025a42d010193gt.html

VS/TUN原理:
    LB收到用户请求包后,根据IP隧道协议封装该包,然后传给某个选定的RS;RS解出请求信息,直接将应答内容传给用户。
    此时要求RS和LB都要支持IP隧道协议。
    LB与RS可以不在同一个网络.

    数据包处理过程:
    step1:LB收到数据包,如下:
            +------------------+-----------+---------------------------+
            |Src IP(源IP,即CIP)| 目标IP,VIP|           Data            |
            +------------------+-----------+---------------------------+
          此时LB采用IP tunneling封装协议对上面的IP数据包封装在另外一个IP包中.如下:
            +----------------------+------------------+-----------------------------------------------------------------------+
                                                                           New Data                                  |
                                                    +------------------+-----------+---------------------------+     |
            |Src IP(源IP,即LB的RIP)| 目标IP,即RS的RIP      |Src IP(源IP,即CIP)| 目标IP,VIP|           Data               |
                                                    +------------------+-----------+---------------------------+     |
                                                                                                                     |
            +----------------------+------------------+-----------------------------------------------------------------------+
           然后LB将该数据包路由给RS.
    step2:RS收到LB发来的数据包时,根据IP tunneling封装协议对该数据包进行解包.
          将LB收到的原始数据解出来,如下:
            +------------------+-----------+---------------------------+
            |Src IP(源IP,即VIP)| 目标IP,CIP          Data            |
            +------------------+-----------+---------------------------+
          解包后,RS发现目标地址是自己(即VIP在RS上面有配置,即Tunl接口),就会处理该数据包,并将处理结果直接返回给用户端CIP,不再经过LB.


通讯模型
+-------+
      |CIP<---返回---------------------------------------------+
                                                            |
|Client |                                                     |
      |CIP----请求----->+                             |
                                                         |
+-------+                                                  |
                          |请求包                            |返回包
                                                              |
                                                              |
                         VIP                                    VIP(Tunel设备IP)
                  +----------------+         封装包        +-------------+
                    Director    |DIP--------->-------RIP|  RealServer |
                  +----------------+       (不同Vlan)      +-------------+


请求包格式:
                  源IP                 目标IP
            +----------------------+------------------+---------------------------+
            |Src IP(CIP)           | LB的VIP                   Data            |
            +----------------------+------------------+---------------------------+
封装包格式:
                  源IP                 目标IP
            +----------------------+------------------+-----------------------------------------------------------------------+
                                                                New Data (即完整的请求包)                            |
                 Src IP                             +------------------+-----------+---------------------------+     |
            |LB的DIP,即VIP所在网卡 | 目标IP,即RS的RIP |      |Src IP(源IP,即CIP)| 目标IP,VIP|           Data               |
            |的主IP,即RIP                              +------------------+-----------+---------------------------+     |
                                                            将请求包封装在另外一个IP报文中                           |
            +----------------------+------------------+-----------------------------------------------------------------------+
返回包格式:
                  源IP                 目标IP
            +----------------------+------------------+---------------------------+
            |Src IP(即RS的VIP)     | 目标IP,即CIP              Data     |
            +----------------------+------------------+---------------------------+

 

这篇关于LVS/Tun 成功案例的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/949242

相关文章

SpringBoot实现动态插拔的AOP的完整案例

《SpringBoot实现动态插拔的AOP的完整案例》在现代软件开发中,面向切面编程(AOP)是一种非常重要的技术,能够有效实现日志记录、安全控制、性能监控等横切关注点的分离,在传统的AOP实现中,切... 目录引言一、AOP 概述1.1 什么是 AOP1.2 AOP 的典型应用场景1.3 为什么需要动态插

mysql外键创建不成功/失效如何处理

《mysql外键创建不成功/失效如何处理》文章介绍了在MySQL5.5.40版本中,创建带有外键约束的`stu`和`grade`表时遇到的问题,发现`grade`表的`id`字段没有随着`studen... 当前mysql版本:SELECT VERSION();结果为:5.5.40。在复习mysql外键约

Golang操作DuckDB实战案例分享

《Golang操作DuckDB实战案例分享》DuckDB是一个嵌入式SQL数据库引擎,它与众所周知的SQLite非常相似,但它是为olap风格的工作负载设计的,DuckDB支持各种数据类型和SQL特性... 目录DuckDB的主要优点环境准备初始化表和数据查询单行或多行错误处理和事务完整代码最后总结Duck

MySQL不使用子查询的原因及优化案例

《MySQL不使用子查询的原因及优化案例》对于mysql,不推荐使用子查询,效率太差,执行子查询时,MYSQL需要创建临时表,查询完毕后再删除这些临时表,所以,子查询的速度会受到一定的影响,本文给大家... 目录不推荐使用子查询和JOIN的原因解决方案优化案例案例1:查询所有有库存的商品信息案例2:使用EX

Hadoop企业开发案例调优场景

需求 (1)需求:从1G数据中,统计每个单词出现次数。服务器3台,每台配置4G内存,4核CPU,4线程。 (2)需求分析: 1G / 128m = 8个MapTask;1个ReduceTask;1个mrAppMaster 平均每个节点运行10个 / 3台 ≈ 3个任务(4    3    3) HDFS参数调优 (1)修改:hadoop-env.sh export HDFS_NAMENOD

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题,本文将一起从代码层去分析为什么没有建立索引? 开源ERP项目地址:https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置

深入探索协同过滤:从原理到推荐模块案例

文章目录 前言一、协同过滤1. 基于用户的协同过滤(UserCF)2. 基于物品的协同过滤(ItemCF)3. 相似度计算方法 二、相似度计算方法1. 欧氏距离2. 皮尔逊相关系数3. 杰卡德相似系数4. 余弦相似度 三、推荐模块案例1.基于文章的协同过滤推荐功能2.基于用户的协同过滤推荐功能 前言     在信息过载的时代,推荐系统成为连接用户与内容的桥梁。本文聚焦于

【区块链 + 人才服务】可信教育区块链治理系统 | FISCO BCOS应用案例

伴随着区块链技术的不断完善,其在教育信息化中的应用也在持续发展。利用区块链数据共识、不可篡改的特性, 将与教育相关的数据要素在区块链上进行存证确权,在确保数据可信的前提下,促进教育的公平、透明、开放,为教育教学质量提升赋能,实现教育数据的安全共享、高等教育体系的智慧治理。 可信教育区块链治理系统的顶层治理架构由教育部、高校、企业、学生等多方角色共同参与建设、维护,支撑教育资源共享、教学质量评估、

客户案例:安全海外中继助力知名家电企业化解海外通邮困境

1、客户背景 广东格兰仕集团有限公司(以下简称“格兰仕”),成立于1978年,是中国家电行业的领军企业之一。作为全球最大的微波炉生产基地,格兰仕拥有多项国际领先的家电制造技术,连续多年位列中国家电出口前列。格兰仕不仅注重业务的全球拓展,更重视业务流程的高效与顺畅,以确保在国际舞台上的竞争力。 2、需求痛点 随着格兰仕全球化战略的深入实施,其海外业务快速增长,电子邮件成为了关键的沟通工具。

【区块链 + 人才服务】区块链集成开发平台 | FISCO BCOS应用案例

随着区块链技术的快速发展,越来越多的企业开始将其应用于实际业务中。然而,区块链技术的专业性使得其集成开发成为一项挑战。针对此,广东中创智慧科技有限公司基于国产开源联盟链 FISCO BCOS 推出了区块链集成开发平台。该平台基于区块链技术,提供一套全面的区块链开发工具和开发环境,支持开发者快速开发和部署区块链应用。此外,该平台还可以提供一套全面的区块链开发教程和文档,帮助开发者快速上手区块链开发。