编者的话 主编 杨赛 审阅 煮酒品茶 前一阵子同事引荐了一位神奇的Geek,高中没读完,大 学尚未毕业,之前搞微软的Windows Phone应用开发搞了 很久,后来Windows Phone升级8代,悲催的老硬件被永 久停留在7.8,于是怒而出离,开始做起了开源硬件的活 出版方 计。 51CTO系统频道 不过,这开源硬件还不是很多人想的那种绿色服务器或 是廉价PC那种的,而是另一种很有游戏气息的想法。 (os.51cto.com) 深深感觉到,IT界的年轻人开始崛起了。而且,IT界的方 向正变得越来越广阔。十年前,IT工种无非C/Java开发,网 络管理员,系统管理员;现在,Web已经是主流,移动化也 出版日期 是趋势,一名运维管理上万台Linux服务器也不算啥,很多 每个月的第2个星期五 老知识体系正在不断地被边缘化。 不少运维在聊天的时候反映说在学习开发,感觉单纯做 运维,发展方向太过狭隘。这也是现在整个IT技术界的一个 邮件订阅 大趋势吧。 ■ ht tp://os.51ct o.com / ——lazycai art/201011/233915.htm RSS订阅(最早发布) http://www.51cto.com/ php/rss.php?typeid=777 《Linux运维趋势》是由51CTO系统频道策划、针对 Linux/Unix系统运维人员制作的一份开放的电子杂志, iPad订阅 内容从基础的技巧心得、实际操作案例到中、高端的运 《读览天下》客户端 维技术趋势与理念等均有覆盖。我们的所有内容均收集 整理自国内外互联网,每篇文章都会严格标注出处与作 者,同时编辑也会尽力联系每一篇文章的原作者进行确 联系电话 认。如果您认为本杂志的内容侵犯到了您的版权,可发 信至[email protected]进行投诉。 010-68476606-8035
目录 本月推荐 19 Zimbra邮件系统安装与使用过程中 各种报错与问题的详细解决方法 04 天涯的运维之路 文/heminjie 文/周小军 22 一次被黑经历与一些反思 06 系统管理员该学什么语言? 文/old_hoodlum 文/Tom Limoncelli 编译/核子可乐 28 又一次运维,恶意 js 脚本注入访问 技术分享 伪随机域名 文/尘埃落定 08 还在使用6年前的设备?你需要叉车 式升级 观察思考 文/ Henry Newman 编译/布加迪 30 如何熟悉一个开源项目? 10 腾讯后台开发技术总监浅谈过载保护 文/庄周梦蝶 小心雪崩效应 文/mysqlops 31 四个新的 HTTP 状态码 文/红薯 12 一个DBA眼中的HBase 文 / vogts 32 云计算时代,运维人你们准备好了 吗? 14 异构存储系统数据迁移步骤分享 文/杨赛 文/miskey07 15 iptables自动封杀暴力破解(Qmail 邮件系统)者的IP地址 文/sfzhang88
本月推荐 天涯的运维之路 文/周小军 天涯社区是一个典型的中型互联网公司,目前的 遇太低,跳槽去了省级报社),面对访问量一大就崩 现状为: 溃的天涯网站,我们开始和技术团队一起开始了天涯 运维的第一阶段,架构扩展阶段。 1、千台服务器规模,近10G的流量,日PV亿 级,每秒用户会话几千; 天涯是个动态内容网站,所有的内容直接从数据 库生成,也就是说,用户每访问一个帖子,都会在应 2、2个数据中心,1个主机房,1个分时数据备 用服务器逻辑计算一次,在数据库后端生成一次事 份;还没有实现双机房冗余,即应用和数据的实时同 务,一天上百万的PV就是上百万的数据库事务,对 步; 应用和数据库压力非常之大。 3、运维团队规模不大,人员流动性大,要求运 我们当时参考了车东等网上技术大牛的博客,用 维工程师多面手; squid在前端做了被动内容缓存,应用层用ASP函数 4、业务繁杂,产品运维支持困难,产品变动 生成HTTP过期标记。帖子页面过期时间为5分钟。 大,服务器经常在不同的产品间相互变更。 squid初上线时的命中率为45%左右,不算高, 2002年我进入天涯,02年的天涯仅十多台服务 于是我 们又在sq uid 的前端加了一 层反向代理 器,1名sa。当时运维团队的重点是创收,所以运维 haproxy,使用haproxy通过url hash将指定的url由 团队的工作中,运维仅是一小部分。运维部门的重点 统一一组squid来支持。通过这样的策略,命中率提 工作是做项目搞创收。几年以来实施的项目有系统集 升到70%多。 成、网站开发和托管、机房建设等工程。 数据库扩展方面,我们用最简单的办法,分库。 比如海南省某银行的机房工程项目,从方案设计 原来的版块是一张表,分库后每一个版块是一个独立 到机房施工,包括布线、装修、消防、空调、新风、 的库,访问量大的版块甚至由一组独立的数据库服务 强电、防雷等几百平方米机房建设项目,全部由我们 器承载。早期的数据库平台是MSSQL Server,我 这支廖廖数人的队伍完成。 们用日志复制的方式来做双机,发布和分发服务器是 主,订阅服务器是从。 我们实施的网站开发与托管累计有数百个,运维 团队和技术团队共同在天涯运营最困难的时候,保住 后期迁移到Mysql后就更简单了,一组服务器由 了天涯顺利渡过互联网寒冬时期。 一台/二台master和多台slave组成。master负责 写,slave负责读。目前架构设计正在考虑通过 几年后,随着互联网复苏,天涯流量不断翻番, NOSQL的架构重新将所有版块库组成一个更大的, 运维部门逐渐从系统集成项目抽身而退,工作重心转 支持更高水平扩展的分布式虚拟数据库。 移到天涯网站的架构扩展及运维之上。 面对早期的windows服务器,运维团队很难对其 在天涯网站调整发展时,国内的互联网无论在网 进行自动化运维,所以当时sa最烦的事情就是软件部 站架构或是运维上资料极少,不象现在这么丰富。所 署、补丁升级、服务器重启及配置管理等重复劳动的 以我们只能是边摸索边测试边实践。 工作。当时的运维基本上靠手工和一些简单的运维工 具。 最早期的天涯是ASP+MSSQL Server的二层结 构,应用层通过ODBC直接访问后台数据库。产品功 随着天涯应用架构从ASP转向JSP,原来的 能设计非常简单,缺乏基础产品,例如没有搜索产 IIS+MSSQL+Windows平台也转向 品,标题搜索直接用like来匹配标题字段。这样的程 Resin+MySQL+Linux,此时的运维团队开始天涯 序实现在访问量一大时马上把数据库堵死。 运维的第二个阶段,平台转型阶段。 这个时期的运维团队仅有2个人(最早的sa因待 原来整个运维团队仅四五人,每个工程师均负责 04 本月推荐 Linux运维趋势 2012年6月号 总第20期
“天涯在虚拟化的过程中,主 要问题集中在网卡上。” 网络、数据库和系统职能。新阶段人员按职能组建成 拟化,即双路4核CPU,64G内存,6块SATA硬 3个组,分别负责系统、网络和数据库。每个组由各 盘。 组主管负责本组工作。简单的运维流程和管理规范也 随之成熟规范起来。 每个VM的实例为单核CPU、8G内存、100G磁 盘空间、100M网卡。我们没有使用统一存储,经过 天涯网络和应用架构在运维团队及技术团队的努 计算这样的性价比不高。VM的容错我们通过将VM 力下已经成熟稳定,前端是智能DNS和双线接入, 部署在不同的物理服务器实现。至于应用集群则通过 本地负载均衡采用F5-LTM 6400和LVS,反向代理 前端负载均衡解决。 采用Haproxy,页面内容缓存使用varnish替换了 squid,应用层为Nginx+esin,静态资源采用 经过二年多的虚拟化实践,虚拟化技术很好地解 Varnish+Nginx,数据级缓存采用Memcached, 决了天涯对各产品的快速支撑需求,特别是在仅有几 数据库为MySQL,中间层使用ICE和MQ。 名sa的运维团队中,支持了天涯几十个产品,上百个 应用的在线运行,为业务的扩展提供了便利。 这个时候的运维工具主要由sa手工来搭建。因工 程师人力不足,sa的日常工作重点是产品运维和排 虚拟化实践经历过一些挑战,比如2011年数据 障,所以大家都是通过晚上和周末见缝搜针地学习、 中心UPS掉电,一个楼层的服务器全部当机,虚拟化 开发和部署运维工具。 平台中有多台VM没有自动启动,后来由sa手工修改 了启动参数后才顺利启动VM,但虚拟化平台没有发 我们用cacti来做性能监控,nagios做主机监 生大规模故障,经受住了挑战。 控,用PHP+ssh实现远程管理,用ASP+MSSQL自 己写资产管理系统等。 天涯在虚拟化的过程中,主要问题集中在网卡 上。例如某台VM网络流量过大时,会影响其上的其 2009年,运维团队开始天涯运维的第三个阶 它VM,表现为网络有延迟或丢包。因此在新的服务 段,运维平台。 器硬件上我们采取了新的策略,采用多队列网卡应对 VM在网络方面的瓶颈。 2009年运维团队开始组建内部独立的运维开发 组,专门负责运维平台的规划和开发。运维开发组将 随着天涯虚拟化的不断深入,天涯的虚拟化应用 早期零散的运维工具和资源统一起来,重新开发一套 越来越广泛,目前天涯的VM已经占了天涯服务器总 平台化的天涯运维系统。 数的四成以上。现在天涯的虚拟化正从XEN迁移到 KVM。 已完成的天涯运维系统有资源中心、监控中心、 数据库信息管理、网络设备管理、性能监控、容量规 未来的天涯运维方向将重点在公司私有云的技术 划、远程操作、应用发布、LVS管理、Puppet配置 实现和运维上。我所理解的私有云由虚拟化+虚拟存 管理、虚拟机管理、Haproxy管理等功能模块。 储+大二层网络+分布式数据库+自动化运维几个重要 构件组成。这需要在云计算方面投入研发资源,同时 正在开发及计划开发的有软件包管理、应用和业 在开源平台上进行二次开发。 务监控、流程管理、工单管理、数据库管理等功能模 块。在运维管理平台的开发上,我们借鉴了大互联网 私有云的实践对运维工程师提出了更高的要求和 公司的运维平台,同时结合天涯本身的业务和产品特 挑战,运维工程师要达到devops的境界,并且更深 点,量身定制,走一条适合自己的路。 入地理解私有云架构才能实现对私有云的运维能力。 为了提升硬件的使用效率,解决产品快速扩容及 所以我们的运维团队首先是学习型团队,团队成 缩容的问题,加快服务器部署时间,提升sa对产品的 员的成长是我们最看重的团队目标。每个工程师必须 快速支持,2009年运维团队开始尝试使用虚拟化技 有自己清晰的职业生涯规划,不断在职业成长中实现 术。在经过测试和实践后,我们使用了XEN来实施虚 个人的近中远期目标。 ■ 拟化,并使用性价比最高的服务器硬件方案来实施虚 原文:http://millerzhou.blog.51cto.com/5275815/896938 投稿信箱:[email protected] 05
系统管理员该学 什么语言? 文/Tom Limoncelli 编译/核子可乐 最近有人问我:系统管理员该学什么语言。 选择Perl、Python还是Ruby,这通常取决于贵 公司已经在使用什么语言。Ruby和Python最近变得 如果你是一名Windows系统管理员,那么答案很 比Perl更为流行,所以许多公司重点关注Perl。如果 简单:该学PowerShell。 你使用Puppet,那么熟悉Ruby将有助于你熟练运用 如果你是Unix/Linux系统管理员,答案就比较复 Puppet。我在谷歌工作,这家公司很看重Python, 杂,因为有更多的选择。我不想引发一场“语言大 于是我进入谷歌后学习了这门语言。对于自1991年 战”,而是想说: 以来就熟悉Perl的本人来说,这的确是一次不容易的 学习过程(最近有人告诉我Perl在1991年还没有出 我认为,每一个Unix/Linux系统管理员都应该知 现……我建议他不妨查查维基百科)。 道外壳程序(sh或bash ),另外还要知道 Perl、Ruby或Python当中的某一门语言。至于学哪 从职业管理的角度来看,我认为真正擅长其中一 一门语言,并不重要。 门语言,对另外两门语言有所涉猎,这至关重要;哪 怕这意味着仅仅阅读介绍这些语言的书籍的头几个章 在我看来,上面这番话比我认为Perl、Python或 节。真正擅长其中一门语言意味着,你深入了解如何 Ruby哪门语言更优秀或者哪门语言有更多的职位空 运用该语言,深入了解该语言在“底层”是怎么一回 缺(或者使用其他任何标准)来得重要。容我细细解 事,那样你在设计更大型的程序时,就能作出更合理 释: 的决策。我之所以把这个问题上升到职业管理问题的 层面来讨论,原因在于,如果你想受雇于一家使用不 学习bash确实蛮重要,因为bash对于你许多方 同语言的公司,“成为愿意学习不同语言的专家”远 面的工作来说极其重要。无论是调试/etc/init.d脚 比“成为只想学习大有潜力的语言”或“对这门或那 本,还是编写一个小型包装器。每一个Unix/Linux 门语言一知半解,但是从来没有耐心把某一门语言学 系统管理员都应该知道:如何执行for循环、while循 好的人”来得重要。 ■ 环、if with [[或[、$1、$2、$3... $*和$@以及case 语句,还要明白变量代换是怎么一回事,如何处理简 单的命令行标记。只有掌握了那些基本的东西,你才 能继续深入一步。我惊讶地发现,我结识的不少人接 触了好多的Unix/Linux,却不会用bash来执行循 环;他们迟早会为没有尽早学习bash而自责不迭。 原文: http://everythingsysadmin.com/2012/06/salang.html 译文: http://os.51cto.com/art/201206/340820.htm 06 本月推荐 Linux运维趋势 2012年6月号 总第20期
文章千千万, 时间分分秒。 往来者看一热闹, 有心人看一品味。 ——Techmimi.com 投稿信箱:[email protected] 07
技术分享 还在使用6年前的设备? 你需要叉车式升级 文/ Henry Newman 编译/布加迪 在过去的三五年间,IT预算充其量也不太多。这 存储方面的决定 些预算主要用于对现有系统进行小打小闹的改动,而 不是购买新的软硬件。与此同时,市面上出现的新技 就在六年前,如果你需要高性能的存储系统,就 术不是很多。过去几年主要还是对旧的软硬件进行逐 只有一条路可以走:从销售基于SAN的技术的普通 步改进,厂商发布的新技术基本上没有得到大范围的 厂商那里购买SAN。与存储系统连接的网络采用光 采用。 纤通道,存储系统中的网络采用光纤通道,而磁盘驱 动器采用光纤通道或SATA——由于密度高、成本 这方面的一个典例就是万兆以太网(10 Gbit 低,SATA驱动器在当时变得流行起来。许多人着重 Ethernet)。万兆以太网的销售趋势和价格(通常 提到,想同时获得可靠性、高性能和高密度,就需要 与销售量有关)告诉了我们许多道理。万兆以太网的 使用RAID-6。于是你在购买硬件后,就得考虑该使 价格终于跌下来了,而早在2007年和2008年预测 用哪种文件系统把你的系统连接起来。 采用率很高、价格很低的那些人(包括本人)预测错 了。只是现在,我们才看到了这一幕隐约可见。 瞧瞧六年间发生了多大的变化!如今,网络附加 存储(NAS)设备能够满足高性能方面的许多要 所以,回到叉车式升级——我接触的几家企业在 求。这些设备可以通过万兆以太网连接起来,向外扩 使用非常旧的光纤通道磁盘驱动器。有一回,我听说 展。它们采用NFS或CIFS协议来用于通信。如果你 某个站点使用的是早在2002年发布的146 GB光纤 需要更高的性能,许多厂商还在开发文件系统硬件硬 通道驱动器。IT工作人员还在使用2004年发布的 件设备。这些厂商使用像通用并行文件系统 300 GB光纤通道驱动器。这个站点在生产环境中同 (GPFS)、Lustre、Gluster和Panasas这些向外 时运行这两种磁盘,最近在RAID-5逻辑单元号 扩展型文件系统,它们用软件把硬件包装起来,从而 (LUN)上遇到了双重故障。发生这种状况时,我 大大提高了硬件的易用性。这些设备也可以通过NFS 们都知道。你可能会问,为什么他们的这些旧驱动器 或CIFS来进行通信,或者通过在服务器上运行的文 采用RAID-5而不是RAID-6?原因是,RAID控制器 件系统客户软件,大大提高运行和通信速度。 太旧了,无法支持RAID-6。 这些文件系统设备中的硬件其构造方式与仅仅六 这并不是一种罕见的情形。我看到越来越多的站 年前的RAID设备完全不同。首先,今天的磁盘驱动 点在丢弃这种类型的旧硬件,改用新系统。现在市面 器通过SAS连接技术来连接,而不是通过光纤通道来 上有太多的选择,而这在6年前、8年前或10年前根 连接。取代六年前旧SATA驱动器的驱动器名为近线 本不可能。所以,你如何决定购买什么存储系统来更 SAS,它们支持SAS接口或SATA接口。在进行购买 换旧的存储区域网络(SAN)环境呢? 时,务必确保你向其购买的厂商使用SAS接口,因为 这种接口提供了丰富得多的功能。 08 技术分享 Linux运维趋势 2012年6月号 总第20期
“如果你间隔很长的时间才更 换系统,选择余地就会加大。” 这些驱动器的机械部件(马达等)是SATA,这 会拉大。而六年前不是这种情况,从目前的价格趋势 意味着与过去同样的硬错误率,而年故障率(AFR) 来看,我不相信:如果有人非要对新的存储基础设施 只是略有下降。此外如今出现了这一举动:这个方面 进行叉车式升级,他可以忽视万兆以太网。一些外置 从3.5英寸驱动器改用2.5英寸驱动器。据我所知,主 设备(如磁盘驱动器)仍需要光纤通道,但是这并不 要的驱动因素是每IOP瓦特和每Gib/秒瓦特。六年前 意味着,你的整套基础设施必须是光纤通道,因为几 的企业光纤通道驱动器如今在2.5英寸10K或15K 乎所有厂商都有同时支持光纤通道和以太网的交换 SAS驱动器上的速度是6.0 Gb/秒。硬错误率仍然低 机。 一个数量级,年故障率也比较好。因而,你有不同的 驱动器种类和大小可以选择,但是我们迅速采用了单 叉车式升级是好事 一的驱动器互连技术,那就是SAS。 如果你经常进行增量式升级,目的是在升级时尽 最后但并非最不重要的是,固态硬盘(SSD)方 量减小对生产系统带来的干扰。因而,你购买了某项 面的选择。现在有SAS、SATA和PCIe等类型的 技术的下一代版本。相比之下,如果你间隔很长的时 SSD。实际上,你的选择受向你销售硬件设备的厂商 间才更换系统,选择余地就会加大。考虑到近些年来 的限制,除非你在扩建自己的架构。这些新的文件系 出现的技术变化,在一些情况下,进行叉车式升级带 统硬件设备不大需要管理人员的介入,因为它们针对 来的干扰与累积的增量式升级带来的干扰大致相当。 你的环境事先进行了集成。它们在性能上不是2006 比如说,不妨比较一下使用来自SAN的文件系统设 年时候的NAS设备。NAS厂商在这段期间并没有一 备和升级SAN。在这两种情况下,升级文件存储系 成不变;它们开发了向外扩展型架构。pNFS终于进 统网络同样困难。 入到了发布的Linux内核中。NAS厂商们只要改动一 下自己的文件系统,就能够支持pNFS。 将系统升级到与之前一样的架构之前,要考虑存 储系统和网络方面的所有选择。不过最终,应该由需 这两种新技术都需要叉车式升级(forklift 求来决定决策。你必须明白新技术与原有技术相比的 upgrade),因为用这些新技术来升级2006年的设 优缺点。这需要全面的调查研究,以了解新的设备、 备并不明智。 新的NAS产品、网络选择和磁盘驱动器类型。 网络方面要做出的决定 由于经济形势逐渐好转,我认为我们会看到运行 大型计算机中心的基础设施方面出现重大变化。考虑 在2006年,服务器与服务器的通信是千兆以太 到以太网成本较低、光纤通道成本较高,你必须确定 网的天下。没错,当时是有万兆以太网技术,但是这 继续走原来这条路是不是很明智。为企业交换机购买 项技术对大多数企业来说成本高得吓人。就存储通信 另一块光纤通道卡、继续使用三年前的光纤通道可能 网络而言,NAS除外,2005年发布了速度达到4Gb 完全很明智,但是当该交换机需要更换时,它是合适 的光纤通道。如今,光纤通道总体上只用于遗留的 的技术吗?SAN是适合特定环境的基础设施吗?所 SAN环境。没错,光纤通道是非常高效,但是每个 有这些问题都应该摆到台面上。正确的答案可能是不 端口的成本(对主机总线适配器和交换机端口而言) 采取以前的做法,而是考虑采用新的不同技术。 远比万兆以太网网卡和交换机端口高得多。我认为, 考虑到万兆以太网的销售量增加后,成本方面的差距 叉车式升级就在眼前。请作出明智的选择。 ■ 原文: http://www.enterprisestorageforum.com/storage-technology/forklift-vs.-incremental-upgrade-weighing-all-the-factors.html 译文: http://os.51cto.com/art/201205/336021.htm 投稿信箱:[email protected] 09
腾讯后台开发技术 总监浅谈过载保护 小心雪崩效应 文/mysqlops 对于时延敏感的服务,当外部 Step6: 应答前端用户,回到 过载分析 请求超过系统处理能力,如果系 step1处理下一个请求 统没有做相应保护,可能导致历 当后端系统B处理时延延长至 史 累 计 的 超 时 请 求 达 到 一 定 规 正常情况下的负载 50ms的时候,进程A每秒只能处 模,像雪球一样形成恶性循环。 理20个请求(1s / 50ms = 20 由于系统处理的每个请求都因为 正常情况下: )。小于正常情况下的用户请求 超时而无效,系统对外呈现的服 峰值30次/s。这个时候操作失败 务能力为0,且这种情况下不能自 1 、 前 端 请 求 报 文 大 小 约 的用户往往会重试,我们观察到 动恢复。 100Bytes。前端请求的峰值每分 前端用户请求增加了6倍以上,达 钟1800次,即峰值每秒30次。 到200次/s,是进程A最 大处理 腾 讯 后 台开 发 技 术 总监 能力(20次/s)的10倍! bison,给大家分享了非常精彩的 2、后端系统B并行能力较高, 过载保护,其看似简单,但是要 每秒可以处理10000次以上,绝 这个时候为什么所有用户发现 做好并不容易。这里用两个曾经 大多数请求处理时延在20ms内。 操作都是失败的呢? 为什么不是 经历的反面案例,给出过载保护 3、进程A在处理请求的时候, 1/10的用户发现操作能成功呢? 的直观展现,并附上一点感想。 主要时延是在等待后端系统B,其 因为请求量和处理能力之间巨大 他 本 地 运 算 耗 时 非 常 少 , 小 于 的差异使得5.6s内就迅速填满了 socket接收缓冲区(平均能缓存 案例一 基本情况 1ms 1000个请 求,1000/(200- 如下图,进程A是一个单进程 这个时候,我们可以看出,系 20)=5.6s),并且该缓冲区将一 系统,通过udp套接字接收前端请 统 工 作 良 好 , 因 为 处 理 时 延 在 直保持满的状态。这意味着,一 求进行处理。在处理过程中,需 20ms内,每秒进程A每秒中可以 个请求被追加到缓冲区里后,要 要访问后端系统B,是同步的方式 处理50个请求,足以将用户每秒 等待50s(缓存1000个请 求,每 访问后端系统B,根据后端系统B 峰值30个请求及时处理完。 秒处理20个,需要50s)后才能 的 SL A , 超时 时 间设 置是 被进程A 取出来处理,这个时候 100ms。前端用户请求的超时时 导火索 用户早就看到操作超时了。换句 间是1s。 话说,进程A每次处理的请求,都 某天,后端系统B进行了新特 已经是50s以前产生的,进程A一 进程A的时序是: 性发布,由于内部逻辑变复杂, 直在做无用功。雪球产生了。 导致每个请求处理时延从20ms延 Step1: 从socket接收缓冲区 接收用户请求 长至50ms,根据sla的100ms超 案例二 基本情况 时时间,这个时延仍然在正常范 Step2: 进行本地逻辑处理 围内。当用户请求达到峰值时间 前端系统C通过udp访问后端 点时,灾难出现了,用户每次操 serverD,后端server D的udp套 Step3: 发送请求到后端系统B 作都是“服务器超时无响应”, 接字缓冲区为4MB,每个请求大 Step4: 等待后端系统B返回 整个服务不可用。 小约400字节。后端serverD偶尔 处理超时情况下,前端系统C会重 Step5: 接收后端系统B的应答 试,最多重试2次。 10 技术分享 Linux运维趋势 2012年6月号 总第20期
“每个系统要做好自我保护, 量力而为,而不是尽力而为。” 正常情况下的负载 是20次/S,而是10次/S。因为 8、 中间层server对后端发送 它是单进程同步的访问后端B, 且 请求,重试机制要慎用,一定要 正常情况,后端serverD单机 访问后端 B的超时时间 是 用的话要有严格频率控制。 收到请求峰值为300次/s,后端 100ms,所以他的处理能力就是 serverD单机处理能力是每秒 1S/100ms=10次/S。而平时处 9、 当雪球发生了,直接清空 1500次,时延10ms左右。这个 理能力表现为50次/S,只是运气 雪球队列(例如重启进程可以清 时候工作正常。 好。 空socket 缓冲区)可能是快速恢 复的有效方法。 导火索 2、 每个系统要做好自我保 护 , 量 力 而 为 , 而 不 是 尽 力 而 10、过载保护很重要的一点, 由于产品特性(例如提前通知 为。对于超出自己处理能力范围 不是说要加强系统性能、容量, 大量用户,未来某某时刻将进行 的请求,要勇于拒绝。 成功应答所有请求,而是保证在 一项秒杀活动;类似奥运门票, 高压下,系统的服务能力不要陡 大量用户提前得知信息:某日开 3、 每个系统要有能力发现哪 降到0,而是顽强的对外展现最大 始发售门票),大量的用户聚集 些是有效的请求,哪些是无效的 有效处理能力。 在同 一时刻发起了大量请求,超 请求。上面两个案例中,过载的 对于“每个系统要有能力发现 出了后台serverD的最大负载能 系统都不具备这中慧眼,逮着请 哪些是有效的请求,哪些是雪球 力 。 操 作 响 应 失 败 的 用 户 又 重 求做死的处理,雪球时其实是做 无效的请求”,这里推荐一种方 试, 中间系统的重试,进一步带 无用功。 案:在该系统每个机器上新增一 来了更大量的请求(正常情况下的 4、 前端系统有保护后端系统 个进程:interface进程。 9倍)。导致所有用户操作都是失 的义务,sla中承诺多大的能力, Interface进程能够快速的从 败的。 就只给到后端多大的压力。这就 socket缓冲区中取得请求,打上 要求每一个前后端接口的地方, 当前时间戳,压入channel。业务 过载分析 都有明确的负载约定,一环扣一 处理进程从channel中获取请求和 环。 该请 求的时间戳,如果发现时间 只是导火索不一样,同案例 戳早于当前时间减去超时时间( 一,巨大的请求和处理能力之间 5、 当过载发生时,该拒绝的 即已经超时,处理也没有意义) 的鸿沟,导致后端serverD的4M 请求(1、超出整个系统处理能力 ,就直接丢弃该请求,或者应答 大小的接收缓冲区迅速填满(4秒 范围的;2、已经超时的无效请 一个失败报文。 就填满),且过载时间内, 接收 求)越早拒绝越好。就像上海机 缓冲区一直都是满的。而处理完 场到市区的高速上,刚出机场就 Channel是一个先进先出的通 缓冲区内的请求,ServerD需要6 有电子公示牌显示,进入市区某 信方式,可以是socket,也可以 秒以上(4MB / 400 / 1500 = 某路段拥堵,请绕行。 是共享内存、消息队列、或者管 6.7S)。所以serverD处理的请 道,不限。 求都是6s之前放入缓冲区的,而 6、 对于用户的重试行为,要 该请求在最前端早已经超时。雪 适当的延缓。例如登录发现后端 Socket缓冲区要设置合理,如 球形成了。 响应失败,再重新展现登录页面 果过大,导致及时interface进程 前,可以适当延时几秒钟,并展 都需要处理长时间才能清空该队 现进度条等友好界面。当多次重 列,就不合适了。建议的大小上 启示 试还失败的情况下,要安抚用户。 限是:缓存住超时时间内 1、 每个系统,自己的最大处 7、 产品特性设计和发布上, interface进程能够处理掉的请求 理能力是多少要做到清清楚楚。 要尽量避免某个时刻导致大量用 个数(注意考虑网络通讯中的元 例如案例一中的前端进程A,他的 户集体触发某些请求的设计。发 数据)。 ■ 最大处理能力不是50次/s,也不 布的时候注意灰度。 原文:http://www.mysqlops.com/2012/05/10/protect.html 投稿信箱:[email protected] 11
一个DBA眼中的HBase 文 / vogts Hadoop,HBase,NO-SQL是当今业界比较火 2:没办法建立二级索引。对于mysql,oracle对 的一些名词。满互联网都是对它的他们的赞许,其实 于一张表建立多个索引是天经地义的时候,而 光芒的背后还有部分缺点。本文只是我vogts的一些 HBase是不支持的。据说新版本会考虑,个人觉得 观点和想法。 如果HBase将来真的要发展,必须走google f1,这 是终局。 HBase的优点: 3:没办法做类似oracle的dataguard,或者 分布式,易扩展,高性价比,运维成本低都是它 mysql的master-slave。 当然由于数据量实在太大 的优点。HBase可以支持海量数据,单张表的数据 了,每天的IO吞吐量也太大了,就算做一个,估计性 量不上T,都不好意思出来打招呼。甚至可以拿很烂 能立马下降30%。单目前新版本的HBase,确实在 的SATA盘来作为存储,由于依赖底层的HDFS。新 考虑做master-slave,复制DML到备库上应用。 装的机器甚至可以不用做硬RAID。 4:当然trigger,procedure什么的,也更不可 HBase可以在任何时候随时宕掉2,3台机器,就 能有了。 当什么都没发生似的(当然master除外,但是 5:对于性能诊断不够给力,目前监控的粒度, hbase,hadoop的master节点负载都很”清闲“ 差不多都是这些指标: )。这是HBase本身分布式的架构,先天性的优 势。 h tt p: // s em at ex t. c om /s pm /h b as e- performance-monitoring/index.html 最近听说facebook计划全部放到hbase 上,ebay的搜索引擎也计划使用hbase,hbase甚 Cluster and RegionServer read and write 至可以代替lunce来做搜索引擎。我承认HBase确实 request counts 可以做到,也确实可以做的更好。关键就看你怎么用 Read, Write, and Sync min, max, and average 了。 latency Number of Stores opened on RegionServers 很多开发都争着要上HBase,一窝蜂的热度。不 StoreFile Index size and counts 用hadoop,不用hbase,不用no-sql就要落伍了, MemStore size 云云。 Block cache: item count, hit cache and hit caching ratio, number of evictions, hits and HBase的一些限制: misses, bytes free Compactions: compactionSizeNumOps, 由于HBase是一个NO-SQL的列存储,很多特性 compactionTimeNumOps 目前是不支持的。比如: Compactions min, max, and average time 1:HBase名字像个Database的名字,它不支持 Compactions min, max, and average size SQL。必须依赖开发进行代码解决。因为HBase实 Compactions queue size 际存储的是字节流。 Flush: flushSizeNumOps, flushTimeNumOps Flush min, max, and average size 不过,由于没有SQL,也产生了一些好处,就是 Flush min, max, and average time 没必要去搞统计信息,担心执行计划走错等问题的发 Splits: splitSizeNumOps, splitTimeNumOps 生。 Splits min, max, and average size 12 技术分享 Linux运维趋势 2012年6月号 总第20期
“一个DBA更希望得到是:什 么命令,在干什么,哪个客户 端,等待事件什么,等等,都必 要要了解清楚。” Splits min, max, and average time HBase region count CPU usage RAM used/free System load Disk reads/writes 资源推荐 Disk used/free Network interface traffic Swap IO JVM memory usage JVM garbage collection times and counts JVM thread counts 单纯从指标上来说,这些够用了。这些指标确实 能窥探出一些问题。但一个DBA更希望得到是:什 么命令,在干什么,哪个客户端,等待事件什么,等 等,都必要要了解清楚。这个HBase目前还无法提 Linux网络服务配置详解 供,希望在未来的新版本能够加强。 7:当region在进行compact或者split会出现短 暂的读写堵塞。 8:权限,安全上存在隐患。只要知道ZK的IP和 端口,你就能轻松访问HBASE,甚至不需要任何权 限校验。 9:如果Row-Key的区分度不高,性能也不行。 先吐槽到这里吧,HBase将来还有很多地方需要 Linux必学的60个命令 提高。 毕竟传统的RDBMS数据库已经历经几十年,而 HBase从06年出道到现在,更像一个刚刚上幼儿园 的小孩。我相信它应该会慢慢走向完善,终局应该是 Google的F1。 ■ 原文:http://www.alidba.net/index.php/archives/598 投稿信箱:[email protected] 13
异构存储系统数据迁移 步骤分享 文/miskey07 “整个过程单实例只需一次关 机,2次重启服务器。RPO>5分 钟;RTO>5分钟。” 摘要:此次是系统和数据迁移是把源设备上的操 --------完成单控存储业务数据向双控存储上备份 作系统、应用程序、数据信息,通过数据镜像同步软 转移 件迁移到目标设备上。并且保证迁移前后用户的系统 平台以及应用和所有的数据,包括普通的数据,用户 6、关闭VM虚拟机,在VM虚拟机上删除裸映射 的帐户信息,链接等等,都不发生任何的改变。这样 的磁盘LUN。 当迁移完成后可以马上投入使用,满足业务的需求。 7、新建虚拟机,添加裸映射磁盘LUN启动系统 环境:从单控存储LUN里划分给虚拟主机上的的 (显示还原模式)。 虚拟机完整平滑迁移到双控存储LUN。 --------业务恢复,完成数据中转过程 整个过程单实例只需一次关机,2次重启服务 8、在双控存储上划分一个大LUN给虚拟主机服 器。RPO>5分钟;RTO>5分钟。 务器。(等于单控LUN的大小,目标是将单控LUN 整个过程步骤如下: 上所有的虚机迁移到双控LUN上) 1、双控存储上划分一个LUN(用于中转),其 9、从大LUN分配磁盘给刚裸映射启动的系统, 容量必须大于或等于源VM虚拟机磁盘的容量。 格式化分配的新磁盘,容量必须大于或等于其整个磁 盘容量。 2、LUN分配给虚拟主机服务器,扫描新的存储 设备。 10、完成从源裸磁盘业务数据还原至新LUN数据 盘的操作。 3、VM虚拟机添加裸机映射磁盘LUN,默认设置 至完成。 11、重启,用备份磁盘启动系统。(VM“选 项”启动强制进入BIOS设置选择磁盘启动顺序) 4、VM虚拟机安装CDP软件,安装后重启,添加 软件相关序列号。 12、确认数据完整一致后删除裸磁盘。 5、完成从源磁盘数据备份至裸磁盘操作。 ---------整个系统业务数据迁移完成。 ■ 原文:http://mefoo.blog.51cto.com/922293/898177 14 技术分享 Linux运维趋势 2012年6月号 总第20期
iptables自动封杀暴力 破解(Qmail邮件系 统)者的IP地址 文/sfzhang88 今天发现Qmail邮件系统的maillog里面有大量的“user not found”信息,通过下面的日志不难发现, 是来自同一IP的很多不同的用户连接Qmail邮件系统认证失败的信息。黑客试图通过这种方式来破解Qmail邮 件系统的用户名和密码,从而来发送大量的垃圾邮件和病毒邮件。 大量的并发连接会消耗Qmail系统的性能,甚至在严重的时候会造成正常邮件无法发送和接收,即出现连 接SMTP超时情况。通过Linux的Iptables封杀掉这些IP地址即可,下面是我写的Iptables的脚本,如有错 误,请多多指正。 投稿信箱:[email protected] 15
#!/bin/bash #作者:张世锋 2012.06.02 LOGFILE=”/var/log/maillog” BASE=`dirname $0` cat $LOGFILE |grep “not found” | awk ‘{print $11}’ | awk -F: ‘{print $2}’ | sort | uniq -c |awk ‘{print $2}’ > $BASE/badip.txt if [ `ls -l $BASE/badip.txt |awk ‘{print $5}’` -eq 0 ] then exit fi for IP in `cat $BASE/badip.txt` do cat $BASE/iptables.sh |grep $IP > $BASE/badaddip.txt if [ `ls -l $BASE/badaddip.txt |awk ‘{print $5}’` -eq 0 ] then echo “iptables -A INPUT -s $IP -p all -j DROP” >> $BASE/iptables.sh echo $IP >> $BASE/badallip.txt mail -s “Qmail bad ip add iptables” [email protected] < $BASE/badip.txt sh /root/sh/iptables.sh fi 注释:第5行查找qmail日志里面出现”not found”的行,并打印出IP地址(去掉重复行)到badip.txt 文件里面。 6-9 行判断badip.txt文件是否为空,如果为空直接退出if语句。 11行把badip.txt的ip地址赋值给变量IP 13-19判断该ip地址是否在iptables脚本文件里面,如果没有添加到iptables.sh文件里面,并发送邮件给 系统管理员,最后重新加载脚本文件。 脚本的逻辑结构大致是:分析统计系统maillog日志,取出攻击者的IP地址,然后和服务器的Iptables脚 本(iptables.sh)作对比,如果该IP地址没有在iptables.sh里面,添加一条DROP的策略到iptables.sh, 然后发送一份邮件给系统管理员,并重新加载iptables.sh。 下面测试一下这个脚本的运行效果,手动执行一下这个脚本。 [root@mail sh]# sh add_badip_iptables.sh查看一下badip.txt文件,里面添加的是被攻的IP地址信息。 查看系统管理员的邮箱里面也成果收到用户的报警邮件。 16 技术分享 Linux运维趋势 2012年6月号 总第20期
“大量的并发连接会消耗 Qmail系统的性能,甚至在严重 的时候会造成正常邮件无法发送 和接收,即出现连接SMTP超时 情况。” 同时发现iptables.sh脚本文件也成功添加DROP记录。 最后用iptables -L查看已经把这些IP成功添加到Linux系统的Iptables防火墙策略里面,并且给DROP掉 了。 投稿信箱:[email protected] 17
“邮件运维人在员在设置邮箱 用户名的时候尽量避免 test,salse,test01这样的用户 名,很容易被黑客猜测到。” 最后添加crontab,每隔10分钟让系统自动执行。 总结:建议在所有的邮件系统上面都应该有这样的防范措施,另外,邮件运维人在员在设置邮箱用户名的 时候尽量避免test,salse,test01这样的用户名,很容易被黑客猜测到,同时设置的邮箱密码应该符合大写, 小写,数字和特殊字符的组合。 ■ 原文:http://sfzhang88.blog.51cto.com/4995876/885540 18 技术分享 Linux运维趋势 2012年6月号 总第20期
Zimbra邮件系统安装与 使用过程中各种报错与 问题的详细解决方法 文/heminjie Zimbra是VMware旗下的一款免费开源的邮件系 prot after reloc: Permission denied Also 统,其功能齐全,有自带的webadmin与webmail, aspell doesn’t seem to work either. 个人感觉webmail界面比较美观。 真正的原因是selinux被设置为强制模式。解决办 法: 在大家安装域使用过程中此邮件系统的同时,往 往在安装过程中会遇到这样那样的报错与问题,虽然 你需要vi /etc/sysconfig/selinux,把SELINUX 网上有很多解决办法,但是都很凌乱,没有一个确切 禁用掉,SELINUX=disabled,然后在命令行模式 的方法。 下执行:# chcon -t textrel_shlib_t /opt/zimbra/ httpd/modules/libphp5.so 之后需要重启一下系 下面我就列举在安装过程中会经常碰到的几个报 统。 错与解决方法。 平台与软件: 2、 postfix is not running OS:CentOS 5.5 解决办法: Zimbra版本:zimbra-7.1.3_GA_3346. 把sendmail关掉! RHEL5.20110928134520.tgz 因为端口25被sendmail占用了。你需要用命令 首先必须安装依赖的软件包(我是用CentOS自带 zmcontrol stop先停掉zimbra,然后zmcontrol 的yum安装,如果系统为linux,可以到网上去下载 start重新启动zimbra,最后就ok了! 相应rpm软件包): yum -y install sudo perl libstdc++ gpg sqlite 3、Failed to start slapd. Attempting debug gmp sysstat mysql mysql-server start to determine error. 1、ERROR: daemon: bind(7) failed errno=99 (Cannot assign requested address) startup.log:Starting apache...httpd: Syntax error on line 232 of /opt/zimbra/conf/httpd. slap_open_listener: failed on ldap://zimbra. conf: Cannot load /opt/zimbra/httpd/modules/ example.com:389这是一个错误拒绝访问消息,这 libphp5.so into server: /opt/zimbra/httpd/ 就意味着它试图绑定到的ip地址不在任何的网络接口 modules/libphp5.so: cannot restore segment 上。 投稿信箱:[email protected] 19
“Zimbra默认启用Dedupe (去除重复邮件),对于某一时 间内同已发件者大量发送邮件可 能会存在丢失邮件的可能。” 解决办法: 3.第一条命令用于修改标准HTTP端口,第二条 命令用于修改HTTPS端口。 vi /etc/hosts 192.168.0.250 zimbra.example.com zimbra 4.修改完成后,需执行如下命令重启服务器: 这个ip地址要写正确,否则就会出现这样的错 zmcontrol stop 误。 zmcontrol start 6、Zimbra邮件系统使用一段时候后会发现用户 4、mysql.server is not running 丢失邮件,并且在日志文件里会发现大量的错误日志 解决方法: 的信息,信息如下: 先给系统zimbra用户设置一个密码,然后切换至 [root@mail log]# pwd zimbra用户登陆。 /opt/zimbra/log [root@mail log]# cat mailbox.log.2012-03-16 [zimbra@mail libexec]# passwd zimbra |grep delivering su zimbra 2012-03-16 10:35:15,058 INFO [zimbra@mail libexec]$ cd /opt/zimbra/libexec [LmtpServer-113063] [name=hmj@heminjie. [zimbra@mail libexec]$ ./zmmyinit com;mid=16;ip=58.35.62.49;] lmtp - Not delivering message with duplicate 5、修改web client的方法: 原因:Zimbra默认启用Dedupe(去除重复邮 zmprov ms mail.yourdomain.com zimbraMailPort 件),对于某一时间内同已发件者大量发送邮件可能 60081 会存在丢失邮件的可能 zmprov ms mail.yourdomain.com 解决方法: zimbraMailSSLPort 60443 下列命令要在/opt/zimbra/bin目录里执行 注意: [root@mail bin]# ./zmprov gacf | grep 1.须以zimbra用户身份执行 zimbraMessageIdDedupeCacheSize 2.注意替换命令行中的服务器名称 zimbraMessageIdDedupeCacheSize: 3000 ×/默认值 为3000,修改为0,即可禁用Zimbra检测重复邮件 的功能 20 技术分享 Linux运维趋势 2012年6月号 总第20期
Search
Read the Text Version
- 1 - 34
Pages: