Oracle 12c ASM 防火防盗新特性揭秘

简介:

在Oracle ASM的初始年代中,相信很多人都遭遇过ASM盘头损坏的故障,甚至积累下来备份磁盘头的运维习惯。在12c版本中,Oracle做出了强有力的改进,进行ASM数据保护,ASMFD就是这样的核心特性,请欣赏云和恩墨张乐奕对于这一特性的测试解析。


张乐奕

云和恩墨副总经理 Oracle ACE 总监

ITPUB Oracle数据库管理版版主、Oracle高可用版版主、ACOUG联合创始人


什么是 Oracle ASM Filter Driver (ASMFD)?
简单地说,这是一个可以取代 ASMLIB 和 udev 设置的新功能,并且还增加了 I/O Filter 功能,这也体现在该功能的命名中。ASMFD 目前只在 Linux 操作系统中有效,并且必须要使用最新版的 Oracle ASM 12.1.0.2。在之前,由于 Linux 操作系统对于块设备的发现顺序不定,所以在系统重启以后,无法保证原来的 /dev/sda 还是 sda,所以不能直接使用这样原始的设备名来做 ASM Disk 的 Path,因此出现了 ASMLIB,以 Label 的方式给予设备一个固定的名字,而 ASM 则直接使用这个固定的名字来创建 ASM 磁盘,后来 ASMLIB 必须要 ULN 帐号才可以下载了,于是大家全部转到了 udev 方式,我还因此写了几篇文章来阐述在 Linux 中如何设置 udev rule。比如:

—How to use udev for Oracle ASM in Oracle Linux 6

—Oracle Datafiles & Block Device & Parted & Udev


现在 Oracle 推出了 ASMFD,可以一举取代 ASMLIB 和手动设置 udev rules 文件的繁琐,并且最重要的是 I/O Filter 功能。
什么是 I/O Filter 功能?
文档原文如下:
The Oracle ASM Filter Driver rejects any I/O requests that are invalid. This action eliminates accidental overwrites of Oracle ASM disks that would cause corruption in the disks and files within the disk group. For example, the Oracle ASM Filter Driver filters out all non-Oracle I/Os which could cause accidental overwrites.


意思是:该功能可以拒绝所有无效的 I/O 请求,最主要的作用是防止意外覆写 ASM 磁盘的底层盘,在后面的测试中可以看到对于 root 用户的 dd 全盘清零这样的变态操作也都是可以过滤的。

真是不错,那么该怎么启用这个功能呢?

--确认目前 ASMFD 模块(以下简称 AFD)的状态,未加载。


--获取当前 ASM 磁盘发现路径,我这里是使用udev 绑定的名称


--设置 ASM 磁盘路径,将新的 DiskString 加入

--可以看到在设置该参数时,ASM 会检查现有已经加载的磁盘,如果不在发现路径上,将会报错。


--因此我们必须将新的路径加在原始路径后面,设置成多种路径,该操作会运行一段时间,视ASM 磁盘多少而定


--检查现在 GI 环境中的节点。


--以下命令必须在所有 Hub 节点上都运行,可以使用Rolling 的方式。以下命令有些需要root 用户,有些需要 grid 用户,请注意 # 或者 $ 不同的提示符表示不同的用户。

--先停止crs


--作 AFD Configure,实际上这是一个解压程序包,安装,并加载 Driver 的过程,需要消耗一些时间


--结束以后,可以再次检查 AFD 状态,显示已加载。


--接下来需要设置 AFD 自己的磁盘发现路径了,其实这里很像以前 ASMLIB 的操作。

--设置 AFD 磁盘发现路径,必须先启动CRS,否则将会遇到下面的错误。同时也可以看到这个信息是存储在每个节点自己的 OLR 中,因此必须在所有节点中都设置。


--启动 CRS


--此时查看后台的 ASM 告警日志,可以看到加载的磁盘仍然使用的是原始路径。但是也可以看到 libafd 已经成功加载。


