RAC集群搭建ASM和私网网卡问题分析

一、项目背景

此次来长春一星期，发生的事情很多。

刚下飞机就感觉有点冷，第二天就发烧了，不过吃了感冒药和消炎药两天多就好了。

生病期间打车去项目现场，精神不太好，不小心将陪伴了我四年之久的手机丢在出租车上了，我把号码紧急报停之后，第二天好心人联系了我姐姐，将手机还给了我，谢谢。

另外，就是感谢大伟、生哥、宽爷、海峰、超哥等项目组小伙伴对我的照顾，谢谢。

此项目所有主机资源、网络环境、存储资源都是由联通方进行提供，都是在云上资源的划分，那本次文章就是介绍联通方一系列的问题导致搭建集群失败的相关分析。
当然后续经过调整，集群成功搭建。

但是在搭建前的准备和搭建中一共遇到了两个很重要的问题，在此分享给大家，以后如果有需要搭建集群环境的项目应该注意。

• 单块ASM磁盘不能超过2T大小，即裸LUN的分配要注意不超过2T
• 私网网卡在虚机上配置不要加地址绑定限制和HAIP的相关问题

二、ASM磁盘的BUG

刚到项目，进行环境检查时发现两个节点挂载的是一块15T的裸LUN,就想到了去年搭建抚顺教育云时遇到的ASM磁盘组的BUG,这些细节地方确实前期很容易被忽视。

早期的集群是通过各存储厂家的存储技术实现的，直到10G之后，oracle公司研究出ASM磁盘的技术，将集群技术进行统一。

ASM是一个卷管理器，Oracle数据库文件的一个文件系统，ASM支持单实例和集群配置，它是oracle推荐的存储方案，为传统卷管理器，文件系统，裸设备提供一个选择。

2.1 每块ASM磁盘不大于2T

ASM磁盘有一定限制：单块ASM的磁盘不能大于2T，不然创建磁盘组就会报错ORA-15196 WITH ASM DISKS LARGER THAN 2TB。
联系联通云平台的相关人员进行处理，其反馈了两个问题：

• 15T裸LUN得重新划分需要先将其格式化，15T大小的磁盘格式化时间大约8个小时；
• 15T的裸LUN要划分成每块盘不大于2T，至少需要7个LUN来进行划分，但是目前的云平台是不支持划分这么多数量的，无法保证云平台的稳定。

由于ASM磁盘的限制问题，和联通方表示，LUN的重新划分必须要进行，后进行沟通，按照我们提出的需求联通方进行处理，但是由于前期对资源没沟通到位，确实对项目的推进效率造成了一定的影响。

2.2 ASM - Scalability and Limits

参考MOS文档：文档 ID 370921.1

ASM磁盘共有如下一些限制：

1. 63 disk groups in a storage system
   代表一个存储系统最多只能有63各磁盘组，但是一般我们只需要3到四个磁盘组即可：CRS、ARCH、DATA。
2. 10,000 ASM disks in a storage system
   代表一个存储系统最多1万个ASM盘文件，假设我们单块磁盘2T，那我们有2*10000=2万T的空间，这已经很大了，绰绰有余。
3. 2 terabyte maximum storage for each ASM disk
   即上文提到的每个ASM磁盘不超过2T，代表我们在挂裸LUN的时候，单个lUN要注意大小。
4. 1 million files for each disk group
   代表每个磁盘组最多100万个文件
5. 2.4 terabyte maximum storage for each file
   每个文件的最大存储容量2.4T,参考一下即可，我们单块磁盘都不超过2T，没意义的限制。

当然，以上限制到12.1版本之后有所更改，比如只能有63个磁盘组增加到511个，2T磁盘限制也有所修改，具体可以参考文档 ID 370921.1。

三、私网网卡相关问题

在安装Grid集群时候，有一步要在两个节点分别执行root.sh，类似的操作如果有安装过数据库的小伙伴也应该有经历过。那在Grid安装的这一步会出现各种莫名奇妙的问题，这个时候就需要有查看日志进行解决的能力了。

3.1 私网网卡上绑定的HAIP无法通信

在一节点上执行root.sh成功后，在二节点执行root.sh时报错，截取了oraagent_grid.log一段最初的报错信息，除此之后没有其他的报错信息：

