半自動化運維之伺服器資訊維護

在很多的時候，隨著工作的持續開展，可能會接手更多的伺服器資源，這個時候我們手裡就不但是一兩臺伺服器那麼簡單，可能幾十個，上百個，甚至上千個，這個時候伺服器資訊的維護就變得額外重要，拋開業務線的規劃，對於DBA來說，掌握伺服器的資訊，做到知根知底，才能在問題發生的時候合理處理問題。
伺服器資訊可以分成幾個方面來看，比如作業系統情況，核心版本，硬碟，記憶體，空間使用情況，累計執行時間，資料庫例項執行時間，系統中的swap爭用情況等等，儘可能根據實際的情況進行一些維度的劃分和細粒度的歸納。
比如說在生產中，考慮容災，會有一主一備，甚至一主多備，這個時候，我們也需要考慮主備環境中的硬體資源的情況，資源使用情況。
舉幾個例子。
比如我們手頭有兩臺伺服器，是作為異地容災的，我們透過簡單的解析得到了兩臺伺服器的初步資訊。
伺服器一：RHEL 6,空間使用近70G,120G記憶體，24CPU,伺服器已啟動590多天，資料庫例項啟動自2013年，
伺服器二：RHEL 4,空間分配達3.1T,使用率達2.5T,40G記憶體24CPU,伺服器已啟動280多天,資料庫例項啟動自2014年,swap爭用較高
在這種情況我們怎麼來分析呢，
這個時候我們可以看到系統版本，空間資源使用情況都差不多，系統的記憶體相對有些緊張，跑了好幾個資料庫勉強才有8G的記憶體空間，主庫伺服器上有兩個資料庫例項在跑，而備庫中有兩個備庫例項在跑，另外還有一臺其他業務的資料庫例項，這種情況下，就可能會有一些災難場景，我們可以瞭解到主庫伺服器已經執行了近800天，已經兩年多了，而備庫也有差不多1年半了。在這種情況，系統的資源使用情況比較緊俏，很可能就會出現問題。一旦出現問題，就會有問題的放大效應，比如備庫出現了介質損壞，那麼額外的那個資料庫例項就沒有辦法恢復了，因為本地的空間情況剩餘也只有50G左右，如果規劃系統的rman備份，也沒有多少空間可用，而且同時主庫已經跑了2年多了，壓力還是相似甚至開始加大的狀態下，主庫長期在這種資源緊俏的時候更容易出現問題，這個時候主庫出現問題，備庫的隱患還是沒有解除，因為這個時候系統的壓力全部都到了備庫上了。如果備庫壓力突增，更可能出現問題。
所以這個時候與時俱進做一個前瞻的準備還是不錯的，比如我們的主庫資源配置較低，但是我們配備了一個高配的備庫，這樣就相對可以輕鬆很多，如果出現問題，問題處理的餘地還很大，甚至我們還是希望主庫能夠切換到備庫上來，這樣出現問題之後切換系統的穩定性反而更強了。

所以說如果手頭擁有大量的伺服器資源，不妨還是適當規劃一些，看看是否能夠做一些合理的改變，在問題發生的時候更加從容一些，畢竟自動化運維是一個很大的方向，我們不能保證系統的資源都是完全一樣的，可能很多時候因為各種因素，會有很大的差別，這些系統資源的權衡是自動化運維所不能完全考慮到的，所以我還是希望這是屬於半自動化運維中的範疇。