Linux集群和自动化运维.html.pdf
《Linux集群和自动化运维.html.pdf》由会员分享,可在线阅读,更多相关《Linux集群和自动化运维.html.pdf(80页珍藏版)》请在三一文库上搜索。
1、推荐序一 在全球“互联网”的大背景下,互联网创业企业的数量如雨后春笋般大量产生并得到了快速发展!对“互联网”最有力的支撑就是Linux运维架构师、云计算和大数据工程师,以及自动化开发工程 师等! 但是,随着计算机技术的发展,企业对Linux运维人员的能力要求越来越高,这就使得很多想入门运维的新手不知所措,望而却步,甚至努力了很久却仍然徘徊在运维岗位的边缘;而有些已经工作了的 运维人员也往往是疲于奔命,没有时间和精力去学习企业所需的新知识和新技能,从而使得个人的职业发展前景大大受限。 本书就是在这样的背景下诞生并致力于为上述问题提供解决方案的,本书是作者余洪春先生10多年来一线工作经验的“再”结
2、晶,此前作者已经出版过Linux集群方向的图书(构建高可用Linux服务 器),本次出版的书是作者对运维行业的再回馈。 书中不仅涵盖了入门运维人员必须了解的IDC和CDN服务的选型、Linux系统及常见服务的优化实践内容,还有对于企业运维人员需要的大规模集群场景下必备的运维自动化Shell和Python企业开发应用 实践案例、热门的自动化运维工具的企业应用实践、大规模集群及高可用的企业案例分享与安全防护等。 本书能够帮助运维人员掌握业内运维实战专家的网站集群的企业级应用经验的精髓,从而以较高的标准胜任各类企业运维的工作岗位,并提升自己的运维职业发展竞争力,值得一读! 老男孩 老男孩Linux实
3、战运维培训中心总裁 跟老男孩学Linux运维:Web集群实战作者 推荐序二 本书作者余洪春先生和我相识于ChinaUnix举办的一次技术交流活动“千万级PV高性能高并发网站架构与设计交流”,当时他已经在宣传自己的第一本著作构建高可用Linux服务器,该书凝 聚并整合了他多年来在一线工作的经验结晶,以至时至今日,该书仍是一本在国内非常经典的运维原创著作,现在已经更新到第三版,这种对技术不断进行完善的坚持及工匠精神让我深深折服。这次能受 邀为他的新书Linux集群和自动化运维写推荐序,让我倍感荣幸。 本书覆盖了Linux集群服务的核心技术,同时还介绍了基于Python语言构建的主流自动化运维工具,
4、包括Python脚本、Fabric、Ansible等,这些都是DevOps工具元素周期表中最闪亮的内容,也是运维人 员必备的技能。本书中分享的案例是余洪春多年实战经验的精华,具有非常高的参考价值及借鉴意义。 书中内容从互联网业务平台构建及自动运维的场景出发,以常见的业务服务为基础,给出了大量的实战案例,这些都是作者在十余年的互联网运维工作中总结出来的宝贵经验,相信会给读者带来不少 启发及思考。 更难能可贵的是,作者能从通俗易懂的角度出发,由浅入深地剖析自动运维管理之道。对于不同水平层次的读者来说,都能有效地阅读和吸收,也能根据实际需要各取所需。 最后,感谢余洪春给中国互联网从业者带来这么好的图
5、书,我相信阅读本书的每一位读者都能从中获取提升的能量,为企业及行业做出自己的贡献。 腾讯高级工程师 刘天斯 前言 为什么要写这本书 笔者从事系统运维和网站架构设计的工作已有10多年,现在在一家外企担任云平台架构师。云计算是现在的主流技术,未来也有很好的发展趋势,云计算的流行对于传统的运维知识体系来说,其实也 造成了冲击,有很多读者经常向笔者咨询工作中的困惑,比如从事系统运维工作35年后就不知道该如何继续学习和规划自己的职业生涯了。因此笔者想通过此书,跟大家分享一下自己的工作经验和心得 (包括传统运维和云平台运维工作的区别与对比),以期解决大家在工作中的困惑。本书提供了大量项目实践和线上案例,希
6、望能让大家迅速了解Linux运维人员的工作职责,快速进入工作状态并找到成长 方向。希望大家通过阅读此书,能够掌握Linux系统集群和自动化运维及网站架构设计的精髓,从而能够轻松愉快地工作,并提升自己的职业技能,这就是笔者写作此书的初衷。 运维架构师之路 在成为运维架构师之前,笔者从事过很长一段时间的系统集成、运维和管理工作,在CDN门户网站、电子广告、电子商务领域也有不少的沉淀和积累,在之前的构建高可用Linux服务器一书中已经 跟大家分享了很多跟Linux集群有关的知识。笔者目前的主要工作职责是维护和优化公司的DSP电子广告业务平台,主要方向是云计算和大数据方面。需要维护的数据中心和机器数量
7、非常之多,所以自动化 运维和DevOps是目前的主要工作方向,此外,也会涉及网站架构设计及调优工作,因此在此书中特意将这部分工作经验分享出来,希望大家能从中学到新的知识体系,借以提升自己的职业技能。 读者对象 本书适合以下读者阅读。 中高级系统管理员 系统架构设计师 高级程序开发人员 运维开发工程师 如何阅读本书 本书是笔者对实际工作中积累的技术和经验所做的总结,涉及大量的知识点和专业术语。全书总共分为三大部分,第一部分包含第1章和第2章,主要讲解进行系统架构设计的软硬件环境,以及生产环 境下的Shell脚本和Python脚本。其中,第2章的内容是以Shell为主,Python为辅,Shell
8、部分讲得比较详细,Python部分需要重点关注的地方也有所提及。之所以这样安排,主要是考虑到大多数搞开发的读者 或DevOps工程师都是Java程序员出身,对Shell脚本语言不是很熟悉。第二部分包含第3章、第4章和第5章,主要讲自动化运维,包括Fabric、Ansibel和Puppet三大工具,大家可以结合自己的实际环境来选择对 应的工具。第三部分包含第6章、第7章和第8章,主要讲的是Linux集群和网站架构设计,特别是第8章,分别以百万PV、千万PV及亿级PV的网站为例来详细说明网站系统架构设计的相关技术,然后细分五 层来解说网站的架构,并指出了设计网站的压力及关注点所在。 大家可以根据自
9、己的职业发展和工作需求来选择不同的章节进行阅读或学习。 关于本书中的配置文件、Shell脚本和Python脚本的编号,这里也略作说明,比如1.5.3节中有1.sh,表示这是1.5.3节的第一个Shell脚本;如果是2.py,则表示是1.5.3节的第二个Python脚本;其他依此类 推,在哪个章节中出现的配置文件或脚本就在哪个章节中寻找,这样对照起来阅读理解会比较方便。此外,书中多次出现的Nginx配置文件nginx.conf也在对应的章节里。本书相关的GitHub地址 为http:/ 勘误 尽管笔者花费了大量的时间和精力来核对文件和语法,但书中难免还会存在一些错误和纰漏,如果大家发现有任何问题
10、,都请及时反馈给我,相关信息可以发到个人邮箱。尽 管无法保证对于每一个问题都会有一个正确答案,但我肯定会努力回答并且指出一个正确的方向。 致谢 感谢爱女媛媛的出生,你的降临是上天赐给我的最好礼物,是我进行写作的源泉和动力。 感谢我的家人,他们在生活上对我的照顾无微不至,让我有更多的精力和动力去工作和创作。 感谢好友三宝这么多年来对我的信任和支持,从始至终一直都在支持和信任我。 感谢机械工业出版社华章公司的编辑杨福川和杨绣国,在你们的信任、支持和帮助下,我才能如此顺利地完成全部书稿。 感谢好友老男孩和刘天斯,闲暇之余和你们一起交流开源技术和发展趋势,也是一种享受。 感谢Linux之父Linus
11、Torvalds,他不仅创造了Linux系统,而且还创造了Git这么神奇的版本管理软件。 余洪春(抚琴煮酒) 中国,武汉 第1章 系统架构设计的构建基础 作为一名系统架构设计师,会面临着很多系统方面的架构设计工作,比如电子商务系统、CDN(内容分发网络)大型电子广告平台和DSP电子广告系统的运维方案确定及平台架构设计等,此外,还会 涉及核心业务的系统在线优化及升级等工作。在以上这些工作中,又将包括多项选择:比如是考虑自建CDN,还是租赁CDN系统;公司的业务系统所在的机房是考虑自建机房、托管机房,还是云计算平 台,而如果选择托管机房,又会有更多的细节需要考虑,比如是选择电信机房、双线机房还是B
12、GP机房,服务器应该如何选型,选择哪种操作系统等,这个时候系统架构设计师的经验和作用就体现出来 了。他们应该在系统网站实施的初期就做好项目的成本预算和风险规避,并对系统的高可用及扩展性进行细致权衡,这些也是其工作职责所在。当然,在了解上述这些之前,首先应该了解一些网站架构设 计相关的专业术语,下面就一起来看看。 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.
13、1采用了效率更高的持续连接机制,即客户端和服务器建立TCP连接以后,后续相关联的HTTP请求可以重复利用已经建立起来的TCP连接。 HTTP 1.1是用来在Internet上传送超文本的传送协议。它是运行在TCP/IP协议族之上的HTTP应用协议,它可以使浏览器更加高效,并减少网络传输。任何服务器除了包括HTML文件以外,都还有一个 HTTP驻留程序,用于响应用户请求。如果浏览器是HTTP客户,在向服务器发送请求时,向浏览器中输入一个开始文件或点击一个超级链接,浏览器就向服务器发送HTTP请求,此请求被送往由URL指定的 IP地址。驻留程序接收到请求,在进行必要的操作后就会回送所要求的文件。
14、HTTP 1.1支持持续连接。通过这种连接,就有可能在建立一个TCP连接后,发送请求并得到回应,然后发送更多的请求并得到更多的回应。由于把建立和释放TCP连接的开销分摊到了多个请求上,因 此对于每个请求而言,由于TCP连接而造成的相对开销就被大大地降低了。而且,还可以发送流水线请求,也就是说在发送请求1的回应到来之前就发送请求2。也可以认为,一次连接发送多个请求,由客 户机确认是否关闭连接,而服务器会认为这些请求分别来自于不同的请求。 1.2 IDC机房的选择及CDN的选型 如果自己的业务网站中含有大量的图片和视频类文件,为了加快客户端的访问速度,同时为了减缓对真正的核心机房的服务压力,并且提
15、升用户体验,建议在前端最好采用CDN缓存加速方案。 CDN(Content Delivery Network),即内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构,将网站的内容发布到最接近用户的网络“边缘”,使用户可以就近取得所需的内 容,提高用户访问网站的响应速度。CDN缓存加速方案一般有如下几种方式。 租赁CDN:中小型网站直接购买服务就好,现在CDN已经进入按需付费的云计算模式了,性价比是可以准确计算的。 自建CDN:这种方案的成本就有点大了,为了保证良好的缓存效果,必须在全国机房布点,还要自建智能Bind系统,搭建大型网站时推荐采用此种方案,专业的视频网站或图片
16、网站一般会考虑采用 此种方案。 IDC机房的选择一般也有几种类型。 单电信IDC机房:这种类型一般业务模式比较固定,访问量也不是很大,适合新闻类网站或政务类网站。如果网站的PV流量持续增加的话,则建议后期采用租赁CDN的方式解决非电信用户访问网站 速度过慢的问题。 双线IDC机房:由于国内两大网络(电信和网通)之间存在互联互通的问题,导致电信用户访问网通网站或网通用户访问电信网站速度很慢,因此就产生了双线机房、双线服务器、双线服务器托管 和双线服务器租用服务。双线机房实际是一个机房有电信和网通两条线路。双线机房通过内部路由器设置,以及BGP自动路由的分析,可实现电信用户访问电信线路,网通用户访
17、问网通线路,这样就可实 现电信网通的快速访问。 BGP机房:BGP(边界网关协议)是用来连接Internet独立系统的路由选择协议。它是Internet工程任务组制定的一个加强的、完善的、可伸缩的协议。BGP4支持CIDR寻址方案,该方案增加了Internet 上的可用IP地址数量。BGP是为取代最初的外部网关协议EGP而设计的。它也被认为是一个路径矢量协议。采用BGP方案来实现双线路互联或多线路互联的机房,则称为BGP机房。对于用户来说,选择 BGP机房可以实现网站在各运营商线路之间互联互通,使得所有互联运营商的用户访问网站都很快,且更加稳定,不用担心全国各地因线路问题带来的访问速度快慢不一
18、的问题,这也是传统双IP双线机房 无法相比的优势。在条件允许的情况下,服务器的租用和托管可以尽量选择BGP机房,因为会带给用户最优的访问体验。 现在云计算服务也非常流行,目前首推的就是亚马逊云(AWS)和阿里云。 对于我们来说,云计算服务提供的产品能让我们的研究发团队专注于产品开发本身,而不是购买、配置和维护硬件等繁杂的工作,还可以减少初始资金的投入。我们主要采用亚马逊云的EC2/EBS/S3服 务,其实Amazon EC2主机提供了多种适用于不同使用案例的实例类型以供选择。实例类型由CPU、内存、存储和网络容量组成了不同的组合,可让我们灵活地为其选择适当的资源组合。 云计算特别适合两类网站:
19、在某些日期或某些时间段流量会激增的网站,比如竞标业务机器,用户会集中在某些时段进行竞价,因此在这些时间段使用的Instance数量可能是白天的几倍甚至几十倍。 也就是说,此时段内瞬间可能要开启很多实例处理,处理完毕后立刻终止。EC2 Instance是可以按照运行的小时数来进行收费的。像笔者公司的线上系统,经常运行着很多特殊业务的Spot Instance1,以 小时计费,完成任务后立即终止。 1 Spot Instance:使用竞标的方式来获得便宜的Instance,一般是在需要大量、便宜、短时间使用的需求时才会使用。 1.3 如何根据服务器应用选购服务器 无论物理服务器是选用IDC托管还是
20、AWS EC2云主机(以下为了简略说明,将它们统称为服务器),我们都要面临一个问题,那就是选择服务器的硬件配置,选购硬件配置时要根据服务器的应用需求 而定。因为只通过一台服务器是无法满足所有的需求,并解决所有的问题的。在设计网站的系统架构之前,应该从以下方面考虑如何选购服务器: 服务器要运行什么应用。 需要支持多少用户访问。 需要多大空间来存储数据。 业务有多重要。 服务器网卡方面的考虑。 安全方面的考虑。 机架安排是否合理化。 服务器的价格是否超出了预算。 1.服务器运行什么应用 这是选购服务器时首先需要考虑的问题,通常是根据服务器的应用类型(也就是用途),来决定服务器的性能、容量和可靠性需
21、求。下面将按照负载均衡、缓存服务器、前端服务器、应用程序服务 器、数据服务器和Hadoop分布式计算的常见基础架构来讨论。 负载均衡端:除了网卡性能以外,其他方面对服务器的要求比较低,如果选用的是LVS负载均衡方案,那么它会直接将所有的连接要求都转给后端的Web应用服务器,因此建议选用万兆网卡。如果选 用的是HAProxy负载均衡器,由于它的运行机制跟LVS不一样,流量必须双向经过HAProxy机器本身,因此对CPU的运行能力会有要求,也建议选用万兆网卡。如果选用的是AWS EC2机器,则推荐使用 m3.xlarge实例类型(m3类型提供计算、内存和网络资源的平衡,因此是很多应用程序的良好选择
22、)。另外,AWS官方也推出了负载均衡服务产品,即Elastic Load Balancing,它具有DNS故障转移和Auto Scalling的功能。 缓存服务器:主要是Varnish和redis,对CPU及其他方面的性能要求一般,但在内存方面的要求会尽量多些。笔者曾为了保证预算,在双核(r3.large)机器上运行了4个redis实例,AWS官方也建议将此 内存优化型实例应用于高性能数据库、分布式内存缓存、内存中分析、基因组装配和分析,以及SAP、Microsoft SharePoint和其他企业级应用程序的较大部署。 应用服务器:由于它承担了计算和功能实现的重任,因此需要为基于Web架构的
23、应用程序服务器(Application Server)选择足够快的服务器,另外应用程序服务器可能需要用到大量的内存,尤其是基 于Windows基础架构的Ruby、Python、Java服务器,这一类服务器至少需要使用单路至强的配置;笔者公司线上的核心业务机器选用的AWS c3.xlarge类型。至于可靠性问题,如果你的架构中只有一台应用服 务器,那这台服务器肯定要足够可靠才行,RAID是绝对不能被忽视的选项。但如果有多台应用服务器,并设计了负载均衡机制,具有冗余功能,那就不必过于担心了。 注意 c3.xlarge EC2主机属于计算优化型(Compute Optimized),也就是CPU加强
24、型。这种类型的CPU/内存比例比较大,适合于计算密集型业务,它包含c1和c3系列。其实例除了较旧的两个c1系列 (c1.medium和c1.xlarge)是采用普通磁盘作为实例存储以外,其他的(也就是c3系列的)全部都以SSD作为实例存储,其中最高档次的c3.8xlarge(32核心108个计算单元)的网络性能明确标注为10G bit/s,c3系列被认为是最具性价比的类型。 特殊应用:除了用于Web架构中的应用程序之外,如果服务器还要处理流媒体视频编码、服务器虚拟化、媒体服务器,或者作为游戏服务器(逻辑、地图、聊天)运行,那么对CPU和内存的需求同 样会比较高,至少要考虑四核以上的服务器。 公
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Linux 集群 自动化 html
链接地址:https://www.31doc.com/p-5518537.html