liu 发布的文章

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


传统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


做为中小站长来说,一般购买了云服务器之后,可以自己在云服务器ECS上搭建数据库,并不需要另外购买云数据库。但是当网站的数据量规模已经大到一定程度之后,这种应用与数据库不分离的模式就会显露弊端了,会出现服务器反应迟缓卡顿现象。


 

云数据库结合云服务器使用,布局站库分离的网站,这样的站库分离模式速度更快,也减少了数据安全风险,更降低了运营成本。云数据库RDS提供高可用、高可靠、高安全、可扩展的托管数据库服务,性能等同于商业数据库,但是价格相比ECS自建数据库,仅需约1/3,相比自购服务器搭建数据库,仅需约1/10。云数据库与自建数据库的成本比较,请看以下对比表:

价格对比

 

费用云数据库RDSECS自建数据库自购服务器搭建数据库

硬件费用和备品配件费用RDS实例的费用。例如,2 CPU、4 GB内存、存储空间 100 GB(IOPS能力可达到6800)的实例费用是8000元/年。至少需要2台ECS实例作为主备实例。2台2 CPU、4 GB内存、存储空间 100 GB(IOPS能力可达到6800)的ECS实例费用是6800元/年。

至少需要2台数据库服务器。每台IOPS能力达到6800的服务器费用大约是8000元。

1台用于连接前端Web服务器的内网交换机(便宜的1U非网管交换机为1000元左右)。

后期硬件损坏和更换至少还要消耗30%费用。

硬件花费:(8000 × 2 + 1000)× 130% = 22100元。

每年费用:22100元/3 = 7366元(硬件按照3年折旧计算)。


机房托管费用服务商负责,无需付费。服务商负责,无需付费。1U机柜空间托管费用为3000元/年,共有2台1U服务器和1台1U内网交换机需要计费,机房托管费用:3000 × 3 = 9000元。

带宽费用

同一地域内,ECS和RDS可以通过内网互通,且不收取费用。

若在不同地域,ECS和RDS可以通过外网互通,需收取外网流量费用,详细收费标准请参见云数据库RDS详细价格信息。

同一地域内,ECS实例之间可以通过内网互通,不收取费用。

若在不同地域,ECS实例之间可以通过外网互通,需收取外网流量费用,详细收费标准请参见公网带宽计费方式。

只用于内网,不产生公网费用。

数据库运维工程师费用数据库维护由服务商负责,无人员成本。1个初级DBA工程师月薪至少5000/月,假设当前项目占用该工程师30%的工作量,则人员成本为5000 × 12× 30% = 18000元。1个初级DBA工程师月薪至少5000/月,假设当前项目占用该工程师30%的工作量,则人员成本为5000 × 12× 30% = 18000元。

每年总费用8000元/年24800元/年34366元/年

RDS MySQL与自建数据库对比优势

 

对比项RDS MySQLECS自建自购服务器搭建数据库

性价比

弹性资源。

ALISQL提供各种特性功能,提升用户使用感受。

备份有一半实例空间免费。

公网流量免费。

免费使用自带的域名。

更新速度快,紧跟MySQL最新版本。

弹性资源。

开源版无性能优化。

备份空间独立收费。

公网流量收费。

一次投入的沉没成本大。

开源版无性能优化。

需要独立准备备份资源,成本极高。

公网流量收费,域名费用高。

可用性

基础版约15分钟即可完成故障转移。

高可用版和集群版提供自研高可用系统,实现30秒内故障恢复。

只读实例自动实现负载均衡。

读写分离使用方便。

未来会推出分析节点,满足分析型场景需求。

基础版约30分钟完成故障转移。

需要单独购买高可用系统。

需要单独实现或者购买负载均衡服务。

分析型场景需要与分析型数据库结合,搭建难度大、成本高。

单机实例,少则两小时,多则等待配货数周。

需要单独购买高可用系统。

需要单独实现或者购买负载均衡设备。

分析型场景需要与分析型数据库结合,搭建难度大、成本高。

可靠性

数据可靠性高,自动主备复制、数据备份、日志备份等。

MySQL 5.6三节点企业版,实现RPO(Recovery Point Object)=0。

MySQL 5.7三节点企业版(MGR),实现RPO=0、RTO(Recovery Time Objective) < 1分钟。

在好的架构下才能实现高可靠性。

实现RPO=0的成本极高,需要单独购买研发服务。

数据可靠性一般,取决于单块磁盘的损害概率。

实现RPO=0的成本极高,需要单独购买研发服务。

易用性

自动化备份恢复系统,支持按时间点恢复、单库备份恢复等,流式备份对实例性能影响小。

