在主机适配器失败后移动资源时，RPC服务器在Hyper-V群集上不可用
在运行Hyper-V的Windows 2008 R2 SP1群集上，主要主机接口上的networking连接丢失。 接口快速上下跳动，后来确定是由于交换机端口故障造成的。
由于这是一个集群服务器，主机接口不具有容错能力（看到整个服务器是如何容错的），所以与主机的连接正在上升和下降。
Hyper-V guest虚拟机完全不受networking中断的影响，因为他们在与主机接口分离的服务器上使用专用中继。 另外，集群和实时迁移networking的专用接口也很好。
- 在Hyper-V下的SCSI硬盘上安装CentOS
- 如何将网卡专用于Hyper-V中的虚拟机
- Hyper-Vnetworking随着最新的LIS而降级
- PowerShell Hyper-V远程？
- Hyper-V在Win 8上给内部networking接入互联网
为了诊断服务器，我尝试通过故障转移群集pipe理器将所有资源（Hyper-V Guest）移动到其他节点。 这些移动失败，出现RPC Server Unavailable错误。
移动资源的唯一方法是closuresguest虚拟机，停止节点A上的群集服务，允许其他节点获取资源的所有权，然后重新启动guest虚拟机。
其他一些说明：
- 所有节点都具有在群集和LMnetworking上启用的用于MSnetworking和文件和打印机共享的客户端。
- 节点A可以通过来自其他节点的集群和LMnetworking访问（这些是私有的，仅集群networking）。 pingable，CIF等。
- 正如您在本例中所期望的，访问\\ NODEA是通过主机适配器完成的，并且是该适配器closures时
RPC Server Unavailable错误的原因。
我的问题在这里 –
- 有没有办法在这样的故障情况下仍然使用实时迁移来防止closuresHyper-V guest虚拟机？
- 未来如何重新configurationnetworking，以便群集服务尝试使用群集和/或实时迁移networking发出RPC请求？
好问题！
RPC故障最可能的原因是群集名称资源（和IP地址）可能位于主networking连接抖动的服务器上。
由于接口正在上升和下降，因此通过群集名称访问群集可能会因networking中断而失败。
您应该能够从命令行执行针对群集的命令（cluster.exe或PowerShell中的FailoverClusters模块）。 如果configuration了相应的凭据委派（CredSSP或Kerberos），FailOverClusters模块可用于PowerShell远程处理。
如果networking接口托pipe群集名称失败，则可以使用PowerShell将该群集组移动到其中一个可访问的节点上，或者您可以对群集执行命令来迁移机器等。
为了确保不再发生这种情况，您可能需要使NIC具有高可用性（网卡绑定）。 这取决于您从哪里pipe理集群..从一个服务器或远程pipe理工作站。 如果您正在使用同一群集中的群集机器进行pipe理，则可以将群集networking上的IP添加到群集名称中，但是要确保未添加到DNS中，否则可能会中断远程pipe理客户端能够连接。
通过PowerShell将IP地址添加到群集组 –
$Resource = Add-ClusterResource -Name SecondaryIP -ResourceType "IP Address" -Group 'Cluster Group' $Resource | Set-ClusterParameter -Name 'Address' -Value 'Your-IP-Here' $Resource | Set-ClusterParameter -Name 'SubnetMask' -Value 'Your-SubnetMask-Here'
如果您不希望远程pipe理客户端尝试与专用networking通信，则需要禁用dynamicDNS注册并创build静态条目。