oracle 11g RAC 的一些基本概念（三）

標籤：des   style   blog   http   使用   os   io   檔案   

Grid Infrastructure共用組件 Grid Infrastructure使用兩種類型的共用裝置來管理叢集資源和節點：OCR(Oracle Cluster Registry)和表決磁碟。Oracle 11.2引入一個新的檔案，稱作Oracle Local Registry(OLR)，它只允許存放在本地。 OCR和OLR 

OCR為所有節點所共用，包含了叢集資源的所有資訊和 Grid Infrastructure需要的操作許可。為了實現共用，OCR需要存放在裸裝置、共用塊裝置、類似OCFS2的叢集檔案系統或者ASM上。在Grid Infrastructure中，只有通過升級而來的系統才支援非ASM管理的OCR，如果是新的安裝，你必須使用叢集檔案系統或者ASM。在RAC10和11.1中，OCR可以有1個鏡像，而到了11.2，則增加到了5個拷貝。

Grid Infrastructure每4個小時自動備份一次OCR，並保留一些備份用以恢複。RAC11.1中引入一個選項來手動備份Cluster Registy，以root使用者運行診斷程式時將執行附加的完整性檢查。Clusterware11.1通過Oracle Universal Installer簡化了Cluster Registry在共用的塊裝置上的部署，在此之前，需要手動進行一個移動OCR到塊裝置上的過程。當你在Red Hat 4或SLES10上，在RAC11.1中使用裸裝置，需要通過udev來手動對裸裝置進行配置。Oracle Support中對這個配置過程提供了說明，單路徑和多重路徑串連共用儲存的方法有所不同。

在一些罕見的情況中，OCR可能會被毀壞，此時就需要從備份中來還原。根據毀壞的嚴重性，可能從一個鏡像中來還原就足夠了，也可能需要從備份中來還原。只能通過Oracle提供的工具來管理和維護OCR，如果直接對OCR中的內容進行轉儲和修改，造成的配置問題Oracle將不予支援。

Oracle 11.2中引入另一個叢集設定檔，叫OLR。這個檔案在每個節點的Grid Infrastructure安裝目錄中都有自己單獨的拷貝。OLR儲存了叢集啟動初期OHAS使用的重要的安全環境。定位voting盤時需要用到OLR和網格隨插即用設定檔，如果它們儲存在ASM中，GPnP的profile中的discovery相關字串將被叢集同步進程用來尋找它們。在叢集軟體啟動的後期，cssd進程將啟動ASM執行個體來串連OCR檔案。然而，它們的路徑儲存在/etc/ocr.loc檔案中，和RAC11.1中一樣。當然，如果voting檔案和OCR如果儲存在一個共用的叢集檔案系統上，ASM執行個體不需要也不會啟動，除非其他資源需要使用到ASM。

配置Voting Disks 若一個節點在指定時間內(countdown-threshold)無法響應其他節點的心跳請求，這個節點將被踢出叢集。與OCR類似，voting disk和它的鏡像都必須存放在共用儲存上(11.1中支援3個voting disks，11.2中增加到15個)。和OCR一樣，Grid Infrastructure只在升級的系統上支援裸裝置，新安裝的只支援叢集檔案系統或ASM。塊裝置和裸裝置在Oracle12中將不再支援。Oracle強烈建議在不同的位置上使用至少3個voting disks。當使用ASM管理voting disks時，你需要注意磁碟組和故障組的冗餘層級。注意，voting disk的所有拷貝都在一個磁碟組裡面，你不能將voting disks分布在多個磁碟組中。當使用外部冗餘的磁碟組，你只能有1個voting disk。使用normal redundancy冗餘層級需要至少3個故障組來儲存3個voting disks，high redundancy冗餘層級更加靈活，它支援多達5個voting disks。

 

使用ASM 

ASM是oracle10.1中開始引入的，它是Oracle的物理資料庫結構上的一個支援叢集的邏輯卷管理器。可以儲存在ASM中的檔案包括控制檔案、資料庫檔案和線上重做日誌(還有spfile和歸檔日誌)。直到11g r2，都不能儲存任何類型的作業系統檔案。

ASM支援的檔案類型每個版本都不太一樣。下面貼出10.2和11.2的列表以供參考比較：

10.2

 

11.2：

 

ASM建立在ASM disk、Failure groups、ASM disk groups概念的基礎上的。

幾個ASM disk構成一個ASM disk group。與LVM類似，一個ASM disk就相當於LVM裡的一個physical volume。與LVM不同的是，共用一個共同的故障點(例如磁碟控制卡)的幾個ASM disk可以組成一個failure group。一個ASM disk group可以用來儲存物理資料庫結構：資料檔案、控制檔案、redo日誌和其他一些檔案類型。與linux裡的邏輯卷管理器(LVM)相比較，disk group上面沒有再建立邏輯卷，取而代之的是，資料庫中的所有檔案進行了邏輯分組放在disk group上的一個目錄裡。ASM中不需要檔案系統，這也是為何ASM相對傳統的LVM更具效能優勢。

 

 

