藍的成長記——追逐DBA(13):協調硬體廠商,六個故事:所見所感的“伺服器、儲存、交換器”,dba硬體廠商
原創作品,出自 “深藍的blog” 部落格,歡迎轉載,轉載時請務必註明出處,否則追究著作權法律責任。
深藍的blog:http://blog.csdn.net/huangyanlong/article/details/43989939
【簡介】
個人在oracle路上的成長記錄,其中以藍自喻,分享成長中的情感、眼界與技術的變化與成長。敏感資訊均以英文形式代替,不會泄露任何企業機密,純為技術分享。
創作靈感源於對自己的自省和記錄。若能對剛剛起步的庫友起到些許的協助或共鳴,欣慰不已。
歡迎拍磚,如有關技術細節表述有錯誤之處,請您留言或郵件(hyldba@163.com)指明,不勝感激。
【前言】
這是一部個人記錄的成長雜記,既然步入到oracle的這片藍海,免不了一路的奔波與不斷的考驗。藉由此雜記與庫友們分享藍的成長曆程。
不知何時起對藍有了一種說不出來的癡迷,癡迷其廣博,癡迷其深邃,癡迷於近在咫尺卻又遙不可及。
而又說不清從何時起,注視於oracle的紅色耀眼,照亮出眼前的一道光,未知與迷惑在自己的腳下開始初露些許人生的充實與青春的回饋。
在追逐於DBA夢想的道路上步步前行。
___________________________________________________________________
面對自己不懂的知識面,抓住機會,就要“多問多學多看”。
——深藍
___________________________________________________________________
第一個故事:多看——伺服器磁碟的損壞
現象:伺服器啟動不正常。
開始說之前,想提的是,作為一個想從事資料庫方面或是IT領域的人士們,不要認為小機率的事情就不會發生。因為這次發生的就是小機率。
下面記錄了一個小操作,源於伺服器的一塊磁碟損壞,致使伺服器在安裝作業系統後,啟動卡在捲軸介面。開始的時候,不知道這是怎麼回事。看到系統廠商的工程師,敲擊了下“ESC”,這才雲開霧散,因為這時我看到了系統的啟動過程,報出了檢測一塊dev裝置(磁碟)時遇錯了,而無法繼續下去。突然想到這塊磁碟在昨天硬碟指示燈確實紅燈亮起過,報過故障了。只不過後來恢複正常綠燈了(不知道為什麼),想畢應該是這塊硬碟仍然存在不確定問題(排除了鬆動,懷疑存在壞道或控制器損壞等原因)。於是藉由硬體廠商聯絡了伺服器廠商(浪潮原廠工程師),一番描述後,聯絡好第二天會到現場檢測。再之後,浪潮來的工程師更換了這塊故障磁碟,系統啟動恢複正常。因為磁碟做了RAID5,允許一塊磁碟損壞。所以作業系統和原磁碟資料並未損壞和丟失。而最終確定,系統無法啟動是因為自檢這塊磁碟時不通過,因為系統不通過檢測,系統就會反覆的對這塊磁碟進行檢測,從而出現了卡頓現象。
最後想說的是,這個伺服器是跟隨項目全新上線的,從系統整合商來裝系統,到我方在現場檢查硬體情況,前前後後,不出一周時間。而就在沒有任何業務壓力的情況下,一塊磁碟莫名其妙的壞掉了。但遇到這種情況,見得多了就不以為新奇了,任何電子產品都有可能出現不確定問題。這也就是為什麼會有容災方案的原因吧。哈,所以這才意識到,硬體廠商的質保期不是沒有用的,因為在出廠的時候,可能廠商就預見到了會有損壞的,這種情況是目前人為所不能控制的。但轉念一想,是不是暴漏本身產品的品質缺陷呢?聯想到了鎚子手機的碎屏險,是不是因為工程師預見了螢幕的破損機率大,於是就做出了一個質保的方案呢(我這裡胡思亂想了)。也懷念曾經的“諾基亞”,假設不給質保也不會擔心有損壞問題(品質好啊)。但,或許這正是人類科技水平發展的道路上,在探索的過程中必然要經曆的,進步是需要付出一定代價的。
至此,想再提一下這個簡單的操作:就是在啟動LINUX系統時,在進度條介面,如果我們點擊ESC就會看到系統啟動時進行的操作。如:
點擊“esc”,可以看到啟動過程,如下:
說實話,以前還真不知道。
學到了點皮毛,還是感覺慚愧,這個小操作竟然才知道,誒呀~~~。引以為戒了,不知道大家都知道不,反正我以前不知道,以後就知道了。
第二個故事:多問——什麼叫多重路徑?
來源於主機(PC-server)、小型機串連“光纖交換器”時,再串連“光纖儲存”,這樣就會形成多條鏈路,如果在主機上從儲存划出一塊盤,可能會在主機上映射出很多塊盤,會讓操作者無法選擇應該操作那一塊磁碟。為了避免這個繁瑣的磁碟鏈路,就會使用到多重路徑軟體,將多條路徑彙總到一起。既起到方便管控磁碟的作用,也起到負載平衡的效果,假設一條鏈路斷掉,其它鏈路仍然可用,這樣不會影響對於磁碟的訪問。
幾款多重路徑軟體:
(1)、IBM主機和IBM儲存:RDAC、MPIO、SDDPCM
(2)、日立的儲存:HDLM
(3)、EMC儲存:PowerPath
第三個故事:多學——儲存中的LUN?
(1)、初探LUN
LUN是SCSI協議中的名詞,是SCSI ID的更細一級的地址號,每個SCSI ID(Target ID)下面還可以有更多的LUN ID。對於大型磁碟陣列,可以生產幾百甚至幾千個虛擬磁碟,為每個虛擬磁碟分配一個SCSI ID是遠遠不夠用的。因為沒有SCSI匯流排最多允許16個裝置接入(目前32位SCSI標準最大允許32個裝置)。要在一條匯流排上放置多於16個物理裝置也是不可能的,LUN就是這樣一個次級定址ID。磁碟陣列可以在一個SCSI ID下虛擬多個LUN地址,每個LUN地址對應一個虛擬磁碟,這樣就可以在一條匯流排上產生眾多虛擬磁碟,以滿足需求。
後來,人們把硬體層次產生的虛擬磁碟,統一稱為“LUN”,不管是不是在SCSI環境下,雖然LUN最初只是SCSI體系裡面的一個概念。而由軟體產生的虛擬磁碟,統一稱為“卷”,比如各種卷管理軟體、軟RAID軟體等所產生的虛擬磁碟。
--摘自張冬瓜,大話儲存2
(2)、SAN
下面展示一個SAN儲存架構圖(來源於電子書中),如下:
SAN(storage area network):關於存放區域網路
網路,不僅僅指乙太網路、TCP/IP網,可以是SCSI網、PCI匯流排網、USB網等。RAID控制器,就相當於一個路由器,也就是協議轉換器。
將磁碟放到了主機外部,存放裝置和主機之間,就形成了又一個獨立的網路:存放區域網路(Storage Area Network,SAN)。
(摘自,張冬瓜,大話儲存2)。
(3)、儲存的規劃方案
最後,由於方案前期採購出現的錯誤(因為當時我方還未介入),沒有採購光纖交換器,而是採購的華為的S5700S系列,雖然效率上有些失望,但還是把我們應該做的工作做好吧。
完成儲存的劃分,其中包括儲存的RAID部署、儲存初始化、RAID分區(劃分儲存資料分割配置由我方提出,硬體廠商給予實施)、完成映射(在多伺服器系統內需要安裝多重路徑軟體)。
面對著12塊、6塊磁碟儲存盤陣,簡單闡述下儲存方案,如下:
儲存名稱 |
RAID方案 |
物理容量 |
可用容量 |
LUN劃分 |
資料庫儲存 |
RAID5+熱備盤1塊 |
12*3TB |
10*3TB |
(3*20G)+(55*500G) |
備份儲存 |
RAID5+熱備盤1塊 |
6*3TB |
4*3TB |
2*5119G |
資料庫伺服器 |
RAID5 |
6*1TB |
5*1TB |
4T+1T |
看一眼實物圖:
第四個故事:犯了低級錯誤之斷電
淩亂的線纜,還沒來得及整理的線纜,先體驗了一把突然斷電的爽快。這是發生的一次意外斷電以致使伺服器宕機。其實恢複這個很簡單,只需要到機房重啟即可。而這次,我犯了低等的錯誤。由於之前有過一次網路部門隨意拔掉了我們一次網線的經曆,我下意識的把這次認為是“人為事故”,看了一眼資料庫伺服器的狀態,指示燈運行正常的,就跑到了機櫃的後部查看電纜,如:
而這次我犯了錯誤。由於自己的粗心大意,直接去了網路部,找到了網路部門的工程師,並表示伺服器沒有問題,但是網路不通了。而網路工程師倒也沒有任何隱瞞說昨天有過一次斷電,不知道是否和這有關係。於是去查看了接入區域網路的連接埠線,但是沒有發現問題。然後查看了我方交換器的vlan設定,表示說可能斷電引起設定衝掉了。截止到此,我們在錯誤的方向上開始了天方夜譚。為什麼這麼說,原因有下:
1、路由器斷電不能使其配置失效(不知道當時網路工程師是故弄玄虛還是真的這麼想的,我差點就信了,誒呀~~,這裡我承認,我弱智了,難道還有把配置資訊放到記憶體裡的不成,額~~(⊙o⊙)。)
2、斷電後直接反應應該確認伺服器是否啟動,而不是去直接聯絡網路部(這裡我又二了一把,誒呀~~,又弱智一次)。之所以會產生如此低級錯誤,其實原因很簡單。其實我原本查看了伺服器,不過只是查看了資料庫伺服器,因為這兩台伺服器設定了通電後自動啟機了。而沒看其它伺服器,造成了這次低級錯誤的發生。
第五個故事:讓人鬱悶的PDU
電源的固定,簡單的事一拖再拖。跟協調的人有關,但之所以鬱悶,本無關的事變的有關了,而後又沒處理好,這就鬱悶了。
這個說來,本應該負責的部門不負責,也就是機房管理方,而硬體服務商、系統整合商或我們軟體開發商都表示不承擔這部分的工作。所以客戶頭也大了,連線纜還沒有進行布設(就像那樣,淩亂呐~~)。由於線纜沒有布設,機櫃中的線纜淩亂的被塞到了伺服器後面,給正常運行造成了安全隱患。
好在,在過了許久之後,終於,客戶自行解決了這個問題,我們的硬體裝置也總算是穩定下來了。
稍微瞭解一下PDU,PDU(電源配置單位), Power Distribution Unit也被稱為“機櫃電源插座”,如下兩張圖:
第六個故事:開闊視野——直面傳說中的“oracle一體機”
原以為神秘又高大上的一體機,沒成想,一個不小心,這個價值千萬元層級的裝置就這樣活生生的展現在了我的眼前。
記得之前在一節oracle公開課中,簡單瞭解了一下exadata(oracle一體機),在這裡做個簡單的回憶,從解決四方面問題入手的一體機。
(1)、如何解決傳統資料庫部署所帶來的效能問題?
傳統的資料庫部署:
儲存層:1、資料量增加IO瓶頸;2、資料分布不均;
網路層:頻寬不足
伺服器層:過多資料處理
解決思路:減輕負載、加寬頻寬、提高並行
1、加寬通道
2、減少資料量傳到資料庫伺服器
3、增加系統平行處理
理念化:
儲存橫向擴充,實現平行處理能力
儲存層:智能化、預先處理
伺服器端的卸載預先處理工作分擔到儲存層,處理完後返回給資料庫伺服器。
(2)、解決了資源獨立,無法共用的問題?
傳統資料庫:
分配給不同的主機,不是共用的,分配資源不均,有些資源不足,有些資源過度。生產環境動態變化,無法動態滿足負載的目標
設計原則:資源共用、資源控制
解決:
如:1、把儲存伺服器的資源變成一個儲存池,一個儲存池給一個或多個資料庫使用,伺服器都可以用到所有磁碟的能力,滿足IO輸送量;
2、對IO進行控制,根據業務的優先順序來處理。
(3)、解決複雜的資料庫系統均衡化配置?
傳統資料庫:
大型的儲存系統,EMC儲存;
分區;
裝置昂貴;
技術維護管理;
總的代價開銷非常大;
讓一體機實現效能均衡化:
使用exadata,平衡及最佳化的配置
主機、儲存、資料庫、應用程式:調優
exadata端到端最佳化:硬體軟體配置好了的
易於上線,不需設計、調優、維護、設定
(4)、如何解決系統的維護和擴容過程複雜
一體機:
簡化部署:消除複雜部署;
當天部署完成,獲得極限效能。
以上通過理論性、概述式的介紹了一下一體機,其中具體的技術細節並沒有涉及到,如果對於exadata的技術真正感興趣的朋友,不妨去看看官方手冊或參考文檔,相信會有所收穫的。
這裡對於一體機的瞭解我也是剛剛開始,就簡單介紹這些吧,畢竟還是菜鳥,O(∩_∩)O~
系列連結:
藍的成長記——追逐DBA(1):奔波於路上,挺進山東
藍的成長記——追逐DBA(2):安裝!安裝!久違的記憶,引起我對DBA的重新認知
藍的成長記——追逐DBA(3):古董上操作,資料匯入匯出成了問題
藍的成長記——追逐DBA(4):追憶少年情愁,再探oracle安裝(Linux下10g、11g)
藍的成長記——追逐DBA(5):不談技術談業務,惱人的應用系統
藍的成長記——追逐DBA(6): 做事與做人:小技術,大為人
藍的成長記——追逐DBA(7):基礎命令,地基之石
藍的成長記——追逐DBA(8):重拾SP報告,回憶oracle的STATSPACK實驗
藍的成長記— —追逐DBA(9):國慶漸去,追逐DBA,新規劃,新啟程
藍的成長記——追逐DBA(10):飛刀防身,熟絡而非專長:擺弄中介軟體Websphere
藍的成長記——追逐DBA(11):回家後的安逸,暈暈乎乎醒了過來
藍的成長記——追逐DBA(12):七天七收穫的SQL
原創作品,出自 “深藍的blog” 部落格,歡迎轉載,轉載時請務必註明出處,否則追究著作權法律責任。
深藍的blog:http://blog.csdn.net/huangyanlong/article/details/43989939