现代云数据中心服务器架构选型
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
以可用性为第一 简单
从执行层面分析，当前可以重点从以下几个方面进行业务转型：
（1）真正以客户为中心，提升客户体验 （2）全渠道接触，贴近客户，增强客户黏性 （3）推动数字化运营，向数据要效益
3
4
互联网IT架构的发展对传统行业的启示
传统企业和互联网公司的业务需求差异
传统企业业务需求
互联网企业业务需求
应可用可
• 模块化组合
布式的应用架构实现，服务实体可以横向伸
模靠块靠
• 灵活扩展，快速部署， 缩
化性再性 到要资要
水平伸缩
关键应 用资源
池
一般应用 资源池
存储
资源
…
池
源求池求
化
基础架构云化：实现资源的精确供给、动态
伸缩、快速应用部署、自动化运维
7
Agenda
• 传统企业的互联网＋之路 • 分布式架构转型之路 • 服务器平台如何选型 • 经验分享
非结构化数据很多 IT设计可以影响或引
计关系 读写比例
7：3或8：2
导业务需求 10：1以上
业务需求的巨大差异必然带来IT架构设计的迥异
4
5
“互联网+”时代的业务系统对IT基础架构提出多样化的要求
核心交易系统
• 智能资源调配 • 应用快速部署 • 架构灵活扩展 • 业务持续运行
分析洞察系统
• 海量数据处理 • 实时分析响应 • 数据安全合规 • 软件定义架构
Time
Slave节点:750MHz CPU
4
8
12
并行计算后的Time Overhead：
•Mater节点任务分解和汇总的开销 •各节点通信的开销 •子任务启动和停止的系统开销 •长尾子任务的延时开销
以上对比假设原始任务可以分解为任意多 个可以并行的子任务
Time 并行计算后的Cost Overhead：
6
传统IT架构向互联网架构学习转变思路
• 纵向解耦、横向分层
自顶上顶
• SOA化，构建统一服务 层
对外服务SOA化：梳理服务类型和接口，实 现对外服务的标准化，和能力的对外开放
而层下层 的设设设 计 从计，计服
• 分布式架构
实务 S实现O现A
• 轻量级中间件
化高到高
应用逻辑模块化：将标准化的服务，使用分
• CAP理论告诉我们集群系统状态下 如果数据不共享，必须要牺牲A（可 用性）或者C（一致性）的其中一个 。
• 支付业务属于高并发、高可用性要 求和高一致性的典型应用，其数据 库只能采用共享式集群架构。
Oracle RAC架构
• Oracle RAC为典型的集中共享式集群，所有节点共享一份数据，节点间通 过网卡高速交换内存数据，保证状态一致性，并通过共享磁盘保证持久化 数据一致性
现代云数据中心服务器架构选型
Agenda
• 传统企业的互联网＋之路 • 分布式架构转型之路 • 服务器平台如何选型 • 经验分享
33
互联网＋时代传统行业如何转型
以运营商为例：传统电信运营商 业务套餐复杂，内容僵化且计费 成本高，使用体验差。未来电信 业务的转型可多向互联网业务学 习以用户体验为中心的业务设计 模式，简化业务规则、简化系统 设计难度并尝试后向收费模式。
业务设计核心 目标 业务规则 业务套餐设计
业务计费方式 业务体验
业务流程设计 计费规则
运营商传统业务
以流程为中心
组合业务多，规则复杂 内部人员设计，一般不能 用户定制 前向收费为主 业务体验与资费基本无法 挂钩 以安全性为第一 复杂
互联网业务
以用户体验为中心
单品业务多，规则简单 开放给用户灵活定制
后向收费为主 业务体验与资费直接对应
互动参与系统
• 设备无缝接入 • 安全可控至上 • 敏捷开发迭代 • 开放互联协作
5
混合IT架构将成为企业IT架构新常态
记录系统
CRM
HR
DB
ERP
企业混合IT环境
私有云
公有云
+
交互系统、洞察系统
应用
传感器
设备
传统IT
混合IT – 将现有技术与新兴技术相融合，协助
企业满足并超出客户日益增长的需求与期望
High Performance Efficiency
Industry Affiliation
Scalability
Data Capabilities
Security
Reliability and Availability
Advanced Virtualization
Automation Mature and Growth Markets Large Scale Adoption
99
分布式计算一定强？
分布式计算的Trade-off
原始任务 1 2 3 4 5 6 7 8 9 10 11 12
Master节点:750MHz CPU
Slave节点:750MHz CPU
1
5
9Βιβλιοθήκη Baidu
Slave节点:750MHz CPU
2
6
10
4Ghz CPU
Slave节点:750MHz CPU
3
7
11
9
分布式架构要牺牲可用性或一致性
美国加州.伯克利大学Eric Brewer教授提出CAP理论 -一 个分布式系统不可能 同时满足一致性、可用性 和分区容忍性这三项需求, 最多同时只能 满足其中两 项。因此集中式处理方式 更适用于要求数据完整性 核心帐务交易处理
10
系统分布化的难点：事物交易系统
为什么OLTP在线交易数据库集群要采用共享式架构？
• Oracle RAC适合对数据一致性和可用性要求很高的支付应用 • 其架构横向扩展困难，需要纵向扩展 • Oracle RAC对系统硬件（CPU、内存、IO板卡、磁盘）均有极高的可靠性
要求，任何轻微的硬件故障均可能导致Oracle重启
11
进行分布式架构转变需要考虑的问题
可用性：小型机存储的高冗余机制,PC和MySQL能否做到 一致性：Oracle物理级别一致性,MySQL有没有问题(语句模式) 高性能：高端小机存储的性能和IO能力很强,PC能否顶得过；MySQL和Oracle对SQL的处理性能是否相同 扩展性：分多少库分多少表,什么维度分 – 后期二次拆分如何更方便
系统设计目标优 可用性第一
先级
安全和业务一致性第
二
安全和业务一致性第 二 可用性第二
业务流程
长流程、复杂流程多 短流程组合为主
事务复杂性
复杂事物多
基本没有复杂事物
性能要求
业务并发变化小，一 业务并发变化大，要
般可以提前预估性能 求系统能够快速响应
变化
性能伸缩
数据类型
以结构化数据为主
业务需求和IT设 业务需求主导IT设计
•更多的节点==更多的附属不可压缩成本(线缆、磁盘、端口、空间) •更多的节点和OS==更多的运维成本 •更多的节点和OS==更多的系统开销(OS系统常驻内存、系统进程) •更多的节点==更难的资源均衡和更低的平均资源利用率 •并行计算需要更多的软件优化和开发成本 •更多的节点==更高的子任务长尾概率
从执行层面分析，当前可以重点从以下几个方面进行业务转型：
（1）真正以客户为中心，提升客户体验 （2）全渠道接触，贴近客户，增强客户黏性 （3）推动数字化运营，向数据要效益
3
4
互联网IT架构的发展对传统行业的启示
传统企业和互联网公司的业务需求差异
传统企业业务需求
互联网企业业务需求
应可用可
• 模块化组合
布式的应用架构实现，服务实体可以横向伸
模靠块靠
• 灵活扩展，快速部署， 缩
化性再性 到要资要
水平伸缩
关键应 用资源
池
一般应用 资源池
存储
资源
…
池
源求池求
化
基础架构云化：实现资源的精确供给、动态
伸缩、快速应用部署、自动化运维
7
Agenda
• 传统企业的互联网＋之路 • 分布式架构转型之路 • 服务器平台如何选型 • 经验分享
非结构化数据很多 IT设计可以影响或引
计关系 读写比例
7：3或8：2
导业务需求 10：1以上
业务需求的巨大差异必然带来IT架构设计的迥异
4
5
“互联网+”时代的业务系统对IT基础架构提出多样化的要求
核心交易系统
• 智能资源调配 • 应用快速部署 • 架构灵活扩展 • 业务持续运行
分析洞察系统
• 海量数据处理 • 实时分析响应 • 数据安全合规 • 软件定义架构
Time
Slave节点:750MHz CPU
4
8
12
并行计算后的Time Overhead：
•Mater节点任务分解和汇总的开销 •各节点通信的开销 •子任务启动和停止的系统开销 •长尾子任务的延时开销
以上对比假设原始任务可以分解为任意多 个可以并行的子任务
Time 并行计算后的Cost Overhead：
6
传统IT架构向互联网架构学习转变思路
• 纵向解耦、横向分层
自顶上顶
• SOA化，构建统一服务 层
对外服务SOA化：梳理服务类型和接口，实 现对外服务的标准化，和能力的对外开放
而层下层 的设设设 计 从计，计服
• 分布式架构
实务 S实现O现A
• 轻量级中间件
化高到高
应用逻辑模块化：将标准化的服务，使用分
• CAP理论告诉我们集群系统状态下 如果数据不共享，必须要牺牲A（可 用性）或者C（一致性）的其中一个 。
• 支付业务属于高并发、高可用性要 求和高一致性的典型应用，其数据 库只能采用共享式集群架构。
Oracle RAC架构
• Oracle RAC为典型的集中共享式集群，所有节点共享一份数据，节点间通 过网卡高速交换内存数据，保证状态一致性，并通过共享磁盘保证持久化 数据一致性
现代云数据中心服务器架构选型
Agenda
• 传统企业的互联网＋之路 • 分布式架构转型之路 • 服务器平台如何选型 • 经验分享
33
互联网＋时代传统行业如何转型
以运营商为例：传统电信运营商 业务套餐复杂，内容僵化且计费 成本高，使用体验差。未来电信 业务的转型可多向互联网业务学 习以用户体验为中心的业务设计 模式，简化业务规则、简化系统 设计难度并尝试后向收费模式。
业务设计核心 目标 业务规则 业务套餐设计
业务计费方式 业务体验
业务流程设计 计费规则
运营商传统业务
以流程为中心
组合业务多，规则复杂 内部人员设计，一般不能 用户定制 前向收费为主 业务体验与资费基本无法 挂钩 以安全性为第一 复杂
互联网业务
以用户体验为中心
单品业务多，规则简单 开放给用户灵活定制
后向收费为主 业务体验与资费直接对应
互动参与系统
• 设备无缝接入 • 安全可控至上 • 敏捷开发迭代 • 开放互联协作
5
混合IT架构将成为企业IT架构新常态
记录系统
CRM
HR
DB
ERP
企业混合IT环境
私有云
公有云
+
交互系统、洞察系统
应用
传感器
设备
传统IT
混合IT – 将现有技术与新兴技术相融合，协助
企业满足并超出客户日益增长的需求与期望
High Performance Efficiency
Industry Affiliation
Scalability
Data Capabilities
Security
Reliability and Availability
Advanced Virtualization
Automation Mature and Growth Markets Large Scale Adoption
99
分布式计算一定强？
分布式计算的Trade-off
原始任务 1 2 3 4 5 6 7 8 9 10 11 12
Master节点:750MHz CPU
Slave节点:750MHz CPU
1
5
9Βιβλιοθήκη Baidu
Slave节点:750MHz CPU
2
6
10
4Ghz CPU
Slave节点:750MHz CPU
3
7
11
9
分布式架构要牺牲可用性或一致性
美国加州.伯克利大学Eric Brewer教授提出CAP理论 -一 个分布式系统不可能 同时满足一致性、可用性 和分区容忍性这三项需求, 最多同时只能 满足其中两 项。因此集中式处理方式 更适用于要求数据完整性 核心帐务交易处理
10
系统分布化的难点：事物交易系统
为什么OLTP在线交易数据库集群要采用共享式架构？
• Oracle RAC适合对数据一致性和可用性要求很高的支付应用 • 其架构横向扩展困难，需要纵向扩展 • Oracle RAC对系统硬件（CPU、内存、IO板卡、磁盘）均有极高的可靠性
要求，任何轻微的硬件故障均可能导致Oracle重启
11
进行分布式架构转变需要考虑的问题
可用性：小型机存储的高冗余机制,PC和MySQL能否做到 一致性：Oracle物理级别一致性,MySQL有没有问题(语句模式) 高性能：高端小机存储的性能和IO能力很强,PC能否顶得过；MySQL和Oracle对SQL的处理性能是否相同 扩展性：分多少库分多少表,什么维度分 – 后期二次拆分如何更方便
系统设计目标优 可用性第一
先级
安全和业务一致性第
二
安全和业务一致性第 二 可用性第二
业务流程
长流程、复杂流程多 短流程组合为主
事务复杂性
复杂事物多
基本没有复杂事物
性能要求
业务并发变化小，一 业务并发变化大，要
般可以提前预估性能 求系统能够快速响应
变化
性能伸缩
数据类型
以结构化数据为主
业务需求和IT设 业务需求主导IT设计
•更多的节点==更多的附属不可压缩成本(线缆、磁盘、端口、空间) •更多的节点和OS==更多的运维成本 •更多的节点和OS==更多的系统开销(OS系统常驻内存、系统进程) •更多的节点==更难的资源均衡和更低的平均资源利用率 •并行计算需要更多的软件优化和开发成本 •更多的节点==更高的子任务长尾概率