【学习目标】

1.知识目标

了解运营成本的概念。

了解云服务企业运营成本管理的过程、控制方式、风险与优化。

熟悉云资源的规划。

掌握云服务架构高可用性设计。

掌握柔性部署方式设计。

掌握其他云服务运营规划技术。

2.技能目标

能够独立进行服务器/IDC/CDN/公有云/私有云的选型并给出相关实施建议。

能够对大中型企业的硬件设备、机房网络等资源状况，进行资源的调配、带宽迁移及扩容进行决策。

能够对成本进行分摊核算。

能掌握运营管理过程中所涉及业务的风险点，并能够通过一些方法进行有效控制和改进。

【认证考点】

了解云服务运营成本的规划、控制、管理。

熟悉云服务成本核算。

根据成本模型，采用有效的方法对业务产生的成本进行有效控制。

掌握对中小型业务结合硬件设备、机房网络等资源状况，进行资源的使用调配、带宽迁移及扩容决策。

掌握运营管理过程中所涉及业务的风险点，并能够通过一些方法进行有效控制和改进。

项目引导：大型企业云服务运营规划与设计

【项目描述】

重庆XXX科技有限公司现有的云服务，有着深厚的基础架构，并且有着多年对海量互联网服务的经验，不管是社交、游戏还是其他领域，都有多年的成熟产品来提供产品服务。企业在云端完成重要部署，为开发者及企业提供云服务、云数据、云运营等整体一站式服务方案。该方案具体包括云服务器、云存储、云数据库和弹性Web引擎等基础云服务；可以提供给这个行业的差异化优势，造就了可支持各种互联网使用场景的高品质的云计算平台。本章将对公司的云计算服务运营规划与设计进行介绍。

知识储备

6.1云服务运营成本规划

随着云计算的发展，IT企业在市场运营的竞争也越来越激烈，各个企业的生产运营大环境也发生了大变化，做好企业运营的成本控制逐渐成为了企业获取利益的另一个措施途径，同时也是企业在日益激烈的市场竞争中有效利用手段。从目前的市场发展来看，每一种IT产品的市场都有许多家企业在竞争，如果企业降低运营成本，就获得了比同类企业更大的竞争优势，企业就可以利用价格这一优势作为自己的竞争手段，有利于企业占有更多的市场份额。

云服务公司的生产成本与传统的制造业和IT公司有所不同：它主要通过互联网提供产品和服务。它的生产成本主要由机房和电信费用等运营成本来构成。

运营成本可以用下面的公式概括：

运营成本（Operations Cost）=运营设备折旧（CAPEX depreciation）+机房（运营成本）+运营部门人员和部门费用。

这些成本要素是：

（1）设备的资本投入（Capital）：如IDC设施投资、服务器、管理软件、网络和电话设备的投入等。这些资本投入是需要根据财务规则逐月来摊销费用的。

（2）数据中心（机房）的运营费用：运营时的成本，例如电费，网络带宽，机柜租金，电信专线等这些按月发生的费用。

（3）人力资源的成本：机房运营人员的相关费用，包括工资、奖金、福利等其他费用。

下面的表6-1-1中列出了云服务提供商与传统IT产业的成本比较。

从表中可以看出，与传统的IT产业如软件公司相比，云服务公司面临的挑战是:

（1）投资高度密集：需要购买大量的服务器、网络设备等，如果建立自己的数据中心设施，成本会非常高。在硬件和软件采购的第一年的CAPEX（Capital Expenditure）成本非常高的，随之带来现金流的巨大压力。

（2）数据中心(机房)的实时运营成本，如带宽和托管费是一个持续的重复发生的成本。这是一个传统的IT公司不需要，或者只需要维持在较低水平的成本。

（3）相比传统的IT公司，机房基础设施运营团队的成本是一个额外的开支，因为一般IT公司都没有基础设施技术运营团队。技术运营团队涉及到人力资源的成本，这一成本在近年来以全球居于高位的增长速度，持续上涨。

6.1.1 云服务企业运营管理过程

运营管理，就是对运营过程的计划。组织、实施和控制，是与产品生产和服务创造密切相关的各项管理工作的总称。从另一个角度来讲，运营管理也可以指为对生产和提供公司主要的产品和服务的系统进行设计、运行、评价和改造。

在云服务提供商的成本中，技术类的运营成本占的比例非常高。

这主要是两块：

（1）研发成本，主要是研发的人力成本；

（2）技术运营成本，主要是指构建生产线的服务平台和7×24生产线的运营。

其中，技术运营成本（Technical operation cost），特别是IaaS和自建基础设施平台的PaaS和SaaS服务提供商中，占的比例比研发通常要高很多。我们在这里主要讨论技术运营的成本管理。这也是一般的IT公司不会涉及到的。

运营管理是在服务、基础设施、项目等的整个生命周期中进行成本管理的一种方法，运营管理的重点始于项目选择、规划和启动阶段。到成本管理的各个阶段直到服务完成商业生命周期后下线。

这里的活动包括：

（1）工程造价（Cost Engineering）：成本估算、控制、预算、投入产出分析等；

（2）项目管理；

（3）规划和调度；

（4）成本和进度绩效监控。

上面的核心活动融入到一个服务的生命周期的各个流程中，包括在整体服务的开发及运营过程中的关键控制点。主要有四个过程关联和促进着运营管理。它们是公司财务控制、服务产品的设计、容量规划和服务质量管理。如图6-1-2所示。

每个过程都有自己的目标和重点，并且每个过程都有可衡量的和可管理的检查点，以此来决定何时何地何人，来执行上述活动。

公司财务控制（Corp Finance Control）是从整体企业的角度看，根据公司经营战略，盈利能力等来进行的成本管理，公司财务控制的目标是，以确保运营成本是可以达到该公司所定义的投资回报率的目的。

所涉及的活动有：

（1）全面预算管理，部门预算规划；

（2）投资回报率（ROI）分析；

（3）常规审计；

（4）供应商筛选；

（5）生成一个详细的“应该成本”（should cost），以验证供应商的报价，并确保最低价格；

（6）批量分析整个商品目前的价格，以发现超过成本的问题；

（7）库存管理。

云服务生产设计（Service Production Design）主要是从工程设计和开发方面入手来控制成本。通常，在开发新的服务产品时，通常用定期会议的形式，来审查产品需求及设计，以保证其满足商务和运营的要求。然而，很少有设计会议，来专门评估有关的财务影响。一个有效的成本管理应包括强制性的成本评估，作为一个关键来对设计进行审查。

容量规划（Capacity Planning）是技术运营管理的关键流程之一。

（1）不要把生产线建的过大或过小，这两种方式都会带来成本的浪费。

（2）容量的建模或模拟来做预测是必需的，即使是用简单的线性回归来做计算。

（3）实施过程中用分期实施的方式。

（4）对架构和设计的生命周期的要求。例如，基础设施的设计需要至少要满足12个月的时间内的生产线需求，在这期间内不要再进行升级。

服务质量管理（SQM，Service Quality Management）的重要目标之一是提高成本效率。为达到这个目标，SQM需要监控生产环境的各个环节、收集数据、分析数据和提出改善计划。

在日常工作中，管理人员需要定期查看市场上新的技术和服务，并用于自己的服务生产线。如应用虚拟机技术、使用第三方IaaS服务、以消除服务器或是数据中心网络带宽使用的峰/谷效应等。

6.1.2 云服务企业运营成本控制方式

云服务公司的运营成本控制可以从下个几个方面来实现。

