如何理解Oracle CRS/GI的進程

138次閱讀

共計 4838 個字符，預計需要花費 13 分鐘才能閱讀完成。

今天就跟大家聊聊有關如何理解 Oracle CRS/GI 的進程，可能很多人都不太了解，為了讓大家更加了解，丸趣 TV 小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

在
10g 和 11.1，Oracle 的集群稱為 CRS(Oracle Cluster Ready Service)，
在 11.2，Oracle 的集群稱為 GI(Grid Infrastructure)。
對于 CRS/GI，他們的一些核心進程的功能基本類似，但是在 11.2，新增了很多新的 Deamon 進程。

10.2 CRS：
$ ps -ef|grep crs/bin
root 4373 3605 0 Feb25 ? 00:02:49 /u01/app/crs/bin/crsd.bin reboot
oracle 4380 4379 0 Feb25 ? 00:00:03 /u01/app/crs/bin/evmd.bin
oracle 4925 4888 0 Feb25 ? 00:00:00 /u01/app/crs/bin/oclsomon.bin
root 4928 4483 0 Feb25 ? 00:00:00 /u01/app/crs/bin/oprocd.bin run -t 1000 -m 10000 –
hsi 5:10:50:75:90 -f
oracle 5065 4512 0 Feb25 ? 00:00:54 /u01/app/crs/bin/ocssd.bin
oracle 6825 4380 0 Feb25 ? 00:00:00 /u01/app/crs/bin/evmlogger.bin -o

11.2 GI：
$ ps -ef|grep grid/bin
root 6656 1 0 Feb25 ? 00:09:20 /u01/app/11.2.0/grid/bin/ohasd.bin reboot
grid 7960 1 0 Feb25 ? 00:16:54 /u01/app/11.2.0/grid/bin/oraagent.bin
grid 7972 1 0 Feb25 ? 00:00:05 /u01/app/11.2.0/grid/bin/mdnsd.bin
grid 7982 1 0 Feb25 ? 00:03:45 /u01/app/11.2.0/grid/bin/gpnpd.bin
grid 7993 1 0 Feb25 ? 00:14:19 /u01/app/11.2.0/grid/bin/gipcd.bin
root 7995 1 1 Feb25 ? 00:41:42 /u01/app/11.2.0/grid/bin/orarootagent.bin
root 8010 1 0 Feb25 ? 00:28:03 /u01/app/11.2.0/grid/bin/osysmond.bin
root 8026 1 0 Feb25 ? 00:01:31 /u01/app/11.2.0/grid/bin/cssdmonitor
root 8040 1 0 Feb25 ? 00:02:22 /u01/app/11.2.0/grid/bin/cssdagent
grid 8057 1 1 Feb25 ? 00:48:04 /u01/app/11.2.0/grid/bin/ocssd.bin
root 8136 1 0 Feb25 ? 00:02:49 /u01/app/11.2.0/grid/bin/octssd.bin reboot
grid 8158 1 0 Feb25 ? 00:02:24 /u01/app/11.2.0/grid/bin/evmd.bin
root 8278 1 0 Feb25 ? 00:04:18 /u01/app/11.2.0/grid/bin/crsd.bin reboot
grid 8357 8158 0 Feb25 ? 00:00:00 /u01/app/11.2.0/grid/bin/evmlogger.bin -o
/u01/app/11.2.0/grid/evm/log/evmlogger.info -l /u01/app/11.2.0/grid/evm/log/evmlogger.log
grid 8406 1 0 Feb25 ? 00:11:22 /u01/app/11.2.0/grid/bin/oraagent.bin
root 8414 1 1 Feb25 ? 00:36:22 /u01/app/11.2.0/grid/bin/orarootagent.bin

我們對這些常見的集群進程做一些解釋：

各個版本共有的：
1.
ocssd.bin：這是一個很核心的進程，如果它異常終止會導致這個節點的集群或者主機重啟。這個進程主要用于檢查表決盤能否正常訪問，節點私網間的通
信是否正常。數據庫實例上的 LMON 進程也會注冊到 CSSD 上，這樣 CSSD 會通過 LMON 來了解數據庫實例的健康情況。
如果節點發生了主機自動重啟，需要查看 ocssd 的日志，位于：/log//cssd。

可以參考下面的文檔來了解節點重啟：
如何診斷節點重啟問題
11gR2 如何診斷節點重啟問題

2. crsd.bin：這個進程主要用于管理集群中的資源。用來啟動、停止檢查一些資源，比如數據庫實例、ASM、監聽、磁盤組、VIP 等。在 11.2，這些具體的操作由對應的 agent 執行。另外，OCR 的維護也是由 CRSD 完成的。
當發現某些資源異常終止后，首先需要查看 crsd 的日志：/log//crsd。

3. evmd.bin：事件監控 (event monitor) 進程，由它來發布集群事件，比如實例啟動、停止等事件。

4. ons 進程：Oracle Notification Service
daemon，它用于接收 evmd 發來的集群事件，然后將這些事件發送給應用預訂者或者本地的監聽，這樣就可以實現 FAN(Fast
Application Notification)，應用能夠接收到這些事件并進行處理。

