跨机房数据库解决方案Word格式文档下载.docx
- 文档编号:18241890
- 上传时间:2022-12-14
- 格式:DOCX
- 页数:5
- 大小:20.55KB
跨机房数据库解决方案Word格式文档下载.docx
《跨机房数据库解决方案Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《跨机房数据库解决方案Word格式文档下载.docx(5页珍藏版)》请在冰豆网上搜索。
对于发热量大的服务器等IT设备,通常选用高通孔率(一般大于70%)网孔门的机柜,提高机柜进出风量;
将机柜面对面、背对背布置,在机房内形成冷热隔离的风道,提高制冷效率;
空调采用下送风方式,确保机房送风均匀,提高制冷效率。
在某些功率密度特别高场合(发热量超过5kw/机柜),往往容易产生局部热点,形成故障隐患。
为消除局部热点,需要采用相应的高热密度解决方案,如开放式方案即为在局部热点发生处加装制冷终端XD,加强局部制冷能力,以消除局部热点;
封闭式方案即为高功率密度设备放置在封闭机柜内,通过机柜内制冷循环,高效率制冷散热。
3、机房监控管理系统,大型数据中心需要对电源、空调等设备运行状态进行管理,同时还需要对机房内环境,如温湿度、漏水、烟感等参量进行监控,确保数据中心工作在一个正常的范围之内。
并对数据中心设备运行参数和环境量实时监控和管理,同时远程监控和管理,实现机房无人值守。
篇二:
双城数据中心双机房建设解决方案
双城数据中心双机房建设解决方案
目录
第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章概述
为进一步推进某信息化建设,以信息化推动某业务工作的改革与发展,某在科技楼建有核心机房和一个小的本地容灾备份中心,现在在干保楼又新建了容灾网,实现同城双中心布局。
为提高业务可靠性与双中心设备资源的利用率,某拟建同城双活数据中心,达到双中心同时对外提供同种业务的目标,同时实现业务切换无感知、计算资源灵活调度的功能目标。
数据集中阶段的数据中心建设
传统架构存在的问题
传统数据中心网络采用传统以太网技术构建,随着各类业务应用对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的服务器已无处理能力。
篇三:
魅族多机房部署方案
魅族为什么做多机房部署?
20XX年魅族转型,转型之后放弃小而美的发展模式,这个时候用户量达到2500万,这个是比较早的数量,还不包括双11的数量,达到20XX万之后,机房扩展出现了一个瓶颈,单机房已经很难满足需求了。
魅族不就是做手机的
魅族的应用商店,日亿;
在线引用,日亿;
用户数据同步,即包括联系人、短信、设置项目在内的用户手机上的数据,全部传到云端,日PV也有亿,数据量可达300亿条记录,规模较大。
单机房的问题
1.扩展存在困难
之前的机房选址广州亚泰,质量可观,机位紧俏。
相应的,扩容就很困难,绝不是需要就可以马上得到。
我们要提前预约好机柜的数量,但业务量爆发的时候,数量可能会超出预计,因而单机房扩容,极为困难。
2.价格很难谈妥
因为只有一个机房,在与机房IDC谈商务条款时屡遭困难,对方云淡风轻“要不你就拆迁呗”,我们无可奈何,并没地方迁,价格因而很难谈下来。
3.无法做到容灾
挖掘机挖段光纤的事情屡见不鲜,支付宝也曾不幸中招业务中断。
当然他们基于更为复杂的业务也有相应的多机房容灾机制。
此外也有云服务商的机房遭受闪电攻击,进而电力出现问题。
单机房若遭闪电必停止服务无疑。
实际经营中,各种意想不到的情况都有可能发生。
因此:
魅族在20XX年初时即着手准备做多机房部署。
多机房部署面临的挑战
1.
首先是数据一致性难以保障,这是最大的一个问题,当数据在一个地方有变动,在另外一个地方怎么样体现出来,这很困难。
如果机房和机房之间通过网络传输数据,先不论可怕的网络延时,跨机房专线的昂贵和无保障也足以让人望而却步。
运营商不可能说专线给你做到3个9或者是4个9,一般就不错了,你怎么样做到3个9,4个9,这个问题只有自己解决。
2.
3.
我们的流量该怎样调度?
用户怎样决定去A机房还是B机房,用什么方式决定?
4.
5.业务层面,多机房的架构,必须考虑业务部门的感受,不能天马行空。
我说我哪里那里需要重写,业务部门很难接受。
所以方案必须要让业务部门改动尽可能小。
6.
7.
最后,因为各个业务之间的依赖关系很复杂,之前也要做若干解偶和业务的切分。
8.
魅族的两大跨机房部署方案
大大小小五六十个业务,映射到两种类型,第一个是读多写少的业务,另外一个是按用户维度划分的业务,是两种不同的方案。
应用商店想必已经周所周知。
而魅族的应用商店有一个特点,数据是一个榜单,主要是展示它给大家看,不管是竞选、排行、分类,各种都是榜单,数据变化很小、很少,对数据的一致性要求并不高,A和B用户看到的数据可能不一致,并不会影响大局,只要可以下载应用就可以。
跨机房之一,应用商店
单机房架构下业务分为三类:
API客户端接入使用,客户端就是应用商店的APP要想下载,就在这里拉数据、列表。
开发者社区,提供给开发者维护应用的数据。
API数据的一个特征主要是读取数据,写很少,只是拉榜单出来。
一部分像评论,下载的话有一个下载的机数,数量较少。
而开发者社区的读和写差不多,量也是差不多。
4.
5.
运营后台,主要是后台运营成员来维护数据,读和写也类似,数量上差不多。
我们前端划分了许多业务,后端则会有一些服务化的按照业务做了切分,做不同的服务,应用排行、购买服务、运营服务等等,数据如API等,要使用应用排行,需要通过Task到Recis集群读取。
应用商店怎样做到多机房
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 机房 数据库 解决方案