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

1、跨机房数据库解决方案跨机房数据库解决方案 跨机房数据库解决方案 篇一：大型数据中心机房解决方案 大型数据中心机房解决方案 大型数据中心的基础设施系统主要分电源、环境控制和机房监控管理系统。由于大型数据中心承载企业、集团、机构的核心业务，重要性高，不允许业务中断。因而大型数据中心一般根据 TIA942标准的 Tier4 标准建设，可靠性要求以上，以保证异常故障和正常维护情况下，数据中心正常工作，核心业务不受影响。1、电源系统，通常选用多路市电源互为备份，并且机房设有专用柴油发电机系统作为备用电源系统，市电电源间、市电电源和柴油发电机间通过 ATS（自动切换开关）进行切换，为数据中心内 UPS（不

2、间断供电电源）、机房空调、照明等设备供电。由于大型数据中心业务重要性，通常采用双母线的供电方案供电，满足大型数据中心服务器等 IT设备高可靠性用电要求。双母线供电系统，有两套独立 UPS 供电系统（包含 UPS 配电系统），在任一套供电母线（供电系统）需要维护或故障等无法正常供电的情况下，另一套供电母线仍能承担所有负载，保证机房业务供电，确保数据中心业务不受影响。在 UPS 输出到服务器等 IT 设备输入间，选用 SPM（服务器电源管理器）进行电源分配和供电管理，实现对每台机柜用电监控管理，提高供电系统的可靠性和易管理性。对于双路电源的服务器等 IT设备，可以通过 SPM 直接从双母线供电系统

3、的两套母线引人电源，即可保证其用电高可靠性。对于单路电源的服务器等 IT 设备，通常选用 STS（静态切换开关）为其选择切换一套供电母线供电。在供电母线无法正常供电时，STS 将自动快速 切换到另一套供电正常的母线供电，确保服务器等 IT设备的可靠用电。图示双母线供电系统可确保供电可靠性高达以上 2、环境控制系统，通常选用机房精密空调对数据中心的环境调节，确保服务器等IT设备的运行环境。对于发热量大的服务器等 IT设备，通常选用高通孔率（一般大于70）网孔门的机柜，提高机柜进出风量；将机柜面对面、背对背布置，在机房内形成冷热隔离的风道，提高制冷效率；空调采用下送风方式，确保机房送风均匀，提高制

4、冷效率。在某些功率密度特别高场合（发热量超过 5kw/机柜），往往容易产生局部热点，形成故障隐患。为消除局部热点，需要采用相应的高热密度解决方案，如开放式方案即为在局部热点发生处加装制冷终端 XD，加强局部制冷能力，以消除局部热点；封闭式方案即为高功率密度设备放置在封闭机柜内，通过机柜内制冷循环，高效率制冷散热。3、机房监控管理系统，大型数据中心需要对电源、空调等设备运行状态进行管理，同时还需要对机房内环境，如温湿度、漏水、烟感等参量进行监控，确保数据中心工作在一个正常的范围之内。并对数据中心设备运行参数和环境量实时监控和管理，同时远程监控和管理，实现机房无人值守。篇二：双城数据中心双机房建设

5、解决方案 双城数据中心双机房建设解决方案 目 录 第 1章 概述.2 数据集中阶段的数据中心建设.2 传统架构存在的问题.2 H3C 全融合虚拟化架构.3 双活数据中心建设目标.3 第 2章(来自:小龙 文档 网:跨机房数据库解决方案)双活数据中心业务部署.4 基于 IP 的业务部署模式.4 模式简介.4 企业数据中心 IP 业务典型部署.4 基于 DNS 的业务部署模式.6 DNS 技术简介.6 企业数据中心 DNS 典型部署.7 GSLB与 SLB.9 第 3章 某双活数据中心设计.12 某网络结构.12 某双活数据中心部署.12 第 1章 概述 为进一步推进某信息化建设，以信息化推动某业

6、务工作的改革与发展，某在科技楼建有核心机房和一个小的本地容灾备份中心，现在在干保楼又新建了容灾网，实现同城双中心布局。为提高业务可靠性与双中心设备资源的利用率，某拟建同城双活数据中心，达到双中心同时对外提供同种业务的目标，同时实现业务切换无感知、计算资源灵活调度的功能目标。数据集中阶段的数据中心建设 传统架构存在的问题 传统数据中心网络采用传统以太网技术构建，随着各类业务应用对 IT需求的深入发展，业务部门对资源的需求正以几何级数增长，传统的 IT基础架构方式给管理员和未来业务的扩展带来巨大挑战。具体而言存在如下问题：?维护管理难：在传统构架的网络中进行业务扩容、迁移或增加新的服务功能越 来越