5. gsd：只有當 CRS 或者 GI 上需要管理 9i 的數據庫時才需要。在 11.2, gsd 默認就是 offline 的。
可以參考 My Oracle Support 文檔：GSD Is Used Only if 9i RAC Database is Present (Doc ID 429966.1)

10g 和 11.1 特有的：
1. oprocd.bin：Oracle Clusterware Process Monitor Daemon，用來監控主機 hang，如果發現主機 hang 后會發起主機重啟。只有未使用第三方的集群軟件時才運行，Linux 上從 10.2.0.4 開始使用。
oprocd 的日志會在：/etc/oracle/oprocd/*.log.* 或者 /var/opt/oracle/oprocd/*.log.*。

2. oclsomon.bin：用來監控 ocssd 進程是否 hang，如果發現 hang，會發起 reboot.

11.2 特有的：
1. cssdagent(11.2)：這個進程由 ohasd 啟動，然后由它來啟動、停止、檢查 ocssd 進程，以 root 身份運行。
它的日志位于：/log//agent/ohasd/oracssdagent_root

2. cssdmonitor(11.2)：監控 cssdagent，并且檢查節點 hang（類似于 oprocd），監控 ocssd 進程是否 hang（類似于 oclsomon）, 監控 vendor clusterware（類似于 vmon），以 root 身份運行。
它的日志位于：/log//agent/ohasd/oracssdmonitor_root

3. ohasd.bin: 在 GI 啟動時，最先啟動的就是 ohasd, 然后由它啟動 agent(orarootagent,oraagent, cssdagnet 和 cssdmonitor)，各個 agent 再啟動對應的進程。
如果 GI 啟動過程有問題，可以查看一下 ohasd 的日志：/log//agent/ohasd

4. mdnsd.bin：這個進程通過多播（Multicast）發現集群中的節點和所有的網卡信息。一定要確定集群中的網卡支持多播，而且節點間的通信正常。
它的日志位于：/log//mdnsd

5. gpnpd.bin：發布構建集群所需要的 bootstrap 信息，并且在集群的所有節點之間同步 gpnp profile。
它的日志位于：/log//gpnpd

6. gipcd.bin：這個進程負責管理集群中所有的私網（cluster interconnect）網卡。私網信息是通過 gpnpd 獲得的。
它的日志位于：/log//gipcd

7. gnsd(可選): Grid Naming Service. 相當于子 DNS，功能和 DNS 類似，會取代使用 /etc/hosts 進行主機的解析。
它的日志位于：/log//gnsd

8. octssd.bin: The Cluster Time Sync Service(CTSS)
用于各個節點間的時鐘同步，集群中的一個節點的時鐘會作為參照節點，其它節點和這個節點進行時鐘同步。注意：當第三方時間同步軟件（例如：NTP）
存在時，CTSS 會以‘觀察者’的方式運行，并不修改節點時間，但是，如果 CTSS 沒有發現第三方時間同步軟件，它會開始修改節點時間以便和參考節點同
步。
它的日志位于：/log//ctssd.

9. osysmond.bin：這是 Oracle Cluster Health
Monitor(CHM)的主要進程，這個進程在所有節點都會運行，sysmond 會將每個節點的資源使用情況發送給 cluster logger
service，后者將會把所有節點的信息都接收并保存到 CHM 的資料庫。
它的日志位于：/log//crfmond/crfmond.log

10. ologgerd：這是 Oracle Cluster Health
Monitor(CHM)的另一個主要進程，在一個集群中的，ologgerd
會有一個主機點(master)，還有一個備節點(standby)。當 ologgerd 在當前的節點遇到問題無法啟動后，它會在備用節點啟用。
它的日志位于：/log//crflogd/crflogd.log

關于 CHM，請參考：
11gR2 新特性：Oracle Cluster Health Monitor(CHM)簡介

11. agent.bin：在 11.2，各個資源的啟動、停止和檢查都是由 agent 來執行的。ohasd 會把這些 agent 啟動。

Agent 包括兩種，一種是 ohasd 的：
oraagent_grid：啟動 / 停止 / 檢查 / 清除 ora.asm, ora.evmd, ora.gipcd, ora.gpnpd, ora.mdnsd 等資源。
orarootagent_root：啟動 / 停止 / 檢查 / 清除 ora.crsd, ora.ctssd, ora.diskmon, ora.drivers.acfs, ora.crf (11.2.0.2)等資源。
oracssdagent_root: 啟動 / 停止 / 檢查 ocssd 進程。
oracssdmonitor_root：監控 cssdagent 進程。

它們的日志位于：/log//agent/ohasd

另一種是 crsd 的：
oraagent_grid: 啟動 / 停止 / 檢查 / 清除 asm, ora.eons, ora.LISTENER.lsnr, SCAN listeners, ora.ons, diskgroup 等資源
oraagent_oracle: 啟動 / 停止 / 檢查 / 清除 service, database 等資源
orarootagent_root : 啟動 / 停止 / 檢查 / 清除 GNS, VIP, SCAN VIP and network 等資源.
scriptagent_grid: 應用服務定制的服務。

它們的日志位于：/log//agent/crsd

看完上述內容，你們對如何理解 Oracle CRS/GI 的進程有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注丸趣 TV 行業資訊頻道，感謝大家的支持。

正文完