Grid Infrastructure引入了ASM叢集檔案系統(ACFS)，消除了儲存通用用途檔案的限制。ASM使用stripe-and-mirror-everything方式來提供最佳效能。

ASM和ACFS的使用不受叢集的限制；單一實例oracle同樣可以通過它得到很多好處。技術上，Oracle ASM被應用為一種特殊的Oracle執行個體，它有自己的SGA，但沒有持續的字典。在RAC中，每個叢集節點有且只有一個單獨的ASM執行個體。當啟動的時候，每個執行個體會通過叢集軟體中的初始化參數在Grid Infrastructure檢測到ASM磁碟組資源。每個執行個體將掛載這些磁碟組。通過賦予正確的許可權(ASM11.2中引入了存取控制清單(ACLs))資料庫可以訪問它們自己的資料檔案。使用ASM需要應用OMF，這意味著不同的資料庫檔案管理方式。RDBMS執行個體中的初始化參數，例如db_create_file_dest和db_create_online_dest_n，還有db_recovery_file_dest，指定了相關的檔案儲存體在哪個磁碟組中。當需要建立一個新的檔案時，OMF將以以下格式來建立：+diskGroupName/dbUniqueName/file_type/file_type_tag.file.incarnation 給個例子：+DATA/oradb/datafile/users.293.699134381

ASM允許你執行許多線上操作，在ASM11.1及更高版本中，可以以滾動方式(rolling fashion)進行升級，最小化對資料庫的影響。

ASM在裸分區層級上進行操作；為了降低產品系統的開銷，應該避免使用LVM2邏輯卷。在NFS上ASM同樣是被支援的。但是，代替直接掛載檔案管理工具給出的目錄，需要用dd工具建立的零填補檔案作為ASM卷。使用NFS的時候，你需要和供貨商協商，讓他們提供最佳實務的文檔。

有特殊需求的環境，比如大於10TB資料量的海量資料庫，可以在磁碟組層級從可定製的盤區(extent)大小上得到好處。一個通用的儲存最佳化技術包括只使用磁碟邊緣位置，比使用其他位置能提供更高的效能。ASM的智能資料分布允許管理員來定義具備更高速度和頻寬的作用區。經常訪問的檔案可以放置到這些位置來提高效能。硬碟製造商即將推出扇區大小為4k的硬碟，儲存密度增加，且更快，容量更大。ASM為此做好了準備，它提供了磁碟組的一個屬性，叫sector size，可以設定為512位元組或4k。

大部分安裝中，一個典型的工作流程：儲存管理員提供叢集的所有節點上用來做ASM disk的儲存；系統管理員為這些新的塊裝置建立分區，做多重路徑配置，使用ASMlib或udev將這些分區後的塊裝置標記為候選磁碟；移交到資料庫小組後，Oracle管理員可以配置ASM disk和ASM磁碟組。這些操作都可以線上完成，不需要重啟伺服器。

 

