虛IP解決AlWaysON讀庫服務器過保替換

     公司核心交易數據庫，使用SQL 2012 AlWaysON的1主4從，有2臺（8.14，8.15）從庫服務器，已經使用3年多，過保替換，新買的2臺服務器已經安裝好，一開始方案以下：

服務器（8.14）替換方案：
1，	需提早修改程序鏈接8.14的配置和DBMS，改爲8.15服務器並重啓相關服務
2，	監控幾天未有程序使用8.14數據庫服務器
3，	凌晨2點—5點，在AlwaysON集羣中刪除8.14服務器   
4，	修改原8.14（1.14）成新IP，修改8.84的IP成（8.14） 
5，	配置新的8.14機器加入8.13的故障轉移集羣    
6，	新8.14還原3個數據庫和日誌 
7，	配置新8.14的3個數據庫加入AlwaysON集羣    
8，	測試新8.14的可用性  

    本身想了想，這個機會，能夠用DNS解決之前程序連IP的故障問題，一旦程序連的8.14服務器出現故障，鏈接8.14程序要所有修改重啓，太麻煩，故障一發生，必定是個大事故，想用這個機會用DNS解決，到時真的出問題

只須要修改DNS解析IP就能夠。

   後來跟開發和測試溝通，  測試以爲涉及到程序太多，修改起來的確麻煩，開發那邊以爲，公司內網的DNS解析穩定性不可靠，一個開發負責人說他之前的有老東家準備用dns域名來作，後來取消了，不可靠。

   這麼多人反對，用DNS方案來替換不行。

   後來你們討論：  可否用虛IP來解決這個程序修改的問題，這樣之前用8.14，8.15 這樣的IP就不用改任何程序，把這個相似的8.14等IP提成虛IP，由於Windows沒有虛IP的說法，就是直接加上一個IP。

  在線下作了一個模擬環境，模擬線上用虛IP來更換服務器： 

測試報告

線下測試機：
192.168.60.36（主）
192.168.60.133/60.152/60.247 （備機）

配置SQL Server AlwaysON   1主3從
測試刪除節點：
1，	刪除備機60.133的SQL Server AlwaysON集羣 （1分鐘內）
2，	刪除備機60.133的Windows集羣  （1分鐘內）
3，	修改60.133的IP
4，	在60.247增長60.133的新IP
5，	其餘機器連60.133數據庫正常  

  測試下來，用虛IP方案是可行了，後來又連續測試了一週，沒有什麼異常。後來和開發測試討論，方案以下：

8.15舊機器替換

刪除8.15節點：
1，	刪除備機8.15的SQL Server AlwaysON集羣 （1分鐘）
2，	刪除備機8.15的Windows集羣  （1分鐘）
3，	修改8.14的IP   （3分鐘）
4，	在8.14增長8.15的新IP （3分鐘）
5，	測試連8.15數據庫是否正常 （10分鐘）
新加節點8.85
   提早配置好帳號密碼（已處理），提早幾個小時還原最新的完整數據庫備份（3個），提早半小時備份最新的3個數據庫日誌
1，	新加備機8.85到windows集羣  （1分鐘）
2，	還原最新的8.13的3個數據庫日誌 （15分鐘）
3，	配置8.85到SQL Server AlwaysON集羣 （15分鐘）
4，	刪除8.14的8.15  IP （3分鐘）
5，	在8.85新加8.15  IP （3分鐘）
6，	測試連8.15數據庫是否正常 （10分鐘）

  定在週日凌晨的1:00--5:00,這個時間，2臺機器替換下來，花了大約2個小時，替換過程比較順利。

 總結：

   1，之前咱們總是說linux的虛IP，在windows中不多去作這個，此次把實機的IP變成一個能夠虛的IP，根據須要在不一樣的服務器增長，刪除。達到減小服務器不可用時間，又能快速解決問題。

   2，用虛IP來解決這個服務器替換，的確是一個比較省時省力的辦法。