Evaluation of an Accounting Model for Dynamic Virtual Organiz ations

Martin Waldburger · Matthias Gohner · Helmut Reiser · Gabi Dreo Rodosek ·Burkhard Stiller

Abstract Accounting of Grid resource and service usagedetermines the central support activity for Grid systems tobe adopted as a means for service-oriented computing in Dy-namic Virtual Organizations (DVO). An all-embracing studyof existing Grid accounting systems has revealed that theseapproaches focus primarily on technical precision, whilethey lack a foundation of appropriate economic account-ing principles and the support for multi-provider scenariosor virtualization concepts. Consequently, a new, flexible,re-source-based accounting model for DVOs was developed,combining technical and economic accounting by means ofActivity-based Costing (ABC).

Driven by a functional evaluation, this paper pursues afull-fledged evaluation of the new, generically applicableGrid accounting model. This is done for the specific envi-ronment of the Leibniz Supercomputing Centre (LRZ) inGarching, Germany. Thus, a detailed evaluation method-ology and evaluation environment is outlined, leading toactual model-based cost calculations for a defined set ofconsidered Grid services. The results gained are analyzedand respective conclusions on model applicability, optimiza-tions, and further extensions are drawn.

M. Waldburger, B. StillerUniversity of Zurich, Department of Informatics (IFI), CH–8050Zurich, SwitzerlandE-mail: waldburger@ifi.uzh.ch, stiller@ifi.uzh.ch

M. Gohner, G. Dreo RodosekUniversitat der Bundeswehr Munchen (UniBwM), D–85577 Neu-biberg, GermanyE-mail: matthias.goehner@unibw.de, gabi.dreo@unibw.de

H. ReiserLeibniz Supercomputing Centre, D–85748 Garching near Munich,GermanyE-mail: reiser@lrz.de

B. StillerETH Zurich, Computer Engineering and Networks Lab (TIK), CH–8092 Zurich, SwitzerlandE-mail: stiller@tik.ee.ethz.ch

Keywords Grid Computing· Accounting· DynamicVirtual Organization· Activity-based costing

1 Introduction

Grid service accounting constitutes a central functional sup-port activity in both, research-oriented and business Gridsystems, as it facilitates the creation of service and resourceusage records. Accounting relies on successful user authen-tication and authorization. Once access to a resource or re-spectively a service is granted, resource usage has to beaccounted reliably. This results from the fact that account-ing data becomes retrievable for auditing purposes or—in afully competitive environment—it is finally transferred intocharging records which in turn will be equipped by mon-etary values so that a bill to the service consumer can beissued. These steps are reflected by AAA (Authentication,Authorization, Accounting) [19][27] and its extended view,A4C (AAA plus Auditing and Charging) [10][20].

Accounting for Grid systems represents an important re-search focus, since it constitutes on the one hand the keymechanism for commercial electronic services to be offeredand charged to customers and on the other hand, account-ing data potentially contain valuable information for a Gridservice provider regarding current and past service usage aswell as resource consumption. Such information can be usedfor charging purposes as well as for internal optimizationprocesses or service portfolio optimization. Both requireac-countable units that equip a service provider with significantinformation that correlates closely with chosen optimizationcriteria. For instance, a service provider may want to op-timize its cost-benefit ratio. For that purpose Grid serviceaccounting is required to produce records that allow this ser-vice provider to identify and classify the relevant set of costdrivers.

2

In the same way as Grid service accounting is of keyimportance to outlined reasons like successful commercial-ization and cost management, the respective steps of Gridservice accounting have to build on a solid theoretical ba-sis being represented by the appropriate underlying Grid ac-counting model. This Grid accounting model is required tosatisfy multiple demands. These comprise technical require-ments such as precision and scalability in obtaining account-ing records, and, equally important, economic requirementssuch as a sound support of established cost accounting meth-ods from the accounting across organizational boundaries inDVOs.

There are many accounting approaches for Grid sys-tems available, which lack a sound economic accountingbasis as they are highly specific to the considered applica-tion case so that they are not generically applicable [15]. Toovercome these shortcomings, a resource-driven and activ-ity-based accounting model for DVOs—as implemented byGrid systems—was developed [15][17]. The generic modelwhich is described in greater detail in Section 2.3 is usedto calculate costs incurred for a given Grid service in thecontext of a DVO. The developed model has proven to be ahighly promising approach from a functional point of view[15].

Based on the existing conceptual evaluation of our pre-sented approach in [15], a full-fledged assessment of thismodel in existing Grid environments needs to be undertaken.This evaluation constitutes the main focus of this work. Itis done by applying the generic model to the Grid infras-tructure operated by the LRZ, the Leibniz SupercomputingCentre in Garching near Munich, Germany [25]. The evalu-ation’s main goal consists in applying the conceptually eval-uated Grid accounting model to an existing operational Gridinfrastructure in order to reveal the key set of practical as-pects relevant for model application and to determine modelimprovements and extensions. In particular, the model is as-sessed by means of three dimensions. In consideration of themodel’s overall aim to calculate costs of a Grid service, theevaluation addresses achieved model functionality, availableand used means of model parametrization, and serviceabilityregarding the respective LRZ application context.

Accordingly, the remainder of this paper is structuredas outlined in Figure 1. Section 2 provides an overview ofrelated work for accounting in DVOs. Driven by the analy-sis of existing Grid accounting approaches (Section 2.1) andthe derived requirements on Grid accounting (mentioned ex-plicitly in Section 2.3), this includes in particular a presenta-tion of the respective key characteristics of previous achieve-ments, namely the developed DVO service model (Section2.2), a comprehensive Grid resource classification (Section2.4), and the developed Grid accounting model for DVOs(Section 2.3).

Fig. 1 Paper Structure (Sections in Brackets)

Later sections address this work’s core focus determinedas the application and evaluation of the generic Grid ac-counting model to the LRZ environment. This builds ona detailed description of the used application and evalua-tion methodology in Section 3, covering an in-depth inves-tigation of the considered LRZ Grid infrastructure and therespective multi-domain Grid accounting scenario (Section3.1), an all-embracing description on necessary steps to ap-ply the Grid accounting model to the determined scenarioand LRZ infrastructure (Section 3.2), and a definition ofobjectives and requirements for model application assess-ment. According to those outlined application and evalua-tion methods, model calculations and the according resultsare presented in Section 4 and discussed in Section 5. Drivenby the gained insights, the work is summarized and the re-spective conclusions are drawn in Section 6, including pro-posed adaptations of the Grid accounting model.

2 Related Work

In this section, related work addressing the research domainof Grid accounting is presented and relevant concepts arediscussed. Herefore, Section 2.1 contains an overview ofexisting Grid accounting approaches which are evaluatedagainst a list of 23 identified criteria, which have been de-rived on comprehensive requirements analysis as well asvarious accounting-specific use cases. Moreover, as a soundtheoretical basis for successful model application and evalu-ation, terminology in use and those key mechanisms for Gridservice accounting in DVOs need to be outlined. This cov-ers in particular the inspection of core achievements fromprevious work, namely those developed core models—DVOservice (Section 2.2) and Grid accounting model (Section2.3)—as well as an all-embracing classification of Grid re-sources and possible accountable units (Section 2.4).

3

2.1 Overview and Evaluation of Existing AccountingSystems

Based on a comprehensive survey on Grid accountingapproaches in [11] and [15], the following provides anoverview of existing accounting systems and tools from Eu-ropean as well as international Grid projects and finallypresents an evaluation of fundamental characteristics asshown in Table 1. In the survey, the following accountingsystems were analyzed:

– Accounting processor for Event Logs (APEL) [7]– Distributed Grid Accounting System (DGAS) [2]– Grid Accounting Services Architecture (GASA)/Grid-

Bank [4]– Grid Based Application Service Provision (GRASP)

[16]– Grid Service Accounting Extensions (GSAX) [5]– Multi-organisation Grid Accounting System (MOGAS)

[26]– Nimrod/G [6][3]– SweGrid Accounting System (SGAS) [29]

In consideration of technical aspects, Table 1 depictsthat, by focusing only on the accounting of physically ex-isting Grid resources, none of the examined approaches ad-dresses a concept for service and resource virtualization.Additionally, existing systems do not provide mechanismsfor the accounting of composed virtual services and virtualresources as they are usually offered within multi-providerGrid environments. These are both key requirements for ser-vice provisioning and the according accounting in DVOs.Additionally, to some extent, only static environments withGrid resources of homogeneous nature and few accounting

Table 1 Evaluation of Existing Systems (+ “Yes”, (+) “In parts”, –“No”, n.s “Not Specified”) [15]

Criteria Accounting System

APEL DGAS GASA GRASP GSAX MOGAS Nimrod/G SGAS

Interoperability and portability (+) (+) (+) n.s. (+) (+) + +

Scalability + (+) – n.s. + (+) + +

Integration (+) (+) (+) n.s. (+) + + +

Inter-organizational accounting + + + n.s. + n.s. n.s. +

Flexibility and extensibility + n.s. + n.s. + (+) (+) +

Support of existing standards – – (+) (+) (+) n.s. n.s. +

Support of multi-provider scenarios – – – – – – – –

Visualization of accounting data + – – n.s. n.s. + n.s. –

User transparency n.s. n.s. n.s. n.s. n.s. (+) n.s. (+)

Accounting of heterogeneous resources (+) + + (+) n.s. (+) n.s. –

Accounting of virtual resources – – – – – – – –

Accounting of virtual services – – – – – – – –

Virtualization concept – – – – – – – –

Support of high dynamics + (+) (+) n.s. n.s. (+) + +

Security n.s. + + n.s. + + n.s. +

Standardized, generic interfaces – – – n.s. (+) n.s. + (+)

Support of various accountable units/metrics + + + n.s. + n.s. n.s. –

Precision and abundance + + + + + + n.s. +

Support of different accounting policies + + n.s. n.s. + - n.s. (+)

Reliability and fault tolerance n.s. n.s. (+) n.s. n.s. n.s. n.s. +

Administration and management n.s. (+) n.s. n.s. n.s. n.s. n.s. +

Verification n.s. + + n.s. n.s. n.s. + +

Open source + + + – – n.s. + +

units are supported. Dynamic Grid environments with a highlevel of heterogeneity regarding services and resources, op-erating systems, and Grid middleware solutions are in mostcases not taken into consideration.