（1）云服务公司的产品设计，包括采用价值工程法(Value Engineering）,做最佳性价比分析，确定销售产品的功能。通过确定目标销售价格，分解目标产品成本。这里需要工程设计、软件设计人员及财务分析人员共同参与产品定位、设计、成本等工作。管理者应该对市场现有产品及价格有深入了解，在改善公司产品价格的同时，努力降低成本。

（2）采购过程的控制对于云服务公司是非常重要的管理流程。对于产品的直接成本，如网络带宽、专线、托管费用，有效的成本控制包括两个方面的内容。对这些资源消耗的控制，以及对资源采购成本的控制。

资源消耗的控制可以通过对现有资源的容量管理及订单的管理来实现。采购成本的控制可以通过采购人员对市场的调查，充分了解市场各种资源的性价比之后再做购买决定。同时，采购流程必须符合公司的流程以及及时调整的预算。也可以考虑批量订购，这样有可能可以获得厂家最好的折扣。采购同时会涉及是否采用外包服务等经济决策。

（3）生产成本包括机房技术运营所需要的费用，机房的房租水电费，以及机房技术运营人员的工资和福利。对这些成本的控制主要运用在对机房人员的工作流程以及工作手册的制定上。同时我们还建议管理团队考虑是否采用运营服务外包。在考虑是否外包服务时，可以使用“自制或外购决策”的分析方法，进行成本的比较和分析，做出决策。

（4）期间费用主要是机房工程的折旧，机器及电子设备和办公设备的折旧。对于这些费用的控制，都是属于事前控制需要考虑的范畴。在下面技术运营成本的讨论中，我们还会对此进行讨论。

（5）销售及管理费用，在财务报表中是独立的两笔分类。销售费用(Sales and marketing expenses）是指企业在销售产品时发生的费用，如差旅费、展览费、广告费，还包括了销售机构产生的费用，如销售人员的工资奖金以及被分摊的办公费用等。管理费用(general and administrative expenses）是指企业管理部门如行政、财务、科研、战略等部门的费用，包括了人员工资福利、教育培训、差旅等支出。

这一类的费用是在事先、事中、事后这三个成本控制过程中都需要密切关注的。这类的费用需要及时地随企业的运营情况做调整。譬如，当销售收入没有达到预期时，需要马上考虑是否减少差旅费用，停止或延迟招聘人员，取消或减少会议等，来帮助企业达成利润目标。

6.1.3 云服务企业运营管理优化

要做什么(What to do）即运营的目标是什么，或我们要做的是什么。怎样去做(How to do）即实现的原理及方法，或怎样达到我们的目标。

来自一线运营管理者的经验：

（1）一半技术一半管理

这实际上是生产技术运营的第一原则。从统计的数字来看，生产线问题的一半原因来自于技术和人员的管理问题，另一半原因来源于技术问题。

（2）主动措施，而非被动措施

牢靠的服务是建立在主动模式上的，在生产线发布之前建立稳固的服务平台，而不是上线发现问题后再去改进。

（3）生产线运营：快速恢复服务是第一要务

生产线运营的目标是尽可能快的恢复服务，而不是找出引起问题的根本原因。这个道理听上去很简单，但是在处理事故过程中，绝大部分的工程师们都投入在找问题中，而不是恢复服务中。

（4）不间断的学习和改进

“逆水行舟，不进则退”。需要建立一个学习导向的流程和组织，用以不断地提高服务质量。

（5）KISS原则(Keep It Simple and Straightforward）

简单原则用尽量简单的流程或技术设计，保持简单和易懂。

这体现在下面几个方面：

①流程的简单

在讨论管理流程时，有一个事实是没有人可以避开的。那就是，大家不愿接受流程。这是因为流程越多，执行中投入的精力越多，效率也越低。实际上，质量的提高要有流程来保证的，而流程的执行必然带来效率在某种程度上的降低。因此，一个好的运营管理者要善于在其中找到平衡点。如何建立起简单而有效的流程，例如，信息技术基础架构库（Information Technology Infrastructure Library，ITIL）在业界中已经众所周知。然而，很多IT公司，特别是中小型公司，大多停留在讨论阶段，而不是真正的运用它。这是因为ITIL系统太庞大不利于执行。

②技术的简单

需要同时强调的是技术的简单。从本质上讲，工程师们倾向于使用最好的技术。事实上，我们需要的是合适的技术而不是最好的技术。最好的技术在开发上和运营上都会更加昂贵。要记住，云服务提供给客户的是服务，而不是技术。

（6）人员管理：团队的分立

建立研发、运营和质量管理的相对独立团队会对服务质量的提高提供保障。比如，在产品线发布过程中，各个团队会根据自己的目标定义接受标准(Acceptance Criteria）,从而提高产品的质量验证。这类似于三权分立。

团队的分立的另外一个原因是，这些团队的工程师风格（style）也是不一样的。例如，研发团队需要更多的是创造性人才，而运营团队需要更多的是纪律性人才。高级管理着在构建团队的时候需要考虑这些特性，才能给各团队配备合适的管理与技术人员。

6.1.4 云服务企业运营管理过程风险点及控制方法

在7×24小时的云服务运营中，很多的技术运营经理都会遇到很多运营管理过程的问题。

云服务的运营管理和一般IT公司环境相比有很非常明显的不同，它所面临的挑战有：

（1）服务高可用性需求，通常需要99.9%或者是99.99%级别。

（2）大数量用户共享的生产线环境。

（3）客户形态千变万化，尤其对于B2B商业模式来说，从财富500强客户到中小企业，带来对服务特性的要求的不同。

这样的挑战需要生产线的变更要有严格的控制，包括变更时间、变更频率、变更成功率、客户的影响等。所有的这些要素都应该在运营管理中考虑到。

由于云服务的生产线所涉及的技术、客户数目、服务影响和内部相关部门比较多，因此在运营管理问题的处理上，比一般的IT活动要花更多的精力和时间。

对于一个云计算服务的公司，如果想要生存并且成功，服务的可靠性和业务连续性是必须要保证的。服务和基础设施的变更，从风险角度来看，是一定会对业务造成负面的影响的，带来业务中断可能性。变更管理通过以下几个方面来确保7×24生产线的服务质量，来体现自己对业务的价值：

（1）控制变更、降低无计划的变更或紧急变更，从而减少相关的服务中断，提高服务可用性。

（2）通过更快、更成熟的变更实施步骤来减少恢复服务的平均时间(MTRS）。

（3）对业务所要求的变更能够快速响应，及时安排和实施。

（4）管理、法律、合同和监管需求都需满足安全规范的审计。

同时，通过与发布管理(Release Management）和服务质量改进(Service Quality Management）流程的对接，找出生产线运营平台和流程需要改进的地方，能够达到节省服务运营的成本、优化效率和不断提高服务质量的目标。

项目实施

项目以“重庆XXX科技有限公司”的网络架构为背景，进行云资源的规划、应用、高可用架构设计、以及柔性部署。

需要完成的任务：

• 能够进行云资源的规划。
• 能够进行应用、高可用架构设计。
• 能够进行柔性部署方式设计。
• 能够其他云运营规划技术。

6.2 任务1：云资源的规划

云计算已经被公认为是信息产业发展的制高点。云计算技术将大大提高社会计算资源、存储资源的利用效率，促进资源、信息的高度共享。建设、应用好云数据中心，将进一步推动我国信息产业健康持续发展，提高互联网、电子商务、电子政务等行业的国际竞争力。

企业如何进行云资源的规划与设计呢？下面章节将具体进行介绍。

6.2.1云计算的类型及应用场景

云计算作为一种计算方式，它允许通过互联网以“服务”的形式向外部用户交付灵活、可扩展的IT功能。简言之，云计算是企业为了达到降低基础架构成本、提高效益、解决容量/可扩展性问题等目的，而采用的一种新型应用架构。如图6-2-1所示。

目前云计算的类型主要是三种：

1.私有云

即企业内部基础架构、桌面、应用程序和数据的统称，由企业防火墙后面的IT人员按需交付。私有云的优势很多，灵活交付服务、提供自服务、可精细化地跟踪使用情况，同时允许企业对自己的基础架构有很强的控制力，具有更高的安全性。

2.公有云

即场外多租户基础架构、存储和计算资源以及SaaS应用和数据的统称，通常由外部服务提供商按需提供。

3.混合云

多指“云融合”，私有云与公共云紧密集成在一起时就形成了混合云，使IT有更多的灵活性，可以选择将应用放在哪里运行，在成本和安全性之间进行平衡。

云计算的应用场景：

1.App部署

通过使用云平台部署App应用，可以根据目前用户数量动态调整需要的硬件以及网络带宽等资源，随时调整随时生效非常方便，而且使用成本非常廉价。

2.企业商务网站及办公

通过使用云计算平台，企业网站可以根据目前最新的客户需求，通过云计算平台提供的开发模块进行网站的动态扩张，商业模式推出之后，商务网站会迅速完成软件部署。

3.行业应用

云计算的分布式存储特点与目前的很多行业应用非常契合，比如连锁销售、金融、交通、医疗等等。这些行业应用具备物理分散逻辑集中的分布式特点，通过云计算平台能完成独立运行、安全运行和整合运行的灵活应用。

6.2.2云计算资源的选型

计算资源承载私有云中所有业务系统的需求，计算资源选型需满足以下两点：

（1）根据先进可用的原则，进要保证整个计算平台的平稳运行，要不能过多得追求高性能，要求做到合理选型、合理分配。

（2）尽量的利旧，利用现有可用资源可以根据后续需要合理设计到整个计算平台中，防止浪费。

服务器是云计算平台的核心之一，其承担着云计算平台的“计算”功能。在服务器选型方面要符合以下几方面的要求：可靠性、可用性、可扩展性、易用性、可管理性。

1.服务器的硬件配置

CPU性能——多核高主频技术使得CPU成为性能瓶颈的可能性越来越低。

内存大小——作为硬指标的内存，配置越高，所能支持的虚机数量越多。

网络端口——千兆网环境已很普遍，网络带宽大多有保证，更多从管理角度来考虑。

HBA卡——磁盘访问性能对虚机数量有一定影响，建议采用10G以太网或者8Gbps FC以减少链路影响。

本地磁盘——内置磁盘的可用性及IO吞吐能力均较弱，不建议在其上存放虚拟机，推荐使用外置高性能磁盘阵列。

2.应用负载大小

由于物理服务器资源自身的最大限制，应用负载越大，所能同时运行的虚机数量越少。将不同应用访问特性的应用混合部署在同一物理服务器上。灵活运用DRS和VMotion技术可将物理机与虚机的比率关系调到最优。考虑到HA及DRS所要求的资源冗余，所有运行虚机在正常负载下，总体资源使用率不超过三分之二会比较合适，在部署虚拟化时，对物理服务器的硬件配置需要考虑以下因素：

（1）可用的CPU目标数量尽可能多，单台服务器建议配置6个以上的CPU核。

（2）超线程技术并不能提供等同于多核处理器的好处；建议关闭CPU的超线程功能。

（3）使用具有EM64T能力的IntelVT或AMDV技术的CPU可以同时支持运行32位和64位的虚拟机。

（4）采用同一厂商、同一产品家族和同一代处理器的服务器组成的集群，可以获得最好的虚拟机迁移兼容能力。

（5）内存资源往往比CPU资源更会成为潜在的瓶颈，尽可能采用最大容量的内存条（单条16GB效果优于两条8GB）。

如表6-2-1所示给出了部署虚拟化时的服务器典型配置。

6.2.3 云网络资源的选型

网络资源同计算资源以及存储资源一样，是一种可被租户共享使用并提高利用率的资源。但是，不同租户的计算资源以及存储资源之间，有很强的隔离性，可以实现按需按比例分配的使用方式，但是网络资源却不可以。

主要原因是，一台虚拟机使用的网络资源，会受到在同一台物理服务器其他虚拟机的影响（竞争唯一的网卡资源），以及其他会同此虚拟机进行通信的虚拟机影响（竞争此虚拟机的可用带宽），此外其他虚拟机之间的通信也会竞争此虚拟机通信时可使用的链路资源。

在传统的数据中心，每个网口对应唯一一个物理机。有了云，一台物理网卡可能会承载多个虚拟网卡。

1.二层网络资源

二层网络，对应于一个二层广播域，进行二层相关的隔离。一般用物理网络的设备名称标识。VLAN、VXLAN、或者SDN等能提供二层隔离技术都可作为二层网络。

二层网络负责为三层网络提供二层隔离。如图6-2-2所示。

二层网络主要支持以下三种类型：

（1）L2NoVlanNetwork

NoVlanNetwork类型表示相关的物理机对应的网络设备不设置VLAN，如果交换机端口设置了VLAN，则需在交换机端配置Access模式，如果交换机端口没有设置VLAN，则无须特别设置。

（2）L2VlanNetwork

VlanNetwork类型表示相关的物理机对应的网络设备需设置VLAN，从逻辑上划分虚拟局域网，支持1～4094个子网，此类型需在物理机接入的交换机端进行Trunk设置。

（3）VxlanNetwork

VxlanNetwork类型表示使用VXLAN的子网进行网络配置，需要先建立VXLANPool，再建立VxlanNetwork。

2.三层网络资源

三层网络，云主机使用的网络配置，包含了IP地址范围、网关、DNS、网络服务等。

（1）公有网络

可直接连通互联网的网络，在云路由网络、VPC中可以提供网络服务。可用于扁平网络创建和使用公网的云主机；可用于云路由网络环境，单独创建使用公网的云主机；可用于VPC网络环境，单独创建使用公网的云主机。

（2）系统网络

管理节点用于特定用途的网络。可用于部署配置相关资源的管理网络，例如部署物理机、主存储、镜像服务器、云路由等资源；可用于云主机迁移的迁移网络；

如果网络资源不足，可与公有网络共用；独立的系统网络用于特定用途，例如管理云路由器的网络；系统网络不能用于创建普通云主机。

（3）私有网络

可称之为业务网络或接入网络，云主机使用的网络，一般情况下设置为私网。私有网络指定为云主机使用的网络，支持三种网络架构模型扁平网络、云路由网络、VPC。作为系统网络的一种，用于管理控制对应的物理资源。

例如物理机、镜像服务器、主存储等需提供IP进行访问的资源时使用的网络；创建云路由器/VPC路由器时需要云路由器/VPC路由器存在管理节点互通的IP，以便部署Agent及Agent代理消息返回。

（4）存储心跳网络

特指在进行分布式存储部署时，底层存储系统通信使用的网络。在添加主存储时，可标识存储网络的无类别域间路由（CIDR），表示使用此网络来判断云主机健康状态。

3.路由资源云路由网络

主要使用定制的Linux云主机作为路由设备，提供DHCP、DNS、SNAT、弹性IP、端口转发、负载均衡、IPsec隧道、安全组等网络服务。如图6-2-3所示。

（1）公有网络

用于提供弹性IP、端口转发、负载均衡、IPSec隧道等网络服务需要提供虚拟IP的网络，公有网络一般要求可直接接入互联网。

（2）管理网络

用于管理控制对应的物理资源，例如物理机、镜像服务器、主存储等需提供IP进行访问的资源时使用的网络。

（3）私有网络

也称之为业务网络或接入网络，是云主机使用的内部网络。

云网络的设计与实施要根据项目实际情况进行，既要满足生成环境需求，又要便于管理。

6.2.4 云存储资源的选型

目前主流的存储架构包括DAS、NAS、SAN，如图6-2-4所示。下面针对3种主流应用系统做架构分析。

直连方式存储（Direct Attached Storage，DAS）。如图6-2-4a所示。顾名思义，在这种方式中，存储设备是通过电缆（通常是SCSI接口电缆）直接到服务器。I/O请求直接发送到存储设备。

网络连接存储（Network Attached Storage，NAS）。如图6-2-4b所示。NAS设备通常是集成了处理器和磁盘/磁盘柜，连接到TCP/IP网络上（可以通过LAN或WAN），通过文件存取协议（例如NFS，CIFS等）存取数据。NAS将文件存取请求转换为内部I/O请求。

存储区域网络（Storage Area Network，SAN）。如图6-2-4c所示。存储设备组成单独的网络，大多利用光纤连接，服务器和存储设备间可以任意连接。I/O请求也是直接发送到存储设备。如果SAN是基于TCP/IP的网络，则通过iSCSI技术，实现IP-SAN网络。

上述几种存储方式的优劣势分析如表6-2-2所示。

通过以上对比可以看出SAN具有如下优势：

• 关键任务数据库应用，其中可预计的响应时间、可用性和可扩展性是基本要素；
• SAN具有出色的可扩展性；
• SAN克服了传统上与SCSI相连的线缆限制，极大地拓展了服务器和存储之间的距离，从而增加了更多连接的可能性；
• 改进的扩展性还简化了服务器的部署和升级，保护了原有硬件设备的投资。集中的存储备份，其中性能、数据一致性和可靠性可以确保关键数据的安全；
• 高可用性和故障切换环境可以确保更低的成本、更高的应用水平；
• 可扩展的存储虚拟化，可使存储与直接主机连接相分离，并确保动态存储分区；
• 改进的灾难容错特性，在主机服务器及其连接设备之间提供光纤通道高性能和扩展的距离。

考虑到IP-SAN的扩展性比FC-SAN更加出色。我们可以在IP-SAN中使用SCSI、FC、SATA、SAS等多种磁盘阵列来扩展IP-SAN的容量，我们推荐使用IP-SAN存储架构。

6.2.5 云数据库资源的选型

如今包括企业级产品在内的互联网产品越来越丰富，传统的数据库产品只有联机事务处理（On-Line Transaction Processing，OLTP）和联机分析处理（Online Analytical Processing，OLAP）等简单处理功能，目前的数据库产品已经非常丰富了，比如MySQL、SQL Server、PG、HBASE、Redis以及MongoDB等数据库产品，而且如果单机无法存储全部数据还会提供数据库分片技术。

现在无论是对于中小企业还是大中型企业，云计算带来的运营管理和业务效率的提升都是显著的。随着业务云化的深入，数据库云化也尤为重要。因为，企业的研发、设计、生产、销售等一系列业务流程，离不开对数据进行存储和管理的仓库，云同样是最合适的。因此数据库云化是必然趋势。

数据库云化有着诸多明显优势，具体来说：

（1）更高的灵活性和可扩展性。利用云计算池化资源的天然优势，云数据库可以提供更好的弹性，利于企业进行存储和计算资源的独立扩缩容，按需开通、快速部署，使资源得到最大化利用。

（2）更高的性价比。相比自建数据库，需付出昂贵的软硬件成本，云数据库只需要按照自己实际使用的资源付费，产品开发与运营的硬件成本显著降低。

（3）更高效，即开即用。几分钟内便可获得一个高性能、高可靠的数据库实例，从而实现从繁琐的硬件采购、服务部署与维护中解放出来。

1.MySQL数据库

MySQL是一种关系型数据库管理系统，关系数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。

MySQL所使用的SQL语言是用于访问数据库的最常用标准化语言。MySQL软件采用了双授权政策，分为社区版和商业版，由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，一般中小型网站的开发都选择MySQL作为网站数据库。

2.Redis数据库

Redis（Remote Dictionary Server），即远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

Redis是一个Key-Value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string（字符串）、list（链表）、set（集合）、zset（sorted set --有序集合）和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，Redis支持各种不同方式的排序。与Memcached一样，为了保证效率，数据都是缓存在内存中。区别的是Redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了Master-Slave（主从）同步。

Redis是一个高性能的Key-Value数据库。Redis的出现，很大程度补偿了Memcached这类Key-Value存储的不足，在部分场合可以对关系数据库起到很好的补充作用。它提供了Java、C/C++、C#、PHP、JavaScript、Perl、Object-C、Python、Ruby、Erlang等客户端，使用很方便。

Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。

3.MongoDB数据库

MongoDB是一个基于分布式文件存储的数据库。由C++语言编写。旨在为WEB应用提供可扩展的高性能数据存储解决方案。

MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。它支持的数据结构非常松散，是类似Json的Bson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是它支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。

它的特点是高性能、易部署、易使用，存储数据非常方便。主要功能特性有面向集合存储、易存储对象类型的数据、模式自由、支持动态查询、支持完全索引、还包含内部对象、支持查询、支持复制和故障恢复、使用高效的二进制数据存储、大型对象（如视频等）、自动处理碎片，以支持云计算层次的扩展性。

4.HBase数据库

Hadoop Database是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。

HBase数据库主要利用Hadoop HDFS作为其文件存储系统，利用Hadoop MapReduce来处理HBase中的海量数据，利用Zookeeper作为其分布式协同服务，来存储非结构化和半结构化的松散数据。

云数据库的种类很多，在选型时先思考需求，判断需求是否真实。你可以从数据量、QPS、延时等方面考虑需求。在架构选择上，基础版是单点部署，价格低，性价比很高，提供监控服务，可以保证数据可靠性；高可用版则在可用性上做了很大提升，出现故障可以实时切换，误操作可以冷备热备结合的方式恢复数据。数据库版本的选择首要考虑的因素是兼容性。数据复制方式，结合业务场景需求，要求数据强一致的业务，强同步复制是不二之选。

6.3任务2：云服务系统架构设计

云计算应用和企业私有云建设不是简单的虚拟化和传统意义上的主机托管。为了着力提升企业信息资源的重用性、敏捷性和快速服务响应水平。一般来讲，对云服务系统考察的是系统总体的可用性，即系统不间断持续提供服务的能力，而对终端系统，一般采用可靠性来评估系统稳定提供功能、不出现错误的能力。如前所述，对于云服务系统，系统可用性要求比传统软件要高，业界要求的最高水平达到99.99%的可用度。除此之外，时时刻刻监控系统的正常运转更是重中之重。

6.3.1云服务系统架构分层

从云服务构架层次上来划分，IaaS是基础，然后是PaaS和SaaS。整体结构如图6-3-1所示。

在IaaS层，服务于用户的是基础设施，如计算机，包括CPU、内存、磁盘空间、网络连接等基础设备，此外还有操作系统等基础软件，其计费往往以CPU内存、存储空间和网络流量等使用收费。用户使用的一般都是虚拟机，因此IaaS服务是虚拟化技术发展的产物，如果希望构架IaaS服务，首先是对虚拟化技术了解。

PaaS服务是在基础层之上提供中间件，让用户能够快速开发部署SaaS应用，这些应用开发是对原始PaaS应用扩展，使其能够快速开张业务，比如网络培训平台，当培训公司在其上部署自己应用，针对自己专业、客户提供服务，但一般的培训公司，更专注自己专业和流程，并不是实时通讯的专家，而培训平台能够提供这些功能，使得培训公司从自己不熟悉领域解放出来，更关注自己专业能力，更好更快提供服务给自己客户。这是PaaS平台特点。

IaaS和PaaS有些界限并不是很明显，如亚马逊是一家IaaS服务公司，但也提供统一数据库服务，用户可以租用数据库，不用关心数据同步、备份等一系列问题，这些是PaaS功能，但被集成到IaaS服务中。

SaaS服务是面向客户的应用，是基于PaaS开发，并可使用IaaS部署的服务，因此构建云服务时，要同时了解IaaS、PaaS和SaaS特点，有针对性设计构架。

6.3.2 架构高可用性术语介绍

高可用性HA（High Availability）指的是通过尽量缩短因日常维护操作（计划）和突发的系统崩溃（非计划）所导致的停机时间，以提高系统和应用的可用性。它与被认为是不间断操作的容错技术有所不同。HA系统是企业防止核心计算机系统因故障停机的最有效手段。

集群（Cluster）技术是一种较新的技术，通过集群技术，可以在付出较低成本的情况下获得在性能、可靠性、灵活性方面的相对较高的收益，其任务调度则是集群系统中的核心技术。集群是一组相互独立的、通过高速网络互联的计算机，它们构成了一个组，并以单一系统的模式加以管理。一个客户与集群相互作用时，集群像是一个独立的服务器。集群配置是用于提高可用性和可缩放性。

负载均衡（Load Balance），其含义就是指将负载（工作任务）进行平衡、分摊到多个操作单元上进行运行，例如FTP服务器、Web服务器、企业核心应用服务器和其它主要任务服务器等，从而协同完成工作任务。负载均衡构建在原有网络结构之上，它提供了一种透明且廉价有效的方法扩展服务器和网络设备的带宽、加强网络数据处理能力、增加吞吐量、提高网络的可用性和灵活性。

双机热备（Hot-Standby）是一种软硬件结合的服务容错方案，通常由两台服务器系统和一个外接共享磁盘队列柜及相应的软件组成。“故障隔离"是双机热备的工作原理，通过主动转移故障点来保障业务的连续性，双机热备本身不具有修复故障的功能，只是将服务转移到备用服务器上。“故障检测”是双机热备的一项任务，采用“心跳”方法来保证主系统和备用系统的联系。

容灾系统DR（Disaster recovery）是指在相隔较远的异地，建立两套或多套功能相同的系统，互相之间可以进行健康状态监视和功能切换，当一处系统因意外（如火灾、地震等）停止工作时，整个应用系统可以切换到另一处，使得该系统可以继续正常工作。

6.3.3 架构高可用性应用场景

1.高可用Web应用

场景描述：将业务不同的服务采用不同可用组部署，隔离服务层故障影响。高可用组将保证Web服务对应的云主机实例分散在物理资源上，数据库服务对应的云主机也分散在不同物理资源上。当某一台Web服务云主机所在物理资源出现故障时，其他Web服务实例以及数据库服务实例不受影响，保证业务高可用。如图6-3-2所示。

2.弹性高性能计算应用

场景描述：计算请求通过负载均衡到达应用服务器，当计算量波动时，支持基于监控指标配置告警伸缩策略，自动触发新增或删除云主机，保障集群计算能力，节省业务部署成本。若可预估计算量波动情况，您可预先规划可用组内云主机数量并配置定时伸缩策略，定时触发新增或删除云主机。如图6-3-3所示。

3.高可用数据库应用

场景描述：一台机器A作为读写库，另一台B作为备份库；A库故障后B库作为读写库；A库恢复后A作为备库。数据源配置中的数据库IP地址，可采用虚拟的IP地址。虚拟IP地址由两台数据库机器上的Keepalive配置，并互相检测心跳。当其中一台故障后，虚拟IP地址会自动漂移到另外一台正常的库上。如图6-3-4所示。

数据库的主备配置、故障排除和数据补全，需要DBA和运维人员来维护。而程序代码或配置并不需要修改。

6.3.4 架构高可用性具体设计

根据不同的应用，高可用的具体设计要求和级别是不一样的。下面从简单到复杂，从低要求到高要求进行设计。

1.FT(Fault Tolerance)双机热备

通过创建与主实例保持虚拟同步的虚拟机，使应用在服务器发生故障的情况下也能够持续可用。如图6-3-5所示。

这种方法常通过使主虚拟机和辅助虚拟机执行相同顺序的x86指令来完成此过程。主虚拟机捕获所有输入和事件，并在辅助虚拟机上进行重放。

辅助虚拟机执行与主虚拟机相同的指令序列，如果运行主虚拟机的主机或运行辅助虚拟机的主机发生故障，则会发生即时且透明的故障切换。

虽然FT功能很强大，但是在虚拟化中很少用到FT功能，一是对资源浪费比较严重，二是性能下降比较快，由于是指令级别的同步，因而两台虚拟机之间的距离非常近，无法完全达到容灾的目的，三是如果主虚拟机因为执行非法指令蓝屏，则辅助虚拟机也马上就会发生，根本无法保证业务延续性。

2.虚拟机HA

虚拟机HA主要指在有一个共享存储池的情况下，当一台物理机挂了，这台物理机上的虚拟机可以迁移到其他物理机的机制。

因为虚拟机是有状态的，因而需要共享存储池来保证状态可以被另外一台物理机读取到。如图6-3-6所示。

在HA状态下，虚拟机的恢复时间一般在秒级别，也即当监控探测到物理机挂了之后，可以迅速在空闲的物理机上将虚拟机启动起来。

启动HA的物理机集群可以比较大，可以跨机架，比FT更能起到容灾的目标。

3.同城双活

如果一个机架，或者整个机房，甚至整个数据中心着火了，则如何保证业务的连续性呢？

一种常用的机制是同城双活，就是在同一个城市，距离大概30km到100km的两个数据中心之间，通过高速专线互联的方式，让两个数据中心形成一个大二层网络。如图6-3-7所示。

同城双活最重要的是数据如何从一个数据中心同步到另一个数据中心，并且在一个数据中心故障的时候，可以实现存储设备的切换，保证状态能够快速切换到另一个数据中心。主流的存储厂商都提供在高速光纤互联情况下，在一定距离之内的两台存储设备的近实时的同步，数据双活是一切双活的基础。

基于双数据中心的数据同步，对上看起来可以形成一个统一的存储池，从而数据库层在共享存储池的情况下可以近实时的切换，例如Oracle RAC。

虚拟机在统一的存储池的情况下，也可以实现跨机房的HA，在一个机房切换到另一个机房。

SLB负载均衡实现同一机房的各个虚拟机之间的负载均衡。

GSLB可以实现跨机房的负载均衡，实现外部访问的切换。

如果在两个数据中心距离很近，并且大二层可通的情况下，也可以使用VRRP协议，通过VIP方式进行外部访问的切换。

同城双活一般宣称是实时切换，但是真正实施起来，一般在几分钟到十几分钟，对于数据量比较大的，还会几十分钟。

4.异地容灾

当你觉得一个地方两个数据中心还是不保险，例如海啸、地震、原子弹等，则可以在异地修建容灾数据中心。如图6-3-8所示。

第一大问题还是数据的问题，也即生产数据中心的数据如何备份到容灾数据中心，由于异地距离比较远，不可能像双活一样采取近同步的方式，只能通过异步的方式进行同步，可以预见的是容灾切换的时候，数据会丢失一部分。

由于容灾数据中心平时是不用的，不会将所有的业务都进行容灾，否则成本太高。

对于数据的问题比较建议从业务层面进行容灾，由于数据同步会比较慢，可以根据业务需求高优先级同步重要的数据，因而容灾的层次越高越好。

6.3.5 监控策略

监控系统是服务运营体系的重要组成部分（就像航空运营中的雷达系统一样）。如果没有监控，生产环境的状态将不能被有效展现，甚至失去控制。完善的监控服务能够快速地发现故障、定位故障点、诊断故障原因、帮助制定解决方案，从而缩短服务停止时间和提高客户满意度。

有效性（effectiveness）和高效性（efficiency）是监控体系的两大挑战。具体地说：

有效性（effectiveness）是所有的生产线上问题都应该被报出。

高效性（efficiency）是不应该出现问题误报。

1.云服务监控体系的架构

当客户通过互联网或移动网使用云服务的时候，他们所关心的就是云服务作为整体的功能和性能体验。但是，对云服务提供商而言，监控系统是有两个部分组成的，内部环境监控（如IDC和自建的网络骨干网），外部环境监控（如互联网，用户所在LAN的环境等）。整体结构，如图6-3-9所示。

云服务提供商的服务系统的监控(Service Plattform Monitoring），主要是监控云服务商自己拥有的设施，包括在自己数据中心和网络上的设施。这种监控分为两个层次：

基础层监控(infrastructure level monitoring），包括网络、系统、数据库、应用服务等。

业务活动层监控(business activities monitoring），这里是业务逻辑层的监控，如业务流量等。

客户的性能监控(Customers Performance Monitoring），主要是监控运营商自有的设施之外的环境监控，比如互联网。对云服务商的挑战是，当用户通过自己公司内网，跨过互联网或移动网来使用服务时，一旦出了问题，他们是希望云服务商来解决的，而不管这些是不是云服务商的设施。这就像是航空服务，如果因为天气不好，乘客被耽误飞机。但是乘客会把天气耽误飞机的原因归咎于航空公司一样。因此，航空公司要严密监控天气，做好防范和应急措施。这就是云服务运营商要做的同样的事情。用户体验监控包括互联网性能监控(internet performance monitoring）、用户体验监控(user experience monitoring）。

2.基础设施的监控

在计算机诞生的时候就一直伴随着宕机、硬件故障、软件故障等等问题，虽然计算机的硬件和软件制造商不断地改进优化，但是从理论上来讲，无故障(BUG-free）的硬件和软件是不可能实现的。

（1）基础设施监控目标

为了让故障发生时，服务商能第一时间知道，并且处理问题，将损失降低到最小，需要对计算机的系统、网络设备、数据库、存储等进行监控，这些就是基础设施的监控。如表6-3-1所示。

监控部分内容如下：

①系统是否出现磁盘满、网络中断、CPU或内存出现高负载，指定进程是否在运行、端口是否绑定、HA服务是否正常。

②网络设备是否出现网络中断、线路负载过高、CPU或内存出现高负载。

③数据库不仅需要对其进行系统级的监控，还需要对数据库服务进行监控，进程是否存在，是否可以提供正常的查询/写入服务、数据同步是否正常。

m存储也需要对其进行系统级的监控，另外还需要监控器是否可以提供网络服务、磁盘空间，高可用性（HA）是否正常工作。

（2）基础设施的监控方法

目前对于基础监控的方法基本上有两种，一种是基于SNMP协议开发的监控件，另一种是通过C/S (client/server）的方式开发的监控软件。

SNMP协议出现时间早，且覆盖面广，硬件厂商基本都对其支持，基于SNMP开发的监控软件有，Cacti、Zabbix、Zenoss、Ganglia等等，能大部分满足上面提出的基础监控的需求。对于网络设备，这些监控软件都自带模板，可以满足上面提出的对网络设备监控的需求。但是对于一些特殊的监控，像数据库的查询写入和数据是否同步，这些需要单独开发模板。模板提供远程访问MySQL的功能，能将MySQL的各种状态获取，然后Cacti分析这些数据，根据预定义的设置进行报警，这些不是依赖SNMP实现的。这些模板大部分监控软件都已经提供，但是像对存储的HA监控，以及系统上的进程是否存在，端口是否被绑定，这些需要单独开发监控脚本，部署到被监控的主机上，然后绑定一个OID号，配置到snmpd.conf中，在服务端通过指定的OID号即可对其监控。

C/S方式也有很多支持厂商。各大商业监控厂商都有自己的一套C/S软件，像HP的OpenView，开源的也有很出名的Nagios。对于上面的监控需求都能满足，而且Nagios灵活的架构，对脚本支持广泛。

3.虚拟化监控

虚拟化能大大节约硬件资源的投入，提高硬件的资源使用效率，可以更合理、更简单的调整和分配资源，使IT管理成本也得到很大地降低。对这些虚拟化的宿主机监控也是基础监控的一部分，每台组主机都工作数台甚至数十台虚拟机，一旦出现故障，影响将十分巨大，因此对宿主机的监控也是监控工作的重点。

目前使用的较多的虛拟化技术有VMware、Xen、KVM、Hyper-V。以VMware为例，VMware提供了一套监控接口，通过VMware监控SDK，即可获取宿主机运行的各种状态数据，VMware对外发布了check esx3.pl脚本，此脚本是专门针对Nagios开发的，能很好地与Nagios结合，此脚本能监控到Nagios的宿主机运行的状态，也能监控虚拟机的运行状态，比如监控宿主机的CPU和内存信息。

3.业务活动监控

业务活动监控BAM(Business Activity Monitoring）的核心是应用程序层(Application Level Monitoring）的监控。具体分三个步骤执行，首先以有效及时的方式收集足够量的相关数据来提供有意义结果；然后处理数据来识别分类特定关系相关的因素；最后分析数据并以清晰、简洁的方式展示结果，让工作人员能采取适当措施。

5.互联网的性能监控

互联网监测主要有以下几个指标：

（1）网络丢包率监控

网络丢包率是指测试中所丢失数据包数量占所发送数据包的比率，通常在吞吐量范围内测试。丢包率主要与网络的流量及硬件设备有关，准确地说是与从用户计算机到产品运营服务器之间每段路由的网络拥塞程度及之间的路由交换设备好坏有关。由于交换机和路由器的处理能力有限，当网络流量过高来不及处理时就将一部分数据包丢弃造成丟包，另外如果之间的设备损坏也会造成丢包。由于TCP/IP网络能够自动实现重发，这样发生丢包后不断重发，将造成更大量的丢包。

（2）网络延时及抖动监控

网络延时指一个数据包从用户的计算机发送到产品运营服务器，然后再立即从服务器返回用户计算机的来回时间。通常使用网络管理工具PING(Packet Internet GroupProtocol）来测量网络延时。由于互联网络的复杂性、网络流量的动态变化和网络路由的动态选择，网络延时随时都在不停地变化，不停的变化称为网络延时抖动。网络延时和网络延时的抖动越小，那么网络的质量就越好。

6.用户体验的监控

在云服务的环境下，服务商需要提供给用户一个最优的用户体验，不管用户处于何种网络，以及何种地理位置，都能得到最好的服务，因此传统的监控已经不能满足需求，需要监控到每个用户使用云服务的情况，也就是用户体验的监控（User experience monitoring）这包括：

（1）监控用户端（Client end）到服务端（Server end）的网络质量状况，当客户到某个云服务点出现网络问题，根据当时情况，可以调整客户到他最优的另外一个云服务点。

（2）监控用户端(Client end）的使用体验，如用户的LAN的状况、Client软件的运行情况、客户使用模式等。监控体系可以根据收集到数据做用户行为分析，为以后产品的更新和重构提供基础。

监控要点，根据云服务产品的特点，针对性设计出网络质量和业务特性的监控，这包括定义好那些关键的、需要被监控的点和指标；确定这些指标的阀值；开发相应的应用接口。

6.4任务3：柔性部署方式设计

在项目迭代的过程中，不可避免需要进行项目上线。上线对应着部署或者重新部署，部署对应着修改，修改则意味着风险。

目前有很多用于部署的技术，有的简单，有的复杂，有的得停机，有的不需要停机即可完成部署。

在一般情况下，升级服务器端应用，需要将应用源码或程序包上传到服务器，然后停止掉老版本服务，再启动新版本。但是这种简单的发布方式存在两个问题，一方面，在新版本升级过程中，服务是暂时中断的，另一方面，如果新版本有Bug，升级失败，回滚起来也非常麻烦，容易造成更长时间的服务不可用。

为了解决这些问题，研究出了多种发布策略，下面我们一一介绍。

6.4.1 蓝绿部署

所谓蓝绿部署，是指同时运行两个版本的应用，如图6-4-1所示，蓝绿部署的时候，并不停止掉老版本，而是直接部署一套新版本，等新版本运行起来后，再将流量切换到新版本上。但是蓝绿部署要求在升级过程中，同时运行两套程序，对硬件的要求就是日常所需的二倍，比如日常运行时，需要10台服务器支撑业务，那么使用蓝绿部署，你就需要购置二十台服务器。

特点：蓝绿部署无需停机，并且风险较小。但蓝绿部署对框架隔离有较高要求，如Docker容器、Dubbo框架等，不建议将新老版本部署在一个容器中。服务器及数据库资源要求1比1复制，对资源消耗较大。

优势：升级切换和回退速度非常快。

不足：切换需要全量切换，如果新版本有问题，则对用户体验有直接影响，但可快速还原到旧版本，需要两倍机器资源，对数据库同步要求高。

6.4.2灰度/金丝雀发布

灰度发布也叫金丝雀发布，起源是矿井工人发现，金丝雀对瓦斯气体很敏感，矿工会在下井之前，先放一只金丝雀到井中，如果金丝雀不叫了，就代表瓦斯浓度高。

在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来，而是测试人员对新版本进行线上测试，启动的这个新版本应用，就是我们的金丝雀。如果没有问题，那么可以将少量的用户流量导入到新版本上，然后再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比，就是所谓的A/B测试。如图6-4-2所示。

当确认新版本运行良好后，再逐步将更多的流量导入到新版本上，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。

如果在灰度发布过程中（灰度期）发现了新版本有问题，就应该立即将流量切回老版本上，这样，就会将负面影响控制在最小范围内。

优势：用户体验影响小，灰度发布过程出现问题只影响少量用户。

不足：发布自动化程度不够，发布期间可引发服务中断。

6.4.3 滚动发布

滚动发布是在金丝雀发布基础上的进一步优化改进，一种自动化程度较高的发布方式，用户体验比较平滑，是目前成熟型技术组织所采用的主流发布方式。

就是在升级过程中，并不一下子启动所有新版本，是先启动一台新版本，再停止一台老版本，然后再启动一台新版本，再停止一台老版本，直到升级完成。如图6-4-3所示。

这样的话，如果日常需要10台服务器，那么升级过程中也就只需要11台就行了。

但是滚动升级有一个问题，在开始滚动升级后，流量会直接流向已经启动起来的新版本，但是这个时候，新版本是不一定可用的，比如需要进一步的测试才能确认。那么在滚动升级期间，整个系统就处于非常不稳定的状态，如果发现了问题，也比较难以确定是新版本还是老版本造成的问题。

特点：这种部署方式相对于蓝绿部署，更加节约资源——它不需要运行两个集群、两倍的实例数。我们可以部分部署，例如每次只取出集群的20%进行升级。

优势：用户体验影响小，体验较平滑。

不足：发布和回退时间比较缓慢。

6.5 任务4：其他云服务运营规划技术

大多数的云计算的使用者，无论是企业或者是个人用户，都无法容忍服务中断或数据丢失。其对服务可用性的要求达到99.9%至99.99%的服务可用度要求。这是来自前端用户的最直接的挑战。对后端的要求是技术方案的实施与管理及其成本效益。那么就需要业务连续性（Business Continuity）。

业务连续性是一个服务提供商为了确保其客户能够随时访问到其业务功能而进行的一系列的运营活动。这些活动包括许多日常运营任务，如系统备份、数据备份、系统变更控制、系统实时监控等。业务连续性不是在灾难发生时才去实施的系统，业务连续性是指为维护服务的高可用性、一致性和可恢复性而执行的日常业务活动。

接下来我们介绍如何把业务迁移上云，并保持业务连续性。

6.5.1 迁移上云规划

系统迁移上云是一个整体系统工程。迁移必须保证用户系统建设的相关要求，

在迁移方案设计中，我们重点考虑几个问题。

（1）保障业务中断停机时间最小化

业务中断对于用户无论是运行环境还是测试环境均存在较大的恢复风险，这样的风险特别对于时间敏感型数据和数据完整性业务都是不可以接受的。我们基于这样的要求，考虑到如何将停机时间最小，能否实现0停机的建设目标。

（2）业务切割时间节点优化

针对现有系统需要对外提供服务的应用，需要通过对用户历史应用进行分析，选择最优的切割时间节点，以及切割期间的备份链路、人工受理手段。

（3）迁移后完整性测试

迁移涉及到应用、实例、数据库的操作以外，还涉及到迁移前规划、迁移后测试的完整性测试。这些测试包括但不限于数据一致性测试、数据完整性测试、应用会话状态完整性测试、连接中断测试、数据恢复测试。只有这样才能保证迁移的安全性和有效性。

1.服务器硬件环境迁移方案

对原有服务器硬件环境和操作系统环境虚拟的支持程度，可以降低迁移的难度。

迁移评估迁移前，需要工程师勘察现有系统的架构和资源使用状况。

（1）迁移评估

评估过程必须包含以下信息和内容：

现有系统支撑的服务数量以及在服务器中的分布情况；

现有物理服务器资源占用状况，包括CPU、内存、磁盘和网络连接状况，为

保证迁移成功，目标虚拟机规格应不低于原物理机标准；

当前的物理环境是否支持虚拟化，是否支持资源扩展，因为在迁移之前须在物理服务器上完成虚拟化；

对当前的存储容量和资源利用率进行评估，需在目标系统中规划好迁移需要的存储空间。需明确现有存储如何利用，比如有些服务器是在本地磁盘上创建系统盘和用户盘，有些服务器则在本地磁盘上创建系统盘而在SAN/NAS上创建用户盘。

（2）迁移计划

通过对现有网络环境的评估，对现有资源利用率、服务以及系统需求非常清晰地进行评估后才能开始对迁移进行计划，步骤如下：

确定迁移步骤，包括所有服务器的迁移先后顺序，其顺序按风险的高低降序排列。

确定备份方案，由于现有系统会被加固，某些服务器通过虚拟化重复利用，而在虚拟化前需要清除所有的数据，因此需要对这些服务器进行备份保证服。

确定并准备好迁移所需的工具，包括工具在迁移中必备的一系列功能和使用工具所需具备的网络环境。

在实际迁移开始之前确定额外的测试环境，该测试环境能够引导测试从而确保迁移成功。因此，测试环境需明确设计的服务器和存储数量。

规划网络环境，由于网络中的服务器各处不同位置，因此在迁移中需考虑到网络连接情况、数据备份方式，以及网络流量来源，确定网络流量是否会引发网络拥塞。

确定迁移周期以及参与人员，包括迁移起止时间，团队能力建设以及团队成员的角色。

（3）测试计划

迁移计划后，执行小批量的测试迁移方案，这里会涉及到首批迁移的测试和审核，步骤如下：

准备用于测试迁移的测试系统环境，在测试时，第一批服务器将会迁移到该系统环境中。

安装并核实迁移工具，此时要执行第一批服务器的迁移。对第一批服务器，需分析存储系统，不管该服务器在存储迁移中采用本地磁盘存储还是远端SAN/NAS存储系统。

（4）迁移实施

在迁移实施过程中，所有的服务器都会被迁移到虚拟化系统下。执行步骤如下：

确保批量迁移的整个网络环境已准备完毕，并通过迁移工具完成源系统和目标系统之间的连通。此处的目标系统属于中转系统。

对迁移系统进行性能审核和健康检查，如果系统状态监视则停用旧系统并将其服务暂时转移到新的虚拟化系统中。

进行利旧，对于一部分可用的旧硬件可在服务器虚拟化中重新再利用，一些软件资源需扩展，如内存和硬盘。这些服务器构成最终的虚拟化基础设施，即最终系统。

最后，在目标系统和最终系统之间进行迁移。

2.应用系统和数据库迁移方案

（1）应用服务器迁移

针对应用系统迁移，要基于多种应用环境、多种应用程序框架。对应用环境以及应用程序框架提出构建NLB（Network Load Balancing）群集，将当前系统不停机加入到NLB群集中，使之成为群集中的一个节点，而新环境则为另外一个节点。实施完成后再退出此迁移群集，将新环境加入到新的构建的NLB群集。

NLB不但能实现负载均衡，而且还能实现多种形式的冗余。NLB主要用于那些文件改动不大，并且不常驻内存的环境，比如WEB服务、FTP服务和VPN服务等。

当用户访问集群的时候，集群能将访问请求分摊到集群中的每个服务器上，以达到均衡负载的效果。这些服务器被称为集群节点。在负载平衡中，每个节点的文件一般都要求是一样的。这样每个节点返回给客户的结果都是一致的。一般来说组建一个NLB要求至少两个节点，其中一个节点不能使用，则全部负载将落入到剩下的那个节点上，即全载。NLB能提供三种冗余功能，软件冗余、硬件冗余、站点冗余。

（2）数据库迁移实施

如果数据库搬迁环境的情况是数据库文件比较大，而且要求传送文件的速度快。

具体解决方案如下：

为了使宕机时间最短，使用完整备份和差异备份来迁移数据库，对需要迁移的数据库进行一次完整备份，并把备份文件拷贝到目标服务器进行还原，之后再进行一次差异备份，再把这个差异备份拷贝到目标服务器，在完整还原的基础上再进行差异还原。

保证数据迁移过程中的安全性和操作可审计性，数据迁移中的安全性不可忽略，需要设计基于多重数据审计功能实现迁移安全性和操作审计性。

6.5.2 异地多活规划

异地多活一般是指在不同城市建立独立的数据中心，“活”是相对于冷备份而言的，冷备份是备份全量数据，平时不支撑业务需求，只有在主机房出现故障的时候才会切换到备用机房，而多活是指这些机房在日常的业务中也需要走流量，做业务支撑。冷备份的主要问题是成本高，不跑业务，当主机房出问题的时候，也不一定能成功把业务接管过来。

1.架构模式

（1）同城异区

部署在同一个城市不同区的机房，用专用网络连接。同城异区两个机房距离一般就是几十千米，网络传输速度几乎和同一个机房相同，降低了系统复杂度、成本。

这个模式无法解决极端的灾难情况，例如某个城市的地震、水灾，此方式是用来解决一些常规故障的，例如机房的火灾、停电、空调故障。

（2）跨城异地

部署在不同城市的多个机房，距离要远一些，例如北京和广州。此模式就是用来处理极端灾难情况的，例如城市的地震、相邻城市的大停电。

跨城异地主要问题就是网络传输延迟，例如北京到广州，正常情况下的RTT（Round-Trip Time往返时延）是50毫秒，当遇到网络波动等情况，会升到500毫秒甚至1秒，而且会有丢包问题。

（3）跨国异地

部署在不同国家的多个机房。此模式的延时就更长了，正常情况也得几秒，无法满足正常的业务访问。

所以，跨国异地多活适用于：

为不同地区用户提供服务，例如亚马逊美国是为美国用户服务的，亚马逊中国的账号是无法登录美国亚马逊的。

只读类业务，例如谷歌的搜索，不管用户在哪个国家搜索，得到的结果基本相同，对用户来说，跨国异地的几秒延迟，对搜索结果没什么影响。

从架构层面来看，当前传统数据库业界主要以Oracle的RAC与IBM的GDPS为多活架构代表。

2.分布式数据库异地多活架构

异地容灾：异地的容灾和备份，保证数据安全，中心间距离超过1000km以上。满足“两地三中心”的需求。

同城双活：同城双中心的数据准实时同步，保证数据一致；双中心数据可以实现同时读写，大大提升读写效率；中心切换RTO小于10分钟。

数据压缩机制：节约带宽资源，加快同步和备份过程。

该架构是基于三副本方案构建的同城灾备，其中两副本部署在本机生产环境中，一副本部署在灾备环境中，整个集群跨越生产环境与灾备环境两个机房。如图6-5-1所示，为了保证灾备环境与生产环境的数据保持实时一致，开启数据库中数据同步强一致性的功能。

开启数据同步强一致性后，每次进行数据更新时，只有当存活的节点全部同步完成后，应用端才回收到更新成功的返回，这样就能在最大程度上保证了数据不丢失。

在同城灾备的基础上，在异地机房单独部署一套集群作为异地灾备集群。如图6-5-2所示，异地集群只保持单副本，两地间结构化数据的同步通过传输同城灾备集群日志到异地灾备集群，然后通过重放日志记录的方式实现结构化数据的同步。

3.灾难应对

（1）单节点故障应对

由于采用了三副本高可用架构，个别节点故障情况下，数据组依然可以正常工作。针对个别节点的故障场景，无需采取特别的应对措施，只需要及时修复故障节点，并通过自动数据同步或者人工数据同步的方式去恢复故障节点数据即可。如图6-5-3所示。

（2）本地生产环境整体故障应对

当生产环境机房出现整体故障时，整个集群环境将会失去三分之二的节点，如果从每个数据组来看，相当于每个数据组有两个数据节点出现了故障，存活的节点只剩余一个。当这种情况发生时，如果不采取任何措施，灾备环境中存活的节点，只能为业务提供查询功能。

当这种场景发生时，为了让使灾备环境中的一个副本继续提供读写服务，这时需要使用SequoiaDB的集群Takeover功能，把灾备环境中的集群分裂成单节点集群，这时灾备环境节点均可提供读写服务。分裂集群的耗时相对比较短，一般在十分钟内便能完成。如图6-5-4所示。

其中分裂集群之后，不可再启动生产集群的两个副本，需要使用SequoiaDB的合并集群功能后才能进行启动，否则将出现脑裂，即生产集群也开始提供数据更新服务。将造成生产集群和灾备集群两个数据版本，很难将两者合并。

（3）灾备环境整体故障应对

当灾备环境出现整体故障时，由于每个数据组都有两个副本部署在生产环境中，每个数据组存活节点的数量还大于每个数据组的总节点数，所以每个数据组仍然能够为应用层提供读写服务。针对灾备环境整体故障的场景，无需采取特别的应对措施，只需要及时修复故障节点，并通过自动数据同步或者人工数据同步的方式去恢复故障节点数据即可。如图6-5-5所示。

（4）网络故障应对

当同城网络出现故障，导致本地环境与灾备环境无法进行通信时，由于采用了三副本的架构，应用程序可以通过访问本地两副本集群。针对同城网络的故障场景，无需采取特别的应对措施，只需要及时修复网络故障，修复后通过自动数据同步或者人工数据同步的方式去恢复灾备节点的数据即可。如图6-5-6所示。

该用户的影像平台采用了同城双活架构，每个数据组都有两个节点落在主机房中，另外一个节点落在灾备机房中。在数据同步方面，使用了SequoiaDB提供的节点强一致性的功能，当数据写入主节点时，数据库会确保节点间的数据都同步完成后才返回，这样即使在主机房发生整体灾难时也能有效得保证数据的完整性与安全性。由于当主机房整体出现故障时，可以使用SequoiaDB数据库提供的分裂功能在数分钟内快速地把灾备机房中的单一副本分裂成独立的集群为业务提供服务，因此恢复时间目标（Recovery Time Objective，RTO）几乎接近零。由于SequoiaDB开启了节点数据强一致性的功能，因此RPO也几乎接近零。

分布式数据库作为数据管理的最核心枢纽，也将不断提高数据安全、数据可用性方面的功能。通过双活、多活以及高可用灾备等机制不断创新，数据库安全将会提升一个新的台阶。

6.5.3 容灾备份规划

灾备系统(DR，Disaster Recovery）是一种基于不同地理位置的服务高可用性解决方案。它通过在不同的地理位置建立相同的云计算服务实例，实例之间进行数据实时复制，以此来实现当城市断电，主干光纤网络中断，以及地震等自然灾害造成的大规模的区域云数据中心失效时，将云计算服务自动转移到另一个地理位置的云数据中心，从而保证服务可以继续的一种策略。

相对于本地高可用性的策略（比如双机备份、群组），服务的灾备系统是更高级别的高可用性方案，同时也是IDC级别的备份系统（相对而言，双机备份、群组等只是机器级别的或组件级别的备份）。

灾备系统架构：

云服务灾备系统是一个庞大而复杂的系统，它包括以下几个子系统网络系统、应用系统、数据同步系统，包含存储数据(Storage）及数据库数据(Database）的同步。云服务灾备系统的基本框架如图6-5-7所示。

当一个地点的服务完全中断，其他地点的客户被透明地转移到另一个地点。

（1）网络系统

网络层是整个云计算系统中的最高层，终端用户通过网络访问服务，所以首先要求主系统和备份系统所在的不同的数据中心之间要有必要的网络互联。

终端用户要能够自由地通过广域网来访问任何一个数据中心，这样才能保证无论服务是在哪个数据中心都可以被客户访问。数据中心之间要有专线连接，这样才能保证跨数据中心之间的带宽和稳定性，这个主要用于跨数据中心间的数据复制和应用程序的跨地域访问（这在Web2.0的应用中很普遍），还有用于控制服务转移的网络设备也需要稳定的跨数据中心的数据交换，如Load Balancer的GSLB（Global Server Load Balance，全球服务器负载均衡）、DNS server间的同步等等。服务备份系统服务转移过程如图6-5-8所示。

一般客户端都是通过域名(DNS Name）来访问服务，假设服务的域名是boo.com，在域名服务器上会有两条记录，分别对应着主服务和备份服务的虚拟IP。如果主服务是健康的，当客户端访问boo.com时，域名服务器会返回主服务的虚拟IP给客户端，客户的请求就被定向到主服务；如果主服务有问题，主服务的虚拟IP就会自动关闭，当域名服务器感知后，就会返回备份服务的虚拟IP给客户端，这样客户的请求就被自动转移到备份服务，从而实现服务转移。

（2）云应用系统

应用层是云计算的业务逻辑层。当终端用户通过网络访问服务时，网络层最终把请求转发给了相应的应用服务器（物理的或虚拟的），一般现代的企业级的云计算系统都用一群功能相同的服务器（集群）来实现一个服务。关于集群的结构，如图6-5-9所示。

集群的好处有：

动态扩展容量。第一次部署可能只有2台服务器，后面如果发觉访问量增加了，可以加一台或多台服务器到已经存在的集群。

一定的容错能力。当一个集群中有多台服务器时，如果其中的部分服务器发生故障，负载平衡器会自动地把这些服务器从集群中屏蔽掉，从而保证用户的请求永远只会被转发给健康的服务器。

那么负载平衡器是根据什么来判断和某一个VIP相关联的服务器的健康状况呢?这依赖于每一个服务器本身提供的健康检测方法(Health Check Method）。当某一个服务器被加入到负载平衡器的某一个特定的VIP，负载平衡器就会每隔一定的时间去访问这个服务器提供的一个特殊的方法，比如TCP call、HTTP call、ping等等。

当服务器接收到来自负载平衡器的特殊的调用时，就进行自我检查，如果发现自己的服务正常，就返回一个固定的结果给负载平衡器（比如“OK”），负载均衡器就知道这个服务器仍然是健康的；相反，如果服务器在做自我检查时，发现已经不能提供正常的服务了(比如应用服务器不能连接数据库），就会返回一个固定的结果给负载平衡器（比如“NOT _OK"），负载均衡器就知道这个服务器已经有故障了，就会把它从这个VIP中剔除。当某个VIP中所有的服务器都有故障，这个VIP自己的状态就会变成不可用。

（3）数据同步系统

数据同步系统包括数据库和文件系统。在服务备份系统中，永久存储层存储着用户的数据，当服务转移发生时，用户仍然需要能够访问他们的数据，这就要求永久存储层要有一个健壮、高效的跨网的数据复制通道。这通常是整个系统中最具挑战性的部分。通常关系数据库已经比较成熟，比如针对Oracle的Stream和GoldenGate数据库复制工具，以及Quest Software 的Shareplex，都是比较成熟的实时双向复制工具。数据库复制工具的工作机制如图6-5-10所示。

文件系统的实时双向复制机制类似于数据库复制工作机制。

另外由于复制是实时双向的，所以必然会存在两边同时修改同一个文件或数据库的记录，当复制到对方时，必然会产生数据冲突。这时要根据应用程序和客户的需要，进行取舍（无论如何最终只能保留一个结果）。这就要求在数据复制工具中，要能够根据客户和应用程序的需要，灵活地定制数据冲突解决方案，并且要求数据复制工具能够感知数据冲突的发生，并且能够选择调用合适的冲突解决方案来修正数据。

通常除了实时双向的数据复制之外，还要开发高效的批量数据同步工具，这个主要用于手工维护。当某种异常情况发生后，积攒了大量的数据需要复制，并且需要有选择的复制，这个时候利用同步工具手工同步就更加灵活和高效。

本章小结

本章主要介绍了云服务企业的运营管理和技术管理，系统阐述了云计算的实现和运营，涉及各个方面。从运营商务和技术出发，系统地介绍了云计算所涉及到的构建、管理和运营各个方面。对商务运营、技术运营、技术架构做了系统和全面的描述。通过本章的学习，深刻地认识IT企业从刚开始的硬件时代（Mainframe，PC）,到软件（Enterprise and personal software）时代，到现在的服务(services)。云计算将IT真正带入到了服务的时代。

本章习题

一、单项选择题

1.云系统利用一种计量功能，通常是按使用付费，或者计件，来自动调控和优化资源利用，根据不同的服务类型，按照合适的度量指标进行计量，监督控制和报告资源的使用情况，对服务提供商和用户来说都是( ）的。

A.未知的

B.透明的

C.不确定的

D.不透明的

2.在云计算系统中，提供“云+端”服务模式是( ）公司的云计算服务平台。

A. IBM

B. GOOGLE

C. Amazon

D.微软

3.下列说法错误的是( ）。

A.云计算平台可以灵活的提供各种功能。

B.云计算平台需要管理人员手动扩展。

C.云计算平台能够根据需求快速调整资源。

D.用户可以在任何时间获取任意数量的功能。 .

4.某云计算服务商向电信运营商提供计算能力、存储空间及相应的运营管理服务。按照云计算服务提供的资源层次，该服务类型属于( ）。

A.IaaS

B.CaaS

C.PaaS

D.SaaS

5.项目成本管理包括的主要过程有( ）。

A.成本估算

B.成本预算

C.成本控制

D.以上都是

6.以下描述错误的是哪一项?( ）

A.自建机房需要自己关注所有事情，成本高昂。

B.传统IDC分为实体服务器托管和租用两种类型，IDC数据中心提供IP接入、带宽接入、电力供应和网络维护等。

C.云计算是一种新的提供资源按需租用的服务模式。

D.以上均不对(正确答案)

7.下面哪个阶段不是项目管理流程中的阶段?( ）

A.项目立项

B.项目开发

C.项目测试

D.项目质保

8.以下哪一个是收尾过程的正确顺序。( ）

A.得到正式验收、解散团队、写出经验教训、结束合同

B.写出经验教训、解散团队、得到正式验收、结束合同

C.得到正式验收、写出经验教训、解散团队、结束合同

D.得到正式验收、结束合同、写出经验教训、解散团队

二、多项选择题

1.“云”服务影响包括( ）。

A.理财服务

B.健康服务

C.交通导航服务

D.个人服务

2.对高可用系统关心的内容有( ）。

A.可用的网络构架

B.关键链路提供设备级、链路级冗余备份

C.减少非计划性的宕机

D.可用可靠的网络管理

3.云计算软件技术的关键技术包括( ）。

A.海量数据处理技术 B.大规模消息通信技术

C.大规模分布式存储技术 D.大规模重构技术

4.下列属于保障系统高可用的技术有( ）。

A.降级技术

B.隔离技术

C.分流技术

D.熔断技术

三、判断题

1.云计算的消费者需要管理或控制云计算的基础设施，例如网络,操作系统、存储等。( ）

2.分布式文件系统基本上都有冗余备份机制和容错机制来保证数据读写的正确性。( ）

3.异步消息通信机制，可以使得 云计算每个层次中的内部组件之间及各个层次之间解耦合。( ）

参考文献

1 陈赤榕. 云计算服务运营管理与技术架构M，北京：清华大学出版社，2017.