Wednesday, August 24, 2011

Survey of System Management Frameworks

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

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
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
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)
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
Post a Comment