Metering System Companion

LEGAL NOTICE

This publication is based on current information and resource allocations as of its date of publication and is subject to change or withdrawal by CA at any time without notice. The information in this publication could include typographical errors or technical inaccuracies. CA may make modifications to any CA product, software program, method or procedure described in this publication at any time without notice. Any reference in this publication to non-CA products and non-CA websites are provided for convenience only and shall not serve as CA’s endorsement of such products or websites. Your use of such products, websites, and any information regarding such products or any materials provided with such products or at such websites shall be at your own risk. Notwithstanding anything in this publication to the contrary, this publication shall not (i) constitute product documentation or specifications under any existing or future written license agreement or services agreement relating to any CA software product, or be subject to any warranty set forth in any such written agreement; (ii) serve to affect the rights and/or obligations of CA or its licensees under any existing or future written license agreement or services agreement relating to any CA software product; or (iii) serve to amend any product documentation or specifications for any CA software product. The development, release and timing of any features or functionality described in this publication remain at CA’s sole discretion. The information in this publication is based upon CA’s experiences with the referenced software products in a variety of development and customer environments. Past performance of the software products in such development and customer environments is not indicative of the future performance of such software products in identical, similar or different environments. CA does not warrant that the software products will operate as specifically set forth in this publication. CA will support only the referenced products in accordance with (i) the documentation and specifications provided with the referenced product, and (ii) CA’s then-current maintenance and support policy for the referenced product. Certain information in this publication may outline CA’s general product direction. All information in this publication is for your informational purposes only and may not be incorporated into any contract. CA assumes no responsibility for the accuracy or completeness of the information. To the extent permitted by applicable law, CA provides this document “AS IS” without warranty of any kind, including, without limitation, any implied warranties of merchantability, fitness for a particular purpose, or non-infringement. In no event will CA be liable for any loss or damage, direct or indirect, from the use of this document, including, without limitation, lost profits, lost investment, business interruption, goodwill or lost data, even if CA is expressly advised of the possibility of such damages.

COPYRIGHT LICENSE AND NOTICE:

This publication may contain sample application programming code and/or language which illustrate programming techniques on various operating systems. Notwithstanding anything to the contrary contained in this publication, such sample code does not constitute licensed products or software under any CA license or services agreement. You may copy, modify and use this sample code for the purposes of performing the installation methods and routines described in this document. These samples have not been tested. CA does not make, and you may not rely on, any promise, express or implied, of reliability, serviceability or function of the sample code. Copyright © 2010 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies. Microsoft product screen shots reprinted with permission from Microsoft Corporation.

TITLE AND PUBLICATION DATE:

CA 3Tera AppLogic Best Practices: Metering System Companion Publication Date: DRAFT – Last Update January 28, 2011

ACKNOWLEDGEMENTS

Principal Authors and Technical Editors Alex Moscoso Terry Pisauro Gregory Buonaiuto

The principal authors and CA would like to thank the following contributors: Eric Tessler Peter Nickolov Becky Hester

CA PRODUCT REFERENCES

This document references the following CA products: ■ CA 3Tera® AppLogic®

FEEDBACK

Please email us at [email protected] to share your feedback on this publication. Please include the title of this publication in the subject of your email response. For technical assistance with a CA product, please contact CA Technical Support at http://ca.com/support. For assistance with support specific to Japanese operating systems, please contact CA at http://www.casupport.jp.

Chapter 1: Introduction 7 What this Guide Provides ...... 7 Common Terms ...... 8 Where to go for more information ...... 10 Technical Support ...... 10 Product Documentation, Education and User Forums ...... 11

Chapter 2: Getting Started 13 The Components ...... 13 Basic Metering Client (BMC) ...... 13 Basic Metering Server (BMS) ...... 13 Metering Gateway (MGT) ...... 14 Understanding the Metering System Process ...... 14 Collecting Metering Data through the BMC ...... 15 Reporting Metering Data to BMS ...... 15 What if the information is not transferred to the BMS? ...... 16 If A Closer Look at the Architecture ...... 17 Architectural Dependencies ...... 19

Chapter 3: Implementing the Metering System 21 Installing the BMC ...... 21 What can be configured and how? ...... 21 Starting the BMC ...... 22 Installing the BMS ...... 22 What can be configured and how? ...... 22 Starting the BMS ...... 23 Installing the MGT ...... 24 Setup the client-side SSL certificate ...... 24 Configuring Grids to Use the Metering Gateway ...... 25 What can be configured and how? ...... 26 Starting the MGT ...... 27 Collected Metering Data ...... 27 Error Messages...... 31 Customer Account Management ...... 32

Appendix A: Metering Server Command Line Reference 35 account create ...... 36 account destroy ...... 37 account reset ...... 37 account enable ...... 37 account disable ...... 38 account check ...... 38 account list ...... 38 account info...... 40 account set ...... 41

CA 3Tera® AppLogic® Best Practices 5

account change ...... 41 certificate sign ...... 42 message post ...... 43 message recall...... 43 message status...... 43 grid destroy ...... 44 grid list ...... 44 grid uptime ...... 45 grid downtime...... 46 grid change ...... 47 meter dump ...... 48 meter license ...... 52 meter exception ...... 53 meter appliance ...... 55 meter archive ...... 56 meter clean ...... 57 data receive ...... 57 message get ...... 58

6 Contents

Draft Document – Last Updated January 28 2011

CA 3Tera AppLogic is a turn-key cloud computing solution for enterprises and service providers who need to accelerate time to value, increase agility, and rapidly enter new markets with existing assets. It provides a fast track to private cloud creation with service assembly, dynamic provisioning and scaling, self-service, and resource metering, all in a single environment. CA 3Tera AppLogic takes the stack of hardware infrastructure previously needed to support an application and delivers it as software. This allows you to assemble and package n-tier services so they can be moved and scaled up or down. Load balancers, firewalls, and network-attached storage become virtual and reusable. Instead of being hardwired to each other, infrastructure components are abstracted and encapsulated at almost any level, with intelligence and a radically simple interface that enables you to visually drag-and-drop components together to assemble even complex composite business and infrastructure services.

CA 3Tera AppLogic also includes a built-in system for metering the resources used by each application. The system interacts directly with the scheduler, and the storage, virtual machine and connection managers. The metering system enables you to easily measure and create reports identifying the hardware resources assigned to each application and component and to implement sophisticated billing systems based on actual resource consumption.

This document provides an overview of the CA 3Tera AppLogic Metering system – including its components, installation and configuration options. It is intended to be used in conjunction with the standard product documentation included with your CA 3Tera download – not as a replacement for it.

Note: Although this document was written for the CA 3Tera AppLogic 2.9 release most of the steps can be applied to prior releases and will continue to be relevant in the next release.

CA 3Tera® AppLogic® Best Practices 7

Following is a list of terms you should be familiar with prior to using this document. For more complete discussion see the CA 3Tera AppLogic product documentation.

Term Definition

3tbmc Basic Metering Client Utility

3tbms Basic Metering Server Utility.

AppLogic Distribution Server The installation deployment vehicle for the AppLogic grid. The (ALDO) ALDO server is the central distribution server on which the CA 3Tera AppLogic software is downloaded and from which the grid node imaging originates.

AppLogic Distribution The directory on the AppLogic Distribution Server (ALDO) where Directory the AppLogic installation media files are stored. Typically this would be located in the following folder:

/var/applogic/applogic-version

For example:

/var/applogic/applogic-2.8.9

Appliance A copyable building block used to create AppLogic applications.

Application A single system object that includes everything necessary to run a specific distributed application – including the code, HTML pages, templates and scripts, databases and content, as well as the operating systems, middleware, file storage, load balancers, firewalls and all configuration information needed to reconstruct and run the application on an AppLogic grid. Each application has defined resource budget which specifies a minimum set of hardware resources (CPU, memory and bandwidth) required to run the application, and the maximum resource quota allowed.