自动化监控告警系统,支持秒级监控,覆盖实例和数据库所有性能指标,支持短信、邮箱、旺旺、钉钉等通道,且根据消费有大额度的免费短信数量。

支持异地容灾。

支持一键版本升级。

无自动备份系统,流式备份能力需要单独实现,实现按时间点恢复功能成本高。

需要单独购买监控系统,在云监控中配置告警系统。

技术实现难度极大。

版本升级成本高。

无自动备份系统,流式备份能力需要单独实现,实现按时间点恢复功能成本高。

需要单独购买或配置监控系统,通道较少,成本较高。

异地数据中心成本极高,技术实现难度也大,很难实现异地容灾。

版本升级成本高。

性能

MySQL的本地SSD盘实例性能极佳。

MySQL的ESSD性能较SSD提升显著。

增加只读实例之后性能强劲且负载均衡。

CloudDBA提供高级优化能力。

SQL洞察满足大部分监控及性能优化数据库场景。

ECS本地盘意味着降低数据可靠性,采用云盘需要规划架构,成本支出较大。

基于ESSD的ECS自建MySQL性能低于基于ESSD的RDS MySQL性能。

实现集群版的难度较高,咨询成本较高,维护成本极高。

依赖资深DBA,支出大,受制于人。

比云计算硬件更新速度慢,性能一般都会低于云数据库。

难以实现计算和存储分离,若使用高端存储实现计算和存储分离,动辄需要数千万支出。

实现集群版的难度较高,咨询成本较高,维护成本极高。

依赖资深DBA,支出大,受制于人。

安全

事前防护:白名单、安全组、专有网络隔离。

事中保护:连接链路加密、数据落盘加密(BYOK覆盖多种存储介质)。

事后审计:SQL洞察、历史事件。

事前防护:白名单、安全组、专有网络隔离。

事中保护:需要单独实现连接链路加密和数据落盘加密,BYOK密钥轮转难度大,咨询成本较高。

事后审计:审计困难,需要单独保存SQL日志。

事前防护:白名单和专有网络隔离的咨询成本较高。

事中保护:需要单独实现连接链路加密和数据落盘加密,BYOK密钥轮转难度大,咨询成本较高。

事后审计:审计困难,需要单独保存SQL日志。

RDS SQL Server与自建数据库对比优势

 

对比项RDS SQL ServerECS自建自购服务器搭建数据库

性价比

弹性资源。

WEB版性价比极高。

备份有一半实例空间免费。

公网流量免费。

弹性资源。

不可使用WEB版。

备份空间独立收费。

公网流量收费。

一次投入的沉没成本大。

不可使用WEB版。

需要独立准备备份资源,成本极高。

公网流量收费,域名费用高。

可用性

基础版约15分钟即可完成故障转移。

高可用版和集群版提供自研高可用系统,实现30秒内故障恢复。

集群版的只读实例自动实现负载均衡。

集群版的读写分离使用方便。

基础版约30分钟完成故障转移。

需要单独购买高可用系统。

需要单独实现或者购买负载均衡服务。

单机实例,少则两小时,多则等待配货数周。

需要单独购买高可用系统。

需要单独实现或者购买负载均衡设备。

可靠性

数据可靠性高,自动主备复制、数据备份、日志备份等。

集群版可实现RPO(Recovery Point Object)=0。

在好的架构下才能实现高可靠性。

实现RPO=0的成本极高,需要单独购买研发服务。

数据可靠性一般,取决于单块磁盘的损害概率。

实现RPO=0的成本极高,需要单独购买研发服务。

易用性

自动化备份恢复系统,支持按时间点恢复、单库备份恢复等,流式备份对实例性能影响小。

自动化监控告警系统,支持秒级监控,覆盖实例和数据库所有性能指标,支持短信、邮箱、旺旺、钉钉等通道,且根据消费有大额度的免费短信数量。

即将支持异地容灾。

无自动备份系统,流式备份能力需要单独实现,实现按时间点恢复功能成本高。

需要单独购买监控系统,在云监控中配置告警系统。

技术实现难度极大。

无自动备份系统,流式备份能力需要单独实现,实现按时间点恢复功能成本高。

需要单独购买或配置监控系统,通道较少,成本较高。

异地数据中心成本极高,技术实现难度也大,很难实现异地容灾。

性能

SQL Server 2008 R2的本地SSD盘实例性能极佳,SQL Server 201x版本新计算存储分离架构可享受硬件红利 。

SQL Server的ESSD性能较SSD提升显著。

增加只读实例之后性能强劲且负载均衡。

