Linux集群和自动化运维(txt+pdf+epub+mobi电子书下载)


发布时间:2020-06-05 23:41:21

点击下载

作者:余洪春

出版社:机械工业出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

Linux集群和自动化运维

Linux集群和自动化运维试读:

前言

为什么要写这本书

笔者从事系统运维和网站架构设计的工作已有10多年,现在在一家外企担任云平台架构师。云计算是现在的主流技术,未来也有很好的发展趋势,云计算的流行对于传统的运维知识体系来说,其实也造成了冲击,有很多读者经常向笔者咨询工作中的困惑,比如从事系统运维工作3~5年后就不知道该如何继续学习和规划自己的职业生涯了。因此笔者想通过此书,跟大家分享一下自己的工作经验和心得(包括传统运维和云平台运维工作的区别与对比),以期解决大家在工作中的困惑。本书提供了大量项目实践和线上案例,希望能让大家迅速了解Linux运维人员的工作职责,快速进入工作状态并找到成长方向。希望大家通过阅读此书,能够掌握Linux系统集群和自动化运维及网站架构设计的精髓,从而能够轻松愉快地工作,并提升自己的职业技能,这就是笔者写作此书的初衷。运维架构师之路

在成为运维架构师之前,笔者从事过很长一段时间的系统集成、运维和管理工作,在CDN门户网站、电子广告、电子商务领域也有不少的沉淀和积累,在之前的《构建高可用Linux服务器》一书中已经跟大家分享了很多跟Linux集群有关的知识。笔者目前的主要工作职责是维护和优化公司的DSP电子广告业务平台,主要方向是云计算和大数据方面。需要维护的数据中心和机器数量非常之多,所以自动化运维和DevOps是目前的主要工作方向,此外,也会涉及网站架构设计及调优工作,因此在此书中特意将这部分工作经验分享出来,希望大家能从中学到新的知识体系,借以提升自己的职业技能。读者对象

本书适合以下读者阅读。

·中高级系统管理员

·系统架构设计师

·高级程序开发人员

·运维开发工程师如何阅读本书

本书是笔者对实际工作中积累的技术和经验所做的总结,涉及大量的知识点和专业术语。全书总共分为三大部分,第一部分包含第1章和第2章,主要讲解进行系统架构设计的软硬件环境,以及生产环境下的Shell脚本和Python脚本。其中,第2章的内容是以Shell为主,Python为辅,Shell部分讲得比较详细,Python部分需要重点关注的地方也有所提及。之所以这样安排,主要是考虑到大多数搞开发的读者或DevOps工程师都是Java程序员出身,对Shell脚本语言不是很熟悉。第二部分包含第3章、第4章和第5章,主要讲自动化运维,包括Fabric、Ansibel和Puppet三大工具,大家可以结合自己的实际环境来选择对应的工具。第三部分包含第6章、第7章和第8章,主要讲的是Linux集群和网站架构设计,特别是第8章,分别以百万PV、千万PV及亿级PV的网站为例来详细说明网站系统架构设计的相关技术,然后细分五层来解说网站的架构,并指出了设计网站的压力及关注点所在。

大家可以根据自己的职业发展和工作需求来选择不同的章节进行阅读或学习。

关于本书中的配置文件、Shell脚本和Python脚本的编号,这里也略作说明,比如1.5.3节中有1.sh,表示这是1.5.3节的第一个Shell脚本;如果是2.py,则表示是1.5.3节的第二个Python脚本;其他依此类推,在哪个章节中出现的配置文件或脚本就在哪个章节中寻找,这样对照起来阅读理解会比较方便。此外,书中多次出现的Nginx配置文件nginx.conf也在对应的章节里。本书相关的GitHub地址为http://github.com/yuhongchun/automation。勘误

尽管笔者花费了大量的时间和精力来核对文件和语法,但书中难免还会存在一些错误和纰漏,如果大家发现有任何问题,都请及时反馈给我,相关信息可以发到个人邮箱yuhongchun027@gmail.com。尽管无法保证对于每一个问题都会有一个正确答案,但我肯定会努力回答并且指出一个正确的方向。致谢

感谢爱女媛媛的出生,你的降临是上天赐给我的最好礼物,是我进行写作的源泉和动力。

感谢我的家人,他们在生活上对我的照顾无微不至,让我有更多的精力和动力去工作和创作。

感谢好友三宝这么多年来对我的信任和支持,从始至终一直都在支持和信任我。

感谢机械工业出版社华章公司的编辑杨福川和杨绣国,在你们的信任、支持和帮助下,我才能如此顺利地完成全部书稿。

感谢好友老男孩和刘天斯,闲暇之余和你们一起交流开源技术和发展趋势,也是一种享受。

感谢Linux之父——Linus Torvalds,他不仅创造了Linux系统,而且还创造了Git这么神奇的版本管理软件。余洪春(抚琴煮酒)中国,武汉第1章系统架构设计的构建基础

作为一名系统架构设计师,会面临着很多系统方面的架构设计工作,比如电子商务系统、CDN(内容分发网络)大型电子广告平台和DSP电子广告系统的运维方案确定及平台架构设计等,此外,还会涉及核心业务的系统在线优化及升级等工作。在以上这些工作中,又将包括多项选择:比如是考虑自建CDN,还是租赁CDN系统;公司的业务系统所在的机房是考虑自建机房、托管机房,还是云计算平台,而如果选择托管机房,又会有更多的细节需要考虑,比如是选择电信机房、双线机房还是BGP机房,服务器应该如何选型,选择哪种操作系统等,这个时候系统架构设计师的经验和作用就体现出来了。他们应该在系统网站实施的初期就做好项目的成本预算和风险规避,并对系统的高可用及扩展性进行细致权衡,这些也是其工作职责所在。当然,在了解上述这些之前,首先应该了解一些网站架构设计相关的专业术语,下面就一起来看看。1.1 网站架构设计相关术语1.1.1 什么是HTTP 1.1

