相當多的企業應用程式和虛擬化系統都有自己的建立容錯解決方案的機制。 具體來說，Oracle RAC（Oracle Real Application Cluster）是由兩個或多個 Oracle 資料庫伺服器組成的集群，它們協同工作以平衡負載並提供伺服器/應用程式層級的容錯能力。 要工作在這種模式下，您需要一個共享存儲，通常是一個存儲系統。
正如我們已經在我們的一篇文章中討論過的 ，儲存系統本身，儘管存在重複的元件（包括控制器），仍然存在故障點——主要以單組資料的形式出現。 因此，要建構可靠性要求更高的Oracle解決方案，「N伺服器-一個儲存系統」方案需要變得複雜。
當然，首先我們要決定我們要防範哪些風險。 在本文中，我們不會考慮針對「隕石已到達」等威脅的保護。 因此，建構地理上分散的災難復原解決方案仍將是以下文章之一的主題。 在這裡，我們將研究所謂的跨機架災難復原解決方案，即在伺服器機櫃層級建構保護。 機櫃本身可以位於同一房間或不同房間，但通常位於同一建築物內。
這些機櫃必須包含整套必要的設備和軟體，無論「鄰居」的狀態如何，都允許 Oracle 資料庫運作。 換句話說，使用跨機架災難復原解決方案，我們消除了故障風險：
- Oracle 應用程式伺服器
- 存儲系統
- 開關係統
- 機櫃內所有設備完全故障：
- 拒電
- 冷卻系統故障
- 外在因素（人為、自然等）
Oracle 伺服器的複製意味著 Oracle RAC 的運作原理，並透過應用程式實現。 交換設施的重複也不是問題。 但隨著儲存系統的重複，一切就沒那麼簡單了。
最簡單的選擇是將資料從主儲存系統複製到備份系統。 同步或異步，取決於儲存系統的能力。 對於非同步複製，立即出現的問題是如何確保與 Oracle 相關的資料一致性。 但即使有軟體與應用程式集成，無論如何，一旦主儲存系統發生故障，就需要管理員手動幹預，才能將叢集切換到備份儲存。
更複雜的選擇是軟體和/或硬體儲存“虛擬化器”，它將消除一致性問題和手動幹預。 但部署和後續管理的複雜性，以及此類解決方案的高昂成本，讓許多人望而卻步。
AccelStor NeoSapphire™全快閃陣列解決方案非常適合跨機架災難復原等場景 使用無共享架構。 該模型是一個雙節點儲存系統，使用專有的 FlexiRemap® 技術與快閃磁碟機配合使用。 謝謝 NeoSapphire™ H710 能夠提供高達 600K IOPS@4K 隨機寫入和 1M+ IOPS@4K 隨機讀取的效能，這是使用基於 RAID 的經典儲存系統無法實現的。
但 NeoSapphire™ H710 的主要特點是以單獨案例的形式執行兩個節點，每個節點都有自己的資料副本。 節點的同步是透過外部InfiniBand介面進行的。 透過這種架構，可以將節點分佈到相距最遠100m的不同地點，從而提供跨機架的容災解決方案。 兩個節點完全同步運作。 從主機端來看，H710就像一個普通的雙控儲存系統。 因此，無需執行任何額外的軟體或硬體選項或特別複雜的設定。
如果我們比較上述所有跨機架災難復原解決方案，那麼 AccelStor 的選項在其他選項中脫穎而出：
AccelStor NeoSapphire™ 無共享架構
軟體或硬體「虛擬化」儲存系統
基於複製的解決方案
可用性
伺服器故障
無停機時間
無停機時間
無停機時間
開關故障
無停機時間
無停機時間
無停機時間
儲存系統故障
無停機時間
無停機時間
暫停使用時間
整個機櫃故障
無停機時間
無停機時間
暫停使用時間
成本和複雜性
解決方案成本
低的*
高
高
部署複雜度
低
高
高
*AccelStor NeoSapphire™ 仍然是全快閃陣列，根據定義，其成本不會“3 戈比”，特別是因為它具有雙倍容量儲備。 然而，當將基於它的解決方案的最終成本與其他供應商的類似解決方案進行比較時，可以認為成本很低。
連接應用程式伺服器和全快閃陣列節點的拓撲如下所示：
在規劃拓撲時，強烈建議複製管理交換器並互連伺服器。
在這裡，我們將進一步討論透過光纖通道進行連接。 如果您使用 iSCSI，一切都將是相同的，只是根據所使用的交換器類型進行調整，並且陣列設定略有不同。
陣列的準備工作
使用的設備和軟體
伺服器和交換器規格
組件
描述
Oracle 資料庫 11g 伺服器
二
服務器操作系統
Oracle Linux
Oracle資料庫版本
11克（RAC）
每台伺服器的處理器數
兩台 16 核心 Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz
每台伺服器的實體記憶體
128GB
光纖通道網路
具有多路徑功能的 16Gb/s FC
光纖通道HBA
Emulex Lpe-16002B
用於叢集管理的專用公共 1GbE 端口
英特爾乙太網路適配器 RJ45
16Gb/s 光纖通道交換機
博科6505
用於資料同步的專用私有 10GbE 端口
英特爾X520
AccelStor NeoSapphire™ 全快閃陣列規格
組件
描述
存儲系統
NeoSapphire™ 高可用性型號：H710
圖片版
4.0.1
驅動器總數
48
驅動器大小
1.92TB
驅動器類型
SSD
FC 目標連接埠
16 個 16Gb 連接埠（每個節點 8 個）
管理端口
透過乙太網路交換器連接到主機的 1GbE 乙太網路電纜
心跳連接埠
連接兩個儲存節點之間的 1GbE 乙太網路電纜
資料同步連接埠
56Gb/s InfiniBand 電纜
在使用數組之前，必須對其進行初始化。 預設情況下，兩個節點的控制位址相同（192.168.1.1）。 您需要一一連接到它們並設定新的（已經不同的）管理位址並設定時間同步，之後管理連接埠可以連接到單一網路。 然後，透過為 Interlink 連線指派子網，將節點組合成 HA 對。
初始化完成後，您可以從任何節點管理陣列。
接下來，我們建立必要的磁碟區並將它們發佈到應用程式伺服器。
強烈建議為 Oracle ASM 建立多個卷，因為這將增加伺服器的目標數量，從而最終提高整體效能（更多關於佇列的信息，請參閱另一個 ).
測試配置
儲存磁碟區名稱
卷大小
Data01
200GB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
網格01
1GB
網格02
1GB
網格03
1GB
網格04
1GB
網格05
1GB
網格06
1GB
重做01
100GB
重做02
100GB
重做03
100GB
重做04
100GB
重做05
100GB
重做06
100GB
重做07
100GB
重做08
100GB
重做09
100GB
重做10
100GB
關於陣列工作模式和緊急情況下發生的流程的一些解釋
每個節點的資料集都有一個「版本號」參數。 初始初始化後，它是相同的，等於1。如果由於某種原因版本號不同，那麼資料總是從舊版本同步到新版本，之後新版本的版本號對齊，即這意味著副本是相同的。 版本可能不同的原因：
- 計劃重新啟動其中一個節點
- 由於突然停機（供電、過熱等）導致其中一個節點發生事故。
- InfiniBand 連線遺失且無法同步
- 由於資料損壞，其中一個節點崩潰。 這裡需要建立一個新的HA組並完成資料集的同步。
在任何情況下，保持在線的節點都會將其版本號加一，以便在與該對的連接恢復後同步其資料集。
如果乙太網路鏈路上的連線遺失，Heartbeat 會暫時切換到 InfiniBand，並在恢復後 10 秒內返回。
設定主機
為了確保容錯並提高效能，必須為陣列啟用 MPIO 支援。 為此，您需要將行新增至 /etc/multipath.conf 文件，然後重新啟動多路徑服務
隱藏文字裝置 {
裝置 {
供應商“AStor”
路徑分組策略“group_by_prio”
path_selector“佇列長度0”
路徑檢查器“tur”
特徵“0”
硬體處理程序“0”
先驗“常數”
立即故障回覆
fast_io_fail_tmo 5
dev_loss_tmo 60
使用者友善名稱 是
detector_prio 是
rr_min_io_rq 1
無路徑重試 0
}
}
接下來，為了讓 ASM 透過 ASMLib 與 MPIO 配合使用，您需要更改 /etc/sysconfig/oracleasm 文件，然後執行 /etc/init.d/oracleasm scandisks
隱藏文字
# ORACLEASM_SCANORDER：匹配模式以排序磁碟掃描
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE：匹配模式以從掃描中排除磁碟
ORACLEASM_SCANEXCLUDE="sd"
注意
如果你不想使用ASMLib，你可以使用UDEV規則，它是ASMLib的基礎。
從 Oracle 資料庫版本 12.1.0.2 開始，該選項可作為 ASMFD 軟體的一部分進行安裝。
必須確保為 Oracle ASM 建立的磁碟與陣列實體操作的區塊大小 (4K) 一致。 否則，可能會出現效能問題。 因此，有必要使用適當的參數來建立磁碟區：
parted /dev/mapper/設備名稱 mklabel gpt mkpart 主要 2048s 100% 對齊檢查最佳 1
在我們的測試配置中跨建立的磁碟區分配資料庫
儲存磁碟區名稱
卷大小
卷 LUN 映射
ASM 卷設備詳細信息
分配單位大小
Data01
200GB
將所有儲存磁碟區對應到儲存系統的所有資料端口
冗餘：正常
名稱：DGDATA
用途：數據文件
4MB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
網格01
1GB
冗餘：正常
名稱：DGGRID1
目的：網格：CRS 和投票
4MB
網格02
1GB
網格03
1GB
網格04
1GB
冗餘：正常
名稱：DGGRID2
目的：網格：CRS 和投票
4MB
網格05
1GB
網格06
1GB
重做01
100GB
冗餘：正常
名稱：DGREDO1
用途：線程1的重做日誌
4MB
重做02
100GB
重做03
100GB
重做04
100GB
重做05
100GB
重做06
100GB
冗餘：正常
名稱：DGREDO2
用途：線程2的重做日誌
4MB
重做07
100GB
重做08
100GB
重做09
100GB
重做10
100GB
資料庫設定
- 塊大小 = 8K
- 交換空間 = 16GB
- 停用 AMM（自動記憶體管理）
- 禁用透明大頁
其他設定
# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-max = 6815744
✓ 核心.shmmax 103079215104
✓ 核心.shmall 31457280
✓ 核心.shmmn 4096
✓ 內核.sem = 250 32000 100 128
✓ net.ipv4.ip_local_port_range = 9000 65500
✓ net.core.rmem_default = 262144
✓ net.core.rmem_max = 4194304
✓ net.core.wmem_default = 262144
✓ net.core.wmem_max = 1048586
✓vm.swappiness=10
✓ vm.min_free_kbytes=524288 # 如果您使用的是 Linux x86，請勿設定此選項
✓ vm.vfs_cache_Pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ 網格軟體 nproc 2047
✓ 網格硬 nproc 16384
✓ 網格軟 nofile 1024
✓ 網格硬線 65536
✓ 網格軟堆疊 10240
✓ 網格硬堆疊 32768
✓ Oracle 軟體 nproc 2047
✓ Oracle 硬 nproc 16384
✓ oracle 軟 nofile 1024
✓ Oracle 硬文件 65536
✓ Oracle軟堆疊10240
✓ 甲骨文硬堆疊32768
✓ 軟記憶體鎖 120795954
✓ 硬記憶體鎖 120795954
sqlplus“/作為sysdba”
更改系統設定進程=2000範圍=spfile;
更改系統設定 open_cursors=2000 範圍=spfile;
更改系統設定 session_cached_cursors=300 範圍=spfile;
更改系統設定 db_files=8192 範圍=spfile；
失效測試
出於演示目的，HammerDB 用於模擬 OLTP 負載。 HammerDB設定：
倉庫數量
256
每個用戶的總交易量
1000000000000
虛擬用戶
256
結果是 2.1M TPM，遠未達到陣列的性能極限 ，而是伺服器當前硬體配置（主要是處理器）及其數量的「上限」。 此測試的目的仍然是為了證明整個解決方案的容錯能力，而不是為了實現最大效能。 因此，我們將簡單地建立在這個數字的基礎上。
測試其中一個節點的故障
主機遺失了部分儲存路徑，繼續透過第二個節點處理剩餘路徑。 由於路徑正在重建，效能下降了幾秒鐘，然後恢復正常。 服務沒有中斷。
所有設備的機櫃故障測試
在這種情況下，由於路徑的重組，效能也下降了幾秒鐘，然後又恢復到原來值的一半。 由於一台應用程式伺服器被排除在運行之外，結果比最初的結果減半。 服務也沒有中斷。
如果需要以合理的成本和很少的部署/管理工作為 Oracle 實施容錯的跨機架災難復原解決方案，那麼 Oracle RAC 和架構可以協同工作 將是最好的選擇之一。 例如，除了 Oracle RAC 之外，還可以使用任何其他提供叢集的軟體、相同的 DBMS 或虛擬化系統。 建構解決方案的原則將保持不變。 RTO 和 RPO 的底線為零。
來源： www.habr.com