容災半自動化的實現思路（一)

最近也在對容災的切換做一些改進。
目前碰到的問題有
1.災難切換後備庫的核心引數設定不到位，導致切換後又潛在的效能問題
2.災難切換後在同機房，網路相關的情況下，需要切換備庫的IP為主庫，但是跨機房，跨IDC可能不行，可以修改IP的情況下，對應用基本是透明，但是如果修改IP就需要應用修改配置。
3.災難切換之後防火牆資訊在主庫無法得到的情況，在備庫只能關閉防火牆，或者設定最大的訪問許可權
4.原來主庫中的db link可能無法正常解析，如果解析不當或者依賴較多，會有資料庫負載成百倍暴漲的可能性
5.原來主庫啟用的監聽埠，切換之後備庫可能無從知曉
6.主庫中設定的域名解析，如果不同步或有缺失，切換之後會直接應用listener.ora,tnsnames.ora等等配置。
7.主庫的引數配置可能和備庫不同，切換之後無從判別這些引數的差別。
8.主備庫的profile檔案可能不同，這些關鍵的環境變數可能在切換之後會有差別或者不滿足要求。
其實還有一些，容我再想想，繼續補充，大體基於以上的一些情況和問題，其實最關鍵的是這些問題如果發生的時候，還是需要人工介入去修改和校正，災難切換我希望不要發生，但是發生的機率還是較低，所以一旦發生就會有些措手不及，所以處理問題的時候會花費額外的一些時間。
   之前也分析過，其實很多時候我們的備庫在資料切換上是有oracle的技術兜底，但是在業務需求方面這些工作還是我們得自己完成，而且我建議為半自動切換，主要是因為failover,switchover
這個需要人工的判定，需要聯絡業務方來共同協作，而不是自動化的切換，這樣很容易造成後續的補充工作跟不上節奏，步調不一致。
以上的這些問題，其實就涉及到一些切換中需要考慮的檔案。
1.災難切換後備庫的核心引數設定不到位，導致切換後又潛在的效能問題   --/etc/sysctl.conf, /etc/security/limits.conf
2.災難切換後在同機房，網路相關的情況下，需要切換備庫的IP為主庫，但是跨機房，跨IDC可能不行，可以修改IP的情況下，對應用基本是透明，但是如果修改IP就需要應用修改配置。--/etc/sysconfig/network-scripts/ifcfg-ethx, /etc/sysconfig/network
3.災難切換之後防火牆資訊在主庫無法得到的情況，在備庫只能關閉防火牆，或者設定最大的訪問許可權  --/etc/sysconfig/iptables
4.原來主庫中的db link可能無法正常解析，如果解析不當或者依賴較多，會有資料庫負載成百倍暴漲的可能性   -- tnsnames.ora
5.原來主庫啟用的監聽埠，切換之後備庫可能無從知曉     --listener.ora
6.主庫中設定的域名解析，如果不同步或有缺失，切換之後會直接應用listener.ora,tnsnames.ora等等配置。   --/etc/hosts
7.主庫的引數配置可能和備庫不同，切換之後無從判別這些引數的差別。  --   initxxxx.ora
8.主備庫的profile檔案可能不同，這些關鍵的環境變數可能在切換之後會有差別或者不滿足要求。   -- .bash_profile
 
目前自己設想的實現方式如下。首先需要有一臺中控機器，能夠訪問到主庫和備庫環境。在中控存放主備庫的配置資訊。就如同右邊的圖所示。
然後主庫會定期抓取這些配置資訊，然後主庫和備庫建立單向的信任關係，可以直接把主庫的配置資訊透過crontab同步到備庫。
而備庫中也會定期抓取自己的配置資訊，但是不會同步到主庫造成干擾。一旦發生問題的時候可以從中控抓取備庫的配置。

以上的配置就需要設定一些規範了。首先需要在主備庫中都保持/home/conf這樣一個目錄結構。
主備庫的網路卡別名都保持一致，比如都是eth0，如果不同同步過去之後還是可能出現問題。
主備庫的/etc/oratab的配置要準確，因為這個檔案就是個配置資訊，但是如果配置不夠規範在後期做解析的時候會有一些麻煩。
主備庫的網路配置都保持一樣的風格，比如有的主庫是使用ip的形式，有的是使用主機名的形式來匹配，這些都統一一下，在切換的時候會更加方便一些。
主備庫的主機名都能規範一下，很多時候我看到的主庫的主機名是備庫的，備庫看到的是另外一個主機名，出現問題的時候會比較糾結。

還有一些是需要後期去改進的地方，當然也是自己想一想看看怎麼實現了。
怎麼透過主庫抓取到備庫的資訊情況，目前的情況如果建立了單向信任關係，其實實現思路還是比較清晰的。
怎麼判別主庫和備庫是否在同機房
怎麼判別切換後的ip是否可用
怎麼判別ILO資訊是否有效，怎麼保證在切換IP之後始終保持操作的可持續性。