HTTP 1.1(Hypertext Transfer Protocol Version 1.1),即超文本传输协议-版本1.1,跟版本1.0是有区别的。

针对HTTP 1.0中TCP连接不能重复利用的情况,HTTP1.1采用了效率更高的持续连接机制,即客户端和服务器建立TCP连接以后,后续相关联的HTTP请求可以重复利用已经建立起来的TCP连接。

HTTP 1.1是用来在Internet上传送超文本的传送协议。它是运行在TCP/IP协议族之上的HTTP应用协议,它可以使浏览器更加高效,并减少网络传输。任何服务器除了包括HTML文件以外,都还有一个HTTP驻留程序,用于响应用户请求。如果浏览器是HTTP客户,在向服务器发送请求时,向浏览器中输入一个开始文件或点击一个超级链接,浏览器就向服务器发送HTTP请求,此请求被送往由URL指定的IP地址。驻留程序接收到请求,在进行必要的操作后就会回送所要求的文件。

HTTP 1.1支持持续连接。通过这种连接,就有可能在建立一个TCP连接后,发送请求并得到回应,然后发送更多的请求并得到更多的回应。由于把建立和释放TCP连接的开销分摊到了多个请求上,因此对于每个请求而言,由于TCP连接而造成的相对开销就被大大地降低了。而且,还可以发送流水线请求,也就是说在发送请求1的回应到来之前就发送请求2。也可以认为,一次连接发送多个请求,由客户机确认是否关闭连接,而服务器会认为这些请求分别来自于不同的请求。1.1.2 什么是Web 2.0

Web 2.0,指的是利用Web的平台,由用户主导而生成内容的互联网产品模式,为了区别由网站雇员主导生成内容的传统网站而定义为Web 2.0。Web 1.0的盈利模式都基于一个共同点,即巨大的点击流量,无论是早期融资还是后期获利,依托的都是众多的用户和点击率,以点击率为基础融资上市或开展增值服务,充分体现了互联网的眼球经济色彩,例如早期的新浪、搜狐和网易等。

Web 2.0是资源平等的体现。Web 2.0的应用可以让人了解到目前万维网正在进行的一场改变——从一系列网站到一个成熟的、为最终用户提供网络应用的服务平台。这种概念的支持者期望Web 2.0服务在很多用途上能最终取代桌面计算机应用。虽然Web 2.0并不是一个技术标准,但是它包含了技术架构及应用软件。它的特点是鼓励信息的最终利用者通过分享,使得可供分享的资源变得更加丰富;相反的,过去网上的各种分享方式则显得支离破碎。

Web 2.0是网络运用的新时代,网络成为了新的平台,内容因为每位用户的参与而产生,参与所产生的个人化内容,借由人与人(P2P)的分享,形成了现在的Web 2.0世界。

Web 2.0的主要特点和基于这些特点所产生的具有代表性的服务如下。

1.博客

博客(Blog)是Web 2.0最早期的服务之一,可使任何参与者拥有自己的专栏,成为网络内容的产生源,进而形成微媒体,为网络提供文字、图片、声音或视频信息。

2.内容源

内容源(RSS)是伴随博客产生的简单文本协议,将博客产生的内容进行重新格式化输出,从而将内容从页面中分离出来,便于同步到第三方网站或提供给订阅者进行阅读。

3.Wiki

是一个众人协作的平台,方便编写百科全书、词典等。Wiki指的是一种超文本系统,这种超文本系统支持面向社区的协作写作,例如百度百科和维基百科。

4.参与评论与评分的Digg机制

Web 2.0最显著的特点之一是分享机制和去中心化,Digg机制为更多的网络用户提供了参与网络建设的机制,无须进行内容贡献或创作,只要用户对网络内容进行评分或点评,即可参与到网络内容的建设过程当中。

5.美味书签

美味书签(Delicious)不同于个人博客,用户可根据自己的喜好进行网络内容的收藏与转载,并将自己的收藏或转载整理成列表,分享给更多的用户,从而在网络上起到信息聚合与过滤的作用。

6.社会化网络

社会化网络(SNS)从原有的以网站、内容为中心,转为侧重于以人与人之间的关联为中心,网络上每一个节点所承载的不再是信息,而是以具体的自然人为节点,形成的新型互联网形态。

7.微博

微博(Microblog)作为博客的精简版,有较为严格的字数限制和政治立场限制。有更简单的发布流程和更随意(被限制的话题、领域)的写作方式,使得参与到网络内容贡献中的门槛降低,更大程度地推动了网络内容建设和个体信息贡献。

8.基于位置信息的服务

基于位置信息的服务(LBS)是集地理信息系统(GIS)、微博(Twitter)和移动设备(Mobile)及A-GPS定位服务于一体的增强型微博系统,其主导思想是每一条信息除了利用时间为索引,还加入了地理经纬度的索引,从而实现不仅可以通过时间对信息进行筛选,还可以利用地理坐标对信息进行合理的筛选。

9.即时通信

即时通信(IM)软件可以说是目前中国网上用户使用率最高的软件。聊天一直是网民们上网的主要活动之一,网上聊天的主要工具已经从初期的聊天室、论坛变为以QQ和Skype为主要代表的即时通信软件。1.1.3 软件开发C/S结构与B/S结构的区别

