Storage Portal Architecture and Design
Storage Portal Architecture and Design
Draft
Authors: Team IBM
Customer: ETH
Status: Draft
Version: V0.5
Document:
Status:
S: ubject:
106758705
Draft
Storage Portal Architecture and Design
Date: 23.11.2011
Version: V0.5
Page 1 of 16
Storage Portal Architecture and Design
Document History
Document Location
This is a snapshot of an on-line document. Paper copies are valid only on the day they are printed. Refer
to the author if you are in any doubt about the currency of this document.
Revision History
Revision
Number
V0.1
V0.2
V0.3
V0.4
V0.5
Revision
Date
11.11.11
17.11.11
22.11.11
23.11.11
01.12.11
Summary of Changes
Editor
Initial Creation
Add Design decisions for phase 1
Add TPC information
Incorporate changes from Jörn Siglen
Incorporate changes from meeting with ETH from 29.11.11
G. Rieker
J Thomann
B. Steiner
J. Thomann
J. Thomann
Distribution
This document has been distributed to
Date
23.11.2011
Document Version
V0.4
Name
Tilo Steiger
Company
ETH
01.12.2011
V0.5
Tilo Steiger
ETH
Document:
Status:
S: ubject:
106758705
Draft
Storage Portal Architecture and Design
Date: 23.11.2011
Version: V0.5
Page 2 of 16
Storage Portal Architecture and Design
Contents
1.
Architecture Overview............................................................................................. 5
1.1
Phase 1: Metering & Accounting ..................................................................................................... 5
1.2
Phase 2: Storage Cloud Management Portal ................................................................................. 6
2.
Functional Requirements ........................................................................................ 7
2.1
Phase 1: Metering & Accounting ..................................................................................................... 7
2.2
Phase 2: Storage Cloud Management Portal ................................................................................. 7
2.2.1
Base Functions ........................................................................................................................ 7
2.2.2
Individual Functions and Use Cases ....................................................................................... 7
3.
Non-Functional Requirements ................................................................................ 9
3.1
Phase 1: Metering & Accounting ..................................................................................................... 9
3.2
Phase 2: Storage Cloud Management Portal ................................................................................. 9
4.
Solution Design .................................................................................................... 10
4.1
Phase 1: Metering & Accounting (TUAM) ..................................................................................... 10
4.1.1
Roles ...................................................................................................................................... 10
4.1.2
Reports .................................................................................................................................. 10
4.1.3
Metering ................................................................................................................................. 11
4.1.4
Account structure ................................................................................................................... 11
4.1.5
Account association ............................................................................................................... 11
4.1.6
Storage Tier ........................................................................................................................... 12
4.1.7
Billing Rates ........................................................................................................................... 12
4.1.8
Required Metering Data ......................................................................................................... 13
4.2
Phase 1: Performance Measurement (TPC) ................................................................................ 13
4.3
Phase 1: Physical Design ............................................................................................................. 13
4.3.1
4.4
5.
Hardware ............................................................................................................................... 13
Phase 2: Storage Cloud Management Portal ............................................................................... 15
Glossary ............................................................................................................... 16
Document:
Status:
S: ubject:
106758705
Draft
Storage Portal Architecture and Design
Date: 23.11.2011
Version: V0.5
Page 3 of 16
Storage Portal Architecture and Design
Table of Figures
Figure 1: Main components and planned schedule for the 2 phases ...........................................................5
Index of Tables
Table 1: Roles and Access Rights ............................................................................................................. 10
Table 2: Account structure of ETH ............................................................................................................. 11
Table 3: TPC ordered hardware ................................................................................................................. 14
Table 4: TUAM ordered hardware .............................................................................................................. 14
Document:
Status:
S: ubject:
106758705
Draft
Storage Portal Architecture and Design
Date: 23.11.2011
Version: V0.5
Page 4 of 16
Storage Portal Architecture and Design
1. Architecture Overview
ETH decided to modernise its existing storage infrastructure to satisfy the increasing demand of their
internal customers regarding amount of available capacity, flexibility and cost transparency in the storage
area. With the renewal of its storage landscape ETH also pursues the goal to offer a Storage Portal to
their customers, where they can choose between different Service offerings and request them in a self
service manner.
This document provides the design specification for the Storage Portal and the underlying components.
The implementation of these components is divided in 2 main phases.

Metering and Accounting