Assembly A packaged structure of interconnected components that can be manufactured on demand and used in exactly the same way as one would use a virtual appliance. Assemblies can be grouped to create additional assemblies. Also referred to as a “composite appliance”.

8 CA 3Tera® AppLogic® Best Practices

Backbone, Backbone LAN Private LAN (192.168.x.x) used to connect the hosts in the CA 3Tera AppLogic grid.

BMC Basic Metering Client Application.

BMS Basic Metering Server application.

BMT Basic Metering subsystem, comprised of the Basic Metering Client (BMC) and Basic Metering Server (BMS)

Boundary Identifies the class name, input and output terminals, storage volumes, configuration values and defaults that comprise the definition of an appliance.

Catalogs Set of disposable infrastructure appliances, such as gateways, firewalls, load balancers, web servers, application servers, database servers, file servers, mail servers and so on. The main assembly of an application ties them together into a logical structure capable of running the application. This includes all information required to configure each appliance and tie them together.

Class volume Contains all of the software required to boot and operate an instance of a class – includes the operating system, application server and anything else the application needs.

Distro Set of software components (open source components) assembled into a working whole and distributed to the user community.

Core Grid CA 3Tera grid on which the AppLogic documentation site, Metering Server application, as well as other customer facing applications, are run.

Grid Key component in grid computing. In the context of this document a “grid” refers to the combination of multiple computer resources combined and managed by AppLogic.

Grid Controller A grid appliance that serves as the central point for managing the grid, creating, running and managing applications and monitoring operations.

CA 3Tera® AppLogic® Best Practices 9

Grid Nodes The physical computers that will be used to make up the grid that AppLogic runs on.

MGT Metering Gateway Application which provides a gateway through which grids running in a particular datacenter can report their license and metering data over https to the BMS – located either on-site or on the central CA 3Tera grid..

PuTTY A free telnet/SSH client that provides standard Windows type GUIs that can be used to perform SSH tasks. Although there are other tools which can be used to perform these tasks, the procedures provided in this document utilize the PuTTY suite – which includes PuTTY, PuTTY Pageant and PuTTYgen – to perform key installation tasks.

Singleton An uncopyable appliance. The graphic depiction in the editor includes and S symbol to indicate it is a singleton. Singletons are often used to edit or troubleshoot code.

SSH – Secure Shell Network protocol that allows data to be exchanged using a secure channel between two networked devices.

Following are additional sources of information to assist you with your CA 3Tera AppLogic implementation.

Technical Support

CA Technologies Support completed the transition from 3tera Systems to CA Technologies Systems on September 15th 2010. As a result, the following changes have been made to how Support is accessed: ■ Online Self-Service Support: The 3tera self-service link and 3tera Forum pages were retired and replaced by CA Support Online. ■ Email Support: All support email IDs that end in @3tera.com have been retired and will no longer allow issues or issue updates to be submitted. ■ Phone Support: All inbound calls will now come through the local CA Technologies country number or the North America 1 800 225 5224 number. All other inquires related to CA Technologies | 3tera should be directed to your local CA Technologies country number or the North America 1 800 225 5224 number.

10 CA 3Tera® AppLogic® Best Practices

The new product home page for CA 3Tera AppLogic is

https://support.ca.com/irj/portal/prddtlshome?productID=8383

Product Documentation, Education and User Forums

Product documentation for CA 3Tera AppLogic can be accessed through the following link: https://support.ca.com/irj/portal/anonymous/phpdocs?filePath=0/8383/8383_docmanindex.ht ml

Further training is available from the CA Learning Site: https://calearning.ca.com/plateau/user/cadeeplink.do?linkId=CATALOG_SEARCH_RESULTS&siteI D=United+States&keywords=applogic

Finally, there are also interactive forums where users can post questions, request information, or offer insight and suggestions. The forums, which were previously located at http://forums.3tera.com, are now available through the CA 3Tera Global User Community: https://communities.ca.com/web/ca-3tera-global-user-community/welcome-3tera-forum-users

To access the message boards and forums you will need to first create a CA Support Online account profile - if you do not already have one - and login in to Support Online. If you previously participated in the AppLogic Forums, your information has been transferred to the new CA 3Tera Global User Community - and your user name will be changed to your CA user ID associated with your email address. If you are a new user to the community you need to join the community first (click "Join this Community" link).

CA 3Tera® AppLogic® Best Practices 11

This chapter provides an overview of the metering system and focuses on the preliminary steps required to prepare your environment for its implementation.

The CA 3Tera AppLogic Basic Metering subsystem (BMT) consists of the following components: ■ Metering Client (BMC) ■ Metering Server (BMS) ■ Metering Gateway (MGT)

Basic Metering Client (BMC)

The Basic Metering Client (BMC) component continuously collects metering data for all applications running on the grid and reports that data to the Basic Metering Server (BMS) once a day.

You can then login to the BMS, via SSH, collect the reported data and use it to generate reports.

Basic Metering Server (BMS)

The Basic Metering Server (BMS) is a CA 3Tera AppLogic application that maintains accounts for each grid and stores the metering data collected by the BMC. In larger enterprise systems the BMS may reside on site, however it typically resides on the CA 3Tera master grid where it accepts metering data via SSH (default) or through HTTPS when a Metering Gateway (MGT) component is used.

The BMS also provides a command line interface with grid/account management commands that administrators can use to generate reports on collected metering data.

CA 3Tera® AppLogic® Best Practices 13

Metering Gateway (MGT)

The Metering Gateway (MGT) is a CA 3Tera AppLogic application that provides a gateway through which grids running within a particular datacenter can report their license and metering data to the BMS (either on–site or on the CA 3Tera metering system server) over HTTPS. In environments where there are multiple grids – and multiple BMCs - an MGT can also be used as a central collection point for an on-site BMS. The MGT typically resides on a grid within a customer’s datacenter where other grids within that datacenter do not have access to the Metering Server (BMS) via SSH due to security reasons.

The MGT is configured with the account name as well as the SSH public key that is required for grids to report their data to it. Through a simple menu-driven interface, which is accessed by running the MGT application, users can manage the SSL certificates in order to communicate with the BMS.

In addition to the input interface through which grids within the datacenter can report their metering data over SSH the MGT also implements an output interface through which it reports metering data to the BMS over HTTPS through port 443. As of this writing, that output interface cannot be proxied and the port number is not configurable.

Note: MGT serves a single metering account. If multiple accounts need to be operated within the same datacenter, multiple MGTs need to be run.

The basic metering operation consists of the following two functions: ■ Collecting and reporting metering data ■ Customer account management

These functions are performed by the BMC and BMS though, in cases where port availability may be an issue, the MGT can be utilized to report metering data from the grid.

The following example demonstrates how the metering data is generated, collected, added to a report and used to create resource usage bills.

14 Getting Started

The BMS residing on the CA 3Tera “master grid” – though this is not required as previously mentioned. In these configurations, an on-site MGT acts as an intermediary collecting metering data from the BMC running on the local grid controller and periodically delivering it to the BMS on CA Technologies master grid. Customers can then login to their individual accounts on the CA Technologies BMS and generate, on demand, any of the available metering reports.

Collecting Metering Data through the BMC

The BMC runs the 3tbmc utility on the grid controller and is responsible for initiating contact with the BMS\MGT. It continuously collects several metering metrics from all applications running on your grid. By default, this occurs once every 12 minutes. The collection is automatically initiated on your grid controller, via a CRON job, when it is created and this value is not configurable.

As the metering data is collected by the BMC, it is written to a file. For example:

/var/applogic/license/year.month.day.log

Reporting Metering Data to BMS

The BMC reports all collected data to the BMS (or MGT if configured to use one) once per day utilizing SSH to make the connection to transfer data. When BMC reports the metering data to the BMS/MGT, it executes the following command on the BMS/MGT, to invoke the metering client utility (3tbms) supplying the content of the data file as standard input.

3tbms data receive account grid_name signature year.month.day -- zipped

