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。

有結論嗎？

以上還不夠嗎？就醬！

文章轉自數據和雲公眾號，原文鏈接