Storage Cloud Management Portal
The main components for these 2 phases are displayed in the following graphic:
Phase 1: Metering & Accounting
Phase 2: Final Solution
ISDM (Metering &
Accounting)
ISDM (Portal)
TSAM
TSAM
User
Metering &
Accounting
TPM
SVC/V7000
Managment
Performance
Data, etc.
TUAM
ITM
Metering Data
Integration CLI
User
Storage
Portal
TPM
TUAM
ITM
Storage
Administrator
SMAC API
SoNAS & SVC/V7000
Managment
Performance Data, etc.
TPC
Storage
Administrator
TPC
SoNAS
SVC
SVC
SoNAS
V7000
V7000
V7000
Phase 1
Start Setup
10/2011
V7000
Phase 2
Installation ETH
12/2011
Solution Design
Q1/2012
Beta Program
04/2012
Portal GA
06/2012
Figure 1: Main components and planned schedule for the 2 phases
1.1 Phase 1: Metering & Accounting
The implementation of the Storage Portal will start with the design, implementation and configuration of 2
independent software products from the IBM software portfolio, Tivoli Usage and Accounting Manager
(TUAM) and Total Storage Productivity Center for Disk (TPC for Disk). TPC for Disk will be used as a
performance measurement tool to provide ETH performance information about their installed storage
Document:
Status:
S: ubject:
106758705
Draft
Storage Portal Architecture and Design
Date: 23.11.2011
Version: V0.5
Page 5 of 16
Storage Portal Architecture and Design
hardware. The TPC software will be connected to the SVC where it gets its data from. This information
will help ETH to better understand the usage of the current environment and help them to tune the
different storage resources to increase performance and accessibility.
Tivoli Usage and Accounting Manager collects metering data from 2 different sources. In the first phase it
collects metering data via command line from the SONAS system to get information about the file
storage. A second command line interface collects metering data via SVC about block storage.
Based on the collected data reports are generated and provided to the different ETH Departments and
ETH Institutes. The reports include the amount of used storage for a defined timeframe and in a second
step the billing data for the used or reserved resources.
1.2 Phase 2: Storage Cloud Management Portal
The planned start for Phase 2 is Q1/2012.
Document:
Status:
S: ubject:
106758705
Draft
Storage Portal Architecture and Design
Date: 23.11.2011
Version: V0.5
Page 6 of 16
Storage Portal Architecture and Design
2. Functional Requirements
2.1 Phase 1: Metering & Accounting
The following list is a collection of the functional requirements, which are related to Metering and
Accounting:

Regular collection of metering data from SONAS and SVC (Quotas/allocated storage)

Periodically generating reports for different timeframes

Generating reports for each scientific working group

Automatic delivery of the generated reports via mail

Allow customers to generate predefined ad-hoc reports

Access rights are based on a role model

User authentication is based on the ETH Directory Service

Rate codes can be included and used to regular generate bills

Different storage tiers can be reflected in the system

Billing is done based on the different storage tiers
2.2 Phase 2: Storage Cloud Management Portal
2.2.1 Base Functions
End User Portal
Service Administrator Portal
Service Catalog
Service Request Management
Metering & Accounting for entries in the Service Catalog
Automatic Service Instance Provisioning, Management/Configuration, Deprovisioning
Integration with Corporate Directory (AD) for authentication and access – one single repository for all
actors (consumers, administrators)
2.2.2 Individual Functions and Use Cases
Storage Service Consumer – via Portal
Browse Storage Services

View restricted depending on role
Request Storage Services

View restricted depending on role
Document:
Status:
S: ubject:
106758705
Draft
Storage Portal Architecture and Design
Date: 23.11.2011
Version: V0.5
Page 7 of 16
Storage Portal Architecture and Design

Optional assigning of specific permissions (read, write to other organizational units or individuals)
Request Storage Services on behalf of individual or group

assigning of specific permissions (read, write to other organizational units or individuals)
Storage Service Administrator – via Portal
View Storage Services
Create Storage Services – various types
Manage Storage Services
Service Request Process / Service Catalog
Modular service request processes – re-usable process elements (e.g. approval)
Service Portfolio: Active / inactive Services
User Management – based on Directory, via Portal or Admin Portal
Manage User Security – role based, central one-stop management
User Self-Registration
Create / Modify / Delete User – Global User (AD integration), Local User (not in AD)

User permission based on roles

User to role assignment based on AD group membership (assuming multiple roles per user
possible)
Identity Management at ETH is done with different tools. One of the main tools is “nethz”. This in-house
developed application could be an integration point to manage the role based access to the Storage
Cloud environment.
Metering, Reporting, Billing
Measure consumption of defined Resource Units – (Quotas, allocated storage)
Request / View Usage Reports

