博客园_新进化论

笔记本电源消耗测量

2012-06-03T07:11:00Z

So far, I’m very anxious to see how much power I can save with my laptop (let’s say – if I turn of my screen, my speaker, my ODD, etc). Well, this time I have chance to test myself

I use my laptop, ASUS F3JC. Powered with Intel T7400 (2.16 GHz), 2 GB or RAM, 120GB of SATA HDD, 15.4″ screen, and a Super Multi ODD. What else? I use standard 65 Watt adapter.

I use a device that can measure the power consumption directly. You just need to plug this device on to the wall outlet, then connect your peripheral to this device. Then, this device can measure the power consumption of your peripheral instantly (real time). Take a look of the device below.

This tiny little device can measure the Voltage, Current, Power Consumption (in Watt or VA), Frequency (Hz), Efficiency (Power Factor), and Power Usage (kWh). This is a great device, but somewhere not available in Indonesia.

And here is the result:

With minimum brightness (one step before completely off), I get 21 Watt of power consumption (with processor clocked at 994 MHz). Additional 2 Watt is needed if I set my processor at 2160 MHz. With full load (2 core all at 100%), my notebook will consume around 28 Watt (at 994 MHz) and 56 Watt (at 2160 MHz).

With medium brightness (half step between completely off and maximum setting), I get 23 Watt of power consumption (with processor clocked at 994 MHz). Similar with the result before, additional 2 Watt is needed if I set my processor at 2160 MHz. With full load (2 core all at 100%), my notebook will consume around 30 Watt (at 994 MHz) and 58 Watt (at 2160 MHz).

With maximum brightness (maximum brightness setting available), I get 26 Watt of power consumption (with processor clocked at 994 MHz). A little bit higher, I need additional 3 Watt if I set my processor at 2160 MHz. With full load (2 core all at 100%), my notebook will consume around 34 Watt (at 994 MHz) and 61 Watt (at 2160 MHz). I also test with single core only (100% load on first core, and idle on second core). The result has no different in significant margin I think. I will use around 33 Watt vs 34 Watt in 994 MHz and 54 Watt vs 61 Watt in 2160 MHz. I think this is because the second core is not totally shut-off physically, only not used at its maximum load.

Additional test:

Speaker at maximum volume will consume around 1 Watt
WLAN will consume around 1 Watt
Spin-up CD/DVD will consume around 3 Watt
Reading CD/DVD will consume around 6 Watt

Conclusion:
Well, from this short article, you can see that actually, the back light of the screen will not consume too many power as we have thought before (please remember that I’m currently using 15.4″ screen, it will consume less power for smaller screen).

If we can do some math, with minimum back light (full processing power) will consume around 56 Watt, while it will consume around 61 Watt with full brightness. The 5 Watt different means around 10% only. So if your battery should last 4 hours, with maximum brightness, it will last around 3,6 hours (or around 3,8 hours with medium brightness). A price that you have to pay for a comfortable screen?

WLAN and speaker will not consume a lot of power, but reading (or writing CD/DVD) simply will. Even the spin-up process (after you insert a CD/DVD in to the drive), will consume around 3 Watt of power.

本文链接

word编辑长文档方法

2012-06-03T07:10:00Z

视频教程1：http://v.youku.com/v_show/id_XMTU4MjQyNDQ0.html

视频教程2：word教学39长文档3.图表目录.表格目录.交叉引用，图片目录，格式设置

微软文档：Word 2003 长篇文档排版技巧（二）

微软文档：Word 2003 长篇文档排版技巧（一）

快捷键应用样式

