之前也寫過一篇比較基本的文章,也算是自己對運維平台的一個基本思考。當然想法簡單,而且缺乏實踐,但是朝着這個方向邁進是沒有錯的。從我的觀點來看,現在能夠實作半自動化運維已經很了不得了。而且把這些工作能夠落到實處,更是不易 。
比如舉幾個簡單的例子。
比如對于資料庫的資料檔案添加這個功能來說,其實完全可以實作自動化擴容。但是是否完全可行呢,我覺得還有待斟酌。比如temp設定為自動增長,如果出現了sql語句導緻的問題,結果導緻temp被撐爆,聽說過temp無限擴充達到TB級的問題,最後還是sql語句的問題導緻。
那麼這個資料檔案是否支援擴充,怎麼擴充,這個應該一方面是根據系統資源進行權衡,另一方面就得根據具體的系統情況來決定了。這也就引申出我今天想說的關于中繼資料的管理。
順便講個小段子,幾個同僚跑過來找我,說有一個緊急操作需要DBA配合,然後想讓我去和他們開個會,我就不喜歡那種沒有結果的會議讨論,從DBA的角度來說,提供完整的操作步驟,正确的腳本,你們來評估業務可行性,我們來評估從安全,性能,業務上是否需要支援和改進,當然我說的也很簡單,我就是個幹活的,你來提供詳細的步驟和參考,我來評估和執行,會我還是不參加了吧。其實話說回來,如果我們隻是簡單評估和執行,那麼我們工作的含金量會大大降低,外企都很強調的design,DBA也是需要加強這方面的功底的。老是搬磚,時間長了就隻會搬磚了。
是以這些design的工作怎麼做,不是一下子高屋建瓴,我們來想想我們能夠做些什麼。從整個運維系統,運維平台的角度來考慮,中繼資料管理還是根本,但是似乎沒有什麼人重視。
從我的角度來講,我認為中繼資料的管理,除了資産層面的資源狀态管理,從運維平台來說,還是有很多值得注意的地方。
我大體列舉了一部分,從我的角度來看認為還是非常有必要去考慮的。
這些中繼資料看起來非常瑣碎,但是一旦管理起來,作用就非常巨大了。比如給你最短的時間做資源盤點,檢視目前的5000台伺服器中哪些伺服器是在redhat的某個子版本,簡單評估是否可以更新等等。這些沒有中繼資料管理,簡直不可想象。是以我把中繼資料的考慮劃分成了下面的幾個部分,當然還需要不斷完善。
系統情況,核心版本,更新檔,作業系統版本。
硬體配置:基本的硬體配置情況 cpu cpu合數,實體CPU數
記憶體 記憶體大小
swap分區設定:swap分區的設定,swap的大小是否合理,如果是在有些雲伺服器中,預設是不開啟swap的。 磁盤分區設定:磁盤分區的情況,盤數,raid級别等 crontab: 自動任務的情況,是否有ntp的自動同步,是否有定時的業務排程,是否有定時的備份和系統檢查。
防火牆:防火牆開設的端口,開放的用戶端 主機名:伺服器的主機名管理,尤其是在很多系統遷移中,做了大量的主從切換等情況下,有時候從主機名根本分不出來一台伺服器到底是主庫還是備庫。 ip配置 内網外網,網絡ip的設定,/etc/hosts中的配置,比如在mysql中的主機名dns權限解析。如果主從切換之後,是否備庫一定會有主庫所擁有的權限。 主備,主從關系配置:主從切換之後,是否從庫或者備庫一定能夠勝任,備庫是否已經完全做好了時刻切換的準備。根據主庫是否能夠找到比對的備庫,或者根據備庫關聯到主庫。
核心參數配置,核心參數的設定,是否初始化的時候已經合理規劃還是根據感覺想到哪裡做到哪裡。有些核心參數設定是否是按照系統硬體資源來設定,是否考慮周全。之前就碰到過一個資料庫程序數設定為150,但是資源配置非常好,但是自己申請調高process之後重新開機資料庫的時候,發現原來的核心參數就取的預設值,是以資源好,但是軟體層面的性能跑不上去。 端口配置:對于資料庫來說,開放了哪些端口,哪些端口處于閑置狀态 資料庫參數 init.ora my.cnf,對于oracle,mysql而言,參數的管理也很有必要,如果一台伺服器當機,想找到之前的一些完整配置,不一定備庫的就和主庫一樣,到底哪裡不同,哪些參數可能設定不和規範,通過統一的參數管理就可以得到一些答案,比如對于oltp,olap來說,哪些參數需要考慮,10g,11g中的特性參數如何取舍,哪些需要統一。 外部檔案挂載,系統中是否有外部的挂載點,比如nfs,其它共享存儲等。 備份情況,系統的備份情況,資料的備份情況等等。 當然從資料庫的層面進行更多的思考,需要做到具體的事情就更多了,我們後續再做補充。
最後說一句,聖誕快樂,其實提這個節日的人多,過節的少,該加班加班,幹睡覺睡覺,生活快快樂樂,天天都是節日:)
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23718752/viewspace-1960938/,如需轉載,請注明出處,否則将追究法律責任。
轉載于:http://blog.itpub.net/23718752/viewspace-1960938/