7、困难，每一次变更都将牵涉相互关联的、不同时期按不同初衷建设的多种 物理设施，涉及多个不同领域、不同服务方向，工作繁琐、维护困难，而且容 易出现漏洞和差错。比如数据中心新增加一个业务类型，需要调整新的应用访 问控制需求，此时管理员不仅要了解新业务的逻辑访问策略，还要精通物理的 防火墙实体的部署、连接、安装，要考虑是增加新的防火墙端口、还是需要添 置新的防火墙设备，要考虑如何以及何处接入，有没有相应的接口，如何跳线，以及随之而来的 VLAN、路由等等，如果网络中还有诸如地址转换、7层交换等 等服务与之相关联，那将是非常繁杂的任务。当这样的 IT 资源需求在短期内 累积，将极易在使得系统维护的质量和

8、稳定性下降，同时反过来减慢新业务的 部署，进而阻碍公司业务的推进和发展。?资源利用率低：传统架构方式对底层资源的投入与在上层业务所收到的效果很 难得到同比发展，最普遍的现象就是忙的设备不堪重负，闲的设备资源储备过 多，二者相互之间又无法借用和共用。这是由于对底层网络建设是以功能单元 为中心进行建设的，并不考虑上层业务对底层资源调用的优化，这使得对网络 的投入往往无法取得同样的业务应用效果的改善，反而浪费了较多的资源和维 护成本。?服务策略不一致：传统架构最严重的问题是这种以孤立的设备功能为中心的设 计思路无法真正从整个系统角度制订统一的服务策略，比如安全策略、高可用 性策略、业务优化策略等等，

9、造成跨平台策略的不一致性，从而难以将所投入 的产品能力形成合力为上层业务提供强大的服务支撑。H3C 全融合虚拟化架构 H3C 提供横向虚拟化、1虚多的设备虚拟化以及纵向虚拟化的全融合虚拟化方案。通过建设网络资源池，不仅简化了网络部署，而且提高了网络设备的利用率，是业界最具优势的数据中心网络解决方案。双活数据中心建设目标 某双活数据中心应实现如下设计目标：?简化管理：同城双中心业务统一部署，统一管理，使上层业务的变更作用于物 理设施的复杂度降低，能够最低限度的减少了物理资源的直接调度，使维护管 理的难度和成本大大降低。?高效复用：同城双中心网络资源与计算资源高效利用，减少设备主备部署，提 高网络

10、设备利用率。物理服务器部署虚拟机，实现计算资源高度复用，提高计 算资源利用率。?策略一致：降低具体设备个体的策略复杂性，最大程度的在设备层面以上建立 统一、抽象的服务，每一个被充分抽象的服务都按找上层调用的目标进行统一 的规范和策略化，这样整个 IT将可以达到理想的服务规则和策略的一致性。?无缝切换：同城双中心同时对外提供同一种业务，当某中心业务失效，要实现 应用的无缝切换，在短时间内实现业务的快速恢复。?资源调度：同城双中心二层互联，计算资源可以在双中心之间灵活迁移，快 速扩展，统一调度。第 2章 双活数据中心业务部署 基于 IP 的业务部署模式 模式简介 基于 IP 发布的业务一般用于企业

11、内部管理，业务运营。客户直接通过访问某个 IP地址来实现端到端通信。由标准的路由协议以及健康路由注入来实现 IP 地址的自动发布。企业数据中心 IP 业务典型部署 两个数据中心的 SLB 跨中心部署 HA Cluster，服务器跨数据中心部署负载均衡集群。同一个业务的在两个数据中心的业务 IP 不同，分别为 VIP-A 与 VIP-B。1、部署时 External self IP 和业务 IP 可以直接使用相同的网段，因为用户访问业务时通过主机路由进行选路，而 HA Cluster中只有为 Active的 SLB才会发布主机路由。2、对于同一业务，数据中心 A使用 VIP-A对外提供服务，数据

