藍的成長記——追逐DBA(13):協調硬體廠商,六個故事:所見所感的“伺服器、儲存、交換器”,dba硬體廠商

來源:互聯網
上載者:User

藍的成長記——追逐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

相關文章

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.