CA 3Tera® AppLogic® Best Practices 15

Note: The log files are zipped prior to transfer

When 3tbmc is invoked to report metering data to the metering server, it copies all metering files – with the exception of those files that were created on the current day - using secure copy to the metering server under the following path:

/home/account/grid_name-signature/year.month.day.zip

Once the metering data has been successfully posted to the BMS/MGT the local file is then deleted from the grid controller.

The 3tbms command line utility is used to: ■ Manages accounts for all grids ■ Manages the metering data store for each account ■ Generates metering data reports

See Appendix A for more information on these functions and a complete BMS Command Line reference.

After successfully copying each file, 3tbmc removes the file from its directory so that it will not be reported again. 3tbmc’s operation is synchronous and it guards itself from being invoked multiple times simultaneously.

When an MGT is being utilized, it reports any metering data it has received to CA’s metering system once a day at the time specified by the “report_hour” property (for more details on this parameter see report_hour under the MGT – What can be configured and how? section in Chapter 3).Like the BMC, if the MGT fails to transfer a file because it cannot contact the BMS or for some other reason, it logs a message in the system log of the controller, logs a message to the controller’s dashboard, and will attempt to transfer the files each hour until all data has been reported.

Once MGT has successfully reported its metering data to metering system, it archives the metering data – /home/account/grid_name-signature/archive- log_file_name – and retains it for a designated period of time – as specified by the “retention_days” property (for more details on this parameter, see retention_days under the MGT – What can be configured and how? section in Chapter 3). Once the retention period has expired, the metering data is permanently deleted from the MGT.

What if the information is not transferred to the BMS?

If the BMC should fail to zip a log file or to transfer a file (due to inability to contact the BMS or any other reason), it will log a message in the system log. For example:

"Metering report failure – Failed to zip log file." "Metering report failure – Failed to transfer log file for date date."

16 Getting Started

It will also log a generic message to the grid dashboard stating that it failed to report metering data to the metering server. The message in the system log gives the specific reason why this occurred.

The BMC will then automatically attempt to transfer these files - plus any newly collected files - when it runs again the next day. In addition to writing to the system log, the BMC will log a message to the grid dashboard. For example:

"Grid metering data could not be sent to 3Tera due to internal error, please contact support for assistance."

If the issue is the result of an inability to transfer the data to BMS the following message is logged to the dashboard:

Grid metering data could not be sent to 3Tera. This is a transient error; AppLogic will retry automatically and remove this message upon success. If this error persists more for more than 72 hours, please contact support for immediate assistance.

The BMC is packaged as a Perl script that is installed automatically when the grid controller is installed. It runs the 3tbmc utility which collects and reports application memory utilization to the BMS\MGT.

The BMS and MGT are packaged as CA 3Tera AppLogic applications. The MGT application runs on a grid within a customer’s datacenter, collects metering information for all grids of a single account and reports that metering data to BMS. If there are multiple accounts served by the datacenter, multiple instances of the MGT application must be run.

The BMS application maintains accounts and metering information for all grids. It is run either on the customer grid – or on the CA 3Tera core grid (in which case an MGT can be used to transfer the metering data over https). The BMS runs the 3tbms metering utility to manage accounts and collect account metering information. The MGT runs the 3tbms metering utility, as well, but only utilizes the data receive functionality. In addition, the MGT uses the 3tbmtkeys (SSL Certificate Management Utility) utility to create and manage client-side SSL certificate which it uses to communicate with BMS.

CA 3Tera® AppLogic® Best Practices 17

Here you can see the structural details of the BMS application:

In this example, you can see that the BMS application consists of the following: ■ Input Gateway (INSSLR) – which provides an entry point for network traffic into the Metering Server application. The Input gateway only accepts HTTPS and SSH connections. ■ Port Switch (PS8) – which splits SSH traffic. ■ Web Server Appliance (WEB5) – which implements the primary functionality of the Metering Server application. ■ NAS Appliance (NAS) – which maintains the metering data store for the Metering Server application. ■ OUT gateway (OUT) – which provides an interface through which email notifications are forwarded to CA 3Tera.

Consider the following example:

In this example you can see how the MGT is used. The MGT consists of the following: ■ Input Gateway (INSSLR) – which provides the entry point for network traffic into the Metering Gateway application. The Input only accepts SSH and HTTPS connections. ■ Metering Gateway (MGT) – which implements the primary functionality of the Metering Gateway application.

18 Getting Started

■ NAS Appliance (NAS) – which maintains the metering data store for the Metering Gateway application. ■ Output Gateway (NET) – which provides the gateway to the Metering Server (BMS) through which MGT reports its metering data and sends email notifications.

For the metering system to function properly, the following conditions must be met: ■ Grid Controller is able to access the BMS or MGT ■ MGT is able to access the BMS ■ SSH Client is installed and operational before the BMC

In addition, both the BMC and MGT applications require the following 3rd party packages/modules to be installed: ■ Gnu GPG version 1.2.7 ■ IPC::Run version 0.80 ■ Sort::Naturally 1.02 ■ AppLogic::UDL 1.59 (EDT version) ■ Getopt::Long ■ Time::Local ■ Text::Wrap ■ Net::SMTP

These dependencies are enabled by default within the Grid Controller and Metering System itself– no manual intervention is required.

CA 3Tera® AppLogic® Best Practices 19

This chapter focuses on how the metering system is implemented within CA 3Tera AppLogic.

The BMC is a Perl script that is executed within the AppLogic Controller. It is installed automatically when the grid controller is installed.

What can be configured and how?

All necessary configurations for the BMC’s operation are retrieved from the applogic.conf configuration file or are hard-coded within BMC. When the BMC is invoked to collect metering data, it reads information from the applogic.conf file to retrieve the grid signature, customer account name, and the name of the metering server. It then retrieves a timestamp and enumerates each application that is currently running, outputting the results as a record to the metering data file.

The applogic.conf file is automatically populated after the initial installation. It contains the following parameters for the BMC:

Parameter Type Notes Name String Name of grid Signature String Grid Signature (public SSH key) meter_srv String Name or IP address of Metering Server. Default is grm.3tera.net Account String Customer Account Name meter_srv_port Int Specifies port by which 3tbmc connects to the metering server via the SSH protocol

CA 3Tera® AppLogic® Best Practices 21

With the exception of the signature parameter, which is generated automatically when the grid is installed, these parameters can be configured through the ./aldo set command.

Communications details between the BMC, BMS and MGT are specified through the applogic.conf configuration file and the BMS boundary definitions.

Starting the BMC

The BMC is loaded periodically by a cron job. This occurs automatically and does not require manual intervention.

The BMS is released as an exported application package from CA 3Tera AppLogic. It is installed on the grid by running the app import command from within the 3t AppLogic shell. For example:

3t app import BMS

Note: If you will be using the BMS installed on the central CA 3Tera AppLogic grid see the MGT Installation section for details on using the MGT to connect to that BMS.

What can be configured and how?

Since the BMS is delivered as an application, the configuration details are managed through the application’s boundary. Following is a list of properties that can be parameterized on the boundary of BMS. These properties may be set through the AppLogic Editor or on the command line using 3tappcfg.

Parameter Type Notes in_ip IP address This is the IP address that all BMCs/MGTs use to report metering data as well as to manage accounts and grids. This property is mandatory in_netmask IP address Netmask for the public input. This property is mandatory in_gateway IP address Gateway for the public input. Default is empty, i.e., no gateway out_ip IP address This is the IP address at which received email notifications are forwarded. This property is mandatory out_netmask IP address This is the netmask for the output through which email notifications are forwarded. Default: 255.255.255.0. out_gateway IP address Address of IP gateway to be used to route traffic. This property must be specified in order to access a mail server that is outside of the IP network on which BMS is

22 Implementing the Metering System