12、中心 B使用 VIP-B对外提供服务，实现业务在两个数据中心之间的负载均衡，当数据中心 A发生故障时，Traffic group-1将进行 HA切换，VIP-A 的主机路由将由数据中心 B的 SLB发布。如果数据中心 A的 SLB发生故障，如图所示。由于两个数据中心的 SLB跨中心部署 HA Cluster，服务器跨数据中心部署负载均衡集群，所以数据中心 B的 SLB在一个心跳周期结束之后，感知到数据中心 A的 SLB无响应，数据中心 A的 SLB发生故障，Traffic Group-1将发生 HA 切换，此时用户访问 VIP-A时将直接到达数据中心 B，由 SLB处理后发送至数据中心 A的服

13、务器。如果当数据中心 A 的服务器发生故障，如图所示。数据中心 SLB探测到本中心的服务器都故障，则触发 Traffic Group-1将发生 HA切换，此时用户访问 VIP-A 时将直接到达数据中心 B，由数据中心 B 的服务器进行处理，因为此时数据中心 A的服务器已无处理能力。篇三：魅族多机房部署方案 魅族为什么做多机房部署？XX年魅族转型，转型之后放弃小而美的发展模式，这个时候用户量达到 2500万，这个是比较早的数量，还不包括双 11的数量，达到 XX万之后，机房扩展出现了一个瓶颈，单机房已经很难满足需求了。魅族不就是做手机的 魅族的应用商店，日亿；在线引用，日亿；用户数据同步，即包括

14、联系人、短信、设置项目在内的用户手机上的数据，全部传到云端，日 PV也有亿，数据量可达300 亿条记录，规模较大。单机房的问题 1.扩展存在困难 之前的机房选址广州亚泰，质量可观，机位紧俏。相应的，扩容就很困难，绝不是需要就可以马上得到。我们要提前预约好机柜的数量，但业务量爆发的时候，数量可能会超出预计，因而单机房扩容，极为困难。2.价格很难谈妥 因为只有一个机房，在与机房 IDC 谈商务条款时屡遭困难，对方云淡风轻“要不你就拆迁呗”，我们无可奈何，并没地方迁，价格因而很难谈下来。3.无法做到容灾 挖掘机挖段光纤的事情屡见不鲜，支付宝也曾不幸中招业务中断。当然他们基于更为复杂的业务也有相应的多

15、机房容灾机制。此外也有云服务商的机房遭受闪电攻击，进而电力出现问题。单机房若遭闪电必停止服务无疑。实际经营中，各种意想不到的情况都有可能发生。因此：魅族在 XX 年初时即着手准备做多机房部署。多机房部署面临的挑战 1.首先是数据一致性难以保障，这是最大的一个问题，当数据在一个地方有变动，在另外一个地方怎么样体现出来，这很困难。如果机房和机房之间通过网络传输数据，先不论可怕的网络延时，跨机房专线的昂贵和无保障也足以让人望而却步。运营商不可能说专线给你做到 3个 9 或者是 4 个 9，一般就不错了，你怎么样做到 3个 9，4 个 9，这个问题只有自己解决。2.3.我们的流量该怎样调度？用户怎样决

16、定去 A机房还是 B机房，用什么方式决定？4.5.业务层面，多机房的架构，必须考虑业务部门的感受，不能天马行空。我说我哪里那里需要重写，业务部门很难接受。所以方案必须要让业务部门改动尽可能小。6.7.最后，因为各个业务之间的依赖关系很复杂，之前也要做若干解偶和业务的切分。8.魅族的两大跨机房部署方案 大大小小五六十个业务，映射到两种类型，第一个是读多写少的业务，另外一个是按用户维度划分的业务，是两种不同的方案。应用商店想必已经周所周知。而魅族的应用商店有一个特点，数据是一个榜单，主要是展示它给大家看，不管是竞选、排行、分类，各种都是榜单，数据变化很小、很少，对数据的一致性要求并不高，A和 B用

17、户看到的数据可能不一致，并不会影响大局，只要可以下载应用就可以。跨机房之一，应用商店 单机房架构下业务分为三类：1.API客户端接入使用，客户端就是应用商店的 APP 要想下载，就在这里拉数据、列表。2.3.开发者社区，提供给开发者维护应用的数据。API数据的一个特征主要是读取数据，写很少，只是拉榜单出来。一部分像评论，下载的话有一个下载的机数，数量较少。而开发者社区的读和写差不多，量也是差不多。4.5.运营后台，主要是后台运营成员来维护数据，读和写也类似，数量上差不多。我们前端划分了许多业务，后端则会有一些服务化的按照业务做了切分，做不同的服务，应用排行、购买服务、运营服务等等，数据如 API等，要使用应用排行，需要通过 Task 到 Recis 集群读取。6.应用商店怎样做到多机房