数据中心高可靠性方案
议程
新一代数据中心高可靠性管理热点探析
如何实现新一代数据中心高可靠性管理技术研究与案例分享
12
3
数据中心发展趋势与目标
简化
标准化的技术
架构复杂性
IT 竖井
全面云计算
云共享的服务
敏捷
高效
整合的平台
业务模块化
标准化
集中化
服务化
目前数据中心关注点之一：通过整合提升资源利用率5% -10% 60% -70%
烟囱式架构-低效的资源管理
整合架构-动态负载管理
目前数据中心关注点之二：通过池化实现共享敏捷性
共享
应用A, B, C, D, E
如果利用率太高，则自动增加处理能力；
如果利用率太低，则自动释放处理能力
Server A Server B Server C Server D
按需伸缩
数据中心整合与池化共享的隐忧思考——可靠性？
数据泄露了怎么办？
怎么有效保护数据安全？
宕机了怎么办？
怎么保障业务连续性？
自然灾害不是导致业务中断的主要原因
头号可能的泄露数据源
数据库服务器占泄露
记录总数的92%，
数据库安全成为安全
体系建设的关键所在！
数据泄露调查报告
支撑数据中心高可靠管理的两大基石
池化共享
整合共享
高可用高安全
为什么是数据库？
60%以上的可用性/性能故障与90%以上的数据泄漏都与数据库有直接关系
对业务影响度
运维工作量要求
网络
主机
存储
应用服务器
数据库
机房
更高稳定性更高可用性
压力可分散
单点
数据中心高可靠性管理的基石：高可用数据库不可用=>业务不可用，一切都无从谈起
传统的高可用系统
灾备专用存储阵列
灾备系统
第3方文件系统/卷管理器…
第3方备份&带库管理软件…
第3方冷故障切换集群…
专用存储阵列
热备服务器
生产服务器
生产中心
灾备中心
存储远程镜像…
?显著的网络消耗：高昂的网络带宽费用支出?
不保证数据复制质量：数据块坏会传递到目的端
不支持快速切换：日常处于冷备状态，切换过程复杂
?设备利用率低：日常处于冷备状况，不能分担生产任务
?资源共享性差：应用均为独立主机部署，专用资源不能支援其他应用及开发、测试等活动
?切换失败风险：灾备切换演练缺乏常态化，只有真正切换了才知道是否可用，仅能满足监管要求的最低要求?灾难恢复能力有限：灾备系统配置一般较低，约为生产的一半
缺乏专业化运维支撑：生产与灾备运维人员重复，无法有效管理，轻灾备现象严重
Oracle高可用技术三剑客
真实应用集群
RAC
活动数据卫士
Active Data Guard
数据库复制
GoldenGate
真实应用集群RAC
最基本、最有效、最可靠、多活的高可用技术；事实标准
?支持业务连续性
与高可用
?可伸缩与敏捷性
?自动负载均衡
?自动存储管理
100%的重要系统数据库都是RAC架构。
除非你的系统真的不那么重要。
活动数据卫士ADG
?完全一致，灾备最佳?目标可读，实现双活?坏块自动修复
?零数据丢失
?计划宕机时间最小化（滚动升级）
案例分享：富国银行利用RAC/ADG实现高可用+双活
数据库复制GoldenGate ?关键系统的连续性
保障
–零宕机操作
–灾难恢复与数据保护
–数据分发
–查询卸载
?企业内部数据实时
集成
–实时数据仓库
–运营报表卸载
案例分享：某某海关利用GG实现高可用、数据交换、数据集中等复杂需求
最大化高可用性：多技术融合
Oracle 公有云的高可用设计最佳实践
数据中心高可用
?
灾备环境部署在与主数据中心同属地理区域和法律管辖范围的地点，并与主数据中心按对称策略配置
互联网接入服务商高可用
?
配置与多个ISP 多路对等地位免费互联协议，确保一个或多个ISP 网络故障不影响用户访问的连续性存储高可用
?所有类型的存储都被设计成两倍或三倍冗余
网络高可用
?所有网络部件–防火墙，负载均衡器，交换机和路由器–都被设计成全双路冗余
?
为应对数据中心失效，还使用了全局DNS 提供商的高可用DNS 服务
数据库高可用
?所有生产数据库都配置成多节点active-active RAC 集群?同时还配置了Active Data Guard 异地灾备应用中间件层高可用
?
所有生产中间件层都配置成多节点状态实时复制的active-active 应用服务器集群
?
同时使用Oracle Site Guard 提供应用灾备，并使用DataGuard 与异地灾备同步
专业运营团队
?
数据中心的云服务都由指定的同属法律管辖范围的专业团队运营，Oracle 避免跨地域的交叉运营团队以避免从远程运营中心对云服务发起过失操作
隐私和法务培训
?
不同的国家会有不同的数据存放和相应运营的法律要求，因此，Oracle 公有云会给每个数据中心的运营团队进行培训，以满足当地法规的合规性要求
数据中心高可靠性管理的基石：高安全敏感数据泄漏？乌纱帽不保