Parameter Type Notes running, i.e., most cases. Use 0.0.0.0 to disable. This property is mandatory dns1 IP address IP address of a DNS server for host name resolutions. Used to resolve the mail server name. This property is mandatory dns2 IP address IP address of a backup DNS server for host name resolutions. Used to resolve the metering server name. Default: 0.0.0.0 mail_srv String IP address or DNS name of mail server to which email notifications are to be forwarded. This property is mandatory misc_param String Space separated list of email notification parameters for email notifications generated upon the first report received for new grids:

to_email – one or more addresses separated by commas to which notifications are sent. If empty, no notifications are generated. Default is “”

from_email – from email address specified in notifications. Default is [email protected]

reply_email – reply-to address specified in notifications. Default is [email protected]

In addition to this, the Metering Server application uses the following user volumes: ■ content – Volume used to store the metering server-specific files

■ data – Volume used to store the metering data

The content volume is read-only and not modifiable. The data volume, however, should be resized as appropriate to accommodate all of the metering data.

The BMS does not support reconfiguration while in execution. Therefore, you will need to stop the BMS prior to making any configuration changes. This can be done through the AppLogic UI or by executing the following command from the grid controller:

3t app stop BMS

Starting the BMS

The Metering Server is started by starting the BMS application through app start command

3t app start BMS

CA 3Tera® AppLogic® Best Practices 23

If you will be using the BMS located on the central CA 3Tera AppLogic grid, collecting metering data from multiple BMCs or if you need to use SSH to transfer metering data to an on-site BMS through https , you will need to install an MGT.

The MGT is released as an exported locked application package from CA 3Ter AppLogic. It is installed on a grid by executing app_import command from the 3t AppLogic command shell. For example:

3t app import MGT

Important: If the MGT will be exporting metering data to the CA 3Tera metering server it must have access to the internet.

Setup the client-side SSL certificate

The MGT uses SSL certificates to authenticate itself and communicate with CA's metering system. To install a signed SSL certificate from CA on the Metering Gateway do the following: 1. Start the Metering Gateway application. A message should be logged to the grid dashboard specifying the SSL certificate is missing. 2. Login into the MGT application (app login MGT) The following simple text menu is presented: Metering Gateway SSL Certificate Management Utility - version 1.0.0 Copyright 2006-2008 3Tera Inc. A. Create new SSL certificate B. Delete current SSL certificate C. Display current SSL certificate D. Test notifications Q. Exit

Please enter selection --> Where:

– Create new SSL certificate generates a new SSL certificate. If an SSL certificate already exists, the user is prompted before deleting the existing certificate and generating a new one. Upon successful certificate creation, the certificate signature request is displayed and the user is instructed to e-mail the certificate signature request to CA so that the certificate can be signed. The signed certificate is to be installed on the data volume, see Installing SSL Certificate for instructions on how to copy the signed certificate to the data volume.

– Delete current SSL certificate deletes the SSL certificate for the account.

– Display current SSL certificate displays either the signed SSL certificate or the certificate signature request. If the certificate has already been signed, the signed certificate is displayed. If the certificate has not been signed, the certificate

24 Implementing the Metering System

signature request is displayed and the user is instructed to e-mail the certificate signature request to CA so that the certificate can be signed.

– Test notifications verifies that a message can be written to the dashboard of the grid controller. The user is prompted to verify that the dashboard displays the message and that any recipients of email notifications received the email from the grid controller. 3. Select Create new SSL certificate 4. Copy and paste the displayed certificate signature request into an e-mail and send it to CA 3Tera support. 5. When CA technical support replies with the signed certificate, save the certificate to your local machine. 6. As a grid user (not a maintainer), scp the certificate to the data volume from your local machine: scp signed_SSL_certificate_file grid_IPaddress:/app/mgt/data/mnt/data/ssl/mgt.cert

7. Verify the signed SSL certificate has been copied by logging into the MGT application and selecting the Display current SSL certificate menu option. 8. Restart the mgt appliance: comp restart MGT:main.mgt

9. Verify no error messages are logged to the grid dashboard. If there are error messages, please contact CA technical support.

Configuring Grids to Use the Metering Gateway

To configure your grid to report metering data to the MGT application, do one of the following: ■ For new grids: Update the account_srv parameter in the default.conf file of the CA 3Tera AppLogic distro to the IP address specified by the in_ip property on ./aldo new, include the account_srv parameter and set it to the IP address specified by the in_ip property ■ For existing grids: Execute the following command: ./aldo set grid=grid_name account_srv=input_IPaddress

CA 3Tera® AppLogic® Best Practices 25

What can be configured and how?

The Metering Gateway is configured through parameters on the MGT application boundary. Following is a list of properties that can be parameterized. These properties may be set through the AppLogic Editor or on the command-line using the following command: app config MGT --boundary Parameter Type Notes in_ip IP address IP address for the private input. Used to obtain metering data, as well as to manage accounts and grids. This property is mandatory in_netmask IP address Netmask for the private input. This property is mandatory in_gateway IP address Gateway for the private input. Default is 0.0.0.0 ( i.e., no gateway) in_allowed_hosts String List of hosts and/or subnets allowed to connect to the Metering Server through the private input. This is a space or comma separated list. Default is “0.0.0.0/0”( i.e., all allowed to connect) out_ip IP address IP address for the public input. IP address through which MGT reports its metering data. This property is mandatory out_netmask IP address Netmask for the public input. This property is mandatory out_gateway IP address Gateway for the public input. Default is empty (i.e., no gateway) dns1 IP address IP address of a DNS server for host name resolutions. Used to resolve the Metering Server name. This property is mandatory dns2 IP address IP address of a backup DNS server for host name resolutions. Used to resolve the Metering Server name. Default: 0.0.0.0 account_name String Customer Account name. This property is mandatory account_pub_key String Customer public SSH key. This property is mandatory report_hour String Time at which MGT is to report its metering data to the BMS. Format: 'HH:MM', where HH is a value between 0 and 23 and MM is a value between 0 and 59. Default: 12:00 (12 noon) retention_days Integer Number of days MGT is to keep archived metering data. Once the number of days has expired, the metering data is permanently deleted provided that it has been successfully reported to the BMS. If set to 0, no metering data is archived and

26 Implementing the Metering System

Parameter Type Notes is permanently deleted once it has been successfully reported to the BMS Default is 30 days.

In addition, the MGT has the following user volumes:

■ data – Volume used to store the metering data.

The data volume should be resized, as appropriate, to accommodate all of the metering data. It should be sufficient to store at least 30 days of metering data for all grids that report to this instance of MGT (approximately 4 MB per grid for 30 days of metering data). For example, to resize the data volume to 3 GB, execute: vol resize MGT:data size=3G

As with the BMS, the MGT does not support reconfiguration while in execution.

Starting the MGT

The Metering Gateway can be started either by selecting the MGT application in the AppLogic UI and choosing Start from the right-click menu or by executing the following command from the grid controller:

3t app start MGT

The file containing the metering data that is reported to BMS has the following format: report Rdate-time-tzone { grid name { collection_interval = val server_collection_interval = val app_list_failure = val comp_list_failure = val srv_list_failure = val usr_list_failure = val local_epoch = val local_tzone = val version = val description = val controller_ip = val controller_hostname = val n_apps_running = val

CA 3Tera® AppLogic® Best Practices 27

n_servers = val n_servers_enabled = val total_mem = val total_cpu = val total_bw = val tag = val uptime = val ha_state = val switches { Switch:id=value,name=value,network=value, mode=value,manufacturer=value, detection_method=value … } avg_comps_per_app = val ha_msg_txt = val vol_msg_txt = val ssl_sh1_fingerprint = val n_dashboard_msgs = val n_dashboard_alerts = val } application name: ref1=value,ref2=value,state=value, cpu=value,mem=value,bw=value,uptime=value,locked=value, tag="value" { component name: uptime = value,t_start = value, cpu=value,mem=value,bw=value,server=value, state=value,class=value,locked=value,tag="value", os_guess=value,os_type=value,os_flavor=value, os_version=value,pv_driver=value ... } ... server name { } ... user: id=value,license=value ... hardware_changes [ date=value, server=value, message=value

28 Implementing the Metering System

... ] } report Rdate -time -tzone { grid name { ... } } ...