C/S结构是大家熟知的软件系统体系结构,即Client/Server(客户机/服务器)结构,它通过将任务合理地分配到Client端和Server端,来降低系统的通信开销,不过需要安装客户端才可进行管理操作。B/S结构,即Browser/Server(浏览器/服务器)结构,是随着Internet技术的兴起,对C/S结构的一种变化或改进的结构。在这种结构下,用户界面可完全通过WWW浏览器来实现。像QQ、Skype这类即时通信软件就属于C/S结构;而像百度、Google这样的搜索引擎就属于B/S结构。

随着计算机技术的不断发展与应用,计算模式从集中式转向了分布式,尤为典型的是C/S结构。两层结构C/S模式,在20世纪80年代及90年代初得到了大量的应用,最直接的原因是可视化开发工具的推广。之后,它开始向三层结构发展。近年来,随着网络技术的不断发展,尤其是基于Web的信息发布和检索技术、Java计算技术及网络分布式对象技术的飞速发展,导致了很多应用系统的体系结构从C/S结构向更加灵活的多级分布结构演变,使得软件系统的网络体系结构跨入一个新阶段,即B/S体系结构。基于Web的B/S模式其实也是一种客户机/服务器模式,只不过它的客户端是浏览器。为了区别于传统的C/S模式,才特意将其称为B/S模式的。了解这些结构的特征,对于系统的选型而言是很关键的。

下面是C/S结构与B/S结构的特点分析。

1.系统的性能

在系统的性能方面,B/S占有优势的是其异地浏览和信息采集的灵活性。任何时间、任何地点、任何系统,只要可以使用浏览器上网,就可以使用B/S系统的终端。

不过,采用B/S结构时,客户端只能完成浏览、查询、数据输入等简单功能,绝大部分工作由服务器承担,这就使得服务器的负担很重。采用C/S结构时,客户端和服务器端都能够处理任务,这虽然对客户机的要求较高,但因此可以减轻服务器的压力。而且,由于客户端使用浏览器,使得网上发布的信息必须是以HTML格式为主,其他格式的文件则多半是以附件的形式来存放的。而且HTML格式文件(也就是Web页面)不便于编辑修改,给文件的管理带来了许多不便。

2.系统的开发

C/S结构是建立在中间件产品基础之上的,要求应用开发者自己去处理事务管理、消息队列、数据的复制和同步、通信安全等系统级的问题。这对应用开发者提出了较高的要求,而且还会迫使应用开发者投入很多精力来解决应用程序以外的问题,这使得应用程序的维护、移植和互操作变得复杂。如果客户端是在不同的操作系统上,那么C/S结构的软件还需要开发不同版本的客户端软件。

但是,与B/S结构相比,C/S技术的发展历史更为“悠久”。从技术成熟度及软件设计、开发人员的掌握水平来看,C/S技术应是更成熟、更可靠的。

3.系统的升级维护

C/S系统的模块中只要有一部分发生改变,就会关联到其他模块的变动,这会使得系统的升级成本比较高。B/S与C/S处理模式相比,则大大简化了客户端,只要客户端机器能上网就可以。对于B/S而言,开发、维护等几乎所有的工作也都集中在服务器端,当企业对网络应用进行升级时,只需更新服务器端的软件就可以了,这就降低了异地用户进行系统维护与升级的成本。如果客户端的软件系统升级比较频繁,那么B/S架构的产品优势就更明显——所有的升级操作只需要针对服务器进行即可,这对那些点多面广的应用是很有价值的,例如一些招聘网站就需要采用B/S模式,客户端分散,且应用简单,只需要进行简单的浏览和少量信息的录入即可。

在系统安全维护上,B/S则略显不足,B/S结构尤其得考虑数据的安全性和服务器的安全性,毕竟现在的网络安全系数并不高。以OA(办公自动化)软件为例,B/S结构要实现办公协作过程中复杂的工作流控制与安全性控制,还有很多技术上的难点。因此,当前虽然出现了B/S结构的OA系统产品,但尚未大范围推广。1.1.4 评估网站性能的专业术语

1.PV

PV(Page View)即访问量,中文翻译为页面浏览,即页面浏览量或点击量,用户每刷新一次就会被计算一次。PV的具体度量方法就是从浏览器对网络服务器发出一个请求(Request),网络服务器接到这个请求后,会将该请求对应的一个网页(Page)发送给浏览器,从而产生一个PV。在这里只要是请求发送给了浏览器,无论这个页面是否完全打开(下载完成),那么都被计为1个PV。PV反映的是浏览某网站的页面数,所以每刷新一次也算一次,也就是说PV与UV(独立访客)的数量成正比,但PV并不是页面的来访者数量,而是网站被访问的页面数量。

2.UV

UV(Unique Visitor)即独立访问,访问网站的一台电脑客户端为一个访客,如果以天为计量单位,程序会统计00:00至24:00时间段内的电脑客户端。相同的客户端只被计算一次。一个电脑客户端可能有多个不同的自然人访问,但也只记一个UV,通过不同的技术方法来记录,实际会有误差。如果企业内部通过NAT技术共享上网,那么出去的公网IP有且只有一个,这个时候在程序里面统计的话,也只能算是一个UV。

3.并发连接数

当一个网页被浏览,服务器就会和浏览器建立连接,每个连接表示一个并发。如果当前网页的页面中包含很多图片,图片并不是一个一个显示的,服务器会产生多个连接同时发送文字和图片以提高浏览速度。网页中的图片越多,那么服务器的并发连接数(Concurrent TCP Connections)就会越多。我们一般以此值作为衡量单台Web机器性能的参数。现在Nginx在网站中的应用比例非常大,可以参考Nginx的活动并发连接数。