Beside the examined Grid accounting systems and tools,[18] presents a high-level description of an infrastructurecomprising accounting, banking as well as electronic pay-ment services that are used for service-oriented Grid com-puting systems. This mainly theoretical approach only incor-porates an accounting of elementary Grid services and phys-ically existing Grid resources. Compound virtual Grid ser-vices and resources in multi-provider domains of dynamicVirtual Organizations are not taken into consideration. Ad-ditionally, the proposed architecture mainly focuses on pay-ment issues and does not consider any aspects addressingthe determination of costs incurred for a provided Grid ser-vice by combining technical and economic accounting, thuslacking an adequate economic basis.

In general, the study of existing approaches revealed thatcurrently deployed Grid accounting systems mainly focuson technical precision and project-specific issues while theyare not based on adequate economic cost accounting princi-ples suitable for the accounting across organizational bound-aries and DVOs. In addition, present accounting systemsand tools usually have been developed for specific applica-tion areas comprising homogeneous hardware platforms anduniform technical infrastructures thus being not genericallyapplicable on highly dynamic Grid environments [8][11].Moreover, in many cases, the focus of existing accountingapproaches is mainly on technical optimization criteria likemeasurement procedures and metering points with regardto the acquisition of accounting relevant data. Despite thefact that existing systems as for example SGAS, DGAS andGASA consider economic aspects,e.g., payment schemesand bank services, business aspects of accounting regard-ing methods of cost calculation and cost accounting are nottaken into account by any approach.

Since the above identified missing characteristics of ex-isting Grid accounting approaches are of key relevance to atechnically and economically sound multi-domain Grid ac-counting, the need to develop an appropriate Grid account-ing model for DVOs became apparent. This led to majorachievements in the suitable DVO service (cf. Section 2.2)and Grid accounting models (cf. Section 2.3) on one handand in a classification of different Grid resource types on theother hand (cf. Section 2.4). These results of previous workconstitute a solid theoretical basis for the Grid accountingmodel’s application and evaluation.

2.2 DVO Service Model

In previous work [15], a comprehensive service model forDVOs was developed taking into account the concept of

4

resource and service virtualization within multi-providerGrid environments. This service model which reflects theprovider’s perspective is structured into two separate layers,i.e., a Virtual Organization (VO) layer and a layer of under-lying real organizations (RO) providing an adequate basiswith respect to appropriate structure descriptions and pos-sible compositions of virtual services and virtual resourcesprovisioned within the context of DVOs.

Figure 2 illustrates a formal representation of this ser-vice model comprising all relevant entities as for instanceVOs and ROs along with their elements,i.e., real services(S) and real resources (R) as well as virtual services (VS)and virtual resources (VR). Moreover, the UML notationof the service model reflects possible types of interactionsbetween involved elements as for example utilization, com-position as well as a mapping between VO and RO layers.A detailed overview of the service model along with a de-scription of its elements and fundamental characteristics, aswell as a presentation of concrete examples regarding re-source and service provisioning within DVOs can be foundin [11][15].

2.3 Grid Accounting Model for DVOs

Based on the service model for DVOs introduced in Section2.2 and driven by the analysis of existing Grid accountingapproaches (cf. Section 2.1), a generic accounting modelwas proposed [15][17] that allows for the accounting ofcomplex, composed virtual services and virtual resources in

1

0..*

1

1..*

1

0..*

includes

0..* 1..*

utilizes

0..*

1..*

1

0..*

0..*

0..*

is m

ap

pe

d

1

0..*

1

0..*

includes

1

0..*

includes

1

0..*

0..* 0..*

utilizes

0..*

1

0..*

1

0..*

1

0..*

0..* 1..*

0..*

0..*

0..*

utilizes

utilizes

1

0..*

0..* 0..*1

utilizes1..*1..*

0..*

0..*

1

includes

includes

is m

ap

pe

d

-elements

Virtual Resource

-elements

Real Service Real Resource

-members

Real Organization

-members

Virtual Organization

0..*

0..*provides resource(s) / service(s)

1

0..*

1..*

-elements

Virtual Service

0..*

elements from potentially

different ROs / VOs

Fig. 2 Formal Representation of the Service Model [11]

multi-provider Grid environments, thus, going a step furtherthan existing approaches.

The presented accounting model which focuses on eco-nomic and technical aspects was derived in accordancewith a set of determined generic, DVO-specific require-ments. Concrete examples are (i) compliance with the ser-vice model for DVOs, (ii) providing capabilities for bridgingthe concepts of cost accounting and technical accounting,(iii) support of various accountable units adequately reflect-ing resource consumption and service usage, as well as (iv)a high degree of flexibility, applicability, and extensibilityfor the use within highly dynamic Grid environments.

The proposed accounting model relies on two account-ing concepts that are well-known in the domain of (eco-nomic) cost accounting: These are the Traditional Cost Ac-counting System (TCAS) and ABC [21][22]. TCAS re-lates to established, standard methods in economic costaccounting—also referred to as managerial or internal ac-counting. Hence, details on principles of TCAS can be foundin text books on cost accounting, such as [23]. ABC isa widely accepted costing system that is particularly wellsuited for the accounting of electronic services [13]. In ourGrid accounting model, TCAS and ABC are interconnectedby means of so called service constituent parts, namelyPro-cessing, Storage, Transferring, andOutput, representing aconsistent set of building blocks every provisioned Grid ser-vice can be composed of. Figure 3 illustrates the fundamen-tal idea of bridging the gap between TCAS and ABC bymeans of the identified service constituent parts along withtheir central role in the accounting process.

In addition, these four service constituent parts representthe basic hardware functionality within the context of GridComputing, out of which any electronic service is assem-bled by some specific amount. The service constituent partsthemselves are adapted to the specific resource they reflect.This is required, since typically different costs incur, whena job is run on different hardware or with specified serviceguarantees. Thus, in addition to interconnecting TCAS andABC, these service constituent parts also interconnect eco-nomic and technical accounting. Technical accounting is de-fined as the ”collection of resource consumption data for thepurposes of capacity and trend analysis, cost allocation, au-diting, and billing. Accounting management requires that re-source consumption be measured, rated, assigned, and com-municated between appropriate parties” [1]. Accordingly,the use of service constituent parts as a concept in orderto configure activities for ABC links to the respective setof accountable units as needed for metering and accountingrecord preparation.

– Processingcalculates costs for computation and dataprocessing by using computational resources.

– Storageconsiders incurred costs for data storage andarchiving by means of storage resources.

5

Fig. 3 Accountable Units Overview [15]

– Transferring reflects costs for transferring data withinor between ROs or VOs respectively by use of networkcomponents.

– Output calculates costs for generated output,e.g.,printed documents, graphical representation of simula-tion results etc.

Moreover, in order to be able to allocate also other costsfor service provisioning which are not chargeable to anyof the above mentioned service constituent parts, a furthergeneric service constituent partOther has been specified.Concrete examples for this service constituent part are or-ganization-specific cost elements such as,e.g., administra-tive cost that accrue due to service provisioning, but whichcannot be mapped to a particular resource. Finally, the con-stituent partExternal is used to take costs into considera-tion that are associated with the usage of a service or a re-source provisioned by an external provider as for exampleanother VO. A detailed description of the identified serviceconstituent parts along with concrete examples with respectto applicable metrics, relevant cost drivers, and associatedcosts can be found in [15].

These identified service constituent parts are resource-specific and mapped to activities. This means that the finalIT product,e.g., in form of a composed virtual service con-sists of a number of sub processes whereas sub processesare composed by activities, and activities are finally com-posed by service constituent parts serving as building blocksin the cost analysis process. In the example given in Fig-ure 4, VO1 offers a virtual service that is composed of twoexternal services provided by RO1 and RO2. In addition tothe costs incurred by sourcing those external services, addi-tional costs as for instance for administrative activitiesareincluded on the VO level. Focusing on the first external ser-vice provided by RO1, the example reflects the cost-relevantactivities which are needed in order to provide this service

to VO1. Similarly, on level of RO1, an external service issourced from a third party, followed by RO1’s main pro-cess along with other cost elements that are not specifiedin greater detail at this stage. Within the administrative do-main of RO1, several steps that aggregate information aretaken, leading in a top-down approach to a fine-granular pro-cess cost analysis, until, on the lowest level, the respectiveservice constituent part assignment per real IT resource isconducted.

2.4 Grid Resource Classification

By means of those presented generic and extendable ser-vice constituent parts, our Grid accounting model providesthe basis for a highly flexible, resource-based accounting inDVOs. In order to apply the model to a complex and hetero-geneous environment such as the LRZ, however, an in-depthunderstanding of those resources of use in Grid systems isneeded. Within the context of commercial and research-ori-ented Grid environments,e.g., the D-Grid, a German-wideGrid infrastructure for establishing methods of e-Scienceinthe German scientific community [9], a variety of differenttypes of Grid resources having a high degree of heterogene-ity can be identified. The basic requirement of the account-ing system of supporting an accounting of various types ofreal as well as virtual Grid resources, which determine thebasis for electronic service provisioning, implies the devel-opment of a taxonomy of Grid resources and possible subtypes of resources.

Fig. 4 ABC Accounting Model for DVOs

6

Group of

resource

Possible

sub groupsExamples

Possibleaccounting units

Computational

elements

Multi processor systems

Single processor systems

Hardware elements/emulators

Storage

elements

Primary storageelements

Mass storageelements

Databases

Relationaldatabases

XMLdatabases

Network

components-

Software

components/

libraries-

Costs for:

Resources for

data aquisition-

Further

resources/

resource types

-

Due to different characteristics of resources very application-specificaccounting units

Vector computer

Parallel computer

Cluster computer (e.g., IBM p690 Cluster etc.)

High-performance computer (e.g., SGI Altix 4700 etc.)

etc.

Desktop PCs (e.g., X86, x86_64, PowerPC etc.)etc.

FFT hardware (e.g., special hardware emulators etc.)

Co processor

etc.

Main memory

Caches (e.g., special harddisk caches etc.)

etc.

RAID systems

Tape systems

Archive systems

etc.

mySQLOracle

IBM DB2

etc.

eXist

Xindice

Tamino

etc.

Router

Switch

Gateway

Communication networks (e.g., LANs, WLANs, WANs)

etc.

