Following is couple of tables I took out of Survey I did on system management frameworks. A detailed writeup of this survey is in my thesis under related works. I want to write up a survey paper on this, but have not got to that yet.
Lets start with brief outline on rational for the choice of matrices to compare different implementations. System management frameworks monitor a system, take decisions on how to fix things, and execute those decisions. They often consist of three parts: Sensors, a brain that make decisions, and set of actuators to execute decisions. From 10,000-foot view, most architectures follow this model, but differ on how they collect data, make decisions, and execute them. First table compares them on this aspect.
System management frameworks themselves have to scale and provide High availability. To do those, they have to be composed of multiple servers (managers). Taking decisions with multiple managers (coordination) is one of the key challenges in system management framework design. The second table compares and contrast different coordination models using different architectural styles.
The 3rd table discusses decision models—in other words, implementation of the brain. More details can find from http://people.apache.org/~hemapani/research/system-management-survey.html.
Systems based on Functionality/Design
| Sensors->Brain-> (Actuators)? | InfoSpect(Prolog),WRMFDS (AI), Rule-basedDignosis (Hierachy) (Monitoring & Dignosis) Ref Archi, Autopilot, Policy2Actions (Centralized) JADE, JINI-Fed, ReactiveSys, (Managers) Tivoli (Managers + Manual Coordinator) |
| Sensors->Gauges->Brain-> (Actuators)? | Paradyn MRNet (Monitoring Only) Rainbow (Archi Model*), ACME-CMU, CoordOfSysMngServices, Code InfraMonMangGrid(Centralized) eXtreme(KX),Galaxy* (Managers) |
| Sensors->DataModel->Brain->Actuators | DealingWithScale(CIM), Marvel( Centralized) Scalable Management (PLDB/Managers), Nester (Distributed directory service), SelfOrgSWArchi |
| Sensors->ECA->Actuators | DREAM, SmartSub, IrisLog, HiFi, Sophia (Prolog) - (Managers) |
| Management Hierarchy | NaradaBrokerMng, WildCat, BISE,ReflexEngine |
| Queries on demand | ACME , Decentralizing Network Management, Mng4P2P (Managers) |
| Workflow systems/ Resource management | Unity, RecipeBased (Centralized), SelfMngWFEngine, Automate Accord, ScWAreaRM, P2PDesktopGrid (Distributed) |
| Fault tolerant systems | WSRF-Container, GEMS (Distributed) |
| Decentralized | DMonA,Guerrilla, K-Componets |
| Deployment frameworks | SmartFrog , Plush, CoordApat |
| Monitoring | Inca (Centralized), PIPER (multicast over DHT), MDS (LDAP, Events), NWS(LDAP), Scalable Info management, Astorable (Gossip), Monitoring with accuracy, RGMA (DB like access) |
Systems based on Coordination and Communication model
| Monitoring Only | One Manager without coordination | One Manager with coordination | Managers without coordination | Managers with coordination | |
| Pull / events | InfoSpect Sophia |
Rainbow, Unity, Ref Archi, Autopilot, InfraMonMangGrid | CoordOfSysMngServices | JADE | DMonA, Tivoli (Manual) |
| Pub/Sub hierarchy | DealingWithScale, ACME-CMU | Scalable Management, DREAM, SmartSub | NaradaBrokerMng, | ||
| P2P | PIPER, | Automate Accord, Mng4P2P, WSRF-Container, | |||
| Hierarchy | Gangila, Globus MDS, Paradyn MRNet, WRMFDS | IrisLog, HiFi, JINI-Fed, eXtreme(KX), ScWAreaRM | WildCat | ||
| Gossip | Astorable, GEMS | Galaxy | |||
| Spanning Tree (Network/P2P) | Scalable Info management, ACME | ||||
| Group Communication | ReactiveSys, Galaxy | SelfOrgSWArchi | |||
| Distributed Queue | SelfMngWFEngine |
Decision Models in management Systems
| Rules | Conflict resolution | Verifier | Batch Mode used? | Meta-model used? | Planning | |
| DIOS++ | If/then | yes, use priority | No | results of rules applied in next iteration | Yes | No |
| Rainbow | If/then | No | Yes | No | ||
| InfoSpect | Prolog Like | Only Monitoring | No | No | Yes | No |
| Marvel(1995) | PreCnd->action->PostCond | Yes | No | Yes | No | |
| CoordOfSysMngServices | Yes (Detect ->Human Help) | Yes | Yes | No | Yes | |
| Sophia | Prolog like | No | No | No | ||
| RecipeBased | Java Code | Yes | No | No | No | |
| HiFi, DREAM | pub/sub Filter->action | No | No | No | No | No |
| IrisLog | DB triggers | No | No | No | No | No |
| ACME | (timer/sensor/completion) conditions->action |
No | No | possible with timer conditions | Yes | No |
| ReactiveSys (1993) | if/then | No | No | No | Yes | No |
| Policy2Actions (2007) | Policy- name, conditions (name of method to run + parameters), actions, target component | Yes, based on runtime state + history | There are tests associated with each actions that decide should action need to run | - | No | Yes |
No comments:
Post a Comment