SQL群集，在SQL2008R2以前的版本中，是企業使用最多的高可用技術，該技術實現了服務器硬件層面的高可用，一旦出現故障，可實現SQL數據庫的自動故障轉移，對應用透明，本文將從一次較有價值（保證續約成功）的SQL群集故障問題處理進行描述。

一、    問題現象描述

在我們合作多年的一家國企公司，在他們的對外服務的業務平台是運行在一套Windows2008 R2+SQL2005的A+A群集上，在前天進行Windows服務器的補丁更新後，Windows操作系統無異常，但SQL群集中的命名實例無法啟動；
在該平台的系統管理員進行各種各樣的嘗試操作後，包括將主動節點上的Windows補丁卸載，SQL命名實例群集的仍是無法啟動；
就算最後進行了該群集實例的卸載、重新安裝，在安裝結束步驟中報錯如下：

確定後，SQL群集實例已安裝，但仍然是無法啟動狀態，在群集管理器中，相關SQL服務資源全為失敗狀態。

二、    原因分析

由於該故障是由於Windows補丁更新後所導致，初步判定為Windows補丁更新問題，但是在群集上的另一默認實例是正常的，無法確定是否為Windows補丁更新所導致；

在與該UAP平台的管理員進行溝通後發現，該命名實例之前是固定端口為2433，現重新安裝後再次設置固定端口為2433重啟，無法成功，提示錯誤為：
checkODBCConnectError: sqlstate = 08001; native error = ffffffff; message = [Microsoft][SQL Native Client]SQL Network Interfaces: Error Locating Server/Instance Specified [xFFFFFFFF]；此報錯的原因為：The cluster service is not able to Connect with Clustered Named instance of SQL Server. SQL Browser even though running is not actually listening for requests，因此判斷分析問題可能是出現在SQL Browser的端口問題上；

將該實例的端口設置為動態端口後啟動，可以啟動1~2分鐘，之後又自動關閉了。在可以啟動的時間段內，無法通過‘服務器名\命名實例名稱’的方式進行連接訪問，查看UDP1434端口，發現此端口被禁用（此端口為SQL browser服務所使用，進行SQL命名實例的端口解析），與管理員溝通後發現，此端口不滿足安全掃描要求，在半年前已經禁用掉，故而設置命名實例的固定端口為2433；

端口1434早在半年前已經禁用，為什麼本次故障是由此端口被禁用引起呢？那是因為在端口禁用期間，SQL群集已經處於聯機啟動狀態，無需進行命名實例的端口解析，而本次發生故障後進行了SQL群集的重裝，在重裝完成後是處於動態端口，需要SQL Browser解析完成後才能聯機啟動成功，而SQL Browser的端口已經禁用，導致解析失敗而無法聯機啟動成功。

三、    解決方法

由於該命名實例上所承載的應用仍未恢復，考慮到生產第一，而群集上的另一默認實例群集是正常的，於是暫時將此問題群集上的所有重要應用數據庫遷移到正常的默認實例上，恢復應用；
在恢復應用後，進行SQL群集命名實例的重新安裝，安裝完成後報錯，而且群集管理器上無法將該SQL群集實例的相關資源進行聯機啟動；
與管理員溝通後，臨時開放UDP 1434端口進行測試，啟用1434端口後，在群集管理器上能夠將將SQL相關服務聯機，並且其他的SQL服務也能夠正常啟動，並且能夠進行群集資源的切換；
由於之前設置了命名實例的端口為固定端口2433，在SQL 配置管理器中，同樣將SQL命名實例的端口固定為2433，重啟SQL群集命名實例UAPSQL2後，能夠正常使用固定端口進行訪問。
該命名實例的所有數據庫之前已經遷移到另一默認實例中，後續需要UAP平台的管理員將所有數據庫遷移回命名實例UAPSQL2上。

四、    事件總結

在安裝SQL群集命名實例時，是需要進行命名實例端口的解析，解析不通過會導致SQL群集相關服務無法正常啟動，所以在安裝SQL群集命名實例時需要開啟端口UDP 1434；
而之前在禁用UDP1434端口期間，由於SQL群集總在某一節點上進行保持運行，而且命名實例的端口已固定為2433，故未出現此問題；而本次故障的發生，是由於在安裝補丁更新時，同時將兩個節點同時進行重啟後，SQL群集服務需要再次進行聯機啟動，未能解析到相應端口而出現故障；
本次故障中，由於端口的禁用，導致了重新安裝6~7次的SQL群集都是失敗，一旦未查明此原因，就算重裝操作系統也一樣會出現此問題。