[Aaron-devel] Architecture updated...
Status: Pre-Alpha
Brought to you by:
thetitan
Menu
▾
▴
[Aaron-devel] Architecture updated...
|
From: Sean C. <sea...@it...> - 2001-07-04 22:38:42
|
CVS commit emails are broken at SourceForge right now, but here's=20 an update regarding aaron. If you want to see how I'm thinking about=20 implementing this, check out the following link. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/aaron/aaron/doc/architecture= ?rev=3D1.3&content-type=3Dtext/vnd.viewcvs-markup Anyone want to make an HTML version of this that's click-able? =20 <:~) If it doesn't look good in email, check out the URL above. There=20 are descriptions of what each component does below the diagram. Does this look detailed enough so that you can start working on a DTD or schema for the XML for any of the configs that'd go in the Action Manager? I know I tossed together a few configs, but I don't think they're abstract enough, not yet at least. What would be really helpful to me would be for people to start asking questions about this so that I can answer them and document any implied understandings that I have that aren't existing on paper (err... = =20 email/text files). Time to get something to eat... -sc Aaron's Architecture $Id: architecture,v 1.3 2001/07/04 22:08:42 thetitan Exp $ /--------------------------------------------------------------------------= ---\ | = | | Aaron - Transaction Scheduling and exception handling machine = | | = | | /-----------------------------\ /------------------------------------= \ | | | | | = | | | | Stats Manager | | Config Loader and Data Validator = | | | | | | = | | | \-----------------------------/ \------------------------------------= / | | = | | /-----------------------------\ /------------------------------------= \ | | | | | = | | | | Logging Manager | | External Process Manager = | | | | | | = | | | \-----------------------------/ \------------------------------------= / | | = | | = | | /-----------------------------\ /------------------------------------= \ | | | | | = | | | | Network Queue Manager | | Action Manager = | | | | (incoming transactions) | | = | | | | | | /------------------------------\ = | | | +-----------------------------+ | | | = | | | | | | | Event Pool Manager | = | | | | Transaction Queue | | | | = | | | | | | \------------------------------/ = | | | | /-------------------------\ | | = | | | | | | | | /------------------------------\ = | | | | | Scheduled Transactions | | | | | = | | | | | | | | | Response Pool Manager | = | | | | +-------------------------+ | | | | = | | | | | | | | \------------------------------/ = | | | | | Queued Transactions | | | = | | | | | | | | /------------------------------\ = | | | | \-------------------------/ | | | | = | | | | | | | Transaction Pool Manager | = | | | +-----------------------------+ | | | = | | | | | | \------------------------------/ = | | | | Network Queue Manager | | = | | | | (outgoing transactions) | \------------------------------------= / | | | | = | | \-----------------------------/ = | | = | | = | | /-----------------------------------------------------------------------= \ | | | = | | | | Transaction Execution Manager = | | | | = | | | | /-----------------------------------------------------------------\ = | | | | | | = | | | | | Network Synchronization | = | | | | | | = | | | | +-----------------------------------------------------------------+ = | | | | | | = | | | | | Transaction Execution (repeat as necessary) | = | | | | | | = | | | | | /-----------------------------------------------------------\ | = | | | | | | | | = | | | | | | Event Execution | | = | | | | | | | | = | | | | | +-----------------------------------------------------------+ | = | | | | | | | | = | | | | | | Response Execution | | = | | | | | | | | = | | | | | \-----------------------------------------------------------/ | = | | | | | | = | | | | +-----------------------------------------------------------------+ = | | | | | | = | | | | | Network Synchronization | = | | | | | | = | | | | +-----------------------------------------------------------------+ = | | | | | | = | | | | | Transaction Rescheduling | = | | | | | | = | | | | \-----------------------------------------------------------------/ = | | | | = | | | \-----------------------------------------------------------------------= / | | = | \--------------------------------------------------------------------------= ---/ Notes on the Architecture: [Stats Manager] Stats Manager is a dynamically definable collection device that can hold information based on the configuration of Actions that have been loaded. Responsible for basic accountancy and persistence of statistical informat= ion inside of Aaron. Transactions that wish to keep their own stats can, but the integrity of a transaction in the Transaction Queue is not guaranteed. [Config Loader and Data Validator] This routine is called once at startup. Upon the completion of the Loade= r's execution, the Loader registers itself as an Action with the Action Manag= er and schedules itself as a transaction that needs to be rerun as specified= in its own configuration files or by default (10 min). The Config Loader registers new actions after a successful load and validation of the data. A failure prompts a warning and moves on. A fai= led config load will be reread every time the Config Loader Action is run. The Config Loader also loads statistics modules for the Stats Manager and logging modules for the Logging Manager. The Config Loader loads modules= in the following order, stats, logging, then actions. [Logging Manager] The logging manager is responsible for persisting database connections, keeping log files open, sockets to central logging hosts, etc. The Logging Manager exports an API that is available to any module in Aaron that manages all logging related functions in order to provide a consiste= nt interface that is reliable and abstract. =20 [External Process Manager] If a module wishes to call an external program that is marked as a slow, = or potentially slow, external system call, then the module has the External Process Manager fork/exec and load the process, and report back with the output and status codes. This is a desired feature, but is not core to t= he initial release of Aaron. [Network Queue Manager (incoming transactions)] When a new transaction is placed in the Transaction Queue, the Network Qu= eue Manager syncs up the transaction between the host and any other copies of Aaron that are running on other servers in the Monitoring Cluster. The Network Queue Manager is also responsible for sending transactions across the network to other copies of Aaron for processing, or failure notificat= ion in the event that the server performing the transaction crashes, the other server(s) in the Cluster will assume responsibility for executing the Response. The Network Queue Manager is responsible for notifying members of the Aaron Cluster that a transaction has completed execution. Often t= imes the transaction is re-queued for execution. [Transaction Queue] The transaction queue is just that, a queue of transactions that are wait= ing to be processed. They are in the queue either waiting for the right time= to execute, or are waiting for the appropriate resources to execute. [Scheduled Transactions] This contains transactions that are sleeping and waiting for their timer to go off. [Queued Transactions] This is a queue of transactions that are waiting for a free thread so that they can be executed. [Network Queue Manager (outgoing transactions)] When a transaction is handed off to the Transaction Execution Manager, the Network Queue Manager sends out a message to all other copies of Aaron informing the other hosts that a transaction is about to execute (and sho= uld respond accordingly based on the config of the transaction). [Action Manager] Container that holds the Event, Response, and Transaction Pools. All ite= ms in the Action Manager are read-only and can be updated only by the Config Loader. [Event Pool Manager] Contains read-only Events (can only be changed through the Config Loader) that are executed in a Transaction. This does the actual proactive action that monitors, executes, polls, etc. [Response Pool Manager] Depending on the return code and supplementary information from the execu= tion of an Event, a response is executed internally within Aaron. The Response Action can send email, log, update stats, etc. Response Modules contain conditional logic to handle the various return codes from an Event. [Transaction Pool Manager] Contains combinations (not limited to pairs) of references to Events and Responses. A Transaction must have at least one Event, but can have zero= or more responses. A Transaction can also hold multiple groupings of Events= and Responses. [Transaction Execution Manager] This is where all of the magic and actual processing occurs. The Manager receives a copy of the transaction to operate on. [Network Synchronization] Notifies the Aaron Monitoring Cluster of the execution of a specific transaction. Syncs up all nodes before a transaction is handed off to a thread for execution. [Transaction Execution] This layer interprets the Transaction and performs the decision making for recursing into the Transaction Tree and executing/responding to the Actions as necessary. The Transaction Execution step is responsible for catching all errors and exceptions from the Event Execution. [Transaction Rescheduling] Before the transaction is complete, it must either reschedule itself or a= dd itself to a list of transactions that are not to execute again until manu= ally notified to rerun (GUI anyone?). --=20 Sean Chittenden |