4.每秒查询率QPS

QPS(Query Per Second)是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准,在因特网上,作为域名系统服务器的机器其性能经常用每秒查询率来衡量。对应的是Fetches/Sec,即每秒的响应请求数,也称为最大吞吐能力。对于系统而言,QPS数值是一个非常重要的参数,它是综合反映系统最大吞吐能力的衡量标准。它反映的不仅仅是Web层面的,还有缓存、数据库方面的,它反映的是系统的综合处理能力。

参考文档http://baike.baidu.com/view/733.htm

参考文档http://www.hyokay.com/news/industry/41.html1.2 IDC机房的选择及CDN的选型

如果自己的业务网站中含有大量的图片和视频类文件,为了加快客户端的访问速度,同时为了减缓对真正的核心机房的服务压力,并且提升用户体验,建议在前端最好采用CDN缓存加速方案。

CDN(Content Delivery Network),即内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构,将网站的内容发布到最接近用户的网络“边缘”,使用户可以就近取得所需的内容,提高用户访问网站的响应速度。CDN缓存加速方案一般有如下几种方式。

·租赁CDN:中小型网站直接购买服务就好,现在CDN已经进入按需付费的云计算模式了,性价比是可以准确计算的。

·自建CDN:这种方案的成本就有点大了,为了保证良好的缓存效果,必须在全国机房布点,还要自建智能Bind系统,搭建大型网站时推荐采用此种方案,专业的视频网站或图片网站一般会考虑采用此种方案。

IDC机房的选择一般也有几种类型。

·单电信IDC机房:这种类型一般业务模式比较固定,访问量也不是很大,适合新闻类网站或政务类网站。如果网站的PV流量持续增加的话,则建议后期采用租赁CDN的方式解决非电信用户访问网站速度过慢的问题。

·双线IDC机房:由于国内两大网络(电信和网通)之间存在互联互通的问题,导致电信用户访问网通网站或网通用户访问电信网站速度很慢,因此就产生了双线机房、双线服务器、双线服务器托管和双线服务器租用服务。双线机房实际是一个机房有电信和网通两条线路。双线机房通过内部路由器设置,以及BGP自动路由的分析,可实现电信用户访问电信线路,网通用户访问网通线路,这样就可实现电信网通的快速访问。

·BGP机房:BGP(边界网关协议)是用来连接Internet独立系统的路由选择协议。它是Internet工程任务组制定的一个加强的、完善的、可伸缩的协议。BGP4支持CIDR寻址方案,该方案增加了Internet上的可用IP地址数量。BGP是为取代最初的外部网关协议EGP而设计的。它也被认为是一个路径矢量协议。采用BGP方案来实现双线路互联或多线路互联的机房,则称为BGP机房。对于用户来说,选择BGP机房可以实现网站在各运营商线路之间互联互通,使得所有互联运营商的用户访问网站都很快,且更加稳定,不用担心全国各地因线路问题带来的访问速度快慢不一的问题,这也是传统双IP双线机房无法相比的优势。在条件允许的情况下,服务器的租用和托管可以尽量选择BGP机房,因为会带给用户最优的访问体验。

现在云计算服务也非常流行,目前首推的就是亚马逊云(AWS)和阿里云。

对于我们来说,云计算服务提供的产品能让我们的研究发团队专注于产品开发本身,而不是购买、配置和维护硬件等繁杂的工作,还可以减少初始资金的投入。我们主要采用亚马逊云的EC2/EBS/S3服务,其实Amazon EC2主机提供了多种适用于不同使用案例的实例类型以供选择。实例类型由CPU、内存、存储和网络容量组成了不同的组合,可让我们灵活地为其选择适当的资源组合。

云计算特别适合两类网站:在某些日期或某些时间段流量会激增的网站,比如竞标业务机器,用户会集中在某些时段进行竞价,因此在这些时间段使用的Instance数量可能是白天的几倍甚至几十倍。也就是说,此时段内瞬间可能要开启很多实例处理,处理完毕后立刻终止。EC2 Instance是可以按照运行的小时数来进行收费的。像笔者公[1]司的线上系统,经常运行着很多特殊业务的Spot Instance,以小时计费,完成任务后立即终止。[1] Spot Instance:使用竞标的方式来获得便宜的Instance,一般是在需要大量、便宜、短时间使用的需求时才会使用。1.3 如何根据服务器应用选购服务器

无论物理服务器是选用IDC托管还是AWS EC2云主机(以下为了简略说明,将它们统称为服务器),我们都要面临一个问题,那就是选择服务器的硬件配置,选购硬件配置时要根据服务器的应用需求而定。因为只通过一台服务器是无法满足所有的需求,并解决所有的问题的。在设计网站的系统架构之前,应该从以下方面考虑如何选购服务器:

·服务器要运行什么应用。

·需要支持多少用户访问。

·需要多大空间来存储数据。

·业务有多重要。

·服务器网卡方面的考虑。

·安全方面的考虑。

·机架安排是否合理化。

·服务器的价格是否超出了预算。

1.服务器运行什么应用

这是选购服务器时首先需要考虑的问题,通常是根据服务器的应用类型(也就是用途),来决定服务器的性能、容量和可靠性需求。下面将按照负载均衡、缓存服务器、前端服务器、应用程序服务器、数据服务器和Hadoop分布式计算的常见基础架构来讨论。