--将 afd_ds 设置为 ASM 磁盘的底层磁盘设备名,这样以后就不再需要手工配置 udev rules 了。


--我在测试的时候,上面犯了一个错误,将路径设置为了“dev/sd*”,缺少了最开始的根目录。因此此处没有发现任何磁盘,如果你的测试中,这一步已经可以发现磁盘,请告诉我。


--再次提醒,到此为止的所有命令,都必须要在集群环境的所有节点中都执行。

--接下来就是将原先的 ASM 磁盘路径从 udev 转到 AFD

--先检查现在的磁盘路径


--由于要修改 OCR 所在的磁盘,因此修改之前需要停止 Cluster。


--直接修改会报错,因为/dev/asm-disk1 已经存在在 ASM 中了。


--必须要增加 migrate 关键字,才可以成功。


--在我的测试 ASM 中,一共有 13 块磁盘,因此依次修改。


--在另外的节点中,不再需要作 label,而是直接 scan 即可,这跟使用ASMLIB 的操作非常相像。


--重新启动 Cluster


--可以看到 ASM 告警日志中已经显示开始使用新的名称。关于其中 WARNING 的含义表示目前AFD 还不支持 Advanced Format 格式的磁盘,普通磁盘格式一个扇区是 512 字节,而高级格式则为 4K 字节。


--检查磁盘加载路径,以及功能全部是 AFD 样式了。


--但是我们可以看到在数据字典中仍然存在之前的磁盘路径。


--需要将 ASM 磁盘发现路径(注意,这跟设置 AFD 磁盘发现路径不是一个命令)中原先的路径去除,只保留 AFD 路径。


--再次重启 ASM,一切正常了。


--收尾工作,将原先的 udev rules 文件移除。当然,这要在所有节点中都运行.以后如果服务器再次重启,AFD 就会完全接管了。

还有什么发现?

其实,AFD 也在使用 udev。囧。


Label 过后的磁盘在 /dev/oracleafd/disks 目录中可以找到。


这里有一个很大不同,所有磁盘的属主变成了 root,并且只有 root 才有写入的权限。很多文章认为,这就是 AFD 的 filter 功能体现了,因为现在用 oracle 或者 grid 用户都没有办法直接对 ASM 磁盘进行写入操作,自然就获得了一层保护。比如以下命令会直接报权限不足。


但是如果你认为这就是 AFD 的保护功能,那也太小看 Oracle 了,仅仅是这样也对不起名字中 Filter 字样。且看后面分解。

操作系统中也可以看到 AFD 磁盘和底层磁盘的对应关系。


再次重启服务器以后,afd_lsdsk 的结果中显示的路径都已经变为底层磁盘,但是 Filtering 却变成了 DISABLED。不要在意这里的 Label 和 Path 的对应和上面的不一样,因为有些是在节点 1 中执行的结果,有些是在节点 2 中执行的结果,而这也是 AFD 功能的展示,不管两边机器发现块设备的顺序是不是一样,只要绑定了 AFD 的 Label,就没问题了。

最后,该来测试一下 I/O Filter 功能了吧,等好久了!
对,这才是重点。

先看一下如何启用或者禁用 Filter 功能。在我的测试中,单独设置某块盘启用还是禁用是不生效的,只能全局启用或者禁用。



启用 Filter 功能。


为了以防万一,不破坏我自己的实验环境,增加了一块磁盘来作测试。



创建一个新的磁盘组。


先用 KFED 读取一下磁盘头,验证一下确实无误。



直接使用 dd 尝试将整个磁盘清零。dd 命令本身没有任何错误返回。



之后重新 mount 磁盘组,如果磁盘被清零,在重新 mount 的时候一定会出现错误,而现在正常挂载。


觉得不过瘾?那再创建一个表空间,插入一些数据,做一次 checkpoint,仍然一切正常。



但是诡异的是,这时候在操作系统级别直接去读取 /dev/sdo 的内容,会显示全部都已经被清空为 0 了。


使用 strings 命令也完全看不到任何有意义的字符。