Respecting organizational model

Access depending on role and organization
Request / View Billing Reports

Respecting organizational model

Access depending on role and organization
Automatic/Scheduled report generation and distribution (email, website)
Monitor/Trend Capacity; monitor capacity and derive trends for proactive service capacity management
Document:
Status:
S: ubject:
106758705
Draft
Storage Portal Architecture and Design
Date: 23.11.2011
Version: V0.5
Page 8 of 16
Storage Portal Architecture and Design
3. Non-Functional Requirements
3.1 Phase 1: Metering & Accounting
There are no non-functional requirements defined.
3.2 Phase 2: Storage Cloud Management Portal
The following listing specifies points which could influence the design of the Portal implementation during
phase 2:

Service Catalog

Definition for Quality of Service

Response times

Legal aspects

Requirements regarding data

Maintenance and Support
Document:
Status:
S: ubject:
106758705
Draft
Storage Portal Architecture and Design
Date: 23.11.2011
Version: V0.5
Page 9 of 16
Storage Portal Architecture and Design
4. Solution Design
4.1 Phase 1: Metering & Accounting (TUAM)
4.1.1 Roles
The following table shows 3 roles with its assigned rights, which are required for the access of the
Metering and Accounting application.
Role Name
Administrator
ETH Specific Name of Group
SGA
Access Rights
Full control TUAM
Full control Reports (TCR/Cognos)
Department-Administrator
(Decentral Admin)
ISG
No access to TUAM
Read-only access to Reports
Execute Ad-hoc Reports
Assign permissions to reports for IK
Users
IK (Informatik Koordinator)
No access to TUAM
Read-only access to Reports
Table 1: Roles and Access Rights
The user assignment to the different roles is administrated using groups in the Active Directory of ETH.
4.1.2 Reports
We distinguish between 3 different reports.

Scheduled reports

Ad-hoc reports

Custom reports
Scheduled reports
Scheduled reports are based on fixed report templates and generated automatically with the following
frequency:

Monthly

Quarterly

Yearly
The reports are automatically sent via mail to the IK (Informatik Koordinator) of each Department, Institute
or Scientific Working Group.
Ad-hoc reports
Ad-hoc reports can be generated on demand by each Department Administrator. Ad-hoc reports are
based on predefined report templates. Within these report templates the start- and end-date and the
Document:
Status:
S: ubject:
106758705
Draft
Storage Portal Architecture and Design
Date: 23.11.2011
Version: V0.5
Page 10 of 16
Storage Portal Architecture and Design
Department or the Scientific Working Group are parameters, which can be freely changed by the
requestor.
Custom reports
Custom reports can only be generated by users belonging to the Administrator group. These are mainly
the group SGA and other knowledgeable users. Creating and running a report requires good know-how
about the data structure in the underlying database.
Reports for ETH
For ETH 5 reports are generated. These are:

1 scheduled report on Department level

1 scheduled report on Institute or Scientific Working Group level

1 ad-hoc report with freely adjustable parameter “Department” and parameter start/end date

1 ad-hoc report with freely adjustable parameter “Scientific Working Group” and parameter
start/end date

1 custom report in cooperation with ETH
4.1.3 Metering
The metering data is collected from 2 data sources

SONAS

