公司网站建设方案详细方案,四川省公共资源交易中心,做百度手机网站,最好的网站模版1. 从“重启恢复”到“业务零中断”#xff1a;为什么你需要了解Fault Tolerance#xff1f; 在虚拟化世界里#xff0c;高可用性#xff08;HA#xff09;大家应该都听过。它的工作模式有点像“保险”#xff1a;当一台物理服务器突然宕机#xff0c;HA机制会迅速在集群…1. 从“重启恢复”到“业务零中断”为什么你需要了解Fault Tolerance在虚拟化世界里高可用性HA大家应该都听过。它的工作模式有点像“保险”当一台物理服务器突然宕机HA机制会迅速在集群的另一台主机上把宕机服务器上的虚拟机重新启动起来。这确实能救命避免了业务长时间中断。但不知道你有没有想过从物理机宕机到虚拟机在另一台主机上完成重启、操作系统加载、应用服务恢复这中间的时间窗口短则几十秒长则几分钟。对于一些对业务连续性要求极高的核心系统比如实时交易系统、关键数据库、7x24小时在线的核心应用这几分钟的“空窗期”可能就是无法接受的。这时候Fault ToleranceFT容错就该登场了。你可以把它理解为HA的“终极进化版”。如果说HA是“快速重启”那FT就是“无缝切换”。它的核心思想特别酷为你的主虚拟机Primary VM创建一个完全同步、实时更新的“影子”虚拟机Secondary VM这个影子虚拟机运行在集群的另一台主机上。主虚拟机做的每一个CPU指令、内存的每一次修改、网络的每一个数据包都会通过一个低延迟的专用网络几乎实时地同步到影子虚拟机。两台虚拟机在逻辑上就像是一个整体但物理上却运行在不同的“底盘”上。当运行主虚拟机的那台物理主机突然挂掉比如断电、硬件故障会发生什么影子虚拟机会在零感知、零中断的情况下瞬间“转正”成为新的主虚拟机继续对外提供服务。对于虚拟机内部运行的操作系统和应用来说它们完全感觉不到底层硬件已经换了一台。这个过程没有重启没有服务停止业务流量不会丢失用户会话不会断开。这才是真正意义上的“业务零中断”高可用。听起来是不是有点像科幻片但这确实是vSphere企业级功能里的一块瑰宝。我最早接触FT是在一个金融项目的核心结算系统上客户的要求简单粗暴“计划内维护可以停机但任何意外故障业务不能停一秒钟都不行。”当时我们评估了各种方案最终FT以它的“零切换”特性完美胜出。当然它也不是没有代价和限制的比如对硬件有要求、会消耗更多资源但这些在“零中断”的价值面前很多时候是值得的。接下来我就带你从零开始亲手搭建并深入理解这个强大的功能。2. 实战前哨搭建你的FT实验环境与核心概念扫盲纸上谈兵终觉浅咱们直接动手。在开始配置之前得先把“战场”准备好并搞清楚几个关键概念免得后面踩坑。首先实验环境。我强烈建议你用一个隔离的测试环境来操作比如家里用几台旧电脑搭的vSphere实验室或者公司的开发测试集群。我的演示环境基于vSphere 7.0 U1这是目前比较稳定且FT功能成熟的一个版本。你需要一个vCenter Server用于集中管理。至少两台ESXi主机组成一个集群Cluster。FT要求主、备虚拟机必须运行在不同的主机上所以两台是起步三台或以上能提供更灵活的放置策略。共享存储。这是必须的主、备虚拟机的虚拟磁盘文件必须放在共享存储如VMFS/NFS/vSAN上这样当主机故障切换时另一台主机才能无障碍地访问到相同的磁盘数据。本地存储玩不转FT。环境准备好了我们来扫清几个最容易混淆的概念Primary VM (主虚拟机)就是你原本要保护的那台业务虚拟机它正常运行对外提供服务。Secondary VM (辅助/影子虚拟机)由FT功能自动创建并维护的副本。它不接收外部网络流量只默默地、持续地从Primary VM同步状态。你对它进行任何直接操作开机、关机都会破坏FT保护。FT Logging Network (FT日志网络)这是FT的“生命线”。主备虚拟机之间所有的状态同步主要是CPU指令和内存增量变化都通过这个专用网络进行。它需要极高的带宽和极低的延迟万兆网络是推荐配置并且必须配置在专用的VMkernel网卡上不能和业务流量混用。vLockstep (虚拟锁步)这是FT实现同步的核心技术。你可以想象成Primary VM每执行一步都会等一下等Secondary VM也执行完同样的这一步并确认然后Primary VM才执行下一步。这就保证了两台虚拟机的状态严格一致。这个“等待”和“同步”的信号就是通过FT日志网络传递的。这里有个我踩过的大坑要提醒你FT对虚拟机的配置有严格限制。在vSphere 7.0中FT最多支持8个vCPU的虚拟机。如果你的业务虚拟机是16核甚至32核的“巨无霸”很遗憾FT暂时保护不了它你得考虑其他高可用方案或者评估能否拆分应用。另外启用FT的虚拟机不能使用某些高级功能比如快照Snapshot、Storage vMotion会临时中断FT、以及一些需要直通硬件的设备。3. 第一步为FT铺好“高速公路”——配置VMkernel网络万事俱备只欠“网路”。FT日志网络是整套机制的基石配置不好后面全白搭。这一步需要在集群中每一台计划运行FT虚拟机无论是主还是备的ESXi主机上单独配置。登录到你的vSphere Client进入主机与集群视图。选中第一台ESXi主机进入“配置”选项卡在“网络”下选择“VMkernel适配器”然后点击“添加网络”。选择连接类型这里务必选择“VMkernel网络适配器”然后下一步。选择目标设备为你计划用于FT流量的物理网卡选择一个上行链路。最佳实践是使用独立的物理网卡至少也是与业务流量隔离的VLAN。我一般会专门预留一个万兆电口或光口给FT确保带宽和隔离性。端口属性这是关键一步在“启用服务”里找到并勾选“Fault Tolerance 日志记录”。其他服务如vMotion、管理流量等不要勾选专网专用。给你的这个VMkernel适配器起个容易识别的名字比如ft-logging。IPv4设置为这个适配器配置一个与管理网络、业务网络都不同的IP地址段。比如你管理网是192.168.1.x业务网是10.10.x.x那FT日志网络可以规划一个172.16.1.x的网段。确保集群内所有主机的FT日志网络IP在同一个子网且能互相ping通。重复以上步骤为集群里的第二台、第三台主机都配置好FT日志记录的VMkernel适配器。完成后你可以从一台主机的FT网卡去ping另一台主机的FT网卡IP测试连通性。这里有个高级技巧如果你追求极致的高可用和性能可以为FT配置多网卡绑定。在创建VMkernel适配器时选择多个上行链路并设置负载均衡策略比如基于源虚拟端口ID。这样即使一条物理链路故障FT同步也不会中断。我在生产环境给核心系统配置FT时就用了两条10G链路做绑定稳如泰山。4. 第二步点石成金——为虚拟机开启Fault Tolerance保护网络配通我们就可以对心爱的虚拟机施展“保护咒”了。这个过程在vCenter里操作非常直观。找到你想要保护的虚拟机右键点击选择“Fault Tolerance” - “打开 Fault Tolerance...”。系统会弹出一个向导这里有几个重要的选择点选择数据存储首先会让你为Secondary VM影子机选择存放配置文件和数据的位置。这里必须选择一个共享存储并且最好是与Primary VM不同的数据存储出于性能隔离和冗余考虑。系统会列出可用的共享存储列表你选一个就行。我通常会选一个性能不错的全闪存vSAN数据存储或者集中式SAN存储。选择主机接下来是最有意思的一步——为Secondary VM选择运行在哪台主机上。vSphere会基于DRS分布式资源调度的规则自动为你推荐一个与Primary VM所在主机不同的服务器。它会考虑主机的CPU、内存资源是否充足以及FT日志网络的延迟。我强烈建议你接受系统的推荐除非你有明确的理由比如知道某台主机硬件不太稳定。手动选择也可以但一定要确保和目标主机之间的FT网络延迟足够低通常要求1ms。点击完成vCenter就开始施展魔法了。你会看到任务列表里出现“打开 Fault Tolerance”的任务。这个过程需要一些时间因为它要做几件事在指定的共享存储上为Secondary VM创建一套完整的配置文件。在选定的备用主机上注册并启动Secondary VM。建立Primary VM和Secondary VM之间的初始同步Initial Synchronization。这个阶段Primary VM的内存状态会被完整地拷贝到Secondary VM如果你的虚拟机内存很大比如128GB这个阶段会耗时较长并且会产生大量的FT日志网络流量。初始同步完成后进入持续的“锁步”运行状态。开启成功后你回到虚拟机视图会发现被保护的虚拟机图标左下角多了一个特殊的FT标志两个重叠的小方块。右键虚拟机查看“摘要”选项卡也能看到“Fault Tolerance 状态”显示为“受保护”。这时候你的业务虚拟机就已经拥有了一个时刻待命的“数字孪生兄弟”。5. 第三步“破坏性”测试——验证FT的切换效果配置好了不测试一下怎么知道真的管用测试FT切换是检验我们工作成果最激动人心的环节。但测试要有方法不能蛮干。最安全、最经典的测试方法是使用vCenter提供的“测试故障切换”功能。右键受FT保护的虚拟机选择“Fault Tolerance” - “测试故障切换”。这个操作非常精妙它会让Primary VM暂停注意不是关机也不是崩溃然后观察Secondary VM是否能无缝地接管并变成新的Primary VM。因为Primary VM只是暂停所以测试完成后你可以轻松地“撤销”这次测试让一切恢复原状对业务的影响微乎其微会有一次短暂的网络闪断因为MAC地址和IP需要重新宣告。这是官方推荐的测试方法也是上线前必做的动作。如果你想模拟更真实的主机故障可以尝试对运行着Primary VM的ESXi主机做一些“暴力操作”。比如在这台主机上执行“进入维护模式”vCenter会尝试将Primary VM迁移到其他主机如果开启了DRS而FT机制会确保Secondary VM接管。或者更直接一点在确保业务可承受风险的前提下直接给那台物理主机断电这是最真实的演练。你会看到在vCenter的监控界面上原来作为Secondary VM的虚拟机会在几秒钟内状态变为Primary并开始接收业务流量。而故障主机上的那个Primary VM实例会显示为“孤立”或“无响应”。我印象最深的一次测试是在客户现场我们拔掉了主虚拟机所在主机的电源线。监控屏幕上的业务系统性能图表只出现了一个持续时间小于1秒的微小毛刺应用完全没有报错用户会话保持。客户的技术总监当时就说“这效果值了。”测试完成后别忘了检查。新的Primary VM运行是否正常业务应用日志有没有报错FT保护状态是否自动为新的Primary VM生成了新的Secondary VM这个过程叫“重新保护”这些都需要确认。6. 进阶管理与排坑指南参数、限制与日常运维FT用起来很爽但日常管理和排错才是真功夫。这里分享一些进阶知识和我踩过的坑。首先是许可和配置限制。FT是vSphere高级版本的功能需要Enterprise Plus许可证。而且正如开头提到的它支持的最大vCPU数是8个。这是硬限制由许可证层控制无法通过配置修改突破。另外默认情况下一个ESXi主机上能运行的受FT保护的虚拟机数量以及这些虚拟机vCPU总数也受集群HA设置的限制。这些参数是das.maxftvmsperhost单台主机上允许的最大FT虚拟机数量。das.maxftvcpusperhost单台主机上允许的FT虚拟机vCPU总数。如果你想在测试环境解除这些集群限制以便在一台主机上运行多个小型FT虚拟机做测试可以在vCenter的集群设置里找到“vSphere Availability”下的“高级选项”添加这两个参数并把值都设为0。但务必注意这只能解除集群层面的软限制8个vCPU的许可证硬限制依然存在。日常运维要注意什么监控FT网络这个网络的健康状况是FT的生命线。要持续监控其带宽使用率和网络延迟。如果延迟持续过高会导致Primary VM性能下降因为要等待Secondary VM同步严重时甚至会触发FT中断。主机维护当需要对某台运行着FT虚拟机的主机进行维护打补丁、升级硬件时不要直接关机。应该先通过vCenter将主机置于维护模式系统会自动触发FT的“迁移”动作将受影响的FT虚拟机无论是Primary还是Secondary平滑地迁移到其他主机整个过程业务无感知。存储迁移要小心对受FT保护的虚拟机执行Storage vMotion迁移存储时FT功能会暂时关闭迁移完成后再自动重新启用。这中间会有一个短暂的FT保护空窗期需要安排在业务低峰期进行。快照与FT不兼容这是很多人的误区。你无法对一台已经开启FT的虚拟机创建内存快照或静默快照。必须先关闭FT打快照然后再重新打开FT。重新打开FT会触发一次完整的初始同步耗时较长。排错经验谈如果FT开启失败首先检查FT日志网络的连通性和MTU设置建议用巨帧。检查主机证书和时间是否同步证书问题经常导致FT通信失败。查看ESXi主机的/var/log/vmware/hostd.log和vmkernel.log搜索“FT”、“fault tolerance”、“vLockstep”等关键词能找到具体的错误原因。我曾遇到过一个诡异的问题FT开启后几分钟就自动断开。最后排查发现是客户在交换机上对FT网段做了端口安全策略限制了MAC地址学习数量而FT同步会产生大量带有不同源MAC地址的包来自不同的虚拟端口触发了策略丢弃。所以确保FT网络路径上的所有物理交换机端口配置为“portfast”或类似特性并关闭不必要的安全策略。FT功能虽然强大但它也是资源消耗大户。因为它要求所有CPU指令和内存写入都同步一次所以会带来一定的性能开销通常CPU开销在5%-15%之间并且会占用大量网络带宽。因此它最适合用来保护那些规模适中vCPU 8、但对中断及其敏感的核心业务虚拟机。对于规模更大的系统你可能需要结合使用vSphere HA、应用集群如Windows故障转移集群、Oracle RAC等其他高可用方案来构建更深层次的防御体系。