Your SlideShare is downloading. ×
Linux运维趋势 第16期 cdn缓存系统
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Linux运维趋势 第16期 cdn缓存系统

9,597
views

Published on

本期目录: …

本期目录:

003 Theo Schlossnagle谈监控,统计学与运维的本质 via 51CTO
007 服务器虚拟化:如何选择合适的模式? via 51CTO
009 Hash冲突漏洞需修补 12306.cn引热议 via 51CTO
011 web网站加速之CDN技术原理 via 北方人(@戒日祭)
014 大型网站后台架构的web server与缓存 via 凤凰舞者
016 Squid常用命令总结 via @NetSeek_linuxtone
018 [CDN]动态内容的缓存技术 CSI,SSI,ESI via 扶凯
019 squid/varnish/ats简单测试 via 三斗室
020 使用Nginx代替squid充当代理缓存服务器 via @晓辉201010
023 MySQL性能优化教程之MySQL运维优化 via @caoz
026 建设一个靠谱的火车票网上订购系统 via @林玥煜、邓侃(@邓侃)
029 红帽虚拟桌面SPICE服务概述与安装指南 via 曹江华
031 为什么要尽量避免重启你的Unix服务器 via 51CTO

《Linux运维趋势》是由 51CTO 系统频道策划、针对 Linux/Unix 系统运维人员的一份电子杂志,内容从基础的技巧心得、实际操作案例到中、高端的运维技术趋势与理念等均有覆盖。

本杂志长期处于探索期,需要更多来自大家的意见与参与。谢谢!

微群讨论:http://q.weibo.com/121303
邮件订阅入口:http://os.51cto.com/art/201011/233915.htm
投稿信箱:yangsai@51cto.com
发布周期:每个月的第二个星期五
往期《Linux运维趋势》下载汇总页:http://down.51cto.com/zt/71

Published in: Technology

