Oracle云的部署和架构

本月12日,Oracle全球第20个数据中心在中国落地,和腾讯展开合作,联合为中国企业提供云服务。而今年的oow的文档,如果你关注一下下载次数,你会发现被下载最多的是关于cloud的文档,另外,拉里今年的oow2015的keynotes,大量的话题提到的都是云,我们是一家云公司。所以今天我们来谈谈云,谈谈ORACLE云的部署和架构。

首先,我们为什么需要云?大家都在谈云,都说云是趋势,云是未来,但是云的初衷,我认为是为了解决资源闲置的问题。由于IT业务,特别是互联网业务,有着很明显的有高峰和低谷,如京东的618,阿里的双十一,亚马逊的黑五等等,都是业务高峰,都需要大量的系统资源来支撑业务,而这些资源,在平时的时候,都是被闲置起来的。仅仅是在业务高峰的时候才被需要,此时传统的IT架构,堆机器的方式,就不再适合这种业务模式,我们需要一种能动态的调整资源的模式,能方便的按需加载资源,减掉资源的方式,于是,云的概念就被提了出来。我们可以在云上方便的加减资源。

那么,云的概念被提出来之后,其概念中有一个核心,就是资源共享。我们在云中是需要将资源做加减法,当我需要资源的时候,我能从别的地方把资源挪过来用,而我不需要用资源的时候,也可以把我的资源挪给别人用,这些资源是完全共享的,按需所分配的。那么,如何实现资源共享,用到的技术就是虚拟化。

那么,有了虚拟化技术,进行了资源共享,我们的云可以实现那些功能呢?大体上来说,或者目前大部分的宣传上说,云可以实现以下功能:
1. 标准化,由于在虚拟化之后,硬件不再各自为战,可以用标准化的接口统一起来,软件也是如此。
2. 低成本,由于可以对资源进行加减法,使得资源能得到有效利用,因此减低了成本。
3. 动态性,在云上建立一个主机或者删除一个主机,都是非常容易的事情,可以动态的扩展资源。不再依赖物理主机。
4. 自助性,所有操作都可以在前台页面,自助操作,点点按钮即可完成。
5. 灵活性,主机的物理位置,不一定要在某个地方,在云上选择合适的地区即可。

在最近oow15中拉里的keynotes中讲到,oracle云提供的六大目标:
1.低成本,等于或低于aws
2.高可靠,无单点故障
3.高性能,内存计算
4.标准化,支持业界开放标准
5.高兼容性,支持不同云的,自动化迁移
6.高安全性,数据和系统的实时保护

ok,了解了云的初衷,核心和功能,我们来讨论下如何一步一步的部署云。对于部署考虑到关键点,有如下:
首先,你需要考虑你采用哪一种类型的云,云的类型有公有云,私有云,和混合云。需要考虑成本,安全性等等因素。(oow2015的一些ppt中,可以看出,在传统IT架构和Oracle云架构中,oracle希望可以在oracle的公有云中放dataguard,或者Database backup cloud service,建立起原来机房的database和cloud之间的联系)
其次,你需要考虑你是否有一些数据是非结构化的数据,是否都满足ACID原则,是否在你的架构中可以放入大数据的架构,来进行处理。
再次,你需要注意,即使是上了云,云不是万能的,云不能帮你解决高可用和容灾的问题。还是需要设计云上面对HA和DR。
第四,你要考虑一下是否锁定厂商。如果锁定厂商,往往比较容易得到快速一体化的解决方案,如果决定自己干,往往需要投入大量的人力和时间进行研究和培养,但是能做到比较好的个性化适配。就ORACLE来说,ORACLE有OEM12C来提供安装和管理,ORACLE也有自己的公有云,叫Oracle onDemand,ORACLE也提供私有云的解决方案,包括Exadata的一体机,包括App on Demand(SaaS层面的),包括Exalogic Elastic Cloud(PaaS层面的),还有DBaaS。
第五,你需要考虑采用哪种的虚拟化方案。目前有本地虚拟化(Bare Metal,裸机),用的方案有vmware ESX,XenServer,Oracle VM等等,还有OS虚拟化(Containers,容器),用的方案有Vbox,Vmware workstation,Parallel Desktop等等。

基于上述的考虑点之后,我们来一步一步的迈向云端。在这里,我们分成5个阶段来做:
第一,我们需要做的事情,是合并,我们需要清楚计划或者了解有哪些服务器可以合并,哪些存储层可以合并,哪些网络设备可以合并,哪些应用可以合并。在这一步当中,也为后面如果要做DBaaS打下基础。
第二步,虚拟化。我们需要将第一步合并出来的资源,进行抽象化和虚拟化,包括服务器和存储的虚拟化,桌面虚拟化,网络服务虚拟化和应用的虚拟化。
第三步,自动化。我们需要做一些基于ITIL流程的管理,做一些多层面安全的管理,做一些基于策略的管理,做一些多层面的数据恢复。将管理任务自动化,提供网络安全,数据安全和架构保护。
第四步,建设可用率。量化和数字化服务目标,建立SLA,故障响应和审计,提供持续的可用性和failover。注:之前说的需要在云上设计HA和DR,就需要在这一步打下基础。
第五步,云来到。这这一阶段,你已经可以提供基于需求方服务,提供IaaS,Paas,SaaS,提供面向服务的架构,提供多片内部云和统一的portal管理界面。

