江西响应式网站建设,黑白灰网站,产品免费推广网站有哪些,怎么样能够为一个网站做推广在本篇文章中#xff0c;老王将从实际应用的角度来为大家讲解下群集仲裁在真实情况下的呈现#xff0c;以及出现不同点数的节点宕机应该如何处理#xff0c;在老王本篇文章中以及以后的文章中#xff0c;我并不会去讲如何去安装一个群集#xff0c;后面我们也将主要专注于… 在本篇文章中老王将从实际应用的角度来为大家讲解下群集仲裁在真实情况下的呈现以及出现不同点数的节点宕机应该如何处理在老王本篇文章中以及以后的文章中我并不会去讲如何去安装一个群集后面我们也将主要专注于群集的深入知识概念理解架构设计迁移优化。 本篇文章分为以下几个场景 场景1.两个站点三个节点的群集假设北京站点两个节点保定站点一个节点群集采用多数节点方式我们将依次测试重现群集坏掉1个节点会发生什么应该如何处理群集坏掉两个节点会发生什么应该如何处理。 场景2.两个站点四个节点的群集假设北京站点两个节点保定站点两个节点群集采用磁盘仲裁的方式我们将依次测试重现群集见证磁盘活着时候坏掉一个节点时群集会发生什么应该如何处理坏掉两个节点时群集会发生什么应该如何处理当见证磁盘不在会发生什么情况应该如何处理。 场景1环境介绍 北京站点 Node1 管理网卡 10.0.0.3 网关10.0.0.1 DNS10.0.0.2 存储网卡 40.0.0.3 网关40.0.0.1 心跳网卡 18.0.0.1 Node2 管理网卡 10.0.0.4 网关10.0.0.1 DNS10.0.0.2 存储网卡 40.0.0.4 网关40.0.0.1 心跳网卡 18.0.0.2 08DC lan1 10.0.0.2 网关10.0.0.1 网关服务器 10.0.0.1 20.0.0.1 30.0.0.1 40.0.0.1 保定站点 管理网卡 20.0.0.5 网关20.0.0.1 DNS10.0.0.2 存储网卡 30.0.0.5 网关30.0.0.1 心跳网卡 18.0.0.3 此次设计上并没有采取一些最佳实践老王只是为了重现出这样一个多站点的场景把两个站点间管理网卡和存储网卡的网络分开在之后的实验08DC也会承担ISCSI Server角色严格来说网关服务器和存储应该要放在一个相对来说比较稳定安全的地方防止由于网关或存储导致群集出现单点故障另外 大家看到我在心跳卡上面两个站点的用的是同一个网端这在实际企业环境里面不会这样通常情况下是打通一个大VLAN这样去做但是要注意群集节点网卡一定要至少有一块网卡不配置网关因为群集在创建的时候会去利用启发性算法来查找群集默认会找没有配置网关的网卡来作为心跳网卡如果全部网卡都配置上网关你会发现群集出现故障因此如果心跳网卡也需要跨越网段可以采取在节点上面用route -p的方式手动添加路由表进行解决 参考 https://blogs.technet.microsoft.com/timmcmic/2009/04/26/windows-2008-multi-subnet-clusters-and-using-static-routes/ 另外也需要考虑跨站点DNS缓存的问题由于环境有限所以在这里老王只用了一台DNS服务器严格来说应该是各站点有自己的DNS服务器的例如当前群集角色testdtc在北京站点的群集联机地址是10.0.0.9但是北京DNS就会记录这个VCO是这个10网段的地址然后每隔一段时间复制到保定的DNS服务器这个复制时间就是个时间差跨站点故障转移时间实际也需要考虑到DNS服务器复制的缓存和客户端的客户端的缓存因为在北京没复制到保定之前保定从北京或得到testdtc就是10网段的地址就会cache下来客户端来请求就都返回这个地址但是当群集应用转移到保定保定是20网段因此就需要CNO重新注册VCO的DNS记录然后群集资源名称才可以正常联机对外使用通常这种跨子网的群集应用我们会设置绑定多个IP地址然后依赖关系设置为or即只要其中一个IP可以活着 绑定注册DNS就可以群集请求DNS更新了VCO的地址这时候VCO可以正常联机了但是客户端能不能访问了呢还不一定因为客户端还有dns cache针对于跨站点群集VCO的DNS缓存和记录生命周期后面老王会单独写一篇深入介绍多站点群集的博客在里面会指出一些最佳实践其中网络部分会深入讲解这里只是简单带过首先可以看到节点服务器目前都是正常的状态以及按照预定规划的多站点群集网络架构我们创建了一个群集DTC应用可以看到当前是主运行在node1节点上直接将node1进行断电关机可以看到群集DTC已经转移至node2继续提供服务打开node2服务器系统日志可以看到关于检测node1已经离线了的日志这时虽然群集还可以运作但是已经仲裁已经提示警告意思就是提醒你一下你之前和我签订的仲裁协议是多数节点的3节点群集现在你坏了一台了不能再坏了再坏群集就要关了真实场景下如果三节点群集坏了一个节点应该立刻修复节点重新上线不然再坏一台群集将不再对外提供服务。这时候我们将node2也直接断电关机我们失去了整个北京站点之后打开群集管理器可以看到群集状态已经变成了下移这时候实际上群集已经不再对外提供服务CNO和VCO都将无法访问打开事件管理器系统日志可以看到群集服务因为仲裁协议违反已经被迫停止针对于群集的分析主要分为系统日志群集详细分析日志群集验证报告cluster目录日志cluster.log日志其中系统日志和详细分析日志相对比较容易理解建议大家可以先从这方面的日志看起后面会有文章专门介绍群集日志分析这时群集由于连续的节点崩溃已经只剩下最后一个节点这时候群集也关闭了不再对外提供服务但是我们也可以通过强制启动的方式把最后一个节点的群集服务启动起来让群集继续对外提供服务虽然一个节点能承载的负载有限但是可以访问一部分总比什么也访问不到强直接运行命令 net stop clussvcnet start clussvc /FQ即可把群集服务先停止然后强制启动起来 执行完成强制启动后可以看到群集已经使用但是群集有提示我们当前是在forcequorum状态运行群集配置可能会丢失 老王猜想是因为这是使用多数节点仲裁的原因或者共享见证时会遇到的问题因为这类仲裁模式群集数据库只存在本地节点间互相同步假设现在只有Node3强制启动了其它节点都不在我们修改了群集资源然后节点3下其它节点上会因为时间分区的原因导致无法启动等类似原因 因此建议大家强制启动只能是作为实在没办法下的最后一道手段能让群集短暂的起死回生但是回生之后应该立即修复其它节点加入群集解除ForceQuorum模式。可以看到强制启动之后 群集DTC服务已经在保定站点正常启动了起来群集名称对应的IP地址现在是保定那边的20网段如果大家点击一个群集角色的依赖报告可以看到类似下面的这种图理解依赖关系对于多站点群集应用上线很重要AND则代表虽有关联的子资源必须联机父资源才可以联机OR则代表选项中的几个子资源有一个活着父资源就可以启动例如网络名称需要绑定IP如果10可以绑定注册就绑定10网段如果10子网无法绑定那么20网段可以绑定注册网络名称也可以上线联机。以上我们实际看了三节点多数节点仲裁情况下节点依次宕机时的处理接下来我们再看第二个场景 场景2环境介绍 北京站点 Node1 管理网卡 10.0.0.3 网关10.0.0.1 DNS10.0.0.2 存储网卡 40.0.0.3 网关40.0.0.1 心跳网卡 18.0.0.1 Node2 管理网卡 10.0.0.4 网关10.0.0.1 DNS10.0.0.2 存储网卡 40.0.0.4 网关40.0.0.1 心跳网卡 18.0.0.2 08DC lan1 10.0.0.2 网关10.0.0.1 lan2 20.0.0.2 网关10.0.0.1 lan3 30.0.0.2 网关30.0.0.1 网关服务器 10.0.0.1 20.0.0.1 30.0.0.1 40.0.0.1 保定站点 Node3 管理网卡 20.0.0.5 网关20.0.0.1 DNS10.0.0.2 存储网卡 30.0.0.5 网关30.0.0.1 心跳网卡 18.0.0.3 Node4 管理网卡 20.0.0.6 网关20.0.0.1 DNS10.0.0.2 存储网卡 30.0.0.6 网关30.0.0.1 心跳网卡 18.0.0.4可以看到群集已经新增至四个节点同时也已经配置了磁盘见证依旧部署一个群集DTC目前托管在北京node2节点我们直接将node2断电可以看到现在DTC群集应用已经自动转移至本站点的node1服务器接下来我们把Node1也直接断电模拟我们失去了整个北京站点的节点可以看到由于我们采用了磁盘见证因此我们可以接受一半的节点坏掉群集依然可以正常工作但是提示我们了在当前的情况下只要再坏掉一个节点或者群集磁盘宕机都会导致群集关闭这时应该抓紧时间修复北京站点尽快上线不要让这种情况持续太久假设这时没抢救好北京站点保定站点又坏了一个节点群集则会变成下移关闭状态所有群集服务也将都无法访问这时由于群集宕机节点数已经违背了仲裁协议中的节点数因此也只能使用强制启动的方式把群集启动起来但是这种状态同样也不要持续太久还是应该尽快修复其它节点上线接下来我们来模拟下脑裂的场景即北京与保定直接发生了网络分区两边各自为政实际最佳老王应该模仿是群集四个节点先是失去了到仲裁磁盘的连接然后变成四个节点四个投票的情况下中间产生一个分区但是由于老王AD和ISCSI模拟在了一起如果直接把这台机器宕机所有节点别想正常工作了因此老王这里临时将群集仲裁模型改为了多数节点即四个节点四票的一个多数节点架构脑裂一触即发的架构哇哈哈这时我们模拟脑裂分区将node3和node4直接改到另外一个网络中So it begin可以在node2上面看到只有node1和node2活着node3 node4形成群集或无法形成但是如果访问群集名称测试会发现还是不能访问的因为这是群集已经没办法执行仲裁两边没有一方是多数的因此整个群集都将没办法正常工作都在摸瞎胡中这时由于域控和存储在北京这边北京这边可以正常工作保定那边网络还未修复因此我们强制启动北京的群集分区在node2上面运行强制启动命令可以看到只需要在node2上面运行一下强制启动的命令之后整个群集就都变得可用了node1和node2在同一个分区内node1感觉到node2形成了权威分区于是自动又融入了群集但这时由于我们是强制启动的群集群集还处于强制启动状态不论任何情况下都不要长时间让群集处于强制启动状态还是应该尽快的去恢复网络。可以看到群集DTC现在已经在北京站点正常联机工作当保定站点网络修复好了后这一侧的群集分区感应到了北京的权威群集分区就又会自动融合进去群集现在又正常工作了强制启动状态的警告也已经消除 总结一下我们看了再多数节点仲裁模型下群集节点在不停宕机时群集的变化处理又看了在磁盘见证模型下磁盘在的情况下群集节点在不停宕机时群集的变化处理以及磁盘见证不在发生网络分区时的变化处理 简单来说在群集工作状态中只要不违背你与群集签订仲裁协议的规则群集都是可以正常运作的当达到临界值时群集会提醒当前已经达到临界值再宕机一票群集就要关了这时候应该要抓紧时间修复群集其它节点 然后假设出现了连续宕机的情况下只剩下一个节点或者只剩下少数节点如果想让群集起死回生出来提供服务可以使用强制仲裁的方式在少数节点的情况下也可以让群集启动起来 强制仲裁主要就是用于在少数节点的情况下启动起来群集或者在群集发生脑裂50 50的情况下启动起来其中一端出来提供服务同样强制仲裁状态时间不可以太长否则会出现配置不同步风险也要尽快修复节点或网络故障上线才是 当我们执行强制仲裁命令之后实际上背后群集会做两件事确立强制仲裁一方为权威方提升强制仲裁分区的群集配置Paxos标记提升为最高类似于AD里面的授权恢复让强制仲裁的一方为黄金权威方群集将在权威方进行运作其它节点的群集配置将会与强制仲裁一端同步不可否认强制仲裁很多时候还是很实用的 以上就是老王想和大家说的强制仲裁以及仲裁处理希望大家看过之后能有收获当群集出现逐个节点宕机时心里有数该如何处理 补充几点1.强制启动起来只是我们把群集救活了但是可不可以完整的对外提供服务呢不一定因为假设是四个节点的群集资源都是一致的那强制启动起来的节点能否承载起来四个节点的负载呢这是个问题如果支持不起来负载一些群集应用也是没办法联机访问的因此实际规划时也需要考虑到这种只剩下最后一个节点的场景最佳是设计的时候能够做好规划服务器资源足够当然最好也可以通过规划群集应用优先级的方式规划一旦发生这种情况那些群集应用优先级比较高先让这些应用活起来或者设置一个冷备机平时不参加群集投票一旦出现这种只剩下一个节点的情况下可以再把冷备节点启动来承载负载 2.上面其实还有一种场景老王没写到最后上张图把出于好奇心我在2008R2的群集上面试了下3个节点见证磁盘的仲裁模型结果死的很惨可以看到当群集坏一个节点就已经告诉我当前已经达到了临界值见证磁盘失效或者再坏一个节点节点群集就关了这样来看完全没什么优势啊因为我如果3个节点多数节点我只需要考虑保证两个节点可用就好了这样的话我还要多考虑一个见证磁盘的可用对于保持群集可用可谓一点用处没有唯独能想到的可能就是这种场景下可以避免时间分区的问题如果最后剩下一个节点和见证磁盘还可以把配置修改信息同步到见证磁盘其它节点再上线也可以正常使用到了2012时代这个就变了不再鸡肋3节点配见证磁盘不需要强制启动的情况下也可以活到最后一个节点下篇文章我们就来实际测试2012时代仲裁发生的变化 转载于:https://blog.51cto.com/wzde2012/1951840