Software licenses (e.g., medical software etc.)

Program libraries

Specialized software

etc.

Gauging station (e.g., virtual telescope, observatories)

Specialized hardware (e.g., electron microscopes, etc.)

Sensors

etc.

Information systems

Visualization components

Administration/support

QoS parameters (e.g., priorities etc.)

etc.

CPU seconds

CPU hours

Wallclock time

Number of CPUs

Number of nodes

Number of computers/computer systemsMIPS

etc.

Number of page accesses

Main memory (max.)

Main memory (avg.)

etc.

Used storage (MB/GB/TB)

Used storage x time

etc.

Number of accesses

Utilization time

Value of extracted informationetc.

Bandwidth

Transferred data (MB/GB/TB)

etc.

Software licenses

Applications

Access to libraries

etc.

Number of accesses

Utilization time

etc.

Fig. 5 Classification of Grid Resources and Possible Accounting Units

Therefore, a classification of different Grid resourcetypes is presented. This classification provides an appropri-ate basis for the identification of accounting units and met-rics adequately reflecting resource consumption and serviceusage. Basically, the following set of Grid resources can beidentified:

– Computational elements– Storage resources– Network components– Databases/information repositories– Software components and licenses– Specialized hardware and scientific devices

In Figure 5 a detailed classification of Grid resourcesand possible sub groups along with a list of appropriate ac-counting units per resource type is outlined, thus providing auseful basis for the specification of accounting units for theidentified service constituent parts as described in Section2.3.

3 Application and Evaluation Methodology

In accordance with service and accounting model character-istics, and in consideration of the described Grid resources,

the used methodology for application and evaluation of thepresented Grid accounting model needs to be outlined. Sec-tion 3.1 determines an LRZ-specific scenario for Grid ac-counting model application and evaluation. This involvesdetailed considerations of LRZ infrastructure and Grid ser-vices as well as an overview of financial, cost-related inputdata. While Section 3.2 outlines those functional steps re-quired for Grid accounting model application, the set of rel-evant evaluation objectives and requirements is determinedin Section 3.3.

3.1 LRZ Scenario Definition

The heterogeneous supercomputing infrastructure of theLRZ constitutes a complex application environment for theGrid accounting model at hand. Section 3.1.1 introduces theLRZ Grid infrastructure components. This is followed bypresenting an elaborate accounting scenario in Section 3.1.2.The LRZ Grid infrastructure and the scenario provide thebasic frame for subsequent model application—in particularwith respect to cost calculations—and evaluation tasks.

3.1.1 LRZ Grid Infrastructure

As a service provider for scientific high performance com-puting, the LRZ operates computation systems for use byeducational institutions in Munich, Bavaria as well as ona nationwide level. Beyond operation of system hardware,services offered at the LRZ also comprise backup/archive,Grid Computing as well as training courses on usage of HPC(High Performance Computing) systems, parallel program-ming and optimization [24].

The LRZ infrastructure encompasses several computingfacilities. These consist,e.g., of the new National Super-computer “Hochstleistungsrechner in Bayern II” (HLRB II)based on SGI’s Altix 4700 platform which is optimized forhigh application performance and high memory bandwidth.Within the second phase of installation, the HLRB II hascurrently a total number of 9’728 CPU cores based on In-tel Itanium2 Montecito Dual Core processors with an over-all peak performance of 62.3 TFlop/s and 39 TByte of sys-tem memory as well as 600 TByte of direct attached disks.Current projects performed on the HLRB II reside in thedomain of applied mathematics, astrophysics, biosciences,chemistry, and computational fluid dynamics etc. [24].

Moreover, the LRZ consists of several Linux-based clus-ter systems of varying size, performance, interconnect, andarchitecture (32 and 64 bit Intel processors) comprisingclose to 700 CPU cores in total. In 2008, the LRZ Linuxclusters are extended to more than 3’500 CPU cores. TheLRZ Linux clusters offer shared and distributed memory,varying available memory sizes, parallelization based onmessage passing (MPI), and shared memory parallelization.

7

The main focus of the Linux cluster systems is the devel-opment and testing of HPC applications as well as capacitycomputing.

The computing facilities offered at the LRZ—in partic-ular the Linux clusters—are characterized by a high degreeof heterogeneity with respect to underlying hardware plat-forms, numbers of processors, sizes of shared memory, andbatch systems. In addition, three different kinds of Grid mid-dleware solutions (Globus Toolkit [14], UNICORE [30] andgLite [12]) are currently in productive use resulting in a het-erogeneous Grid infrastructure.

3.1.2 Multi-domain Grid Accounting Scenario

In the following, a fictitious scenario addressing the utiliza-tion and the accounting of a complex virtual service is pre-sented in detail. This scenario can be seen as a concrete in-stantiation of the service model introduced in Section 2.2.Itserves as a basis for the evaluation of the proposed account-ing model. Moreover, the example scenario is enhanced withconcrete values and parameter settings reflecting the usageof a compound virtual service consisting of several under-lying services and resources which can be seen as buildingblocks the virtual service is composed of. Based on existingreal-world accounting data reflecting service usage and re-source consumption within the layer of the underlying realorganizations,i.e., the Grid infrastructure at the LRZ, an ab-straction with regard to the virtual resources and virtual ser-vices provisioned within the layer of the Virtual Organiza-tions is being performed.

This multi-domain scenario as depicted in Figure 6 com-prises two VOs (VO1 and VO2) and two underlying ROsconsisting of the LRZ which is part of VO1 as well as afictitious Grid service provider being part of VO2 thus span-ning multiple administrative domains. For reasons of sim-plification, the presented scenario only contains a 1:1 map-ping between involved VOs and the underlying ROs,i.e.,one VO consists of exactly one RO. In real-world Grid envi-ronments, the normal case is that several ROs jointly partic-ipate in one or multiple VOs, respectively.

Within the considered example scenario, VO1 offers avirtual simulation service (VS1) performing large, three-di-mensional simulations of turbulent flows and reactive flowsin complex geometries. Accordingly, VS1 comprises severaldata- and computation-intensive tasks. In the scenario, thesimulation service VS1 provisioned by VO1 consists of sev-eral (sub) elements,i.e., real as well as virtual services andresources which are offered by different organizations (VOsand ROs) jointly contributing the offered functionality ofthevirtual service VS1.

The virtual simulation service VS1 comprises a virtualcomputation service (VS2) which is provided upon a com-pound virtual computation resource (VR1) on which com-

VR1

VO1 VO2

LRZ

Virtual

Ressource

VS R SVR

Virtual

ServiceReal Ressource

Real

ServiceEncapsulation

Provided

UponUser

Access

VS1(virtual

simulation)

VS2(virtual

computation)

VS3(virtual

storage)

R1(HLRB II)

R2(IA 64)

R3(Altix)

S1(short term

storage)

S2(long termstorage)

R4(NAS)

R5(SAN)

R6(VR

cluster)

R7(RV

cluster)

S3(virtual reality)

S4(remote visual.)

Ext. org

VS4(virtual

visualization)

Fig. 6 Fictitious Accounting Scenario

plex calculations are performed. Moreover, VS1 makes useof a virtual storage service (VS3) being composed of twounderlying real storage services (S1 and S2) offered withinthe LRZ. VS3 is used for the archival storage of acquiredsimulation results. The real data services S1 and S2 whichare responsible for the resource management coordinationas well as the transparent storage of the data are providedupon physically existing storage resources R4 and R5. Fi-nally, the virtual simulation service comprises a visualiza-tion service (VS4) offered by an external provider (VO2) inorder to graphically illustrate the simulation results whichare forwarded from the computation service VS2.

Within the considered scenario, 19 percent (=512 pro-cessors) of the supercomputer HLRB II (R1) are availablefor the execution of the user job. In addition, negotiatedQuality-of-Service (QoS) parameters with respect to,e.g.,execution time of a user job have to be met. Therefore, be-sides the HLRB II also a part of the 64-Bit cluster IA 64(R2) of the LRZ infrastructure comprising a total of 220 pro-cessors as well as 25 percent (=32 processors) of the LinuxCluster based on the SGI Altix 3700 Bx2 (R3) are used aspart of the virtual computation resource VR1. In order to per-form the necessary calculations of the simulation service the512 processors of the supercomputer HLRB II are used for2.5 hours with a memory utilization of 2 GByte per proces-sor whereas the physically existing resource R2 is utilizedfor 4 hours along with a utilization of 1 GByte per processorof primary storage. Finally, 25 percent of the SGI Altix 3700cluster is utilized for a time period of 6 hours together witha temporary consumption of main memory of 1.5 GByte perprocessor.

8

Simulation results with an overall size of 7 TByte arearchived on storage resources at the LRZ by use of the tworeal data services S1 and S2. In this context, frequently usedsimulation results with a total size of 2 TByte are stored for5 days on the network-attached disks of the HLRB II (R4) inform of network attached storage (NAS) for short-term ac-cess, whereas 5 TByte of infrequently used simulation dataare archived for 360 days by means of a storage area net-work (SAN) (R5).

Further functionality of the virtual simulation serviceVS1 offered to the customer includes graphical representa-tion of simulation results by means of a visualization ser-vice. Due to the fact that the user has specific requirementsregarding simulation data visualization, a customized visu-alization service (VS4) provisioned by an external provider(VO2) is used in order to visualize the simulation results byusing the real services S3 and S4 which are each based onspecialized visualization hardware or software (R6 and R7)offered at an external Grid service provider. In order to per-form a rendering of three-dimensional turbulent flow graph-ics, the visualization service VS4 is utilized for the time pe-riod of 2 hours. The accordingly resulting total costs are notdirectly obtainable by VO1 since VO1 does not have ac-cess to detailed accounting and charging records of VO2.Instead, aggregated and consolidated pricing informationisforwarded to VO1 in form of a bill.

3.2 Accounting Model Application Methodology

Applying an extensive and flexible accounting model to acomplex environment requires an elaborate methodology tobe in place. Figure 7 provides an overview of the chosenmodel application methodology. It is structured into twomain, chronologically separated building blocks, namelyABC taking input values from TCAS (0) and IT product costcalculation (1). IT product cost calculation relies on thoseactivity costs determined by ABC. Section 3.2.1 and Sec-tion 3.2.2 explain procedures required for (0), while Section3.2.3 details (1).