For example: report R2010.10.15-10.48.01-UTC { grid grid01 { collection_interval = 0.2 server_collection_interval = 0.2 app_list_failure = 0 comp_list_failure = 0 srv_list_failure = 0 usr_list_failure = 0 local_epoch = 1287139681 local_timezone = "PDT" version = "2.9.9 hf3821 hf3820" description = "" controller_ip = "172.23.72.90" hostname = "grid01.mycompany.net" n_apps_running = 0 n_servers = 1 n_servers_enabled = 1 total_mem = 0 total_cpu = 0.00 total_bw = 0 uptime = 55078 controller_uptime = 54696 last_srv_failure_ts = 1287085018 last_failed_srv = "srv1" ha_state = "unavailable" srv_mgmt_mode = "none" avg_comps_per_app = 0 vol_msg_txt = "Volume check completed on Oct 15, 2010 at 00:19:31. Volume maintenance is required. Found 1 inaccessible volume, 8 unused volumes."

CA 3Tera® AppLogic® Best Practices 29

ssl_sha1_fingerprint = "94:B0:C9:CD:44:7D:CC:7B:16:12:97:42:DB:97:A7:A6:30:BB:57:88" n_dashboard_msgs = 5 n_dashboard_alerts = 3 } server srv1 { state = "up" enabled = 1 ha_role = "primary" uid = "55d29082fed64cefb2ce0cdb8329834c" current_time = 1287139685 uptime = 55081 boot_id = "20dbcfcd-2ebb-4bce-95e5- bed056f55025" power_control_enabled = 0 ip1 = 192.168.16.1 ip2 = 172.23.72.77 network backbone { ha_mode = none nic eth1 : switch="00:1c:b0:e3:78:80:0001", state="active-up", mac="00:1A:4B:D5:30:7F" } network external { ha_mode = none nic eth0 : switch="00:1e:49:d9:e4:00:0066", state="active-up", mac="00:1A:4B:D5:30:7E" } switches [ id = "00:1c:b0:e3:78:80:0001", name = "Switch", manufacturer = "", model = "cisco WS-C2960G-48TC-L", detection_method = "cdp dtp loop" id = "00:1e:49:d9:e4:00:0066", name = "10-41-8- 7.layeredtech.com", manufacturer = "", model = "Cisco IOS Software; C3560 Software (C3560-IPSERVICESK9-M); Version 12.2(40)SE; RELEASE SOFTWARE (fc3) Copyright (c) 1986-2007 by Cisco Systems; Inc.", detection_method = "dtp lldp_m loop" ] bios_vendor = "HP" bios_version = "O08 " bios_date = "03/13/2007" motherboard_manufacturer = "Wistron Corporation"

30 Implementing the Metering System

motherboard_model = "M95ILA" motherboard_version = "NA" hvm_support = 1 cpu_phy_total = 2 cpu_total = 8 cpu_type = "Intel(R) Xeon(R) CPU E5320 @ 1.86GHz " cpu_freq = 1861 cpu_bogomips = 3725 cpu_load = 0.56 cpu_reserved = 0.10 cpu_free = 7.90 cpu_alloc = 0.00 mem_total = 34357641216 mem_reserved = 1818230784 mem_free = 32539410432 mem_alloc = 0 mem_service = 0 bw_total = 2000000000 bw_reserved = 0 bw_free = 2000000000 bw_alloc = 0 n_disks = 1 disk_total = 1743697801216 disk_reserved = 10737418240 disk_free = 1459015247995 disk_check_supported = 1 disk_check_enabled = 0 } }

The typical response to errors is to fail the pending request/operation. If the error is encountered while executing a sequence of steps, BMC, BMS, and MGT will cleanup properly prior to failing the request. In other words, any memory that was allocated will be freed, any entity that was started will be stopped, any entity that was created will be destroyed, and so on.

The BMC outputs all info, error, and warning messages to the controller system log. If the BMC fails to transfer metering data due to inability to contact the Metering Server or the Metering Gateway or for some other reason, it logs a message in the system log and will attempt to transfer the data when it is invoked to report the metering data again. It also logs a message to the grid dashboard. This message is removed once the metering data is successfully transferred.

The BMS outputs all info, error, and warning messages to the system log of the metering server appliance.

CA 3Tera® AppLogic® Best Practices 31

The MGT outputs all info, error, and warning messages to the system log of the metering gateway appliance. In addition, MGT logs error messages to the dashboard of the controller for the grid on which it is running. If MGT fails to transfer metering data because it cannot contact the Metering Server or for some other reason, it logs a message to the system log as well as the grid dashboard of the grid controller on which it is running.

All customer and grid information is stored on a user volume in the BMS in a hierarchically organized file store. The file store is located at /home/account in BMS and has the following structure: home/ account/ .ssh/ Authorized_keys Desc grid_name-signature/ year.month.day.zip

The descriptor under each account is a UDL file containing the following information for the account: ■ Account name ■ Account ID ■ Account public key ■ Company name ■ Billing address ■ Billing contact person ■ Technical contact person ■ Client key 1..4 ■ Tag

The zip file contains a collection of metering records for the specified date and time. For example, 2010.10.10.zip contains the metering data for October 10, 2010.

BMS provides an input through which administrators (either on-site client administrators or CA 3Tera AppLogic BMS operators ) can manage the customer accounts and their grids, as well as obtain metering information. The private input occurs over SSH and provides a shell similar to the current AppLogic shell.

32 Implementing the Metering System

The following operations are supported through the input: ■ account management- includes creating, destroying, enabling, disabling, retrieving information for, changing and updating accounts, as well as listing obtaining a list of accounts. ■ message management – includes posting dashboard messages to the grids, displaying and recalling posted messages ■ grid management – includes listing all grids for a customer account, destroying a grid under a customer account and displaying grid change, uptime or downtime reports ■ data receive – receive metering data from metering client ■ message get – retrieve pending dashboard messages (called by Metering Client) ■ metering data management – includes dumping all metering data – as well as displaying specific metering data, such as license, exception or appliance metering - for a grid, cleaning up metering data files (destroying) and archiving processed metering data.

See Appendix A for more details on these options.

The MGT provides an input through which administrators can manage the SSL certificate required for MGT to communicate with the Metering Server (BMS). The private input occurs over SSH using a simple text menu with the following menu options: ■ A. Create new SSL certificate ■ B. Display/Send current certificate ■ C. Remove current SSL Certificate ■ D. Test notifications ■ Q. Exit

CA 3Tera® AppLogic® Best Practices 33

This appendix identifies the commands available to grid maintainers for accessing and managing their metering data on the BMS. For both inputs, the format of the Command Line is: ssh account@BMS_location entity command [options]*

Where: ■ BMS_location - identifies the public location at which the BMS can be accessed. For the CA 3Tera Metering server that is “grm.3tera.net”. ■ entity – specifies the entity type: account, grid, meter, or data ■ command – specifies the command that is to be executed

■ options – specifies additional command-specific arguments

The following entities and commands are supported for all end users:

Entity & Command Description account info Get customer account information account set Update customer account information account change Display account change report message post Post dashboard message to grid(s) message recall Recall, i.e., delete, posted dashboard message message status Display pending dashboard messages for a grid grid list List grids for the specified account grid uptime Display grid uptime report grid downtime Display grid downtime details meter dump Display metering data meter license Display license metering data meter exception Display exception metering data meter appliance Display appliance metering data

Following is the list of additional entities and commands that are to administer the BMS:

Entity & Command Description account create Create customer account account destroy Destroy customer account account check Check customer account account list List customer accounts Certificate sign Sign SSL certificate

35 Implementing the Metering System

Entity & Command Description grid destroy Destroy grid for specified account meter archive Archiving metering data meter clean Clear metering information, i.e., delete data receive Receive metering data message get Retrieve dashboard messages