·负载均衡端:除了网卡性能以外,其他方面对服务器的要求比较低,如果选用的是LVS负载均衡方案,那么它会直接将所有的连接要求都转给后端的Web应用服务器,因此建议选用万兆网卡。如果选用的是HAProxy负载均衡器,由于它的运行机制跟LVS不一样,流量必须双向经过HAProxy机器本身,因此对CPU的运行能力会有要求,也建议选用万兆网卡。如果选用的是AWS EC2机器,则推荐使用m3.xlarge实例类型(m3类型提供计算、内存和网络资源的平衡,因此是很多应用程序的良好选择)。另外,AWS官方也推出了负载均衡服务产品,即Elastic Load Balancing,它具有DNS故障转移和Auto Scalling的功能。

·缓存服务器:主要是Varnish和redis,对CPU及其他方面的性能要求一般,但在内存方面的要求会尽量多些。笔者曾为了保证预算,在双核(r3.large)机器上运行了4个redis实例,AWS官方也建议将此内存优化型实例应用于高性能数据库、分布式内存缓存、内存中分析、基因组装配和分析,以及SAP、Microsoft SharePoint和其他企业级应用程序的较大部署。

·应用服务器:由于它承担了计算和功能实现的重任,因此需要为基于Web架构的应用程序服务器(Application Server)选择足够快的服务器,另外应用程序服务器可能需要用到大量的内存,尤其是基于Windows基础架构的Ruby、Python、Java服务器,这一类服务器至少需要使用单路至强的配置;笔者公司线上的核心业务机器选用的AWS c3.xlarge类型。至于可靠性问题,如果你的架构中只有一台应用服务器,那这台服务器肯定要足够可靠才行,RAID是绝对不能被忽视的选项。但如果有多台应用服务器,并设计了负载均衡机制,具有冗余功能,那就不必过于担心了。注意

c3.xlarge EC2主机属于计算优化型(Compute Optimized),也就是CPU加强型。这种类型的CPU/内存比例比较大,适合于计算密集型业务,它包含c1和c3系列。其实例除了较旧的两个c1系列(c1.medium和c1.xlarge)是采用普通磁盘作为实例存储以外,其他的(也就是c3系列的)全部都以SSD作为实例存储,其中最高档次的c3.8xlarge(32核心108个计算单元)的网络性能明确标注为10G bit/s,c3系列被认为是最具性价比的类型。

·特殊应用:除了用于Web架构中的应用程序之外,如果服务器还要处理流媒体视频编码、服务器虚拟化、媒体服务器,或者作为游戏服务器(逻辑、地图、聊天)运行,那么对CPU和内存的需求同样会比较高,至少要考虑四核以上的服务器。

·公共服务:这里指的是邮件服务器、文件服务器、DNS服务器、域控服务器等。通常会部署两台DNS服务器以互相备份,域控主服务器也会拥有一台备份服务器(专用的或非专用的),所以对于可靠性,无须过于苛刻。至于邮件服务器,至少需要具备足够的硬件可靠性和容量大小,这主要是对邮件数据负责,因为很多用户没有保存和归档邮件数据的习惯,待其重装系统后,就会习惯性地到服务器上重新下载相应的数据。至于性能问题,则应评估用户数量后再做决定。另外,考虑到它的重要性,建议尽量选择稳定的服务器系统,比如Linux或BSD系列。

·数据库服务器:数据库对服务器的要求也是最高、最重要的。无论你使用的是MySQL、SQL Server还是Oracle,一般情况下,都需要有足够快的CPU、足够大的内存、足够稳定可靠的硬件。可直接采用DELL PowerEdge R710或HP 580G5,CPU和内存方面也要尽可能最大化,如果预算充分,建议用固态硬盘做RAID 10,因为数据库服务器对硬盘的I/O要求是最高的。

·Hadoop分布式计算:这里建议选用密集存储实例——D2实例,它拥有高频率Intel Xeon E5-2676v3(Haswell)处理器、高达48TB的本地存储、具备高磁盘吞吐量,并支持Amazon EC2增强型联网。它适合于大规模并行处理数据仓库、MapReduce和Hadoop分布式计算、分布式文件系统、网络文件系统、日志或数据处理等应用。

更多关于AWS EC2的实例类型请参考:https://aws.amazon.com/cn/ec2/instance-types/。

2.服务器需要支持多少用户访问

服务器就是用来给用户提供某种服务的,所以使用这些服务的用户同样是我们必须考虑的因素,可以从下面几个具体的方面进行评估:

·有多少注册用户。

·正常情况下有多少用户会同时在线访问。

·每天同时在线访问的最高峰值大概是多少。

一般在项目实施之前,客户方面会针对这些问题给出一个大致的结果,但设计要尽量更充分和具体,同时,还要对未来的用户增长做一个尽可能准确的预测和规划,因为服务器可能会支持越来越多的用户,所以在进行网站或系统架构设计时要让机器能够灵活地扩展。

3.需要多大空间来存储数据

关于这个问题需要从两个方面来考虑,一方面是有哪些类别的数据,包括:操作系统本身占用的空间,安装应用程序所需要的空间,应用程序所产生的数据、数据库、日志文件、邮件数据等,如果网站是Web 2.0的,还要计算每个用户的存储空间;另一方面是从时间轴上来考虑,这些数据每天都在增长,至少要为未来两三年的数据增长做个准确的预算,这就需要软件开发人员和业务人员一起来提供充分的信息了。最后将计算出来的结果乘上1.5左右的系数,以方便维护的时候做各种数据的备份和文件转移操作。

4.我的业务有多重要

这需要根据自身的业务领域来考虑,下面举几个简单的例子,帮助大家了解这些服务器对可靠性、数据完整性等方面的要求:

