跨机房数据库解决方案.docx

跨机房数据库解决方案.docx

《跨机房数据库解决方案.docx》由会员分享，可在线阅读，更多相关《跨机房数据库解决方案.docx（5页珍藏版）》请在冰豆网上搜索。

跨机房数据库解决方案跨机房数据库解决方案跨机房数据库解决方案篇一：

大型数据中心机房解决方案大型数据中心机房解决方案大型数据中心的基础设施系统主要分电源、环境控制和机房监控管理系统。

由于大型数据中心承载企业、集团、机构的核心业务，重要性高，不允许业务中断。

因而大型数据中心一般根据TIA942标准的Tier4标准建设，可靠性要求以上，以保证异常故障和正常维护情况下，数据中心正常工作，核心业务不受影响。

1、电源系统，通常选用多路市电源互为备份，并且机房设有专用柴油发电机系统作为备用电源系统，市电电源间、市电电源和柴油发电机间通过ATS（自动切换开关）进行切换，为数据中心内UPS（不间断供电电源）、机房空调、照明等设备供电。

由于大型数据中心业务重要性，通常采用双母线的供电方案供电，满足大型数据中心服务器等IT设备高可靠性用电要求。

双母线供电系统，有两套独立UPS供电系统（包含UPS配电系统），在任一套供电母线（供电系统）需要维护或故障等无法正常供电的情况下，另一套供电母线仍能承担所有负载，保证机房业务供电，确保数据中心业务不受影响。

在UPS输出到服务器等IT设备输入间，选用SPM（服务器电源管理器）进行电源分配和供电管理，实现对每台机柜用电监控管理，提高供电系统的可靠性和易管理性。

对于双路电源的服务器等IT设备，可以通过SPM直接从双母线供电系统的两套母线引人电源，即可保证其用电高可靠性。

对于单路电源的服务器等IT设备，通常选用STS（静态切换开关）为其选择切换一套供电母线供电。

在供电母线无法正常供电时，STS将自动快速切换到另一套供电正常的母线供电，确保服务器等IT设备的可靠用电。

图示双母线供电系统可确保供电可靠性高达以上2、环境控制系统，通常选用机房精密空调对数据中心的环境调节，确保服务器等IT设备的运行环境。

对于发热量大的服务器等IT设备，通常选用高通孔率（一般大于70）网孔门的机柜，提高机柜进出风量；将机柜面对面、背对背布置，在机房内形成冷热隔离的风道，提高制冷效率；空调采用下送风方式，确保机房送风均匀，提高制冷效率。

在某些功率密度特别高场合（发热量超过5kw/机柜），往往容易产生局部热点，形成故障隐患。

为消除局部热点，需要采用相应的高热密度解决方案，如开放式方案即为在局部热点发生处加装制冷终端XD，加强局部制冷能力，以消除局部热点；封闭式方案即为高功率密度设备放置在封闭机柜内，通过机柜内制冷循环，高效率制冷散热。

3、机房监控管理系统，大型数据中心需要对电源、空调等设备运行状态进行管理，同时还需要对机房内环境，如温湿度、漏水、烟感等参量进行监控，确保数据中心工作在一个正常的范围之内。

并对数据中心设备运行参数和环境量实时监控和管理，同时远程监控和管理，实现机房无人值守。

篇二：

双城数据中心双机房建设解决方案双城数据中心双机房建设解决方案目录第1章概述.2数据集中阶段的数据中心建设.2传统架构存在的问题.2H3C全融合虚拟化架构.3双活数据中心建设目标.3第2章（来自:

小龙文档网:

跨机房数据库解决方案）双活数据中心业务部署.4基于IP的业务部署模式.4模式简介.4企业数据中心IP业务典型部署.4基于DNS的业务部署模式.6DNS技术简介.6企业数据中心DNS典型部署.7GSLB与SLB.9第3章某双活数据中心设计.12某网络结构.12某双活数据中心部署.12第1章概述为进一步推进某信息化建设，以信息化推动某业务工作的改革与发展，某在科技楼建有核心机房和一个小的本地容灾备份中心，现在在干保楼又新建了容灾网，实现同城双中心布局。

为提高业务可靠性与双中心设备资源的利用率，某拟建同城双活数据中心，达到双中心同时对外提供同种业务的目标，同时实现业务切换无感知、计算资源灵活调度的功能目标。