3.2.1 Annual Cost Input from TCAS

ABC seeks to identify costs per activity. In the applied meth-odology, activities are grouped by the criterion whether theycan be related to an IT product (2) or they lack a prod-uct relation (3). Activities with product relation are furthergrouped in production activities (4) and activities that sup-port production (5). The first category covers activities asdetermined by resource-specific instantiations of the intro-duced service constituent parts, namelyProcessing, Stor-age, Transferring, Output, External, andOther. The latterincludes activities such as IT service and infrastructure man-

Table 2 Considered Resource Attribution Keys

Attribution Key Unit

Floor space consumed by a resource, including spacerequired for maintenance

m2

Annual resource power consumption kW/yearAnnual resource uptime h/year

agement. Activities without product relation typically em-brace facility management and administrative tasks (6).

The accounting model takes annual costs of varioustypes as input. These cost elements constitute typical val-ues of TCAS. In the area of production-oriented activities,input values are needed in terms of annual costs with infras-tructure performance (A). This is due to the fact that IT pro-duction in this context means the provisioning and composi-tion of electronic services, such as a storage service. Theseservices, out of which the final IT product is composed, areprovided on infrastructure, that is, on IT resources. A givenannual cost element with infrastructure performance is ei-ther attributed directly to the specific resource it relatesto(I) or—in case these costs are not directly attributable to oneof the existing IT resources—that cost element needs to beattributed indirectly by means of an allocation base, whichisbound to an additional cost-relevant characteristic (II).IT re-sources, thus, reflect a concept from TCAS, namely the ideaof a cost center. These cost centers embrace LRZ-internalcomputing and storage resources (C) as described in full de-tail in Section 3.1.1.

In order to allocate indirect costs to resources, attribu-tion keys need to be in place as an allocation base. Ta-ble 2 lists those three attribution keys considered, namelyfloor space, power consumption, and uptime. The Grid ac-counting model is by no means limited to this specific setof attribution keys. This selection reflects information avail-able at the LRZ, cost-wise relevant to the specific LRZ re-sources. The initial investment (ine, not differentiating bet-ween state and LRZ financing share) and annual operationcosts (ine/year) for air conditioning infrastructure, emer-gency system, network infrastructure, and buildings con-stitute those LRZ cost elements with infrastructure perfor-mance that are not directly attributable to one of the consid-ered computing or storage resources. As internal and exter-nal network traffic specific to Grid services is currently notseparable from other traffic at the LRZ, all network-relatedcosts need to be handled as indirect costs, even though,in principle, these costs would qualify to be directly at-tributable to network resources and, in a second step, to theaccordingTransferringservice constituent parts.

Table 3 lists directly attributable costs with infrastruc-ture performance. These consider the annual cost elementsavailable from LRZ’s TCAS. Annual investment shares arenot directly available, but calculated as the division of an

9

Fig. 7 Accounting Model Application Methodology Overview

Table 3 Directly Attributable Annual Costs with Infrastructure Perfor-mance

Cost Element Unit

Annual investment share (reflects annual deprecia-tion depending on initial resource investment and re-source life time)

e/year

Annual electricity consumption (depending on thekWh price for electricity; excluding air conditioning)

e/year

Annual electricity consumption for air conditioning(depending on the kWh price for air conditioning)

e/year

Annual resource rental fee (applicable if resource isrented)

e/year

Annual software rental fee (total amount of softwarerental fees attributable to a resource)

e/year

Annual external labor costs (e.g., for on-site service) e/yearAnnual material costs e/year

IT resource’s initial investment by its life time. Similarly,costs for annual electricity are calculated with the help ofadditional parameters. They result from multiplying an ITresource’s annual uptime by its applicable kWh price andnominal power consumption.

After direct (I) or indirect (II) attribution of annual costswith infrastructure performance (A), total annual costs perconsidered IT resource—each representing a cost center—are revealed (C). Total annual costs per resource are definedas the sum of all direct annual cost elements and all indirectannual cost elements. The latter is attributed according totherespective annual cost share for air conditioning, emergencysystem, network infrastructure, and building costs. For in-stance, the annual air conditioning cost share for the Opteroncluster resource (cf. Section 3.1.1) is calculated by addingannual air conditioning operation costs to the annual air con-ditioning depreciation share (i.e., the division of the originalinvestment in air conditioning infrastructure by its life time),and multiplying this sum by the ratio of the Opteron cluster’snominal power consumption to the total nominal power con-sumption of all considered resources.

In contrast to annual costs with infrastructure perfor-mance (A), annual costs with labor performance (B) do notrequire an intermediate attribution step to cost centers,i.e.resources, since labor performance costs are directly relatedto activities (D). Annual costs with labor performance (B)and production support (5) embrace human labor activities

10

which are grouped after process activities of the IT Infra-structure Library (ITIL) [28] version 2. These best practicesdetermine the de-facto standard in service management. Therespective books on infrastructure and service managementsare of particular importance for this work as they are con-cerned with production support activities. Due to the factthat the LRZ cannot provide any information on employeework assignments for legal reasons, an estimation of whichITIL activity is more costly than another is not feasible atthis time. Therefore, it is assumed initially that all ITIL ac-tivities need to cover an equal cost share. These relativecost shares (20% for each ITIL activity, since 5 ITIL ac-tivity types are considered) are used as keys to attribute(III) annual costs with labor performance (B) and produc-tion support (5) to the respective ABC activities (D). Annualcosts are available at the LRZ for two labor categories, inter-nal operations and internal support. For both categories, thenumber of positions at the LRZ is multiplied by the averagewage, the results added, then multiplied by the applicablepercental cost share, and finally divided by the mathemati-cal product of annual working days and daily working hours.By this calculation (III), average costs per hour are gainedfor each considered ITIL activity (D).

Annual costs with labor performance (B) without prod-uct relation (3) include facility management and adminis-trative overhead activities. For both types, average costsperactivity (D) are directly retrievable (IV),i.e., an attributionaccording to a key is not necessary. Consequently, the ap-plied calculation method represents a simplified version ofthe method used for ITIL activities: The number of positionsat the LRZ is multiplied by the average wage, and the resultis divided by the mathematical product of annual workingdays and daily working hours. This results in average costsper hour and activity (D), whereas these activities embracethe mentioned facility management and administrative over-head.

3.2.2 Resource-specific Activity-based Costing

Table 4 gives an overview of those 15 activities (D) result-ing from either dividing resource-attributed costs by annualactivities (V) or attributing annual costs with labor perfor-mance (B) by either cost share (III) or by direct attribution(IV). For each activity, the corresponding service constituentpart is listed. Production activities (4) are represented by aProcessing, Storage, or externalOutputservice constituentpart, while production support (5) and facility/overhead ac-tivities (6) are represented by the service constituent partOther.

This list of activities constitutes the key functional stepin applying the Grid accounting model as it comprises thoseactivities that form the basis for ABC. At this step in modelapplication (D), first the full list of activities for building a

Table 4 Activities and Service Constituent Parts

Activity Service Constituent Part

HLRB II Processing32 Bit ProcessingIA 64 ProcessingOpteron ProcessingAltix ProcessingBackup, archive, SAN StorageNAS StorageVR cluster Output (external)RV cluster Output (external)IT infrastructure design and planning OtherIT infrastructure deployment OtherIT infrastructure operations OtherIT infrastructure technical support OtherFacility management OtherAdministrative overhead Other

service tree (F) from is available, and second the averagecosts per activity are revealed. This means,e.g., for thePro-cessingactivity Altix that costs for computing on that re-source per CPU second are known. In general, costs per ac-tivity and the accordingly applicable metric are determined.

All ProcessingandOutputactivities use CPU seconds,all Storageactivities use resource reservation events, andall Other activities use working hours as metric. AsOut-put activities are not provided internally, but are offered byan external provider (see Section 3.1.2 for scenario details),cost calculation and metric selection decisions lie withinthatother organization’s responsibility. Calculations for theseactivities, hence, are not performed with the same granu-larity as it is the case for internal activities. Consequently,the metric of CPU seconds is not used for actual cost calcu-lations, but seen as a metric to appear on a bill received bythat other organization.

From a business logic viewpoint, metrics are bound toABC’s activity drivers. Activity drivers are perceived as theevent or fact that influences an activity’s intensity with re-spect to costs incurred. ForProcessingactivities, this costtriggering event is found, for instance, in the atomic com-puting activity of a CPU second used on a given resource.Those chosen metrics, however, are neither fully determin-istically selected nor are they elements of a statically definedset of available metrics. Accordingly, those metrics chosenhere are on the one hand inspired by the overview on ac-countable units provided in Figure 5, on the other hand de-termined by metering capabilities available at the LRZ.

The activities determined as shown in Table 4 can ei-ther directly (VIII to XI) form elements of the service tree(F) for product cost calculation (1) or, before that, they canbe further refined in order to support quality adjustments(E). Quality-adjusted activities are determined for all inter-nal activities, thus according to the applicable scenario (cf.Section 3.1.2), for allProcessingandStorageactivities. The

11

underlying principle for quality adjustments funds on a qual-ity premium scheme. It supposes that non-adjusted activities(D) include a standard configuration. ForStorageactivities,a two-dimensional standard configuration is assumed. Forbackup, this includes a resource reservation of 1 TByte ca-pacity for the duration of 360 days, while for NAS, a capac-ity of 1 GByte for the duration of 30 days is assumed. Simi-larly, Processingactivities see a presumed two-dimensionalstandard configuration of 1’024 CPUs with 4 GByte of mainmemory per CPU available in case of HLRB II, and of 32CPUs with 1 GByte main memory per CPU for all otherLRZ computing resources. Whenever a standard configura-tion needs to be changed increased costs for (potentially)intensified resource usage are possible to be reflected by acost premium (VII), which is a percental supplement to theaverage activity costs (D).

A quality premium is represented by ABC’s resourcedriver concept. Resource drivers—as opposed to activitydrivers—are events or facts that influence a resource’s us-age intensity, such as a resource reservation for extendedstorage capacity. Multi-dimensional quality premiums areimplemented by defining a multi-dimensional unit. ForStor-ageactivities, that is GBd (GByte day), while forProcessingactivities, a unit called CGB (CPU second GByte) is used.Both units are calculated as the mathematical product ofeach involved single-dimension unit. For instance, quality-adjusted costs for theStorageactivity NAS are determinedby dividing first the standard,i.e., not quality-adjusted costfor NAS by its standard GBd configuration (368’640 GBdas the mathematical product of 1’024 GByte and 360 days).This intermediate result is multiplied by the respective qual-ity premium, resulting in quality-adjusted costs measuredbya unit ofe/GBd.