2017-06-16 16:43:00.813: [ora.asm][2023237376]{0:0:209} [start] InstAgent::startup
2017-06-16 16:43:21.970: [ora.mdnsd][2029348608]{0:0:153} [check] clsdmc_respget return: status=0, ecode=0
2017-06-16 16:43:23.142: [ora.gpnpd][2029348608]{0:0:161} [check] clsdmc_respget return: status=0, ecode=0
2017-06-16 16:43:24.553: [ora.gipcd][1530365696]{0:0:162} [check] clsdmc_respget return: status=0, ecode=0
2017-06-16 16:43:50.911: [    AGFW][2027247360]{0:0:153} Agent received the message: AGENT_HB[Engine] ID 12293:660
2017-06-16 16:43:51.973: [ora.mdnsd][1530365696]{0:0:153} [check] clsdmc_respget return: status=0, ecode=0
2017-06-16 16:43:53.144: [ora.gpnpd][2029348608]{0:0:161} [check] clsdmc_respget return: status=0, ecode=0
2017-06-16 16:43:54.556: [ora.gipcd][2029348608]{0:0:162} [check] clsdmc_respget return: status=0, ecode=0
2017-06-16 16:44:20.914: [    AGFW][2027247360]{0:0:153} Agent received the message: AGENT_HB[Engine] ID 12293:670
2017-06-16 16:44:21.975: [ora.mdnsd][2029348608]{0:0:153} [check] clsdmc_respget return: status=0, ecode=0
2017-06-16 16:44:22.590: [ora.asm][2023237376]{0:0:209} [start] ORA-03113: end-of-file on communication channel
Process ID: 0
Session ID: 0 Serial number: 0
2017-06-16 16:44:22.590: [ora.asm][2023237376]{0:0:209} [start] InstAgent::start: 1 errcode 3113
2017-06-16 16:44:22.590: [ora.asm][2023237376]{0:0:209} [start] InstAgent::start: untrapped error
2017-06-16 16:44:22.590: [ora.asm][2023237376]{0:0:209} [start] InstAgent::start: 2 errcode 3113
2017-06-16 16:44:22.590: [ USRTHRD][2023237376]{0:0:209} InstConnection:~InstConnection: this 54037cc0
2017-06-16 16:44:22.590: [ora.asm][2023237376]{0:0:209} [start] clean {
2017-06-16 16:44:22.590: [ora.asm][2023237376]{0:0:209} [start] InstAgent::stop_option stop mode immediate option 1
2017-06-16 16:44:22.590: [ora.asm][2023237376]{0:0:209} [start] InstAgent::stop { 
2017-06-16 16:44:22.590: [ora.asm][2023237376]{0:0:209} [start] getResAttrib: attrib name USR_ORA_OPI value false len 5
2017-06-16 16:44:22.590: [ora.asm][2023237376]{0:0:209} [start] InstAgent::stop original reason system do shutdown abort
2017-06-16 16:44:22.590: [ora.asm][2023237376]{0:0:209} [start] ConnectionPool::resetConnection  s_statusOfConnectionMap 00ae9760
2017-06-16 16:44:22.590: [ora.asm][2023237376]{0:0:209} [start] ConnectionPool::resetConnection sid +ASM1 status  2

截取的这一段日志比较重要，可以看到第一行开始InstAgent，然后进行clsdmc_respget检查（对此我的理解是两个节点上私网网卡绑定的HAIP进行通信检查），可以看出多次通信未成功，然后报错ORA-03113: end-of-file on communication channel，直接把和ASM信息的数据库断开，然后开始清除InstAgent的信息，至此节点2执行root.sh失败，意味着集群搭建失败。

对于这个错误我的初步判断是联通分配的私网网卡有问题。

和联通方负责人沟通后，并未得到想要的答案，其表示正常的私网网卡，使用没有问题。
没办法，只能去找确凿的证据，来告诉联通方其私网网卡确实有问题。
经过一天的排查下来，最终在MOS文档上 Doc ID 1383737.1 找到证据。

3.1.1 Symptoms

如果这个问题出现在安装Grid Infrastructure执行root.sh脚本时，表现出以下症状：

• root script screen output

  Start of resource "ora.asm" failed
  CRS-2672: Attempting to start 'ora.asm' on 'racnode1'
  CRS-5017: The resource action "ora.asm start" encountered the following error:
  ORA-03113: end-of-file on communication channel
  Process ID: 0
  Session ID: 0 Serial number: 0
  . For details refer to "(:CLSN00107:)" in "/ocw/grid/log/racnode1/agent/ohasd/oraagent_grid/oraagent_grid.log".
  CRS-2674: Start of 'ora.asm' on 'racnode1' failed
  ..
  Failed to start ASM at /ispiris-qa/app/11.2.0.3/crs/install/crsconfig_lib.pm line 1272

• $GRID_HOME/cfgtoollogs/crsconfig/rootcrs_<nodename>.log

  ..
  >  CRS-2672: Attempting to start 'ora.asm' on 'racnode1'
  >  CRS-5017: The resource action "ora.asm start" encountered the following error:
  >  ORA-03113: end-of-file on communication channel
  >  Process ID: 0
  >  Session ID: 0 Serial number: 0
  >  . For details refer to "(:CLSN00107:)" in "/ispiris-qa/app/11.2.0.3/log/racnode1/agent/ohasd/oraagent_grid/oraagent_grid.log".
  >  CRS-2674: Start of 'ora.asm' on 'racnode1' failed
  >  CRS-2679: Attempting to clean 'ora.asm' on 'racnode1'
  >  CRS-2681: Clean of 'ora.asm' on 'racnode1' succeeded
  ..
  >  CRS-4000: Command Start failed, or completed with errors.

• For 12.1.0.2, the root.sh on the 2nd node could report:

  PRVG-6056 : Insufficient ASM instances found.  Expected 2 but found 1, on nodes "racnode2".

可以看出我们正好符合症状1，执行root.sh脚本出现ORA-03113: end-of-file on communication channel错误。

3.1.2 Details

• case 1:link local IP (169.254.x.x) is being used by other adapter/network
  169.254.X.X这个IP时执行root.sh脚本时候，会自动绑定一个HAIP的信息到私网网卡上，如果这个IP正好被其他设备占用，那当然会绑定失败，最简单的检查办法是通过ifconfig -a进行检查是否存在169.254.X.X相关信息。
• Case2: firewall exists between nodes on private network (iptables etc)
  两节点之间的private network之间存在防火墙等问题，比如iptables,ipmon等等。
• HAIP is up on some nodes but not on all
  HAIP只在一个节点上绑定了，但是并不是所有节点都绑定了HAIP，在两个节点都进行ifconfig检查，就会发现eth1网卡（私有网卡）下面多了一个169.254.X.X格式的HAIP
  
• Case4: HAIP is up on all nodes but some do not have route info
  虽然所有节点上都有HAIP的信息，但是路由表上没有相关信息。
  检查路由表，发现两个节点都是有对应的路由信息，应该也不是这个问题
  
• Case5. HAIP is up on all nodes and route info is presented but HAIP is not pingable
  虽然HAIP在每个节点上都有绑定，而且路由表上也有对应IP信息，但是无法ping通。

在项目现场，用两个16.254.X.X的IP进行互相ping，发现两个IP无法ping通，于是将此问题和联通方沟通，告知其肯定是私网的问题，希望其进行排查，最终联通给了回复，确实是私网出现了问题。
由于拿出了十足的证据告诉联通方确实是他们方面出现了问题，所以后面问题的解决也比较快，在此贴一下对话截图吧。

这儿告诉联通方问题确实出现了eth1这个网卡上。

原来联通方面做了对应网卡的地址绑定，每块网卡写死IP就只有对应IP能通信，坑...

3.2 root.sh Fails to Start HAIP as Default Gateway is Configured for Private Network VLAN

参考文档 ID 1366211.1

在联通方将对应地址绑定配置修改掉后，重新搭建集群，每次重新搭建集群就得将所有文件删掉，将存储dd清空，非常麻烦。
本以为这次应该可以大功告成了，没想到跑一节点的root.sh就直接报错，真是尴尬和烦！
报错信息：

Start of resource "ora.cluster_interconnect.haip" failed
CRS-2672: Attempting to start 'ora.cluster_interconnect.haip' on 'db1'
CRS-5017: The resource action "ora.cluster_interconnect.haip start" encountered the following error:
Start action for HAIP aborted
CRS-2674: Start of 'ora.cluster_interconnect.haip' on 'db1' failed
CRS-2679: Attempting to clean 'ora.cluster_interconnect.haip' on 'db1'
CRS-2681: Clean of 'ora.cluster_interconnect.haip' on 'db1' succeeded
CRS-4000: Command Start failed, or completed with errors.
Failed to start Oracle Clusterware stack
Failed to start High Availability IP at /u01/app/11.2.0/grid/crs/install/crsconfig_lib.pm line 1043.
/u01/app/11.2.0/grid/perl/bin/perl -I/u01/app/11.2.0/grid/perl/lib -I/u01/app/11.2.0/grid/crs/install /u01/app/11.2.0/grid/crs/install/rootcrs.pl execution failed

这次有了私网的经验，直接检查HAIP，发现根本没有绑定HAIP，于是直接将情况和联通方进行沟通，联通方应该也意识到时自己的问题，这次对方配合很迅速。

告知联通方，eth1网卡无法绑定IP信息

原来问题是由于他们CAS配置只改了一半，没改完全，导致无法绑定IP信息，真是坑...

四、总结

还好，最后将集群搭建的事宜圆满完成了。
简单总结下吧：
1.ASM磁盘不能大于2T在项目上以后很常见吧，现在存储空间都很大，动辄就是申请15T的资源，那么前期沟通，应该就要知晓裸LUN不能大于2T，免得15T又只划分一个LUN，重新格式化需要很长时间；

2.项目上有其他厂家进行配合时候，有事情一定要给他拿出证据，告诉他哪里哪里有问题，外面厂家很多都是提交工单，然后进行处理模式，这种固化的模式导致你告诉他可能哪里哪里有问题，他们根本不会分析的，你必须，必须告诉他你们这个地方确实有问题，他们才会进行处理；

3.心态的问题,考虑到大伟后期还要和联通方一直合作，不然我早就把联通方相关人员都喷一遍了。克制.克制.克制.