IT运维工程师基础知识Word下载.docx
《IT运维工程师基础知识Word下载.docx》由会员分享，可在线阅读，更多相关《IT运维工程师基础知识Word下载.docx（12页珍藏版）》请在冰豆网上搜索。
热替换（Hotreplacement）、热添加（hotexpansion）和热升级（hotupgrade），
3Failover失效转移
通俗地说，即当A无法为客户服务时，系统能够自动地切换，使B能够及时地顶上继续为客户提供服务，且客户感觉不到这个为他提供服务的对象已经更换。
4磁盘阵列RAID
磁盘阵列（RedundantArraysofIndependentDisks，RAID），有“独立磁盘构成的具有冗余能力的阵列”之意。
磁盘阵列是由很多价格较便宜的磁盘，组合成一个容量巨大的磁盘组，利用个别磁盘提供数据所产生加成效果提升整个磁盘系统效能。
利用这项技术，将数据切割成许多区段，分别存放在各个硬盘上。
磁盘阵列还能利用同位检查（ParityCheck）的观念，在数组中任意一个硬盘故障时，仍可读出数据，在数据重构时，将数据经计算后重新置入新硬盘中。
4.1RAID级别
4.1.1RAID0
RAID0是最早出现的RAID模式，即DataStripping数据分条技术。
RAID0是组建磁盘阵列中最简单的一种形式，只需要2块以上的硬盘即可，成本低，可以提高整个磁盘的性能和吞吐量。
RAID0没有提供冗余或错误修复能力，但实现成本是最低的。
RAID0最简单的实现方式就是把N块同样的硬盘用硬件的形式通过智能磁盘控制器或用操作系统中的磁盘驱动程序以软件的方式串联在一起创建一个大的卷集。
在使用中电脑数据依次写入到各块硬盘中，它的最大优点就是可以整倍的提高硬盘的容量。
如使用了三块80GB的硬盘组建成RAID0模式，那么磁盘容量就会是240GB。
其速度方面，各单独一块硬盘的速度完全相同。
最大的缺点在于任何一块硬盘出现故障，整个系统将会受到破坏，可靠性仅为单独一块硬盘的1/N。
4.1.2RAID1
RAID1称为磁盘镜像，原理是把一个磁盘的数据镜像到另一个磁盘上，也就是说数据在写入一块磁盘的同时，会在另一块闲置的磁盘上生成镜像文件，在不影响性能情况下最大限度的保证系统的可靠性和可修复性上，只要系统中任何一对镜像盘中至少有一块磁盘可以使用，甚至可以在一半数量的硬盘出现问题时系统都可以正常运行,当一块硬盘失效时，系统会忽略该硬盘，转而使用剩余的镜像盘读写数据，具备很好的磁盘冗余能力。
虽然这样对数据来讲绝对安全，但是成本也会明显增加，磁盘利用率为50%，以四块80GB容量的硬盘来讲，可利用的磁盘空间仅为160GB。
另外，出现硬盘故障的RAID系统不再可靠，应当及时的更换损坏的硬盘，否则剩余的镜像盘也出现问题，那么整个系统就会崩溃。
更换新盘后原有数据会需要很长时间同步镜像，外界对数据的访问不会受到影响，只是这时整个系统的性能有所下降。
因此，RAID1多用在保存关键性的重要数据的场合。
4.1.3RAID0+1
RAID0+1名称上我们便可以看出是RAID0与RAID1的结合体。
在我们单独使用RAID1也会出现类似单独使用RAID0那样的问题，即在同一时间内只能向一块磁盘写入数据，不能充分利用所有的资源。
为了解决这一问题，我们可以在磁盘镜像中建立带区集。
因为这种配置方式综合了带区集和镜像的优势，所以被称为RAID0+1。
把RAID0和RAID1技术结合起来，数据除分布在多个盘上外，每个盘都有其物理镜像盘，提供全冗余能力，允许一个以下磁盘故障，而不影响数据可用性，并具有快速读/写能力。
RAID0+1要在磁盘镜像中建立带区集至少4个硬盘。
4.1.4RAID5
RAID3和RAID5都是校验方式。
RAID3的工作方式是用一块磁盘存放校验数据。
由于任何数据的改变都要修改相应的数据校验信息，存放数据的磁盘有好几个且并行工作，而存放校验数据的磁盘只有一个，这就带来了校验数据存放时的瓶颈。
RAID5的工作方式是将各个磁盘生成的数据校验切成块，分别存放到组成阵列的各个磁盘中去，这样就缓解了校验数据存放时所产生的瓶颈问题，但是分割数据及控制存放都要付出速度上的代价。
在RAID5上，读/写指针可同时对阵列设备进行操作，提供了更高的数据流量。
RAID5更适合于小数据块和随机读写的数据。
在RAID5中有“写损失”，即每一次写操作将产生四个实际的读/写操作，其中两次读旧的数据及奇偶信息，两次写新的数据及奇偶信息,适用于读多写少的应用。
当其中一个磁盘数据发生损坏后,利用剩下的磁盘和相应的奇偶校验信息重新恢复/生成丢失的数据而不影响数据的可用性。
至少需要3个或以上的硬盘。
适用于大数据量的操作。
成本稍高、储存新强、可靠性强的阵列方式。
5心跳消息（HeartbeatMessage）
心跳消息（HeartbeatMessage）是一种发送源发送到接收方的消息，这种消息可以让接收方确定发送源是否以及何时出现故障或终止。
通常，心跳消息从发送源启动时开始发送，直到发送源关闭，期间发送源会不间断的发送周期性或重复消息。
当接收方在某个消息接收周期内未收到消息，接收方可能会认为发送源已经关闭、出现故障、或者当前不可用。
心跳消息可能常被用于高可用性或容错处理的目的。
6双机热备（hotbackup）
6.1双机热备名词解释
从广义上讲，就是对于重要的服务，使用两台服务器，互相备份，共同执行同一服务。
当一台服务器出现故障时，可以由另一台服务器承担服务任务，从而在不需要人工干预的情况下，自动保证系统能持续提供服务。
双机热备由备用的服务器解决了在主服务器故障时服务不中断的问题。
但在实际应用中，可能会出现多台服务器的情况，即服务器集群。
双机热备一般情况下需要有共享的存储设备。
但某些情况下也可以使用两台独立的服务器。
实现双机热备，需要通过专业的集群软件或双机软件。
从狭义上讲，双机热备特指基于active/standby方式的服务器热备。
服务器数据包括数据库数据同时往两台或多台服务器写，或者使用一个共享的存储设备。
在同一时间内只有一台服务器运行。
当其中运行着的一台服务器出现故障无法启动时，另一台备份服务器会通过软件诊测（一般是通过心跳诊断）将standby机器激活，保证应用在短时间内完全恢复正常使用。
6.2使用双机热备的原因
为了使软硬件系统正常运转，双机热备一般能做到以下功能：
对操作系统的检测、对网络的检测功能、对数据库的检测功能、用户特有程序的热备、第三方软件编程能力,双机热备软件，一旦检测到故障后会自动切换到备用服务器，从而实现不停机服务。
详解如下：
服务器的故障可能由各种原因引起，如设备故障、操作系统故障、软件系统故障等等。
一般地讲，在技术人员在现场的情况下，恢复服务器正常可能需要至少5分钟、几小时甚至几天。
从实际经验上看，除非是简单地重启服务器（可能隐患仍然存在），否则往往需要几个小时以上。
而如果技术人员不在现场，则恢复服务的时间就更长了。
而对于一些重要系统而言，用户是很难忍受这样长时间的服务中断的。
因此，就需要通过双机热备，来避免长时间的服务中断，保证系统长期、可靠的服务。
决定是否使用双机热备，正确的方法是要分析一下系统的重要性以及对服务中断的容忍程度，以此决定是否使用双机热备。
即，你的用户能容忍多长时间恢复服务，如果服务不能恢复会造成多大的影响。
在考虑双机热备时，需要注意，一般意义上的双机热备都会有一个切换过程，这个切换过程可能是一分钟左右。
在切换过程中，服务是有可能短时间中断的。
但是，当切换完成后，服务将正常恢复。
因此，双机热备不是无缝、不中断的，但它能够保证在出现系统故障时，能够很快恢复正常的服务，业务不致受到影响。
而如果没有双机热备，则一旦出现服务器故障，可能会出现几个小时的服务中断，对业务的影响就可能会很严重。
另有一点需要强调，即服务器的故障与交换机、存储设备的故障不同，其概念要高得多。
原因在于服务器是比交换机、存储设备复杂得多的设备，同时也是既包括硬件、也包括操作系统、应用软件系统的复杂系统。
不仅设备故障可能引起服务中断，而且软件方面的问题也可能导致服务器不能正常工作。
还应指出的是，一些其他的防护措施如磁盘阵列（RAID）、数据备份虽然是非常重要的，但却不能代替双机热备的作用。
6.33双机主从、互备、多点集群
主从模式是最标准、最简单的双机热备，即是目前通常所说的active/standby方式。
它使用两台服务器，一台作为主服务器（Active），运行应用系统来提供服务。
另一台作为备机，安装完全一样的应用系统，但处于待机状态（Standby）。
当active服务器出现故障的时候，通过软件诊测（一般是通过心跳诊断）将standby机器激活，保证应用在短时间内完全恢复正常使用。
双机互备，在双机热备的基础上，两个相对独立的应用在两台机器同时运行，但彼此均设为备机，当某一台服务器出现故障时，另一台服务器可以在短时间内将故障服务器的应用接管过来，从而保证了应用的持续性。
这种方式实际上是双机热备的一种应用。
它避免了两个应用使用四台服务器分别实现双机热备。
但双机互备存在着性能瓶颈，即如果进行切换后，在一台服务器上就有同时运行两个应用，有可能负载过大。
并且，有些情况下会有不止两台服务器对外提供服务。
在这种情况上，多点集群就显示出了其必要性。
多点集群可以理解为双机热备在技术上的提升。
多机服务器可以组成一个集群。
根据应用的实际情况，可以灵活地在这些服务器上进行部署，同时可以灵活地设置接管策略。
比如，可以由一台服务器作为其他所有服务器的备机，也可以设置多重的接管关系，等等。
这样，就可以充分地利用服务器的资源，同时保证系统的高可用性。
6.4常见部署
6.4.1双主机共享陈列浮动IP
微软Sqlserver集群（MSCS群集），oralceOFS（OracleFailSafe）,ServHA等，下面以ServH来说原理
ServHA为运行在Windows平台和Linux平台上的双机集群产品，其负责管理2台主机运行各自的应用系统，当主机或主机上的软件出现故障时，不需人工干预，双机集群中另外主机通过心跳线路，可以检测出该故障主机，准确、快速地将原主机的应用系统移交到另一台主机上继续运行，实现整个系统的不间断运行，从而保证整个系统对外服务的正常，为企事业机构24小时×
365天的关键业务应用提供了强大的保障。
ServHA双机系统的两台服务器（主机）都与磁盘阵列（共享存储）系统连接，用户的操作系统、应用软件和ServHA软件分别安装在两台主机上，数据库等共享数据存放在存储系统上，两台主机之间通过私用（或公用）网络建立心跳连接。
配置好的系统主机开始工作后，ServHA服务开始监控系统，通过心跳连接，每台主机上的ServHA服务都可监控另一台主机的状态。
当工作主机发生故障时，心跳信息就会产生变化，这种变化可以通过心跳连接被ServHA服务捕捉。
当捕捉到这种变化后ServHA就会控制系统进行主机切换，即备份机启动和工作主机一样的应用程序接管工作主机的工作（包括提供TCP/IP网络服务、存储系统的存取等服务）并进行报警，提示管理人员对故障主机进行维修。
当维修完毕后，可以根据ServHA的设定自动或手动再切换回来，也可以不切换，此时维修好的主机就作为备份机，双机系统继续工作。
ServHA实现容错功能的关键在于，对客户端来说主机是透明的，当系统发生错误而进行切换时，主机的切换在客户端看来没有变化，所有基于主机的应用都仍然正常运行。
ServHA采用了IP漂移技术来实现此功能。
客户端通过虚拟地址和工作主机通讯，无论系统是否发生切换，虚拟地址始终指向工作主机。
在进行网络服务时，ServHA提供一个逻辑的虚拟地址，任何一个客户端需要请求服务时只需要使用这个虚拟地址。
正常运行时，虚拟地址及网络服务由主服务器提供。
当主服务器出现故障时，ServHA会将虚拟地址转移到另外一台服务器的网卡上，继续提供网络服务。
切换完成后，在客户端看来系统并没有出现故障，网络服务仍然可以使用。
除IP地址外，ServHA还可以提供虚拟的计算机别名供客户端访问。
对于数据库服务，当有主服务器出现故障时，另外一台服务器就会自动接管，同时启动数据库和应用程序，使用户数据库可以正常操作
7负载均衡（LoadBalance）
7.1概念
网络的负载均衡是一种动态均衡技术，常见的实现方式是通过一些工具实时地分析数据包，掌握网络中的数据流量状况，把任务合理均衡地分配出去。
这种技术基于现有网络结构，提供了一种扩展服务器带宽和增加服务器吞吐量的廉价有效的方法，加强了网络数据处理能力，提高了网络的灵活性和可用性。
（对于数据流量过大的网络中，往往单一设备无法承担，需要多台设备进行数据分流，而负载均衡器就是用来将数据分流到多台设备的一个转发器。
）日常生活中到处都能看到“负载均衡”，一个超市的收营员高峰期只能服务10位顾客，当做活动时有20位顾客需要服务的话可能就会排长队，这样购物体验将会很差（就像客户抱怨系统/网站访问太慢）。
最简单的办法就是再招个营业员，重新开通一个出口。
负载均衡的核心就是“分摊压力”。
7.2
负载均衡系统
负载均衡系统：
负载均衡又有DNS负载均衡（比较常用）、IP负载均衡、反向代理负载均衡等，也就是在集群中有服务器A、B、C，它们都是互不影响，互不相干的，任何一台的机器宕了，都不会影响其他机器的运行，当用户来一个请求，有负载均衡器的算法决定由哪台机器来处理，假如你的算法是采用round算法，有用户a、b、c，那么分别由服务器A、B、C来处理
7.3Haproxy介绍
haproxy是一个基于TCP\HTTP反向代理的高可用性负载均衡器，具体以下特点：
支持对cookie、HTTP头的添加/修改/删除；
基于cookie可客户端对同一服务器的持继请求；
有将检测失败的服务器从服务群中排去和检测成功后将服务器再加到服务群中的能力；
可设定服务器的权重；
还具有简单TCP服务器负载能力；
应用实例如图：
某ＷＥＢ服务网站具有172.16.33.244-245两台真实服务器（实际节点可以在2-8台），在haproxy具有双ip,公网ip211.xx.xx.90,内部ip172.16.33.1，对外访问ip为211.xx.xx.90
正常情况由haproxy完成对两台服务器的请求分发，
由于有服务器状态检查，所以在真实服务器只有还有一台服务器工作，客户端也不会感知。
7.4F5交换机
F5BIG-IP用作HTTP负载均衡器的主要功能：
①、F5BIG-IP提供12种灵活的算法将所有流量均衡的分配到各个服务器，而面对用户，只是一台虚拟服务器。
②、F5BIG-IP可以确认应用程序能否对请求返回对应的数据。
假如F5BIG-IP后面的某一台服务器发生服务停止、死机等故障，F5会检查出来并将该服务器标识为宕机，从而不将用户的访问请求传送到该台发生故障的服务器上。
这样，只要其它的服务器正常，用户的访问就不会受到影响。
宕机一旦修复，F5BIG-IP就会自动查证应用已能对客户请求作出正确响应并恢复向该服务器传送。
③、F5BIG-IP具有动态Session的会话保持功能。
④、F5BIG-IP的iRules功能可以做HTTP内容过滤，根据不同的域名、URL，将访问请求传送到不同的服务器。
8什么是高可用HA（HighAvailability）“脑裂"
在涉及到高可用性时，经常会听到”脑裂“，到底啥是”脑裂“？
一句话：
当两（多）个节点同时认为自已是唯一处于活动状态的服务器从而出现争用资源的情况，这种争用资源的场景即是所谓的“脑裂”（split-brain）或”区间集群“（
HeartBeat原理：
HeartBeat运行于备用主机上的Heartbeat可以通过以太网连接检测主服务器的运行状态，一旦其无法检测到主服务器的"
心跳"
则自动接管主服务器的资源。
通常情况下，主、备服务器间的心跳连接是一个独立的物理连接，这个连接可以是串行线缆、一个由"
交叉线"
实现的以太网连接。
Heartbeat甚至可同时通过多个物理连接检测主服务器的工作状态，而其只要能通过其中一个连接收到主服务器处于活动状态的信息，就会认为主服务器处于正常状态。
从实践经验的角度来说，建议为Heartbeat配置多条独立的物理连接，以避免Heartbeat通信线路本身存在单点故障。
在“双机热备”高可用（HA）系统中，当联系2个节点的“心跳线”断开时，本来为一整体、动作协调的HA系统，就分裂成为2个独立的个体。
由于相互失去了联系，都以为是对方出了故障，2个节点上的HA软件像“裂脑人”一样，“本能”地争抢“共享资源”、争起“应用服务”，就会发生严重后果：
或者共享资源被瓜分、2边“服务”都起不来了；
或者2边“服务”都起来了，但同时读写“共享存储”，导致数据损坏（常见如数据库轮询着的联机日志出错）。
运行于备用主机上的Heartbeat可以通过以太网连接检测主服务器的运行状态，一旦其无法检测到主服务器的“心跳”则自动接管主服务器的资源。
通常情况下，主、备服务器间的心跳连接是一个独立的物理连接，这个连接可以是串行线缆、一个由“交叉线”实现的以太网连接。
1、串行电缆：
被认为是比以太网连接安全性稍好些的连接方式，因为hacker无法通过串行连接运行诸如telnet、ssh或rsh类的程序，从而可以降低其通过已劫持的服务器再次侵入备份服务器的几率。
但串行线缆受限于可用长度，因此主、备服务器的距离必须非常短。
2、以太网连接：
使用此方式可以消除串行线缆的在长度方面限制，并且可以通过此连接在主备服务器间同步文件系统，从而减少了从正常通信连接带宽的占用。
基于冗余的角度考虑，应该在主、备服务器使用两个物理连接传输heartbeat的控制信息；
这样可以避免在一个网络或线缆故障时导致两个节点同时认为自已是唯一处于活动状态的服务器从而出现争用资源的情况，这种争用资源的场景即是所谓的“脑裂”（split-brain）或“partitionedcluster”。
在两个节点共享同一个物理设备资源的情况下，脑裂会产生相当可怕的后果。
为了避免出现脑裂，可采用下面的预防措施：
添加冗余的心跳线，例如双线条线。
尽量减少“裂脑”发生机会。
启用磁盘锁。
正在服务一方锁住共享磁盘，“裂脑”发生时，让对方完全“抢不走”共享磁盘资源。
但使用锁磁盘也会有一个不小的问题，如果占用共享盘的一方不主动“解锁”，另一方就永远得不到共享磁盘。
现实中假如服务节点突然死机或崩溃，就不可能执行解锁命令。
后备节点也就接管不了共享资源和应用服务。
于是有人在HA中设计了“智能”锁。
即，正在服务的一方只在发现心跳线全部断开（察觉不到对端）时才启用磁盘锁。
平时就不上锁了。
设置仲裁机制。
例如设置参考IP（如网关IP），当心跳线完全断开时，2个节点都各自ping一下参考IP，不通则表明断点就出在本端，不仅“心跳”、还兼对外“服务”的本端网络链路断了，即使启动（或继续）应用服务也没有用了，那就主动放弃竞争，让能够ping通参考IP的一端去起服务。
更保险一些，ping不通参考IP的一方干脆就自我重启，以彻底释放有可能还占用着的那些共享资源。
9轮询和推送模式
应用系统信息交互过程通常是客户端发出一个请求，服务器端接收和审核完请求后进行处理并返回结果给客户端，然后客户端将信息呈现出来，这种机制对于信息变化不是特别频繁的应用尚能相安无事，但是对于那些实时要求比较高的应用来说，比如说在线游戏、在线证券、设备监控、新闻在线播报、RSS订阅推送等等，当客户端准备呈现这些信息的时候，这些信息在服务器端可能已经过时了。
所以保持客户端和服务器端的信息及时更新是应用的关键要素，开发人员想实现及时更新信息的功能，其中最常用的就是轮询和推送技术，
轮询模式：
由客户端定时向服务器查询，流程为：
如果设定这客户端每2秒轮询一次，那么客户端每2秒就会发送一次请求，相应的服务器端每2秒就要响应这个客户端的一次请求。
而实际上服务器端可能1秒钟后就有更新，也可能1分钟后才有更新。
对于1秒钟就有更新的，客户端至少会有1秒钟的延时；
而1分钟后才有更新的，只有最后一次查询有意义，这一分钟内的轮询其实都是没有必要的，服务器端和客户端均有资源的浪费，本方式取的过程中如果网络故障，客户端重新查询就可以，编程实现简单。
推送模式：
服务器如果有信息，马上主动给客户端发送，流程为：
客户端发送一次请求后马上挂起等待服务器端响应，可能1秒，也可能10秒钟，也可能1分钟。
如果服务器端是1秒就有更新，那么到1秒钟时客户端马上就收到更新了，如果是1分钟才有更新，那么整个一分钟客户端也只请求一次，服务器也只会相应一次，这个跟轮询的区别是不是已经很清楚了，本方法：
如果推的过程中由于网络的原因失败，服务端要进行重发考虑的处理，实现过程中关注的问提多，编程实现复杂
10短连接和长连接的区别
首先介绍下短链接和长连接的区别：
短连接
连接->
传输数据->
关闭连接
比如HTTP是无状态的的短链接，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。
也可以这样说：
短连接是指SOCKET连接后，发送接收完数据后马上断开连接。
因为连接后接收了数据就断开了，所以每次数据接受处理不会有联系。
长连接
保持连接->
传输数据->
...........->
直到一方关闭连接，多是客户端关闭连接。
长连接指建立SOCKET连接后不管是否使用都保持连接，但安全性较差。
什么时候用长连接，短连接？
长连接多用于操作频繁，点对点的通讯，
升级会员 