SVC/V7000
The interfaces to these systems are both realized using the CLI interfaces they provide. The collection of
the metering data is a scheduled job, which runs every 24 hours. The collection is triggered by TUAM.
4.1.4 Account structure
The account structure represents ETH’s organization structure within TUAM. ETH defines 3 different
organization layers. The bottom layer is the smallest entity on which reports can be generated in TUAM.
With help of identifiers collected metering data is associated to an entity.
The following table shows the account structure for ETH:
Level
Organization Name
String Length
1
Department
8
2
Institute
16
3
Scientific Working
Group
8
4
Identifier
32
Table 2: Account structure of ETH
4.1.5 Account association
Based on the metering data collected from the 2 data sources, this data must be mapped to the ETH
organization. The mapping for each data record uses identifiers to do the correct mapping.
Document:
Status:
S: ubject:
106758705
Draft
Storage Portal Architecture and Design
Date: 23.11.2011
Version: V0.5
Page 11 of 16
Storage Portal Architecture and Design
Identifiers and order for matching are:
1. File system name
2. Fileset name
3. IK technical (means a technical user, belonging to a Department, Institute or Scientific
Working Group)
4. Hostname
There are 2 sources defined for doing the match between a metering data record and an organization
entity. The sources are:
1. Lookup table (used as an exception table e.g. for Block Storage account association)
2. ETH’s Active Directory
The lookup table is a manually administrated table, where an association between an identifier and an
organizational unit can be defined. The table resides on the TUAM server. The administration is done
using a standard text editor.
The Active Directory information is automatically extracted from ETH’s Active Directory on a scheduled
basis. Every 24 hours all the needed information is pulled out of the AD and stored locally on the TUAM
server.
The account association is based on a string comparison between the identifier and the 2 tables (lookup
table and AD). First the lookup table is checked by the automatic account association process to find a
matching string. If there is no entry, the AD information is searched to find matching data. If no adequate
match can be found, the metering data record will be reported to the TUAM administrator.
To generate as less as possible unmatched metering data records, the fileset name must contain the
name of the organization unit it belongs to.
4.1.6 Storage Tier
ETH provides different storage tiers to their customers. The storage tiers differ from each other in the
quality of Service. Therefore the different tiers must be rated separately.
TUAM gets information from SVC about the different storage groups (mdisk). To decide which storage tier
the storage group belongs to, a naming convention for the storage groups must be followed.
In SVC 2 types of storage pools are created. Static pools and “easy tiering” pools. The easy tiering pools
will do an automatic allocation of the data on different storage classes depending on its access rates. For
TUAM it is not possible to analyze individual data allocation per customer within this data pool. Therefore
this pool will be handled like other static pools.
SONAS does also know a concept like easy tiering within SVC and can have different storage pools
belonging to different storage tiers. Like for SVC the storage pool names need to follow a naming
convention, so that the pools can be allocated to the correct storage tier. The storage tier with the easy
tiering function can not be analyzed individually per customer by TUAM, so this pool will be handled like
other static pools (same as for SVC).
4.1.7 Billing Rates
ETH plans to bill their storage consumers according to the reported usage of the storage infrastructure.
The bill rates are based on the following parameters:

User Quota + Storage tier (SONAS)

Allocated LUN + Storage tier (Block)
Document:
Status:
S: ubject:
106758705
Draft
Storage Portal Architecture and Design
Date: 23.11.2011
Version: V0.5
Page 12 of 16
Storage Portal Architecture and Design
The bills will be structured in the same way as the reports. The lowest organization infrastructure for
receiving a bill is a Scientific Working Group.
The bill contains the identifier for each record, so that a further split by the Scientific Working Group itself
is possible (e.g. according to hostname or user).
4.1.8 Required Metering Data
The following data records must be collected to be able to do a usage reporting:
From ETH’s Active Directory

Hostname and the appropriate Scientific Working Group (or it can read from the lookup table (see
chapter 4.1.5))

User and the appropriate Scientific Working Group

Scientific Working Group and the appropriate Institute (or instead it can be derived from the
Scientific Working Group name)

Institute and the appropriate Department (or it can be derived from the Institute name)
From SONAS for each metering data record:

User Quota

Usage

Directory (which must contain Department name or Scientific Working Group name)

Storage Tier
From SVC for each metering data record:

SAN Volume Size

SAN Volume Name

WWPN Alias (which must contain appropriate hostname)