While the same quality premium concept applies for cal-culation of quality-adjusted activity costs ofStorageactivi-ties and ofProcessingactivities, the respective used multi-dimensional units need to be differentiated clearly: The unitof GBd is used exclusively forStorageactivities, and CGBis used exclusively forProcessingactivities.

3.2.3 IT Product Cost Calculation

According to the scenario-specific service tree depicted inFigure 6, in the following the methodology introduced inSection 3.2 concerning product cost calculations is alteredby means of concrete values. On the one hand used data di-rectly correlates to some extent to concrete values and pa-rameter settings acquired from the LRZ, on the other handsome of the data is based on assumptions or approximations,respectively.

On top-level, the virtual simulation service VS1 offeredwithin VO1 is composed of virtual services being repre-sented by the service constituent partsProcessing(VS2),

Storage(VS3), as well as the service constituent partOut-put (external), reflecting the usage of the virtual service VS4

offered at an external Grid service provider. Additionally, inorder to adequately reflect the activities being performed us-ing the virtual simulation service, tasks with regard to thedesign and planning of the compound virtual service VS1

have to be taken into consideration as well, resulting in a to-tal of 10 working hours estimated which are being mappedon a batch of 20 service requests. This implies that 5 percentof the resulting costs for these activities have to be calcu-lated per service invocation. Additionally, costs occurringwith respect to facility management (0.5 hours per servicerequest assumed) as well as administrative overhead (1 hourper service request estimated) being covered by the serviceconstituent partOther also have to be incorporated as rel-evant activities having a direct relation to the compoundvirtual simulation service VS1. Finally, expenses originat-ing from activities with respect to IT service managementhave to be taken into consideration as well. Due to the highdegree of dynamics within the context of DVOs as well asrapidly changing business processes, concerning the com-pound virtual simulation service VS1, configuration man-agement and change management constitute important ITILactivities which result in 15 working hours estimated each,also being mapped on a batch of 20 service requests. Thesesubcategories of IT service management, thus, result in totalin 30 working hours per 20 service requests.

The virtual computation service VS2 itself is performedusing the composed virtual computation resource VR1 com-prising the HLRB II (R1), the IA 64 cluster (R2) as wellas the Altix cluster (R3). Within the scenario, 512 proces-sors of the HLRB II are used for 2.5 hours (=9’000 CPUseconds) each with an average main memory utilization of2 GByte per processor, resulting in 1’024 CGB which islower than the standard configuration of 512 CPUs and 4GByte of reserved main memory by the factor of 2. Addi-tionally, in order to process the user job, the entire IA 64cluster (R2) comprising a total of 220 processors is utilizedfor 4 hours (=14’400 CPU seconds) along with an averagememory usage of 1 GByte per CPU resulting in 220 CGB intotal. Finally, 25 percent (=32 processors) of the Altix clus-ter are utilized for a time period of 6 hours (=32’600 CPUseconds) each, together with the utilization of 1.5 GByte ofmain memory per CPU (=48 CGB) which exceeds the stan-dard configuration for computing resources, thus, resultingin quality-adjusted costs per activity. Moreover, concerningthe virtual computation resource VR1 costs regarding the ITinfrastructure deployment as well as the IT infrastructureop-erations have to be taken into consideration, resulting in ato-tal of 10 working hours estimated per activity and per monthwhich have to be mapped on a batch of 5 service requests ofthe virtual computation service VS2. Due to fact that negoti-ated QoS parameters with respect to execution time have to

12

be met (cf. Section 3.1.2), also costs reflecting ITIL activi-ties in relation to Service Level Management (SLM) result-ing in 1 working hour estimated per service request have tobe incorporated into the product cost calculation.

Additionally, in the scenario the compound virtual stor-age service VS3 provided by VO1 comprises two real dataservices S1 and S2 offered at the LRZ which in turn are pro-visioned upon the physical storage resources R4 in form ofa network attached storage and R5 being a storage area net-work. Within the scenario depicted in Section 3.1.2, the realdata service S1 is used in order to store frequently used sim-ulation results with a size of 2 TByte for the time period of5 days, which results in a total of 10’240 GBd, thus exceed-ing the standard capacity and duration activity for storageresources. Besides, in order to archive 5 TByte of simula-tion data on the long-term data storage for 360 days, thereal data service S2 making use of a magnetic tape system(R5) offered at the LRZ is used. The utilization of the reallong-term storage service S2 results in a total of 1’843’200GBd. In addition, costs reflecting the IT infrastructure tech-nical support of the storage resources have to be consideredwhen calculating the costs of the activities being performedby means of the virtual data service. Hence, overall costs of5 working hours estimated in relation to technical storageresource support—to be mapped on a batch of 10 serviceinvocations—also have to be calculated per service request.In order to assure long-term archival storage of the simu-lation data using the virtual storage service VS3, activitieswith respect to continuity management also have to be con-sidered, resulting in 0.5 working hours estimated per servicerequest.

Finally, as shown in the service tree presented in Sec-tion 3.1.2, a virtual visualization service (VS3) is part ofan external Grid service provider (VO2) and is used in or-der to graphically represent obtained simulation results byconsuming two real visualization services, S3 and S4. Ac-cording to the bill which is forwarded by the external Gridservice provider to the customer VO1, a VR cluster (R6) aswell as a remote RV cluster (R7) both represented by the ser-vice constituent partOutput(external) are each utilized for1 hour (=3’600 CPU seconds).

3.3 Key Evaluation Objectives and Requirements

Based on the fact that the identified activities are resource-specific and have to be adapted to the particular resourcesthey reflect (cf. Section 2.3), the evaluation of the proposedaccounting model needs to include a detailed infrastructureand service analysis. This analysis needs to document whatresources are available (formally also reflected by resource-specific activities) and what commercial services need to berun on them (leading to a bill of activities and the fully doc-umented service tree). Based on this information, the evalu-

ation shall reveal what costs need to be covered per servicerequest.

As input data to the Grid accounting model, informationfrom the traditional financial and the cost accounting—bothareas of economic (as opposed to technical) accounting—is needed. This comprises, for instance, information on in-vestments or maintenance costs incurred during a fiscal year.These cost elements are first categorized into cost categoriesand secondly either directly or indirectly allocated to costcenters. Those steps still determine typical activities ina tra-ditional accounting system. The evaluation, thus, needs toanswer the questions whether such information was avail-able at the LRZ in the first place and if it was of the rightgranularity in order to deliver meaningful input for the ac-counting model.

Overall, the conducted evaluation shall answer how wellthe existing Grid accounting model is able to calculate coststo be covered for a specific service request. In particular,and by means of varying assumptions, the evaluation shalldepict for a real Grid infrastructure what input data andalso what level of detail is required to allow the model toproduce meaningful results with reasonable costs incurredby using the model. Further, potential improvements to themodel need to be derived. Driven by these key evaluation re-quirements outlined, the set of specific qualitative evaluationcriteria is determined as listed subsequently:

– Model functionality : General functionality of the Gridaccounting model and information content provided isassessed. This comprises in particular the achieved levelof result expressiveness, addressing both, gained insightas well as limitations encountered.

– Model parametrization: The applied set of serviceconstituent parts, considered metrics, and chosen activ-ity/resource drivers is examined in detail. This addressesunit characteristics with associated interdependencies.Effects of changes in calculation input parameter as-sumptions are of particular interest.

– Model application context: The respective available in-put data for model application by means of the presentedmulti-provider scenario is assessed. Sensitivity analyseswith respect to product cost impact caused by scenarioparameter changes are evaluated.

The discussion on model functionality is conducted inSection 5.1, while Section 5.2 assesses results with respectto model parametrization, and Section 5.3 is concerned withan evaluation of the model application context.

4 Results

Driven by the outlined application and evaluation method-ology, the proposed Grid accounting model for DVOs is ap-

13

���������

�������� ��� ���

��� � ��� ���� �� �����

������� � � � ���������� ���������� �

������� ����� ��������� ������� �������� � ����

�������� � � � � �����

��������������������

����� ����� ���� ��� ���

�� ���� ���� ���� ���� �� �� ����

���� �� � �� � � �� ����� ��

����� ���� ���� ���� ���� ���� ���� ���� ����� � ����

���� ���� ���� ���� ���� ���� ���� � ���

����� ����� ����� ����� ����� ����� ����� � ���

�������� � � � �����

� �� ���� ��� ��� ��� ��� � � � �

��������� ����� ���� ������� ��������� ��������� ������ �������� �

���������� ���� ������� ������ ������� ��������� ������ � ����

!��"#�"�$ ��������� ������ ���� ������ ������ ������ ������ �������� � ����

���� ������ ����� ���� ����� ����� ����� ����� � ����

� � � � � � � � � ����

� � � � � � � � � ����

� � � � ������� � � ������� � ����

%��#����"�� � � ������ � � � � ������ � ����

������������

�������� ������ ������ ������ ������ ������� ����� � ����

����� ���� ��� ����� ����� ���� ���� � ����

����� ���� ���� ���� ���� ������ ����� � ����

��������� ���� ���� ���� ���� ����� ����� � ����

�������� ���� ���� ���� ���� ������ ������ � ����

��������� ������ ������ ����� ������� �������� ���� ���������� � ����

���� ��� �� �����

&��� ���� ���� � ����

����� � ��

���������� ����������

��� ���� ����

� ����� ���

����'�#� �� �� �� �� �� �

&��� � ���� � ����

����� � �

��� ���� ����

� ����� ���

��#�"�����(���

!��#���"$��$���

��)#*���(�#��#�"�#�

�������������������

���������#(����

������������������������

��������������#�+����*�$

�!���"��#���$�%��

&'�����$�"��%�"'����%�#�����"�

&'�����$�"��%�"'����%�#�����"�

&'�����$�"��%�"'����%�#�����"�

,��#� ���-��"*��.��#"'���.����

���������������

/�#����"����"�0�������(��"�

)�#�"�(������

������������������������

�������������

*&'��#�"��1���"#�"�$2