CloudDBA提供高级优化能力。

ECS本地盘意味着降低数据可靠性,采用云盘需要规划架构,成本支出较大。

基于ESSD的ECS自建SQL Server性能低于基于ESSD的RDS SQL Server性能。

实现集群版的难度较高,咨询成本较高,维护成本极高。

依赖资深DBA,支出大,受制于人。

比云计算硬件更新速度慢,性能一般都会低于云数据库。

难以实现计算和存储分离,若使用高端存储实现计算和存储分离,动辄需要数千万支出。

实现集群版的难度较高,咨询成本较高,维护成本极高。

依赖资深DBA,支出大,受制于人。

安全

事前防护:白名单、专有网络隔离。

事中保护:连接链路加密、数据落盘加密。

事后审计:SQL审计(数据库审计)、历史事件。

微软安全更新,阿里技术兜底。

事前防护:白名单、安全组、专有网络隔离。

事中保护:需要单独实现连接链路加密和数据落盘加密,咨询成本较高。

事后审计:审计困难,需要单独保存SQL日志。

事前防护:白名单和专有网络隔离的咨询成本较高。

事中保护:需要单独实现连接链路加密和数据落盘加密,咨询成本较高。

事后审计:审计困难,需要单独保存SQL日志。

法律

附带License,无法律风险。

即将支持自带License,降低整体成本支出。

只有单独购买License。只有单独购买License,否则法律风险极大。

RDS PostgreSQL与自建数据库对比优势

 

对比项RDS PostgreSQLECS自建自购服务器搭建数据库

性价比

弹性资源。

内核优化,提供各种特性功能,提升用户使用感受。

备份有一半实例空间免费。

公网流量免费。

免费使用自带的域名。

更新速度快,紧跟PostgreSQL最新版本。

弹性资源。

开源版无性能优化。

备份空间独立收费。

公网流量收费。

一次投入的沉没成本大。

开源版无性能优化。

需要独立准备备份资源,成本极高。

公网流量收费,域名费用高。

可用性

基础版约15分钟即可完成故障转移。

高可用版提供自研高可用系统,实现30秒内故障恢复。

只读实例自动实现负载均衡。

基础版约30分钟完成故障转移。

需要单独购买高可用系统。

需要单独实现或者购买负载均衡服务。

单机实例,少则两小时,多则等待配货数周。

需要单独购买高可用系统。

需要单独实现或者购买负载均衡设备。

可靠性

数据可靠性高,自动主备复制、数据备份、日志备份等。

支持设置保护级别,最高RPO=0。

在好的架构下才能实现高可靠性。

实现RPO=0的成本极高,需要单独购买研发服务。

数据可靠性一般,取决于单块磁盘的损害概率。

实现RPO=0的成本极高,需要单独购买研发服务。

易用性

自动化备份恢复系统,支持按时间点恢复、单库备份恢复等,流式备份对实例性能影响小。

自动化监控告警系统,覆盖实例和数据库所有性能指标,支持短信、邮箱、旺旺、钉钉等通道,且根据消费有大额度的免费短信数量。

无自动备份系统,流式备份能力需要单独实现,实现按时间点恢复功能成本高。

需要单独购买监控系统,在云监控中配置告警系统。

无自动备份系统,流式备份能力需要单独实现,实现按时间点恢复功能成本高。

需要单独购买或配置监控系统,通道较少,成本较高。

性能

PostgreSQL的本地SSD盘实例性能极佳。

PostgreSQL的ESSD性能较SSD提升显著。

增加只读实例之后性能强劲且负载均衡。

CloudDBA提供高级优化能力。

SQL审计(数据库审计)满足大部分监控及性能优化数据库场景。

ECS本地盘意味着降低数据可靠性,采用云盘需要规划架构,成本支出较大。

基于ESSD的ECS自建PostgreSQL性能低于基于ESSD的RDS PostgreSQL性能。

依赖资深DBA,支出大,受制于人。

比云计算硬件更新速度慢,性能一般都会低于云数据库。

难以实现计算和存储分离,若使用高端存储实现计算和存储分离,动辄需要数千万支出。

依赖资深DBA,支出大,受制于人。

安全

事前防护:白名单、安全组、专有网络隔离。

事中保护:连接链路加密、云盘加密。

事后审计:SQL审计(数据库审计)、历史事件。

事前防护:白名单、安全组、专有网络隔离。

事中保护:需要单独实现连接链路加密。

事后审计:审计困难,需要单独保存SQL日志。

事前防护:白名单和专有网络隔离的咨询成本较高。

事中保护:需要单独实现连接链路加密。