Use built-in shortcut keys for Heading styles and Normal style (which is the only way that hasn't changed since way back last century).

Apply Heading 1 style: Alt-Ctrl-1
Apply Heading 2 style: Alt-Ctrl-2
Apply Heading 3 style: Alt-Ctrl-3
Apply Normal style: Ctrl-Shift-n
Promote a heading paragraph to the next-highest level (for example, Heading 2 to Heading 1): Shift-Alt-Left arrow
Demote a heading paragraph to the next-lowest level (for example, Heading 1 to Heading 2): Shift-Alt-Right arrow

本文链接

拨云见日：企业网络准入策略小议

2012-06-03T04:31:00Z

近来有机会接触了一些企业网络准入的项目，感触颇深。针对这个复杂的市场有一点自己的心得，没有结论，意在抛砖引玉，为大家的思考和讨论铺路。

本文只关注企业用户，而且是具备一定用户规模的国内企业用户，不是学校、不是小区宽带；其次，范围是用户对网络资源的访问，包括有线、无线、VPN等等。之所以要这么规定一下，是为了后面的讨论更准确、更有针对性，企业用户有自己的特点和需求，适合其它环境的思路在企业网中很可能玩儿不转，任何一种技术方案只有在立足的环境中才存在讨论的意义。

一. 缘起

网络准入是一个由来已久的话题，但一直以来并不是IT安全的重点，直到近年来，才逐渐成为炙手可热的话题。无线接入、智能移动终端和云计算的兴起共同催生了这一波热潮。

随着云计算的不断深入，越来越多的企业业务系统由传统的C/S架构向B/S架构迁移，以往访问后台数据需要安装专用软件，IT部门控制客户端软件的许可发放，就能够大致控制访问用户的范围。而在B/S架构中，用户只需要一个WEB浏览器即可登录系统，加上智能手机、智能平板和WiFi的流行，以往的限制条件消失了，任何人手中的设备都成了可能访问后台数据库的平台，IT部门突然一下子失去了对局面的控制，因此，对网络的准入控制被重新提上日程。只有合法的用户才能够接入网络，通过对接入用户的控制，IT部门开始试图重新夺回对数据访问的控制权。

二. 几种思路

控制用户接入网络的技术伴随网络本身的诞生和发展已经衍生出五花八门的派别，每种方式都有自己的特点和适用场景，很难说那种方式在技术和最终效果上技高一筹取得了绝对的领先地位。

在新形势下，接入技术本身并没有发生翻天覆地的变化，其演进更多地是从满足需求的前提出发，将现有的方式进行重新的优化、组合，从而推出一个满足新需求的解决方案。在实际环境中常见的认证方式包括二层认证、三层认证和基于客户端方式的认证。

二层认证

二层认证就是用户在获得IP地址之前必须通过的认证，大型企业往往利用DHCP进行IP地址分发，用户在接入网络之初同网络侧通过二层连接进行认证数据的交互，只有成功通过认证才能向DHCP服务器申请IP地址，从而收发数据。

二层认证的代表实现方式就是802.1X。802.1X是IEEE 802.1协议集的一部分，定义了EAP在以太网环境中的实现方式，而EAP是IETF在RFC3748中制定的在数据链路层中进行认证行为的一种机制，以满足在不同的二层环境下进行统一、一致的认证的需求。这个逻辑连起来就是，IETF首先制定了在数据链路层也就是二层上进行验证的EAP机制，然后IEEE给出了EAP在以太网环境中的运行方式，这个方式就是大家熟知的802.1X。现在，我们可以回答两个常常被混淆的问题：

1）802.1X是802.11的子集吗？

No，802.1X不但可以工作在无线环境中，同样能够工作在有线环境中，并且在WiFi被大规模部署之前，802.1X就已经是有线网络中一种重要的认证方式。

2）EAP是802.1X专用的认证方式吗？

No，理论上EAP可以被运用在任何一种数据链路层之上，例如PPP或以太。

基于802.1X的二层认证基本工作方式如下图所示：

上图中的三个元素，分别是客户端（Supplicant）、认证方（Authenticator）和认证服务器（Authentication Server）。客户端就是支持802.1X功能的终端设备，如笔记本、智能手机；认证方是将客户端接入网络的接入设备，在有线网络中是接入交换机，无线网络中是无线AP和控制器，在VPN连接中，认证方则是VPN服务器，认证方负责接受客户端的认证请求，但本身并没有处理这些请求的能力，它会将获得的信息转发到认证服务器，由认证服务器辨别客户端的合法性；认证服务器通常是集中部署在网络内的一台安全设备，当收到转发来的用户请求后，认证服务器将请求信息同已有的用户资料做比对，并将结果返还给认证方，如用户合法，认证方便会将客户端接入网络，否则予以屏蔽，或放入特殊VLAN，至此，一个标准的二层认证流程才结束。

在这个过程中，认证方和认证服务器之间通过特定的协议通信，目前采用最普遍的两个协议是RADIUS和TACACS+，总体说来，TACACS+的稳定性、安全性和灵活性更高，但TACACS+是思科私有协议，因此，在一般的用户接入场合，RADIUS更加常见。

通过多年的发展，802.1X+RADIUS的实现方式已经发展成为一个功能非常强大的准入方案，RADIUS丰富的字段使得认证可以不仅仅针对用户名与密码，还可以根据接入设备的MAC地址、IP地址、交换机端口等信息来进行认证。

之所以解释这么多二层认证的细节，是想说明基于802.1X的二层接入是一个非常成熟的方案，市场接受程度很高，不管认证方还是认证服务器，都不难找到多家厂商的产品，客户端的支持方面也不是问题，主流的桌面操作系统和智能手机终端大都支持802.1X。用户的接受与市场的成熟，对于安全策略的长期部署是非常重要的，802.1X在这方面的优势异常明显，其他方案不一定有这么幸运。

总体说来，802.1X的二层模式具备了以下三个特点：

1）完全公开的架构，每一个部分都有相应的国际标准，便于企业客户自由选择软硬件、搭建一个灵活的安全架构，不会受制于特定厂家；

2）成熟的技术标准，802.1X已经部署在全球成千上万的园区网，本身是一个非常成熟的技术，实施风险和成本低；

3）包含完善的认证和授权机制，能够满足企业用户的大部分需求。

如果仔细揣摩这三点，你会发现802.1X同以太网非常相似–公开、成熟、实用，这其实就是企业客户的核心需求，企业的IT部门在做任何选择时首先考虑的都是技术的可延续性以及成熟性，如果某项技术大家都在用，本身功能又实现得七七八八，这个方案就是最优方案，华而不实的新鲜玩意反而难以得到企业用户的垂青。

三层认证

说了这么多，传统的二层方案是个完美的方案了？如果放在五年前，也许是这样，但随着网络的发展，接入环境越来越复杂，802.1X在某些方面渐渐显得力不从心了。例如，某些企业需要为访客提供无线网络接入，但不可能每次有来访人员时临时在笔记本电脑上配置802.1X策略，这就需要一个快捷的办法将没有经过认证的第三方设备接到网络中。

三层认证就在这种背景下应运而生了。

三层认证又被称为WEB认证，顾名思义，认证过程是通过一个WEB页面完成的。当有新的设备需要接入时，网络设备不会默认屏蔽它，而仅仅为其提供一些基本数据的转发能力，如DHCP、DNS等，客户端可以通过DHCP拿到地址，但他还没有办法获得完全的网络权限，比如上个QQ啥的；此时，用户需要发起一个HTTP请求(在浏览器中访问任意一个WEB页面)，交换机或者无线控制器从中截取到用户的这个HTTP请求，并将用户重定向到一个预先写好的认证页面上（这个页面可以存放在任意一个IP可达的WEB服务器上），用户在在这个页面使用用户名/密码完成认证，从而获得全面的网络访问权限。

同传统的二层认证比较，WEB最大区别就是去除了对客户端的要求，用户端设备无需进行配置，只要有一个浏览器就OK了，而这个条件基本上所有的个人设备都能够满足。因此，近年来WEB认证的发展非常快，特别是在无线、大型园区等环境中得到了大规模的部署，而主流网络厂家也纷纷将WEB认证作为无线控制器和接入交换机的一项默认内置功能。

三层认证凭借其自身的特点获得了市场的认可，但在现阶段毕竟还是一个补充方案，难以作为企业环境的主力认证方式。首先，每次上网通过WEB页面登录的方式对大多数企业用户来说都“土”了一点儿，而且WEB认证检查的内容也比较简单，大部分时候仅有用户名和密码，在高安全级别的环境中仍显单薄。

客户端方式

除了三层认证和二层认证，还有一种很有意思的思路，即通过客户端对接入用户进行认证。这里所说的客户端是指安装在用户设备的上的软件，其表现形式五花八门，以杀毒软件起家的厂商会做成杀软的功能子集、以桌面控制立足的厂家会做成控制软件的一部分、而传统的网络设备厂家则会将这部分功能集成到VPN\无线接入的用户端软件中。不管是什么路子，这类软件一般只干两件事情：1）从操作系统接手802.1X的认证流程；2）对操作系统的健康状况做检查，如是否安装了最新版补丁、杀毒软件是否更新到最新病毒库等等，若操作系统处于可靠的状态则允许接入网络，否则拒绝。

这种方式有一点像一个加强版的360软件，它不但帮你检查身体，还基于你的身体状况决定你是否能获得一张游泳证。由于健康状态的检查内容包含了系统的补丁安装、应用软件安装、杀毒软件更新等情况，因此，必须在客户的设备上安装一个系统权限非常高的客户端软件才能完成所有的检查工作。

很明显，客户端方式完全是从企业IT部门的视角出发，对最终用户采取更多的限制。通常，这种方式都会和厂家进行紧密的绑定，通过在每台终端设备上安装客户端，用户的IT流程和安全规范也紧密地同厂家能够提供的功能选项结合在一起。

三种方式的对比表格

三. 延伸思考

用户需要什么样的方案？

企业网的准入是一项非常特殊的技术，最终用户的体验是决定一个项目成败的关键。有的方案从技术上评估非常完美，但实施之后发现最终用户根本接受不了，过多挑战用户的使用习惯，最终被行政层面废掉。

有的客户在被厂家忽悠过后决定在整个公司范围内推广严格的网络准入控制，在所有PC终端上安装安全客户端软件。结果，客户端装上后频频告警，因为不少人在自己的电脑上安装的下载软件强行修改了系统的下载线程限制，还有的员工干脆卸载了原有杀毒软件，自己重新安装了互联网上的免费杀软。这些被折腾过的电脑，在安全客户端内置的严格的策略规则前统统被亮了红灯，上线测试第一周就有不少员工无法正常接入网络。结果IT部门啥都顾不上，成天到各处救火，最后这个系统被大领导一句话下了马。

即使是最通行的802.1X方式，也不一定适应每个地方的水土。当一台配置了802.1X接入的PC机刚开机时需要一定时间同网络侧交互认证信息，如果用户接受程度不高，很可能会认为网络接入效率低，从而投诉，给IT部门造成很大压力。

因此，对于最用用户来说，最好的方案就是用户体验最友好的方案，只有对原有使用流程影响最小的技术方案才能得到上下一致的支持，从而推动最终的全面部署。另一方面，业务部门对准入的支持也至关重要。

IT部门需要什么样的方案

对于IT部门来说，网络准入是一个非常笼统、模糊的概念，什么样的用户能够接入网络？什么样的安全检查才是足够安全？同企业的其他安全策略该如何整合？这些问题在业界都没有统一的结论，而且安全防护是一场没有终点的拉锯战，IT部门不可能无限制地投入资源去追求极致的安全级别。

准入控制的实施过程是非常复杂的，是一个惊动全局的工程，因此，IT部门在上马准入时无不希望是一个循序渐进的过程，先从最基本的二层准入或三层准入开始，逐渐推进到设备健康状态检查等复杂的机制，这在准入项目的实施过程中尤其重要。

其次，准入控制的最终对象是企业内部的人员，而大部分企业往往已经具备了用户数据库，且用户的合法性以此数据库的实时数据为准，比如供人力部门使用的微软Active Directory。新的准入系统要能够方便地与原有数据库集成，特别是将准入系统内复杂的策略直接绑定到已有的用户帐号上。例如有的用户希望对PC机的MAC地址进行认证，而在原有的Active Directory内是没有MAC地址这一个字段的，且这个数据库的管理权不一定在IT部门手里，那么新添加的MAC地址信息如何同原有的用户帐号绑定，并实现帐号信息的定期自动更新就是一个挑战。

最后，准入控制系统一定要有一个清晰、简洁的管理流程和界面。

什么是完美的产品？

综上所述，一个优秀的准入控制技术方案需要具备以下特点：

1）可延续性

所谓可延续性是指采用的技术方案要具有长期的发展路线和支持力度，或者是被广泛应用的公开标准，或者是强大厂商的主流产品。准入机制一旦部署将延伸到网络的各个角落，并同企业今后的安全策略紧密结合起来，如果基础平台不稳定，后期变更将是迁一发动全局的麻烦事；

2）可用性

准入策略的顺利实施一定是以最终用户的接受为基础，因此，准入系统对最终用户的使用流程不能有太大的影响，要提供一个足够友好的用户体验；

3）灵活性

准入策略的内涵非常广泛，企业IT部门在实施时一定是一个逐渐完善的过程，为了应对这种需求，准入系统要具备一定灵活性，各个功能模块的实现不能有冲突；

4）整合性

准入系统要能够方便地同主流的企业数据库系统整合，并将安全策略绑定到相应的用户帐号之上，实现自动化的用户数据更新。

虚拟桌面的机会

网络环境的变化，带来的是访问方式的变化。一方面，网络准入技术开始快速发展，另一方面，很多人开始询问“是否一定需要在网络边界做这么严格的控制，还有没有其他方法？”。

也许是有的。

虚拟桌面在企业内部的应用开始逐渐铺开，员工对数据库的访问全部通过虚拟桌面完成，而硬件本身可能是一个简单的瘦客户端，不具备复杂的功能。在企业网络内部对虚拟桌面流量设置高优先级QoS策略，对其余流量以及网络接入采取从简的思路，在未来，这并非不会是一种解决方案。

总之，随着云计算、智能手机、WiFi等新应用的快速发展，传统的企业网络不得不开始主动变化，这种变化将如何发生，往哪里去，得出怎样的结果，现在都还不明晰，但有一点是明确的，那就是有意企业数据网络和安全的厂家现在就必须开始重视这股潮流，未雨绸缪，才能从容应对未来的新一代企业网络的发展。

本文链接

转：车库咖啡网络现状及改造建议

2012-06-03T04:29:00Z

受陈首席委托，本人于5月17日对车库咖啡的网络部署情况进行了实地考察，总结了一些目前存在的问题，并给出改造建议。水平所限，文中定有不妥之处，还望各位弯曲网友多给把关，集思广益得到最合理的解决方案。

网络现状

车库咖啡采用8线ADSL接入，速度均为下行2Mbps/上行512Kbps，服务商为北京联通。（据创始人介绍，除联通ADSL外，车库咖啡所在建筑无其他互联网接入服务可供选择。）线路由图中所示B点入户，在A点与B点各放置了4台ADSL Modem，再由位于同一位置的4台路由器做PPPoE/NAT，其中包括D-Link DI-7200企业级上网行为管理路由器（最大支持4路WAN接入，使用3路连接ADSL）2台、Cisco/Netgear家用级无线宽带路由器各1台。

车库咖啡营业面积大约800平米，分为会议室、书房、大厅三大功能区。为实现全面的Wi-Fi信号覆盖，4台路由器LAN口又连接了若干家用级无线宽带路由器，当做AP使用；在大厅中部分区域，采用了无线网桥的方式拓展信号。整个车库咖啡共有4个SSID供顾客使用，它们彼此独立，无法实现无线漫游等特性。

现存问题

经过调查分析，车库咖啡网络目前存在如下比较明显的问题：

网络割裂：缺少核心交换设备的车库咖啡网络被分割成孤立的4个区域，接入不同SSID的用户无法实现高速数据传输；接入资源也未进行聚合及统一调度，导致带宽利用率失衡。例如考察当天下午（非高峰时间），接入Netgear产品提供Wi-Fi服务的用户数量一度超过拥有3条ADSL接入的D-Link DI-7200，前者的2M下行带宽已满，后者仍有很大余量。
应用流控失控影响网络使用体验：D-Link DI-7200具有一定的应用控制能力，也配置了屏蔽P2P下载的策略，效果却不尽人意。在使用迅雷下载热门应用时，3条ADSL的上下行带宽很快饱和，影响到其他顾客的上网体验。多数在线视频服务也会对网络造成很大压力，例如打开优酷超清视频后，下行带宽很快从1M左右达到饱和。Cisco/Netgear的家用级设备则不具备任何应用识别及控制能力，且在提供Wi-Fi服务的同时要处理DHCP、NAT等业务，网络使用体验难以保证。
Wi-Fi接入体验欠佳：现有无线方案采用家用级产品部署，在顾客较多时效果欠佳，例如考察当晚金山公司在大厅做活动（目测来宾超过200人）时，几个接入点都会有拒绝连接的情况发生。即便侥幸连上Wi-Fi，网络也几乎不可访问。下图是连接后PING路由器内网口IP及百度时的延迟及抖动情况。
不合理配置：个别AP启用了NAT，导致D-Link DI-7200上的MAC/IP绑定、ARP抗攻击、连接数控制及监控统计功能失效，对网络安全性及可管理性造成影响。

改造建议

综上所述，对车库咖啡网络提出如下改造建议：

统一调度接入资源：将8条ADSL线路进行整合，提高带宽利用率。从保护原有投资角度考虑，可使用两台D-Link DI-7200各接4条ADSL。开启其中一台上的DHCP、MAC/IP绑定及ARP抗攻击服务。
对应用进行识别、控制及分流：从车库咖啡“创新孵化器”的具体需求出发，结合日常顾客对互联网的使用习惯，针对应用设定不同的QoS及访问控制策略。同时可基于上述的双网关部署，实现关键应用及非关键应用分流。根据陈首席公布的认捐情况，可使用Panabit专业版实现此功能。
集中交换：局域网需实现物理上的统一，保证性能及可管理性，同时划分不同VLAN给创业团队、VIP用户及普通顾客使用。为简化Wi-Fi方案的部署难度，交换机需支持PoE供电。根据陈首席公布的认捐情况，可使用盛科交换机实现此功能。
部署企业级Wi-Fi解决方案：根据车库咖啡在Wi-Fi接入方面的复杂需求，需部署企业级Wi-Fi解决方案，以无线控制器+瘦AP的方式解决兼容性、可靠性及性能问题。建议开启多SSID特性，将VLAN划分策略延展至Wi-Fi接入层面。

关于车库咖啡（本节内容摘自百度百科）

车库咖啡于2011年4月开始营业，是一家以创业和投资为主题的咖啡厅，创业者只需每人每天点一杯咖啡就可以在这里享用一天的免费开放式办公环境。可以说，车库咖啡不仅是创业者的低成本办公场所，也是投资人的项目库。

车库咖啡的“常驻”创业团队大约有10个，并仍有新的团队不定期“入驻”。在过去半年时间内，车库咖啡已经促成12个创业团队获得天使投资。

车库咖啡的访客不仅有大量的创业者和投资人，还包括关注创新和创业的媒体记者。

本文链接

课程设置

2012-06-02T04:39:00Z

以下内容，总上课时间为340个课时！

一、Linux系统管理基础与进阶（RH033和RH133）:

1、操作系统发展史，系统架构平台概览；

2、Linux起源、理念、发展历史及各发行版；

3、Linux基础知识、命令、获得使用帮助及文件系统基础；

4、Linux用户、组及权限的基础与高级知识；

5、Bash基础及配置、标准I/O和管道；

6、文本处理工具的概念及vim编辑器的使用；

7、基本系统配置工具及管理工具的使用；

8、进程的查看及各种常见管理工具的使用；

9、文件的查及操作；

10、网络属性配置及网络客户端工具的使用；

11、Linux文件系统基础、进阶与高级管理；

12、软件包的配置及管理，rpm及yum的使用；

13、系统初始化、内核基础及内核的定制（定制、编译及安装使用新内核）；

14、X11、SSH、VNC、CUPS系统服务及cron计划任务；

15、LVM、RAID等文件系统高级管理工具的概念及应用；

16、Red Hat Linux系统自动化安装（kickstart文件及安装盘的定制）；

17、Linux常见系统及网络故障排除（Trouble Shooting）；

18、Redhat Enterprise Linux系统定制式精简，实现从零开始按需重组大小、功能等可定制的RHEL，并从微观角度理解Linux构成；

19、嵌入式系统的制作：10M大小，附带web等网络服务器功能；

20、LFS简介，及以同学实践为主实现系统构建

二、常见网络服务及安全管理（RH253和RHS333）:

1、系统性能/安全、安全威胁模型和保护方法；

2、系统服务访问控制及服务安全基础；

3、加密/解密及数据安全，openssl/gpg等安全工具的应用；

4、iptables/netfilter安全体系工具（包括连接追踪、网络地址转换、七层过滤等高级应用）；

5、DNS（BIND）服务配置基础、高级应用和安全，并实现以view为核心的适应国内运营商间解析接驳的智能DNS系统构建；

6、vsftpd、NFS和samba文件服务基础、安全配置及ftps等高级应用；

7、apache服务基础、虚拟主机及安全（https、suEXEC等），LAMP环境的定制及调优；

8、代理服务器的原理及其实现；以squid为例讲解正向代理、透明代理、反向代理及负载均衡、缓存层次性结构等原理及实现方法；

9、sendmail/postfix/dovecot等邮件服务工具的配置和应用，smtps、pop3s、imaps等高级安全应用的实现；以案例为基础讲解postfix、mysql、ldap、虚拟域、虚拟用户、身份验证、邮件加密、垃圾邮件过滤、邮件病毒过滤、WEB MAIL、POP、IMAP服务的整合应用；

10、帐号管理、可插入式认证模块（PAM）的配置及管理

三、Shell编程入门及进阶（穿插大量以实现系统自动化管理为目的脚本案例）：
1、bash基础及定制系统环境；

2、bash脚本编程基础、变量、参数及表达式；

3、循环及分支；

4、函数基础及高级应用；

5、字符串处理、文件操作及命令；

6、脚本调试及版本控制；

7、脚本编程及系统自动化管理；

8、窗口编程：dialog文本对话框命令及shell编程中的应用；

9、sed和awk编程基础及进阶；

四、数据库从入门到精通：

1、SQL基础及Mysql体系结构；

2、MySQL安装、启动、停止及配置；

3、数据库、表、视图和索引；

4、连接及子查询；

5、数据导入、导出；用户变量及触发器；

6、用户管理、字符集、数据库锁；

7、存储引擎、表维护；

8、数据备份及恢复；

9、查询、数据库及服务器优化；

10、MySQL Cluster、复制及高可用配置；

11、PhpMyAdmin、mysql-gui-tools和MySQL Front等第三方工具的使用；

12、基于Linux的Oracle服务器的安装、配置及简单应用；

五、集群/存储专题（包括RH436）:

1、系统集群体系结构、类型及应用方案；

2、Linux虚拟服务器LVS原理，详细讲解其类型、调度方法等；

3、LVS-NAT、LVS-DR的配置及以之实现web、smtp等负载均衡应用，并详细比较此两种实现方式的不同及各自的应用场景；

4、LVS持久性连接应用环境理论及实现；FW方式实现LVS的affinity应用；

5、编写bash脚本实现对realserver健康状态监控，实现realserver故障隔离及自动重新上线等功能；

6、高可用集群原理及Heartbeat、openais/corosync等解决方案的介绍；

7、Heartbeat安装、配置及以web为例实现高可用环境；

8、Hertbeat资源配置方式及维护；使用heartbeat-gui实现基于图形化方式对集群进行管理；

9、Stonith原理及其实现方法；

10、LVS和Heartbeat集成实现高可用director及负载均衡的大规模应用服务器集群，包括ldirectord的应用等；

11、RAID、NAS、SAN、iSCSI等存储原理及基于Linux的iSCSI服务器的实现及应用；讲解openfiler或freenas等开源解决方案的应用；

12、RHCS集群套件的原理及实现；从微观角度介绍其与前述解决方案的异同；

13、GFS集群文件系统的原理、应用及实现；

六、系统监控：

1、SNMP协议原理及Linux系统上的配置及实现应用案例；

2、系统服务监控模型及体系结构；

3、cacti安装、配置和高级应用；

4、ntop安装、配置及高级应用；

5、Nagios入门、进阶及高级应用；

6、整合cacti、ntop和Nagios构建企业级开源监控平台；
7、其它监控工具介绍

七、http代理加速及应用服务器：

1、Nginx入门、进阶、调优及LNMP的实现；nginx实现web反向代理；使用nginx实现web负载均衡应用；

2、Tomcat体系结构、安装配置、连接器及与apache的整合；

3、大规模、高并发、高可用web服务器群的体系结构、设计及其实现

八、安全相关高级话题：

1、Nmap扫描工具的原理及应用；

2、tcpdump、wireshark捕包工具的原理及应用；

3、Nessus系统安全漏洞评估工具的原理及应用；

4、网络入侵检测系统及Snort的安装、配置及应用；

5、主机入侵检测系统及OSSEC的安装、配置及应用；

6、VPN原理及OpenVPN安装、配置及应用

九、Linux系统原理基础及系统调优（RH442）:

1、Linux系统原理性知识基础及扩展；

2、系统性能监控及使用benchmark工具（如LMbench,IOzone等）对系统性能进行

十、职业素质课程：

1、职场礼仪；

2、简历撰写格式及要注意的问题；

3、面试流程、常见问题应对方式及模拟面试；
说明：以上列表只是以重点大纲的方式列出实训内容的要点，并非全部细节性内容；根据授课实际情况，内容可能会有所添加；

所用部分案例：案例1：以当下最新的版本的内核为标准实现Linux系统内核的定制、编译及应用；

案例2：一步步构建嵌入式Linux系统，并层层实现nsswitch、网络服务器等多种功能；

案例3：按照生产环境的需求编译安装LAMP系统，其中包括定制编译 Apache、mysql、php、perl等服务，并对LAMP系统进行性能调优；

案例4：tomcat服务器安装配置、apache与tomcat整合

案例5：tomcat集群的实现；

案例6：使用LVS实现多种服务器集群，如apache,vsftpd,postfix等多种服务器集群；

案例7：Heartbeat实现高可用的web集群和LVS集群；

案例8：整合LVS和Heartbeat实现具有负载均衡和高可用功能的web服务器集群架构；

案例9：Linux防火墙netfilter高级扩展应用，第三方功能模块编译（如l7filter），内核模块编译及高级安全策略的定制；

案例10：Linux防火墙与squid整合搭建多功能智能网关其中包括企业常用的透明网关、入站连接、Web内容过滤、反向代理负载均衡等；

案例11：基于Linux的企业级电子邮件系统解决方案：postfix、mysql、openldap、虚拟域、虚拟用户、身份验证、邮件加密、垃圾邮件过滤、邮件病毒过滤、WEB MAIL、POP、IMAP服务的整合及实现；

案例12：Linux下实际企业监控平台多种解决方案，其中包括ntop、cacti、nagios、短信报警等

案例13：以snort实现IDS入侵检测系统；

案例14：Linux存储技术实践，其中包括iSCSI及开源工具openfiler的使用；

案例16：Linux下MYSQL数据库的常用维护操作、用户管理、权限设置、数据备份恢复、数据导入导出等

案例17：Linux下MYSQL的双机热备、复制实践；

案例18：Linux下ORACLE数据库服务器的配置安装；

案例19：redhat集群套件RHCS构建常见的集群服务；

案例20：Nessus构建系统安全漏洞评估环境，并实现对实验网络环境的安全评估；

案例21：系统性能瓶颈分析及解决方案的设计；

本文链接

运维工程师的职责和前景

2012-06-02T04:36:00Z

运维中关键技术点解剖：1 大量高并发网站的设计方案；2 高可靠、高可伸缩性网络架构设计；3 网站安全问题，如何避免被黑？4 南北互联问题,动态CDN解决方案；5 海量数据存储架构

一、什么是大型网站运维？

首先明确一下，全文所讲的”运维“是指：大型网站运维，与其它运维的区别还是蛮大的；然后我们再对大型网站与小型网站进行范围定义，此定义主要从运维复杂性角度考虑，如网站规范、知名度、服务器量级、pv量等考虑，其它因素不是重点；因此，我们先定义服务器规模大于1000台，pv每天至少上亿（至少国内排名前10），如sina、baidu、QQ，51.com等等；其它小型网站可能没有真正意义上的运维工程师，这与网站规范不够和成本因素有关，更多的是集合网络、系统、开发工作于一身的“复合性人才”，就如有些公司把一些合同采购都纳入了运维职责范围，还有如IDC网络规划也纳入运维职责。所以，非常重要一定需要明白：运维对其它关联工种必须非常了解熟悉：网络、系统、系统开发、存储，安全,DB等；我在这里所讲的运维工程师就是指专职运维工程师。

我们再来说说一般产品的“出生”流程：

1、首先公司管理层给出指导思想，PM定位市场需求（或copy成熟应用）进行调研、分析、最终给出详细设计。

2、架构师根据产品设计的需求，如pv大小预估、服务器规模、应用架构等因素完成网络规划,架构设计等（基本上对网络变动不大，除非大项目）

3、开发工程师将设计code实现出来、测试工程师对应用进行测试。

4、好，到运维工程师出马了，首先明确一点不是说前三步就与运维工作无关了，恰恰相反，前三步与运维关系很大：应用的前期架构设计、软/硬件资源评估申请采购、应用设计性能隐患及评估、IDC、服务性能\安全调优、服务器系统级优化（与特定应用有关）等都需运维全程参与，并主导整个应用上线项目；运维工程师负责产品服务器上架准备工作，服务器系统安装、网络、IP、通用工具集安装。运维工程师还需要对上线的应用系统架构是否合理、是否具备可扩展性、及安全隐患等因素负责，并负责最后将产品（程序）、网络、系统三者进行拼接并最优化的组合在一起，最终完成产品上线提供用户使用，并周而复使：需求->开发（升级）->测试->上线（性能、安全问题等之前预估外的问题随之慢慢就全出来了）在这里提一点：网站开发模式与传统软件开发完全不一样，网站一天开发上线1~5个升级版本是家常便饭，用户体验为王嘛，如果某个线上问题像M$ 需要1年解决，用户早跑光了；应用上线后，运维工作才刚开始，具体工作可能包括：升级版本上线工作、服务监控、应用状态统计、日常服务状态巡检、突发故障处理、服务日常变更调整、集群管理、服务性能评估优化、数据库管理优化、随着应用PV增减进行应用架构的伸缩、安全、运维开发工作：

a 、尽量将日常机械性手工工作通过工具实现（如服务监控、应用状态统计、服务上线等等），提高效率。

b、解决现实中服务存在的问题，如高可靠性、可扩展性问题等。

c、大规模集群管理工具的开发，如1万台机器如何在1分钟内完成密码修改、或运行指定任务？2000台服务器如何快速安装操作系统？各分布式IDC、存储集群中数PT级的数据如何快速的存储、共享、分析？等一系列挑战都需运维工程师的努力。

在此说明一下其它配合工种情况，在整个项目中，前端应用对于网络/系统工程师来说是黑匣子，同时开发工程师职责只是负责完成应用的功能性开发，并对应用本身性能、安全性等应用本身负责，它不负责或关心网络/系统架构方面事宜，当然软/硬件采购人员等事业部其它同事也不会关心这些问题，各司其职，但项目的核心是运维工程师~！所有其它部门的桥梁。

上面说了很多，我想大家应该对运维有一些概念了，在此打个比方吧，如果我们是一辆高速行驶在高速公路上的汽车，那运维工程师就是司机兼维修工，这个司机不简单，有时需要在高速行驶过程中换轮胎、并根据道路情况换档位、当汽车速度越来越快，汽车本身不能满足高速度时对汽车性能调优或零件升级、高速行进中解决汽车故障及性能问题、时刻关注前方安全问题，并先知先觉的采取规避手段。这就是运维工作~！

最后说一下运维工程师的职责：”确保线上稳定“，看似简单，但实属不容易，运维工程师必须在诸多不利因素中进行权衡：新产品模式对现有架构及技术的冲击、产品高频度的升级带来的线上BUG隐患、运维自动化管理承度不高导致的人为失误、IT行业追求的高效率导致流程执行上的缺失、用户增涨带来的性能及架构上的压力、IT行业宽松的技术管理文化、创新风险、互联网安全性问题等因素，都会是网站稳定的大敌，运维工程师必须把控好这最后一关，需具体高度的责任感、原则性及协调能力，如果能做到各因素的最佳平衡，那就是一名优秀的运维工程师了。

另外在此聊点题外话，我在这里看到有很多人要sina、QQ、baidu,51.com等聊自已的运维方面的经验，其实这对于它们有点免为其难：

a、各公司自已网络架构、规模、或多或少还算是公司的核心秘密，要保密，另外，对于大家所熟知的通用软件、架构，由于很多公司会根据自已实际业务需要，同时因为原版性能、安全性、已知bug、功能等原因，进行过二次开发（如apache,php,mysql ），操作系统内核也会根据不同业务类型进行定制的，如某些应用属于运算型、某些是高IO型、或大存储大内存型。根据这些特点进行内核优化定制，如sina就在 memcache上进行过二次开发，搞出了一个MemcacheDB，具体做得如何我们不谈，但开源了，是值得称赞的，国内公司对于开源基本上是索取，没有贡献；另外，服务器也不是大家所熟知的型号，根据业务特点，大部份都是找DELL/HP/ibm进行过定制；另外，在分布式储存方面都有自已解决方案，要不就是使用现成开源hadoop等解决方案，或自已开发。但90%都是借鉴google GFS的思想:分布式存储、计算、大表。

b、各公司业务方向不一样，会导致运维模式或方法都不一样，如51.com和baidu运维肯定区别很大，因为他们业务模式决定了其架构、服务器量级、 IDC分布、网络结构、通用技术都会不一样，主打新闻门户的sina与主打sns的51.com运维模式差异就非常大,甚至职责都不大一样；但有一点，通用技术及大致架构上都大同小异，大家不要太神化，更多的公司只是玩垒积木的游戏罢了，没什么技术含量。

c、如上面所讲，目前大型网站运维还处于幼年时期理念和经验都比较零散，没有成熟的知识体系，可能具体什么是运维，大家都要先思索一番，或压根没想过，真正讨论也只是运维工作的冰山一角，局限于具体技术细节，或某某著名网站大的框架，真正运维体系化东西没有，这也许是目前网上运维相关资料比较少的原故吧。或者也是国内运维人员比较难招，比较牛的运维工程师比较少见的原因之一吧。

二、运维工作师需要什么样的技能及素质

做为一名运维工程师需要什么样的技能及素质呢，首先说说技能吧，如大家上面所看到，运维是一个集多IT工种技能与一身的岗位，对系统->网络 ->存储->协议->需求->开发->测试->安全等各环节都需要了解一些，但对于某些环节需熟悉甚至精通，如系统 (基本操作系统的熟悉使用,*nix,windows ..)、协议、系统开发(日常很重要的工作是自动运维化相关开发、大规模集群工具开发、管理）、通用应用（如lvs、ha、web server 、db、中间件、存储等）、网络,IDC拓朴架构；

技能方面总结以下几点：

1、开发能力，这点非常重要，因为运维工具都需要自已开发，开发语言：perl、python、php（其中之一）、shell（awk,sed,expect….等），需要有过实际项目开发经验，否则工作会非常痛苦。

2、通用应用方面需要了解：操作系统（目前国内主要是linux、bsd）、webserver相关(nginx,apahe,php,lighttpd,java。。。)、数据库(mysql,oralce)、其它杂七八拉的东东；系统优化，高可靠性；这些只是加分项，不需必备，可以边工作边慢慢学，这些东西都不难。当然在运维中，有些是有分工偏重点不一样。

3、系统、网络、安全，存储，CDN，DB等需要相当了解，知道其相关原理。

个人素质方面：

1、沟通能力、团队协作：运维工作跨部门、跨工种工作很多，需善于沟通、并且团队协作能力要强；这应该是现代企业的基本素质要求了，不多说。

2、工作中需胆大心细：胆大才能创新、不走寻常路，特别对于运维这种新的工种，更需创新才能促进发展；心细，运维工程师是网站admin,最高线上权限者，一不小心就会遗憾终生或打入十八层地狱。

3、主动性、执行力、精力旺盛、抗压能力强：由于IT行业的特性，变化快；往往计划赶不上变化，运维工作就更突出了，比如国内各大公司服务器往往是全国各地，哪里便宜性价比高，就那往搬，进行大规模服务迁移（牵扯的服务器成百上千台），这是一个非常头痛的问题；往往时间非常紧迫，如限1周内完成，这种情况下，运维工程师的主动性及执行力就有很高的要求了：计划、方案、服务无缝迁移、机器搬迁上架、环境准备、安全评估、性能评估、基建、各关联部门扯皮,7X24小紧急事故响应等。

4、其它就是一些基本素质了：头脑要灵光、逻辑思维能力强、为人谦虚稳重、亲和力、乐于助人、有大局观。

5、最后一点，做网站运维需要有探索创新精神，通过创新型思维解决现实中的问题，因为这是一个处于幼年的职业（国外也一样，但比国内起步早点），没有成熟体系或方法论可以借鉴，只能靠大家自已摸索努力。

三、怎样才算是一个合格的运维工程师

1、保证服务达到要求的线上标准，如99.9%；保证线上稳定，这是运维工程师的基本责职所在。

2、不断的提升应用的可靠性与健壮性、性能优化、安全提升；这方面非常考验主动性和创新思维。

3、网站各层面监控、统计的覆盖度，软件、硬件、运行状态，能监控的都需要监控统计，避免监控死角、并能实时了解应用的运转情况。

4、通过创新思维解决运维效率问题；目前各公司大部份运维主要工作还是依赖人工操作干预，需要尽可能的解放双手。

5、运维知识的积累与沉淀、文档的完备性，运维是一个经验性非常强的岗位，好的经验与陷阱都需积累下来，避免重复性范错。

6、计划性和执行力；工作有计划，计划后想法设法达到目标，不找借口。

7、自动化运维；能对日常机械化工作进行提炼、设计并开发成工具、系统，能让系统自动完成的尽量依靠系统；让大家更多的时间用于思考、创新思维、做自已喜欢的事情。

以上只是技术上的一些层面，当然个人意识也是很重要的。

四、运维职业的迷惘、现状与发展前景

运维岗位不像其它岗位，如研发工程师、测试工程师等，有非常明确的职责定位及职业规划，比较有职业认同感与成就感；而运维工作可能给人的感觉是哪方面都了解一些，但又都比上专职工程师更精通、感觉平时被关注度比较低（除非线上出现故障），慢慢的大家就会迷惘，对职业发展产生困惑,为什么会有这种现象呢？除了职业本身特点外，主要还是因为对运维了解不深入、做得不深入导致；其实这个问题其它岗位也会出现，但我发现运维更典型，更容易出现这个问题；

针对这个问题我谈一下网站运维的现状及发展前景（也在思考中，可能不太深入全面，也请大家斧正补充）

运维现状：

1、处于刚起步的初级阶段，各大公司有此专职，但重视或重要程度不高，可替代性强；小公司更多是由其它岗位来兼顾做这一块工作，没有专职，也不可能做得深入。

2、技术层次比较低；主要处于技术探索、积累阶段，没有型成体系化的理念、技术。

3、体力劳动偏大；这个问题主要与第二点有关系，很多事情还是依靠人力进行，没有完成好的提练，对于大规模集群没有成熟的自动化管理方法，在此说明一下，大规模集群与运维工作是息息相关的如果只是百十来台机器，那就没有运维太大的生存空间了。

4、优秀运维人才的极度缺乏；目前各大公司基本上都靠自已培养，这个现状导致行业内运维人才的流动性非常低，非常多好的技术都局限在各大公司内部，如 google 50万台机器科学的管理,或者国内互联公司top 10 的一些运维经验，这些经验是非常有价值的东西并决定了一个公司的核心竞争力；这些问题进而导致业内先进运维技术的流通、贯通、与借签，并最终将限制了运维发展。

5、很多优秀的运维经验都掌握在大公司手中；这不在于公司的技术实力，而在于大公司的技术规模、海量PV、硬件规模足够大，如baidu可怕的流量、 51.com海量数据~~~~这些因素决定了他们遇到的问题都是其它中/小公司还没有遇到的，或即将遇到。但大公司可能已有很好的解决方案或系统。

发展前景：

1、从行业角度来看，随着中国互联网的高速发展（目前中国网民已跃升为全球第一）、网站规模越来越来大、架构越来越复杂；对专职网站运维工程师、网站架构师的要求会越来越急迫,特别是对有经验的优秀运维人才需求量大，而且是越老越值钱；目前国内基本上都是选择毕业生培养（限于大公司），培养成本高，而且没有经验人才加入会导致公司技术更新缓慢、影响公司的技术发展；当然，毕业生也有好处：白纸一张，可塑性强，比较认同并容易融入企业文化。

2、从个人角度，运维工程师技术含量及要求会越来越高，同时也是对公司应用、架构最了解最熟悉的人、越来越得到重视。

3、网站运维将成为一个融合多学科（网络、系统、开发、安全、应用架构、存储等）的综合性技术岗位，给大家提供一个很好的个人能力与技术广度的发展空间。

4、运维工作的相关经验将会变得非常重要，而且也将成为个人的核心竞争力，具备很好的各层面问题的解决能力及方案提供、全局思考能力等。

5、特长发挥和兴趣的培养；由于运维岗位所接触的知识面非常广阔，更容易培养或发挥出个人某些方面的特长或爱好，如内核、网络、开发、数据库等方面，可以做得非常深入精通、成为这方面的专家。

6、如果真要以后不想做运维了，转到其它岗位也比较容易，不会有太大的局限性。当然了，你得真正用心去做。

7、技术发展方向：网站/系统架构师。

五、运维关键技术点解剖

1、大规模集群管理问题

首先我们先要明确集群的概念，集群不是泛指各功能服务器的总合，而是指为了达到某一目的或功能的服务器、硬盘资源的整合（机器数大于两台），对于应用来说它就是一个整体，目前常规集群可分为：高可用性集群（HA），负载均衡集群（如lvs），分布式储、计算存储集群（DFS，如google gfs ,yahoo hadoop），特定应用集群（某一特定功能服务器组合、如db、cache层等），目前互联网行业主要基于这四种类型；对于前两种类似，如果业务简单、应用上post操作比较少，可以简单的采用四层交换机解决（如f5），达到服务高可用/负责均衡的作用，对于资源紧张的公司也有一些开源解决办法如lvs+ha,非常灵活；对于后两种，那就考验公司技术实力及应用特点了，第三种DFS主要应用于海量数据应用上，如邮件、搜索等应用，特别是搜索要求就更高了，除了简单海量存储，还包括数据挖掘、用户行为分析；如 google、yahoo就能保存分析近一年的用户记录数据，而baidu应该少于30天、soguo就更少了。。。这些对于搜索准备性、及用户体验是至关重要的。

接下来，我们再谈谈如何科学的管理集群，有以下关键几点：

I、监控

主要包括故障监控和性能、流量、负载等状态监控，这些监控关系到集群的健康运行，及潜在问题的及时发现与干预；

a、服务故障、状态监控：主要是对服务器自身、上层应用、关联服务数据交互监控；例如针对前端web server，我们就可以有很多种类型的监控，包括应用端口状态监控，便于及时发现服务器或应用本身是否crash、通过icmp包探测服务器健康状态，更上层可能还包括应用各频道业务的监控，常用方法是采用面业特征码进行判断，或对重点页面进行签名，以网站被黑篡改（报警、并自动恢复被篡改数据）等等，这些只是一部份，还有N多监控方式，依应用特点而定，还有一些问题需解决，如集群过大，如何高性能的进行监控也是一个现实问题。

b、其它就是集群状态类的监控或统计，为我们合理管理调优集群提供数据参考、包括服务瓶颈、性能问题、异常流量、攻击等问题。

II、故障管理

a、硬件故障问题；对于成百上千或上万机器的N多集群，服务器死机、硬件故障概率是非常大的，几乎每时每刻都有服务硬件问题，死机、硬盘损坏、电源、内存、交换机。针对这种情况，我们在设计网站架构时需要充分考虑到这些问题，并将其视为常态；更多的依靠应用的冗余机制来规避这种风险，但给系统工程师足够宽裕的处理时间。（如google不是号称同时死800台机器，服务不会受到任何影响吗）；这就是考验运维工程师及网站架构师功能的地方了，好的设计能达到google所描述自恢复能力，如gfs，糟糕的设计那就是一台服务器的死机可能会造成大面积服务的连锁故障反映，直接对用户拒绝响应。

b、应用故障问题；可能是某一bug被触发、或某一性能阀值被超越、攻击等情况不一而定，但重要的一点，是要有对这些问题的预防性措施，不能想当然，它不会出问题，如真出问题了，如何应对？这需要运维工程师平时做足功夫，包括应急响应速度、故障处理的科学性、备用方案的有效等。

III、自动化

自动化：简而言之，就是将我们日常手动进行的一些工作通过工具，系统自动来完成，解放我们的双手及枯燥的重复性劳动，例如：没有工具前，我们安装系统需要一台一台裸机安装，如2000台，可能需要10人/10天，搞烂N张光盘，人力成本更大。。。而现在通过自动化工具，只需几个简单命令就能搞定、还有如机器人类程序，自动完成以往每天人工干预的工作，使其自动完成、汇报结果，并具备一定的专家系统能力，能做一些简单的是/非判断、优化选择等。。。这些好处非常明显不再多说。。。应该说，自动化运维是运维工程师职业化的一个追求，利已利公，虽然这是一个异常艰巨的任务：不断变更的业务、不规范化的应用设计、开发模式、网络架构变更、IDC变更、规范变动等因素，都可能会对现有自动化系统产生影响，所以需要模块化、接口化、变因参数化等因此，自动化相关工作，是运维工程师的核心重点工作之一，也是价值的体现。

本文链接

腾讯网络：架构之美--开放环境下的网络架构

2012-06-02T03:41:00Z

另外参见：http://www.chinaz.com/manage/2012/0516/251955.shtml

微信技术总监周颢：一亿用户背后架构秘密

腾讯大讲堂

腾讯业务的飞速发展，对网络等基础设施提出了海量运营的要求。同时，数量众多、且型态各异的业务，所要求的网络服务也各不相同……这些都是对网络架构提出的巨大挑战（图1——网络架构面对的挑战）。

图1——网络架构面对的挑战

2010年，腾讯推出了开放平台，所有平台开发者及合作伙伴的应用都可以在此平台上成长和发展，与此同时，这对计算资源及网络资源提出了更高的要求。经过不断的探索与总结，最终得出：支撑腾讯开放云平台的网络架构，必须要做到以下三点：

1．网络基础设施要健壮强劲；

2．网络要适应多租户接入需求；

3．用户网络覆盖质量要好。

在深入探寻如何实现以上三点前，需要先基本了解腾讯网络架构。

腾讯的网络架构不是一天构造而成、并具备支撑海量业务能力的，而是随着业务的成长逐步发展起来的。在不断发展的十多年期间，随着业务在种类和容量上爆发式的增长，基础网络在技术、容量和架构上也在不断提升，其提升的步伐甚至大于业务需求的步伐。因为只有这样，才能打造一个稳健可靠的、服务于公司各项业务的网络架构平台。

发展至今，我们已有数十人的运营支撑团队、数十人的专业设计构架团队，共支撑超过20万台服务器。网络设备达上万台，具备业界领先的5000台规模计算集群数据中心网络v3.5，搭建百G总容量的广域网络，支撑全国和海外数十个大中型IDC（图2——网络平台构建，与业务共成长）……

图2——网络平台构建，与业务共成长

此网络架构示意图（图3——网络架构示意图）中整体展示了我们的网络架构：从数据中心内部的网络到用于IDC互联的城域网络及广域网络，以及与运营商互联的出口等。

图3——网络架构示意图

尽管现在的网络架构平台有了很大的改进和提升，但团队的努力没有停留于此。我们继续在架构和运营上不断优化提升，从“作坊式定制化的企业型网络”向“海量计算集群网络及智能自定义网络”努力！从“纯手工式故障发现排除”向“全面监控智能化网络”及“运营商级稳定网络”努力！

网络基础设施要健壮强劲

解决早期IDC网络架构老大难题：

早期的IDC网络架构主要存在四大问题：

1. 杂：网络专区过多，特色服务难以快速满足；

2. 乱：网络稳定性欠缺，存在单播flooding；

3. 弱：网络性能难以满足需求，过高超载使得服务器获得的带宽较小；

4. 慢：网络层次和设备多样，标准程度不高，难以满足快速建设需求；

面对这四大问题，腾讯团队重新思考了老版本架构面临新时代挑战所存在的弊端、并对下一代网络产品引入的可行性做了评估之后，参考Google等大牛级架构设计、结合自身产品和企业特点，逐步构建成了具有历史意义的v3.5 IDC网络架构版本（图4——腾讯V3.5数据中心网络）。同时，CLOS架构（http://en.wikipedia.org/wiki/Clos_network）理念的引入，让未来在此版本上持续的scale out也找到了数模依据。

图4——腾讯V3.5数据中心网络

网络，稳定压倒一切！

如果几万台服务器分布在一个城市的几十个IDC，上千种业务在约100条万兆互联链路上产生约700G的跨IDC洪流，每一次故障都会直接影响到用户，这种后果是非常严重的。为保障服务长期稳健运行，腾讯构建了运营商级别的城域和广域网络（图5——运营商级别的城域和广域网络）。

图5——运营商级别的城域和广域网络

城域网采用标准化结构，构建承载力强、冗余性高的健壮城域网络。构建成上T级汇聚能力、百G级站点交互能力，自建大容量、高可靠传输系统的城域网。

广域网主要从架构规整化及能力上大幅提升，就像建造能连接全国范围IDC的高速铁路和高速公路一样，为业务全国分布做好准备。同时，将广域网监控精细化，使业务看得见、有意识、重协作，同时要想高铁VIP一等座和普通座的划分一样对重点业务流量能够予以保障，提供差异化服务且使得资源效率高。

让网络看得见摸得着

为了保障网络的稳定可靠，真正实现能够看得见、管得住、用得好，团队自主研发了TMP系统（图6——腾讯自主研发TMP系统），实现了基础架构海量节点实时监控支持。TMP系统覆盖腾讯全量基础设施，如20W+服务器、2W+网络设备状态、性能、容量的实时采集与智能分析、1分钟存活状态监控、5分钟性能、容量监控，以及100+IDC、200+外网出口、500+内网专线，从IDC内部服务器到出口、专线FullMesh的5分钟粒度的全方位网络质量监控与度量体系。

同时，还具备腾讯基础设施7*24的运营入口-NOC，每天400w条的海量信息处理和+80%故障处理解决率，覆盖公司全业务的基础架构日常运营工作：业务安全防控、流量全局调度、业务质量检测及演戏预案等系列前瞻性运营工作，为海量业务提供高质量、全纬度的运营服务。

图6——腾讯自主研发TMP系统

新形态：多租户接入需求

开放平台的推出对全套的网络架构提出了更高的要求，IDC网络架构必须支持开发者、合作伙伴、自营业务等多种多样业务的需求。

目前， IDC网络架构v3.5可提供（图7——网络架构V3.5可提供服务）：

1. 适应自营业务和开放平台业务的多种多样需求，如高带宽/无阻塞通信、组播、Qos保障……

2. 云计算数据中心的安全服务。网络安全防护手段（VRF、VLAN ACL、PVLAN、基于标记的安全防护等）与硬件抽象层软防火墙/DFW与相结合为虚拟化环境提供所需的安全防护；

3. 整合网络资源，统一调度快速交付。云控制平台/Matrix实现30分钟交付虚拟机，通过自动化工具/例如云计算网络控制中心与Matrix对接，实现业务感知的网络资源调度，VM迁移时，相关的网络信息、网络安全策略、Qos策略统一调度。

图7——网络架构V3.5可提供服务

与此同时，我们与业界一同进行前沿性研究-SDN/自定义网络（图8——腾讯与业界的前沿性研究—SDN），以满足我们的IDC网络能够更加快速地实现业务所需的特性，更加灵活地平滑扩展。

图8——腾讯与业界的前沿性研究—SDN

用户网络覆盖质量要好

作为业务侧，对用户体验非常关心，也是网络架构最关注重点优化的一个方面。

由于业务“内容”在这里，而用户“眼球”在运营商侧，最终用户的访问体验受到很多我们无法掌控的因素所影响。据统计，运营商网络故障对腾讯的影响占比连年超过70%。

举个典型的例子，河南境内某处光缆中断，对我方西安某运营商出口造成中断，流量丢失40G左右。

所以要改善用户体验，为业务提供良好的网络覆盖质量，我们在三个方面进行努力：看清、对齐、布局。

看清 -- 点、线、面的网络质量监控

用户访问体验关系到诸多方面，用户->IDC外网质量，IDC内部网络质量，IDC间网络质量，我们在TMP系统中实现全方位立体化的网络质量监控。

对齐 -- 提前与运营商接口规划信息

运营商省网/城域网、骨干网等都是用户体验的关键环节，我们必须与运营商省/城公司、集团骨干公司提前对齐规划信息，确保各个环节都能够满足我们的容量和质量要求，其中包括运营商骨干网网络容量和质量、省网/城域网上联骨干网带宽容量和质量、省网/城域网网络容量和质量等。

布局 – 网络

在中国的运营商环境中，主力运营商间的互联互通及长期保持质量都较差，除内容至少复制两份之外，还有大批用户在其他运营商网内，在移动互联网大发展的时候，移动网内的用户体验非常关键。

所以在网络布局上，IDC和网络资源上尽可能多提供多运营商接入环境。采用诸多关键技术方案，为业务提供更多的运营商网络接入环境，并保障安全，例如：

1. 域名引导；

2. BGP、IPSLA等网络对接技术；

3. Netflow、Span等网络分析；

4. 负载均衡、流量调度技术；

5. Anti-DDoS等安全防护。

布局 – IDC资源

转变 “被动接受”的IDC资源布局模式。由于业界的IDC供给速度不足，在业务布局前需考虑是哪里有IDC，这样会导致业务部署碎片多、交互效率低、对用户覆盖质量达不到、需事后推动改善等问题。

要向“用户体验为首位”的资源布局思路转换，为业务提供质量覆盖良好且稳定的网络访问。

要建立好这个模型，我们必须深入了解并长期把脉中国的运营商网络环境，且深入了解我们的业务需求，而非眉毛胡子一把抓。针对这种情况，我们首先对业务进行了深入研究，将业务对用户访问体验进行分级，如下示例：

另外，对IDC全国用户的覆盖质量进行长期追踪、建立基线，以确保网络质量保持恒定，而且我们还要有能力推动运营商或自行解决不符合要求的网络覆盖质量。

针对这种情况，我们推出类似这样的模型，使得业务布局最精简，而且是对用户覆盖质量最好的。

通过“看清、对齐、布局”三个方面的改善，我们通过全方位立体的网络监控体系实时了解用户的最终体验情况，与运营商提前主动对齐规划、主动推动改善优化，并通过IDC和网络的布局，最终实现用户访问质量的长期良好状态。

总结

关于开放平台网络架构

1. 腾讯网络架构提供高效稳定、安全可靠的通信。IDC网络架构、城域及广域网络、出口网络、对外互联网络等采用运营商级别的设备和技术；网络架构为开放云平台提供虚拟化支持、合作伙伴安全隔离等定制化特性，在与业界共同探讨更加前言的解决方案，如SDN等；

2. 腾讯网络和基础设施具备海量运营的思路和能力。快速的IDC和网络资源建设供给能力支撑海量运营的监控系统及NOC窗口；

3. 腾讯网络架构作为基础设施整体解决方案的一部分将更加给力。深入理解业务需求，结合网络、平台系统提供综合整体解决方案；腾讯网络架构的优化，获公司级［2011年重大技术突破奖］；

4. 我们在与业界共同努力，积极探索适应互联网行业新的解决方案。

最后，关于网络架构发展的一些简单经验：

1. 业务布局与网络架构要沟通配合。业务的部署要考虑网络特点，否则需要练就乾坤大挪移。互联网业务的特点显著，需要网络特别关注，例如map/reduce；

2. 网络架构的步伐和规划要适当大于业务短期需求。因为网络本身庞大而包袱重，要为可能的海量爆发提前做好准备；

3. 网络要简单而优雅，掌握“架构之美”的度。不要追求技术极致，要考虑运维能力。

关于业务对腾讯开放平台网络的知晓：

1. 了解网络的真正用途。可靠而高质量地实现、负责业务对话、负责连接”眼球”；

2. 在腾讯云平台上的网络灵活自如。数据中心网络和承载网络，架构灵活支持伙伴接入和拓展；

3. 腾讯云网络海量支撑能力为我保驾护航。运营商级别的网络，优质的运营支撑。

文章来源：腾讯大讲堂

本文链接

完善Linux/UNIX审计将每个shell命令记入日志

2012-06-02T03:24:00Z

编者按：为了确保服务器的安全，保留shell命令的执行历史是非常有用的一条技巧。然而，shell虽然有历史功能，但是这个功能并非针对审计的目的而设计，因此很容易被用户篡改或是丢失。本文介绍的步骤能够帮助你将每个shell命令记入日志（你可以将本文和bash history logging攻防一文参考着阅读，看看攻防双方的思路有何不同）。本文作者David Douthitt是一位经验丰富的UNIX和Linux系统管理员，曾做过Linux发行版的打包工作，也是《Advanced Topics in System Administration》和《GNU Screen： A Comprehensive Manual》两本书的作者。以下为正文：

将用户执行的每个shell命令记入日志比最初想象的要来得困难。shell的历史功能原本旨在帮助用户使用以前用过的命令。我们都知道这种使用场合：你刚输入了一个长长的字段，可是拼错了一个字符。shell的历史让你可以改正这一个字符，而不必输入其余的所有字符。

然而， shell历史很难满足审计的目的。换言之，它不是为了确保系统安全而设计的。

对于bash shell来说，问题显得尤其困难，因为该shell的目的是，不管用什么办法，尽可能为用户简化生活——所以，它拥有所有的“花哨功能”（bells and whistles）。必须顾及所有这些多种功能，并且防止对历史文件进行更改。

Korn shell比较简单，使得保护shell的历史比较容易。

如果想要严加保管这些shell的历史，需要执行一系列的步骤。

首先，锁定shell的历史文件本身。更改它的属性，末尾只添加chattr +a .sh_history或chattr +a .bash_history。这样一来，就不可能删除或更改文件中的数据，连用户都无法改变属性——只有root用户才能改变。

其次，确保历史变量设置合理、无法更改。这些历史变量包括最重要的HISTFILE、HISTCOMMAND和HISTIGNORE。要做到这一点，使用shell的typeset命令，带-r选项，这使得指定的变量拥有只读属性。良好的操作规范是使所有历史环境变量都变为只读，比如：

export HISTCONTROL=

export HISTFILE=$HOME/.bash_history

export HISTFILESIZE=2000

export HISTIGNORE=

export HISTSIZE=1000

export HISTTIMEFORMAT=“%a %b %Y %T %z ”

typeset -r HISTCONTROL

typeset -r HISTFILE

typeset -r HISTFILESIZE

typeset -r HISTIGNORE

typeset -r HISTSIZE

typeset -r HISTTIMEFORMAT

HISTTIMEFORMAT是bash shell的扩展，将在历史文件中提供时间戳。

对于bash shell来说，你需要更改历史的一些标准选项：

shopt -s cmdhist

#设置cmdhist将把多行命令放入到单单一个历史行

shopt -s histappend

#设置histappend将确保被添加到历史文件，而不是像通常的做法那样覆盖历史文件。

另外对于bash shell来说，还要设置PROMPT_COMMAND：

PROMPT_COMMAND=“history -a”

typeset -r PROMPT_COMMAND

这是由于bash shell实际上把历史写入到内存中，历史文件仅在shell会话结束时加以更新。这个命令会把上一个命令附加到磁盘上的历史文件。

最后，创建一个SIGDEBUG陷阱，将命令发送到系统日志（syslog）。VMware的ESXi借助自己版本的ash shell已经具有这样的功能。简而言之，应创建一个把当前命令记入日志（从历史文件获取）的函数，然后用logger命令，把它发送到系统日志。这一步在bash shell和Korn Shell中都适用。

这些步骤有些冗长，不过在新版的bash和ksh中有一些新的功能特性，让这一切变得极其容易。GNU Bash在4.1版中添加了记入到系统日志中的功能，只需要编译shell的时候开启该功能即可激活。

自推出ksh93以来，Korn Shell就一直具有审计功能。类似bash 4.1，用户审计是一项编译时功能。想看看你所用的ksh93版本是否安装了审计功能，可以执行下列命令中的某一条：

echo ${.sh.version}

echo $KSH_VERSION

在Ubuntu 10.10中，我得到了来自ksh93的这个输出：

# echo ${.sh.version}

Version JM 93t+ 2009-05-01

如果审计功能开启，特征字符串（JM）还会有字母A（开启审计功能），可能还有字母L（开启针对用户的审计功能）。IBM Developer Works和Musings of an OS Plumber都刊有介绍Korn Shell审计的出色文章。

Bash shell含有审计功能的可能性也比较小。Ubuntu 10.10上的bash是4.1.5（1）版本。

对于仍在使用C shell（以及尤其是tsch）的用户，tcsh有一个变种名为“tcsh-bofh”，它支持记入到系统日志中。遗憾的是，tcsh-bofh并没有得到长期的维护。早在2010年1月，tcsh-bofh的FreeBSD端口就从FreeBSD端口树（port tree）去除了。

上述信息也可以在shell之外获取。比如有两个命令：lastcomm（来自Ubuntu Main软件仓库中的acct程序包）和auditctl（来自Ubuntu Universe软件仓库中的auditd程序包）。另外， Linux Journal在2002年刊发过一篇关于Linux进程统计的好文章。另外还有rootsh和snoopylogger这两个程序包，只是两者都不在Ubuntu软件仓库中。Rootsh好比是typescript的执行版本，而snoopylogger是你可以添加到用户环境的系统库。（这些方法有许多来自在serverfault.com上所提的一个问题，请参阅这个帖子。）

（原文：Logging every shell command）

本文链接

如何禁止IIS缓存静态文件（png、js、html等）

2012-06-02T03:22:00Z

禁止IIS缓存静态文件（png、js、html等）背景：

IIS为了提高性能，默认情况下会对静态文件js、html、gif、png等做内部缓存，这个缓存是在服务器iis进程的内存中的。IIS这么做在很大程度上可以提高静态文件的访问性能，在正常情况下只要静态文件更新了IIS也会更新缓存。但是如果更新的静态文件很多就有可能出现缓存不更新的情况。

弯路：

我遇到这样一个场景，服务器循环更新上万张股票行情图片，IIS也会对图片进行缓存，由于更新的频率很高，文件很多，就出现了IIS缓存文件超过几十分钟都无法更新的情况。

这时候直觉是浏览器对文件进行了缓存，于是就在IIS的目录上设置Http头：Cache-Control:no-cache，但是无济于事，浏览器请求服务器端得到的状态号是200，这可以说明浏览器确实是从服务器端得到了新的内容，而非读取浏览器本地缓存。

如何禁止IIS缓存静态文件（png、js、html等）：

通过设置Http头不让浏览器缓存的方法在这个场景下是行不通的，因为缓存不是出现的客户端，而是出现在IIS服务器上；所以解决问题还需要从IIS本身入手，通过配置Metabase.xml文件禁止IIS缓存相应目录下的静态文件。

1. 首先需要设置IIS允许运行时编辑Metabase.xml文件

打开IIS，然后打开IIS属性页，勾选上“允许直接编辑配置数据库”选项

2. 在运行中输入notepad c：\WINDOWS\system32\inetsrv\MetaBase.xml 打开IIS配置文件

3. 在文件中搜索要配置禁止缓存的虚拟目录名字，找到类似如下配置节

在IIsWebVirtualDir配置节中添加 MD_VR_NO_CACHE=”1“ 属性

4. 保存配置文件，重启IIS即可。

如果想配置服务器上的所有站点都禁用IIS缓存可以通过修改注册表实现：

编辑注册表中的 DisableStaticFileCache值，0为启用，1为禁用，该键值的位置位于：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\InetInfo\Parameters

如果该键不存在可以新建。

注意事项：

通常情况下我们并不需要禁用IIS的静态文件缓存，iis会自动根据静态文件的修改时间自动更新缓存；只有在你遇到非常情况下才有必要禁用IIS缓存。IIS缓存和Http缓存相关头没有任何关系，在IIS上加缓存头没有办法清除掉IIS对静态文件的缓存。

本文链接

PHP环境的搭建之利器 – APMServ

2012-06-02T03:19:00Z

今天讲本地php环境的搭建，主要是利用APMServ软件，不仅仅简单，而且是快速。

PHP环境的搭建 – APMServ

APMServ是一款快速搭建Apache2.2.X、PHP5.2.X、MySQL5.1.X&4.0.26、Nginx、Memcached、phpMyAdmin、OpenSSL、SQLite、ZendOptimizer，以及ASP、CGI、Perl网站服务器平台的绿色软件，并拥有跟IIS一样便捷的图形管理界面。

APMServ的官方【请点我】

APMServ的下载地址【请点我】

APMServ的安装

在我们把APMServ下载回来以后，是一个ZIP的压缩包，那么我们把这个压缩版解压，然后会得到一个 APMServ5.2.6_zip.exe ，如下图

然后我们双击APMServ5.2.6_zip.exe，会出现下图

当然，其中的释放路径是不一样的（这个取决于你解压的目录），这个时候我们需要去改，点击浏览，我选择解压到H盘，当然，也可以解压到某个目录，这个根据自己选择（注意，其中的目录，一定不能有中文，因为my sql不支持中文），如下图：

然后点击释放。直到成功。然后我们进入到我们解压的目录，比如我解压的是H盘，那么我们进入H盘，并且进入APMServ5.2.6文件夹。

其中的APMServ.exe是主程序！双击打开，如下图

① 点击网站目录，然后选择第一个，也就是【打开默认Web目录】，点击以后，会跳出一个文件夹，里边有一个phpinfo.php的文件，这是一个PHP探针，是程序自带的，我们可以删掉，那么这个目录，就是用来放网站程序的，也就是htdocs目录，是放网站程序的目录。

② 在放完程序目录以后，我们就可以点击上图中的【启动APMServ】了，在状态中会提示成功或失败！如果失败，那是因为你的80端口被占用，这个时候，你需要关掉占用80端口的软件，比如迅雷。

③ 成功以后，就可以点击【访问用户本地网站】的按钮了，点击以后，就会弹出网页，也就是你程序的显示页面，也或许是安装页面。

④ 圈4这个按钮，是打开的phpmyadmin，用来管理my sql数据库的，默认的用户名是root，默认密码是空！如果是新手，那么暂且不需要考虑这个。

以上呢，就是利用APMServ来搭建PHP环境的步骤，其实非常简单哦。

文章作者：符号

来源地址：http://www.fuhao1990.com/2012051374.html

本文链接

博客园_新进化论

笔记本电源消耗测量

word编辑长文档方法

拨云见日：企业网络准入策略小议

转：车库咖啡网络现状及改造建议

课程设置

运维工程师的职责和前景

腾讯网络：架构之美--开放环境下的网络架构

完善Linux/UNIX审计 将每个shell命令记入日志

如何禁止IIS缓存静态文件（png、js、html等）

PHP环境的搭建之利器 – APMServ

完善Linux/UNIX审计将每个shell命令记入日志