For example the following command would be used to generate a report identifying the exception metering data for the test account. ssh [email protected] meter exception test

Following are further details on these commands and their supported options. account create

The account create command is used to create a customer account.

Syntax account create name [company=company_name] [addr=billing_address] [bill=billing_contact] [tech=tech_contact] [tag=tag] [clientkey1=SSH_key] [clientkey2=SSH_key2] [clientkey3=SSH_key3] [clientkey4=SSH_key4] where:

■ name - account name ■ company_name - customer company name ■ billing_address - customer billing address

■ billing_contact - customer billing contact information (name + phone# or e-mail) ■ tech_contact - customer technical contact information (name + phone# or e-mail) ■ tag - account tag

■ ssh_key1….ssh_key4 - customer client access keys

Notes: 3tbms creates a Linux user with the user name being the account name. 3tbms also initializes the descriptor for the account under the user home directory.

3tbms also generates a SSH key-pair, stores the public key within the account descriptor and outputs the private key to standard output.

36 Implementing the Metering System

account destroy

The account destroy command is used to destroy an existing customer account.

Syntax

account destroy name [--force] where: name - account name

Notes: If --force is not specified, the user is asked if they really want to destroy the account.

Any existing grids for the account are destroyed before the account is destroyed. 3tbms removes the Linux user thus deleting the user’s home directory. account reset

The account reset command is used to reset the customer account.

Syntax account reset name where: name - account name account enable

The account enable command is used to enable a customer account that has previously been disabled.

Syntax account enable name where: name - account name

CA 3Tera® AppLogic® Best Practices 37

account disable

The account disable command is used to disable the customer account.

Syntax account disable name where: name - account name account check

The account check command is used to check the validity of a customer account – in other words, whether the account exists and if it has been disabled.

Syntax account check name where: name - account name

Notes: This command will fail if the specified account is disabled account list

The account list command is used to list customer accounts.

Syntax account list [--batch] [--verbose] [--all] where:

--verbose - Include grid information in the list

--all - Include disabled accounts also

Notes: The output of this command is a list of customer accounts.

If --batch is not specified, the output of this command is a table with the following columns: ■ Account ■ ID ■ Enabled (displayed only if --all is specified)

38 Implementing the Metering System

■ Tag

If --batch is specified, the output of this command is the following: account Customer #1: id=id, enabled=0/1, tag=tag account Customer #2: id=id, enabled=0/1, tag=tag ... account Customer N : id=id, enabled=0/1, tag=tag

If -–verbose is specified, the output of this command is a table with the following headings: ■ Account ■ ID ■ Enabled (displayed only if --all is specified) ■ Tag ■ Grid ■ Version ■ # servers ■ # apps ■ Mem (MB) ■ Last Report

If --verbose and --batch are provided, the output of this command is the following: account acct1 { id = id enabled = value tag = tag grid grid_name: version=version, n_servers=value, n_apps=value, mem_alloc=value, ssl_sha_fingerprint=value, ha_state=value, n_messages=value, n_alerts=value, last_report=yyyy-mm-dd … } … account acctN { id = id enabled = value tag = tag grid grid_name: version=version, n_servers=value, n_apps=value, mem_alloc=value, ssl_sha_fingerprint=value, ha_state=value, n_messages=value, n_alerts=value, last_report=yyyy-mm-dd …

CA 3Tera® AppLogic® Best Practices 39

} account info

The account info command is used to retrieve information about the customer’s account.

Syntax account info name [--batch] where: name - account name

For example: account info test

Notes: If --batch is not specified, the output of this command is the following:

Name: account_name ID: account_id enabled: Y/N Tag: account_tag Company: company_name Address: customer_address Billing Contact: billing_contact_info Technical Contact: tech_contact_info Number of Grids: number_of_grids_under_account Public Key: public_SSH_key Client Key1: client_SSH_key Client Key2: client_SSH_key Client Key3: client_SSH_key Client Key4: client_SSH_key

If --batch is specified, the output of this command is the following: account "account_name" { id = account_id enabled = 0/1 tag = “account_tag” company = “company_name” address = "customer_address" billing = "billing_contact_info" technical = "tech_contact_info" n_grids = number_of_grids_under_account pub_key = “public_SSH_key” client_key1 = “client_SSH_key”

40 Implementing the Metering System

client_key2 = “client_SSH_key” client_key3 = “client_SSH_key” client_key4 = “client_SSH_key” } account set

The account set command is used to update customer account information.

Syntax account set name [company=company_name] [addr=billing_address] [bill=billing_contact] [tech=tech_contact] [tag=tag] [clientkey1=SSH_key1] [clientkey2=SSH_key2] [clientkey3=SSH_key3] [clientkey4=SSH_key4]

Where: ■ name - account name ■ company_name - customer company name

■ billing_address - customer billing address

■ billing_contact - customer billing contact information (name + phone# or e-mail)

■ tech_contact - customer technical contact information (name + phone# or e-mail) ■ tag - account tag ■ SSH_key1….SSH_key4 - customer client access keys used for accessing account data

Notes: At least one of the account information fields must be specified. 3tbms updates the descriptor in /home/account_name with the account information.

For example: account set test client_key1="ssh-rsa AAAAB3NzaC1yc2EAAAAB..." account change

The account change command is used to list all grids under a customer account.

Syntax account change (account | --all) [--csv] (start=start_date end=end_date) | date=date

CA 3Tera® AppLogic® Best Practices 41

where: ■ account - Generate report for specific account ■ --all - Generate report for all accounts

■ --csv - Generate report as comma-separated list ■ Start_date - start date (YYYY-MM-DD) ■ End_date - end date (YYYY-MM-DD)

■ date - Start and end date (YYYY-MM-DD)

Notes: The output of this command is a list of accounts that have a change in the # of grids and/or # of servers

For example: account change test start=2010-09-01 end=2010-09-30

If --batch is not specified, the output of this command is a table with the following columns: ■ Account ■ Start # Grids ■ End # Grids ■ Start # Servers ■ End # Servers

If --csv is specified, the output of this command is the following:

Account,Start # Grids,End # Grids,Start # Servers,End # Servers

Acct1,sgrid,egrid,ssrv,esrv

… certificate sign

The certificate sing command is used to sign the SSL certificate enabling communication.

Syntax certificate sign

Notes: The certificate request is read from STDIN

42 Implementing the Metering System

message post

The message post command is used to post dashboard messages to the grid(s).

Syntax message post account[:name] | --all id=id [severity=severity] text=text where: ■ account - account name

■ name - grid name ■ id - Message ID – must be in the form: 200_grm_text

■ severity- Message severity – may be info or alert. Default is info

■ text - Message text. If set to ‘-‘, text is read from STDIN message recall

The message recall command is use to recall dashboard message.

Syntax message recall account[:name] | --all id=id where: account - account name name - grid name id - Message ID – must be in the form: 200_grm_text

For example: message recall test id=200_grm_test message status

The message status command is used to display the pending dashboard messages for the specified grid.

Syntax message status account[:name] | --batch where:

CA 3Tera® AppLogic® Best Practices 43

account - account name name - grid name

--batch – Display output in UDL format

For example message status test:grid1-S123465 grid destroy

The grid destroy command is used to destroy an existing grid.

Syntax grid destroy account:name [--force] where: account - account name name - grid name

Notes: If --force is not specified, the user will be asked if they really want to destroy the grid. 3tbms deletes the directory at /home/account/name in the file store. grid list

The grid list command is used to list all grids under a specified customer account.

Syntax grid list account [--batch | --csv] [(start=start_date [end=end_date]) | date=date] where: account - account name start_date - List grids with metering data on or after start date (YYYY-MM-DD) end_date - List grids with metering data on or before end date (YYYY-MM-DD) date - List grids with metering data on date (YYYY-MM-DD)

For example: grid list test

44 Implementing the Metering System

Notes: The output of this command is a list of grids belonging to a customer account.

If --batch is not specified, the output of this command is the following:

Name Version # Servers Tag ------Grid #1 value value value Grid #2 value value value ... Grid N value value value

If --csv is specified, the output of this command is the following:

Name, Version, # Servers, Tag, IP Address, Hostname, HA state, # Messages, # Alerts Grid #1, value, value, value, value, value, value, value, value Grid #2, value, value, value, value, value, value, value, value ... Grid N, value, value, value, value, value

If --batch is specified, the output of this command is the following: grid Grid #1: version = “value”, n_servers = value, tag = value, ip = value, hostname = value, ssl_sha_fingerprint = “value”, ha_state = “value”, n_messages = value, n_alerts = value grid Grid #2: version = “value”, n_servers = value, tag = value, ip = value, hostname = value, ssl_sha_fingerprint = “value”, ha_state = “value”, n_messages = value, n_alerts = value ... grid Grid N : version = “value”, n_servers = value, tag = value, ip = value, hostname = value, ssl_sha_fingerprint = “value”, ha_state = “value”, n_messages = value, n_alerts = value grid uptime

The grid uptime command is used to display the grid uptime report.

Syntax grid uptime (account[:grid_name] | --all) [--csv] [--verbose] (start=start_date end=end_date) | date=date where: ■ account - account name

■ grid_name - grid name ■ --all – display report for all accounts and all grids ■ --csv – display output as comma-separated list

CA 3Tera® AppLogic® Best Practices 45

■ --verbose – display full grid name in report

■ start_date - beginning date of period (YYYY-MM-DD)

■ end_date - end date of period (YYYY-MM-DD) ■ date - beginning and ending date of period (YYYY-MM-DD), i.e., run report for a single day

For example: grid uptime test start=2010-09-01 end=2010-09-30

Notes: The output of this command is a table with the following columns: ■ Account ■ Grid ■ Version ■ Uptime (%) ■ Start Date ■ End Date

If -–csv is specified, the output of this command is the following:

Account,Grid,Version,Uptime (%),Start Date,End Date account, grid_name, version, uptime, start, end … grid downtime

The grid downtime command is used to display the grid downtime report.

Syntax grid downtime (account[:grid_name] | --all) [--verbose] (start=start_date end=end_date) | date=date where: ■ account - account name ■ grid_name - grid name

■ --all – display report for all accounts and all grids ■ --csv – display output as comma-separated list ■ --verbose – display full grid name in report

■ start_date - beginning date of period (YYYY-MM-DD) ■ end_date - end date of period (YYYY-MM-DD)

46 Implementing the Metering System

■ date - beginning and ending date of period (YYYY-MM-DD), i.e., run report for a single day

For example: grid downtime test start=2010-09-01 end=2010-09-30

Notes: The output of this command is a table with the following columns: ■ Account ■ Grid ■ Downtime (Hrs) ■ Previous Report ■ Current Report ■ Previous Version ■ Current Version ■ Description grid change

The grid change command is used to display the grid change report.

Syntax grid change (account[:grid_name] | --all) [--csv] (start=start_date end=end_date) | date=date where: ■ account - account name ■ grid_name - grid name

■ --all – display report for all accounts and all grids ■ --csv – display output as comma-separated list ■ start_date - beginning date of period (YYYY-MM-DD)

■ end_date - end date of period (YYYY-MM-DD) ■ date - beginning and ending date of period (YYYY-MM-DD), i.e., run report for a single day

Notes: If the grid appeared during the period, the Start # of servers is ‘-‘. If the grid disappeared during the period, the End # of servers is ‘-‘.

The output of this command is a list of grids where the number of servers has changed between the specified start and end dates.

CA 3Tera® AppLogic® Best Practices 47

Account Grid Start # Servers End # Servers Tag ------Acct1 Grid1 value value value Grid2 value value value ... GridN value value value

If -–csv is specified, the output of this command is the following:

Account,Grid,Start # Servers,End # Servers, Tag Acct1,Grid1,value,value,value Acct1,Grid2,value,value,value … Acct1,GridN,value,value,value meter dump

The meter dump command is used to display metering data.

Syntax meter dump (account[:grid_name] | --all) [(start=start_date end=end_date) | date=date] [--srv_rsc | --srv_count | -- composite] [--csv | --detail] [--exclude_sys] [--verbose] where: ■ account specified the account name ■ grid_name - identifies the grid name ■ --csv – displays summary metering information as a comma-separated list

■ --srv_rsc – displays server resource metering information ■ --srv_count – displays server count metering information

■ --composite – displays composite report. Includes application resource usage, server resource usage, resource usage in percent, # of servers, and weighted server count. ■ start_date - beginning date of period (YYYY-MM-DD) ■ end_date - end date of period (YYYY-MM-DD)

■ date - beginning and ending date of period (YYYY-MM-DD), i.e., run report for a single day

■ --detail – displays detail metering information as a comma-separated list

■ --exclude_sys – excludes AppLogic system applications from application resource calculation ■ --verbose – displays full grid name

Notes: The start and end dates are inclusive.

48 Implementing the Metering System

For example: meter dump test

Displays all application resource metering information for account test. meter dump test --srv_rsc

Displays all server resource metering information for account test. meter dump test --srv_count

Displays all server count metering information for account test. meter dump test --composite

Displays composite metering information for account test.

If --all is specified without any account name, metering data for all grids on all accounts is displayed. If the grid name is specified, metering data for that particular grid is displayed.

This command supports the following modes: ■ Application Resource Reporting: ■ Server Resource reporting ■ Server Count reporting ■ Composite reporting

Application resource reporting: ■ Summary Output Which includes the following information\metrics:

– Account

– Grid

– # of CPU hours

– Total Memory (GBHrs)

– Total Bandwidth (MbHrs)

– Start date (start date of actual metering data containing server info)

– End date (end date of actual metering data containing server info) ■ The Summary CSV Output is as follows: Account, Grid, CPUh, Memory (GBHrs), Bandwidth (MbHrs), Storage (GBHrs), Start Date, End Date account, grid_name, cpu, mem, bw, storage, start, end ...

CA 3Tera® AppLogic® Best Practices 49

■ Detail Output Account, Grid, Application, User1, User2, State, # Components, CPU, Memory,(MB), Bandwidth(Mbps), Duration (Hrs), Start Date, Start Time, End Date, End Time, CPU (Hrs), Memory (GBhrs), Bandwidth(MbHrs) account, grid_name, app_name, ref1, ref2, state, n_comps, cpu, mem, bw, duration, start_date, start_time, end_date, end_time, calculated_CPU_hrs, calculated_GB_hrs, calculated_Gbps_hrs ...

Server resource reporting: ■ Summary Output Which includes the following information\metrics:

– Account

– Grid

– # of CPU hours

– Total Memory (GBHrs)

– Total Bandwidth (MbHrs)

– Total Storage (GBHrs)

– Start date (start date of actual metering data containing server info)

– End date (end date of actual metering data containing server info) ■ Summary CSV Output Account, Grid, CPUHrs, Memory (GBHrs), Bandwidth (MbHrs), Storage (GBHrs), Start Date, End Date account, grid_name, cpu, mem, bw, storage, start_date, end_date …

■ Detail Output Account, Grid, Server, Total CPUs, Total. Memory(GB), Total Bandwidth (Mbps), Total Storage (GB), Duration (# Hrs), Start Date, Start Time, End Date, End Time, CPUHrs, Memory (GBhrs), Bandwidth (MbHrs), Storage (GBHrs)

account, grid_name, server, number_CPUs, total_mem(GB),total_bw(Mb), total_storage(GB), duration, start_date, start_time, end_date, end_time, calculated_CPU_hrs, calculated_GB_hrs, calculated_Mb_hrs, calculated_GB_hrs ...

Server count reporting: ■ Summary Output Which includes the following information\metrics:

50 Implementing the Metering System

– Account

– Start Date

– End Date

– # Servers

– # days ■ Summary CSV Output Account, Start Date, End Date, # Servers, # Days account, start_date, end_date, number_of_servers, number_of_days …

■ Detail Output Account, Grid, # Servers, Duration (# days), Start Date, End Date

account, grid_name, number_of_servers, duration, start_date, end_date ...

Composite reporting: ■ Summary Output Which includes the following information\metrics:

– Account

– Grid

– Version

– HA State

– App CPUh

– App GBh

– App Mbpsh

– Srv CPUh

– Srv GBh

– Srv Mbpsh

– Srv Disk (GBh)

– Rsc CPU (%)

– Rsc Mem (%)

– Rsc Bandwidth (%)

– Rsc Disk (%)

– # Servers

– Weighted # Servers

CA 3Tera® AppLogic® Best Practices 51

– Weighted # Sockets

– Start date (start date of actual metering data containing server info)

– End date (end date of actual metering data containing server info) ■ Summary CSV Output Account, Grid, Version, HA State, App CPUh, App GBHrs, App MbHrs, Srv CPUh, Srv GBh, Srv MbHrs, Srv Disk(GBh), Rsc CPU (%), Rsc Mem (%), Rsc Bandwidth (%), Rsc Disk (%), # Servers, Weighted # Servers, Weighted # Sockets, Start Date, End Date account, grid_name, version, ha_state, acpu, amem, abw, scup, smem,sbw,sdsk,rcpu,rmem,rw,dsk, n_srv, w_srv, w_sockets, start, end ...

meter license

The meter license command displays license metering data.

Syntax meter license ([account[:grid_name]] | --all) [(start=start_date end=end_date) | date=date] [--srv_license] [filter=filter] [-- csv] [--verbose] where: ■ account - account name ■ grid_name - grid name

■ start_date - beginning date of period (YYYY-MM-DD)

■ end_date - end date of period (YYYY-MM-DD) ■ date - beginning and ending date of period (YYYY-MM-DD), i.e., run report for a single day

■ --srv_license – display per-server license metering information ■ filter – comma-separated list of name=value filter criteria. If no filter is specified, any appliance is considered in the calculations. The filter may contain one or more of the following: os_name=val (filter based upon OS name, i.e., Windows), os_flavor=val (filter based upon OS flavor, i.e., CentOS, Windows 2003 Enterprise Server, etc), os_version=val (filter based upon PV driver information, i.e., 5.1), pv_info=val (filter based upon PV driver information, i.e., turbogate), tag=val (filter based upon tag value) ■ --csv – display metering information as a comma-separated list ■ --verbose – display full grid name (with signature)

52 Implementing the Metering System

Notes: The start and end dates are inclusive. If --all is specified without any account name, metering data for all grids on all accounts is displayed. If the grid name is specified, metering data for that particular grid is displayed.

For example: meter license test

Displays all license summary metering information for account test. meter license test --srv_license

Displays all per server license metering information for account test.

The Summary Output of this command includes the following information\metrics: ■ Account ■ Grid ■ OS Info (flavor, version) or PV Info ■ # Grids ■ #Servers ■ Sockets ■ VMs

If –-csv is specified, the output is a comma-separated list with the above mentioned headings.

The Server License Output contains the following information\metrics: ■ Account ■ Grid ■ Server ■ # Sockets ■ #VMs meter exception

The meter exception command displays exception metering data.

Syntax meter exception ([account[:grid_name]] | --all) [(start=start_date end=end_date) | date=date] [--maint] [--csv] [--verbose]

CA 3Tera® AppLogic® Best Practices 53

where: ■ account - account name ■ grid_name - grid name

■ start_date - beginning date of period (YYYY-MM-DD) ■ end_date - end date of period (YYYY-MM-DD) ■ date - beginning and ending date of period (YYYY-MM-DD), i.e., run report for a single day

■ --maint – display grid maintenance information ■ --csv – display metering information as a comma-separated list ■ --verbose – display full grid name (with signature)

Notes: The start and end dates are inclusive. If --all is specified without any account name, metering data for all grids on all accounts is displayed. If the grid name is specified, metering data for that particular grid is displayed.

For example: meter exception test

Displays all exception metering information for account test. The Summary Output report includes the following information\metrics: ■ Account ■ Grid ■ # Suspicious ■ Application ■ Component ■ Class ■ OS Guess ■ OS Type

If -–csv is specified, the output is a comma-separated list with the above mentioned headings.

The Maintenance Output report includes the following information\metrics: ■ Account ■ Grid ■ HA State ■ HA Message ■ Volume Maintenance Message

54 Implementing the Metering System

If --csv is specified, the output is a comma separated list with the above headings as well as: ■ HA Message Text ■ Volume Message Text meter appliance

The meter appliance command displays exception metering data for the appliance.

Syntax meter appliance ([account[:grid_name]] | --all) [(start=start_date end=end_date) | date=date] [filter=filter] [-- csv] [--verbose] where: ■ account - account name

■ grid_name - grid name ■ start_date - beginning date of period (YYYY-MM-DD)

■ end_date - end date of period (YYYY-MM-DD) ■ date - beginning and ending date of period (YYYY-MM-DD). Used to run a report for a single day ■ filter – comma-separated list of name=value filter criteria. If no filter is specified, any appliance is considered in the calculations. The filter may contain one or more of the following: os_name=val (filter based upon OS name, i.e., Windows), os_flavor=val (filter based upon OS flavor, i.e., CentOS, Windows 2003 Enterprise Server, etc), os_version=val (filter based upon PV driver information, i.e., 5.1), pv_info=val (filter based upon PV driver information, i.e., turbogate), tag=val (filter based upon tag value) ■ --csv – display metering information as a comma-separated list

■ --verbose – display full grid name (with signature)

Notes: The start and end dates are inclusive. If --all is specified without any account name, metering data for all grids on all accounts is displayed. If the grid name is specified, metering data for that particular grid is displayed.

For example: meter appliance test

Display all appliance information for account test

CA 3Tera® AppLogic® Best Practices 55

The Summary Output report includes the following information\metrics: ■ Account ■ Grid ■ App ■ Class ■ OS ■ CPU ■ Mem ■ Time ■ Tag

If –-csv is specified, the output is a comma-separated list with the following headings: ■ Account ■ Grid ■ Application ■ Name ■ Class ■ Locked ■ Start Time ■ Running ■ CPU ■ Memory ■ Bandwidth ■ OS Type ■ OS Flavor ■ OS Version ■ PV Info ■ Tag meter archive

The meter archive command archives metering data.

Syntax meter archive (account[:grid_name] | --all) file=file_name

56 Implementing the Metering System

where:

■ account - account name ■ grid_name - grid name

■ file_name - name of file (without extension) to contain the archived data

Notes: This command collects, tars, and archives the metering data stored in the secure location. meter clean

The meter clean command clears metering data from secure locations.

Syntax meter clean (account[:grid_name] | --all) (start=start_date end=end_date) where: ■ account - account name ■ grid_name - grid name ■ start_date - begin date of the metering data to be cleaned (YYYY-MM-DD)

■ end_date - end date of the metering data to be cleaned (YYYY-MM-DD) data receive

The data receive command receives the metering data file from standard input.

Syntax data receive account grid_name signature date --zipped where: ■ account - account name ■ grid_name - grid name

■ signature - grid signature ■ date - date for which the metering data applies. The format is year.month.day

■ --zipped – metering data has been zipped prior to transport. If not specified, it is assumed that the metering data is ASCII text Notes: This command reads the metering data from standard input. If the data was not zipped, the data is zipped prior to storing on the data volume.

CA 3Tera® AppLogic® Best Practices 57

message get

The message get command displays and deletes pending dashboard messages for the specified grid.

Syntax message get account grid_name signature where: ■ account - account name ■ grid_name - grid name

■ signature - grid signature Notes: This command writes the contents of the dashboard.txt file to STDOUT and then removes the dashboard.txt file

58 Implementing the Metering System