事后审计:审计困难,需要单独保存SQL日志。

综合上面的对比表格,尊托云数给大家总结一下云数据库与传统自建数据库的对比如下:


1.       服务可用性:    在服务可用性方面,云数据库RDS是99.95%可用的;而在自购服务器搭建的传统数据库服务中,需自行保障, 自行搭建主从复制,自建RAID等。 


2.       数据可靠性:    对数据的可靠性来说,云数据库RDS是保证99.9999%可靠的;而在自购服务器搭建的传统数据库服务中,需自行保障, 自行搭建主从复制,自建RAID等。


3.       系统安全性:    云数据库RDS可防DDoS攻击,流量清洗,能及时有效地修复各种数据库安全漏洞,而在自购服务器搭建的传统数据库,则需自行部署,价格高昂,同时也需自行修复数据库安全漏洞。


4.       数据库备份:   云数据库RDS可自动为数据库进行备份,而自购服务器搭建的传统数据库需自行实现,同时需要寻找备份存放空间以及定期验证备份是否可恢复。


5.       软硬件投入:   云数据库RDS无软硬件投入,并按需付费;而自购服务器搭建的传统数据库服务器成本相对较高,对于SQL Server需支付许可证费用。


6.       系统托管:    云数据库RDS无需托管费用,而自购服务器搭建的传统数据库每台2U服务器每年超过5000元(如果需要主从,两台服务器需超过10000元/年)。


7.       维护成本:    云数据库RDS无需运维,而自购服务器搭建的传统数据库需招聘专职DBA来维护,花费大量人力成本。


8.       部署扩容:    云数据库RDS即时开通,快速部署,弹性扩容,按需开通,而自购服务器搭建的传统数据库需硬件采购、机房托管、部署机器等工作,周期较长。


9.       资源利用率:    云数据库RDS按实际结算,100%利用率,而自购服务器搭建的传统数据库需考虑峰值,资源利用率很低。


现在大的云计算服务商都有提供云数据库产品,比如:腾讯云云数据库、阿里云云数据库、华为云云数据库等等(正在进行的品牌云数据库1折抢购活动可进入尊托云数:9i0i.com了解详情)。大型网站应用有必要购买云数据库,有利于网站的健康稳定运营及长期发展。一般需要云数据库的行业应用场景主要有:电商/金融类网站、游戏数据缓存、大数据计算,连接大数据存储、计算和可视化引擎等。

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

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

原文链接:https://blog.csdn.net/xtyly1/article/details/107154098/


作者:华为云开发者社区
链接:https://www.zhihu.com/question/19656397/answer/492063096
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

云服务器和传统服务器的区别主要是:

云服务器是实现软硬件解耦的,通常是部署在虑拟化平台之上的,对外提供的是一个服务,用户可以像使用自来水一样方便来使用,实现一个按需收费的特点。而传统服务器软件是强依赖于硬件设备的,用户需一次买断其使用权,是独享的。

总结几点:

a、稳定:云服务器ECS,实例可用性达99.95%,数据可靠性不低于99.999%,自动宕机迁移,自动快照备份,数据恢复更方便。

传统服务器,传统服务器受限于硬件可靠性,易出问题。需手工备份,人工数据恢复困难、耗时

b、弹性:云服务器ECS,自由配置CPU、内存、带宽,可随时升级,升级配置数据不丢失,业务暂停时间可控

传统服务器,固定配置,难以满足各类需求,改配置需硬件升级,周期长,服务停止时间不可控

c、安全:云服务器ECS,免费提供DDoS防护、木马查杀、防暴力破解等服务,可轻松实现多用户对多服务器的访问控制

传統服务器,需额外购买、部署各种安全措施,基本上做不到多用户对多服务器访问控制

d、成本:云服务器ECS,高性价比,支持包年包月或按量计费,满足不同需求,无需服务器网络和硬件等维护,0成本运维

传统服务器,租用费用高,只能包年包月购买,大量人员负责机器运维,成本高

e、易用性:云服务器ECS,丰富的操作系统和应用软件,通过镜像可一键简单部署,同一镜像可在多台ECS中快速复制环境,轻松扩展

传统服务器,几乎不提供任何软件支持,新增服务器需人工重复所有的部署操作

f、可拓展性:云服务器ECS,ECS可与华为云各种丰富的云产品无缝衔接,可持续为业务发展提供完整的计算、存储、安全等解决方案

传统服务器,很难在同一服务商內找到完整的服务,不能保证业务増长的可扩展性和持续性

更多精彩内容可以关注 华为云技术宅基地


https://max.book118.com/html/2018/0502/164325853.shtm