Storage Tier (derived from the Storage Pool Name)
4.2 Phase 1: Performance Measurement (TPC)
Design Description
4.3 Phase 1: Physical Design
4.3.1 Hardware
There are 4 physical boxes available where the software stack for phase 1 is installed on.
The specification for the 4 physical boxes is the following
TPC Server infrastructure:
Document:
Status:
S: ubject:
106758705
Draft
Storage Portal Architecture and Design
Date: 23.11.2011
Version: V0.5
Page 13 of 16
Storage Portal Architecture and Design
Quantity
Product
2
x3690 X5, Xeon, 4C E7520 95W 1.86 GHz/18MB L3, 2 x 4GB, O/Bay 2.5 in HS SAS,
SR M1015, 675W p/s Rack
2
Intel Xeon 4C Processor Model E7520 95W 1.86 GHz/18MB L3
4
4GB (1x4GB, Quad Rankx8) PC3-8500 CL7 ECC DDR3 1066MHz LP RDIMM
4
IBM 300 GB 2.5in SFF Slim-HS 10K 6Gbps SAS HDD
2
ServeRAID M1000 Series Advance Feature Key
4
QLogic 8Gb FC Single-port HBA for IBM System x
2
Intel Ethernet Quat Port Server Adapter I340-T4 for IBM System x
2
Dual Port 1Gb Ethernet Daughter Card
2
IBM 675W Redundant Power Supply
2
4 Year Onsite Repair 24x7 4 Hour Response
2
IBM UltraSlim Enhanced SATA Multi-Burner
Table 3: TPC ordered hardware
TUAM Server infrastructure:
Quantity
Product
2
x3690 X5, Xeon, 4C E7520 95W 1.86 GHz/18MB L3, 2 x 4GB, O/Bay 2.5 in HS SAS,
SR M1015, 675W p/s Rack
2
Intel Xeon 4C Processor Model E7520 95W 1.86 GHz/18MB L3
4
4GB (1x4GB, Quad Rankx8) PC3-8500 CL7 ECC DDR3 1066MHz LP RDIMM
4
IBM 300 GB 2.5in SFF Slim-HS 10K 6Gbps SAS HDD
2
ServeRAID M1000 Series Advance Feature Key
2
Intel Ethernet Quat Port Server Adapter I340-T4 for IBM System x
2
Dual Port 1Gb Ethernet Daughter Card
2
IBM 675W Redundant Power Supply
2
4 Year Onsite Repair 24x7 4 Hour Response
2
IBM UltraSlim Enhanced SATA Multi-Burner
Table 4: TUAM ordered hardware
Additional there are 2 Management Consoles (SSPC) available in locations “Zentrum” and
“Hönggerberg”. These SSPCs have TPC basic version installed and can be upgraded to any version of
TPC by adding a license key. Also they can be used for Support tasks by IBM and customer.
Installation specifics for TPC server
TPC can be installed on:

Windows 2008 (R2) or 2003 (R2) standard or enterprise version, 32 or 64bit

Linux RedHat Enterprise 5 or 6 64bit

Virtualized on VMWare 3.0, 3.1, 4.0, 4.1 with above guest OS
Document:
Status:
S: ubject:
106758705
Draft
Storage Portal Architecture and Design
Date: 23.11.2011
Version: V0.5
Page 14 of 16
Storage Portal Architecture and Design

AIX
Additionally there has to be installed DB2 as collection Database version 9.7 fp4 (at least)
On the SSPC TPC and DB2 is installed on Windows 2008 (R2)
To work with attached devices TPC may require additional agents (SMI-S) to collect information (SVC
and v7000 has agents included)
Whole list of supported configurations:
http://www01.ibm.com/support/docview.wss?rs=40&context=SSBSEX&context=SSMN28&context=SSMMUP&conte
xt=SS8JB5&context=SS8JFM&uid=swg21386446&loc=en_US&cs=utf-8&lang=en
Installation specifics for TUAM server
Both servers (see table above) are the basis for a virtual environment in which the TUAM software will be
installed.
One of the servers is the productive server; the second one is for test and development purpose. The
software can run in a virtualized environment. The virtualization can be VMWare based. The virtualization
layer and the necessary licenses are provided by ETH.
The specification for the TUAM server is as follows:
Windows Parameter
Value Production
Value Development
OS
Windows 2008 x86 or x64
Windows 2008 x86 or x64
Hard drive space
100 GB
40 GB
Memory
8 GB
4 GB
Linux Parameter
OS
Value Production
Value Development
Red Hat Enterprise Linux (RHEL) 4
and 5 for IA32
Red Hat Enterprise Linux
(RHEL) 4 and 5 for IA32
RHEL 5 and 6 for x64
(AMD64/EM64T)
RHEL 5 and 6 for x64
(AMD64/EM64T)
Hard drive space
100 GB
40 GB
Memory
8 GB
4 GB
Details can be found under the following link:
http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/topic/com.ibm.ituam.doc_7.3/install/c_supported_har
dware_and_software.html
4.4 Phase 2: Storage Cloud Management Portal
Document:
Status:
S: ubject:
106758705
Draft
Storage Portal Architecture and Design
Date: 23.11.2011
Version: V0.5
Page 15 of 16
Storage Portal Architecture and Design
5. Glossary
The following abbreviations are used in the document:
Abbreviation
Full name
TUAM
Tivoli Usage and Accounting Manager
SONAS
Scale Out Network Attached Storage
TCR/Cognos
Tivoli Common Reporting based on Cognos
TPC
Tivoli Productivity Center
Document:
Status:
S: ubject:
106758705
Draft
Storage Portal Architecture and Design
Date: 23.11.2011
Version: V0.5
Page 16 of 16