数据集中阶段的数据中心建设传统架构存在的问题传统数据中心网络采用传统以太网技术构建，随着各类业务应用对IT需求的深入发展，业务部门对资源的需求正以几何级数增长，传统的IT基础架构方式给管理员和未来业务的扩展带来巨大挑战。

具体而言存在如下问题：

?

维护管理难：

在传统构架的网络中进行业务扩容、迁移或增加新的服务功能越来越困难，每一次变更都将牵涉相互关联的、不同时期按不同初衷建设的多种物理设施，涉及多个不同领域、不同服务方向，工作繁琐、维护困难，而且容易出现漏洞和差错。

比如数据中心新增加一个业务类型，需要调整新的应用访问控制需求，此时管理员不仅要了解新业务的逻辑访问策略，还要精通物理的防火墙实体的部署、连接、安装，要考虑是增加新的防火墙端口、还是需要添置新的防火墙设备，要考虑如何以及何处接入，有没有相应的接口，如何跳线，以及随之而来的VLAN、路由等等，如果网络中还有诸如地址转换、7层交换等等服务与之相关联，那将是非常繁杂的任务。

当这样的IT资源需求在短期内累积，将极易在使得系统维护的质量和稳定性下降，同时反过来减慢新业务的部署，进而阻碍公司业务的推进和发展。

?

资源利用率低：

传统架构方式对底层资源的投入与在上层业务所收到的效果很难得到同比发展，最普遍的现象就是忙的设备不堪重负，闲的设备资源储备过多，二者相互之间又无法借用和共用。

这是由于对底层网络建设是以功能单元为中心进行建设的，并不考虑上层业务对底层资源调用的优化，这使得对网络的投入往往无法取得同样的业务应用效果的改善，反而浪费了较多的资源和维护成本。

?

服务策略不一致：

传统架构最严重的问题是这种以孤立的设备功能为中心的设计思路无法真正从整个系统角度制订统一的服务策略，比如安全策略、高可用性策略、业务优化策略等等，造成跨平台策略的不一致性，从而难以将所投入的产品能力形成合力为上层业务提供强大的服务支撑。

H3C全融合虚拟化架构H3C提供横向虚拟化、1虚多的设备虚拟化以及纵向虚拟化的全融合虚拟化方案。

通过建设网络资源池，不仅简化了网络部署，而且提高了网络设备的利用率，是业界最具优势的数据中心网络解决方案。

双活数据中心建设目标某双活数据中心应实现如下设计目标：

?

简化管理：

同城双中心业务统一部署，统一管理，使上层业务的变更作用于物理设施的复杂度降低，能够最低限度的减少了物理资源的直接调度，使维护管理的难度和成本大大降低。

?

高效复用：

同城双中心网络资源与计算资源高效利用，减少设备主备部署，提高网络设备利用率。

物理服务器部署虚拟机，实现计算资源高度复用，提高计算资源利用率。

?

策略一致：

降低具体设备个体的策略复杂性，最大程度的在设备层面以上建立统一、抽象的服务，每一个被充分抽象的服务都按找上层调用的目标进行统一的规范和策略化，这样整个IT将可以达到理想的服务规则和策略的一致性。

?

无缝切换：

同城双中心同时对外提供同一种业务，当某中心业务失效，要实现应用的无缝切换，在短时间内实现业务的快速恢复。

?

资源调度：

同城双中心二层互联，计算资源可以在双中心之间灵活迁移，快速扩展，统一调度。

第2章双活数据中心业务部署基于IP的业务部署模式模式简介基于IP发布的业务一般用于企业内部管理，业务运营。

客户直接通过访问某个IP地址来实现端到端通信。

由标准的路由协议以及健康路由注入来实现IP地址的自动发布。

企业数据中心IP业务典型部署两个数据中心的SLB跨中心部署HACluster，服务器跨数据中心部署负载均衡集群。

同一个业务的在两个数据中心的业务IP不同，分别为VIP-A与VIP-B。

1、部署时ExternalselfIP和业务IP可以直接使用相同的网段，因为用户访问业务时通过主机路由进行选路，而HACluster中只有为Active的SLB才会发布主机路由。

2、对于同一业务，数据中心A使用VIP-A对外提供服务，数据中心B使用VIP-B对外提供服务，实现业务在两个数据中心之间的负载均衡，当数据中心A发生故障时，Trafficgroup-1将进行HA切换，VIP-A的主机路由将由数据中心B的SLB发布。

如果数据中心A的SLB发生故障，如图所示。