·如果服务器是用来运行一个WordPress博客的,那么,一台酷睿处理器的服务器、1GB的内存,外加一块160GB的硬盘就足够了(如果是AWS EC2主机,可以考虑t2.micro实例类型)。就算服务器出现了一点硬件故障,导致几个小时甚至一两天不能提供访问,生活也会照常继续。

·如果服务器是用作测试平台的,那么就不会如生产环境那样对可靠性有极高的要求,所需要的可能只是做好例行的数据备份即可,若服务器宕机,只要能在当天把问题解决掉就可以了。

·如果是一家电子商务公司的服务器,运行着电子商务网站平台,当硬件发生故障而导致宕机时,你需要对以下“危言耸听”的后果做好心理准备:投诉电话被打爆、顾客大量流失、顾客要求退款、市场推广费用打水漂、员工无事可干、公司运营陷入瘫痪状态、数据丢失。事实上,电子商务网站一般是需要365×24小时不间断运行和监控的,而且要有专人轮流值守,并且要有足够的备份设备,每天还要有专人负责检查。

·如果是大型广告类或门户类网站,那么建议选择CDN系统。由于它具有提高网站响应速度、负载均衡、有效抵御DDoS攻击等特点,相对而言,每个节点都会有大量的冗余。

这里其实只是简单地讨论下业务对服务器硬件可靠性的要求。要全面解决这个问题,不能只考虑单个服务器的硬件,还需要结合系统架构的规划设计。

在回答了以上问题后,接下来就可以决定下面这些具体的选项了。(1)选择什么CPU

回忆一下上面关于“服务器运行什么应用”和“需要支持多少用户访问”两个方面的考虑,这将帮助我们选择合适的CPU。毫无疑问,CPU的主频越高,其性能也就越高;两个CPU要比一个CPU来得更好;至强(Xeon)肯定比酷睿(Core)的性能更强。但究竟怎样的CPU才是最合适的呢?下面提供了一些常见情况下的建议:

·如果业务刚刚起步,预算不是很充足,建议选择一款经典的酷睿服务器,这可以帮你节约大量的成本。而且,以后还可以根据业务发展的情况,随时升级到更高配置的服务器。

·如果需要在一台服务器上同时运行多种应用服务,例如基于LNMP架构的Web网站,那么一个单核至强(例如X3330)或新一代的酷睿I5(双核四线程)将是最佳的选择。虽然从技术的角度来说,这并不是一个好主意,但至少能节约一大笔成本。

·如果服务器要运行MySQL或Oracle数据库,而且目前有几百个用户同时在线,未来还会不断增长,那么至少应该选择安装一个双四核服务器。

·如果需要的是Web应用服务器,双四核基本就可以满足要求了。(2)需要多大的内存

同样,“服务器运行什么应用”和“需要支持多少用户访问”两方面的考虑也将有助于我们选择合适的内存容量。相比于CPU,笔者认为内存(RAM)才是影响性能的最关键因素。因为在很多正在运行的服务器中,CPU的利用率一般都在10%~30%之间,甚至更低。但由于内存容量不够而导致服务器运行缓慢的案例比比皆是,如果服务器不能分配足够的内存给应用程序,那么应用程序就需要通过硬盘接口缓慢地交换读写数据了,这将导致网站慢得令人无法接受。内存的大小主要取决于服务器的用户数量,当然也和应用软件对内存的最低需求和内存管理机制有关,所以,最好由程序员或软件开发商给出最佳的内存配置建议。下面同样给出了一些常见应用环境下的内存配置建议:

·无论是Apache还是Nginx服务器,一般情况下Web前端服务器都不需要配置特别高的内存,尤其是在集群架构中,4GB的内存就已经足够了。如果用户数量持续增加,我们才会考虑使用8GB或更大的内存。单Apache Web机器,在配置了16GB的内存后,可以抗6000个并发链接数。

·对于运行Tomcat、Resin、WebLogic的应用服务器,8GB内存应该是基准配置,更准确的数字需要根据用户数量和技术架构来确定。

·数据库服务器的内存由数据库实例的数量、表大小、索引、用户数量等来决定,一般建议配置16GB以上的内存,笔者公司在许多项目方案中使用了24GB到48GB的内存。

·诸如Postfix和Exchange这样的邮件服务器对内存的要求并不高,1GB~2GB就可以满足了。

·还有一些特殊的服务器,需要为之配置尽可能大的内存容量,比如配置有Varnish和Memcached的缓存服务器等。

·若是只有一台文件服务器,1GB的内存可能就足够了。

事实上,由于内存技术在不断进化,价格也在不断降低,因此才得以近乎奢侈地讨论4GB、8GB、16GB这些曾经不可想象的内存容量。然而,除了花钱购买内存来满足应用程序的“贪婪”之外,系统优化和数据库优化仍然是我们需要重视的问题。(3)需要怎样的硬盘存储系统

硬盘存储系统的选择和配置是整个服务器系统里最复杂的一部分,需要考虑硬盘的数量、容量、接口类型、转速、缓存大小,以及是否需要RAID卡、RAID卡的型号和RAID级别等问题。甚至在一些高可靠性高性能的应用环境中,还需要考虑使用怎样的外部存储系统(SAN、NAS或DAS)。下面将服务器的硬盘RAID卡的特点归纳一下:

·如果是用作缓存服务器,比如Varnish或redis,则可以考虑用RAID 0。

·如果是跑Nginx+FastCGI或Nginx等应用,则可以考虑用RAID 1。

·如果是内网开发服务器或存放重要代码的服务器,则可以考虑用RAID 5。

