首先,
虚拟机,,虚拟机网卡,有几种连接方式,就是说,物理网卡,并非虚拟机的网卡
你要测试的,是虚拟机效果(要停就停用,虚拟机网卡)
你要搞清楚,是桥接,还是,NAT模式,
明白后,你就清楚,虚拟机是在什么状态,并不是禁用单网卡(物理卡),像思杰,有多检测机制的,并不单一就自动跳转,
而你禁用2,其实就是断开所有物理机,迁移就中断。(估计你虚拟机,迁移前没删除快照)
而关机是正常(虚拟机正常中断),心跳自动切换了,是符合设定。
建议学习一下思杰,
迁移与热备,是另外一个方案:
什么时候会用到整体数据迁移方案呢?
情况1、当企业从物理机房托管转向公有云平台时,将会涉及到业务数据的搬迁服务,如何能帮企业解决平滑的过渡,保护数据迁移的安全性、海量数据的完整性呢?
首先物理机房的服务器运行环境与云平台的云服务器的物理环境发生了变化,靠传统的搭建环境、再复印粘贴的方式,首先时间上不能保证迁移的时效性,而且 *** 作步骤繁琐,我们要考虑的因素很多,另外因为环境不同很容易出现这样那些的问题,导致业务不能正常启用。
数据迁移:IDC张祚涛
情况2:当企业面临机房搬迁时,会涉及到跨地域进行设备搬迁,这时候可能很多企业可能并没有意识到风险,因为迁移的过程中如果遇到设备老旧或物理颠簸可能就会遇到数据丢失,机器不能正常开机导致业务中断,影响企业生产线的正常运营!
同时,很多企业本地的NAS服务器或者SAN服务器,都装载了企业很多重要的本地核心数据,当遇到企业搬家,很可能涉及到存储设备的搬迁,机器有可能也是用了很多年,存储了近几十TB甚至几百TB、EB级的海量数据,那么,这时候如果遇到设备故障,那企业将面临因为搬迁造成的设备核心数据丢失,那损失将是不可预估的。所以这时候企业最稳妥的方式是搬之做先做一个完整的实时的数据备份,这样当面临意外宕机时,才能将完整的实时的数据备份快速的恢复到原机、或异机进行恢复。
情况3:当企业从A云向B云进行业务转移的时候 ,也会涉及到整体数据迁移方案。总不能下载到本地再从本地搬到另一个云平台上吧,这时候就需要借助一个工具来完成企业的整体数据迁移。
情况4:当公安机关打击违法犯罪时,需要从涉案企业的设备上提取作案证据时,因为有时候可能就是一个大型案件,涉案企业的设备较多,涉及到跨省出警,这时候警察叔叔又不可能把几十台设备都搬到外地去,如果通过移动硬盘进行拷贝的话,首先时间上采用传统的备份可能需要几天的时间,但因为客户服务器的物理环境,比如做了read5那有可能拷过去的数据不可用,那如何能最快的时间提取到涉案企业服务器里的完整的数据,而且保证数据的可用呢。
这时候就需要一种更先进的手段,协助警察同志对数据中心的涉案服务器进行完整的数据迁移提供高可用方案,不仅能为公安机关案件调查节约时间争取早日破案,更能为打击犯罪提供技术支持。
情况5:当企业遇到其它混合云环境下的整体数据迁移,从本地到云端(D2C或D2D2C),云端到云端(C2C)的灾备服务架构的备份与恢复;数据灾备到用户自建的数据中心进行异地灾备,实现跨设备、跨地域、跨云和物理隔离的整体数据迁移方案。
以上几种情况正是「ucache灾备云」能帮企业提供整体数据迁移方案的实例。
「ucache灾备云」可以作为一个服务,为企业提供完整数据备份、数据迁移、灾难恢复服务;
「ucache灾备云」可以看作一个平台,具备云的特性,即开即用,d性扩容;
「ucache灾备云」可以理解为一项技术,可以满足混合云环境下的海量数据、即时备份。
「ucache灾备云」可以当作一个工具,帮企业实现跨设备、跨云、跨地域的数据迁移。
「ucache灾备云」是以在线云服务的方式提供用户Web控制台,备份本地数据至云端和云端数据恢复至本地的数据保护服务,为用户的数据搬迁提供技术保障。
特点如下:
(1)云灾备具备实时性
当面对不同企业用户无论是几百GB或是面临TB-EB 级海量数据的存储及备份时,在业务连续性上都能做到不间断的进行数据备份。
(2)云灾备具备可靠性。
备份数据可靠性=备份数据恢复验证频度×60%+恢复演练环境具备度×40%=(一类系统业务备份数据恢复验证频度×40%+二类系统业务备份数据恢复验证频度×35%+三类系统业务备份数据恢复验证频度×25%)×60%+恢复演练环境具备度×40%。
云灾备平台可以进行灾难恢复演练,通过即时的数据有效性验证,验证备份数据的完整性、可靠性,能够为企业的云灾备提供可靠保障。
(3)云灾备具备安全性。
云灾备平台应当为用户的数据安全提供全过程的数据保护,从传输层、存储层、数据库层全程加密的方式,保障数据全程处于加密状态。
(4)云灾备具备全能性。
云灾备的应用场景可以满足用户:完成数据从本地到云端(D2C或D2D2C),云端到云端(C2C)的灾备服务架构的备份与恢复;数据灾备到用户自建的数据中心进行异地灾备,实现跨设备、跨地域、跨云和物理隔离的灾备数据中心服务。
(5)数据容灾备份具备灵活性。
云灾备应当基于云服务的订阅收费模式,采取按需订阅,d性扩容,减少初期的投资浪费;无需用户初期硬件资产投入以及运维人员投入;满足用户即开即用、 *** 作简单、以云管理的方式交付用户使用。
当灾难发生时,生产数据遭到破坏,可以在线上立刻启用「ucache灾备云」的备份数据,以灾备即服务的方式对数据进行快速恢复,或将备份数据搬迁到新的服务器或应用平台,并且保证系统稳定运行,一键备份,秒级恢复的数据容灾备份解决方案,相信是每个企业进行整体数据备份、迁移、恢复的不二之选!
来源于: 为什么集群需要overlay网络Overlay 网络建立在另一个计算机网络之上的虚拟网络(不能独立出现),Overlay 底层依赖的网络是 Underlay 网络。
Underlay 网络是专门用来承载用户 IP 流量的基础架构层,它与 Overlay 网络之间的关系有点类似物理机和虚拟机。Underlay 网络和物理机都是真正存在的实体,它们分别对应着真实存在的网络设备和计算设备,而 Overlay 网络和虚拟机都是依托在下层实体使用软件虚拟出来的层级。
在实践中我们一般使用虚拟局域网扩展技术VxLAN(Virtual Extensible LAN)组建 Overlay 网络。VxLAN 使用虚拟隧道端点VTEP (Virtual Tunnel End Point)设备对服务器发出和收到的数据包进行二次封装和解封。
两台物理机可以通过三层的 IP 网络互相访问:上图中两个 VTEP 会相互连接并获得网络中的 MAC 地址、IP 地址等信息,例如,服务器 1 中的 VTEP 需要知道想要访问绿色网络中的 10002 虚拟机需要先访问 IP 地址为 20479197200 的服务器 2。这些配置可以被网络管理员手动配置、自动学习、也可以通过上层的管理器设置。
当绿色的 10001 虚拟机想要向绿色的 10002 发送数据时,经过以下步骤:
1) 绿色的 10001 会将 IP 数据包发送给 VTEP;
2) 服务器 1 的 VTEP 收到 10001 发送的数据包后;
a) 从收到的 IP 数据包中获取目的虚拟机的 MAC 地址;
b) 在本地的转发表中查找该 MAC 地址所在服务器的 IP 地址,即 20479197200;
c) 将绿色虚拟机所在的虚拟网络标识符(VxLAN Network Identifier、VNI)以及原始的 IP 数据包作为负载,构建新的 UDP 数据包;
d) 将新的 UDP 数据包发送到网络中;
3) 服务器 2 的 VTEP 收到 UDP 数据包后;
a) 去掉 UDP 数据包中的协议头;
b) 查看数据包中 VNI;
c) 将 IP 数据包转发给目标的绿色服务器 10002;
4) 绿色的 10002 会收到绿色服务器 10001 发送的数据包。
笔记:以上步骤中的VNI(VxLAN Network Identifier)是干嘛的 2) c) 和3) b) 中vni做了什么处理整个过程中VTEP起到网关的重要性。
在数据包的传输过程中,通信的双方都不知道底层网络做的这些转换,它们认为两者可以通过二层的网络互相访问, 但是实际上经过了三层 IP 网络的中转,通过 VTEP 之间建立的隧道实现了连通。 除了 VxLAN 之外,Overlay 网络还有很多实现方案,不过也都大同小异。Overlay 网络虽然能够利用底层网络在多数据中心之间组成二层网络,但是它的封包和拆包过程也会带来额外开销,所以 为什么我们的集群需要 Overlay 网络呢,本文将介绍 Overlay 网络解决的三个问题 :
1) 云计算中集群内的、跨集群的或者数据中心间的 虚拟机和实例的迁移 比较常见;
2) 单个集群中的虚拟机规模可能非常大, 大量的 MAC 地址和 ARP 请求会为网络设备带来巨大的压力 ;
3) 传统的 网络隔离技术 VLAN 只能建立 4096 个虚拟网络 ,公有云以及大规模的虚拟化集群需要更多的虚拟网络才能满足网络隔离的需求;
Kuberentes 目前已经是容器编排领域的事实标准了,虽然很多传统行业仍然在使用物理机部署服务,但是越来越多的计算任务在未来都会跑在虚拟机上。 虚拟机迁移是将虚拟机从一个物理硬件设备移到另一个设备的过程,因为日常的更新维护,集群中的大规模虚拟机迁移是比较常见的事情 ,上千台物理机组成的大集群使得集群内的资源调度变得更加容易,我们可以 通过虚拟机迁移来提高资源的利用率、容忍虚拟机的错误并提高节点的可移植性 。
当虚拟机所在的宿主机因为维护或者其他原因宕机时,当前实例就需要迁移到其他的宿主机上, 为了保证业务不中断,我们需要保证迁移过程中的 IP 地址不变,因为 Overlay 是在网络层实现二层网络,所以多个物理机之间只要网络层可达就能组建虚拟的局域网, 虚拟机或者容器迁移后仍然处于同一个二层网络,也就不需要改变 IP 地址。
如上图所示,迁移后的虚拟机与其他的虚拟机虽然位于不同的数据中心,但是由于上述 两个数据中心之间可以通过 IP 协议连通,所以迁移后的虚拟机仍然可以通过 Overlay 网络与原集群的虚拟机组成二层网络 ,集群内部的主机也完全不清楚、不关心底层的网络架构,它们只知道不同虚拟机之间是可以连通的。
我们在 为什么 Mac 地址不需要全球唯一 曾经介绍过二层网络的通信需要依赖 MAC 地址,一个传统的二层网络需要网络设备中存储着从 IP 地址到 MAC 地址的转发表。
目前 Kuberentes 官方支持的最大集群为 5000 节点 ,如果这 5000 个节点中的每个节点都仅仅包含一个容器,这对于内部的网络设备其实没有太大的压力, 但是在实际情况下 5000 节点的集群中都包含几万甚至几十万个容器 , 当某个容器向集群中发送 ARP 请求,集群中的全部容器都会收到 ARP 请求,这时会带来极高的网络负载 。
在 使用 VxLAN 搭建的 Overlay 网络中 ,网络会将虚拟机发送的数据重新封装成 IP 数据包,这样网络只需要知道不同 VTEP 的 MAC 地址,由此可以 将 MAC 地址表项中的几十万条数据降低到几千条 , ARP 请求也只会在集群中的 VTEP 之间扩散 ,远端的 VTEP 将数据拆包后也仅会在本地广播,不会影响其他的 VTEP,虽然这对于集群中的网络设备仍然有较高的要求,但是已经极大地降低了核心网络设备的压力。
Overlay 网络其实与软件定义网络(Software-defined networking、SDN)密切相关,而 SDN 引入了数据平面和控制平面 ,其中 数据平面负责转发数据 ,而 控制平面负责计算并分发转发表 。VxLAN 的 RFC7348 中只定义了数据平面的内容,由该技术组成的网络可以通过传统的自学习模式学习网络中的 MAC 与 ARP 表项,但是在大规模的集群中,我们仍然需要引入控制平面分发路由转发表
大规模的数据中心往往都会对外提供云计算服务,同一个物理集群可能会被拆分成多个小块分配给不同的租户(Tenant), 因为二层网络的数据帧可能会进行广播,所以出于安全的考虑这些不同的租户之间需要进行网络隔离,避免租户之间的流量互相影响甚至恶意攻击 。传统的网络隔离会使用虚拟局域网技术(Virtual LAN、VLAN),VLAN 会使用 12 比特表示虚拟网络 ID,虚拟网络的上限是 4096 个(2的12次方)。
4096 个虚拟网络对于大规模的数据中心来说远远不够,VxLAN 会使用 24 比特的 VNI 表示虚拟网络个数,总共可以表示 16,777,216 个虚拟网络,这也就能满足数据中心多租户网络隔离的需求了。
更多的虚拟网络其实是 VxLAN 顺手带来的好处,它不应该成为使用 VxLAN 的决定性因素。 VLAN 协议的扩展协议 IEEE 8021ad 允许我们在以太网帧中加入两个 8021Q 的协议头,两个 VLAN ID 组成的 24 比特也可以表示 16,777,216 个虚拟网络 ,所以想要解决网络隔离不是使用 VxLAN 或者 Overlay 网络的充分条件。
今天的数据中心包含多个集群以及海量的物理机, Overlay 网络是虚拟机和底层网络设备之间的中间层,通过 Overlay 网络这一个中间层,我们可以解决虚拟机的迁移问题、降低二层核心网络设备的压力并提供更大规模的虚拟网络数量 :
在使用 VxLAN 构成二层网络中,虚拟机在不同集群、不同可用区和不同数据中心迁移后,仍然可以保证二层网络的可达性,这能够帮助我们保证线上业务的可用性、提升集群的资源利用率、容忍虚拟机和节点的故障;
集群中虚拟机的规模可能是物理机的几十倍,与物理机构成的传统集群相比,虚拟机构成的集群包含的 MAC 地址数量可能多一两个数量级,网络设备很难承担如此大规模的二层网络请求,Overlay 网络通过 IP 封包和控制平面可以减少集群中的 MAC 地址表项和 ARP 请求;
VxLAN 的协议头使用 24 位的 VNI 表示虚拟网络,总共可以表示 1600 万的虚拟网络,我们可以为不同的虚拟网络单独分配网络带宽,满足多租户的网络隔离需求;
需要注意的是,Overlay 网络只是一种在物理网络上的虚拟网络,使用该技术并不能直接解决集群中的规模性等问题,而 VxLAN 也不是组建 Overlay 网络的唯一方法,在不同场景中我们可以考虑使用不同的技术,例如:NVGRE、GRE 等。到最后,我们还是来看一些比较开放的相关问题,有兴趣的读者可以仔细思考一下下面的问题:
VxLAN 将原始数据包封装成 UDP 在网络上分发,那么 NVGRE 和 STT 分别使用哪些方法传输数据呢?
在 Kubernetes 中部署 Overlay 网络应该使用什么技术或者软件?
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)