由于两个数据中心的SLB跨中心部署HACluster，服务器跨数据中心部署负载均衡集群，所以数据中心B的SLB在一个心跳周期结束之后，感知到数据中心A的SLB无响应，数据中心A的SLB发生故障，TrafficGroup-1将发生HA切换，此时用户访问VIP-A时将直接到达数据中心B，由SLB处理后发送至数据中心A的服务器。

如果当数据中心A的服务器发生故障，如图所示。

数据中心SLB探测到本中心的服务器都故障，则触发TrafficGroup-1将发生HA切换，此时用户访问VIP-A时将直接到达数据中心B，由数据中心B的服务器进行处理，因为此时数据中心A的服务器已无处理能力。

篇三：

魅族多机房部署方案魅族为什么做多机房部署？

XX年魅族转型，转型之后放弃小而美的发展模式，这个时候用户量达到2500万，这个是比较早的数量，还不包括双11的数量，达到XX万之后，机房扩展出现了一个瓶颈，单机房已经很难满足需求了。

魅族不就是做手机的魅族的应用商店，日亿；在线引用，日亿；用户数据同步，即包括联系人、短信、设置项目在内的用户手机上的数据，全部传到云端，日PV也有亿，数据量可达300亿条记录，规模较大。

单机房的问题1.扩展存在困难之前的机房选址广州亚泰，质量可观，机位紧俏。

相应的，扩容就很困难，绝不是需要就可以马上得到。

我们要提前预约好机柜的数量，但业务量爆发的时候，数量可能会超出预计，因而单机房扩容，极为困难。

2.价格很难谈妥因为只有一个机房，在与机房IDC谈商务条款时屡遭困难，对方云淡风轻“要不你就拆迁呗”，我们无可奈何，并没地方迁，价格因而很难谈下来。

3.无法做到容灾挖掘机挖段光纤的事情屡见不鲜，支付宝也曾不幸中招业务中断。

当然他们基于更为复杂的业务也有相应的多机房容灾机制。

此外也有云服务商的机房遭受闪电攻击，进而电力出现问题。

单机房若遭闪电必停止服务无疑。

实际经营中，各种意想不到的情况都有可能发生。

因此：

魅族在XX年初时即着手准备做多机房部署。

多机房部署面临的挑战1.首先是数据一致性难以保障，这是最大的一个问题，当数据在一个地方有变动，在另外一个地方怎么样体现出来，这很困难。

如果机房和机房之间通过网络传输数据，先不论可怕的网络延时，跨机房专线的昂贵和无保障也足以让人望而却步。

运营商不可能说专线给你做到3个9或者是4个9，一般就不错了，你怎么样做到3个9，4个9，这个问题只有自己解决。

2.3.我们的流量该怎样调度？

用户怎样决定去A机房还是B机房，用什么方式决定？

4.5.业务层面，多机房的架构，必须考虑业务部门的感受，不能天马行空。

我说我哪里那里需要重写，业务部门很难接受。

所以方案必须要让业务部门改动尽可能小。

6.7.最后，因为各个业务之间的依赖关系很复杂，之前也要做若干解偶和业务的切分。

8.魅族的两大跨机房部署方案大大小小五六十个业务，映射到两种类型，第一个是读多写少的业务，另外一个是按用户维度划分的业务，是两种不同的方案。

应用商店想必已经周所周知。

而魅族的应用商店有一个特点，数据是一个榜单，主要是展示它给大家看，不管是竞选、排行、分类，各种都是榜单，数据变化很小、很少，对数据的一致性要求并不高，A和B用户看到的数据可能不一致，并不会影响大局，只要可以下载应用就可以。

跨机房之一，应用商店单机房架构下业务分为三类：

1.API客户端接入使用，客户端就是应用商店的APP要想下载，就在这里拉数据、列表。

2.3.开发者社区，提供给开发者维护应用的数据。

API数据的一个特征主要是读取数据，写很少，只是拉榜单出来。

一部分像评论，下载的话有一个下载的机数，数量较少。

而开发者社区的读和写差不多，量也是差不多。

4.5.运营后台，主要是后台运营成员来维护数据，读和写也类似，数量上差不多。

我们前端划分了许多业务，后端则会有一些服务化的按照业务做了切分，做不同的服务，应用排行、购买服务、运营服务等等，数据如API等，要使用应用排行，需要通过Task到Recis集群读取。

6.应用商店怎样做到多机房