·如果是跑MySQL或Oracle等数据库应用,则可以考虑用固态硬盘做RAID 5或RAID 10。

5.网卡性能方面的考虑

如果基础架构是多服务器环境,而且服务器之间有大量的数据交换,那么建议为每台服务器配置两个或更多的网卡,一个用来对外提供服务,另一个用来做内部数据交换。由于现在项目外端都置于防火墙内,所以许多时候单网卡就足够了;而比如LVS+Keepalived这种只用公网地址的Linux集群架构,有时可能只需要一块网卡即可。建议大家选用万兆网卡。另外,建议交换机至少也要选择千兆网卡级别的。

如果采用的是AWS EC2云主机环境,单纯以EC2作为LVS或HAProxy意义不大。如果经常使用AWS EC2机器,应该会注意到AWS将机器的网卡性能分成了3个级别,即Low、Moderate、High,那么这3个级别分别是什么情况呢?虽然AWS没有带宽限制,但是由于多虚拟机共享HOST物理机的网络性能和I/O性能,单个虚拟机的网络性能也不是特别好度量,不过大概情况是这样的:Low级别的是20M bit/s,Moderate级别的是40M bit/s,High级别的能达到80M bit/s~100M bit/s。从上面的分析情况可以得知,单台AWS EC2主机作为网站的负载均衡入口,容易成为网站的瓶颈。这个时候可以考虑使用AWS提供的Elastic Load Balancing产品,它可以在云中的多个Amazon EC2实例间自动分配应用程序的访问流量(大家注意到没,相当于它将网站的流量分担到了多台机器上)。它可以实现更高水平的应用程序容错性能,从而无缝地提供分配应用程序流量所需的负载均衡容量。除了提供负载均衡常见的功能之外,它还具有Auto Scalling功能,关于Auto Scalling的详细介绍,可参见AWS官方文档。

6.服务器安全方面的考虑

由于目前国内的DDoS攻击还是比较普遍的,因此建议给每个项目方案和自己的电子商务网站配备硬件防火墙,比如Juniper、Cisco等硬件防火墙。当然了,这个问题也是网站后期运营维护需要考虑的,这里只是想让大家有个概念性的认识。此外,建议租赁CDN服务,这样万一不幸遭遇恶意的DDoS流量攻击,CDN还能帮助抵挡部分恶意流量,核心机房的业务不至于在很短的时间内就会崩溃。

7.根据机架数合理安排服务器的数量

这个问题应该在项目实施前就处理好了的,选择服务器时应该明确服务器的规格,即到底是1U、2U还是4U的,到底有多少台服务器和交换机,应该如何安排,毕竟机柜只有42U的容量。在小项目中这个问题可能无关紧要,但在大型项目的实施过程中,这个问题就很突出了。我们应该根据现有或额定的机架数目确定到底应该选择多少台服务器和交换机。

8.成本考虑:服务器的价格问题

无论是在公司采购时,还是在项目实施过程中,成本都是非常重要的问题。笔者的方案经常被退回,理由就是超出预算。尤其对于一些小项目,预算更吃紧。之前笔者经常面对的客户需求是为证券类资讯网站设计方案,只要求周一至周日的上午九点至下午三点网站不出问题即可,并不需要做复杂的负载均衡高可用。所以面对这种需求,笔者会将单Nginx或HAProxy设计成负载均衡,后面接两台Web应用服务器作为简单集群架构。如果是做中大型电子商务网站,那么在服务器成本上的控制就尤其重要了。事实上,我们经常面对的问题是,客户给出的成本预算有限,而实际应用又需要比较多的服务器,这时候,就不得不另外设计一套最小化成本预算方案来折中处理。

以上8个方面是我们在采购服务器时应该要注意的因素,在选择服务器的组件时要有所偏重,然后根据系统或网站架构来决定服务器的数量,尽量做到服务器资源利用的最大化。在控制方案成本的同时,要做到最优的性价比。1.4 CentOS 6.4 x86_64最小化安装后的优化

购买了服务器以后要做的第一件事就是安装操作系统了,这里推荐安装CentOS 6.4 x86_64,安装系统时要选择最小化安装(不需要图形),在使用服务器时要记住一个原则,系统安装的应用程序包越少,服务器就会越稳定。至于服务器单机性能调优,应本着稳定安全的原则,尽量不要改动系统原有的配置(CentOS系统自身的文件和内存机制就很优秀),以下配置优化部分也适合Amazon Linux系统,大家可以对比参考。1.4.1 系统的基础优化

1.更新yum官方源

CentOS 6.4系统自带的更新源速度比较慢,想必各位都有所感受,国内的速度慢得让人受不了。为了让CentOS 6.4系统使用速度更快的yum更新源,一般做运维的都会选择更换源,笔者一般会选择网易的更新源,详细步骤如下所示。

1)下载repo文件,命令如下:wget http://mirrors.163.com/.help/CentOS6-Base-163.repo

2)备份并替换系统的repo文件,命令如下:cd /etc/yum.repos.d/mv CentOS-Base.repo CentOS-Base.repo.bakmv CentOS6-Base-163.repo CentOS-Base.repo

3)执行yum源更新,命令如下:清除缓存yum clean all #yum重建缓存yum makecache #升级系统yum update #Linux

增加epel源,详细步骤如下所示。

1)下载rpm文件并进行安装,命令如下:wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpmrpm -ivh epel-release-6-8.noarch.rpm

2)安装yum-priorities源优先级工具,命令如下:yum install yum-priorities

