某考试报名系统服务器负载均衡及应用加速报告.pdf

ASCE NETWORKS S U P E R I O R I N I P T E C H N O L O G Y R 1 某考试报名系统服务器负载均衡 及应用加速报告 某考试报名系统服务器负载均衡 及应用加速报告 某大型考试报名系统网站的应用服务器负载均衡及应用加速方案采用了美 国优势网络公司 Asce Networks 的InChorus应用前端交换机产品 设备在整 个报名期间运行稳定 顺利的保证了考试报名的进行 1 客户需求 客户需求 正常情况下要求对后端的服务器的进行负载均衡的功能 实现透明的容错 当某台服务器停机或者出现故障的时候保证网站业务的不间断 准确的会话保持方式 使同一个用户的请求都要分配于同一台服务器之上 保证所有应用正常的运行 在保证对应用负载均衡的同时对应用进行加速 在提高网站整体处理能力的 同时提升用户的访问感受 基于应用层的健康检查方式 要求准确的判断出服务器的健康状况 灵活的扩展空间 根据实际应用的需求进行升级 提高整体服务能力 该类型网站的特点是平时访问量非常低 但是在特殊时期访问量剧增 在该 种情况下 不会造成设备负担过重 影响访问性能 甚至导致设备崩溃 ASCE NETWORKS S U P E R I O R I N I P T E C H N O L O G Y R 2 2 部署模式及拓扑图 部署模式及拓扑图 在本案例中 在本案例中 InChorus 应用前端交换机采用双机应用前端交换机采用双机 active active 旁路部署于核心交换机之上 旁路部署于核心交换机之上 3 报名系统基本状况 报名系统基本状况 整套报名系统包含后端的 10 台基于 IIS 的 web 服务器 3 台数据库服务器 数据库采用 SQLserver 我们 InChorus 旁路部署于核心交换机之上 负责对 10 台 web 服务器进行负载均衡和应用加速的作用 首先通过登录静态引导页面 查询报考的相关信息 那么需要点击页上的报 名的参考信息 如果确定要报名那么需要进入报名系统 另外的一个超链接则是 该考试系统网站主页 在这三条超链接中 只有报名系统是一个基于 aspx 的动 态网页 而某考试系统网站和报名的参考信息中则主要是以 html 静态页面为主 4 InChorus相关运行模式相关运行模式 会话保持方法会话保持方法 会话保持用来保证将同一个用户的所有请求发送到同一台服务器上进行处 理 从而保证用户的数据完整性 对于需要在服务器上保留用户信息的应用至关 重要 InChorus应用前端交换机支持多种会话保持方法 如基于客户端IP地址 基于cookies 基于特定应用的特定cookies 基于java 基于SSL session ID 基 于智能流量管理脚本语言 在对该报名系统的支持中我们采用基于cookies的会 话保持方式 在报名期间没有出现用户反映访问不正常的情况发生 服务器健康检查服务器健康检查 整套报名系统中存在 3 个主要板块 而这三个板块又通过一个静态页面进行 ASCE NETWORKS S U P E R I O R I N I P T E C H N O L O G Y R 3 引导 如果我们仅仅监控服务器能否响应 或者服务端口是否开启 或者某个页 面能否正常打开并不能真实的去反映服务器提供服务的能力 所以 InChorus 应 用前端交换机提供了复合型的健康检查手段 我们采用了三个 full http 和一个 simple http 不仅仅可以检查到主引导页的健康状况而且可以检查到引导页里每 个板块的健康状况 最大限度的贴合了应用 服务器负载均衡算法服务器负载均衡算法 众所周知 对于服务器负载均衡技术而言 非常重要的一个性能指标就是负 载均衡的算法 虽然服务器负载均衡只是InChorus 应用前端交换机的七分之一 的功能 但是其负载均衡算法非常全面 包括 轮循 加权轮循 感知 最小连 接数 最快响应时间 随机等等 由于该报名系统后端服务器的硬件配置完全一样 在性能上不存在太大的差 异 所以我们采用了轮询的负载均衡算法 5 InChorus运行状况运行状况 在半个月的报名期间 设备整体运行稳定 主要采用双活模式 两台设备分 别命名为 AFE 和 AFE1 每天的流量分布状况基本一致 主要存在两个高峰期 分别在早 9 点和晚 8 点左右 此时设备的负载比其他时段高 10 流量从晚上 11 点开始下降 早 7 点开始回升 而其他所有时段的流量基本上趋于平稳 以下内容是流量平稳阶段 的设备负载 带宽状况以及连接状况 下图为设备的带宽情况 紫色线条为设备的输出流量 180M 左右 绿色线条为设备的接收流量 60M 左右 ASCE NETWORKS S U P E R I O R I N I P T E C H N O L O G Y R 4 下图为设备的连接情况 紫色线条为设备已经建立的链接 在一万六左右 粉色线条为每秒新增的连接数 每秒新增两千七左右 设备 AFE 的负载状况 其中 id 值为空闲值 用 100 减 id 等于设备负载 观 察下图可以发现 设备负载在 25 左右 memory 中的 free 为内存的空闲值 设备的总内存为 8G ASCE NETWORKS S U P E R I O R I N I P T E C H N O L O G Y R 5 AFE1 设备负载如下图所示 设备负载在 15 左右 内存空闲 7 1G 整个报名系统刚开始运行时 整体的页面结构并没有做调整 此种情况大概 持续了一天 当时所有用户想要报名必须先打开某考试系统网站的主页 而该 页面有 900K 这样就导致了我们设备的输出带宽非常的大 高达 520M 达到 该考试系统的因特网出口总带宽的极限 这样就导致了外部用户访问速度过慢 或者不能正常访问 此时网络带宽已经成为整个系统的瓶颈 所以介于此种情况 我们开启了压缩功能来缓解这种情况 开启压缩之后带宽的变化 紫色线条为设备的输出流量 输出带宽从 520M 降至 250M 效果非常明显 绿色线条为设备的接收流量 入流量也从 35M 提高到 50M 说明整个应用整体 处理能力提高了 ASCE NETWORKS S U P E R I O R I N I P T E C H N O L O G Y R 6 开启压缩之后连接数的变化 绿色线条为设备已经建立的连接 降低到两万 不需要处理更多的等待连接 黄色线条为每秒新增的连接数 每秒新增连接在五千 可以处理更多的连接 6 给用户的一些建议 给用户的一些建议 在为时半个月的报名期间 InChorus 应用前端交换机可以为用户提供稳定高 性能的服务 但是负载均衡功能只是 InChorus 应用前端交换机众多功能中的一 个部分 如何更充分利用好 InChorus 应用前端交换机 使其为用户提供响应更加迅捷的服务是我们需要着重 考虑的问题 比如 对于静态网页的处理上我们可以 使用 cache 减轻后端服务器负载的同时也能让我们设 备更加轻载 考生的整套报名流程是这样的 首先通过登录静 态引导页面 查询报考的相关信息 那么需要点击页 上的报名的参考信息 如果确定要报名那么需要进入 报名系统 另外的一个超链接则是某考试系统的网站 主页 在这三条超链接中 只有报名系统是一个基于 aspx 的动态网页 考生进入报名系统后主要是填报名 表 查询报考情况 查询考试信息 而某考试系统网 站和报名的参考信息中则主要是以 html 静态页面为 主 既然某考试系统主页和报名的参考信息部分都是以 html 静态页面为主 那 么我们可以通过开启 cache 来处理这部分内容 不仅仅可以减轻后端服务器的压 力 而且也可以减轻我们设备的负载 用户无需担心开启 cache 对应用的影响 因为我们可以通过 TrafficSmart 智 能流量管理脚本语言 TrafficSmart 去控制缓存的内容 InChorus 应用前端交 ASCE NETWORKS S U P E R I O R I N I P T E C H N O L O G Y R 7 换机可根据用户的应用区分哪些页面不需要缓存 哪些页面需要缓存 以及缓存 更新的时间 确保缓存的正确率和高命中率 比如说 用户选择对于后缀为 aspx 的页面不进行缓存 可以通过以下智能脚本来实现 path http getpath if string endswith path aspx http cache disable else http cache enable Cache 和压缩的关系和压缩的关系 在没有开启 cache 的时候 InChorus 每次从后端服务器读取到数据都要进行 一次压缩 这样是非常消耗系统资源的 尤其是在高流量的情况下 如果开启了 cache 那么对于 cache 到的内容我们则只需压缩一次 cache 的内容越多设备 则可以越轻载 所以 cache 和压缩功能也可以说是相辅相成的 以下内容是我们对开启 cache 以及在开启 cache 的基础上开启压缩所进行的 测试数据 设备吞吐量设备吞吐量 设备负载设备负载 内存空闲情况内存空闲情况响应时间平均值响应时间平均值 初始状态 558M 60 1 81G 12 611s 开 cache 726M 44 1 78G 9 662s Cache 加压缩 542M 74 1 77G 8 931s 如上数据我们可以发现 在开启 cache 的时候 由于设备减少了许多与后端 服务器之间的交互动作 所以设备的负载可以明显的降低 由于测试都是在局域 网内进行 所以减少一跳并不能在访问时间上得到多大的提升 在开启了 c