當然，這讓我想得更多。您可以創建幾個腳本，它們調用CLUSTER.EXE將節點添加到Microsoft Cluster Server (MSCS)群集中。您只需為腳本提供節點名稱，然后由腳本處理其余工作。在緊急情況下，自動化確實是您的朋友。
N+1群集
有時，向群集添加節點的原因不是您要更換節點。您可以將更多的SQL Server實例添加到群集中且每個實例都需要不同的磁盤資源。雖然多個實例可以在一個節點上運行，但這些實例會共享CPU和RAM，因此可能會導致性能降低。理想情況下，在一個節點上僅運行一個實例。但在發生故障轉移時如何能確保做到這一點呢?很簡單：答案是，有一個節點上不運行任何服務，而其他節點則是每個節點上運行一個SQL Server實例。實際上，這就是N+1群集的定義： N+1個節點上運行N個實例。額外的節點是備用節點。
升級SQL Server
升級SQL Server的群集實例不是因為膽�。簶嫿ㄈ杭粸橐粋�原因 - 您需要正常運行時間。但SQL Server 2005提供了許多您想利用的增強功能。所以，如果您準備升級，無需太多停機時間便可以繼續進行。
您會選擇哪種方案?我們首先看一看成本最高的解決方案：創建整個新群集。這意味著要創建若干新服務器，或許還要創建新的存儲區域網絡(SAN)。您或許可以保留現有的網絡交換機，但這大約就是您所要保留的全部。顯然，這種方法的成本很高，但它具有一定的優勢。與舊硬件相比，新硬件的運行通常要好得多，因為磁盤容量和速度都得到了增長。因此，僅僅使用新硬件，您的性能就會得到迅速提高。您甚至可能會租用設備，而這只是為了保持領先地位。
硬件到位后，您可以在此安裝上創建新的虛擬SQL Server，將生產數據庫復制過來，然后考察新系統的性能，從而在移交日期之前留有充足的時間來解決程序錯誤。但別忘了編寫腳本，從現有服務器中退出。(萬一發生災難性故障，最好訪問support.microsoft.com/kb/246133來更新登錄構建腳本。)
為了將停機時間減到最少，您很可能必須使用日志傳送，除非您的數據庫相當小并且在一段時間內沒有用戶建立連接。在移交之前，您都可以正確執行日志傳送。接著，刪除這些用戶，剪切并傳送最后的日志，然后指向新實例上的應用程序。(有關感興趣的日志傳送替代方法，請參閱下面的數據庫鏡像部分。)如果使用DNS別名，您甚至可能不需要指向新實例上的應用程序，而是只需更新 DNS 別名。這種方法的優點是，如果您的遷移只進行了一部分，但必須要回退到原始狀態，那您至少還有原始文件。
您還可以采用一種成本較低的方案，但需要您做更多的預先規劃。一個群集可以支持多個SQL Server實例，但每個實例必須有其自己的磁盤資源。因此，在劃分SAN時，請留出一個LUN，以備將來升級。要執行升級，請在此磁盤資源上安裝 SQL Server 二進制文件。您可以演習一下該系統。當您準備好后，關閉當前SQL Server，將磁盤資源從舊的 SQL Server組中移出，更新依賴關系，然后使新SQL Server實例在線。連接舊實例中的數據庫，然后啟動并運行。(您已提早備份了所有數據，對嗎?)
這就是成本較低的方法，實行這個方法需要承擔一些風險。如果出現故障，您無法將數據庫與新實例分離開來并放回原來位置。您的操作已簡化為從備份恢復 - 這意味著需要很長的停機時間。
還有一種方法是將兩個SQL Server實例都放在您的SAN中，前提是您有足夠的磁盤空間。將生產備份(和日志傳送)恢復為新實例，然后按前面介紹的步驟繼續進行。但現在您有退路了。而且，一旦完成遷移，您還可以釋放舊實例占用的SAN資源。您只需增加額外的磁盤。
負載平衡
讓我們首先揭穿這樣一個常見誤解。MSCS群集是用于獲得高可用性的，而非用于實現負載平衡。此外，SQL Server沒有任何內置的、自動負載平衡功能。您必須通過應用程序的物理設計來實現負載平衡。這意味著什么?
文章來源于領測軟件測試網 http://www.kjueaiud.com/
