這篇文章以實際為客戶部署Oracle 11gR2 RAC為例，探討實施過程中對軟硬體產品相容性和Oracle Database最佳實踐的關注，個人覺得這兩點非常的重要。
客戶的硬體是兩臺IBM X3850，作業系統採用Oracle Linux，儲存是EMC。這篇文章僅討論伺服器與作業系統的相容性，其他軟硬體相容性不在這篇文章討論。

我們首先應該考慮的就是IBM X3850與Oracle Linux的相容性問題，這關係到我們裝什麼版本的作業系統。下面是IBM X3850的相容性列表：

由於Redhat Linux和Oracle Linux核心和軟體基本是一致的，IBM並沒有針對Oracle Linux提供相容性列表，所以這裡我們參考for RedHat Linux的相容性內容。

從上面的列表中可以很清晰的看到，IBM X3850 X6和Red Hat Enterprise Linux 5 Server x64 Endition已經不相容了，換句話說，我們不能再在X3850上安裝Oracle Linux 5的作業系統，所以考慮到作業系統的釋出時間和Oracle產品的釋出時間，最終我們選擇了Oracle Linux Enterprise x86_64bit 6.4版本的作業系統。

針對IBM X系列伺服器的相容性列表可以參考如下的頁面：

到目前為止還很少在Oracle Linux 6上部署Oracle RAC，更多的還在使用Oracle Linux 5，所以當然要好好的看看Oracle RAC for Linux的最佳實踐：
《RAC 和 Oracle Clusterware 最佳實踐和初學者指南 (Linux) (Doc ID 1525820.1)》

考慮到篇幅和該文會不斷的更新，這裡不轉載該文的內容，只將在部署過程中發現的Oracle Linux 5和Oracle Linux 6的差別列出來：

1.如果您的叢集執行在RedHat 6, OEL 6, SLES 11 或 UEK2 核心上，請確認關閉THP（Transparent HugePages）以防止其帶來的效能問題導致節點和例項驅逐。
但是，我們仍然推薦使用一般的HugePages(THP和一般HugePages是不同的)。有關更多資訊，請參考Document 1557478.1。

透過在作業系統的/etc/rc.local檔案中加入以下的內容來關閉THP：
if test -f /sys/kernel/mm/transparent_hugepage/enabled; then
echo never > /sys/kernel/mm/transparent_hugepage/enabled
fi
if test -f /sys/kernel/mm/transparent_hugepage/defrag; then
echo never > /sys/kernel/mm/transparent_hugepage/defrag
fi

2.設定 vm.min_free_kbytes 核心引數保留 512MB，以允許 OS 更快地回收記憶體，這樣可以避免記憶體低的壓力。有關更多資訊，請參考 Document 452326.1，Document 452000.1 和 Document 1367153.1。

透過在/etc/sysctl.conf檔案中加入以下內容：
vm.min_free_kbytes=524288

另外還需要注意：對於核心版本小於等於2.6.18的系統，請設定核心引數vm.swappiness=100。壓力測試已經證明，對於核心版本小於等於2.6.18的系統，設定vm.swappiness = 100（預設值為60），能夠降低或延緩由於大量的客戶端連結或連結風暴導致的嚴重的記憶體壓力時節點驅逐的發生。

3.對於Linux 6.x 平臺，您可能會發現在limits.conf檔案中對引數nproc的修改會被忽略-請參考Document 1487773.1獲得更多資訊。

透過在/etc/security/limits.d/90-nproc.conf修改成如下內容來實現對nproc的限制：

* soft nproc 16384
root soft nproc unlimited

4.在 RedHat EL4 或更高版本中，建議設定 aio-max-nr=1048576（ 11g 中設定為 4194304）。

5.根據工作負載，rmem_max 和 wmem_max 核心引數應增加到超過預設值 256kb。這些值可確定為每個開啟的 socket 分配多少核心緩衝區記憶體進行網路讀取和寫入：
net.core.rmem_default=262144
net.core.rmem_max=4194304 (for 11g and all RDS implementations)
net.core.rmem_max=2097152 (for 10g)
net.core.wmem_default=262144
net.core.wmem_max=1048576 (with RDS use at least 2097152)

這裡多說一句，對於11.2.0.2以上的Oracle RAC，我們應該考慮在每臺伺服器上啟用4個HAIP，和對心跳網路使用Jumbo Frames來提供心跳的效能，這點同樣的重要！

有關Jumbo Frames巨型幀的內容可以參考以下兩篇文章：
http://blog.itpub.net/23135684/viewspace-752040/
《Recommendation for the Real Application Cluster Interconnect and Jumbo Frames (Doc ID 341788.1)》

6.對於 Linux Kernels 2.6.31 和更高版本，已經修正了 Reverse Path Filtering 中的一個 bug。由於此 bug 的修正，可能會在擁有多個私網的系統上產生資料包阻止/丟棄的情況。為避免出現這種情況，請將私網網路卡的 rp_filter 核心引數設定為值 0（禁用）或 2（寬鬆）。有關更多資訊，請參考 Document 1286796.1.

透過在/etc/sysctl.conf檔案中加入如下的內容來避免出現此bug：
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0
net.ipv4.conf.eth3.rp_filter = 0
net.ipv4.conf.eth5.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0

此次部署我們為客戶選擇的是Oracle 11.2.0.4.0 RAC Database，以上只是節選了部分最佳實踐中的內容，詳細的內容還應完整的參考《RAC 和 Oracle Clusterware 最佳實踐和初學者指南 (Linux) (Doc ID 1525820.1)》。

透過這篇文章我想說明兩點，一是軟硬體的相容性非常的重要，釋出時間相差很大的兩個產品（軟硬體）之間很可能是不相容的，例如，採購新的硬體應該安裝較新的作業系統來支撐它，隨之資料庫軟體也應該選擇匹配的版本（釋出事件相近，檢視產品相容性列表支援），這是作業系統和Oracle產品穩定執行的基石。二是Oracle釋出的最佳實踐，這點同樣重要，這是大量工程師在實踐過程中總結出來的經驗，精華所在，參考最佳實踐進行部署能夠進一步的保證Oracle資料庫系統的穩定、高效，是資料庫工程師的一個好習慣。

--end--

Oracle資料庫實施產品相容性與最佳實踐探討

相關文章