yum-priorities源优先级工具是yum-plugin-priroites插件,用于给yum源划分优先级。比如说系统存在官方源、epel、puppetlabs3个yum源,这3个yum源中可能含有相同的软件,yum管理器会应用该工具来分辨安装软件时采用哪个yum源的软件。

如果说,设置官方的yum源优先级最高,epel yum源第二,puppetlabs第三(用1到99来表示,1最高),那么在安装程序的时候,就会先寻找官方的yum源。如果该源里面有所要的程序,那就停止寻找,直接安装找到的;如果没有找到,则依次寻找epel和puppetlabs的源。如果说3个yum源都含有同一个软件,那就安装优先级最高的官方yum源的。添加优先级的过程比较简单,只需要编辑对应的repo文件,在文件最后添加如下内容即可:对应优先级数字priority=

注意,要想开启yum源的优先级功能,就要先确保priorities.conf文件里面有如下内容,需要先打开此文件,打开文件的命令如下:vim /etc/yum/pluginconf.d/priorities.conf

确保文件里面包含如下内容:[main]enabled=1

2.关闭不需要的服务

众所周知,服务越少,系统占用的资源就会越少,所以应当关闭不需要的服务。建议把不需要的服务关闭掉,这样做的好处是减少内存和CPU资源占用。首先可以看下系统中存在着哪些已经启动了的服务,查看命令如下:ntsysv

下面列出的是需要启动的服务,未列出的服务一律关闭。

·crond:自动计划任务。

·network:Linux系统的网络服务,很重要,若不开启此服务的话,服务器就不能联网。

·sshd:OpenSSH服务器守护进程。

·rsyslog:Linux的日志系统服务(CentOS 5.8下此服务名称为syslog),必须要启动。

3.关闭不需要的TTY

可用vim编辑器打开vim/etc/init/start-ttys.conf文件,文件内容如下所示:start on stopped rc RUNLEVEL=[2345]env ACTIVE_CONSOLES=/dev/tty[1-6]env X_TTY=/dev/tty1taskscript . /etc/sysconfig/init for tty in $(echo $ACTIVE_CONSOLES) ; do [ "$RUNLEVEL" = "5" -a "$tty" = "$X_TTY" ] && continue initctl start tty TTY=$tty doneend script

这段代码使init打开了6个控制台,可分别用ALT+F1到ALT+F6进行访问。此6个控制台默认都驻留在内存中,用ps aux命令即可看到,命令如下:ps aux | grep tty | grpe -v grep

命令显示结果如下所示:root 1011 0.0 0.1 4060 288 tty1 Ss+ Nov25 0:00 /sbin/mingetty /dev/tty1root 1013 0.0 0.1 4060 292 tty2 Ss+ Nov25 0:00 /sbin/mingetty /dev/tty2root 1015 0.0 0.1 4060 292 tty3 Ss+ Nov25 0:00 /sbin/mingetty /dev/tty3root 1017 0.0 0.1 4060 288 tty4 Ss+ Nov25 0:00 /sbin/mingetty /dev/tty4root 1019 0.0 0.1 4060 288 tty5 Ss+ Nov25 0:00 /sbin/mingetty /dev/tty5root 1021 0.0 0.1 4060 292 tty6 Ss+ Nov25 0:00 /sbin/mingetty /dev/tty6root 7467 0.0 0.1 4072 340 hvc0 Ss+ Nov29 0:00 /sbin/agetty /dev/hvc0 38400 vt100-nav

事实上没有必要使用这么多,那如何关闭不需要的进程呢?

通常保留两个控制台就可以了,打开/etc/init/start-ttys.conf文件,注意以下代码内容:env ACTIVE_CONSOLES=/dev/tty[1-6]

将[1-6]修改为[1-2],然后再打开/etc/sysconfig/init文件,注意以下代码内容:ACTIVE_CONSOLES=/dev/tty[1-6]

将[1-6]修改为[1-2],然后重启机器即可。

4.对TCP/IP网络参数进行调整

调整TCP/IP网络参数,可以加强对抗SYN Flood的能力,命令如下:echo 'net.ipv4.tcp_syncookies = 1' >> /etc/sysctl.confsysctl -p

5.修改SHELL命令的history记录个数

用vim编辑器打开/etc/profile文件,关注HISTSIZE=1000:vi /etc/profile

在找到HISTSIZE=1000后,将其改为HISTSIZE=100(这条可根据实际工作环境而定)。

不需要重启系统也可让其生效,命令如下:source /etc/profile

6.定时校正服务器的时间

我们可以定时校正服务器的时间,命令如下:yum install ntpcrontab -e

加入一行:*/5 * * * * /usr/sbin/ntpdate ntp.api.bz

ntp.api.bz是一组NTP服务器集群,之前是6台服务器,位于上海电信;现在是3台服务器,分散于上海和浙江电信,可以用dig命令查看:dig ntp.api.bz

命令显示结果如下所示:; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.5 <<>> ntp.api.bz;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48560;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0;; QUESTION SECTION:;ntp.api.bz. IN A;; ANSWER SECTION:ntp.api.bz. 600 IN A 61.153.197.226ntp.api.bz. 600 IN A 218.75.4.130ntp.api.bz. 600 IN A 114.80.81.1;; Query time: 10 msec;; SERVER: 202.103.24.68#53(202.103.24.68);; WHEN: Thu Dec 24 06:58:36 2015;; MSG SIZE rcvd: 76

7.停止IPv6网络服务

在CentOS 6.4默认的状态下,IPv6是被启用的,可用如下命令查看:lsmod | grep ipv6

试读结束[说明:试读内容隐藏了图片]

下载完整电子书


相关推荐

最新文章


© 2020 txtepub下载