我们再来看看云部署的目的。
按宏观上说,我们部署云是为了instance,db,server的数量,我们可以按照应用的类型来部署云,如分为SAP云,Peoplesoft云,Siebel云,客户自己的application云等等,按照环境类型来部署云,如分成Dev云,UAT云,PROD云,DR云。
从微观上说,我们需要从微观上减少物理和逻辑的数据量,如按应用去减少数据量,按照环境去减少数据量。几个反面案例,(1)一个数据库的某个schema下大部分的对象是只读对象,而这个schema是需要每天复制到多个数据库中的。此时就需要将这些只读对象分离出来。(2)一个环境中包含大量的“非标准”对象,这些对象是在开发阶段产生,带到生产环境中去了。需要清理这些对象。(3)表中有大量的列包含空值。这可能需要应用方面去修改。
结合宏观上的数量减少,和微观上的数据量减少,我们制定云部署的战略时,我们需要先考虑云的OS平台和db的版本,一开始就做好标准化,其次考虑迁移到方案,有rman的备份恢复,有exp/imp和expdp和impdp,有TTS,有ogg等等多种方式。再次考虑迁移后各个系统的隔离,如oracle 11g有instance caging功能,对非生产环境用instance caging的over provisioning,对生产环境用instance caging的partition provisioning;另外,很多OS也自带有分区功能。

最后,我们来看看云部署的关键指标:
1. 退役的数据库数量
2.合并的数据库数量
3.退役的schema数量
4.合并的schame数量
5.License成本低减少
6.退役的服务器数量
7.操作系统license费用的减少
8.存储的成本减少
9.数据中心,电力,冷却费用的减少。

那么云部署完成后,生命周期如何管理。首先,我们要考虑数据的归档和清理,归档方法有按照在网用户和历史用户区分,将在网用户的数据放高端存储,将历史用户的数据放低端存储;每月将在网用户的数据定期插入到历史用户数据中;将历史用户的数据做成只读分区;最后,还可以采用压缩表和分区的方法归档。这里需要提醒的是,数据归档是一条单行线,切忌将归档的数据再次online。
注:将历史数据做成只读分区,我们可以归档到历史表,将表设置成只读,而在12.2中,分区的特性大大加强,有只读表中带上read write分区。
12.2的分区有很多加强对功能,如:
Multi-Column ListPartitioning
Auto list Partitioning
Interval SubPartitioning
Online Partition Maintenance Operation
Online Table Conversion to Partition Table
Filtered Partitioning Maintenance Operation
Read Only Partitions
用好这些分区的特性,对于历史数据的归档非常有用。不过我们今天的主题是云,在此就不展开了。

我们之前不断的提醒,不要把云作为万能的银弹,在云上,也必须要设计HA和DR的方案。没有HA/DR,亚马逊云也一样的downtime,如在2011年4月21日,云端存储出了问题,之前没有做好HA/DR的规划,宕机时间为3天半,大量的新生互联网网站受到影响,如quora,reddit,GroupMe等等都受其影响。而在2011年8月7日,也是类似的存储故障,但是由于做好了HA/DR准备,宕机时间为3小时。(由此看出,DR是底线,从这种程度上说,DR比HA更为重要)。

HA,高可用,我们一般按照类型分为同意数据中心内部,以及不同数据中心(一般在50公里以内)。
而DR,肯定是在不同的数据中心,其间隔往往在1000公里以上,在设计时需要考虑RTO和RPO,高RTO和RPO往往意味着大量的资金的投入。在业界,常用的DR方式有physical dataguard,其同步方式受到距离限制,距离较远时,采用异步模式。另外,physical dataguard按照打开模式分,可以分为DG(passive模式,不可读,意义不大),ADG模式,在11g的ADG中,是一只读模式打开,可以进行报表查询,在12c中,ADG可以实现partial write,即利用global temporary table进行DML操作。

最后,谈一下云HA/DR的架构设计。我们一般会将整体的架构设计成两地三中心,其中本地有2个AZ(available zone),间隔50公里内,利用同步模式的dataguard做HA,primary负责跑事务,standby负责跑报表,之间用broker做fast start failover。远程有一个AZ,相距1000公里以上,利用异步模式的dataguard做DR。

要求每个中心都能独立的接受业务压力,而不是只能承担部分压力,这样在切换到时候,不会压垮。

需要配置global和local的负载均衡(如F5),用于做健康检测和故障切换。

需要配置监控,如Nagios。

需要隔离不同的域名,如跑事务的一个域名,跑报表的一个域名。

如果画成一个架构图的话,就是如下:

另外,如果有些公司不允许交叉网络,即上图中的F5交叉跨机房的检查数据库状态,我们则需要添加多一个global load balancer。见下:

以上就是关于oracle云的部署和架构。可以用这张思维导图来表示(可点击放大):

最后大家如果想要了解更多oracle云方面的知识,欢迎联系我们的销售或者售后服务团队,我们Oracle原厂的ACS(Advanced Customer Service)团队可以帮助客户做很多云方面的工作。

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注