*&'��#�"��1��#�"��������2

����#"����(������

�����������������

���������(��������'�#�

��#�"�����(���

����#"��#����

��)�#��#����

!-�#������+#

3�#�"��������"��

���������#�"���������"���'�#�

����������#���"$��$����"���'�#�

���������()#*����#�(�#�"�#��"���'�#�

�������+����(����"���'�#�

�����������"��

��#�����(�#����

��#�������(�#

�������������������

������������������������

�������������

�#�+����*�$

�������)#*(������$�

3���$�)#*����'�#�

�����#��#�"(�#���������������������

�����#��#�"(�#������$(���

�����#��#�"(�#����#�(���

�����#��#�"(�#���"'��"�������#

����#��"�����������

���������������

��#������"��(�$�������(������+#

��#������(�����#������+#

�����������������

������������������������

�������������

�������)#*(������$�

3���$�)#*����'�#�

Fig. 8 Annual Costs Calculation

14

plied to the determined multi-domain Grid accounting sce-nario. This is achieved by a full-cost calculation performedwith input data from the LRZ.

Figure 8 presents annual cost calculations which includeindirect costs resulting from the LRZ air conditioning sys-tem, the emergency system, its network infrastructure aswell as building costs. It needs to be stressed that initialinvestments in the first three mentioned categories are sub-sumed in the initial investment amount of the LRZ build-ing. Thus, a zero investment value for,e.g., the emergencysystem reflects the fact that these investment costs are notseparately obtainable.

While those investment and annual operations infras-tructure costs reflect indirect costs (II in Figure 7), Figure8 also depicts direct costs (I in Figure 7) such as materialcosts where applicable. Direct and indirect annual costs areattributed to the respective set of LRZ IT resources, consist-ing of computing infrastructure like the HLRB II cluster andof storage infrastructure such as NAS. These LRZ resourcesserve as cost centers (C in Figure 7) that need to bear annualcosts of approximately 28 millione.

Furthermore, Figure 8 visualizes annual costs with laborperformance (B in Figure 7). This covers in particular LRZ-specific information on number of positions, wages, work-ing days, and working hours. It needs to be stressed, how-ever, that these numbers are simplified target figures so that,in reality, differing numbers might apply. Additionally andsimilar to those zero investments reported for,e.g., the LRZair conditioning system, figures for internal facility manage-ment labor are zero. This is due to the fact that facility man-agement costs are included in the respective number for an-nual building operations. Annual facility management laborcosts—although being reported as zero here—and annualadministration labor costs are directly attributed (IV in Fig-ure 7) to activities, whereas annual operations and supportcosts are assigned (III in Figure 7) to activities by means ofan (equal) cost share of 20%.

Figure 9 focuses on activity-related cost calculations (Din Figure 7) of both considered activity cost types, averagecosts per activity and—with regard to non-standard activityconfigurations—quality-adjusted activity costs (E in Figure7). The calculation of average activity costs for activities oftypeProcessingbases on the assumption that all LRZ com-puting resources show a capacity utilization of 80%. For thetime being, the exact capacity utilization value is not mea-sured at the LRZ so that it needs to be estimated. A value of80% determines a conservative estimation, since annual us-age statistics at the LRZ show long queues of waiting jobs.These statistics are considered for all computing resourcesother than the HLRB II cluster. This cluster has seen a majorincrease of nodes in 2007 from 4’096 to 9’728 CPUs—a factwhich does not become apparent in the annual usage figures.In addition, annual statistics only account for the aggregated

uptime of so-called batch nodes (a logic composite of cur-rently 512 CPUs). Thus, annual statistics for the HLRB IIcluster do not allow to estimate its capacity utilization levelreliably. For that reason, the same level of 80% is assumedfor HLRB II activities.

Average costs forStorageandOutputactivities in Figure9 determine estimated values. In the case ofStorage, thesevalues are estimated from previous LRZ experience.Outputactivities for visualization of results represent external ac-tivities which are provided by VO2 (cf. Section 3.1.2). Theaccording activity costs constitute costs from the viewpointof VO1 only, whereas from VO2’s viewpoint, they consti-tute billed values. Billing information might not only coverVO2’s production costs,i.e., it might not follow a strict cost-oriented pricing, but incorporate a pricing scheme whichis profit maximizing. In addition, visualization services arerun on highly specialized, expensive equipment. For thesereasons, averageOutputactivities costs are estimated to behigher than,e.g., internal computing activity costs.

Standard duration and capacity forStorageactivities aswell as standard CPU and main memory numbers determineestimated values from LRZ experience, adopted to the pre-sented Grid scenario. The according quality premium valuescannot be substantiated at this time by specific statistics onresource drivers and, thus, costs caused by providing non-standard resource configurations. Therefore, quality premi-ums are initially set to an assumed (low) percentage of 5%.

Figure 10 visualizes product cost calculations accord-ing to the service tree depicted in Figure 6. These calcu-lations multiply the respective activity costs as outlinedinFigure 9 by the applicable accounted or billed units as de-scribed in Section 3.1.2 (scenario definition) and Section3.2.3 (product calculation specifics). This results in mone-tary values representing costs incurred by each activity and,in sum, in total product costs of 4’656e. The virtual ser-vice VS1 in Figure 6 relates in this context to the product forwhich costs are calculated. Thus, in application of the out-lined methodology of an activity-based, resource specific,full cost-oriented Grid accounting model, this calculationdetermines those costs that need to be covered by each in-vocation of VS1. It needs to be stressed that the resultingamount reflects costs, which are not to be mistaken for prod-uct pricing.

5 Discussion

Based on the evaluation objectives outlined in Section 3.3,this section assesses the results gained from the Grid ac-counting model application by means of the presented costcalculation. This implies the results discussion regardingmodel functionality (cf. Section 5.1), possibilities of modelparametrization (cf. Section 5.2), and the according evalua-tion of the model application context (cf. Section 5.3).

15

����������

��������� ����� ���� ����

����� �������

�������

��������������� �������� �������� ���

������ ����������� �����������

������� ������ ����� �� ���!"���� � ��!"����

� ������� � ������� � ������� � ������� � ������� ��� �� ��� ��

��������������� �������� �������� �������� �������� �������� �������� ��������

������ ����������� ����������� ����������� ����������� ����������� ����������� �����������

������������� ������������� ������������� ������������� � � � � � ��!�"�� ��#$ � ��!�"�� ��#$ �����������

� � � � � � � � � � � � � � � ��!�"�� ��#$ � ��!�"�� ��#$

�%�������� �%�������� �%�������� �%�������� �%�������� ��� � �%�������� �%�������� & ��� ��

��

��� �� '�(

����� �

� � )

�%�������* �%��������

������� ������ �����

��� �� �� �� �� ���

� � � � �

� � � � � )

�%�������� �%�������� �%�������� �%�������� �%�������* & �+,

������� �����

-�.� -�.� -�.� -�.� -�.�

��������������� ��� ��� ��� ��� ���

������ /� 0���.�� �

���%�� ���%�� ���%�� ���%�� ���%�� & .��

-�.� -�.�

��������������� ��� ���

�%�� ��%�� & .��

#����$������%�������!&

#����$������%�'�����!&

"�("��%�')�����!&

����������

1���� ��� �2�� 3�����

4�� �'��� �55��

4�� �'��� �55��

1���� ��� �2�� 3�������3����

4�� �'���������

4�� �'���������

/� 0���.�� �

