《51CTO电子杂志《Linux运维趋势》第2期》由会员分享，可在线阅读，更多相关《51CTO电子杂志《Linux运维趋势》第2期（27页珍藏版）》请在金锄头文库上搜索。
1、2010 年 11月 第二期 本期主题 可用性 关键字 集群 负载均衡 高可用 LVS 内容目录 专访黄琨 运维工作中最大的挑战是什么 1 NoSQL 小故事 单服务器如何应付每秒 75 万次查询 3 八卦 趣闻与数字 2010 10 2010 11 6 本期专题 可用性 7 什么是高可用性 8 手把手让你了解Linux 集群 原理篇 9 可扩展 高可用服务网络设计方案 12 Linux 集群服务LVS概述与安装配置详解 14 19 个心得 明明白白说 Linux 下的负载均衡 16 几个 vi 技巧和诀窍分享 19 全新的备份利器推荐 Duplicity 使用评测 21 开源自动化配置管理工
2、具 Puppet 入门教程 23 杂志策划 51CTO 系统频道 本期主编 杨赛 Logo 制作 高鹏飞 封面制作 徐泽琼 交流圈子 邮件群组 订阅方式 发送 Email 到 linuxops cn subscribe 投稿信箱 yangsai 人物 People 维是一个全面的工作 可以接触到各种 领域的技术和人 运维是一种实操类的 技能 其经验积累很大程度上来自于真实项目的 积累 因此 对于运维领域的新人而言 如果他 们工作的环境并没有提供一个良好的平台 就经 常容易陷入困惑 运 本期 趋势 当中 我们邀请到了黄琨老师到 场 谈谈他自己的运维成长经历及挑战 51CTO 您是什么时候开始做的
3、运维 对工作一 您是什么时候开始做的运维 对工作一 开始的几年有哪些深刻的记忆 开始的几年有哪些深刻的记忆 黄琨 我2002 年之前主要是从事网络集成的 项目的设计实施工作 之后进入石景山区信息中 心负责全区各行政单位的网络 中心 IDC 的维护 工作 那个时候的工作有苦有乐 最重要的是能 够学到知识 有一个好的平台对我来说非常重 要 当时正处于互联网业务发展的初期 有些企 业的业务平台也陆续在中心 IDC 上线 为我的技 术学习提供了良好的氛围和实验条件 记忆最深刻的就是有一次中心机房要从教委迁 移到区政府信息中心 那次迁移工作量相当大 包括 网络设备 服务器 新老应用割接 新设 备上线 对
4、网络和应用层做了链路冗余以及高可 用等 让我有机会一次性的把之前做过的实验用 到了真实的工作中 当时网络设备用的是 CISCO 的 6500 系列两台做的冗余 汇聚层和接入层也 都是 Cisco 的产品 35 系列和 25 系列 服务器 400 台左右 安全方面有天融信的防火墙 还有 NIDS 规模大任务重 当时中心系统组负责人 也是现在我的好朋友张琦老师对我的帮助非常大 从原中心业务系统整体梳理 备份 链路及服务 割接工作的计划设计 各别服务系统更新 重要 服务应用高可用的设计 双因素认证系统等等工 作帮助我整理的井井有条 工作非常顺利 当时 还获得中心同事的表扬 至今记忆犹新 51CTO
5、能介绍一下您现在的工作情况么 您的 能介绍一下您现在的工作情况么 您的 职责包括哪些方面 职责包括哪些方面 黄琨 现在和白璐 杨晨等开源和网络方面的 精英一起开办了一家专门培养运维人才的培训机 构 荣新 IT 培训中心 经过这几年的努力 培 训中心的规模已经扩大了 5 倍 我现在任 CTO 的职位 一方面负责企业项目及 运维外包服务的工作 为企业提供优良的技术服 务之外将前沿技术引入到培训中来 另一方面负 责培训学员到企事业单位的人才输送工作 51CTO 能否大致的描述一下您每天的工作内容 能否大致的描述一下您每天的工作内容 黄琨 本人现在主要负责 1 IT 运维外包项目计划 项目方案设计监督
6、 估算 管理 跟踪项目进度 2 企业人才输送 组织技术指导 收集问题 回馈 协助教学部形成教材 3 Linux 等相关运维人才市场的动向监控 专访黄琨 运维工作中最大的挑战是什么 采访 杨赛 投稿信箱 yangsai 1 人物简介 人物简介 黄琨 曾任知名外企 SP 公司运维经理 多年网络应用架构设计及运维 管理经验 涉及技术包括 Linux SUN 小型机 Windows 运维 互联网 应用平台架构设计 Oracle Mysql 数据库 开源分布式集群架构设计及 调优 网络及安全设备架构及管理 现在任职于荣新 IT 培训中心 担任 IT 运维外包项目总监 企业人才外包项目总监 人物 Peop
7、le 运维一线现在已有600 以上荣新学员 我也描 述一下他们刚入行时候的工作内容吧 1 快速分析整理公司业务及平台设计逻辑架 构 缓存 应用 数据库 网络设备及其他设备 的运作原理 2 平台各层面监控 避免监控死角 实时了 解平台各层应用的运转情况 处理突发问题 迅 速做出问题响应 做好问题处理分析报告为后续 自动化运维设计作补充 3 平台代码更新 根据平台规模设计部署更 新源资源下载服务 补丁批量更新机制 4 配合运维经理设计实现运维支撑系统 包 括系统监控 报警 管理功能 实现数据图形报 表 整合手机短信 邮件 声音报警功能 根据 监控排障反映上来的问题不断完善自动化运维机 制 5 配合
8、运维经理对平台架构进行分析 不断 提升整体应用的可靠性与健壮性 提高性能及安 全性 51CTO 您觉得您目前的运维生涯当中最大的挑 您觉得您目前的运维生涯当中最大的挑 战是什么 战是什么 黄琨 我认为挑战主要分为技术和沟通两方面 当然由于我现在从事培训和运维外包工作 所以 另一个转型的挑战 1 技术方面的挑战是运维工作的职责体现出 来的 简单的说产品从需求收集 开发及网络系 统架构设计 开发测试阶段 产品上线联调 问 题反馈 正式商用后运维阶段等等 因篇幅有限 我无法说得太详细 这些工作运维都需要跟下来 前几项工作中如果没有搞清楚产品的技术细节 比如 软 硬件资源评估确定硬件采购需求 平 台性
9、能的评估 服务性能调优安全加固 根据应 用对服务器系统层的优化等等 将直接影响最 后运维工作的正常开展 从我看来 由于生产平台是企业的命脉所以运 维工作上没有最大的挑战只有不断地挑战 例如 平台上线后如果出现了瓶颈问题那么就需要快速 锁定问题排查瓶颈 在最快的时间解决 尤其对 于做互联网应用的企业 用户体验最重要 三天 两头出问题 用户就会流失 企业利益就会受损 2 沟通方面的挑战 一个合格的运维工程师 不但工作要做好 与本职工作职责在一条链上的 部门同事之间的沟通也至关重要 直接制约工作 的效率与结果 比如平台运行中遭遇问题 经过 排查也锁定了 但是之前与同事沟通不畅造成问 题解决滞后 这个
10、影响很大 当然很多企业非常重视产品上线后的问题响应 从人力上设定了绩效 从技术上利用内部工单来 配合解决 效果也是非常显著 不过制度始终是 需要去遵守的 是死的 工作的人是活的 所以 人与人之间的有效沟通也是非常重要的一项必修 课 这对于运维工作人员来说是挑战 处理不好 经常出现由于部门间工作性质不同带来的信息孤 岛和沟通鸿沟 3 最后一点 我希望将 Linux 高效运维 这项本领和更多的人分享 如何把最难理解的知 识通过最平凡易懂的方式教授给学生 这才是当 前工作的重中之重 51CTO 您现在关注哪些技术领域呢 您现在关注哪些技术领域呢 黄琨 就运维所关注的技术领域来说 我只想 用一句 多而
11、杂 来形容 因为运维是保证企业 业务平台稳定运行的基石 开发 测试 整个平 台架构中的缓存 应用 中间件 数据库 网络 方面数据传输效率 平台监控报警 硬件层面等 等方面 都需要了解 并且深入 根据我现在的工作性质 要不断关注最新的技 术 最重要的就是如何能够提高运维团队的工作 效率 以及组织学习兴趣小组总结运维工作中的 技术难点 达到不断提高的目的 毕竟运维技术 更新很快 但是学习资源相对比开发领域来说是 有差距的 51CTO 最后 能否大致谈谈您对于未来三年的 最后 能否大致谈谈您对于未来三年的 个人发展计划 个人发展计划 黄琨 其实技术和业务是分不开的 关注互联 网行业 3G 融合之后的
12、杀手级业务相关技术是我 的主攻目标 在这个范围内提高自己的技术 能 够为未来的发展提供一个很好的路线引导 未来 3 年我将继续做好 Linux 及其相关的开源 运维培训工作 在 IT 培训领域做出一番成绩 原文 本文有删节 投稿信箱 yangsai 2 交流 Interact 多数大规模Web 应用程序都使用 MySQL Memcached 架构 其中许多应用也同 时使用了NoSQL 数据库 也有一些人全部放弃 MySQL 转投NoSQL 的怀抱 NoSQL 数据库在处 理一些简单访问模式 如主键查找 时比 MySQL 的表现更好 而大多数Web 应用程序的查询都很 简单 因此这看上去是一个很
13、合理的决定 大 和许多其它大规模网站一样 我们 DeNA 多年 来都存在类似的问题 但最终我们全部使用了 MySQL 我们一如既往地使用 Memcached 作为前 端缓存 但没有使用Memcached 缓存数据行 我 们也没有使用NoSQL 因为我们从 MySQL 获得的 性能比其它NoSQL 产品更好 在我们的基准测试 中 我们在一台普通的MySQL InnoDB 5 1 服务 器上获得了750000 QPS 的成绩 在生产环境中 的性能更优秀 SQL 主键查询真得能很快吗 主键查询真得能很快吗 每秒你可以运行多少次主键查询 DeNA 的应 用程序需要执行大量的主键查询 如通过用户 id
14、获取用户信息 通过日记 id 获取日志信息等 Memcached 和 NoSQL 都能很好地适应这种需求 当你运行简单的多线程 memcached get 基准 测试时 每秒大约可以执行 400000 次 get 操作 即使 Memcached 客户端位于远程服务器上 当我 使用最新的 libmemcached 和 memcached 测试时 在一台 2 5GHz 8 核 Nehalem 处理器 四个 Broadcom 千兆以太网卡的服务器上 测试成绩 是每秒执行 420000 次 get 操作 MySQL 执行主键查询需要多长时间 通过基准 测试很容易找到答案 只需要从 sysbench s
15、uper smack 和 mysqlslap 等运行 并行查询即可 每秒有 100000 次查询似乎还不错 但却远远 低于 Memcached 的结果 MySQL 实际上做了些什 么 从 vmstat 输出可以看出 user 和 system 都很高 在 SQL 解析阶段调用了 MYSQLparse 和 MYSQLlex 在查询优化阶段调用了 make join statistics 和 JOIN optimize 这些都是 SQL 开销 很明 显 性能下降主要是由 SQL 层 而不是 InnoDB 存储 层造成的 MySQL 做了很多 Memcached NoSQL 不需要做的事情 如 3
16、投稿信箱 yangsai 我认为 MySQL 完全被 NoSQL 数据库社区低估了 MySQL 的历史悠久 我的前同事们也在不断改 进它 从 NDBAPI 可以看出 MySQL 有成为 NoSQL 的潜力 NoSQL 小故事 单服务器如何应付每秒 75 万次查询 文 Yoshinori Matsunobu 译 黄永兵 matsunobu host vmstat 1 r b swpd free buff cache in cs us sy id wa st 23 0 0 963004 224216 29937708 58242 163470 59 28 12 0 0 24 0 0 963312 224216 29937708 57725 164855 59 28 13 0 0 19 0 0 963232 224216 29937708 58127 164196 60 28 12 0 0 16 0 0 963260 224216 29937708 58021 165275 60 28 12 0 0 20 0 0 963308 224216 29937708 57865 165041 60