0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
9,597
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
55
Comments
0
Likes
8
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 目录杂志订阅 : http://os.51cto.com/art/201011/233915.htm Index《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 目录 人物·People 技巧·工具·脚本·DBA 003 Theo Schlossnagle谈监控,统计学与运维的本质 023 MySQL性能优化教程之MySQL运维优化 交流·Interact 026 建设一个靠谱的火车票网上订购系统 007 服务器虚拟化:如何选择合适的模式? 029 红帽虚拟桌面SPICE服务概述与安装指南 八卦·News 031 为什么要尽量避免重启你的Unix服务器 009 Hash冲突漏洞需修补 12306.cn引热议 专题·Special 011 web网站加速之CDN技术原理 014 大型网站后台架构的web server与缓存 016 Squid常用命令总结 018 [CDN]动态内容的缓存技术 CSI,SSI,ESI 出版方 : 51CTO 系统频道(北京无忧创想信息技术有限公司) 019 squid/varnish/ats简单测试 杂志主编 : 杨赛 020 使用Nginx代替squid充当代理缓存服务器 联系方法 : yangsai@51cto.com 010-68476606(分机 8035) 出版日期 : 2012 年 1 月 13 日 每月第 2 个星期五出版 订阅 : http://os.51cto.com/art/201011/233915.htm 002 51CTO 系统频道 : http://os.51cto.com
  • 2. 人物杂志订阅 : http://os.51cto.com/art/201011/233915.htm People《Linux 运维趋势》投稿信箱 : yangsai@51cto.comTheo Schlossnagle谈监控,统计学与运维的本质 采访整理/lazycai Theo Schlossnagle 是 OmniTI 的创始人和首脑,为高流量网站和其他 需要可靠、可扩展架构工程的客户设计和实施解决方案。他是高可扩展 的 Momentum MTA 架构师,Fontdeck CDN 的架构师,Circonus SaaS 监 控平台背后的导师。Theo 参与很多开源社区,包括 OpenSolaris,Linux, Apache,PostgreSQL, 等等。他是可扩展系统和分布式系统方面的作家, perl 也是开源会议上的资深讲师。 51CTO 在 2011 年底的 Velocity 大会上对 Theo 进行了专访,探讨了运维 工程师成长方面的问题。 51CTO : 您在有关监控的课程中讲了很多统计学的内容。您认为 DBA 和 运维们需要了解这些知识吗? Theo : 我认为对于工程师而言,了解基础程度的统计学是一项基本要求。 因为我们每天都在关注系统的各项数据 : 硬盘是不是慢了?网络是不是慢 了?我们将“太慢”这个概念量化成具体的数值,从而理解这个系统。如果 我们每天看这些数字,而没有统计学的基本知识,那就说不上真正理解这些 数字。 51CTO : 像是 Nagios 和 Cacti 这样的工具目前做到这一点了吗? Theo : 算不上吧。Nagios 做的仅限于提供一些数字——目前大部分系统 都是这样做的,它们被设计隔一段时间做一次检查,比如每隔一分钟做点什 003 51CTO 系统频道 : http://os.51cto.com
  • 3. 人物杂志订阅 : http://os.51cto.com/art/201011/233915.htm People《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 么 动 作, 回 一 个 数 字。 而 现 实 中, 返 我 51CTO : 运维工程师的工作,一直以来 们面对的很多行为,好比硬盘读写的行 “以前你可能花6个小时在分发、打包、部署、 都无非是部署、监控、安全、备份、排障、 为,它往往在每一秒内会执行成百上千 备份上面,而现在你可能只需要1个小时了。” 调优这些。您认为这方面的工作在未来 次,所以如果我们能够仔细研究每一次 会有变化吗? 读写的实际行为,通过这样对硬盘读写 的理解,肯定要远远超过只是取一个每分钟的平均数。你想要了解最高值 是什么,最低值是什么,你想要了解一个分布的情况,98% 或者 99% 的读 写速度在一个什么值,如此这般。这个我认为是我们需要的。 Cacti 相对好一些,它目前提供了一些基本的统计功能,你可以查看数据 的标准偏差,但是其他的相关数据还很有限。 51CTO : 那么你们在 OmniTI 用的监控系统,是完全自己写的,不是通过其 他监控系统修改的是吗? Theo : 是的,我们完全自己写的整个监控系统。这个系统是开源的,而且 监控数据写入数据库,你可以直接用来做统计分析,或者像很多专业数据分 析人士做得一样,将数据抽取出来,放到比如 R 这样专业的统计工具当中 去。用 R 来做统计相对高阶一些,但是很多时候我们通过借助手册的帮助, 也可以很容易的做一些基本的分析。 比如你在网站上放了 JavaScript 监控代码,它能够返回每次页面加载花 费的时间。假设它放在那里跑了一天之后,收集到 1 亿次用户点击,也就是 Theo : 我认为这些工作不会有太大的变化,只不过是有些工作变得越来 1 亿个 PV。你想知道的情况是,页面加载的速度如何。如果给你一个 1 亿 越简单了。备份数据,部署新的系统,我觉得这些方面的技术已经越来越好, 次页面加载时间的平均数,这个肯定是没啥用的 ; 你想知道的是分布的情 越来越容易做。咱们每天工作按 8 小时来算,以前你可能花 6 个小时在分发、 况,有多少次访问在 1 秒,有多少次访问在 10 秒,等等。这样就会收集到很 打包、部署、备份这些工作上面,而现在你可能只需要 1 个小时了。这样下 多数据点,你需要一个视图的方式明白的呈现出来这些数据代表了什么意 来,你就有更多时间考虑性能优化、资源规划这些事情——你以前在这些事 思,那么这时候就可以用 R 语言。当然做这个也有其他的工具,但是 R 是最 情上可能只有 1 小时的时间,但它实际上值得你花每天 8 小时。 简单、最便宜的。 004 51CTO 系统频道 : http://os.51cto.com
  • 4. 人物杂志订阅 : http://os.51cto.com/art/201011/233915.htm People《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 51CTO : 那您认为运维工程师这样的 让 首 页 显 示 老 的 数 据” 最 后 一 个 SA 。 技术人员应该多花时间去了解业务吗? “所以我觉得很多时候,是人们之间没有沟通 实在受不了了,问道 : 显示最新数据的 “ Theo : 当然需要了。当然, 哦, 他们不 清楚。” 商 业 理 由 究 竟 是 什 么? 难 道 1 秒 之 前 的数据都不行吗? 客户反馈说 : 这个 ” “ 需要了解所有的业务 ; 不过他们至少需 啊, 秒钟当然是可以的啦。 所以最后, 1 ” 要知道,自己管理的这些机器为什么在运转?我自己见过这样的事情 : 有 60 台机器优化成了一台。 一个系统在运行了好几年之后,才发现这个系统早就没有人在用了。那是 一个数据仓库的业务。最开始你有一个数据库,以及一个数据仓库。后来, 所以我觉得很多时候,是人们之间没有沟通清楚。我们没有真正明白, 又启动了一个新的数据仓库。所有用户从旧的数据仓库迁移到了一个新的 究竟为什么要跑这个应用软件。客户丢过来一个问题,我们就埋头解决这 数据仓库,但是居然没有任何人通知系统管理员!所以旧的系统还一直在 个问题,启动机器,然后看到没人抱怨,我们就当作没问题了——这其中其 跑着,磁盘阵列跑着,耗费着电力,还有一堆之前设计的自动化脚本在运转。 实是很有问题的。 系统管理员一直也没去看这个系统,以为还有人在用 ; 而业务方面的人则 对于运维这个领域我一直是这样理解的 : (Operations)的本质是让 运维 没有一个想起来要把旧的系统关掉。 业务跑起来,而不是让系统或是一堆计算机跑起来,所以身为运维,必须要 去了解业务。如果他们不去了解业务,那么他们就不会明白如何让业务最 51CTO : 难道系统管理员不会觉得奇怪吗?比如发现一直没有用户请求之 优化的运行。在现实中,整个需求的传递往往是一条长链 : 业务需求传递 类的。 给产品经理,产品经理传递给软件工程师,软件工程师再传递给系统管理 Theo : 这个系统很久以前就没有用户提需求的, 哦, 因为都完全自动化 员……而到了这里,可能我们早就不知道真实的需求到底是什么了。我认 了。在一个数据仓库系统里面处理的任务可能是将每天的销售数据打包存 为就是应该将最原始的需求拿出来,大家在一起讨论比较好。 档,发邮件到某人的邮箱里面去。换了新系统之后,可能由于某种原因,也一直没人去检查那个旧的邮箱,所以就这么一直跑着了。 51CTO : 您的意思是我们要尽量减少这些中间人的存在吗?让用户的需求 直接传达给实际干活儿的人? 还有另外一种情况,比如带宽的使用。你购买了一定的带宽,但实际上 未必需要用到那么多,不少企业对于这其中的成本浪费并不是特别明白。 Theo : 我认为这是一个平衡的问题。在优秀的公司当中,整个链条是存 在的,我们有产品经理,有专注交互的,有专注界面的,还有底层这些。我想 还有另一个例子 : 我们有一个客户,他们的首页一开始不用缓存,因为页 说的是,从一开始,我们就需要来自软件工程师、系统管理员和 DBA 们的参 面是动态显示数据的,客户说必须要让页面随时显示最新的数据,比如最热 与,让他们参与“定义问题”的过程。大家聚在一个屋子里面各抒己见,才 卖的产品之类的。因为客户坚持不用缓存,最初我们在架构设计中只好为 能够更好的理解各自的观点。 这个首页安排了 60 台机器。每次在软件工程师提出要为页面做缓存的时 候,客户就大摇其头的否决 : 不行不行, “ 我们必须要显示最新的数据,不能 005 51CTO 系统频道 : http://os.51cto.com
  • 5. 人物杂志订阅 : http://os.51cto.com/art/201011/233915.htm People《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 51CTO : 您在早上提到了运维的职业 51CTO : 那你们现在也会通过社交网 发展需要向“多面化”的方向走,那您认 “他们了解如何从不同的角度思考,而且会在 络等方式来寻找这样的人吗? 为以后这个领域仍然会按照系统管理 凌晨3点起来排障。” Theo : 实话说吧,在招聘方面我们算 员、运维、DBA 这些职业进行划分吗? 不上多成功。我们的员工都非常的优 Theo : 职业细分这方面肯定还是不会变的。你很难在每个方面都成 哦, 秀,但是我们招聘的速度实在是跟不上需求。 为专家的。所谓多面化的意思是这样的 : 在规模很大的公司里,尤其是在对 社交网络方面,我们主要关注代码社区,比如 Github ; 传统的 Job List 方 性能优化非常关注的互联网公司,比如淘宝这样为这么多用户提供服务的 法也在用,招聘网站什么的。反正是什么方法都用呗。 网站,他们遇到的问题都是很难解决的问题,他们会需要对各方面都熟悉的 人才。因为在一屋子的人都是较窄领域的专家的时候,他们很难去“越界” 51CTO : 最后一个问题。随着云计算的发展,人们预测外包业务将会越来 的处理问题,因为缺乏在其他领域的能力。好比你遇到一个数据库的问题, 越多。这种情况下,您认为系统运维的就业环境是否会变得越来越局限?而这个问题如果你对数据库下面的操作系统有一定了解的话,可能会很容易就发现问题所在了。 Theo : 这个我倒不完全这么认为。现在很多用云计算服务的主要还是小 企业,他们的需求也就在 50 台到 100 台机器上下,在内部系统方面,肯定 IT 51CTO : 那好比 OmniTI 招聘的话,你会期待一个什么样的工程师? 管理员是会减少的,因为像是搭建 Exchange 邮件服务或是配置电话交换机 这种工作,放在哪个公司都差不多,外包在这个方向更有优势 ; 但是网站和 Theo : 这个问题真难……我们的话,首先会要求对方有很好的分析能力, Web 应用就不一样了,每一家网站的业务都是不一样的,有定制,有优化,不能够按照严格的科学方法去发现问题,然后解决问题。你知道,有太多的人 太可能交给外包就能直接搞定。你搞电子商务的,把网站外包出去运营能会在还没了解问题的时候就急急忙忙的跑去解决问题。我面试过的很多人, 行吗?我觉得是不行的,因为这样你就失去了你的差异竞争力。他们之所以没有拿到这份工作正是因为这个原因。我会问他们一个问题,比如“我们的网站很慢。你要怎么做? 而他们没有提出足够多的问题, ” 而 所以我觉得以后会是这样 : Exchange 这样的同质化服务会趋向于外包 ; 是直接开始说“我会这样这样做”等等。他们根本连问题是什么样子的都 小规模的网站会采用相对通用的云服务而不专门聘请一个 SA ; 而对于有一 没搞明白。而相比之下,那些更善于挖掘问题的应聘者——他们往往是相 定规模的网站,即使他们的业务是托管在云平台上运行的,他们也仍会需要 对不那么聪明的一群人——往往能够给出更好的答案。 一些了解企业业务的 SA——他们了解如何从不同的角度思考,而且会在凌 晨 3 点起来排障。他们可能会跟软件工程师这个岗位融合,但不管职位叫 这是方法方面。第二就是,这个人必须愿意学习。这样的人真的非常难 什么,这些网站仍然需要这样一批人。 找! 51CTO : 好的,十分感谢您接受我们的采访!本次访谈到此结束。 原文 : http://os.51cto.com/art/201112/306406.htm 006 51CTO 系统频道 : http://os.51cto.com
  • 6. 交流杂志订阅 : http://os.51cto.com/art/201011/233915.htm Interact《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 服务器虚拟化:如何选择合适的模式? 文/Trevor Pott 编译/核子可乐 直连式虚拟化与分布式虚拟化,二者的冲突给意识形态带来了新的战 所能得到的上限速度仅为 900MBps,而我自己的 SSD RAID 10 也只能带来 场。 2200MBps 的实际表现。不过 2200MBps 已经远胜 900MBps,这样的存储速 度优势已经极具价值。如果大家愿意为某台指定的虚拟机搭配多套虚拟网 直连式虚拟化比较简单,就是一台服务器,配备着托管数套虚拟机的本 卡,那么速度还将进一步提升。 地存储。它们利用由管理程序提供的 vSwitch 进行互相通信,而无需将数 据包经过网卡发送至网络的每个角落。 困境 讨论 当将分布式的非主机设备引入余下的网络中时,这些虚拟机就要争夺有 限的带宽。如果我们有三十套虚拟机系统,那么为它们各自配备 10Gb 带宽, 通常情况下,托管在直连方案中的虚拟机能够与处于主机系统之外的服 与只拿出一块 10Gb 带宽的网卡让它们共用、由物理交换机负责网络处理是务器及客户机进行沟通,但大部分交 完全不同的感觉。流仍然发生在同一套系统中的虚拟机 “如果大家愿意为某台指定的虚拟机搭配多套之间。 如 果 仅 从 目 前 提 出 的 数 字 出 发, 么 那 虚拟网卡,那么速度还将进一步提升。” 分布式虚拟化看起来简直就是疯狂而不 分布式虚拟化则完全不同。主机 可理喻的。但它仍然具备独特的优势。服务器被尽可能当作一套整体的一次性处理单元。存储资源采用集中式管理方案,并通过 SAN 中虚拟机与物理 直连式虚拟化所无法实现的就是从一台主机上的虚拟机中迅速迁移至交换机之间的通信被提供给多台主机。 另一台。虚拟机本身可能就体积庞大,因此通过网络实施迁移会耗费大量 时间。 每种模式都有各种的局限性。 但分布式虚拟化采用了集中式存储模式,不会遇到这个问题。不仅如此, 直连式虚拟化速度快。每块 10Gb 网卡(目前 SAN 的标准接口)在理论 分布式虚拟化还允许我们对不同主机上处于运行状态的虚拟机系统进行实上可以提供最大 1280MBps 的传输速度。而目前相当普遍的 PCIe 8x 2.0 时迁移。RAID 卡理论上的传输速度更高达 4000MBps。 高度的可用性是分布式虚拟化的另一大重要卖点。 不过用在实际工作中就没那么乐观了。我在 10Gb 网 络附加存储系统上 007 51CTO 系统频道 : http://os.51cto.com
  • 7. 交流杂志订阅 : http://os.51cto.com/art/201011/233915.htm Interact《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 直连式虚拟化依靠强劲且具备高度 存储的作法也开始出现。我最近就完 容错性的虚拟主机来实现优秀的可用 “VEPA网卡自身所具备的能力足以被称为交 成了一套部署,其中每台主机都拥有大 性。分布式虚拟化则会在一台主机出 换机。” 量本地存储以辅助备份工作。 现故障并重启时将所有虚拟机在集群 每台主机都拥有一套虚拟备份设备 中的其它主机上加以运行。使用的主机越多,分布式模式的优势就越明显。 (简称 VBA) 其作用是为分配给该主机的虚拟机进行基于镜像的备份, , 并将 分布式虚拟化的另一大优势是,尽管在传输速度上有所限制,但强制将 镜像存储于本地缓冲驱动器中。这增加了备份速度。 所有流量通过物理交换机处理使得网络管理具备更强的直观性及可管理 中央 VBA 会从每台主机上读取备份内容,并不断将其转写至磁带上。磁 性。 带驱动器被直接从主机映射到 VBA 上,而不是作为从网络接入的设备。 设计概念 这种混合式处理方案尚未见诸白皮书,不过它的工作状态相当令人赞 大家可以根据自己的需要选择合适的模式并加以部署,但这似乎还不能 赏,只要再稍加改进,我一定会在未来的部署工作中再次加以使用。 完全令人满意。基于创新的思维方式,混合虚拟化模式开始出现。 进步无止境 新 一 代 网 卡 已 经 开 始 模 糊 二 者 之 间 的 界 线, 中 至 关 重 要 的 一 环 是 其 新技术组合的不断引入使得任何一套虚拟化模式都无法长久保持不变。 802.1Qbg 这 样 的 标 准(也 被 称 为 边 缘 虚 拟 桥) 或 虚 拟 以 太 网 端 口 聚 合 , 目前最新的好方案是 IOMMU,它承诺为单独的虚拟机系统提供直接访问系(VEPA)。 统设备(例如显卡)的能力。 VEPA 网卡自身所具备的能力足以被称为交换机。在使用中,主机上的 虚拟机将有能力充分发挥 GPGPU 计算带来的强大性能,而处理速度的提虚拟机绕过虚拟交换机,直接与网卡中集成的交换机对话。而网卡则能够 升也会要求数据输入量达到光线通道传输能力的级别,这是分布式技术所 与管理软件直接对话,这样一来我们就既拥有了分布式网络带来的种种优 无法满足的。硬件容错能力的提高使单台主机方案更具可靠性,而新的网 势,又不必担心由于所有虚拟机流量都被发往物理交换机而引起传输速度 络技术则将带宽扩大至 40Gb、100Gb 甚至更高。 瓶颈。 到这里我们又说回起点。虚拟化始于大型机,而虚拟化又推动了 x86 在 另一方面,802.1Qbh(也被称为桥口扩展或者 VN 标签)几乎完全是由 采纳新技术的道路上渐行渐远,这使得台式机与大型机的运作方式越来越 思科公司一手打造,它的使用需要对当前以太网规范加以延伸,即采用很多 接近。 新的硬件。 原文 : Server virtualisation: How to pick the right model 这与 VEPA 形成了鲜明的对比,因为 VEPA 并不需要我们更新网络设备。 译文 : http://server.51cto.com/sCollege-306706.htm 在同一台主机上通过差异化配置来实现同时使用直连式存储与分布式 008 51CTO 系统频道 : http://os.51cto.com
  • 8. 八卦杂志订阅 : http://os.51cto.com/art/201011/233915.htm News《Linux 运维趋势》投稿信箱 : yangsai@51cto.com Hash冲突漏洞需修补 12306.cn引热议 ——八卦,新闻与数字 2011.12 - 2012.01 Nginx 的市场份额已经从今年年初的 5.9% 增长到了 10%,成为增长最 Linux 内核 3.2 正式版发布,改进了 EXT4 和 BTRFS 文件系统,改善延 快的 Web 服务器。目前 Apache 仍占主导地位。 迟的 TCP 包恢复算法,增加了 CPU 带宽控制,允许存储空间过度配置。下 载地址 : http://os.51cto.com/art/201112/310103.htm http://www.kernel.org/pub/linux/kernel/v3.0/ Linux Deepin 11.12 发布,使用了 Gnone Shell 作为默认桌面环境,并在 此基础上做了大量细节改进。 Fedora 工 程 筹 划 委 员 会 (FESCo) 近 日 举 行 会 议, 发 人 员 们 批 准 了 开 Beefy Miracle Fedora 17 即将加入的几项关键新特性,包含 GNOME 3.4 和 http://os.51cto.com/art/201112/310727.htm OpenStack 等。 当前包括 PHP、Java、Ruby 在内的很多语言版本存在漏洞,攻击者可以通 http://os.51cto.com/art/201201/312305.htm 过构造 Hash 冲突实现拒绝服务攻击。各语言的漏洞补丁已陆续放出,请抓 紧修补。 2012 年是阿兰·图灵诞生后的一百周年。为了纪念这位伟大的科学家, Scaruffi.com 的 创 始 人 Piero Scaruffi 在 最 近 分 享 了 一 个 83 页 的 幻 灯 片 : http://os.51cto.com/art/201112/310756.htm Alan Turing and the Programmable Universe,对阿兰·图灵的故事进行了 12306.cn : 这事儿聊的很多了,好文层出不穷 : 很精彩的解读。51CTO 特将这份幻灯片翻译过来,跟大家分享。 http://os.51cto.com/art/201201/311396.htm http://os.51cto.com/art/201201/312017.htm http://bbs.hpx-party.org/thread-8488-1-1.html http://hi.baidu.com/caoz/blog/item/f4f1d7caee09b558f21fe780.html 【致歉声明】 除了技术分析和针对招标、运量的分析之外,甚至还有往 SNS 方向拓展 15 期《虚拟化管理软件比较 -- 综合篇》一文的作者为蒋清野, 的思路 : 刊中误打印成了“蒋清扬” 特此勘误, , 并向蒋清野先生致歉! http://blog.codingnow.com/2012/01/12306_sns.html 蒋清野的博客 : http://www.qyjohn.net/ 发现问题比没发现好,有争论比没人谈论好,在有机会讨论的时候多讨 蒋清野的微博 : http://weibo.com/qyjohn 论,才能在明年更容易拿到回家的火车票。 009 51CTO 系统频道 : http://os.51cto.com
  • 9. 专题杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special《Linux 运维趋势》投稿信箱 : yangsai@51cto.com CDN服务缓存系统的选型与技巧 “当 YouTube 出现在世人面前的时候,人们为互联网的又一次革命而叫 好,而与此同时,人们看到了在 YouTube 后面的一个强大的 CDN 支持,是这 个 CDN 网络把 YouTube 的无数视频展现在人们面前,在这个时候,人们发 现 CDN 是不可或缺的,CDN 在经历了那么长时间的默默无闻以后,突然一 夜间闻达于诸侯,就象君士坦丁大帝把天主教定为国教一样,大家突然认识 到了一个不为人熟知的领域。但我们看到的是什么呢?君士坦丁介绍给罗 马的天主教是耶稣创立时的教义么?我们所看到的 CDN 是 MIT 创立时的 CDN 么? 人们开始搜索 CDN,研究 CDN,发现 CDN 是那么的简单,可以用一页 PPT 就把原理讲的清清楚楚,而网络硬件的厂商也会这样和互联网的客户说,我 们可以提供完整的 CDN 解决方案,你不需要做什么,买我们的硬件,它已经 能够解决你所有的 CDN 问题。 从此,CDN 变成了一个流行词汇,尤其是在高盛领投 LimeLight(全球第 二大 CDN 公司) 1.2 亿美金之后,突然之间,世界各地都出现了大大小小 的 CDN 公司,无数的投资蜂拥而至,就像那时的罗马,人人都开始信仰天主 教,也许是真的信仰,也许是为了圣餐,也许是为了研究,总之, “我们都爱 CDN”。 也许有人问 : 我们谈论的是同一个 CDN 么,或者我们谈论的不是 CDN ?” —— via《看上去很美——国内 CDN 现状与美国对比》 by 阀域 010 51CTO 系统频道 : http://os.51cto.com
  • 10. 专题杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special《Linux 运维趋势》投稿信箱 : yangsai@51cto.com web网站加速之CDN技术原理 文/北方人(@戒日祭) 在不同地域的用户访问网站的响应速度存在差异,为了提高用户访问的 过在现有的 Internet 中增加一层新的 CACHE( 缓存 ) 层,将网站的内容发布 响应速度、优化现有 Internet 中信息的流动,需要在用户和服务器间加入中 到最接近用户的网络 " 边缘 " 的节点,使用户可以就近取得所需的内容,提 间层 CDN,使用户能以最快的速度,从最接近用户的地方获得所需的信息, 高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访 彻底解决网络拥塞,提高响应速度,是目前大型网站使用的流行的应用方 问量大、网点分布不均等原因,提高用户访问网站的响应速度。 案。 Cache 层的技术,消除数据峰值访问造成的结点设备阻塞。Cache 服务 1. CDN 概述 器具有缓存功能,所以大部分网页对象(Web page object) 如 html, htm, , php 等页面文件,gif,tif,png,bmp 等图片文件,以及其他格式的文件,在有 CDN 的全称是 Content Delivery Network,即内容分发网络。其目的是通 效期(TTL)内,对于重复的访问,不必从原始网站重新传送文件实体 , 只 需通过简单的认证(Freshness Validation) 传送几十字节的 Header, - 即可 将本地的副本直接传送给访问者。由于缓存服务器通常部署在靠近用户端, 所以能获得近似局域网的响应速度,并有效减少广域带宽的消耗。不仅能 提高响应速度,节约带宽,对于加速 Web 服务器,有效减轻源服务器的负载 是非常有效的。 根据加速对象不同,分为 客户端加速 和 服务器加速 客户端加速 : Cache 部署在网络出口处,把常访问的内容缓存在本地, 提高响应速度和节约带宽 ; 服务器加速 : Cache 部署在服务器前端,作为 Web 服务器的代理缓存 机,提高 Web 服务器的性能,加速访问速度 如果多台 Cache 加速服务器且分布在不同地域,需要通过有效地机制管 理 Cache 网络,引导用户就近访问 ( 比如通过 DNS 引导用户 ),全局负载均 011 51CTO 系统频道 : http://os.51cto.com
  • 11. 专题杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 衡流量,这是 CDN 内容传输网络的基本思想。 LocalDNS 得到域名的授权 DNS 记录后 , 继续向域名授权 DNS 查询域名 的 ip 地址 CDN 对网络的优化作用主要体现在如下几个方面  - 解决服务器端的“第一公里”问题  - 缓解甚至消除了不同运营商之间互联的瓶颈造成 域名授权 DNS 查询域名记录后,回应给 LocalDNS 的影响  - 减轻了各省的出口带宽压力  - 缓解了骨干网的压力  - LocalDNS 将得到的域名 ip 地址,回应给 用户端 优化了网上热点内容的分布 用户得到域名 ip 地址后,访问站点服务器 2. CDN 的工作原理 站点服务器应答请求,将内容返回给客户端 . 2.1. 传统访问过程(未加速缓存服务) 2.2. CDN访问过程(使用缓存服务) 我们先看传统的未加缓存服务的访问过程,以便了解 CDN 缓存访问方式与未加缓存访问方式的差别 : CDN 网络是在用户和服务器之间增加 Cache 层,主要是通过接管 DNS 实 现 , 将用户的请求引导到 Cache 上获得源服务器的数据 下面让我们看看访问使用 CDN 缓存后的网站的过程 : 由上图可见,用户访问未使用 CDN 缓存网站的过程为 : 用户输入访问的域名 , 操作系统向 LocalDNS 查询域名的 ip 地址 . LocalDNS 向 ROOT DNS 查询域名的授权服务器 ( 这里假设 LocalDNS 通过上图,我们可以了解到,使用了 CDN 缓存后的网站的访问过程变为 :缓存过期 ) 用户输入访问的域名 , 操作系统向 LocalDNS 查询域名的 ip 地址 . ROOT DNS 将域名授权 DNS 记录回应给 LocalDNS LocalDNS 向 ROOT DNS 查询域名的授权服务器 ( 这里假设 LocalDNS 012 51CTO 系统频道 : http://os.51cto.com
  • 12. 专题杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 缓存过期 ) 由于它离用户更近,因而响应时间必然更快 . ROOT DNS 将域名授权 DNS 记录回应给 LocalDNS 从上面图中 虚线圈起来的那块,就是 CDN 层 , 这层是位于 用户端 和 站点服务器之间 . LocalDNS 得到域名的授权 DNS 记录后 , 继续向域名授权 DNS 查询域名 的 ip 地址 智能调度 DNS( 比如 f5 的 3DNS) 域名授权 DNS 查询域名记录后 ( 一般是 CNAME),回应给 LocalDNS 智能调度 DNS 是 CDN 服务中的关键系统 . 当用户访问加入 CDN 服务的 网站时,域名解析请求将最终由 智能调度 DNS 负责处理 . LocalDNS 得到域名记录后 , 向智能调度 DNS 查询域名的 ip 地址 它通过一组预先定义好的策略,将当时最接近用户的节点地址提供给用 智能调度 DNS 根据一定的算法和策略 ( 比如静态拓扑,容量等 ), 将最 户,使用户可以得到快速的服务 . 适合的 CDN 节点 ip 地址回应给 LocalDNS 同时它需要与分布在各地的 CDN 节点保持通信,跟踪各节点的健康状 LocalDNS 将得到的域名 ip 地址,回应给 用户端 态 , 容量等,确保将用户的请求分配到就近可用的节点上 . 用户得到域名 ip 地址后,访问站点服务器 缓存功能服务 CDN 节点服务器应答请求,将内容返回给客户端 .( 缓存服务器一方面 负载均衡设备 ( 如 lvs,F5 的 BIG/IP) 在本地进行保存,以备以后使用,二方面把获取的数据返回给客户端,完成 数据服务过程 ) 内容 Cache 服务器 ( 如 squid) 通过以上的分析我们可以得到,为了实现对普通用户透明 ( 使用缓存后 共享存储 ( 根据缓存数据量多少决定是否需要 ) 用户客户端无需进行任何设置 ) 访问,需要使用 DNS( 域名解析 ) 来引导 3. CDN 智能调度DNS 实例分析(略,见原文) 用户来访问 Cache 服务器,以实现透明的加速服务 . 由于用户访问网站的 第一步就是 域名解析 , 所以通过修改 DNS 来引导用户访问是最简单有效 4. CDN的 智能调度DNS 简化实现(略,见原文) 的方式 . 5. 总结(Summary) 2.3. CDN网络的组成要素 在建立 CDN 网路时,最关键的就是 智能调度 DNS,这个是 CDN 网络总 对于普通的 Internet 用户,每个 CDN 节点就相当于一个放置在它周围的 协调 , 通过高效的调度算法,可以使用户得到最佳的访问体验 . 网站服务器 . 其次就是 CDN 节点的管理 , 比如涉及到 内容的同步机制,配置文件的 通过对 DNS 的接管,用户的请求被透明地指向离他最近的节点,节点中 更新等等,都需要有一套机制来保证 . CDN 服务器会像网站的原始服务器一样,响应用户的请求 . 原文 : http://www.51know.info/system_performance/cdn/cdn.html 013 51CTO 系统频道 : http://os.51cto.com
  • 13. 专题杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 大型网站后台架构的web server与缓存 文/凤凰舞者 计算机系统中,缓存有很多种。比如 CPU 内部的一级缓存、二级缓存。 (object)。 文件系统的缓存,磁盘的缓存。在大型网站的后台部署过程中,也灵活运用 (2)squid 通过查询表的方式来定位某个资源的位置。所查询的表有两 了各级缓存。主要有客户端的浏览器缓存,服务器端的 web server 自身缓 种,一种是 Hash table,一种是 Digest table。Hash table 记录着所有 Digest 存,代理缓存,分布式缓存,数据库自身的缓存等。本节主要分析一下代理 table 表信息,所以 Hash table 可以称之为目录或者提纲。而 Digest table 记 缓存。 录了磁盘上每个分区、每个目录里存放的缓存摘要,所以 Digest table 可以 代理缓存 称之为摘要或者索引。所以,Squid 接到请求后先查询 Hashtable,根据 Hash table 所指向的 Digest table,再查询所需要的文件。 在网站后台架构中,代理缓存主要部署在 web server 之上,当用户对网 站后台发起连接请求时,用户请求先到代理缓存中去查找,如果命中,则将 (3)squid 服务器存在两种工作关系,一种为 Child-Parent, child squid 当 请求返回给用户,如果没有命中,则代理缓存将请求发到 web server,然后 server 没有用户需要的数据时,就向 parent squid server 发送请求,并持续 web sever 将请求复制一份到代理缓存中,同时把请求返回给客户。 等 待, 到 parent squid server 回 应 为 止 ; 一 种 为 Sibling, 本 地 squid 直 另 当 server 没有用户请求的数据时,会向 sibling server 发送请求,如果 sibling 常用的代理缓存有 varnish 和 squid。 server 没有资料则会向上级 sibling 或者 internet 发送数据请求。 Squid 所以,综上所述,squid 运行模式如下 : Squid 是一个高性能的代理缓存服务器,可以用来加快浏览网页的速度, 当 Squid Server 没有资料时,先向 Sibling 的 Squid Server 查询数据,如 提高客户机的访问命中率。Squid 不仅支持 HTTP 协议,还支持 FTP、SSL、 果 Sibling 没有,则跳过它直接向 Parent 查询,直到 Parent 提供资料为止 ( 如 WAIS 等协议。Squid 用一个单独的、非模块化的、 驱动的进程来处理所 I/O 果 Parent 没有资料,则到后端的 web server 上获取,当获取到数据后返回 有的客户端请求。 给用户的同时,保留一份在自身的缓存中 )。如果不存在 Parent, Squid 则 Squid 的原理如下 : Server 自身到后端的 web server 上获取数据,当获取到数据后返回给用户 (1) 每一台 squid 代理服务器上存有若干个颗磁盘。每颗磁盘又分割 的同时,保留一份在自身的缓存中。如果还是不能得到数据,则向用户端回 成 多 个 分 区, 一 个 分 区 又 可 建 立 很 多 目 录, 录 下 存 放 着 具 体 的 文 件 每 目 复不能得到数据。 014 51CTO 系统频道 : http://os.51cto.com
  • 14. 专题杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special《Linux 运维趋势》投稿信箱 : yangsai@51cto.com Varnish 主进程 fork 子进程,主进程等待子进程的信号,子进程退出后,主进程重 新启动子进程,子进程生成若干线程 : Varnish 是一款高性能的开源 HTTP 加速器,挪威最大的在线报纸 Verdens Gang 使用 3 台 Varnish 代替了原来的 12 台 Squid,性能比以前更好。 (1)Accept 线程 : 接受请求,将请求挂在 overflow 队列上。 Varnish 的作者 Poul-Henning Kamp 是 FreeBSD 内核开发者之一,他认为 (2)Work 线程 : 有多个,负责从 overflow 队列上摘除请求,对请求进行处 现在的计算机比起 1975 年已经复杂很多。在 1975 年时,存储媒介只有两 理,直到完成,然后处理下一个请求。 种: 内存与硬盘。但现在计算机系统的内存除了主存外,还包括了 CPU 内 (3)Epoll 线程 : 一个请求处理称为一个 session, session 周期内, 在 处理 的 L1L2L3 等 cache。因此 Squid Cache 自行处理物件替换的架构不可 完请求后,会交给 Epoll 处理,监听是否还在事件发生。 能得知这些情况而做到最佳化,但操作系统可以。所以这部分的工作应该 交给操作系统处理,这就是 Varnish cache 设计架构 [4]。Varnish 将所有的 (4)Expire 线程 : 对于缓存的 object,根据过期时间,组织成二叉堆,该线 HTTP object 存于一个单独的大文件中,该文件在工作进程初始化的时候, 程周期检查该堆得根,处理过期的文件。对过期的数据进行删除或重取操 将其整个映射到内存中。这样 Varnish 在该块内存中实现一个简单的文件 作。 系统,具有分配、释放、修剪、 合并内存等功能。 Varnish 分配缓存机制 : Varnish 文件缓存的工作流程 : 根据所读到的 object 大小,创建相应大小的缓存文件。为了读写方便, Varnish 与 一 般 服 务 器 软 件 类 似, 为 master 进 程 和 child 进 程。 其 中 分 程序将每个 object 的大小,转变为最接近其大小的内存页面倍数。然后从 master 进程负责管理,child 进程负责 cache 工作。Master 进程读入命令,进 现有的空闲存储结构体中查找,找到最合适的大小的空闲存储块,分配给 行一些初始化,然后 fork 并监控 child 进程。Child 进程分配若干线程进行 它。如果空闲块没有用完,则把多余的内存再组成一个空闲存储块,挂接到 工作,主要包括管理线程和 worker 线程。如下图所示。 管理结构体上。如果缓存已满,则根据 LRU 算法,把旧的 object 释放掉。 Varnish 释放缓存机制 : Expire 线程负责检测缓存中所有 object 的生存期 (TTL)。如果超过了设 定的 TTL, object 没有被访问, 该 则删除该 object,并释放内存。释放的过程 会考虑内存的合并等操作。 原文 : http://blog.csdn.net/longxibendi/article/details/6647024 推荐阅读 : varnish 权威指南 中文版 《互联网运营智慧》 7 章 第 “简单 cdn”正式版下载 015 51CTO 系统频道 : http://os.51cto.com
  • 15. 专题杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special《Linux 运维趋势》投稿信箱 : yangsai@51cto.com Squid常用命令总结 收集整理/NetSeek Squid安装设试命令: #/usr/local/squid/sbin/squid -k shutdown 1,初始化你在 squid.conf 里配置的 cache 目录 这个不用解释吧。 #/usr/local/squid/sbin/squid -z // 初始化缓存空间 6,重引导修改过的 squid.conf 如果有错误提示,请检查你的 cache 目录的权限。 #/usr/local/squid/sbin/squid -k reconfigure // 载入新的配置文件 2,对你的 squid.conf 排错,即验证 squid.conf 的 语法和配置。 这个估计用的时候比较多,当你发现你的配置有不尽你意的时候,可以 随时修改 squid.conf,然后别忘记对你的 squid.conf 排错,然后再执行此指 #/usr/local/squid/sbin/squid -k parse 令,即可让 squid 重新按照你的 squid.conf 来运行。 如果 squid.conf 有语法或配置错误,这里会返回提示你,如果没有返回, 7./usr/local/squid/sbin/squid -k rotate 轮循日志 恭喜,可以尝试启动 squid。 8, squid 添加到系统启动项 把 3,在前台启动 squid,并输出启动过程。 编辑 /etc/rc.d/rc.local #/usr/local/squid/sbin/squid -N -d1 添加如下行 : /usr/local/squid/sbin/squid -s 如果有 ready to server reques,恭喜,启动成功。 利用 Runc 脚本 ........ 然后 ctrl + c,停止 squid,并以后台运行的方式启动它。 再来点其他的。 4,启动 squid 在后台运行。 1,修改 cache 缓存目录的权限。 #/usr/local/squid/sbin/squid -s #chown -R squid:squid /data/cache 这时候可以 ps -A 来查看系统进程,可以看到两个 squid 进程。 我的 cache 缓存目录是 /data/cache,squid 执行用户和用户组是 squid, 5,停止 squid squid。 016 51CTO 系统频道 : http://os.51cto.com
  • 16. 专题杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 2,修改 squid 日志目录的权限 可以看到详细的性能情况 , 其中 PORT 是你的 proxy 的端口,5min 可以 是 60min #chown -R squid:squid /usr/local/squid/var/logs 取得 squid 运行状态信息 : 这一步并不是适合每一个使用 squid 的用户 . 意为让 squid 有权限在该 目录进行写操作 。 squidclient -p 80 mgr:info 例如生成 access.log cache.log store.log * 取得 squid 内存使用情况 : 3,查看你的日志文档。 squidclient -p 80 mgr:mem #more /usr/local/squid/var/logs/access.log | grep TCP_MEM_HIT * 取得 squid 已经缓存的列表 : 该指令可以看到在 squid 运行过程中,有那些文件被 squid 缓存到内存中, squidclient -p 80 mgrbjects. use it carefully,it may crash 并返回给访问用户。 * 取得 squid 的磁盘使用情况 : #more /usr/local/squid/var/logs/access.log | grep TCP_HIT squidclient -p 80 mgr:diskd 该指令可以看到在 squid 运行过程中,有那些文件被 squid 缓存到 cache * 强制更新某个 url : 目录中,并返回给访问用户。 squidclient -p 80 -m PURGE http://www.yejr.com/static.php #more /usr/local/squid/var/logs/access.log | grep TCP_MISS * 更多的请查看 : 该指令可以看到在 squid 运行过程中,有那些文件没有被 squid 缓存,而 是现重原始服务器获取并返回给访问用户。 squidclient-h 或者 squidclient -p 80 mgr: 关于 TCP_XXXX 等参数及代表的信息,请参看《squid 中文权威指南》 查命中率 : 13.2.1 章节。 /usr/local/squid/bin/squidclient -h111.222.111.111 -p80 mgr:info 当然,grep 的部分可以修改为其他的参数,例如你的域名 www.xxxx. /usr/local/squid/bin/squidclient -h 具体的 IP -p80 mgr:info com ,同样可以看到 access.log 里关于该域名的行。 原文 : http://bbs.linuxtone.org/thread-137-1-1.html squid命中率分析 前面的安装调试部分来自 CU 的这个帖子。 squid/bin/squidclient -p 80 mgr:info 相关链接 : Squid 中文权威指南》 《 在线阅读 squid/bin/squidclient -p 80 mgr:5min 017 51CTO 系统频道 : http://os.51cto.com
  • 17. 专题杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special《Linux 运维趋势》投稿信箱 : yangsai@51cto.com [CDN]动态内容的缓存技术 CSI,SSI,ESI 文/扶凯 CDN 中动态内容是不太好解决的,通常需要很麻烦的技术和方法来实现 目前 Squid 不支持。 这些功能,比如我设计过一种动态缓存的方法,基于 session 栏接,然后根 缺点 : 在语法上不能够直接包含其他服务器的 url, SSI 只能在当前服务 据热点来做动态缓存时间的控制。目前开放的实现 Cache 的技术主要有 器上运行。所以通过 CDN 之类的 Cache 时,还是会失效,不灵活 . CSI,SSI,ESI 之类几种。在一个动态网页中 , 内容不断更新和变化,但这并 不意味不能缓存,其实还是有 90% 的内容都可以做到 CDN 中的。只要 3、Edge Side Includes (ESI) : 花点心思。但这些都对客户有更加高的要需求。下面是这向种技术的介绍。 Edge Side Includes(ESI) 和 Server Side Includes(SSI) 和功能类似。SSI 动态 Cache 页面有如下一些方案 : 需要特殊的文件后缀 (shtml,inc)。ESI(Edge Side Include)通过使用简 单的标记语言来对那些可以加速和不能加速的网页中的内容片断进行描 1、Client Side Includes(CSI) : 述,每个网页都被划分成不同的小部分分别赋予不同的缓存控制 策略,使 通过 iframe、javascript、ajax 等方式将另外一个页面的内容动态包含进 Cache 服务器可以根据这些策略在将完整的网页发送给用户之前将不同的 来。这样来实现动态化。 小部分动态地组合在一起。通过这种控制,可以有效地减少从服务器抓取 整个 页面的次数,而只用从原服务器中提取少量的不能缓存的片断,因此 优点 : 能够利用浏览器客户端并行处理及装载的机制 ; 这种技术基本不 可以有效降低原服务器的负载,同时提高用户访问的响应时间。 需要服务器支持和修改,计算和操作放在客户端,能够降低服务器端压力 优点 : ESI 更适合用于缓存服务器上,缓存整个页面或页面片段,因此 缺点 : 搜索引擎优化问题 ; javascript 兼容性问题 ; 客户端缓存可能导致 ESI 特别适合用于缓存,CDN 的第一名的老大,Akamai 全力支持协议。对 服务器端内容更新后不能及时生效。常常通过加 js version 来解决 . 于布置和 Cache 都是最友好的。 2、Server Side Includes(SSI) : 缺点 : 出来很久,一直没有多少人使用。会这个技术的程序员不多。 SSI 它就是 HTML 文件中,可以通过注释行调用的命令或指针。实现整 原文 : 个网站的内容更新。SSI 需要特殊的文件后缀 (shtml,inc). http://www.php-oa.com/2010/08/13/cdn-cache-csi-ssi-esi.html 优点 : 技术是通用技术, SSI 不受具体语言限制,只需要 Web 服务器或应 用服务器支持即可,Ngnix、Apache、Tomcat、Jboss 等对此都有较好的支持, 018 51CTO 系统频道 : http://os.51cto.com
  • 18. 专题杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special《Linux 运维趋势》投稿信箱 : yangsai@51cto.com squid/varnish/ats简单测试 文/三斗室 简 单 的 试 试 varnish 和 apache traffic server。 跟 squid 进 行 一 下 对 比。 时间与 varnish 相近,响应时间 2.1ms。 介于 varnish 和 ats 都是出现不太久的东西(至少是开源流行不长) 选择其 , 从 trafficserver_shell 的 show:proxy_stats 和 show:cache_stats 命令结果 最新开发版本测试,正巧都是 2.15 版。 来看,缓存命中率 98%,磁盘 IO 几乎没有。可见其实都在内存中返回了。 varnish 配置文件,只修改了 backend 到具体某台 nginx 发布点上。其他 3、最后 squid2.7.9 : -r900 时,fetch/sec 只有 880,响应时间 1.9ms ; 提 都是反向代理缓存的标配。(可参考张宴博客和 varnish 权威指南) 高到 -r1000 时,没有 wrong 报错,fetch/sec 下降到 850,响应时间 2.3ms ; ats 说明更少,从目前的资料看,修改了 records.config 中的监听,cache. 另一个窗口的 netstat 命令直接卡住…… config 遵 循 源 站 未 改,remap.config 添 加 了 map 一 条, 定 域 名 到 同 一 台 绑 squid 按照公司默认做法,缓存目录建在了 tmpfs 上。从 squidclient 来看, nginx 上。 98% 的命中率中只有三分之一是直接通过 cache_mem 返回的,另三分之二 注: varnish 和 ats 都没有修改缓存路径,即分别为 var/varnish/varnish. 是通过 cache_dir 的 tmpfs 返回。 cache 和 var/trafficserver,都是磁盘。 另: 最后 du -sh 查看三者的缓存目录大小,赫然发现 squid 的是 19M, 然后从线上某台 squid2.7 上收集 www.domain.com 下的 html 页面 url ats 是 39M,varnish 是 41M。这个差别也是比较怪异的,值得后续研究…… 一共 164 条,存成 urllist。 从这个简单测试结果看,squid 的稳定性依然没的说 : 对于大多数情况来 使用 http_load 进行测试。第一遍,先用 http_load -r 100 -s 10 完成 说,是乐于见到这种宁愿响应慢点点也要保证响应正确的情况的 ; varnish cache 的加载 ; 第二遍改用 -r 1000 -s 60 进行测试。 在大批量回源时对后端服务器的冲击,显然比较让人担心 ; 和 varnish 具 ats 有同样高效的响应速度(和高压下的错误……) 而且其详细到甚至稍显繁 , 1、 是 varnish : 另 一 个 窗 口 看 netstat, 现 在 第 一 次 加 载 的 时 候, 先 开 发 琐的那堆 config 文件的配置格式,相比 varnish 来说,更加贴近运维人员。 varnish 启动了相当多的链接到后端 nginx 请求数据!第二遍时,-r1000 一 直在刷 wrong,修改成 -r900 就没有问题。最后的报告显示 fetch/sec 还略 原 文: http://chenlinux.com/2011/03/15/simple-test-between- 大于指定的 900 达到 990,建连时间平均 1.3ms,响应时间 1.8ms。 squid-varnish-ats.html 2、然后 ats : -r1000 也报 wrong,于是同样使用 -r900,fetch/sec 和建连 019 51CTO 系统频道 : http://os.51cto.com
  • 19. 专题杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 使用Nginx代替squid充当代理缓存服务器 文/崔晓辉 我的博客是 CentOS+nginx+php+mysql+eaccelerator 这种架构。只有一 worker_connections 65535; 台服务器,所以想到用在让两个 nginx 分别监听 IP:80 和 127.0.0.1:80。 } http 1. 安装 nginx 和 nginx_cache_Purge. { wget http://labs.frickle.com/files/ngx_cache_purge-1.1.tar.gz include mime.types; tar zxvf ngx_cache_purge-1.1.tar.gz default_type application/octet-stream; wget http://nginx.org/download/nginx-0.8.47.tar.gz charset gbk; tar zxvf nginx-0.8.47.tar.gz #source_charset gbk; cd nginx-0.8.47/ server_names_hash_bucket_size 128; ./configure --prefix=/usr/local/nginx --user=www --group=www --add- client_header_buffer_size 32k; module=ngx_cache_purge-1.1 --with-http_stub_status_module --with-http_ large_client_header_buffers 4 32k; ssl_module client_max_body_size 300m; make -j2 && make install sendfile on; cd ../ tcp_nopush on; 2.nginx 配置 keepalive_timeout 60; cat /usr/local/nginx/conf/nginx.conf tcp_nodelay on; user www www; client_body_buffer_size 512k; worker_processes 1; proxy_connect_timeout 5; error_log /usr/local/nginx/logs/nginx_error.log crit; proxy_read_timeout 60; pid /usr/local/nginx/nginx.pid; proxy_send_timeout 5; #Specifies the value for maximum file descriptors that can be opened by this proxy_buffer_size 16k; process. proxy_buffers 4 64k; worker_rlimit_nofile 65535; proxy_busy_buffers_size 128k; events proxy_temp_file_write_size 128k; { gzip on; use epoll; 020 51CTO 系统频道 : http://os.51cto.com
  • 20. 专题杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special《Linux 运维趋势》投稿信箱 : yangsai@51cto.com gzip_min_length 1k; proxy_pass http://backend_server; gzip_buffers 4 16k; add_header X-Cache HIT-FreeBSDSYSTEM.org; gzip_http_version 1.1; expires 1d; gzip_comp_level 2; } gzip_types text/plain application/x-javascript text/css application/xml; location ~ /purge(/.*) gzip_vary on; { proxy_temp_path /home/proxy_temp_dir; allow 127.0.0.1; proxy_cache_path /home/proxy_cache_dir levels=1:2 keys_zone=cache_ allow 219.146.0.0/16; one:200m inactive=1d max_size=30g; deny all; proxy_cache_purge cache_one $host$1$is_args$args; upstream backend_server { } server 127.0.0.1:80 weight=1 max_fails=2 fail_timeout=30s; location ~ .*.(php|jsp|cgi)?$ # server 192.168.8.44:80 weight=1 max_fails=2 fail_timeout=30s; { # server 192.168.8.45:80 weight=1 max_fails=2 fail_timeout=30s; proxy_set_header Host $host; } proxy_set_header X-Forwarded-For $remote_addr; server proxy_pass http://backend_server; { } listen 222.134.x.x:80; access_log off; server_name www.freebsdsystem.org blog.freebsdsystem.org freebsdsystem. } org; server index index.html index.htm index.php; { root /usr/local/AUTOLEMP/www/www.freebsdsystem.org; listen 222.134.66.153:80; location / server_name www.huaanjiuyuan.com; { index index.html index.htm index.php; proxy_next_upstream http_502 http_504 error timeout invalid_header; root /usr/local/AUTOLEMP/www/wwwroot; proxy_cache cache_one; location / proxy_cache_valid 200 304 12h; { proxy_cache_key $host$uri$is_args$args; proxy_next_upstream http_502 http_504 error timeout invalid_header; proxy_set_header Host $host; proxy_cache cache_one; proxy_set_header X-Forwarded-For $remote_addr; proxy_cache_valid 200 304 12h; 021 51CTO 系统频道 : http://os.51cto.com
  • 21. 专题杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special《Linux 运维趋势》投稿信箱 : yangsai@51cto.com proxy_cache_key $host$uri$is_args$args; proxy_set_header Host $host; 【特别推荐】 proxy_set_header X-Forwarded-For $remote_addr; proxy_pass http://backend_server; 大话IT第20期: add_header X-Cache HIT-FreeBSDSYSTEM.org; expires 1d; } 当Windows8遇上Linux控 location ~ /purge(/.*) 本 期 节 目 不 但 有 微 软 最 新 的 Windows 8 操 作 系 统 登 场, 有 还 { Fedora16、Ubuntu 11.10、OpenSUSE 11.4 出马,更有最近密码泄漏事 allow 127.0.0.1; 件频发而被人关注的 keepass 工具…… allow 219.146.0.0/16; deny all; 三位编辑分别在用 Linux 做什么? proxy_cache_purge cache_one $host$1$is_args$args; Windows8 又有啥特别的? } location ~ .*.(php|jsp|cgi)?$ 敬请收看本期的大话 IT。 { proxy_set_header Host $host; proxy_set_header X-Forwarded-For $remote_addr; 在线观看 : proxy_pass http://backend_server; http://os.51cto.com/art/201112/310499.htm } access_log off; IT 听听看官方微博 : } http://weibo.com/itttkan } 3. 修改 www.freebsdsystem.org 的 nginx.conf 将 server 中的 listen 80; 本期参与支持人员 : 为 listen 127.0.0.1:80 嘉文、周达洋、王文文、王玉平、杨赛、王丹、郭晗 4、重启两个 nginx。即可在 /home/proxy_cache_temp 看到缓存的目录! 5、不要在代理缓存服务器中加入 nginx_static_etags,不然你会哭的! 原文 : http://coralzd.blog.51cto.com/90341/439030 022 51CTO 系统频道 : http://os.51cto.com
  • 22. 运维DBA杂志订阅 : http://os.51cto.com/art/201011/233915.htm Database《Linux 运维趋势》投稿信箱 : yangsai@51cto.com MySQL性能优化教程之MySQL运维优化 文/caoz 存储引擎类型  如果前端请求重复度较高,无应用层缓存,query cache 是一个很 好的偷懒选择  Myisam 速度快,响应快。表级锁是致命问题。  对于中等以下规模数据库应用,偷懒不是一个坏选择。  Innodb 目前主流存储引擎  如果确认使用 query cache,记得定时清理碎片,flush query  行级锁 cache.  务必注意影响结果集的定义是什么  要考虑到现实的硬件资源和瓶颈分布 行级锁会带来更新的额外开销,但是通常情况下是值得的。  学会理解热点数据,并将热点数据尽可能内存化  事务提交  所谓热点数据,就是最多被访问的数据。  i/o 效率提升的考虑 对  通常数据库访问是不平均的,少数数据被频繁读写,而更多数据  对安全性的考虑 鲜有读写。  HEAP 内存引擎  学会制定不同的热点数据规则,并测算指标。  频繁更新和海量读取情况下仍会存在锁定状况  热点数据规模,理论上,热点数据越少越好,这样可以更好的 内存使用考量 满足业务的增长趋势。  理论上,内存越大,越多数据读取发生在内存,效率越高  响应满足度,对响应的满足率越高越好。  Query cache 的使用  比如依据最后更新时间,总访问量,回访次数等指标定义热 点数据,并测算不同定义模式下的热点数据规模  如果前端请求重复度不高,或者应用层已经充分缓存重复请求, query cache 不必设置很大,甚至可以不设置。 023 51CTO 系统频道 : http://os.51cto.com
  • 23. 运维DBA杂志订阅 : http://os.51cto.com/art/201011/233915.htm Database《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 性能与安全性考量 • binlog 文件是顺序写  数据提交方式 • 淘宝数据库存储优化是这样处理的  innodb_flush_log_at_trx_commit = 1 每次自动提交,安全性高,  部分安全要求不高的写入操作可以用 /dev/shm 分区存储,简单变 i/o 压力大 成内存写。  innodb_flush_log_at_trx_commit = 2 每秒自动提交,安全性略  多块物理硬盘做 raid10,可以提升写入能力 有影响, 承载强。 i/o  关键存储设备优化,善于比对不同存储介质的压力测试数据。  日志同步 • 例如 fusion-io 在新浪和淘宝都有较多使用。  Sync-binlog =1 每条自动更新,安全性高, 压力大 i/o  涉及必须存储较为庞大的数据量时  Sync-binlog = 0 根据缓存设置情况自动更新,存在丢失数据 • 压缩存储,可以通过增加 cpu 开销(压缩算法)减少 i/o 压力。前 和同步延迟风险, 承载力强。 i/o 提是你确认 cpu 相对空闲而 i/o 压力很大。 新浪微博就是压缩  个人建议保存 binlog 日志文件,便于追溯 更新操作和系统恢复。 存储的典范。  如对日志文件的 i/o 压力有担心,在内存宽裕的情况下,可考虑 • 通过 md5 去重存储,案例是 QQ 的文件共享,以及 dropbox 这样 将 binlog 写入到诸如 /dev/shm 这样的内存映射分区,并定时 的共享服务,如果你上传的是一个别人已有的文件,计算 md5 后, 将旧有的 binlog 转移到物理硬盘。 直接通过 md5 定位到原有文件,这样可以极大减少存储量。涉 及文件共享,头像共享,相册等应用,通过这种方法可以减少超过  性能与安全本身存在相悖的情况,需要在业务诉求层面决定取舍 70% 的存储规模,对硬件资源的节省是相当巨大的。缺点是,删  学会区分什么场合侧重性能,什么场合侧重安全 除文件需要甄别该 md5 是否有其他人使用。 去重存储,用户量  学会将不同安全等级的数据库用不同策略管理 越多,上传文件越多,效率越高! 存储/写入压力优化 • 文件尽量不要存储到数据库内。尽量使用独立的文件系统存储, 该话题不展开。  顺序读写性能远高于随机读写 运维监控体系  将顺序写数据和随机读写数据分成不同的物理磁盘进行,有助于 i/ o 压力的疏解  系统监控 • 数据库文件涉及索引等内容,写入是随即写  服务器资源监控 024 51CTO 系统频道 : http://os.51cto.com
  • 24. 运维DBA杂志订阅 : http://os.51cto.com/art/201011/233915.htm Database《Linux 运维趋势》投稿信箱 : yangsai@51cto.com  Cpu, 内存,硬盘空间, 压力 i/o  写操作,基于 binlog,定期分析。  设置阈值报警  读操作,在前端 db 封装代码中增加抽样日志,并输出执行时 间。  服务器流量监控  分析请求频繁度是开发架构 进一步优化的基础  外网流量,内网流量  最好的优化就是减少请求次数!  设置阈值报警  总结 :  连接状态监控  监控与数据分析是一切优化的基础。  Show processlist 设置阈值,每分钟监测,超过阈值记录  没有运营数据监测就不要妄谈优化!  应用监控  监控要注意不要产生太多额外的负载,不要因监控带来太多额  慢查询监控 外系统开销  慢查询日志 本文摘录自 caoz 的文档《MySQL 性能优化教程》 下载地址 : ,  如果存在多台数据库服务器,应有汇总查阅机制。 http://wenku.baidu.com/view/aa43ecc3aa00b52acfc7ca94.html?st=1  请求错误监控 推荐阅读 :  高频繁应用中,会出现偶发性数据库连接错误或执行错误, MySQL 中创建及优化索引组织结构的思路 将错误信息记录到日志,查看每日的比例变化。 http://database.51cto.com/art/201110/296764.htm  偶发性错误,如果数量极少,可以不用处理,但是需时常监控 其趋势。 MySQL 性能优化的 21 个最佳实践  会存在恶意输入内容,输入边界限定缺乏导致执行出错,需 http://database.51cto.com/art/201108/282615.htm 基于此防止恶意入侵探测行为。 专题 : 讲述 MySQL 索引和优化的故事  微慢查询监控 http://database.51cto.com/art/201107/278040.htm  高并发环境里,超过 0.01 秒的查询请求都应该关注一下。 MySQL 技巧 : 结合相关参数 做好 Limit 优化  频繁度监控 http://database.51cto.com/art/201103/248219.htm 025 51CTO 系统频道 : http://os.51cto.com
  • 25. 新鲜事杂志订阅 : http://os.51cto.com/art/201011/233915.htm Freshy《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 建设一个靠谱的火车票网上订购系统 文/林玥煜、邓侃(@邓侃) 2012 年 1 月 11 日,@fenng 写了一篇文章,批评铁道部火车票网上订购 系统,http://www.12306.cn [1]。同时在新浪发了一条言辞激烈的微博,“去你妈的‘海量事务高速处理系统’ , ” 引起热议 [2]。 开发一套订票系统并不难,难在应对春运期间,日均 10 亿级别的洪峰 流量。日均 10 亿级别的洪峰请求,在中国这个人口全球第一大国,不算稀 罕,不仅火车票订票系统会遇到,而且电子商务在促销时,也会遇到,社交网 站遇到新闻热点时,也会遇到。 所以,能够在中国成功运行的云计算系统,推广到全球,一定也能成功。 图一为 12306.cn 网站系统架构设想图,典型的“展现层” “业务层” / / 但是在美国成功运行的云计算系统,移植到中国,却不一定成功。 “数据层”的三段论。 如果我们能够设计建造一套,稳定而高效的铁路订票系统,不仅解决了 用户接入有两类,一个是运行在电脑里的浏览器,例如 IE,另一个是手 中国老百姓的实际问题,而且在全球高科技业界,也是一大亮点,而且是贴 机。 着中国标签的前沿科技的亮点。 无论用户用电脑浏览器,还是手机访问 http://www.12306.cn 网站, 于是软件工程师们献计献策,讨论如何改进 12306 网上购票系统 [3]。 用户请求首先被网站的负载均衡器接收。负载均衡器连接着一群门户服务 其中比较有代表性的,有两篇 [4,5]。 器,根据各个门户服务器的负载轻重,负载均衡器把用户请求,转发到某一 网友的评论中,有观点认为, 利用 [4] “虚拟排队”的手段,将过程拉长负 相对清闲的门户服务器。 载降低,是网游的设计思路。而 [5] 利用缓存技术,一层层地降低系统负 门户服务器的任务类似于收发室老头儿,它只读每个用户请求的前几个 荷 , 是互联网的设计思路。 bytes,目的是确定用户请求的类型,然后把请求投放到相应类型的队列中 个人认为,[4] 和 [5] 并不是相互排斥的两种路线,两者着重解决的问 去。门户服务器的处理逻辑非常简单,这样做的好处,是让它能够快速处理 题不同,不妨结合起来使用,取长补短。下面介绍一下我们的设计草案,追 大批量用户请求。 求实用,摈弃花哨。抛砖引玉,欢迎拍砖。 根据 [5] 的分析,12306 处理的用户请求,大致分为三类, 026 51CTO 系统频道 : http://os.51cto.com
  • 26. 新鲜事杂志订阅 : http://os.51cto.com/art/201011/233915.htm Freshy《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 1. 查询。用户订票前,查询车次以及余票。用户下订单后,查询是否已 务的处理流程,各不相同。 经订上票。 图二为 12306.cn 网站查询和订票业务流程设想图,描述了查询和订票, 2. 订票,包括确定车次和票数,然后付款。用户付款时,需要在网银等 两个业务的处理流程。登记业务流程从略。 网站上操作。 查询的业务流程,参见图二上半部,分五步。这里有两个问题需要注意, 3. 第一次访问的用户,需要登记,包括姓名和信用卡等信息。 1. 用户发出请求后,经过短暂的等待时间,能够迅速看到结果。平均等 三类请求的业务处理过程,被分为两个阶段, 待时间不能超过 1 秒。 1. 运行于缓存中的任务队列。设置队列的目的,是防止处理过程耗时 2. 影响整个查询速度的关键, “查询服务器” 是 的设计。 太长,导致大量用户请求拥塞于门户服务器,导致系统瘫痪。 查询任务可以进一步细化,大致分成三种。 2. 业务处理处理器,对于每一类业务,分别有一群业务服务器。不同业 1. 查询车次和时间表,这是静态内容,很少与数据库交互,数据量也不 大,可以缓存在内存中。 车次和时间表的数据结构,不妨采用 Key-Value 的方式,开发简单,使 用效率高。Key-Value 的具体实现有很多产品, 建议使用 Redis。 [5] 这些是技术细节,不妨通过对比实验,针对火车票订票系统的实际流量, 以及峰值波动,确定哪一个产品最合适。 2. 查询某一班次的剩余车票,这需要调用数据库中不断更新的数据。 [5] 建议把剩余车票只分为两种, “有” “无” 这样减少调用访问数据 或 , 库的次数,降低数据库的压力。但是这样做,不一定能够满足用户的需求, 说不定会招致网友的批评讥讽。 [4] 建议在订票队列中,增加测算订票队列长度的功能,根据订票队列长 度以及队列中每个请求的购票数量,可以计算出每个车次的剩余座位。如 果 12306.cn 网站只有一个后台系统,这个办法行之有效。 但是假如 12306.cn 网站采用分布式结构,每个铁路分局设有子系统, 分别管理各个铁路分局辖区内的各个车次。在分布式系统下,这个办法面 027 51CTO 系统频道 : http://os.51cto.com
  • 27. 新鲜事杂志订阅 : http://os.51cto.com/art/201011/233915.htm Freshy《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 临任务转发的麻烦。不仅开发工作量大,而且会延长查询流程处理时间,导 的压力。 致用户长久等待。 北京用户的订票数据,只缓存在北京的查询服务器,不跨域缓存,从而降 3. 已经下单的用户,查询是否已经成功地订上票。 低缓存空间的占用,和同步的麻烦。这样做,有个前提假设,查询用户与订 票用户,基本上是同一个人,而且从同一个城市上网。 每个用户通常只关心自己订的票。如果把每个用户订购的车票的所有 内容,都缓存在内存里,不仅非常耗用内存空间,内存空间使用效率低下,更 但是这里有个缺陷,某用户在北京上网订了票。过了几天,他在北京上 严重的问题是,访问数据库过于频繁,数据量大,增大数据库的压力。 网,输入用户 ID 和密码后,就会看到他订购的所有车票。可是又过了几天, 他去了郑州,从郑州上网,同样输入用户 ID 和密码,却看不到他订购的所有 解决上述分布式同步,以及数据库压力的两个问题,不妨从订票的流程 车票。设计和数据结构设计入手。 解决这个缺陷的办法并不麻烦,在用户查询订票信息时,需要注明订票 假如有个北京用户在网上订购了一套联票,途经北京铁路局和郑州铁路 地点,系统根据订票地点,把查询请求转发到相应区域的子系统。局辖区的两个车次。用户从北京上网,由北京铁路局的子系统,处理他的请求。北京铁路局的订票服务器把他的请求一分为二,北京铁路局的车次的 另外,每次订票的时候,网站会给他的手机发送短信,提供订票信息,参订票,在北京子系统完成,郑州铁路局的车次在郑州子系统完成。 见图二下半部第 8 步和第 9 步。 每个子系统处理四种 Key-Value 数据组。 以上是一个初步设计,还有不少细节需要完善,例如防火墙如何布置等 等。这个设计不仅适用于单一的集中式部署,而且也适合分布式部署。 1. 用户 ID : 多个 ( 订单 ID)s。 Reference, 2. 订单 ID : 多个 ( 订票结果 ID)s。 [1] 海量事务高速处理系统。 3. 订票结果 ID: 一个 ( 用户 ID,车次 ID)。 [2] 去你妈的‘海量事务高速处理系统’。 4. 车次 ID : 一个 ( 日期 ),多个 ( 座位,用户 ID)。 [3] 火车订票系统的设想。 北京订票服务器完成订票后,把上述四个数据组,写入北京子系统的数 据库,同时缓存进北京的查询服务器,参见图二下半部第 6 步和第 7 步。 [4] 铁路订票系统的简单设计。 郑州订票服务器完成订票后,把上述四个数据组,写入郑州子系统的数 [5] 铁路订票网站个人的设计浅见。据库,同时缓存进北京的查询服务器,而不是郑州的服务器。 原文 : http://www.ifanr.com/68019 让订票服务器把订票数据,同时写入数据库和查询服务器的缓存,目的 推荐阅读 : 12306.cn 谈谈网站性能技术 via coolshell 由是让数据库永久保留订票记录,而让大多数查询,只访问缓存,降低数据库 028 51CTO 系统频道 : http://os.51cto.com
  • 28. 工具杂志订阅 : http://os.51cto.com/art/201011/233915.htm Tools《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 红帽虚拟桌面SPICE服务概述与安装指南 文/曹江华 SPICE(独立计算环境简单协议)是红帽企业虚拟化桌面版的三大主要 播放通道 技术组件之一,具有自适应能力的远程提交协议,能够提供与物理桌面完全 记录通道 相同的最终用户体验。它包含有 3 个组件 : 每个通道可以是一个单独的数据流。SPICE 和 VNC 对比如下表。 SPICE Driver : SPICE 驱动器 存在于每个虚拟桌面内的组件 ; SPICE VNC SPICE Device : SPICE 设备 存在于红帽企业虚拟化 Hypervisor 内的组件 ; BIOS 屏幕显示 能 能 SPICE Client : SPICE 客户端 存在于终端设备上的组件,可以是瘦客户机 全彩支持 能 能 更改分辨率 能 能 或专用的 PC,用于接入每个虚拟桌面。 多显示器 多显示器支持 (高达 4 画面) 只有一个屏幕 图像传输 图像和图形传输 图像传输 这三个组件协作运行,确定处理图形的最高效位置,以能够最大程度改 视频播放支持 GPU 加速支持 不能 善用户体验并降低系统负荷。如果客户机足够强大,SPICE 向客户机发送 音频传输 双向语音可以控制 不能 图形命令,并在客户机中对图形进行处理,显著减轻服务器的负荷。另一方 鼠标控制 客户端服务器都可以控制 服务器端控制 面,如果客户机不够强大,SPICE 在主机处理图形, CPU 的角度讲, 从 图形处 USB 传输 USB 可以通过网络传输 不能 加密 通讯可以使用 SSL 进行加密 不能 理并不需要太多费用。 SPICE 的工作原理是创建几个通用接口或“通道” 它们都高度抽象, , 所以 Spice 的未来的功能 : 能在各种平台上使用。通道主要包括六个 : 直接借助对 DirectX 和 API 来实现一个虚拟视频卡。加快 CAD 应用和多 主通道 媒体应用。更快的切换与游戏画面直接绘制过程减少闪烁。 显示通道 视频加速(DXVA)视频播放应用程序支持 DXVA, Windows 媒体播放 如 输入通道 器,可以减少对客户端的 CPU 利用率。 鼠标控制通道 3D 加速 会更快地运行在一个虚拟的桌面, OpenGL 和 3D 应用程序, 如 029 51CTO 系统频道 : http://os.51cto.com
  • 29. 工具杂志订阅 : http://os.51cto.com/art/201011/233915.htm Tools《Linux 运维趋势》投稿信箱 : yangsai@51cto.com Windows Aero 的支持,使用虚拟桌面时可以使用 Windows Vista 和 7 function=0x0/> 现在不可以。 可以动态地改变虚拟桌面分辨率。 </memballoon> </devices> 兼容 iPhone 和 ipad 通过智能手机, iPhone 和 iPad 等设备控制。 如 </domain> 剪贴板共享你可以共享与虚拟桌面环境的剪贴板,数据将允许相互合作 可用于无缝连接。 启动虚拟机 : 网络打印机共享 : 打印机被允许从网络访问,提高可用性。 #virsh start web Linux 下有三种方式配置 SPICE 服务器 : 命令行、virt-manager、直接修改 Domain web started 配置文件。篇幅所限,下面只大概介绍命令行配置方式。 Linux下使用SPICE客户机 CentOS 6、RHEL 6安装配置SPICE服务器的方法 #yum -y install spice-client 这里是直接修改配置文件方式,首先安装软件包 : Linux 下使用 spicec 命令连接 : #yum -y install spice-server # /usr/libexec/spicec -h 192.168.0.13 -p 5930 -w password 首先建立一个普通名称是 web 的虚拟机,可以使用 virt-manager 虚拟机 -h 参数是 kvm 虚拟机 ip 地址 管理工具和命令行两种方法。 -p 参数是 kvm 虚拟机端口 下面编辑虚拟机文件添加 spice 参数 : -w 参数是密码 ... Windows下使用SPICE客户机 <input type=tablet bus=usb/> # add 从 http://www.spice-space.org/download.html 下载两个文件 : <graphics type=spice port=5930 autoport=no listen=192.168.0.13 spice-client-win32-0.6.3.zip passwd=password/> <video> spice_libs_win32_063_and_earlier.zip <model type=qxl vram=32768 heads=1/> <address type=pci domain=0x0000 bus=0x00 slot=0x02 function=0x0/> 然后解压缩。spicec.exe 文件复制到 spice_libs_win32_063_and_earlier </video> lib 目录下,运行 spicec.exe 即可。 <memballoon model=virtio> 原文 : http://os.51cto.com/art/201201/311464.htm <address type=pci domain=0x0000 bus=0x00 slot=0x04 030 51CTO 系统频道 : http://os.51cto.com
  • 30. 技巧杂志订阅 : http://os.51cto.com/art/201011/233915.htm Tips《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 为什么要尽量避免重启你的Unix服务器 文/Paul Venezia 编译/核子可乐 Windows 管理员们往往把重启当成故障排查工作的首要步骤之一,而 故障或者其它稀奇古怪的原因。 Unix 团队则一般只在束手无策的情况下才进行尝试。 造成Unix服务器重启的原因 Unix服务器重启的两种情况 如果我们只是简单查看几分钟之后就一拍脑门决定重启设备,那么也许 服务器重启操作应该极少出现。在这里我列举内核更新与硬件更换作 故障的真正原因就彻底湮没在时光中了——也许是某位初级管理员在运行 为例子,因为它们是 Unix 领域中引发重启的两大主要原因。有些人一直在 一套自己编写的愚蠢脚本时无意中删除了 /boot 目录或者 /etc、/usr/lib64 鼓吹什么不重启服务器的话会带来某些严重的安全风险,这简直是一派胡 下的部分内容。这正是引发分段故障以及设备不稳定情况的罪魁祸首。然 言。如果服务项目与应用程序中确实存在安全风险,那么打上漏洞补丁就 而一旦我们直接重启服务器而没有深入挖掘问题,那么显然问题会变得更 能解决问题了,补丁往往不要求重启设备。而如果安全风险在内核模块中, 加严重,接下来不出意外的话大家应该会启动恢复镜像——这就代表需要 一般来说只需卸载对应模块、安装补丁,最后重新加载模块。没错,一旦内 面对大量恢复工作——而与此同时生产服务器也将陷入停机状态。 核中存在安全风险,那么重启操作的确是必要的 ; 但在这种情况之外,大家 以上只是我们在 Unix 领域中应该尽量避免重启操作的原因之一。总之,根本没有切实的理由重新启动 Unix 服务器。 没人能利用 /var 分区重启设备就完全修正错误(另外请别提什么打开文件 有些人认为如果不进行重启,其它形式的风险往往会接踵而至,如某些 句柄这类迂腐的蠢话——我想大家应该理解我的意思)。关键性服务项目在开机时没有正确启动而导致一系列隐患。当然,这种说 服务器重启前请做完你该做的工作法本身是正确的,但只有刚刚接掌服务器设备的菜鸟才会忘记正确设置服 务的启动参数。话说回来,如果大家的服务器正处于构建阶段,且其中还不 在大多数情况下,不进行重启是极其重要的,因为系统中能够帮助我们 涉及任何生产方面的内容,那么不妨随意进行各类重启测试。这不会带来 修复问题的关键性信息在重启前是一定存在的,但在重启后却未必还在。 任何不良影响,而且我认为这正是熟悉重启机制的最好时机。 今后大家在面对问题时,如果有某个家伙说什么“嘿,不如先重启一下看 看” 不妨直接给他两个大嘴巴。 , 但还有另一方面需要考虑 : 那些将重启操作当成故障排查重要步骤之一 的家伙是抱着死猪不怕开水烫的心态,打算一次性把问题都暴露出来。就 原文 : When in doubt, reboot? Not Unix boxes 说一套已经出现问题的 Unix 设备吧,某些还处于运行中的服务项实际上已 译文 : http://os.51cto.com/art/201112/310712.htm 经无法再次启动,而这一点在重启之后就会显现出来——也许是由于分段 031 51CTO 系统频道 : http://os.51cto.com
  • 31. 招募启事《Linux 运维趋势》的建设需要您的加入! 您可以通过如下方式参与我们杂志的建设 : 1、推荐文章 无论是您在互联网上看到的好文章,还是您自己总结 / 整理的资 本刊发布日期 : 每个月的第二个星期五料; 无论是英文还是中文 ; 无论是入门的还是高端的,都欢迎推荐!您可以直接在《Linux 运维趋势》新浪微群中分享 : 您可以通过如下方式检查新刊发布 : http://q.weibo.com/121303 1、电子邮件订阅 : http://os.51cto.com/art/201011/233915.htm 2、投稿 2、RSS 订阅 : http://www.51cto.com/php/rss.php?typeid=777 如果您愿意与大家分享您技术经验的热诚,那么欢迎您的投稿! 3、iPad 订阅 : 《读览天下》 在 客户端中可以搜索下载新刊到本地阅读!原创或译文均可,稿件在 51CTO 首发可领取稿酬 :) 本期杂志封面由 lazycai 制作 投稿信箱 : yangsai@51cto.com 3、推广与意见 《Linux 运维趋势》是由 51CTO 系统频道策划、针对 Linux/Unix 系 如果您喜欢我们的杂志,认为这本杂志对于您的工作有所帮助,请 统运维人员的一份电子杂志,内容从基础的技巧心得、实际操作案例向您的 Linux 好友、同事们推荐它!如果您觉得这份杂志还有什么地 到中、高端的运维技术趋势与理念等均有覆盖。方需要改进或补充,也希望您能够提出您的宝贵意见! 《Linux 运维趋势》是开放的非盈利性电子杂志,其中所有内容均收 反馈可至《Linux 运维趋势》新浪微群 : 集整理自国内外互联网(包含 51CTO 系统频道本身的内容)。对于来 http://q.weibo.com/121303 自国内的内容,编辑都会事先征求原作者的许可(八卦,趣闻 & 数字 或在新浪微博 栏目例外)。如果您认为本杂志的内容侵犯到了您的版权,可发信至 yangsai@51cto.com 进行投诉。 @51CTO 系统频道