(����� �!��'���*"(+��������+���

��������������"����(���

-������!�"2�� ��#$

-������!�"2�� ��#$

1���� ��� �2�� 3�����

1���� ��� �2�� 3�����

1���� ��� �2�� 3�������3����

1���� ��� �2�� 3�������3����

,$$����������"�!���-("��������������

���������������

,$$����������"�!������������������

1���� ��� �2�� 3�������3����

�������������(�����������

���*"(+��������+���

������� �����������������

."�������������(�)���������"����������

6#�� ����� ��������� � ��������(� ��� 3�����

6#�� ����� �2�������� � ��������(� �2�� 3�����

+,��!+,(�����($

���������"���������������

����������(��������������

+,(��

�!�������"����������/�����(������0"�!)����(��-�"-

1"�!���)��2"�����������(������������3�����!�������"����������/�����(�����

& +,�

(����� �!��'

�������� �����������������

4�������-����-�-��������"����������

6#�� ���������� � ���������� (� ��� 23�����

6#�� ���������� � ���������� (� �2�� 3�����

6#�� ���������� � ���������� (� �2�� 3�����

6#�� ���������� � ���������� (� �2�� 3�����

6#�� ���������� � ���������� (� �2�� 3�����

�+,�!�����������+�(��$

��������4��������)���

��������-����-�-�������������%(���4��&

+,(��

�!������4������/���-����-�-����(��-�)"-

1"�!���)��2"�����������(������������3�����!������4������/���-����-�-���

�#���$�����"��"�������������(!�����

�#���$�����"�)�"�����(!��)-���

�#���$�����"�)�"����(���)�����

�#���$�����"�)�"�����������!��"((���

�#���������-����-���

����������

��������������"����(���

/� 0���.�� �

/� 0���.�� �

/� 0���.�� �

/� 0���.�� �

�������������(�����������

5���!����-��)��-���

��-��������)������������

��������������"����(���

�������������(�����������

Fig. 9 Activities Calculation

5.1 Model Functionality

Both, the methodology developed and the specific calcula-tion performed reflect a high level of expressiveness. This isparticularly substantiated by a most direct implementationof the set of key Grid accounting model characteristics: Thecalculation incorporates annual costs resulting from the rel-

evant LRZ infrastructure and IT resources, which act as acost center from an (economic) accounting viewpoint. Thisprinciple of resource-specific calculations is continued bythe definition of resource-adapted activities. These activitiesare not only resource-specific, but support another impor-tant model characteristic as they are quality-aware. The in-troduced quality premium approach allows for configuring

16

�������������� ��� ���

���� ������������ � ��

����� ���

���������

������� ����� ��� � ���� �

����� ������ ��� � �� �

����� ������ �� �� ��� �

������� ������� ������������

�����

��� � ���� �� �

��� ����� ����� �

������������

���������� ����� �� �� �

���������� ����� ��� �

������������

����

�� ��� � �

�� ��� ��� �

�� ��� ��� �

� ��� � �

�� ��� �� �

� ��� ��� �

� ��� � �

������������

����

�� ��� �

� ��� �

����� � �

����� �� ��������� ���������

!�� �"�"����������

���#��$����%��$����

����� ��������� �

�����������������

����� �� �&��#� '�%����

� ��()���%��������"��*�� '�+�����

�,�� +�������*����� ���' �� ���� � '

�,�� +�������*����� ����*"� �

�,�� +�������*����������*��� �

�,�� +�������*��������% ������������

�,��������"� �'�"� ��-��� �� .

�,��������"� �'�"� ��-/�����*� *0���"� ��.

�,��������"� �'�"� ��-�� �� ����"� �'�"� �.

����� �� �&��#� '�%����

1�������"� *�'�"� �

� "� ������*������%��

�������������

Fig. 10 Product Cost Calculation

non-standard offers according to user demand—while stillbeing able to express increased resource usage or even lossesincurred by resources that might not be attributable to otherusers even though they are not used by the initial user. Forinstance, main memory for a node of the HLRB II clustermay be limited for one user to 2 GByte. The remaining 2GByte (4 GByte is standard per node), however, will not beavailable for another user. In that light, the existence of aquality premium seems appropriate.

In a similar way, the calculation has proven the Grid ac-counting model’s theoretical nature of being highly param-eterizable and, thus, being flexible, extensible, and generi-cally applicable. Flexibility is reflected exemplary by a highdegree of freedom to define input parameters, such as at-tribution keys. Extensibility is visualized by the exampleof freely configurable standard activities and quality adjust-ments. General applicability is substantiated exemplary bythe fact that costs related toTransferring—as one of thosefour basic service constituent parts of the original Grid ac-counting model—could be handled as an element of TCASfor pragmatic LRZ-specific reasons, even thoughTransfer-ring activities were foreseen initially to constitute a centralelement in the ABC part of the calculation.

The developed methodology and the appropriately deter-mined calculation are found to first integrate successfullytherespective viewpoints of technical and economic account-ing. Secondly, they show that the Grid accounting model’sexpressiveness finds implementation in a practically viableway to determine product costs for multi-domain Grid ser-vice scenarios. For the considered scenario, product costsof4’656 e were calculated, out of which a share of 34% re-sulted fromProcessingcosts, a comparably high share of36% fromStoragecosts, a 4% share fromOutputcosts, anda 26% share fromOthercosts. At first glance, costs of 4’656e per service instantiation might seem to be relatively high.However, the cost/performance ratio has to be considered inrelation to the respective field of application (e.g., consideran automotive manufacturer within a fully commercial envi-ronment).

Although the calculation demonstrates a successful Gridaccounting model applicability in general, it sees potentialfor further improvements. For instance, it does not considerload balancing aspects which might be of high impact for asupercomputing environment. Similarly, the calculation as itstands needs to consider costs caused by unused but not at-tributable resources in a more fine-granular way. This meansthat the concept of quality premiums needs to be extendedin order to better support competition for resources.

Furthermore, the calculation has revealed that the pro-posed Grid accounting model is in its application to a real-world environment like the LRZ not fully transparent for amodel user. In-depth knowledge, both about the model itselfas well as the underlying infrastructure and service param-eters is still needed. Thus, model and calculation should beextended to define,e.g., the generally applicable, relevant setof technical accounting metering points.

In order to conclude, the calculation is found to pro-vide valuable results in product cost determination by im-plementing the generic Grid accounting model in its full ex-pressiveness and successfully applying it to a real-world en-vironment. However, model application requires at this timeconsiderable effort in configuring and parametrizing the cal-culation.

5.2 Model Parametrization

As the Grid accounting model was applied to a real-worldenvironment for the first time, a number of calculation pa-rameters were required to be estimated. Other parameters,such as those mentioned asTransferringcosts, could not bemetered in a way that would have allowed for data usageas initially intended by the model. Despite such practicalconcerns, the resulting calculation is found to constituteanextensive and effective model application case. In the casethat assumptions were taken, these could be either estimated

17

�������������� �������������������������

��������

���� �� ��� ���� ���� ���

����

������ ���

������� ����� ��� ��������� ���������

���������� ��� ��� ��� ��� ����

���� ���� ���� ���� ����

���� ��� � ��� ���� ����

���� ���� ���� ���� ����

���� ���� ���� ���� ����

������ ��� ��� ��� ���� ����

!�� ��� ��� ���

��� ��� �� ���� ����

��� ��� ���

�� �� ��� ���

��� ��� ���

�� ���

�� ���

���� ���� ��� ��� ����

"�� ��� �� ���

!�������� ��� �� ���

�����#�� ��� ��� ��� ��� ���

�������������$���

% ����&��&��

��'��(���$�����������

�����������$�����

����)���(��*����#�*����

!�'������� �$����

("#������+��$������&,

("#������+����������������,

���������$�� ��

������������-�$����

��������������������&

��������� ���� ��&�������&

�������������$�����������&

�������������$���&�������&

������������������.����������&�/�����&��� ��

����������$�������

�����������$����

����������$ ��������������0��

�1�����������$����������������������

�1�����������$��������&$ ��

�1�����������$��������$�����

�1�����������$������#�������������

�1������ ���� ��

Fig. 11 Percental Impact on Product Costs of a 10% Calculation InputParameter Change

from past LRZ experience or they were clearly termed asassumptions.

In the light that some calculation parameters were esti-mated or assumed, a sensitivity analysis of key parameterchanges helps to assess one parameter’s change impact tothe overall product cost calculation. Figure 11 documentsthe respective percental change in product costs of (initially)4’656 e if one calculation input parameter is changed by10% of its value,ceteris paribus, meaning that all other pa-rameters are left unchanged. Most caused changes are as-sessed marginal with an impact on product costs of less than0.1%. However, there is a considerable impact on productcosts in some areas. The top five impact areas are identifiedas follows: Changes of 10% on Backup, archive, SAN pa-rameters of either average costs per activity, standard dura-tion activity, or standard capacity activity result in a changein product costs in the range of 2.6-2.8%. In other words,these parameter changes are leveraged by about a fourth.The second most important product cost change (in therange of 1.5-1.7%) is observed when selected parametervalues for the Altix cluster are altered by 10%. Changeson wage or position values for internal support labor fallinto a comparable class of relative impact, namely of 1.6%.The third largest leverage effect show selected parameterchanges for the IA 64 cluster, closely followed by effectsincurred by parameter changes in the area of internal oper-ations labor. The fifth largest impact on product costs showparameter changes for the NAS infrastructure, such as foraverage costs per activity (in the range of 0.7-0.8%).

������������������� ������������ �

������� ���� �� ��� ������ ��� ������

��� ��� ���

���� ��� ��� ���

��� ��� ���

�������� ��� ���

���� ��� ��� ���

��� ���

��� ��� ��� ��� ��� ���

��� ��� ��� ��� ��� ���

������� ��� ��� !�"� ���

� �����#������� ��#���������

$����%�%�����������

�����#������� ��#�

�&���'������ (�����#���)����#��������)

�&���'������ (�����#�����(%���

�&���'������ (����������(�����

�&���'������ (������� !�� ����������

�&����"� ��%���)�%���

�#%��������(�"���"��!��#

� �����#�*���(��)�!����

����+,�� !�� ��"����%�����)�'� ���

Fig. 12 Percental Impact on Product Costs of a 10% Scenario Param-eter Change

It has to be stressed that these sensitivity analyses con-ducted cannot provide completely unbiased insight with re-spect to product cost impact due to inherent dependencieson the chosen scenario. For instance, any change on inputparameters in relation to the 32 Bit cluster will not showany effect on product costs here, since this infrastructureisnot considered to be used in the applicable scenario. Nev-ertheless, these sensitivity analyses allow to identify pa-rameter values of particular importance which need care-ful inspection—especially in case such a parameter was as-sumed or estimated as it is the case,e.g., for the averagecosts per activity for Backup, archive, SAN. Thus, this cal-culation cannot only be helpful for product cost calculations,but it can serve as an instrument for optimizations.

5.3 Model Application Context

The developed methodology and the resulting calculationboth document that the Grid accounting model was success-fully applied to existing LRZ infrastructure. The chosen sce-nario, however, incorporates specifics that do not reflect cur-rent LRZ characteristics. Most prominently, the LRZ doesnot offer at present a virtual service similar to VS1. Neitherare virtualized resources made available as Grid services ina multi-domain environment. For such reasons, the scenariochosen needs to be deemed to be of a partially artificialnature. In the same manner as those previously mentionedpractical limitations of partially lacking technical account-ing metering data, this bears a risk to lower overall calcu-lation significance. Thus, a sensitivity analysis of scenarioparameter value changes is of particular interest.

As Figure 12 depicts, these sensitivity analyses con-ducted for 10% scenario parameter value changes show onaverage a larger impact on product costs than the averagepercental impact caused by those calculation input param-eter changes assessed in Figure 11. The respective top fiveimpact areas are identified as follows: Changes in durationand capacity scenario parameters for Backup, archive, SANcause the highest change in product costs (2.8%). This is

18

followed by parameter changes to the Altix cluster (1.9%)and the IA 64 cluster (1.2%), respectively. IT service man-agement parameter changes of 10% result in altered prod-uct costs of 0.9%, while duration and capacity parameterchanges to NAS show an impact of 0.8% to product costs.

In accordance with those conclusions drawn in Section5.1 and Section 5.2, these percental impact numbers consol-idate the identified need for an improved, more fine-granulartechnical accounting that substantiates parameter valuesbymeans of metered data instead of assumed values.

In summary, these areas of future improvements with re-gard to the proposed Grid accounting model were identifiedin the course of the successful model application to the LRZenvironment as performed and discussed so far:

– Consideration of load balancing aspects.– Extension of the concept of quality premiums to better

support competition for resources.– Consideration of costs caused by unused but not at-

tributable resources in a more fine-granular way.– Definition and integration of generally applicable set of

metering points for technical accounting.

6 Summary and Conclusions

With the ongoing trend of adopting Grid systems as a meansfor service-oriented computing in DVOs, the need for ap-propriate support mechanisms becomes apparent. Account-ing of Grid resource and service usage determines the cen-tral support activity since it prepares accounting recordsthatprovide the main input for analysis, optimization, and in par-ticular for charging and billing purposes.

An embracing study of existing Grid accounting systemsrevealed that these approaches focus primarily on techni-cal precision and on project-specific issues, whereas theydo not support multi-provider scenarios or virtualizationconcepts, nor are existing approaches based on appropriateeconomic accounting principles regarding cost calculation.Consequently, the determined resource-based, highly flexi-ble accounting model for DVOs [15] combines both, tech-nical and economic accounting by means of Activity-basedCosting, service constituent parts and defined accountableunits.

Driven by the successful preliminary conceptual evalua-tion of the proposed accounting model for DVOs, through-out this paper, a full-fledged evaluation of the presented ap-proach has been undertaken. For this purpose, the genericaccounting model was applied to an existing operationalGrid infrastructure operated by the Leibniz SupercomputingCentre in Garching near Munich, Germany in order to re-veal the key set of practical aspects relevant for this model’sapplication and to determine potential model improvementsand extensions respectively.

Therefore, based on a brief recapitulation of key mecha-nisms for Grid service accounting in DVOs, addressing theproposed DVO service and Grid accounting models, a tax-onomy of Grid resources was developed, providing an ap-propriate basis for the identification of accounting units andmetrics adequately reflecting resource consumption and ser-vice usage, hence, serving as valuable input with respect tothe evaluation methodology.

In accordance with those identified accounting modelcharacteristics, the appropriate methodology for the appli-cation and evaluation of the proposed model was specifiedin detail. This task included an in-depth investigation intothe LRZ Grid infrastructure and provisioned Grid services aswell as a description of financial, cost-related input data.Ad-ditionally, a multi-domain Grid accounting scenario, whichwas enhanced with concrete values and parameter settings,was introduced providing the basic principles for subsequentmodel application and evaluation tasks.

Based on the gained insights, various model calcula-tions comprising an annual cost calculation, an activitiescalculation as well as a product cost calculation have beenperformed and discussed according to a set of previouslyidentified evaluation criteria regarding model functionality,parametrization, and application context. In this regard,theassessment of those results gained from the presented costcalculation has revealed that the Grid accounting model con-stitutes an expressive, highly flexible, extensible as wellasgenerically applicable tool for two inter-related key pur-poses, (a) Grid service cost calculation and (b) cost opti-mization identification.

The proposed Grid accounting model demonstrates itsgeneral applicability to various organizational contextsthatmay range from small and medium-sized enterprises to largesupercomputing centers such as the LRZ. Due to the model’suniversal design putting emphasis on typical and config-urable activities in a Grid environment, insights gained fromthe model application case at the LRZ are transferable to fur-ther environments. Those model application steps,e.g., withrespect to activity configurations, resource adaptations,andquality premium definitions performed, will be conductedmethodologically fully in line with the application case per-formed. Thus, even though another organizational applica-tion context may expose different resources or other calcula-tion input data from TCAS, the Grid accounting model willbe able to cope with those context specifics by means ofconfiguring the according applicable set of activities of typeProcessing, Storage, Transferring, Output, OtherandExter-nal.

However, the application of the generic accountingmodel to a real-world Grid environment and the per-formed calculation exposed capabilities for further account-ing model improvements as for example the consideration ofload balancing aspects as well as the extension of the pro-

19

posed concept of quality premiums in order to better supportcompetition for resources. Additionally, due to the fact thatdetailed knowledge about the model as well as the underly-ing Grid infrastructure and service parameters is required,the model should be further extended in the way, that a rele-vant set of technical accounting and metering points respec-tively is defined from which relevant data can be gathered.

Finally, a sensitivity analysis considering the impact ofchanges with respect to modified calculation input param-eters as well as scenario parameter values has been con-ducted. This has substantiated the identified need of a morefine-grained technical accounting based on adequate meter-ing information.

Acknowledgements This work has been performed partially in theframework of the EU IST Network of Excellence EMANICS “Man-agement of Internet Technologies and Complex Services” (IST-NoE-026854). Parts of this work have been funded by the German FederalMinistry of Education and Research within the D-Grid Project undercontract 01 AK 800 B.

References

1. B. Aboba, J. Arkko, D. Harrington: Introduction to AccountingManagement; IETF RFC 2975, October 2000,http://www.ietf.

org/rfc/rfc2975.txt.2. C. Anglano, S. Barale, L. Gaido, A. Guarise, G. Patania, R. Piro,

F. Rosso, A. Werbrouk: The Distributed Grid Accounting Sys-tem (DGAS); (Accessed) February 2008,http://www.to.infn.

it/grid/accounting/main.html.3. A. Barmouta: Authorization and Accounting Services for the World

Wide Grid; Master thesis, University of Western Australia, June2004, pp. 1-154.

4. A. Barmouta, R. Buyya: GridBank: A Grid Accounting ServicesArchitecture (GASA) for Distributed Systems Sharing and Integra-tion; 17th Annual International Parallel and Distributed ProcessingSymposium (IPDPS 2003), April 2003, pp. 22-26.

5. A. Beardsmore, K. Hartley, S. Hawkins, S. Laws, J. Magowan,A. Twigg: GSAX Grid Service Accounting Extensions; Septem-ber 2002, pp. 1-30,http://www.doc.ic.ac.uk/~sjn5/GGF/ggf-rus-gsax-01.pdf.

6. R. Buyya, D. Abramson, J. Giddy: Nimrod/G: An Architecture fora Resource Management and Scheduling System in a Global Com-putational Grid; 4th International Conference on High PerformanceComputing in Asia-Pacific Region (HPC Asia’2000), Beijing, China,2000, pp. 1-7.

7. R. Byrom, J. Walk, D. Kant: User Guide for APEL – Ac-counting Using PBS Event Logging; March 2005, pp. 1-32,http://hepunx.rl.ac.uk/edg/wp3/documentation/apel/

apel-user-guide.pdf.8. C. Frogner, T. Mandt, S. Wethal: Cluster and grid com-

puting: Accounting and banking systems; May 2004,http://hovedprosjekter.hig.no/v2004/data/gruppe05/

files/cgc2004_report.pdf.9. D-Grid Initiative: D-Grid Initiative; (Accessed) February 2008,http://www.d-grid.de/.

10. Daidalos: A4C Framework Design Specification; Daidalos Deliv-erable Update D341, September 2004.

11. G. Dreo Rodosek, M. Gohner, M. Golling, M. Kretzschmar: To-wards an Accounting System for Multi-Provider Grid Environments;10th IFIP/IEEE International Symposium on Integrated Manage-ment (IM2007), Munich, Germany, May 21-25, 2007, pp. 1-10.

12. The EGEE Project: gLite – Lightweight Middleware for GridComputing; (Accessed) February 2008,http://glite.web.cern.

ch/glite/.13. J. Gerlach, B. Neumann, E. Moldauer, M. Argo, D. Frisby: Deter-

mining the Cost of IT Services; Communications of the ACM, Vol.45, No. 9, September 2002, pp. 61-67.

14. The Globus Alliance: The Globus Alliance; (Accessed) February2008,http://www.globus.org/.

15. M. Gohner, M. Waldburger, F. Gubler, G. Dreo Rodosek, B.Stiller: An Accounting Model for Dynamic Virtual Organizations;Seventh IEEE International Symposium on Cluster Computing andthe Grid (CCGrid 2007); Rio de Janeiro, Brazil, May 2007, pp. 1-8.

16. The Grid-based Application Service Provision (GRASP) Project:GRASP; (Accessed) June 2006.http://eu-grasp.net/english/

default.htm.17. F. Gubler: Accountable Units for Grid Services in MobileDy-

namic Virtual Organisations; IFI diploma thesis, University ofZurich, Zurich, Switzerland, March 2006, pp. 1-97.

18. J. H. Abawajy: Grid Accounting Service Infrastructure forService-Oriented Grid Computing Systems, SAG 2004, pp. 168-175.

19. The Internet Engineering Task Force (IETF): Authentication, Au-thorization, Accounting (AAA) Charter; September 2004,http:

//www.ietf.org/html.charters/OLD/aaa-charter.html.20. J. Jahnert, J. Zhou, R. L. Aguiar, V. Marques, M. Wetterwald, E.

Melin, J. I. Moreno, A. Cuevas, M. Liebsch, R. Schmitz, P. Pacyna,T.Melia, P. Kurtansky, Hasan, D. Singh, S. Zander, H. J. Einsiedler, B.Stiller: The ’pure-IP’ Moby Dick 4G Architecture; Computer Com-munications, Volume 28, No. 9, June 2005, pp. 1014-1027.

21. R. S. Kaplan, W. Bruns: Accounting and Management: A FieldStudy Perspective; Harvard Business School Press, December 1987.

22. R. S. Kaplan, A. A. Atkinson: Advanced Management Account-ing; Third Edition, Prentice Hall, January 1998.

23. M. R. Kinney, J. Prather-Kinsey, C. A. Raiborn: Cost Accounting:Foundations & Evolutions; 6th edition, Thomson South-Western,February 2005.

24. Leibniz Supercomputing Centre (LRZ): Computing Services;(Accessed) February 2008,www.lrz-muenchen.de/services/compute/.

25. Leibniz Supercomputing Centre (LRZ): LRZ Grid Portal; (Ac-cessed) February 2008,http://www.grid.lrz.de/en/overview.html.

26. D. Lim, Q. Thuan Ho, J. Zhang, B. Sung Lee, Y. Soon Ong: MO-GAS, A Multi-Organizational Grid Accounting System; SCS Inter-national Journal of Information Technology, Vol. 11(4), 2005, pp.84-103.

27. S. Mullen, M. Crawford, M. Lorch, D. Skow: Site Require-ments for Grid Authentication, Authorization and Accounting;Global Grid Forum GFD-I.032, October 2004,http://www.ggf.org/documents/GFD.32.txt.

28. Office of Government Commerce (OGC): ITIL; June 2007,http:

//www.ogc.gov.uk/guidance_itil.asp.29. T. Sandholm, P. Gardfjall, E. Elmroth, L. Johnsson, O. Mulmo:

An OGSA-Based Accounting System for Allocation EnforcementAcross HPC Centers; 2nd International Conference on Service Ori-ented Computing, November 2004, pp. 279-288.

30. UNICORE: Distributed Computing and Data Resources; (Ac-cessed) February 2008,http://www.unicore.eu/.