共 10 篇相关文章
这篇讲的是作者在LVS环境下验证的一种不中断业务的RealServer升级方案。核心目标是在不中断前端服务的情况下，对后端真实服务器进行维护或重启。 作者选用了LVS的DR（直接路由）模式进行实验。文章详细列出了网络规划，包括两台RealServer和一台Director Server的IP分配。关键在于具体的配置实践：在Director上，通过ipvsadm工具设置VIP和采用加权轮询调度算法；在RealServer上，则通过脚本在本地绑定VIP并设置ARP抑制，这是DR模式正常工作的基础。 作者验证的流程是：通过脚本控制，让需要升级的RealServer自动从LVS集群中移除，待维护完成并检查健康后，再自动重新加入集群。整个过程对客户端保持透明，实现了业务不中断。文章提供了可用的脚本片段，将配置步骤代码化，方便读者参考和复现。对于需要在生产环境中安全维护LVS节点的运维人员来说，这个实验记录提供了一套切实可行的操作思路和工具参考。
作者从一次监控异常出发，揭示了LVS/Nginx架构下访问控制的典型陷阱。他在Graphite上发现服务器网卡流量
这篇技术文章详细记录了作者为LVS负载均衡器添加SNAT网关功能的实战过程。目标很明确：让LVS在承担4层反向代理的同时，还能为内网机器提供访问外网的能力。 作者先分析了常规方案的局限——使用iptables虽能实现SNAT，但会严重影响LVS性能。因此，他决定直接修改LVS源代码。文章核心梳理了两种实现路径：一是修复小米已有的dsnat项目，使其兼容NAT和FULLNAT转发模式；二是在官方内核的NAT模式上，以最小改动直接添加SNAT功能，无需依赖额外的FULLNAT补丁。 实现过程颇具细节：从获取内核源码、打补丁、编译调试，到使用tcpdump抓包分析，作者逐步解决了dsnat与原生NAT的兼容性bug，以及其与FULLNAT的配置冲突。最终产出的补丁和配置示例，为有类似需求的读者提供了可直接参考的完整方案。文章也坦诚指出了当前实现的局限，如暂不支持ICMP协议转发。
这篇讲的是如何解决LVS在高并发场景下因默认哈希表过小而导致的性能瓶颈问题。 文章指出，LVS用于记录连接信息的connection hash table默认仅有4096条目（可通过`ipvsadm -ln`查看）。当并发连接数远大于此值时，会发生频繁的哈希冲突与置换，显著增加系统负载。作者在CentOS 5.4环境下，演示了通过重新编译内核来扩展此限制的具体方法。 核心操作是获取系统对应的内核源码包，在编译配置中将`CONFIG_IP_VS_TAB_BITS`参数从默认的12（对应2^12=4096）修改为20（对应2^20=1048576）。使用原有配置进行编译，能确保仅改变哈希表大小而不影响内核其他功能。编译安装新内核并重启后，哈希表大小成功扩展至超过百万级。 作者也分享了实用经验：为应对业务增长，他通常直接将该值设为最大的20。同时提醒，每个连接都会占用内存（约136字节），即使LVS理论性能可达百万级，也需确保服务器有足够的内存资源来支撑。
这篇讲的是在资源有限的场景下，如何将 LVS 负载均衡（DR模式）与它背后的 realserver 服务（如数据库）部署在同一台物理机上，以节省硬件成本。作者在两台服务器构成的集群里，尝试通过 keepalived 实现 LVS 主从高可用，并希望负载和业务服务共存。 但配置完成后，服务无法正常工作。核心矛盾在于，VIP（虚拟IP）同时配置在作为 LVS 和 realserver 的本机网卡上，导致了本地数据流在内核网络栈中的异常路由和重复发送。文中提供的架构图清晰地展示了这个问题：请求包（CIP->VIP）在本机被 LVS 处理后，又作为“外来”数据包被本机的 realserver 服务重复接收了一次，形成了环路。 这篇文章并未直接给出最终的解决方案，而是像一篇“踩坑日志”，详细列出了问题现象、尝试的架构以及配置输出，将 LVS-DR 模式下的一个典型部署陷阱——“同机部署时的数据包回流与自环”——摆在了台面上。它邀请读者一起思考：在这种极致节省的架构下，到底该如何调整内核参数、网络配置或 LVS 规则，才能打破这个循环，让调度器和后端服务在同一台机器上和谐共存。这种对具体、细微问题的深入排查，对面临类似成本与架构权衡的运维和开发人员，有着直接的参考价值。
这篇文章从LVS创始人章文嵩博士的一次内部分享讲起，梳理了LVS的核心实现原理。作者指出，LVS集群最核心的部分是请求分发服务器、处理服务器以及共享存储。在典型的Web集群中，通常只有前两者，但在需要访问一致数据的场景（如邮件服务器）下，共享存储就变得至关重要。 接着，文章将焦点转向了数据库层：在众多的MySQL存储引擎中，唯有NDB Cluster实现了共享存储的功能，因此成为与LVS协同构建数据库集群的可行选择。具体到NDB Cluster，SQL Node充当了处理服务器的角色，而Data Node则承担了共享存储的职责。 这种架构组合带来的直接好处是，它极大地简化了应用开发——开发人员无需关心后端具体的数据库服务器实例，就能获取所需数据。同时，NDB Cluster提供的数据分片与扩容能力，也保障了数据库层面的可扩展性。对于需要数据一致性的高可用架构，这种组合提供了一个清晰的思路。
这篇文章从LVS创始人章文嵩博士在淘宝的一次内部分享切入，梳理了LVS（Linux虚拟服务器）的核心原理及其与MySQL NDB Cluster的结合实践。LVS的架构核心是请求分发服务器、处理服务器和共享存储这三大组件，在典型的Web集群中，通常无需共享存储；但对于邮件服务等需要数据一致性的场景，共享存储则成为必要。 当应用场景转向数据库时，文章指出目前能与LVS有效协同的MySQL集群方案主要是NDB Cluster，原因在于其存储引擎层实现了真正的共享存储。在NDB Cluster架构中，SQL Node对应LVS的处理服务器，Data Node则承担了共享存储的角色。这种组合为应用开发带来了显著简化：开发人员无需感知后端具体是哪台数据库服务器在处理请求，同时又能通过NDB Cluster的数据自动分片与在线扩容能力，确保整个数据库层的高可扩展性。文章通过架构图示对比了Web与邮件集群的不同配置，最终落脚于LVS如何屏蔽底层复杂性、助力应用快速开发与扩展。
这篇讲的是如何用MySQL Cluster 7.0结合LVS，为MySQL搭建一个真正高可用的架构。 作者从传统MySQL主从复制的高可用痛点切入：当主库宕机，需要手动或依赖脚本切换IP，服务中断时间不可控，且存在数据不一致的风险。为了解决这个问题，文章提出了一套基于MySQL Cluster（NDB引擎）与LVS（Linux虚拟服务器）的自动化高可用方案。 方案的核心思路在于利用MySQL Cluster本身的数据多节点复制与自动故障转移能力，确保数据层的高可用；同时，通过LVS在前端负载均衡层进行健康检查与流量调度，自动将请求从故障节点移开，实现应用访问层的无缝切换。文章详细说明了具体的架构设计、LVS的配置要点，以及如何测试验证其故障自动切换的效果。 最终，这套组合拳实现了在节点故障时，业务访问几乎无感知，显著提升了系统的整体可用性。它为需要兼顾高性能与高可用的MySQL环境，提供了一个可靠且具备扩展性的架构参考。
这篇由杨建撰写的文章聚焦于网站加速的系统架构实践，直接针对现代Web应用面临的性能瓶颈和运营成本高企的双重挑战。作者从架构设计的角度切入，指出传统优化手段如简单代码调整或硬件升级往往效果有限且成本递增，而系统层面的重构才是破局关键。 文章的核心方案围绕分布式架构展开，详细阐述了如何通过引入微服务拆分、异步处理机制、智能缓存策略以及弹性伸缩设计，来构建一个高吞吐、低延迟的访问体系。例如，作者可能探讨了如何利用负载均衡和CDN节点部署来分担流量压力，同时结合数据库读写分离与查询优化，减少响应时间。这些架构调整不仅提升了系统整体的并发处理能力，还通过资源利用率的优化避免了不必要的硬件投入。 结论部分用数据说话：经过系统架构优化后，网站性能提升可达数倍，而基础设施和运维成本却实现了10倍以上的节约。这种“一升一降”的效果，为面临相似问题的技术团队提供了一个可复用的蓝图——即通过前瞻性的架构设计，在加速用户体验的同时，牢牢把控成本线。
这篇讲的是杨建如何通过架构层面的优化，在提升网站性能的同时大幅削减成本。作者没有堆砌理论，而是从网站加速中常见的性能与成本的矛盾出发，揭示了传统优化思路的瓶颈。核心方案转向了对请求链路的精细化管控——比如在资源加载、缓存策略和传输环节进行架构级重构，用更聪明的“巧劲”替代粗暴的堆叠资源。 文章的一个亮点是给出了具体的成本对比数据，实测显示新方案能节约高达十倍以上的开销，而性能提升依然显著。这并非靠牺牲体验换来的，而是通过消除冗余请求、优化资源分发路径来实现的。对于面临类似技术选型或成本压力的团队来说，这套思路提供了非常务实的参考：高性能并不必然等于高投入。