ASM disk.ASM disk是ASM的基本組成單位。當一塊ASM候補磁碟被添加到磁碟組中時，中繼資料資訊被寫入到它的頭部，使得ASM執行個體能認出這塊磁碟並掛載到磁碟組中。在存放裝置陣列中，磁碟故障經常發生。個別磁碟被高強度使用，它們發生故障是很正常的。大多數情況下，磁碟陣列能根據使用的保護層級，通過鏡像磁碟或同位資訊來恢複發生故障的磁碟資料。ASM中的磁碟故障不經常發生，因為大多數情況下都是使用經過磁碟陣列保護的LUN。但是，如果當一個ASM保護的磁碟組中的磁碟發生了故障，需要緊急替換故障的磁碟以免它被丟棄。在ASM 11.1中引入一個新的參數叫做磁碟修複時間(disk repair time)，使管理員可以修複短暫的磁碟故障，而不需要進行一個全域的調整操作。當一個磁碟被從一個磁碟組中添加或刪除時，會發生重新調整操作，對磁碟組中的成員重新進行條帶。根據ASM磁碟組的大小，這個調整可能會很耗時。若管理員能幸運地在重新調整操作發生之前使故障的ASM磁碟回到磁碟組中，磁碟組將能很快恢複到正常狀態，因為只需要應用有資料改變的地區(dirty region)的日誌即可，不需要對整體全新進行調整。根據儲存背景使用，LUN可以通過陣列的RAID層級得到保護，也可以是一個沒有經過保護的儲存的集合(JBOD)。 ************************************************************************************************************************************************************************************************ASMLib和udev ASMLib和udev都解決了裝置名稱固定的問題。在linux中，裝置的檢測和枚舉的順序並不是固定的。這和在Solaris中不一樣，舉個例子，除非一個磁碟在陣列中從物理上移動了，否則裝置名稱(例如c0t0d1p1)不會改變。沒做多重路徑的存放裝置陣列的重新設定在linux中會有很大的問題：一個裝置原先在作業系統中顯示為/dev/sda可能會在重啟後被重新對應為/dev/sdg，僅僅是因為作業系統檢測到它比上一次啟動時晚了一點。基於裝置名稱的裸裝置映射註定是要失敗的。首先看看udev的解決方案。一個SCSI裝置的world-wide-ID(WWID)不會發生改變，在udev中利用了這一點制定一個規則，這個規則建立一個映射，它定義裝置/dev/raw/raw1總是指向SCSI ID是xxxx的LUN中。udev的主要問題是，它的配置不夠直觀和易用。由於udev不能複製配置，在叢集中的每個節點上管理員都需要去維護udev配置。(我們可以使用udevinfo -q path -n /dev/sda1 來查看/dev/sda1對應的udev裝置名稱，該路徑在/sys下)配置了多重路徑的儲存則不會有這個問題，因為另一個軟體層(比如，devicemapper-multipath包)或供貨商指定的軟體會建立一個邏輯裝置。ASMLib提供了另一種方式。ASMLib工具可以在http://oss.oracle.com中免費下載，它使ASM磁碟的管理變得非常簡單。ASMLib由3個RPM包組成：一個核心模組、實際ASMLib和支援工具。在使用一個LUN作為ASM disk前，你可以使用ASMLib工具通過將中繼資料資訊添加到磁碟頭部來標記它，然後ASMLib就可以識別出這個新的LUN，將其作為添加到ASM disk group的一個可能的候選。重啟的時候，ASMLib將掃描磁碟頭部的資訊來識別ASM disk，不管物理裝置名稱在啟動過程中變成了什麼。它保證了裝置名稱的穩定性，而且成本非常低。ASMLib是一個核心模組，在內部分配自己的記憶體結構，它可以在單路徑和多重路徑下配置。************************************************************************************************************************************************************************************************ ASM Disk Group ASM磁碟組有三個冗餘層級：外部冗餘；一般冗餘；高度冗餘當建立一個外部冗餘的磁碟組時，ASM讓存放裝置陣列來承擔資料保護的責任，不會做任何的鏡像。它會在磁碟組中的ASM disk間做預設盤區大小為1M的條帶。寫入錯誤會迫使ASM磁碟被卸載。這將產生嚴重的後果，因為該磁碟上的盤區沒有任何可用的拷貝，整個磁碟組都會變得不可用。在普通冗餘層級下，ASM將條帶和鏡像每個盤區，在一個盤區寫入到磁碟中時，會有另一個盤區寫入另一個故障組來提供冗餘。在ASM11.2中，單個的檔案可以用來做條帶和鏡像；預設做一個雙向的的鏡像。普通冗餘可以容忍磁碟組中的一個ASM磁碟發生故障。高度冗餘提供了更進階別的保護，它預設提供條帶和鏡像，建立主盤區的兩個額外的拷貝，可以容忍磁碟組中兩個ASM磁碟的故障。 Failure GroupFailure group是一個邏輯的磁碟組，當其中一個組件發生故障，整個磁碟組都將不可用。打個比方，屬於一個SCSI控制器的磁碟組成一個failure group，如果這個控制器發生故障，所有的磁碟都不可用。在normal和high冗餘中，ASM使用failure group來儲存資料的鏡像拷貝。如果沒有明確配置，每個ASM disk組成自己的failure group。Normal redundancy磁碟組需要由至少2個failure group來組成，high redundancy磁碟組需要至少3個。然後，建議使用比這個最小值更多的fail group來提供額外的資料保護。ASM預設從一個ASM disk group中的primary extent中讀取，在一個extended distance叢集中，如果primary extent在遠端存放裝置陣列上，可能會導致效能問題。ASM 11.1引入了一個首選的鏡像讀取來解決這個問題：每個ASM執行個體都可以被指定從本地extent的拷貝中讀取，不管它是primary extent還是copied extent。

ASM安裝與管理選項 在Oracle 11.1以前，最佳實務是以單獨地安裝ASM，這提供了可以單獨升級叢集軟體和ASM的好處。比如，叢集軟體和ASM可以升級到11.1.0.7，而資料庫還保留在原來的版本。這個最佳實務中，有三個標準的Oracle安裝目錄：叢集軟體、ASM、資料庫如果需要的話，ASM 11.1可以安裝在與安裝RDBMS不同的作業系統使用者下，Oracle對此解釋說，資料庫與儲存管理間的角色獨立是很多網站的一般實務。可以通過SQL*Plus、企業管理器(dbconsole)或者DBCA來管理ASM。在Oracle 11g Release 2中，ASM現在已經是Grid Infrastructure的一部分，不管在單一實例還是RAC環境中。一個新的配置助手asmca接受並擴充了11.1的DBCA中提供的功能。ASM也不再可以從RDBMS Oracle home以外的地方啟動。asmca增加了對另一個叫做ASM Cluster File System的ASM新特性的支援。一個叫SYSASM的新的超級使用者角色的引入使角色分離成為可能，就像Oracle 9i以後的SYSDBA一樣。你可以將SYSASM許可權綁定在不同於SYSOPER和SYSDBA使用者的角色中。轉載：http://blog.sina.com.cn/s/blog_5fe8502601016atp.html