Oracle云的部署和架构
11月24日，Oracle ACS华南区售后团队首席技术工程师何剑敏（小荷）老师，在DBA+深圳群进行了一次主题为“Oracle云的部署和架构”的线上分享。小编特别整理出其中精华内容，供大家学习交流。同时，也非常感谢何剑敏老师对DBA+社群给予的大力支持。
DBA+社群深圳发起人，网名：小荷
曾供职于中国联通信息计费部、卓望数码，系统支撑部首席DBA，负责中国移动全网梦网业务数据库维护和负责移动应用商城（MOBILE MARKET）数据库维护
后供职于IBM，负责米其林项目和澳洲电信（Telstra）项目的ORACLE数据库管理
现供职于Oracle ACS华南区售后团队，首席技术工程师
多年从事第一线的数据库运维工作，有丰富项目经验、维护经验和调优经验，专注于数据库的整体运维
本月12日，Oracle全球第20个数据中心在中国落地，和腾讯展开合作，联合为中国企业提供云服务。而今年的OOW的文档，如果你关注一下下载次数，你会发现被下载最多的是关于cloud的文档，另外，拉里今年的OOW2015的keynotes，大量的话题提到的都是云，我们是一家云公司。所以今天我们来谈谈云，谈谈Oracle云的部署和架构。
首先，我们为什么需要云？大家都在谈云，都说云是趋势，云是未来，但是云的初衷，我认为是为了解决资源闲置的问题。由于IT业务，特别是互联网业务，有着很明显的有高峰和低谷，如京东的618，阿里的双十一，亚马逊的黑五等等，都是业务高峰，都需要大量的系统资源来支撑业务，而这些资源，在平时的时候，都是被闲置起来的。仅仅是在业务高峰的时候才被需要，此时传统的IT架构，堆机器的方式，就不再适合这种业务模式，我们需要一种能动态的调整资源的模式，能方便的按需加载资源，减掉资源的方式，于是，云的概念就被提了出来。我们可以在云上方便的加减资源。
那么，云的概念被提出来之后，其概念中有一个核心，就是资源共享。我们在云中是需要将资源做加减法，当我需要资源的时候，我能从别的地方把资源挪过来用，而我不需要用资源的时候，也可以把我的资源挪给别人用，这些资源是完全共享的，按需所分配的。那么，如何实现资源共享，用到的技术就是虚拟化。
那么，有了虚拟化技术，进行了资源共享，我们的云可以实现那些功能呢？大体上来说，或者目前大部分的宣传上说，云可以实现以下功能：
标准化，由于在虚拟化之后，硬件不再各自为战，可以用标准化的接口统一起来，软件也是如此。
低成本，由于可以对资源进行加减法，使得资源能得到有效利用，因此减低了成本。
动态性，在云上建立一个主机或者删除一个主机，都是非常容易的事情，可以动态的扩展资源。不再依赖物理主机。
自助性，所有操作都可以在前台页面，自助操作，点点按钮即可完成。
灵活性，主机的物理位置，不一定要在某个地方，在云上选择合适的地区即可。
在最近OOW15中拉里的keynotes中讲到，Oracle云提供的六大目标：
低成本，等于或低于aws
高可靠，无单点故障
高性能，内存计算
标准化，支持业界开放标准
高兼容性，支持不同云的，自动化迁移
高安全性，数据和系统的实时保护
了解了云的初衷，核心和功能，我们来讨论下如何一步一步的部署云。对于部署考虑到关键点，有如下：
第一，你需要考虑你采用哪一种类型的云，云的类型有公有云，私有云，和混合云。需要考虑成本，安全性等等因素。（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也自带有分区功能。
最后，我们来看看云部署的关键指标：
退役的数据库数量
合并的数据库数量
退役的schema数量
合并的schame数量
License成本低减少
退役的服务器数量
操作系统license费用的减少
存储的成本减少
数据中心，电力，冷却费用的减少
那么云部署完成后，生命周期如何管理。首先，我们要考虑数据的归档和清理，归档方法有按照在网用户和历史用户区分，将在网用户的数据放高端存储，将历史用户的数据放低端存储；每月将在网用户的数据定期插入到历史用户数据中；将历史用户的数据做成只读分区；最后，还可以采用压缩表和分区的方法归档。这里需要提醒的是，数据归档是一条单行线，切忌将归档的数据再次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）团队可以帮助客户做很多云方面的工作。
再次感谢Oracle ACS华南区售后团队首席技术工程师何剑敏（小荷）老师，对DBA+社群给予的大力支持！
“DBA+社群”将陆续在各大城市群进行线上专题分享活动，以后每周一、周三晚上为【DBA+专业群】的固定时间，每周二、周四晚上为【DBA+各城市群】的固定时间，每周五晚上为【DAMS架构师精英群】的固定时间，欢迎大家积极加入我们。无论是内容还是形式，有好的建议我们都会积极采纳。
未入群的小伙伴们可先关注DBA+社群微信公众号：dbaplus，回复“我要入群”获得各城市群二维码，再加入你所在的城市微群。
小编精心为大家挑选了近日最受欢迎的几篇热文：
回复001，看丁俊的《【重磅干货】看了此文，Oracle SQL优化文章不必再看！》；
回复002，看《灾备故障上了红头文件，容灾技术到底哪家强？》；
回复003，看吕海波的《去不去O，谁说了算？》；
回复004，看胡怡文《PG，一道横跨oltp到olap的梦想之桥》；
回复005，看付新《达梦专家解读：国产数据库也疯狂》；
回复006，看郭耀龙《假事务之名，深入研究UNDO与REDO》；
回复007，看宋日杰《Oracle后台专家解决library cache锁争用的终极武器》。
DBA+社群，是一个以连接全中国DBA为使命的公益性组织，致力于成为DBA界的UBER，充分利用DBA的业余时间，为广大DBA搭建一个学习交流、价值实现、人脉搭建、跨界合作的平台。目前，DBA+社群已于北上广深等全国15大城市成立DBA+城市群，100+业界专家成为联合发起人，6000+跨界DBA加入队伍，每周4次线上技术分享活动同步直播。
扫码关注
DBAplus社群
超越DBA圈子，连接的不仅仅是DBA