分类 大观园 下的文章

2013年1月16日是第七届IDC大会开幕的日子,BingoCC品高云在线是除了中国电信和中国联通以外最重要的国内参展商,(参见:http://www.idcquan.com/special/2012idc/partner.html )名单中,赫然发现,国外巨头已经盯上了中国的IDC市场,telehouse和前面的两大运营商作为大会的重要的三大参展商加入这次会议。当然这次会议,品高也将会有重磅策略让世人再次感觉到品高在云计算领域不断技术创新和市场创新而带来的震撼,请大家拭目以待。
其实今天写这篇文章的本身目的不是为简单的宣传品高参加的IDC会议,而是总结最近在支持合作IDC的时候遇到挺多的困惑,想通过这篇文章来讲讲个人的一些观点,也为这次参加IDC大会的各类IDC们提供一些讨论的话题,这些话题本身也是在我和其他IDC沟通过程中的不断困惑又不断清晰的过程,希望对大家能有一些启发。


一、传统IDC为什么要上云


很多IDC会有困惑,我们为什么要上云,那我们看看传统IDC现有的业务有哪些
a、带宽业务
b、场地、实体硬件租用业务
c、类云业务 (虚拟空间、VPS)
d、其他增值(维护、安全、电力保障等等)
这四类大家都做得很好,云有什么好处呢?
这么多年,大家养成的习惯我们发现,我们必须看美国,美国的IDC目前受到大量提供云服务商冲击,美国的今天就是中国的明天,我们看看美国会有哪些云服务商,如果是业内人士就知道了主要这几家:


1、提供IaaS的亚马逊AWS等(当然谷歌也在Compute Engine服务)
这些云服务是如何冲击传统的IDC业务的呢?


a、带宽业务的冲击
目前国内带宽的计量消费市场有两种一种是时间+带宽峰值计量方式,另一种是流量计量方式
而我们IDC一般都选择第一种方式来计量,那么亚马逊和品高云可以提供什么方式呢,根据用户的不同,我们再后台都能够获得准确的流量值,结合不同的计费模式和计费需求,满足不同用户的需求,这样的服务,我们称为弹性网络IP服务(Elastic IP),能获得准确可靠的数据才可能弹性,行业用户和互联网用户会跟进不同的需求选择最经济的套餐来满足他们的常规需求和突发带宽需求。这样的服务,用户没有道理不心动。


b、场地、实体硬件租用的冲击
云服务上所有的云能力都是一个整体,用户需要多少性能的vm就购买什么性能实时计算或者配额,所有的选择都是自助的,自助的计算能力配置--弹性计算服务(EC2),自助的存储能力配置--弹性存储服务(EBS),用户通过,云监控服务(Cloud Watch),在获得更详细的底层数据后,既可以用,简单通知服务(SNS),来通知自己,也可以通过不同技术的结合实现弹性:应用负载均衡服务(LoadBalance)、自动伸缩服务(Auto-Scale)、云能力编排服务(CloudFormation)等等,这些都是国际通用的标准,你的软件支持这些标准开发,在每个专业的IaaS商上都能跑起来,甚至我们可以,传统应用的自动化部署服务(Beanstalk),不光是扩展vm而是自动化的扩展出完整的软件三层构架(表示层、业务逻辑层、数据层),里面包括各种信息(网络、存储、计算能力等等)等等,这些云上提供的能力,而且远低于传统用户自己购买硬件、维护硬件的成本,这种方式,用户一旦依赖之后,传统的IDC是不是会有危机呢?甚至消亡呢?


c、虚拟空间、VPS等类云业务的问题
这些类型的业务往往被很多小的IDC包装成云业务来忽悠用户,如果用户关注规模很小而且不考虑扩展,这些需求或者能满足用户的需求,但虚拟空间和VPS,这种批发转零售的业务真的有足够盈利去保证好的用户体验吗?在和圈内的中大型IDC沟通中,可以发现,这类业务,利润低、维护度高、用户自主性差体验性差、安全隔离困难等等,用户附加值小导致他们慢慢把这类业务转给更小的IDC去接手,如果真的关注服务品质的用户也会陆续转到专业的云IDC提供商。
d、其他的增值服务
云上会有各种各样的增值业务,很多IDC也被IaaS、Paas、SaaS所困惑失去判断方向。本人曾经拜访过一个省级电信的大型云供应商的云负责人,他对于IaaS一脸的不屑,说这类技术如果2009年来提还很吸引人,现在已经是过气的技术了,还很强势的说,我们这样的企业对IaaS已经没有兴趣了,我们关注的是PaaS和SaaS。对这种观点,我本人保留意见,具体观点我们看看下文。


作者:云掣YUNCHE
链接:https://www.zhihu.com/question/336835694/answer/1417454740
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

上云,一是好处很多二是现在国家也在大力的鼓励上云,并出台了许多的上云政策。

伴随着“云+”时代的到来,通过上云实现企业数字化转型已经成为众多行业的共识。工信部发布的《推动企业上云实施指南(2018-2020年)》提出了企业上云的工作目标,到2020年,云计算要在企业生产、经营、管理中的应用广泛普及,全国新增上云企业100万家。

上云的好处

1. 节约成本

企业上云后,包括企业资料储备信息、企业工作计划等文件,由纸质转为信息化存储,避免了账目易损坏丢失等问题,保证了数据文件安全的同时,还节约了人力整理数据文件的资源成本,现在依靠云服务就可以完成,这是节约的第一笔成本。第二笔成本,企业上云可以利用其他公司的基础设施来做完善自己公司的系统和业务,公司可以节省IT成本,企业不再需要自主购置服务器,减少设备上的开支。第三笔成本,有效避免日常业务中出现的故障或系统上的问题来造成的影响,将企业的运维部分也一起交了出去,节省企业运维成本。

2.提高效率

云服务平台与互联网具有连通性,基于此种连通性,将用户与企业相连接、将员工与企业相连接、将员工与员工相连接。可以方便各种技术流派和技术架构的云用户使用云平台,实现平台资源共享。企业上云最重要的是将企业以往的垂直管理变为扁平化管理,文件决策实时共享传递。取消了纸质化,传输同步的过程,在云平台可以共享工作需要的所有数据,大大的提高了办公的效率。

3.帮助决策

云上的数据的整合可以更直接的帮助企业反映出本身问题的所在,将数据直接在平台上显示出来,做到实时的监控预警。同时可以为企业的发展、业务上的升级,提供了很好的资料,有助于企业智能决策,助力企业的管理。

随着科技的进步和发展,网络也在不断升级改造,由原始的2G,3G,4G到现在正要普及的5G。一切都是在更好更便捷的方向提升优化,企业的管理上也是在不断升级,不断便利化发展。

从企业自身需求来讲:

1. 自身发展难题,产生上云需求。对大部分企业而言,使用云计算服务多是因为IT系统及基础设施的更新换代、IT成本居高不下资源利用率低、IT资源管理困难、安全程度低等原因。无法支撑自己企业的进一步发展,上云寻突破。

2. 互联网转型,产生上云需求。工业互联网作为新一代信息技术与工业系统深度融合的产物,日益成为实现生产制造领域全要素、全产业链、全价值链连接的关键支撑和工业经济数字口网络化、智能化的重要基础设施。

上云案例

政务

为响应上云号召,改善投资发展环境、转变政府职能、方便投资者和广大市民而设立的集信息与咨询、审批与收费、管理与协调、投诉与监督等为一体的市级综合服务平台。但由于政府各部门之间的数据壁垒,群众办事难,政府行政效率低,为满足社会及公众对政府公共管理和公共服务的期望,促进社会经济发展,市政部门计划依托政务云进行新一代政务系统的构建,实现系统节约化建设及政务服务一体化改革。云掣科技基于系统调研、业务访谈、应用考察,数据分析等一些列标准化实施流程及迁云方法论,为客户提供了迁云咨询,方案设计,部署实施,业务割接,可用性验证的全方位定制化服务。大大降低了IT投入成本,有效保障了数据的安全性和私密性。政务服务一体化在线办理,切实提高了人民群众的满意度和办事效率。

医疗

网络医院的PACS集群部署在本地IDC环境,存储了多达300TB的历史数据。随着智慧医疗的快速发展,每年新增的影像数据逐年上升,近年已超过800TB,存储资源日益紧张,PACS系统的数据存取性能也日趋下降。云掣科技帮助帮助该医院梳理和设计云端网络架构,并搭建了全新的云端PACS系统,实现应用的合理布局,完成国内首家三甲医院医疗影像300TB的全量数据迁移上云,释放了线下IDC存储的压力,优化了资源使用,大幅降低了IT系统的运维成本。通过将每日增量数据定时同步到云端,实现无纸化拍片可随时查看,加快智慧医疗的进程,医院可以为病患提供更智能更优质的“互联网+医疗健康”服务。医院梳理和设计云网络架构,实现应用的合理布局,优化了资源使用和成本。

电商

为响应国家“力争实现企业上云环境进一步优化”的上云政策,某公司在年度调整工作计划会议中明确提出建设新电子采购系统计划。云掣科技通过深入调研,为客户制定了“高效率、低成本”的系统规划迁移方案。对电子采购系统进行从云下环境到云上环境,云上环境多地区间的迁移升级,实现了保障数据安全,数据同步零丢失,业务割接时间短,系统稳定运行的目标。在保证数据一致可靠的基础上完成了业务系统平迁微改造、同时将系统不可用的时间降至最低,提高了业务的连续性。

更多技术案例了解:

专有云_迁云搬站_云上运维_数据库容灾_大数据运维_袋鼠云运维中台www.dtstack.com图标


发布于 2020-08-18

赞同 173 条评论

分享

收藏喜欢收起

继续浏览内容

知乎

发现更大的世界

打开

Chrome

继续

更多回答

趣问科技

趣问科技

已认证的官方帐号

25 人赞同了该回答

对于自建机房的人来说,需要考虑很多问题。

首先,当你的提供的服务达到一定水平后,需要自建机房,就要考虑到建设机房、以及建设机房相关人员费用。而且每个区域都应该有多个机房,尤其是业界边缘一个region由3个相距数十公里的机房组成。因此,在建设过程中,要对业务量进行估算,防止后期没有扩张的空间。

接着,建设完成后,需要采购硬件、各种开关、路由、排线、防火、防震、防水、散热、独立供电系统等。

其次,还要具备承担网络费用,符合云厂商标准、入流量免费,尤其是公网流量是非常贵的,这些都需要你来支出。同时,机房需要24小时不间断的驻场人员维护和处理故障,费用也要自理。

最后,业务方需要相应的运维人员进行维护。


以前接触过一个大客户,每年在我负责的服务上花了大约6000万元。只有一名维护人员,大部分服务都是他一个人操作。事实上,我负责每个环节不少于20项服务,另外,他用了我们不止一项服务,所以这里的人工费也不小。

以上是根据你的逻辑计算的费用。

这不是你的机房建了,机器买好了,操作和维护都确定了,就可以开始操作。事实是你用的是服务,而不是机器。

这时你需要具备一个精通虚拟化的团队,尤其是一个精通分布式存储的团队。有了这些资本,你的机房才能正常使用,毕竟,通过人力成本可以秒杀大多数公司。

随后你业务所需的每一个基本组件,如mysql、redis、Kafka、ZK,都需要你自己构建和维护,这里会有更多的开发和经营。

除了基本组件外,还有许多高级功能,如各种图像处理、权限控制、短信服务、视频处理等,都需要一个专业的团队来做这件事。

因此,无论是员工,还是硬件,都不能动态地扩展或减少容量。这里应该增加多少冗余来处理紧急情况?

现在你还认为,在一定程度上建造自己的机房便宜吗?

再讲两句:

1.现在全球的云制造商,不包括广告费用,只有AWS是盈利的,其余的都是亏损的。

2.我们的大多数客户都对自己建造的机房进行了评估。除了这些特别有钱的客户说,成本再高,也需要建立一部分容灾外,其余的都在云端。云服务器,省的是人力,而不是硬件。如果能节省一半人力,云就比自建好。

但很多大企业建立自己的数据中心不是为了省钱,而是为了其它目的。


我们仔细计算过,这类企业在云端的性价比要高于其他企业,那么哪些企业适合上云呢?

1.流量小的个人用户

2.初创企业不希望在环境部署和维护上花费太多时间。

3.企业无运维或运维能力弱的。


在这里不得不提国内市场排名第一的阿里云,以我300台实例7年运维经验来看,阿里云裸机和GPU的性价比最高,值得上云,计算密集型业务尽量用物理机,云上的贵死,性能又差

云服务器 ECS_BGP多线 - 阿里云官网www.aliyun.com图标云服务器ECS活动机型——阿里云www.aliyun.com图标

对于海外业务的企业,又想免除备案,这点推荐海外版云服务器,腾讯云推出的海外云服务器提供包括支持免费更换IP并且不限次数等服务,这点相反非常友好!由于海外云服务器有IP被封禁的风险存在,用户基本上只能向平台提工单解决,针对这类问题一般云服务商解决办法都很模糊不清,要是不能退款,这台服务器就相当于废了,这是目前国内众多云平台的通病了。

腾讯云特惠-1核2G1M低至298元/3年cloud.tencent.com图标全球云服务器活动_海外云服务器优惠低至2折 - 腾讯云官网cloud.tencent.com图标

不过一旦出现IP地址被封禁问题,先别慌,尝试免费更换IP是否能够解决,如果不能再去咨询云服务商发生此类情况的原因,并商讨解决方案。另外国内云平台官网一般给注册新用户的价格各自折扣,老用户的价格相对较高。相比购买一年后续费两年的价格要比一次性购买三年的价格要高不少。考虑到项目业务周期的时间不建议一次性购买五年,要是不差钱,海外的AWS Google的体验也还不错。

腾讯云在性能上得到很大提升,基本让我们老站长在配置上感受不到和阿里云的差距,后期的续费相对要比阿里云低。如果你留意会发现腾讯针对老用户的活动要比阿里云多。

再说一个就是华为云,华为云在当前政务服务体系中拥有着较强的能力,这一点是无需质疑的,在政企和私有云领域,华为云拥有绝对垄断地位,合作的大多是政府、邮政、运营商、高校等单位。

但是华为云在Paas层面,Iaas层面华为云正在加快发展速度,最近几年动作不断

任正非:华为云已初具规模,新的一年里要加大人才投入;企业业务要收缩战线,有所为、有所不为baijiahao.baidu.com图标余承东接管华为云背后:究竟意欲何为?baijiahao.baidu.com图标

华为云是唯一 一家提供端到端服务能力的云计算平台,从底层的物理设备到上层的虚拟化建设都是有华为自助研发的产品(软硬件),并且技术是得到业界广泛认可。其华为云提出的:“上不碰应用,下不碰数据”行业标准,成为云服务商中信息安全的最高标准,这也是众多大型企业迁移入驻到华为云的原因之一。

下面这张图源自于官网价格,也从整体上侧面反映,云服务器价格:阿里云>华为云>腾讯云;不过细分到具体配置,可以从官网中比照。

如果上云考虑下这些大企业,售后服务方面相对更加有保证

官网链接:

腾讯云官网:https://cloud.tencent.com

阿里云官网:https://www.aliyun.com

华为云官网:https://www.huaweicloud.com

Google官网:cloud.google.com/

编辑于 04-21

赞同 25添加评论

分享

收藏喜欢收起

继续浏览内容

知乎

发现更大的世界

打开

Chrome

继续

F5 Networks

F5 Networks

已认证的官方帐号

13 人赞同了该回答

现在确实有越来越多的公司选择将业务搬到云上,甚至是将核心业务搬到云上,但是真正将全部业务搬到云上的公司实际上并没有很多。

从企业上云的动机和驱动力来看,业务上云确实能够帮助企业实现降本增效,但是很多行业头部客户其实对all in cloud还是持谨慎态度的,更多的是根据自身业务形态和部署状况,选择性的将适合在云中发展的业务上云,比如需要借助云中大数据、AI等SaaS类服务能力的,需要通过devops手段实现业务快速迭代的,或者业务本身生存周期不可控,先期在云中做试验的,又或者业务对弹性和扩展要求很高,比如电商类,促销类to C业务,需要用云中的自动化、弹性、扩展能力的,这些业务类型天生适合在云中部署,所以当企业自身转型到这个阶段,对应用要进行改造时就会优先考虑迁移到云上,或者先迁移到云上再改造。

而一些企业的互联网类新生应用尤其是采用分布式思维和架构部署的应用其实不涉及到迁移的过程,大部分企业现在对To C类互联网业务在设计之初就会考虑部署在云中,利用云的快速部署能力和弹性先达到快速获客的目的,然后再随着获客量的增加和客户需求增加逐步做体验优化和功能优化等产品迭代。这类业务其实就是云原生的高度分布式的应用,而这种新型应用未来的发展也会和基础架构的耦合度越来越低,所以会比较轻松的迁移到任何一个云上。

很多企业在考虑多云业务部署时的前提,就是把应用和基础架构解藕,借助容器化,分布式数据库,分布式存储,应用交付,serverless等技术实现多云混合部署,好处是可以把云厂商层面的故障风险分摊,不被一家云厂商绑死,同时平衡各家云的特点,按照应用特性将合适的应用部署在适合的云上,发挥云平台的最大效能,最终在降本增效的同时实现业务价值的最大化。

以弘康人寿“上云”为例,F5全代理架构使它成为天然的大数据收集引擎,实现了云上应用的可视化。由于弘康的私有云数据中心内部已有硬件的F5设备,加上在云上部署轻量的VE,可以通过应用层上的一些配置可以让本地数据中心和公有云之间顺畅交互,形成多云多活技术架构。


摘要:本篇文章将浅显易懂的为你解读将现有的应用迁移到云端所带来的各种益处,以使你在进行决策时做到心中有数。


传统IDC的问题


  1. 硬件和电力投入成本高

    传统的IDC机房 , 需要购买自己的服务器 , 需要自主部署服务器机房 , 或者租用第三方的服务器机房 , 硬件成本和电力投入都非常高。

  2. 烟囱式的架构体系 ,造成资源严重浪费

    烟囱式架构体系 , 为了维护服务器性能的稳定 , 不断地扩充服务器 , 这就造成了现有系统在低峰时段 , 现有资源的严重浪费 . 因应用架构的便跟 , 也会造成大量的服务器资源无法被重复利用 。

  3. 交付周期长  , 通常一个服务器采购时间需要1周不等

     购买新的服务器 , 或者搭建新的网络都需要大量的人力时间 , 服务器从购买到上线部署 , 软件升级以及上线测试需要不少的维护时间。

  4. 专人维护 ,运维管理成本太高

     服务器价格较高, 需要存放在低温无尘的环境下 , 即使这样仍然会因各类原因造成现有固件的损坏 , 从人力上 , 就需要很多人力成本去监控 , 巡检 , 测量以维护各个服务器的使用。

  5. 硬件升级扩展灵活性差

     硬件升级需要在原有的基础上停机 , 并且改装现有的硬件 , 花费的时间长 , 扩展灵活性较低。

公有云的优势


  1. 公信度

        到目前为止,几乎所有的公司,至少都在使用一种IT云服务。与传统的基于控制器的网络管理系统相比,由于其灵活性和无缝可伸缩性,云网络适合各种规模和行业的组织。即使是传统上由于安全性和可用性考虑而依赖于现场部署的行业或地区,也越来越多地转向云服务。


  2. 节省成本

        IT部门不再需要购买、部署和维护内部的计算硬件和软件,可以通过云服务快速、容易地建立起来,无需IT人员参与就能根据需要进行扩展。简而言之,云计算极大地简化和降低了IT服务提供的复杂性和成本,而设置的有线和无线接入网现在可以享受到同样的好处。并且极大的降低了网络管理系统冗余硬件和软件基础设施以及中央硬件控制器的资本支出 , 以及扩展网络时正在进行的管理和可能增加的人员的人事费用。

   3. 灵活弹性

      公有云最吸引人的特征就是弹性 , 根据业务的不断的变化需求 , 能够实现无缝地向上或者向下扩展 , 时间可以控制在以小时为单位 .        例如一个游戏公司中午12:00 和晚上19:00-22:00是用户访问的高峰期 . 那么在中午12点的时候扩展服务器 , 在中午14:00的时候释          放,晚上19:00的时候再次增加服务器 . 而这些所有的服务都是自动化实现的 . 有效的节省在用户访问量低的时间服务器资源的浪费 。


哪些服务更适合上云


  1. 增量服务

     所有的增量业务都应该考虑上云,因为这可以降低固定资产的成本,对于一个大企业来说,转型做互联网业务一定会面临许多增量业务,这种增量一定是云为优先考虑,因为云可以轻松的增加业务弹性。


  2. 互联网基础转型

    广义上讲,公共云这种形态之前是互联网的基础设施,未来则是互联网+的基础设施.


  3. 数据依赖型系统

     业务都需要用数据来提升服务水平,提升产业智能,包括需要用数据来驱动,那么这也是高度依赖云的,因为在云上,这些方面的数据是很容易集成的,上云不是目的,创新才是目的。

    那么要做到“为迁移做好准备",企业应当怎么做呢,其一,即是在充分了解的前提下开始迁移流程。此外,企业也应当充分了解他们所选择的云平台的能力与限制。

   如何快速了解与选择迁移产品?较快捷并且有效的方法就是咨询一家做云迁移服务的公司。

   奇步互动 [ https://www.qibu121.com/ ]已成功为多家企业制定云迁移方案,不仅帮助你了解云迁移,选择适合企业的云迁移产品,并且制定方案并加以实施,帮助

企业节省人力与成本,实现服务器的最大化应用。


1.概述

1.1 简介

本文主要介绍中小型互联网企业,从本地机房迁移数据库到腾讯云的实践方法。其中包含了详细数据库迁移的方法和步骤,并且增加了实践演练和验证。实践与验证部分内容以常见的 Discuz! 论坛迁移上云做为案例。

1.2 相关概念

CVM:Cloud Virtual Machine 云服务器,在本文中代指腾讯云服务器。

CDB:Cloud Database云数据库,在本文中代指腾讯云数据库 Mysql。

TencentDB for Mysql:腾讯云基于开源数据库 MySQL 专业打造的高性能分布式数据存储服务,让用户能够在云中更轻松地设置、操作和扩展关系数据库。

DTS:Data Transmission Service(数据传输服务),支持 MySQL、MariaDB、PostgreSQL、Redis、MongoDB 等多种关系型数据库及 NoSQL 数据库迁移,可帮助用户在业务不停服的前提下轻松完成数据库迁移上云,利用实时同步通道轻松构建高可用的数据库容灾架构,通过数据订阅来满足商业数据挖掘、业务异步解耦等场景需求。

源数据库:简称源库,本文中代指准备迁移的IDC自建数据库。

目标数据库:简称目标库,本文中代指迁移的目标云数据库。

2.云化业务系统架构设计

IDC业务迁移上云架构设计图例

3.业务环境部署

下图展示了一个标准的 IDC 业务架构,此架构作为业务迁移前的标准架构,具体部署方式以实际用户的情况为准。

IDC业务架构示例

4.服务器迁移

根据业务需求,迁移服务器到云上CVM云服务器中。通过云CVM业务访问本地IDC机房数据库(需考虑网络延迟)或者访问云上新建数据库(仅包含测试数据),验证应用服务迁移成功。本文使用一次性割接方案,切割前使用云服务器访问云数据库进行测试和验证。

具体实现细节不在本章详细展开,略。

IDC服务器迁移CVM架构示例

5.数据库迁移

本章节会详细介绍 IDC 自建数据库迁移到云上 CDB的方法和步骤。

数据库迁移架构图示

5.1 迁移流程概览

5.1.1 DTS迁移数据库流程原理图示

DTS数据库迁移原理图

5.1.2 DTS数据传输步骤概览

使用DTS数据传输服务完成数据库迁移上云,主要步骤如下图:

数据库迁移步骤概览

5.1.1 DTS 迁移原理

  1. 对 IDC 自建数据库和云数据库 CDB 环境进行检查,打开防火墙,使 CDB 能够访问到 IDC 网络中的自建数据库。

  2. 利用 mydumper 工具从自建数据库导出 SQL 备份文件到中转机器。

  3. 将 SQL 备份文件导入到 CDB 中。

  4. 将 CDB 和自建数据建立主从关系,同步增量数据。

  5. 等主从同步完成,进行数据抽样对比。

  6. 用户主动断开主从,迁移完成,关闭 DFW 防火墙。

DTS 数据迁移任务包含冷备数据导出、增量数据同步两步骤。其中,冷备数据导出以及迁移后的数据对比过程会对源库负载产生一定的影响,建议在业务低峰期或在备库上进行数据迁移。

5.2 数据库迁移准备

5.2.1 网络规划

源数据库网络(本案例中的表格内容,均为案例的示例):

地域

公网

内网

源数据库地址

功能描述

关联系统名称

广州

xx.xx.19.203

10.0.30.73

xx.xx.19.203:3306

本地IDC数据库所在网络

Discuz论坛

地域 公网 内网 源数据库地址 功能描述 关联系统名称

目标数据库网络:

地域

VPC

subnet

AZ

功能描述

关联系统名称

广州

DefaultVPC

广州3区 10.0.30.64/26

主广州3区/备广州4区

云数据库所在私有网络

Discuz论坛

5.5.2 目标云数据库架构规划

实例名称

数据库类型即版本

架构

源库读写比例

源库读写分离

配合规格

硬盘

备份空间

Discuz数据库

MySQL 5.6

高可用版一主一从

3:1

4核CPU 8G内存

100G

每天备份,保存7天

5.2.3 云数据库参数规划

实例名称

character_set_database

lower_case_table_names

binlog_format

tx_isolation

sql_mode

wait_timeout/interactive_timeout

Discuz数据库

utf8mb4(与源库保持一致)

0

ROW

READ-COMMITTED

NO_ENGINE_SUBSTITUTION(与源库保持一致)

3600

5.2.4 安全组规划

根据访问数据库的来源IP,来规划数据库安全组设置。

实例名称

访问来源IP

访问端口

访问协议

访问策略

关联系统名称

Discuz数据库

10.0.30.64/26

3306

TCP

允许

Discuz论坛

5.3 购买与配置云数据库

根据规划的实例配置与网络信息,购买部署云上数据库资源。如果使用已购买的实例,建议针对规格配置、网络等进行二次检查和调整,同时需要先清空目标云数据库的数据,再进行正式的数据迁移,避免数据冲突导致迁移失败。

5.3.1 购买云数据库实例(可选,如已购买请跳过)

步骤1 点击如下链接,创建云数据库所在私有网络子网(本文中的截图均为案例示例)。

链接:https://console.cloud.tencent.com/vpc/subnet?rid=1

创建私有网络子网

步骤2 登录腾讯云官方网站,进入控制台,选择云数据库 MySQL。

链接:https://console.cloud.tencent.com/cdb

步骤3 选择广州地域,点击【新建】按钮,进入购买页面。

新建Mysql实例

步骤4 根据规划的云数据库网络和架构,进行初始参数的选择,案例示例如下:

  • 实例版本:5.6

  • 架构:高可用版本一主一从

  • 可用区:主在广州三区,备在广州四区

  • 配置:4核CPU 8000MB 内存,100G磁盘

  • 网络:私有网络DefaultVPC,子网subnet-discuz1

新建Mysql实例

新建Mysql实例

根据页面提示,选择【新建安全组】或者选择已经存在的安全组。

新建Mysql实例

新建安全组

新建安全组

阅读云数据库服务条款,确定无误之后,点击“立即购买”,检查完账单信息并完成支付即可。

新建Mysql实例

步骤5 购买成功后,进入Mysql控制台,等待发货完成,如下图。

Mysql控制台

步骤6 发货完成之后,点击数据库信息栏右侧的【初始化】,配置数据库参数,点击【确定】开始初始化操作。

各参数说明:

  • 支持字符集:LATIN1 、GBK、UTF8 、UTF8MB4,默认字符集编码格式是 UTF8。初始化实例后,也可以在控制台实例参数页修改字符集。

  • 表名大小写敏感:表名是否大小写敏感,默认为是。

  • 自定义端口:数据库的访问端口,默认为 3306。

  • 设置 root 帐号密码:新创建的数据库用户名默认为 root,此处用来设置该 root 帐号的密码。

  • 确认密码:再次输入密码。

本案例中使用的设置如下:

参数名

字符集

UTF8MB4

表名大小写敏感

开启,区分大小写

内网端口

3306

root帐号密码

xxx

效果如下图:

实例初始化

5.3.2 设置云数据库参数

进入云数据库 MySQL 的控制台,依次点击:【管理】-【数据库管理】-【参数设置】,进行其他参数的设置。

本案例中调整的参数如下表:

参数

binlog_format

ROW

tx_isolation

READ-COMMITTED

sql_mode

NO_ENGINE_SUBSTITUTION

wait_timeout/interactive_timeout

3600

参数设置

参数设置

参数设置

5.4 源库迁移前的检查与配置

说明:由于不同版本的迁移工具检查项会有差异,本案例以 5.6 版本为例,其他版本以实际迁移时的检查内容为准。

步骤1 整实例迁移的目标 CDB 必须是空库,如果不为空,例如含有测试数据,请先清空目标实例,再进行迁移。

检查源库版本:

mysql> show variables like "version";

源库操作示例

步骤2 版本检查,目前仅支持同版本迁移(5.1/5.5/5.6/5.7),以及5.1->5.5,5.5->5.6迁移。此次迁移为5.6->5.6,满足要求。

步骤3 检查目标库的容量,必须大于源实例。

步骤4 在源库上创建迁移专用的账号(也可以使用权限符合要求的现有账号),建议赋予ALL PRIVILEGES权限,可以使用如下命令操作:

mysql> GRANT ALL PRIVILEGES ON *.* TO "迁移账号"@"%" IDENTIFIED BY "迁移密码";mysql> FLUSH PRIVILEGES;

源库操作示例

步骤5 确认源库全局变量,使用参数的目标值如下所示:

lower_case_table_names=0; 根据需要设置源与目标一致;
server_id=1000; 根据需要与目标库设置为不同值,且不为1;
log_bin = ON; 必须为ON;binlog_format=ROW; 必须为ROW;binlog_row_image = FULL; 必须为FULL;innodb_stats_on_metadata = OFF; 必须为OFF;wait_timeout = 3600; 根据需要设置 [3600,7200)范围内;
interactive_timeout = 3600; 根据需要设置与wait_timeout一致;
character_set_database = UTF8MB4; 根据需要设置源与目标一致;
tx_isolation = 'READ-COMMITTED'; 根据需要设置源与目标一致;
sql_mode = 'NO_ENGINE_SUBSTITUTION'; 根据需要设置源与目标一致;
max_allowed_packet=1073741824; 需大于等于1073741824。

源库操作示例

步骤6 开启源库二进制日志文件。

修改源库配置文件my.cnf,增加log-bin 参数,并重启数据库生效。

# vi /etc/my.cnf[mysqld]log-bin = [自定义文件名]# systemctl stop mysqld.service
# systemctl start mysqld.service

如下图所示,源库二进制日志已经开启。

源库操作示例

步骤7 其余参数可以动态修改,使用set global <参数名> = <参数值>即可。

注:源库配置文件/etc/my.cnf中如果存在不同的值,建议一并修改配置文件,避免源库发生异常重启重置参数值导致迁移失败。

源库操作示例

步骤8 检查源库的表设置,腾讯云数据库 MySQL 目前仅支持 InnoDB 引擎。使用如下 SQL 在源库进行检查输出非InnoDB引擎表,并根据步骤9-10修改。如果不存在非InnoDB表,那么跳过9-10步骤。

mysql> SELECT table_schema, table_name,engine FROM information_schema.tables WHERE engine <> 'InnoDB' AND table_schema NOT IN ('mysql' ,'performance_schema','information_schema');

源库操作示例

步骤9 在源实例的低峰期,针对MEMORY引擎表修改为Innodb引擎(如不存在非InnoDB引擎表可跳过此步骤)。

扫描MEMORY引擎表,并进行修改。

mysql> SELECT table_schema, table_name,engine FROM information_schema.tables WHERE engine = 'MEMORY' AND table_schema NOT IN ('mysql' ,'performance_schema','information_schema');mysql> alter table xxx engine='InnoDB';

源库操作示例

经过修改,源库已经不存在memory 引擎表:

源库操作示例

步骤10 在源实例的业务低峰期,针对row_format=fixed 表修改为row_format=dynamic;

扫描row_format 为fixed的表,并修改为Dynamic。

mysql> SELECT table_schema,table_name,row_format from information_schema.tables where Row_format like '%fix%' AND table_schema NOT IN ('mysql','performance_schema','information_schema');mysql> alter table xxx row_format = Dynamic;

源库操作示例

经过修改,已经不存在row_format 为fixed的表:

源库操作示例

源库操作示例

5.5 创建数据库迁移任务

步骤1 点击如下链接,进入DTS数据传输服务控制台。

链接:https://console.cloud.tencent.com/dts/migration

步骤2 点击【新建迁移任务】,选择【华南地区(广州)】购买数据传输服务,目前数据传输服务免费使用。

创建数据迁移任务

创建数据迁移任务

步骤3 根据页面指引,设置迁移任务和源库类型,并测试源库的连通性。

  • 任务名称:为任务指定名称。

  • 定时执行:可为您的迁移任务指定开始时间。

  • 源库类型:支持有公网 IP 的 MySQL、云服务器上的自建 MySQL、专线接入腾讯云的 MySQL、VPN 接入等 MySQL 源库类型。

  • 服务提供商:支持阿里云定制迁移。

本案例中所采用的参数值如下表:

参数

案例参数取值

任务名称

discus迁移

运行模式

立即执行

源库类型

MySQL

服务提供商

普通

接入类型

公网

所属地域

华南地区(广州)

主机地址

xx.xx.19.203 (源库地址)

端口

3306 (源库访问端口)

帐号

migrate (源库上预先创建的迁移账号)

密码

xxx (源库迁移账号户的密码)

创建数据迁移任务

创建数据迁移任务

根据提示的IP地址,修改源实例防火墙,放通地址xx.xx.84.254、xx.xx.198.143 的访问权限;同时确定源库迁移账号的 host 字段包含图中提示的IP地址 xx.xx.84.254、xx.xx.198.143,允许其访问。调整完之后,点击【重新测试】,直到连通性测试全部通过。

创建数据迁移任务

步骤4 根据页面指引,选择目标库类型MySQL,并在数据库实例下拉列表中选择目标,点击【新建】。

创建数据迁移任务

步骤5 设置所要迁移的数据库。点击【保存】,进行迁移前校验。各参数的意义如下:

  • 结构迁移:仅迁移库表结构。

  • 全量迁移:迁移库表和数据,不追加同步增量数据。

  • 全量+增量迁移:迁移库表和数据,导入全量备份后,进行主备增量数据同步(推荐)。

  • 使用源库root帐户覆盖目标库:如需使用源库 root 帐号或目标库未设置 root,则选【是】,如需保留目标库的 root 帐号,则选【否】。

  • 数据一致性检测:支持全量检测或者不检测。

创建数据迁移任务

步骤6 迁移任务的校验结果,只有所有校验项通过后才能启动迁移任务。任务校验结果存在 3 种状态:

  • 通过:表示校验完全通过;

  • 警告:表示校验不通过,迁移过程中或迁移后可能影响数据库正常运行但不影响迁移任务的执行;

  • 失败:表示校验不通过,无法进行迁移。如果校验失败,请根据出错的校验项,检查并修改迁移任务信息,然后重试校验。失败原因可单击【查看详情】,根据提示的错误原因和修改方法进行修正。

创建数据迁移任务

5.6 数据迁移

步骤1 迁移校验完成页面点击【启动任务】或者是【数据传输】页面中找到迁移任务,点击【立即启动】->【确定】来开始数据迁移。如果设定了迁移任务的定时时间,则迁移任务会在设定的时间开始排队并执行,如果没有设置定时任务,则迁移任务会立即执行。

启动数据库迁移任务

启动数据库迁移任务

步骤2 在数据迁移页面,可以实时查看迁移的进度和状态。

如下图所示,迁移任务共有7个步骤,检查环境、参数配置、冷备份导出、冷备份导入(至此全量数据完成迁移)、同步构建、数据对比、数据同步中状态。

查看数据迁移任务

查看任务状态为准备完成,目标与源库时间延迟为0秒,表示增量同步接近实时同步。

查看数据迁移任务

5.7 数据一致性校验

同步追加无延迟时,进行一次手动的数据一致性校验。

步骤1  登入 Discuz 网站,模拟新用户注册,写入数据到源库中。

Discuz!论坛注册用户

Discuz!论坛注册用户

Discuz!论坛注册用户

步骤2 登入目标库,检查论坛的用户信息是否正确的同步了。论坛的用户信息在 discuz 库的 pre_ucenter_members 表中。

登入云数据库

登入云数据库

登入云数据库

5.8 云上业务测试与验证

完成数据校验之后,源库的数据已经迁移到云上,且正在实时同步。根据预先制定的方案,可对云上环境进行切换前测试和验证。

5.8.1 验证云服务器访问云数据库(只读测试)

登入云服务器,验证 discuz 账户访问云数据库 10.0.30.67 正常。使用 discuz 账户,从云服务器访问云数据库内网地址,验证正常。

验证云服务器访问云数据库操作示例

5.8.2 其他业务测试(写测试、可选)

根据业务需要,进行其他切换前测试。如果涉及写数据库操作,那么请查看本章节;如果不需要,本章节可跳过。

步骤1 写云数据库操作之前,需断开DTS同步状态。验证数据同步一致性完成后,在DTS数据迁移页面找到迁移任务,点击【完成】按钮,二次校验后点击【确定】,断开本地IDC机房数据库与云数据库的同步。

注意事项:点击【完成】按钮后,源库的数据变更不会在同步到目标库中,并且不支持重新同步,请谨慎操作如果不进行任何写操作测试,那么请跳出5.8.2章节。

链接:https://console.cloud.tencent.com/dts/migration

完成数据库迁移任务

完成数据库迁移任务

刷新腾讯云控制台,监控迁移完成任务状态,直到任务成功。

完成数据库迁移任务

步骤2 根据测试案例,进行云上环境的完整验证和测试,包括云数据库的写入测试。具体测试用例以实际需求为准,本章节略。

步骤3 针对测试发现的问题,评估和解决,直到全部测试用例验收通过。

步骤4 验证完成后,需清空云数据库中的测试数据,准备再次发起数据迁移。

步骤5 从5.3章节【购买与配置云数据库实例】开始,正式进行数据迁移,直到5.8.1 完成只读测试。经过数据校验一致并且只读测试通过后,可以进行第6章生产环境的切换准备。

6.生产环境切换

请选择一个合理的时间来完成业务的平滑切换,关键系统需要准备回退方案,本案例使用一次切换的方案,即业务环境与数据库环境同时进行切换。

6.1 云服务器切换前准备

步骤1 验证云上服务器访问 DB 的地址为腾讯云数据库。如果访问的是其他数据库地址,请根据如下步骤进行修改:

先登入云服务器,依次修改三个配置文件的数据库地址,使其访问云数据库:

# cd /data/wwwroot/discuz/upload/# vi ./config/config_global.php

云服务器操作示例

# cd /data/wwwroot/discuz/upload/# vi ./config/config_ucenter.php

云服务器操作示例

# cd /data/wwwroot/discuz/upload/# vi ./uc_server/data/config.inc.php

云服务器操作示例

步骤2 通过浏览器访问云服务器公网地址,验证论坛访问正常,此时目标云数据库被 DTS 设置为 read_only 状态,因此会遇到如下报错:

登入论坛操作示例

6.2 云数据库切换(此过程包含业务停机)

6.2.1 云数据库切换过程图示

云数据库割接切换图示

6.2.2 云数据库切换实施步骤

步骤1 停止对源数据库的写入(即停止业务服务)。登入源库,运行show master status,观察10分钟,确定 binlog 文件和位点没有更新,确认没有新数据写入。

设置 5.6 版本的源库为 read only 模式,禁止新数据写入,同时应避免应用帐号权限过大包含 super 权限导致写入数据(super 权限的账户,允许在 read only 模式下写入)。设置 read_only 的操作如下:set global read_only = ON;。

注意:本案例以 5.6 版本为例;如果源实例为 5.7版本,其支持设置super_read_only,禁止包括 super 权限的账户写入,更安全。

云数据库割接-源库操作示例

步骤2 关闭源库(可选)。关闭数据库可以完全杜绝任何写入操作,但是本操作为高危操作,请谨慎执行。

步骤3 断开云数据库与源库的同步。点击数据传输页面的【完成】,并点击【确定】。

注意事项:点击【完成】按钮后,源库的数据变更不会在同步到目标库中,并且不支持重新同步,请谨慎操作。

链接:https://console.cloud.tencent.com/dts/migration

云数据库割接-完成数据库迁移任务

云数据库割接-完成数据库迁移任务

步骤4 刷新腾讯云控制台,检查迁移任务的状态,直到任务成功。

云数据库割接-完成数据库迁移任务

云数据库割接-完成数据库迁移任务

此时目标库会自动切换为可读可写状态。

云数据库割接-云数据库操作示例

步骤5 登入云服务器业务环境的公网地址,验证论坛访问是否正常。

云数据库割接验证

注册一个新账号 cutover,验证写入成功。

云数据库割接验证

云数据库割接验证

步骤6 交付给 QA 进行切换后的验收测试阶段(全量测试),同时观察目标库的运行情况。验收通过之后,进行6.3章节正式业务切换,如果验收异常,那么进行6.4迁移回滚。

6.3 正式业务切换(此时业务恢复)

修改业务公网域名的 DNS 信息,指向云主机公网地址,切换正式业务的流量到云上,并观察至少 2 小时,确认业务系统和云数据库均正常运行。

业务割接图示

6.4 云数据库切换失败回滚方案(可选)

注意事项:本章节仅用于切换数据库失败场景的回滚方案。如果云数据库切换后,业务一切正常,那么不需要执行本步骤。

割接失败回滚图示

步骤1  启动源库(可选)。

如果没有执行关闭源库的动作,那么跳过此步骤。

步骤2  关闭源库只读设置,修改全局参数read_only=OFF。可以使用如下命令:

set global read_only = OFF;

割接回滚-源库操作示例

步骤3 验证测试自建 IDC 的应用可以正常访问。

割接回滚-业务验证

步骤4 进行用例测试,确保测试用例全部通过验收。

步骤5 修改业务DNS域名指向自建IDC机房应用服务器公网地址。开启业务访问,恢复业务。

步骤6 复盘切换失败原因和解决方案,并重新安排时间窗口进行云数据库迁移。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。


个人博客请访问 http://www.x0100.top  


机房迁移是一个很大的动作:


15年在58同城实施过一次(“逐日”项目),几千台物理机,从IDC迁到了腾讯的天津机房,项目做了10个多月,跨所有的部门,与所有的业务都相关;


16年在58到家又实施了一次(“凌云”项目),几百台虚拟机,从IDC迁到阿里云,前后大概一个季度的时间,也是所有技术部门都需要配合的一个大项目。


 


“单机房架构-全连”

要说机房迁移,先来看看被迁移的系统是一个什么样的架构。



上图是一个典型的互联网单机房系统架构:


(1)上游是客户端,PC浏览器或者APP;


(2)然后是站点接入层,为了面对高流量,保证架构的高可用,站点冗余了多份;


(3)接下来是服务层,服务层又分为与业务相关的业务服务,以及业务无关的基础服务,为了保证高可用,所有服务也冗余了多份;


(4)底层是数据层,数据层又分为缓存数据与数据库;


 


至于为什么要做分层架构,不是今天的重点,不做展开讨论,这是一个典型的互联网单机房分层架构:所有的应用、服务、数据是部署在同一个机房,这个架构有的一个关键词,叫做“全连”:


(1)站点层调用业务服务层,业务服务复制了多少份,上层就要连接多少个服务;


(2)业务服务层调用基础服务层,基础服务复制了多少份,上层就要连多少个服务;


(3)服务层调用数据库,从库冗余了多少份,上层就要连多少个从库;


 


比如说,站点接入层某一个应用有10台机器,业务服务层某一个服务有8层机器,那肯定是上游的10台会与下游的8台进行一个全相连的。系统架构的可用性保证,负载均衡保证,是服务的连接池去做的。不仅仅接入层连接业务服务层是这样,业务服务层连接基础服务层,服务层连接数据库也都是这样,这就是所谓的“全连”。


 


“机房迁移的目标是平滑”

单机房架构的特点是“全连”,那么机房迁移我们是要做一个什么样的事情呢?先看这张图:



之前单机房架构部署在机房A内,迁移之后仍然是单机房架构,只是换了一个B机房,做完这个迁移,有什么好的方案?最容易想到的一个方案,把所有服务在新机房全部搭一套,然后流量切过来了。


 


当系统有几千台机器,有非常非常多的业务的时候,这是一种“不成功便成仁”的方案。做技术的都知道,设计时要考虑回滚方案,如果只有上线方案而没有回滚方案,这便是一个“不成功便成仁”的方案,根据经验,不成功便成仁的操作结果,往往就“便成仁”了。


 


最重要的是,全量搭建一套再流量切换,数据层你怎么搭建一套?怎么切?数据层原来都在A机房,B机房还没有全量的数据,是没办法直接切的。要做一个数据同步的方案,最简单的,停两个小时服务,把数据从旧机房导到新机房,数据导完流量再切过去,这是一个数据迁移的简单方案。这个方案对业务有影响,需要停止服务,这个是无法接受的,何况像58同城一样有两千多台机器,无限多的数据库实例,无限多的数据表的时候,停服务迁移数据根本是不可能的。


 


所以,机房迁移的难点,是“平滑”迁移,整个过程不停服务,整体迁移方案的目标是:


(1)可以分批迁移;


(2)随时可以回滚;


(3)平滑迁移,不停服务;


 


“伪多机房架构-同连”

如果想要平滑的迁移机房,不停服务,在10个月的逐步迁移过程中,肯定存在一个中间过渡阶段,两边机房都有流量,两边机房都对外提供服务,这就是一个多机房的架构了。


 


多机房架构是什么样的架构呢?刚刚提到了单机房架构,上层连中层,中层连下层,它是一个全连的架构,能不能直接将单机房的全连架构套用到多机房呢?在另一个机房部署好站点层、服务层、数据层,直接使用“全连”的单机房架构,我们会发现:会有非常多跨机房的连接


(1)站点层连接业务服务层,一半的请求跨机房


(2)业务服务层连接基础服务层,一半的请求跨机房


(3)基础服务层连数据层(例如从库),一半的请求跨机房


 


大量的跨机房连接会带来什么样的问题呢?


我们知道,同机房连接,内网的性能损耗几乎可以忽略不计,但是一旦涉及到跨机房的访问,即使机房和机房之间有专线,访问的时延可能增加到几毫秒(跟几房间光纤距离有关)。


 


用户访问一个动态页面,需要用到很多数据,这些数据可能需要10次的业务服务层调用,业务服务层可能又有若干次基础服务层的调用,基础服务层可能又有若干次数据层的调用,假设整个过程中有20次调用,其中有一半调用跨机房,假设机房之间延迟是5毫秒,因为跨机房调用导致的请求迟延就达到了50毫秒,这个是不能接受的。


 


因此,在多机房架构设计时,要尽量避免跨机房调用(避免跨机房调用做不到,也要做到“最小化”跨机房调用),会使用“同连”的系统架构。



“同连”也很好理解,在非必须的情况下,优先连接同机房的站点与服务:


(1)站点层只连接同机房的业务服务层;


(2)业务服务层只连接同机房的基础服务层;


(3)服务层只连接同机房的“读”库;


(4)对于写库,没办法,只有跨机房读“写”库了;


 


这个方案没有完全避免跨机房调用,但其实它做到了“最小化”跨机房调用,写主库是需要跨机房的。但互联网的业务,99%都是读多写少的业务,例如百度的搜索100%是读业务,京东淘宝的电商99%的浏览搜索是读业务,只有下单支付是写业务,58同城99%帖子的列表详情查看是读业务,发布帖子是写业务,写业务比例相对少,只有这一部分请求会跨机房调用。


 


迁移机房的过程使用这样一个多机房的架构,最大的好处就是,除了“配置文件”,整个单机房的架构不需要做任何修改,这个优点是很诱人的,所有的技术部门,所有的业务线,只需要配合在新机房部署应用与服务(数据库是DBA统一部署的),然后使用不同的配置文件(如果有配置中心,这一步都省了),就能实现这个迁移过程,大大简化了迁移步骤。


 


这个方案当然也有它的不足:


(1)跨机房同步数据,会多5毫秒(举个栗子,不要叫真这个数值)延时(主从本来会有延时,这个延时会增大),这个影响的是某一个机房的数据读取;


(2)跨机房写,会多5毫秒延时,这个影响的是某一个机房的数据写入,当然这个写请求比例是很小的;


 


这个“同连”架构非常适用于做机房迁移,当然也可以用作多机房架构,用作多机房架构时,还有一个缺点:这个架构有“主机房”和“从机房”的区分。


 


多机房架构的本意是容机房故障,这个架构当出现机房故障时,例如一个机房地震了,把入口处流量切到另一个机房就能容错,不过:


(1)挂掉的是不包含数据库主库的从机房,迁移流量后直接容错;


(2)挂掉的是包含数据库主库的主机房,只迁移流量,其实系统整体99%的读请求可以容错,但1%的写请求其实会受到影响,此时需要人工介入,将从库变为主库,才能完全容错。这个过程只需要DBA介入,不需要所有业务线上游修改(除非,除非,业务线直接使用的IP连接,这个,我就不说什么了)。


 


也正是因为这个原因,在机房故障的时候,有一定概率需要少量人工介入,才能容100%的机房故障,因此这个架构才被称为“伪多机房架构”,还不是完全的“多机房多活”架构。


 


“自顶向下的机房迁移方案”

话题收回来,机房迁移的过程中,一定存在一个中间过渡阶段,两边机房都有流量,两边机房都对外提供服务的多机房架构。具体到机房的逐步迁移,又是个什么步骤呢?通常有两种方案,一种是自顶向下的迁移,一种是自底向上的迁移,这两种方案在58到家和58同城分别实行过,都是可行的,方案有类似的地方,也有很多细节不一样,因为时间关系展开说一种,在58到家实施过的“自顶向下”的机房迁移方案,整个过程是平滑的,逐步迁移的,可回滚的,对业务无影响的。


 


“站点与服务的迁移”



迁移之前当然要做一些提前准备,新机房要准备就绪,专线要准备就绪,这个是前提。


 


自顶向下的的迁移,最先迁移站点层和服务层:先在新机房,把站点层和服务层搭建好,并做充分的测试(此时数据层比如说缓存和数据库还是在原来的机房)。测试,测试,测试,只要流量没有迁移,在新机房想怎么玩都行,新机房准备的过程中,要注意“同连”,原有机房的配制文件是完全不动的,肯定也是“同连”。


 


站点层与服务层的迁移,也是一个业务一个业务的逐步迁移的,类似蚂蚁搬家。充分的测试完一个业务的站点层和服务层之后,为了求稳,先切1%的流量到新机房,观察新机房的站点与服务有没有异常,没有问题的话,再5%,10%,20%,50%,100%的逐步放量,直至第一波蚂蚁搬完家。


 


第一个业务的站点和服务迁移完之后,第二个业务、第三个业务,蚂蚁继续搬家,直至所有的业务把站点层和服务层都全流量的迁移到新机房。


 


在整个迁移的过程中,任何一个业务,任何时间点发现有问题,可以将流量切回,旧机房的站点、服务、配置都没有动过,依然能提供服务。整个迁移步骤,是比较保险的,有问题随时可以迁回来。


 


“缓存的迁移”



站点层和服务层迁移完之后,接下来我们迁数据层,数据层又分为缓存层和数据库层,先迁缓存。


 


经过第一步的迁移,所有的入口流量都已经迁到了新的机房(当然旧机房的站点和服务还是不能停,只要旧机房不停,任何时间点出问题,最坏的情况下流量迁回来),接下来迁移缓存,先在新机房要搭建好缓存,缓存的规模和体量与旧机房一样大。


 


流程上仍然是蚂蚁搬家,按照业务线逐步的迁缓存,使用同连的方式。这个缓存切换的步骤非常的简单:运维做一个缓存内网DNS的切换(内网域名不变,IP切到新机房),并杀掉原有缓存连接,业务线不需要做任何修改,只需要配合观察服务。运维杀掉原有缓存连接之后,程序会自动重连,重连上的缓存就是新机房的缓存了,bingo,迁移完毕。


 


这里要注意几个点:


(1)有些公司缓存没有使用内网域名,而是采用IP直连的话,则需要业务层配合,换新机房IP重启一下即可(如果是IP直连,说明这个架构还有改进的空间哟);


(2)这个操作尽量选在流量低峰期,旧缓存中都是热数据,而新缓存是空数据,如果选在流量高峰期,缓存切换之后,短时间内可能会有大量请求透传到数据库上去,导致数据库压力过大;


(3)这个通用步骤,适用于允许cache miss的业务场景,如果业务对缓存有高可用的要求,不允许cache miss,则需要双写缓存,或者缓存使用主从同步的架构。大部分缓存的业务场景都是允许cache miss的,少数特殊业务使用特殊的方案迁移。


 


缓存的迁移也是按照业务线,一步步蚂蚁搬家式完成的。在迁移过程中,任何一个业务,任何时间点发现有问题,可以将流量切回原来的缓存。所以迁移的过程中,不仅是站点层和服务层,旧机房的缓存层也是不停服务的,至少保证了流量迁回这个兜底方案。


 


“数据库的迁移”


站点层,服务层,缓存层都迁移完之后,最后是数据库的迁移。



数据库还是在旧机房,其他的缓存,服务,站点都迁移到新机房了,服务通过专线跨机房连数据库。


 


如何进行数据库迁移呢,首先肯定是在新机房搭建新的数据库,如果是自建的IDC机房,需要自己搭建数据库实例,58到家直接用的是阿里云的RDS。


 


搭建好数据库之后,接下来进行数据同步,自建机房可以使用数据库MM/MS架构同步,阿里云可以使用DTS同步,DTS同步有一个大坑,只能使用公网进行同步,但问题也不大,只是同步的时间比较长(不知道现能通过专线同步数据了吗?)。


 


数据库同步完之后,如何进行切换和迁移呢?能不能像缓存的迁移一样,运维改一个数据库内网DNS指向,然后切断数据库连接,让服务重连新的数据库,这样业务服务不需要改动,也不需要重启,这样可以么?


这个方式看上去很不错,但数据库的迁移没有那么理想:


第一,得保证数据库同步完成,才能切流量,但数据同步总是有迟延的,旧机房一直在不停的写如数据,何时才算同步完成呢?


第二,只有域名和端口不发生变化,才能不修改配置完成切换,但如果域名和端口(主要是端口)发生变化,是做不到不修改配置和重启的。举个例子,假设原有数据库实例端口用了5858,很吉利,而阿里云要求你使用3200,就必须改端口重启。


 


所以,我们最终的迁移方案,是DBA在旧机房的数据库设置一个read only,停止数据的写入,在秒级别,RDS同步完成之后,业务线修改数据库端口,重启连接新机房的数据库,完成数据层的切换。


 



经过上述站点、服务、缓存、数据库的迁移,我们的平滑机房的目标就这么一步步完成啦。


 


总结与问答

四十分钟很短,focus讲了几个点,希望大家有收获。


做个简要的总结:


(1)互联网单机房架构的特点,全连,站点层全连业务服务层,业务服务层全连的基础服务层,基础服务层全连数据库和缓存;


(2)多机房架构的特点,同连,接入层同连服务层,服务层同连缓存和数据库,架构设计上最大程度的减少跨机房的调用;


(3)自顶向下的机房迁移方案:先进行站点接入层、业务服务层和基础服务层的迁移,搭建服务,逐步的迁移流量;然后是缓存迁移,搭建缓存,运维修改缓存的内网DNS指向,断开旧连接,重连新缓存,完成迁移;最后数据库的迁移,搭建数据库,数据进行同步,只读,保证数据同步完成之后,修改配置,重启,完成迁移。整个过程分批迁移,一个业务线一个业务线的迁移,一块缓存一块缓存的迁移,一个数据库一个数据库的迁移,任何步骤出现问题是可以回滚的,整个过程不停服务。


 


主持人:讲的很细致,大家有什么问题吗,可以提一些问题,可以举手示意我。


提问:做数据迁移的时候,因为您讲的数据中心的都是在同一个老机房,同时又在做同步,我就在想这个数据库的压力是不是特别大。


沈剑:非常好的问题,这个地方一方面要考虑压力,更重要的是考虑跨机房的专线,风险最大的是在带宽这一部分,你在第一步迁移完之后,其实所有的缓存,数据库用其实都是跨机房的,都是通过专线去走的,这个专线带宽是需要重点考虑与评估的,数据库的压力其实还好。


 


提问:我想请教一个问题,你这个流量切换的过程中,有测试性的阶段还是直接切过去的。


沈剑:在切流量之前,肯定是有测试的,在新机房将服务搭建,在切换流量之前,测试的同学需要进行回归,回归的过程可以提前发现很多问题。逐步的切流量也是为了保证可靠性,我们不是一次性百分之百流量都切过来,先切1%的流量过来,观察服务没有问题,再逐步增大流量切换。

————————————————

版权声明:本文为CSDN博主「HelloWorld搬运工」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。

原文链接:https://blog.csdn.net/wufaliang003/article/details/78725400