A few weeks ago while deep diving into the BIG-IP ASM 4100 and what it can do, I began looking around for some documentation on the processes associated with the ASM module.  In particular I wanted to find out what those processes were and exactly what each of them did.  I thought it would make a decent reference article for folks just getting involved with the ASM.

After looking around on the F5 website and through a few reams of paper searching for that information, I discovered that it didn’t exist in the public domain.  Therefore I opened up a ticket with the kind folks over at F5 regarding the matter.  Below is the end result of their hard work:

bd – This process implements the ASM policy on the HTTP traffic it receives.
If not running: No Traffic Passes
Logs To: /ts/log/bd.log

bd_agent
– Delivers policy configuration to the bd process and forwards bd events to the rest of the system.
If not running: No enforcer configuration updates, no statistics (not including request log)
Logs to: /var/log/asm, /ts/log/bd_agent.log

dcc – The DCC process forwards policy updates to the bd via the bd_agent, handles bd events received from the bd_agent, and manages communications with the rest of the system.
If not running: No enforcer configuration updates, no statistics (not including forensics)
Logs to: /var/log/asm, /ts/log/dcc.log

verify_dcc – A form of "watchdog" process that monitors the dcc process, and reports any failures to the recovery_mngr.pl, which handles restarting the dcc.
If not running: No monitoring of dcc availability
Logs to: /ts/log/verify_dcc.log, /var/log/asm

mysqld – The mysql database process holding the policy as well as logs and policy builder data.
If not running: Configuration will not load, no logging, no traffic passes.
Logs to: /var/lib/mysqld.err

verify_mysql – A form of "watchdog" process that monitors the mysqld server, restarts if it needed, and reports any failures to the recovery_mngr.pl process, which restarts the dcc processes, since they must reconnect to the DB after any failure.
If not running: No monitoring of mysql availability
Logs to: /var/log/verify_mysql.log, /var/log/asm

clean_db – Monitors ASM DB tables, and prevents them from exceeding pre-defined limits on table size.
If not running: No deletion of old database records, may fill the disk.
Logs to: /ts/log/clean_db.log, /var/log/asm

log_manager – In charge of ASM-specific log file tasks such as rotating and archiving the logs.
If not running: ASM debug logs (non syslog) will not get rotated to tar archives.
Logs to: /var/log/asm, /ts/log/log_manager.log

recovery_manager – The process is in charge of starting the ASM daemons in their proper order, restarting daemons when watchdogs report failures.
If not running: ASM will not recover from any failure.
Logs to: /var/log/asm, /ts/log/recovery_mngr.log

crawler_manager – Handles starting and stopping the policy builder via the GUI.
If not running: No control of PB actions.
Logs to: /ts/log/crawler_manager.log, /var/log/asm

learning_manager – Populates the learning tables that are used in the processing building policies.
If not running: No learning suggestions.
Logs to: /ts/log/learning_manager.log, /var/log/asm

attack_manager – Populates the "Attacks Reports", based on security events.
If not running: No statistics of attacks.
Logs to: /ts/log/attack_manager.log, /var/log/asm

nwd_core, nwd_ts, and nwd_dms – Multiple instances of "watchdog" processes that monitor ASM daemons, and attempt to restart them if they fail.  Reports failures to restart daemons to the recovery_mngr.pl process.  Covered in https://support.f5.com/kb/en-us/solutions/public/6000/500/sol6590.html
If not running: ASM daemons won’t get brought up on failure.
Logs to: /ts/log/nwd.log, /var/log/asm

Share

No Comment.

Add Your Comment