Oracle Grid Infrastructure CSS（集群同步服务）

所谓覅破解

　　CSS（Cluster Synchronization Service）主要负责构建集群，并且维护集群的一致性。
　　CSS的启动过程
　　1，ocssd.bin被ohasd的代理进程cssdagent启动。
　　2，ocssd.bin访问gpnp profile，获得集群的名称，私网，VF搜索路径等基本信息。
　　3，ocssd.bin在VF搜索路径中找到VF，并在VF的租借块中续租本地节点的节点编号，同时将本地节点的信息添加到VF中，并开始和VF进行磁盘心跳。
　　4，ocssd.bin根据gpnp profile中的信息，和gipcd进程通信，获取集群间通信的私网信息（endpoint）。
　　5，ocssd.bin根据获取的私网信息与远程节点的ocssd.bin建立连接。
　　6，集群重新配置开始，重新配置主节点向集群的其他节点发送消息，通知其他节点有新节点加入，其他节点接收消息。
　　7，重新配置结束，本地节点加入集群。
　　如何维护集群的一致性
　　集群一致性：指集群中每个成员能够了解其他成员的状态，而且每个成员获得的集群中其他节点的状态和集群中节点成员列表信息是一致的。
　　保证集群一致性的机制
　　一，网络心跳（NHB）
　　网络心跳的主要目的是确认节点与节点间的连通性，节点之间能够了解彼此的状态。ocssd.bin守护进程每秒钟会向集群的其他节点发送网络心跳，例如一个4节点集群，集群的每一个节点每一秒都会向集群中的其他三个节点发送网络心跳信息，这也意味着每个节点每一秒也会收到集群中其他节点发送的网络心跳。
　　通俗地说，每个节点都宣告自己还健康地活着，同时也能够感知其他节点也健康地活着。
　　二，磁盘心跳（DHB）
　　磁盘心跳的主要目的是当集群发送脑裂时帮助制定脑裂解决方案。集群的每一个节点每秒钟都会向集群的所有VF注册本地节点的磁盘心跳信息，同时也会将自己能够联系到的集群中其他信息，或者说本地节点认为集群中的成员列表信息写入VF中，一旦发生脑裂，CSS的重新配置线程可以通过VF中的信息了解集群中节点之间的连通性，从而决定集群分裂成几个子集群，以及每个子集群包含的节点情况和每个节点的状态。如果某个节点在200s内一直无法访问某一个VF，对应的VF会被离线，当大多数的VF（VF数量/2+1）被离线时，该节点会被自动重启，因此Oracle建议配置奇数VF。
　　通俗地说，如果一个集群由A，B，C，D四个节点组成，A，B，C三个节点对集群状况的认知是这样滴，而D节点对集群状况的认知是那样滴，那么必须少数服从多数，重新配置主节点命令D节点自杀成仁，并且修改集群成员的花名册，D节点看到命令后结束自己的生命，最终由A，B，C三个节点组成新的集群，每个节点都将自己对集群状况的认知写到表决盘中，因此表决盘相当于投票箱，每个节点对集群状况的认知相当于节点的投票，每个节点都需要往投票箱中投票，因此投票箱必须在一个公共的位置（表决盘必须保存在共享存储上）。重新配置主节点相当于负责计票工作，根据节点的投票做出最终的决策。
　　如果集群仅由A，B两个节点组成，而A，B两个节点对集群状况的认知也不一致，双方势均力敌，难分胜负，这种特殊情况下，就必须制定潜规则，规定节点编号小的节点胜出，另一个节点淘汰。
　　如果集群的一个节点连投票都无法完成（无法写表决盘文件），那么重新配置主节点就无法根据全体成员的投票做出决策，因此规定无法完成投票的节点会自动重启。
　　如果存在3个投票箱，节点在200s内无法在其中一个投票箱内完成投票，那么这个投票箱对这个节点不可用，因此规定节点无法在两个投票箱中完成投票时，节点会自动重启。保证所有节点至少都能够在一个投票箱内完成投票。
　　三，本地心跳（LHB）
　　本地心跳的主要目的是监控ocssd.bin进程以及本地节点的状态，ocssd守护进程每秒钟都向cssdagent和cssdmonitor注册自己的状态信息，如果本地心跳没有问题，cssdagent就认为ocssd.bin进程正常，反之，如果ocssd.bin持续丢失本地心跳（misscount）,ocssdagent就认为本地节点的ocssd.bin进程出现了问题，并重启该节点。
　　通俗地说，一个节点如果自己感知存在严重的问题，那么节点就会自动重启。相当于一个人如果没有心跳了，那么这个人就狗带了，人死不能复生，但是节点可以重启，心若在，梦就在，只不过是从头再来。
　　集群重新配置场景
　　1）丢失网络心跳导致的集群重新配置（ocssd.log）
　　2）丢失磁盘心跳导致的集群重新配置（ocssd.log）
　　3）丢失本地心跳导致的集群重新配置（cssdagent.log或者cssdmonitor.log）
　　4）本地节点HANG导致的集群重新配置（cssdagent.log或者cssdmonitor.log）
　　丢失网络心跳导致的重新配置步骤
　　1）当集群的某一个节点连续一段时间（misscount）丢失网络心跳之后，分析线程决定发起集群重新配置。
　　2）集群的重新配置管理节点（简称RM节点，通常是集群中节点号最小的节点）向集群中的所有节点发送重新配置消息，所有收到此消息的节点会回复该消息，并通知RM节点自己的状态。
　　3）接下来，重新配置管理节点基于每个节点的状态进行投票并检查是否有脑裂会发生。
　　4）对于检查脑裂，重新配置管理节点会查看网络心跳无法访问的节点的磁盘心跳信息，确认这个节点的状态，如果发现无法访问的节点状态也是正常的，那么就可能发生脑裂，需要避免  。
　　5）重新配置管理节点向表决盘的Kill Block中写入有毒（poison package）的信息，需要重启的节点在访问表决盘时读取到有毒信息，完成对本节点的重启（节点驱逐）。
　　6）重新配置管理节点修改集群节点列表（主要是在表决盘中），重新配置完成。
　　集群的重新配置指集群中的节点成员数量发生了改变之后，为了更新集群节点列表和维持集群一致性而进行的一系列操作，有可能是某一个节点加入集群，也有可能是某一个节点离开集群，因此节点驱逐只是集群重新配置的一种情况。
　　术语
　　misscount：这个值用来定义集群网络心跳的超时时间，默认值30s，当集群中的一个或多个节点连续丢失网络心跳超过30s后，集群需要进行重新配置，某一个节点需要离开集群，对于11gR2版本的集群，这个值也是节点本地心跳的超时时间，因为本地心跳和网络心跳是由相同的线程发送的。
　　脑裂：集群的某些节点间的网络心跳丢失，但是节点的磁盘心跳正常的情况。当脑裂出现后，集群会分裂成为若干个子集群，对于这种情况的出现，集群需要进行重新配置，基本原则是：节点数多的子集群存活，如果子集群包含的节点数相同，那么包含最小编号节点的子集群存活。
　　表决盘(Voting File)：这个文件用于保存每个节点的磁盘心跳信息，以及每个节点能够看到的节点列表，这些信息在进行脑裂时用于判断节点状态，以及节点是应该继续存活还是离开集群。
　　重新配置主节点（RM）：当集群中的节点数量发生改变时，会有一个节点被用于完成这次重新配置，该节点负责向集群中的其他节点发送重新配置消息，接收其他节点的反馈信息，并对集群的一些配置文件（OCR，VF）进行修改，以反映集群新的节点数量，通常情况下，集群中编号最小的节点会被选择作为重新配置的主节点
　　Kill Block：保存要求节点重启的信息（poison package），当集群中的一个节点要求另一个节点离开集群时，会在VF的Kill Block中写入poison package,当目标节点读取VF会发现poison package，并重启自己，在集群中一个节点只能要求另一个节点重启，但是，真正重启的节点是本地节点自己。
　　成员终止升级（Member Kill Escalation）
　　当实例驱逐在指定的时间（默认20s）内不能成功完成时，Oracle会在CSS层面上产生一个新的进程（Kill Daemon）,终止目标实例的LMON进程，从而保证实例驱逐能够成功结束。如果KD进程也无法在指定的时间（默认30s）内终止LMON进程，CSS会把成员终止（Member Kill）升级为节点终止（Node Kill）,目标节点的CSS会重启本节点，以确保集群和数据库的一致性。
　　LMON进程被成功终止，Member Kill Escalation未发生的情况
　　步骤1：客户进程（例如：数据库实例1的LMON进程）向CSS的cssgmClientThread线程发出Member Kill请求，要求终止数据库实例2的LMON进程。
　　步骤2：节点1的cssgmClientThread线程响应对应的请求。
　　步骤3：节点1的cssgmClientThread线程向本地节点的cssgmKillThread发出请求，要求终止另一个节点的LMON进程。
　　步骤4：节点2的cssgmListenerThread收到节点1发送的Kill请求。
　　步骤5：节点2的cssgmListenerThread向节点2的cssgmKillThread发出Kill请求。
　　步骤6：节点2的cssgmKillThread线程性KillDaemon发送需要终止的进程列表。
　　步骤7：节点2的KillDaemon终止对应的进程。
　　步骤8：节点2的cssgmKillThread线程通知节点1的cssgmKillThread线程Kill请求已经被成功执行。
　　步骤9：节点1的cssgmKillThread线程通过客户进程Kill请求已经结束。
　　LMON进程未成功终止，Member Kill Escalation发生的情况
　　步骤1：客户进程（例如：数据库实例1的LMON进程）向CSS的cssgmClientThread线程发出Member Kill请求，要求终止数据库实例2的LMON进程
　　步骤2：节点1的cssgmClientThread线程响应对应的请求。
　　步骤3：节点1的cssgmClientThread线程向本地节点的cssgmKillThread发出请求，要求终止另一个节点的LMON进程。
　　步骤4：节点2的cssgmListenerThread收到节点1发送的Kill请求。
　　步骤5：节点2的cssgmListenerThread向节点2的cssgmKillThread发出Kill请求。
　　步骤6：节点2的cssgmKillThread线程性KillDaemon发送需要终止的进程列表。
　　步骤7：节点2的KillDaemon终止对应的进程。
　　步骤8：节点1的cssgmKillThread线程发现在指定的时间（30s）内步骤5-7没有完成，因此向cssgmKillThread发出了escalation请求，要求将Member Kill升级为Node Kill。
　　步骤9：节点1的cssnmKillThread线程向VF的Kill Block中写入poison package。
　　步骤10：节点2的cssnmDiskPingThread线程读取到VF的信息后，重启本地节点。
　　Rebootless Restart
　　当出现以下情况的时候，仅仅重启GI，而不是将节点重启
　　情况1：当某个节点连续丢失网络心跳超过misscount
　　情况2：当某个节点不能访问大多数表决盘（VF）
　　情况3：当Member Kill被升级成为Node Kill
　　如果GI在指定的时间之内无法正常关闭，则直接重启OS。