通過服務器信息維護進行“半自動化”運維

在很多的時候，隨著工作的持續開展，可能會接手更多的服務器資源，這個時候我們手里就不只是一兩臺服務器那么簡單，可能幾十個，上百個，甚至上千個，這個時候服務器信息的維護就變得尤其重要，拋開業務線的規劃，對于DBA來說，掌握服務器的信息，做到知根知底，才能在問題發生的時候合理處理問題。

服務器信息可以分成幾個方面來看，比如操作系統情況，內核版本，硬盤，內存，空間使用情況，累計運行時間，數據庫實例運行時間，系統中的swap爭用情況等等，盡可能根據實際的情況進行一些維度的劃分和細粒度的歸納。

比如說在生產中，考慮容災，會有一主一備，甚至一主多備，這個時候，我們也需要考慮主備環境中的硬件資源的情況，資源使用情況。

舉幾個例子。

比如我們手頭有兩臺服務器，是作為異地容災的，我們通過簡單的解析得到了兩臺服務器的初步信息。

服務器一：RHEL 6，空間使用近70G，120G內存，24CPU，服務器已啟動590多天，數據庫實例啟動自2013年。

服務器二：RHEL 4，空間分配達3.1T，使用率達2.5T，40G內存，24CPU，服務器已啟動280多天，數據庫實例啟動自2014年，swap爭用較高。

我們來看看這兩臺服務器信息在特定的場景中會有哪些考慮，當然有些細節還沒有羅列出來。

第一個部分就是IP信息，dataguard的場景作為異地容災尤為重要，如果主備在同一個機房，勢必會給災備帶來一些隱患，比如機房斷電，這種情況下影響就會凸顯出來。

然后我們來看主備的系統版本，一個是redhat 6，一個是redhat 4，其實也可以搭成主備環境，但是多多少少會有一些影響，比如有些基于操作系統級的參數在不同的系統版本中可能有不同的表現。

我們再來看一看空間分配，第一臺是作為主庫來使用的，可以看到使用了近70G的空間，但是備庫卻又3T左右的空間，使用率卻要高得多，這個時候就需要評估是否空間資源使用是否合理，是否有一些額外的空間消耗沒有釋放。

再來看看內存資源，一臺服務器是120G，一臺是40G，在這種情況下，勢必會對sga的配置會有一定影響，對于系統中的hugepage等的設置也會有所不同，配大了可能備庫不能接受，配小了又有些浪費。

還有一些信息，比如主備庫的系統運行時間，可以看到主庫服務器已經運行了近600天，而備庫有差不多300天的樣子，在這個時間范圍內，可能發生了一些資源的分配最后導致了系統資源，硬件資源出現了一些差別。

最后一個要點就是在備庫中存在著較高的swap現象，這個從數據庫的角度來看，還是沒有能夠合理的利用large page或者hugepage。而在主庫中就沒有明顯的swap爭用。這個時候如果發生了災難切換，切換到備庫之后，可能在備庫中就會存在一些潛在的性能問題。

再比如我們有如下的兩臺數據庫服務器，一部分資源作為dataguard使用，另外一部分資源作為其它的輔助資源來提供，怎么理解呢，可以簡單來說，一臺服務器類似主庫，另外一臺服務器做為備庫，同時根據情況還需要跑其它的業務數據庫。

比如我們得到了兩臺服務器的資源情況如下：

RHEL 5，空間分配350G，使用近170G，8G內存，服務器已啟動780多天，數據庫實例啟動自2013年,同時有xxxxx和xxxx兩個數據庫實例在跑，swap爭用較高。

RHEL 5，空間分配234G，使用近170G，8G內存，服務器已啟動近500天，數據庫實例啟動自2014年，同時又xxxx和xxxx，xxxx三個數據庫實例在跑，swap爭用較高。

在這種情況我們怎么來分析呢?

這個時候我們可以看到系統版本，空間資源使用情況都差不多，系統的內存相對有些緊張，跑了好幾個數據庫勉強才有8G的內存空間，主庫服務器上有兩個數據庫實例在跑，而備庫中有兩個備庫實例在跑，另外還有一臺其他業務的數據庫實例，這種情況下，就可能會有一些災難場景，我們可以了解到主庫服務器已經運行了近800天，已經兩年多了，而備庫也有差不多1年半了。在這種情況，系統的資源使用情況比較緊俏，很可能就會出現問題。一旦出現問題，就會有問題的放大效應，比如備庫出現了介質損壞，那么額外的那個數據庫實例就沒有辦法恢復了，因為本地的空間情況剩余也只有50G左右，如果規劃系統的rman備份，也沒有多少空間可用，而且同時主庫已經跑了2年多了，壓力還是相似甚至開始加大的狀態下，主庫長期在這種資源緊俏的時候更容易出現問題，這個時候主庫出現問題，備庫的隱患還是沒有解除，因為這個時候系統的壓力全部都到了備庫上了。如果備庫壓力突增，更可能出現問題。

所以這個時候與時俱進做一個前瞻的準備還是不錯的，比如我們的主庫資源配置較低，但是我們配備了一個高配的備庫，這樣就相對可以輕松很多，如果出現問題，問題處理的余地還很大，甚至我們還是希望主庫能夠切換到備庫上來，這樣出現問題之后切換系統的穩定性反而更強了。

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