The convergence of workstation technology and local area networks has heralded a change in the nature of ..... t31l Thomson, R., Sommerville, 1.. "An A[proach ...
COOPERATION AND CONFIGURATION WITHIN DISTRIBUTED SYSTEMS MANAGEMENT
G. Dean,D. Hutchison,T. Rodden,I. Sommerville
1. INTRODUCTION The convergence of workstationtechnologyandlocal areanetworkshasheraldeda changein Previously,systemsmanagefswereconcemedwith the the natureof systemsmanage{Eent. andmanagement of predominantly centralised systems.Thesesystemsoftenhad maintenance littie or no dependencyon externalsystemstructures.However,the ubiquitousnatureof acceptance of networkingtechnologyhasseen modernpersonalcomputersandthewidespread becomeincreasingly concemedwith managingsystemsthataredistributed systemsmanagers acrossa numberof workstations. combinedwith theincreasein thenumber This movetowarddistributedsystemsmanagement of machinesto be managedhasresultedin the needfor teamsof managersto work closely togetherto supportsystemsand applicationsdistributedacrossan organisation.A central is systemsconfigurationand the associated aspectof distributedsystemsmanagement to change.It is alreadyrecognised reconfiguration of thesystemin response thatconfiguration management of this lbrm requiresthe cooperationandcoordinationof a numberof systems managers with responsibilityresultingfrom a processof negotiation[1]. However,we would of distributed systems management is a cooperative oneconsisting arguethatthewholeprocess activities,someof whichareopento systemssupport. of a varietyof independent Cooperative Work (CSCW)hasexamined into the areaof ComputerSupported Research andcooperation. Oneof the mainthemesof this work has differentformsof communication ol toolswhichactivelysuppoftvarioustbrmsof cooperation amonguser beenthedevelopment highlightingthe groups.This paperexaminesthe natureof distributedsystemsmanagement, involved,and suggests techniques and toolsto supportthis variousformsof cooperation cooperation. cooperative systemsandhighlighathe Thepaperis structureda.slbllows.Section2 introduces variousforms of CSCW systemwhich haveemergedto date.Section3 examinesthe management by highlightingthevariouscooperative natureof distributedsystems cooperative whichareopento computersupport.The role of a shared activitiesof systemsmanagers is examinedin section4 and a systemmodel within distributedsystemsmanagement conligurationlanguagewhich allowsthe structureof distributedsystemsto t'e modelledis introduced.Finally,section5 identifiesthe varioustoolswhich we aredevelopingto support andthearchitectureusedto integratethem. cooperationin distributedsystemsmanagement 2. COOPERATIVE SYSTEMS MANAGEMENT It is our conjecturethat the activities surroundingdistributedsystemsmanagementare cooperativcin natureand are opento systemssupport. The supportof groupsof users hasbeena growingareaof researchoverthelast endeavours workingtogetheron cooperative of CSCWtogetherwith variouscooperative(or groupwarc) decadeandhasseentheemergence systems.
G. Dean, D. Hutchison, T. Roddenand I. Sommertilleare all with the Computing Department,Ittncaster University,ktncaster I'AI 4YR, UK.
The term CSCW was coined by Greif and Cashmanin 1984 [2] as a shorthandway of referringto he interestsof a numberof researchers involvedin theuseof computers to support usergroups.The areahasevolvedoverthelasteightyearsto combinetheunderstanding of the natureof group working with the enablingtechnologiesof computernetworking,systems Interested suppgltlqq applications. readersarereferredto [3,4] for moredetailsof groupware andCSCWsystemsFourgeneralclasses of cooperative systemhaveemergedfrom CSCWresearch activities: (1) MESSAGESYSTEMS Message systemsaredescendants ofearly electronicmail programswhichalloweda userusing a centralmachineto sendtextualmessages to otherus€rson the samemachine.As wide area networksdesignedto supportcomputercommunication becamemore widespread[5], electronicmail systemsincreasedin complexityandfunctionality. This developmentresultedin the formationof a MessageHandlingSystem(MHS) model described in theCCITT.X.4O0seriesof standards documents systemmakes [6]. Eachmessage useof a particularmessage formatto transferinformation(a message formatis oftendefinedas standards). a partof mostmessage Structuredmessage systemsare basedon the principleof exteqdingthe amountof machineprocessible semanticinformationavailableby adding structureto the existingmessage tbrmats.Systemsof this classincludetheCOSMOSpl and AMIGO [8] projectsandtheObjectt"ens[9], Strudel[10] andISM [11] sysr€ms. (2) COMPUTER CONFERENCING Computerconl'erencing systemsare also a development of the originalelectronicmail programs.However,structureis imposedin termsof how messages are grouped.A typical computerconferencing systemconsistsof a numberof groupscalledconferences, eachof which hasa set of membersanda sequence of messages. Conferences areoftenarrangedso thattheyindividuallyaddressa singleiopic.A usersubscribes to thoseconferences which are of interest.Usually,thesystemstoresinformationabouthow far eachconference memberhas read.This informationis normallyheldalongwith conference messages in onecentraldatabase ratherthantheindividualmailboxapproach usedin messaging systems. Examplesof thisclass lncludeNotepad of systems [12]andCOM tl31. Thedevelopment of reliablehighspeedcommunications hasleadto theemergerrce of newrealtime conferencingsystemssuch as RTCAL [14] which allow conferencemembersto in real-time.Multimediaor Desktopconferencing communicate systems suchasRapport[15] system[16] represent and the MERMAID Conferencing the introductionof multimedia systems.Suchsystemsintegratemanyformsof mediaincluding technologyinto cont-erencing audio,text andvideo. (3) CO-AUTHORINGAND ARGUMENTATIONSYSTEMS Co-Authoringandargumentation systemsform a generalclassof systemwhichaim !o support andrepresent the negotiationandargumentation involvedin groupworking.The cooperative authoringof documentsis demonstrativeof thiSclassof cooperationwherethe final generation of a documentrepresentsthe productof a processof negotiationbetweenauthors.This classof systemis characterised by its widespreaduseof hypertextte€hnology.Argumentationsystems include gIBIS [7] and SIBYL t181,while coAuthoringsystemsinclude Quilt [9] and CoAuthor[20]. (4) MEETINGROOMS Meetingroom systemsprovidecomputersupportfor faceto facemeetings.A typical aulomat€d face to face meetingroom consistsof a conferenceroom furnishedwith a large screen, projectoranda networkof computers. Examplesof meetingsroomsincludethe Colab [21] andthe PlanningLaboratoryat theUniversityof Aizona [22].
Thecooperative systemshighlightedabovesupportvariousformsof cooperation. Theseforms areto be foundin the activitiesof distributedsystemsmanagement. This paperexaminesthe natureof distributed-systems management highlightingthecooperation involvbdandindicating appropriate formsof systemssupportwhereapplicable. 3. DISTRIBUTED SYSTEMS MANAGEMENT Distributedsystemsmanagement researchers, arecurrently ry.in manynewareasof research, debatingboth techniquesand terminology.This problem is compoundedin the caseo? distributedsystemsmanagement by thevariedhistoryof researchers within thecommunityand the complexnatureof key conceptssuchas management itself. To limit confusionaird to em-phasise our focuso,nthecooperative processsupportingsystemsmanagement we adoptthe followingworkingdefinitionfordistributedsystems management: "Distributed systemsmanagement is the cooperativeprocess by which a group ' adninistersand controlsthefacilities andservicesprovidcd by a distibuted system" A definitionof this forrir-bee,s thequestion,who exactlymanages a system,particularlygiven theemphasison the role of the groupin themanagement process.It is our befef thatdystems management is a poten'jallyopenmanagement processwhereeachuserof a computingsystem actsas a systemmanagerover somesetof computingresources. obviously,someuserswill havea widerrangeof management tasksto performandwill beresponsible for a greatersetof resources. 3.1 A Testbed Managed System Theambiguityinvolvedin distributedsystemsmanagement reflectsmanyof thecharacteristics of cooperativesystems,and previousresearch[2] has demonstrated the importanceof the examinationandinvestigationof currentworkingpracticewithin systemdevelopment. Given this_ impetusour work hasbeenbasedon theintbrmalexamination of currentworkingpractice in themanagement of our localcampusnetwork. Our campusset-upconsistsof a numberof distinctUnix systems connected to a backbone campusEthernet(seeFigure 1). It is a reasonable conjecturethat futuredistributedsystems consistingof geographically dispersedLANs joined by high-bandwidth WANS till be comparable with our currentcampusnetwork.Eachof the individualLANs hasa substantial systemconfiguration.For example,the ComputingDepartmenthas approximately40 worktationsconnected via two localEthemets.
Ethernet
Figure 1: The Testbed Campus Network Each of the-departmental domainswithin the campushas an "official" systemsmanager for managingthatportionof the system.In the caseof the ComputerCentre,;all responsible
computingsystemmanagement is the responsibilityof a teamof managers.For historical reasonsmanagement of the.Engineering_domain hasbeenthe responsibilityof theComputing Department. How-ever, Engineeringis oftenconsidered asa separate entity andcannotreadily beviewedasa sub-domain of Computing. Initial investigation of ourlocal systemhassuggested thatoneof themostsignificantproblems for our systemsmanagersis the maintenance of systemconfigurations.Currentlyvery few toolsexistfor_recording andmaintainingsystem.configurations andmostinformationii kept informally by individual systemmanagers.In addition,a diverserangeof systemsactivitiesare evidentin distributedsystemsmanagement, and manyof theseactivitiesarecooperativein nature. 3.2 Supporting Management Activities A set of activities,often independent of eachother,constitutesthe processof systems management. To discoversomeof theactivitiesinvolvedwithin systemsmanagement we have workedalongsidesystemsadministrators andotherusersof the system.This informal study hashighlightedthat eventhe simplestof management taskscansometimesinvolve the needfol cooperation amongsttheparticipants involved.Forexample,considerthesituationwhereusers wish to sharesomeconfigurationinformation,as is often the cas€in sharedapplications.A commonsolutionis thatoneusergrantsaccessto a personalhle containingtheconfiguration inforlnationto a numberof colleagues. Unfortunately,it is equallycommonfor thebriginal userto forgetthis somemonthslateranddeletethefile, causingconfusionamongstthe other userswho sharetheconfiguration information. involvesa wide rangeof cooperative Systemsmanagement activitieswhich occurthroughout the managedprocessin an oflen dynamicand unstructuredway. However, the support requiredfor cooperativemanagcment activitiescan be consideredunderthe following five broadcategories: (] ) SUPPORT FORCONFTGURATION problemin distributedsystemsmanagement Configurationcontrolis a well recognised problemis compounded At first sight it would appear that this in the situationwhere [23,24). managementis perlbrmedas a group activity. However,by adoptingan approachwhere supportis providedfor the recordingandmaintenance of configurationinformation,manyof theproblemsassociated with configuration controlcanbemanuailyresolvedby a group. This approachof semi-automation whereonly thosepartsof an activity most amenableto is characteristic computersupportareautomated of manyof theapproaches adoptedby CSCW systems[25]. Tools arerequiredto supportthe recordingand maintenance of configuration ratherthan enforcarigid contigurationcontrol policies.Thesetools shouldincludea configurationbrowser(seesection5) which will allow configurationand dependency informationto be recordedand examined.Cooperativebrowsersof this form can provide editing facilities akin to thosefound in co-authoringsystems.Othertools may includea simple consistencycheckerwhich will examinerecordedinformationto highlight irregularities. However,we envisagethe correctionof theseirregularilieswill often be undertakenmanually team. by a management (2) SUPP0RT ANDREP9RTING FoR QUERIES A substantialpart of a systemsmanager'stime is takenup with respondingto queriesand messages concemingproblemswith the system[26]. Traditionally,the majority of queries were dealt with by a single systemsmanagerwho understoodandcontrolled a singlesystem. However, the current reality is that most systemsare too complex, particularly when consideredin conjunctionwith the applicationsthey support,to be understoodby a single giventhat administrators oftenrely on theknowledgeof particularapplication administrator. little knowledgeis recorded,andsystemsmanagers Unfonunately, of this acquired experts. or from otherswhenjobroleschangeor individualsmove usersoftenneedto leamnewexpertise location.Multiuser,hypertext systemssuchasAnswerGarden[27] allow knowledgeof this form to be recordedandsharedby a groupof users.
4. MANAGEMENT VIA A SHARED SYSTEM MODEL Thedistinctaim of our work is to providesupportfor thewide varietyof cooperative activities involved in distributedsystemsmanagement. The provisionof tools to achievethis aim is greatlyaidedby the overallfocusof the cooperativetasksinvolved.In general,manaqersof distributedsystemscooperateaboutandvia a sharedartifact,"rhesyster;", whichproiides a -us tbcus for much of their work. This generalstyle of work allows clearly to sebaratethe attributesof thesystembeing.managed (ths systemmodel)andthe activitiesof management (themanagement process), asillustratedin Figure2.
ManagementProcess
SystemModel Figure 2: SeparatingManagementfrom the SystemModel While the lbcus of our work is on the supportof the managementprocessthrough the development of cooperative tools,thesystemmodelhasa crucialrole to play.A modefof the systemprovidesa centralpoint of integrationfor manyof the tools beingdevelopedin the project.This allowsconfiguration informationto bereadilyrecordedandacCessed by a number of systemmanagers.In addition,the sharedsystemmodel providesthe focus for the cooperation involvedin distributedsystems management. The approached we haveadoptedis to augmentthe conceptsof cooperativeauthoringsystemsby providingadditionalspelialist toolsto supportspecificaspecrs of cooperation amongsta numberof ma"nagers. 4.1 Different Views and Perspectives The generalsystemarchitecturecentreson a numberof systemsmanagerssimultaneously accessinga sharedsystemmodel (seeFigure3). However,it shouldbe stressedthat while thesesystemsmanagers sharethis informationtheymayhavedifferentperspectives on it. For example,considering a simpleuserdirectory,theuserto whomthedirectorybelongswouldbe interestedin the detailsof the files anddirectoriesit contains(e.g,name,size,accessrights etc.).In_contrast,a systemadministrator in chargeof enforcinga strictpolicy of spaceusage would be interestedonly in_who _owns.the directory and how much spacethe directory consumes.We characterise thesealternativeperspectives asdifferentmanagers'views on thb samesharedentitywithinthesystemmodel.
.
Each systemmanagerexploitsdifferentviews of the system'sobjectsand configurations. Views arecharacterised by the systementitiesa managercan seeand the attributesof these entitiesthat theymay access.Thesedifferentviews arecontrolledby individual managerviews on the sharedmodelandaredisplayedto systemsmanagers graphically(seeFigure4). Each managercancustomisethis view andwill seethesystemdifferentlydependingon whichrole hisviewis currentlvadootine.
System Manaqer1
System ManagerN
System Manager2
System Model Figure 3; General Framework for SystemsManagement Theseparation of thesedifferentperspectives allowsus to controlaccessto thesharedsystem model.In addition,the deconstruction of certainfeaturesof the systemallowsthe modelto concentrateon the configurationof the systemsand the inlerdependencies found within it. Thuq,,rather thanembedmuchof thesemantics of themanagement process, our systemsmodel containsonly informationon thestructureof thesystemsandtheinterdependencies within it. Additionalmanagement information,suchasexpertiseandpolicy,areheldwithin appropriate tools.This decisionis reflected\iithin themodellinglanguage usedin theproject. 4.2 The Modelling Language The contigurationand structureof the distributedsystembeingmodelledis describedin a language calledSySL[3i, 24] derivedfrom moduleinterconnection languages suchasMIL75 and INTERCOL SySL allows the configuration hardware of and software systems [32] t331. to bedescribed at varyinglevelsof abstraction. in SySLin termsof abstractentities,whichyieldsmanyof thebenefis Systemsaredescribed of structuringprovidedby a hostof objectorientedapproaches. EachSySL entityhasan associated definitionwhichdefinesthestructure of theentity.For example,a SySLstructureto describe a machineanda structure for a networkwouldbe of theform: structure MACIIINE is Name Supplier Monitor Keyboard Processor Disk Memory OperatingSystem end structure
structure NETWORK is Narne Topology
s@
Meditmr end structure
Theseattributescanhavevaluesassociated with themwhich describedetailsspecificto each structure.In addition,SySLhasbeenaugmented to includea rangeof relationswhichcanbe exploitedto describeinterdependencies within the system.The additionof theserelation constructswasfoundto beessential for modellingcomplexdisfibutedsystems. For example, considerthe campusarrangement describedearlier,this requiresthe definition of a relationship to this networkstructure.Therelationshipmechanism to describeconnections addedto SySL definesa relationshipnameandthc domainandrangeof the relationship.The generalfonn of therelationshio constructis:
relation is d o m a i n< < C L A S S L I S T > > range > end relation A connect_to relationship can be defined as relation CONNECT_TOis domainNETWORK,MACHINE rangeNETWORK end relation This relationship can be used to describe the connectivity of machines and networks within the system. For. example,_the network in Figure 1 would have insrantiated sysl- objects to
describeeachof the sub-networks connectad to the backbone. Thesewouldb6 inrtuniiat"din SySLby thefollowingsratement : classNETWORKis computing,physics, cenrc,gcography, Ibackbone, environmenulscience, engineering] The SySL object describingthe backboneErhernetwould be of the form componentbdctbone: NETWORKis Name=>"Lancasrcr CampusBackbonc" => "Ethemct ToPologY Bus" Speed=> "l0Mbi6/scc" Medium=> "Co-axial" e n d c o mp o n e n t Each of the networks instantiated would have a corresponding component definition. Connectionsbetween the networks would be shown as SySL relation-sas foilows: physlcs CONNECT_TObackbone computingCONNECT,TO Tacl
