相当多的企业应用程序和虚拟化系统都有自己的构建容错解决方案的机制。 具体来说，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
user_friendly_names 是
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 的底线为零。
来源： habr.com