但是,千万不要被这样的假象迷惑,以为磁盘真的被清空了,在 dd 的时候,/var/log/message 会产生大量日志,明确表示这些在 ASM 管理的设备上的 IO 操作都是不被支持,这才是 Filter 真正起作用的场合。


使用 kfed,仍然可以读取到正常的信息。

直到重新启动服务器(重新启动 ASM,重新启动 Cluster,在操作系统仍然看到的是清零后的数据),所有的数据又回来了(请不要在重要环境上进行这样的测试)。


最后将 Filter 禁用之后再测试。



同样使用 dd 命令清零整个磁盘。


重新 mount 磁盘组,如期报错,磁盘组无法加载。



重新启动数据库,也会发现由于表空间中数据库不存在而导致数据库无法正常 Open。


有结论吗?

以上还不够吗?就酱!


文章转自数据和云公众号,原文链接

相关文章
|
5月前
|
SQL 机器学习/深度学习 Oracle
关系型数据库Oracle关键特性
【7月更文挑战第5天】
94 3
|
2月前
|
存储 Oracle 关系型数据库
数据库数据恢复—Oracle ASM磁盘组故障数据恢复案例
Oracle数据库数据恢复环境&故障: Oracle ASM磁盘组由4块磁盘组成。Oracle ASM磁盘组掉线 ,ASM实例不能mount。 Oracle数据库故障分析&恢复方案: 数据库数据恢复工程师对组成ASM磁盘组的磁盘进行分析。对ASM元数据进行分析发现ASM存储元数据损坏,导致磁盘组无法挂载。
|
3月前
|
存储 Oracle 关系型数据库
Oracle和MySQL有哪些区别?从基本特性、技术选型、字段类型、事务、语句等角度详细对比Oracle和MySQL
从基本特性、技术选型、字段类型、事务提交方式、SQL语句、分页方法等方面对比Oracle和MySQL的区别。
732 18
|
5月前
|
存储 Oracle 关系型数据库
Oracle 12c支持哪些数据类型?
【7月更文挑战第20天】Oracle 12c支持哪些数据类型?
114 2
|
5月前
|
SQL Oracle 关系型数据库
Oracle 12c有哪些新特性?
【7月更文挑战第20天】Oracle 12c有哪些新特性?
84 2
|
5月前
|
存储 Oracle 关系型数据库
Oracle数据库ACID特性
【7月更文挑战第6天】
123 6
|
7月前
|
SQL Oracle 关系型数据库
Oracle 12c的TOP N语句:数据排名的“快速通道”
【4月更文挑战第19天】Oracle 12c的TOP N语句是用于快速获取数据集排名前N的记录的SQL查询方法,特别适合寻找最具代表性的数据。通过指定排序条件和数量,TOP N能高效筛选出所需信息,例如最高销售额产品或最大访问量网页。在Oracle 12c中,查询优化器对TOP N查询进行了优化,保证快速返回结果,并提供丰富的排序和过滤选项。基本用法如`SELECT ... ORDER BY ... FETCH FIRST N ROWS ONLY`,还可结合`OFFSET`进行分页查询或用`WITH TIES`保持结果完整性。掌握TOP N语句能提升数据分析效率,助力企业决策。
|
7月前
|
存储 Oracle 关系型数据库
Oracle 12c的临时UNDO:数据的“临时保镖”
【4月更文挑战第19天】Oracle 12c引入的临时UNDO为数据安全提供新保障。它为临时操作和特定事务提供独立UNDO空间,避免共享UNDO带来的性能瓶颈和管理复杂性。临时UNDO随事务开始分配,记录修改历史,事务结束后自动释放。优点包括提高性能、简化管理及保证数据一致性。但需注意手动配置、监控和优化,以防长时间占用资源。了解其工作原理和最佳实践是提升数据库性能的关键。
|
SQL Oracle 关系型数据库
|
2月前
|
存储 Oracle 关系型数据库
Oracle数据库的应用场景有哪些?
【10月更文挑战第15天】Oracle数据库的应用场景有哪些?
200 64

推荐镜像

更多