Wednesday May 22, 2013

Video : Meet Growing IT Demand for Databases with Private DBaaS

 


This video discusses the difference between traditional database deployment and database as a service. It also provides an overview of Oracle Enterprise Manager's capabilities for rapid deployment of database as a service.

Monday Feb 18, 2013

Blueprints for your Enterprise Private Cloud

Last week, Oracle introduced Cloud blueprints for enterprise private clouds and posted information of about it at Oracle Technology Network. The Cloud blueprints are used to describe a desired set of inter-related cloud resources.

Like architectural blueprints, for example, more than a century old blueprint , Waldhaus Gasterntal Plan5 , they describe what you want including how they are configured to interact with each other, but not how to build them. For instance, a blueprint doesn’t describe the order in which to create the components; rather, the blueprint orchestration logic figures that out based on inter-resource dependencies.

For example, in order to create a set private cloud resources, such as a WebLogic server instance, an application and a database, that interact with each other, you must first create the database and WebLogic server instance, deploy the application, and create a JEE data source that is to be used by the WebLogic server to connect to the database.

You could always perform all these operations manually, through the Oracle Enterprise Manager Cloud Self Service Portal. You would request creation of the WLS server and database and wait for either to complete. Periodically, you would check the status of the creation requests. Once the WLS server is created, you could deploy the application. When both the WLS server and database are created, you could create the JEE data source.

Alternatively, you can use a blueprint that describes the four cloud resources to automate the process. You request instantiation of the blueprint and provide any input parameter values required by the blueprint. The blueprint initiates the creation of the resources and monitors the creation process to ensure that the dependent resources are automatically created as soon as the required resources are created.

A blueprint can be used to automate the creation of cloud service instances. An Oracle Enterprise Manager self-service portal user can use blueprints for various reasons:

• To create an application composed of several service instances and related cloud resources.

• To create such sets several times (possibly with small variations).

• To facilitate instance creation for other self-service portal users.

• To eliminate the manual interactive steps that would otherwise be needed to create the set of instances

• You want a textual representation, e.g. to place it under version control or so that you can give it to someone else in a form he can review and modify.

For example, the Quality Assurance team in an enterprise needs to allocate and release resources required to test a Web application. Instead of manually creating the service instances using the Enterprise Manager Cloud Self Service application, a blueprint can be used to perform this task. One person authors a blueprint so that all QA engineers can simply invoke the blueprint and enter a few input parameter values, after which the resources are created. Each user can watch as the blueprint processor displays the status for creation of each resource.

Another example illustrates a blueprint’s use to address simplicity and consistency concerns. An IT shop has a service template that accepts 8 input parameters. For a specific group of users, the same set of values should be used for 6 of those 8 parameters. A simple blueprint accepts 2 parameters and uses the template to instantiate the instances with the other 6 parameters consistently defined.

The zipped package on cloud blueprints posted on Oracle Technology Network   has the documentation and source code to discover how to use and how to create your own cloud blueprints. The overview document introduces the blueprint concepts including how to deploy an existing blueprint as well as how to write your own. The reference manual goes into much greater detail on blueprints. 

Thursday Jan 03, 2013

Key Principles of Cloud Chargeback System

Contributed by Eric Tran-Le, VP, Product Management, Oracle Enterprise Manager

With public clouds users can now compare compute pricing pretty much like they would compare a car models. One could argue that compute power and services are different than a car but the fact is that users can compare costs.

Nothing has changed and everything has changed

Cost wise nothing has changed in a sense that the decision to implement a private cloud versus hosting on a public cloud is driven by the same factors than outsourcing or on-premise. It goes well beyond simple cost comparisons to touch upon key principles such as:

- Control of costs
- Visibility of costs
- Fairness of costs

Everything has changed in a sense that there is now a cost “predictability” expectation from users derived from a notion of “unit of compute” (the equivalent of standard energy Unit of Work) from which you can predict your resources consumption and infer total costs (a 45mpg rating means that you can drive 450 miles with 10 gallons or $40 if $4 per gallon). This is a more fundamental change in a sense that IT needs to work with the finance department to rationalize the cost-of-compute(Infrastructure + SW platform) and link it to the cost-to-serve (incident, problem, change & configuration management), the end goal is to produce a standard unit of compute that can be applied to various products and services configurations.

In part 1 of this blog, we will highlight how a cloud chargeback system can help addressing the key principles mentioned above and in part 2 we talk about how to create a profitable cost recovery model.

Key Principles of Chargeback System

Control of Costs

What is not defined cannot be controlled”, “What is not controlled cannot be measured”, “What is not measured cannot be charged”.
A cloud chargeback system provides a framework by which you can define a standard unit of cost for products and services. You can set unit of costs for resources based on hardware tiers or database high availability tiers, you can add fixed costs for on-going support costs or for facilities driven cost such as real-estate, power, HVAC,… but more importantly you can organized them by business units and cost centers so that you do have a cost structure hierarchy to report in aggregate or by business units. To define the right set of configurations, you need to baseline the current workloads utilization, characterize the patterns group of users and type of workloads and since you will use based compute metrics (CPU, memory, I/O,…) to measure utilization it is important for you to define which layers of computing ( Servers, Middleware, Databases,…) will reflect fairly the actual usage pattern of an application.

Visibility of Costs

Among all the features showing business units their VM consumption and allocations is the one that will start to change the relationship between IT and users more fundamentally. Actual utilization rate, historical trending, heat map displaying under and over utilized servers but also virtual environment configuration attributes such as high availability and regulatory compliance reports will contribute to a better cost-to-serve transparency. Another important capability to look for is how you can identify servers that cannot be part of a shared pool of resources due either to legacy applications or simply very high workload requiring dedicated machine this will help when you start sharing with the user the calculation of his charge plan.

Fairness of Costs

This the ONE difference with traditional chargeback models in a sense that metrics collected for charge calculation are actually “IT compute metrics” on top of which you add “services fee-based” metrics. In traditional chargeback direct or indirect model, the finance department tends to use non IT metrics such as # of users in a business unit as a % of aggregate IT costs or data center space taken by rack of servers,…this has led to a lot to the lack of transparency and the sense of “unfair” chargeback. As part of the charge plan calculation the characterization of fixed versus variable costs is essential to calculate the unit of charge.

Conclusion

Remember that in the cloud, users do not want to pay for resources they do not use and there is an expectation that they can dynamically request more resources, allocate and de-allocate resources. A cloud chargeback system will help you transition to a usage-based pricing of your IT resources will the key principles of control, visibility and fairness of costs. Last but not least, you do not need to go for the big-bang and turn chargeback right away you can implement showback and specific chargeback initiatives so that the business units can work with you on an efficient chargeback model.

Wednesday Dec 05, 2012

Amazon Web Services (AWS) Plug-in for Oracle Enterprise Manager

Contributed by Sunil Kunisetty and Daniel Chan

Introduction and Architecture

As more and more enterprises deploy some of their non-critical workload on Amazon Web Services (AWS), it’s becoming critical to monitor those public AWS resources along side with their on-premise resources.

Oracle recently announced Oracle Enterprise Manager Plug-in for Amazon Web Services (AWS) allows you to achieve that goal. The on-premise Oracle Enterprise Manager (EM12c) acts as a single tool to get a comprehensive view of your public AWS resources as well as your private cloud resources.  By deploying the plug-in within your Cloud Control environment, you gain the following management features:

  • Monitor EBS, EC2 and RDS instances on Amazon Web Services
  • Gather performance metrics and configuration details for AWS instances
  • Raise alerts and violations based on thresholds set on monitoring
  • Generate reports based on the gathered data

Users of this Plug-in can leverage the rich Enterprise Manager features such as system promotion, incident generation based on thresholds, integration with 3rd party ticketing applications etc. AWS Monitoring via this Plug-in is enabled via Amazon CloudWatch API and the users of this Plug-in are responsible for supplying credentials for accessing AWS and the CloudWatch API.

This Plug-in can only be deployed on an EM12C R2 platform and agent version should be at minimum 12c R2.Here is a pictorial view of the overall architecture:


Here are a few key features:

  • Rich and exhaustive list of metrics. Metrics can be gathered from an Agent running outside AWS.
  • Critical configuration information.
  • Custom Home Pages with charts and AWS configuration information.
  • Generate incidents based on thresholds set on monitoring data.

Discovery and Monitoring

AWS instances can be added to EM12C either via the EM12c User Interface (UI) or the EM12c Command Line Interface ( EMCLI)  by providing the AWS credentials (Secret Key and Access Key Id) as well as resource specific properties as target properties. Here is a quick mapping of target types and properties for each AWS resources

AWS Resource Type

Target Type

Resource specific properties

EBS Resource

Amazon EBS Service

CloudWatch base URI, EC2 Base URI, Period, Volume Id, Proxy Server and Port

EC2 Resource

Amazon EC2 Service

CloudWatch base URI, EC2 Base URI, Period, Instance  Id, Proxy Server and Port

RDS Resource

Amazon RDS Service

CloudWatch base URI, RDS Base URI, Period, Instance  Id, Proxy Server and Port

Proxy server and port are optional and are only needed if the agent is within the firewall.

Here is an emcli example to add an EC2 target. Please read the Installation and Readme guide for more details and step-by-step instructions to deploy  the plugin and adding the AWS the instances.

./emcli add_target \

      -name="<target name>" \

      -type="AmazonEC2Service" \

      -host="<host>" \

      -properties="ProxyHost=<proxy server>;ProxyPort=<proxy port>;EC2_BaseURI=http://ec2.<region>.amazonaws.com;BaseURI=http://monitoring.<region>.amazonaws.com;InstanceId=<EC2 instance Id>;Period=<data point periond>"  \

    -subseparator=properties="="

./emcli set_monitoring_credential \

                -set_name="AWSKeyCredentialSet"  \

                -target_name="<target name>"  \

                -target_type="AmazonEC2Service" \

                -cred_type="AWSKeyCredential"  \

                -attributes="AccessKeyId:<access key id>;SecretKey:<secret key>"

Emcli utility is found under the ORACLE_HOME of EM12C install. Once the instance is discovered, the target will show up under the ‘All Targets’ list under “Amazon EC2 Service’.

Once the instances are added, one can navigate to the custom homepages for these resource types. The custom home pages not only include critical metrics, but also vital configuration parameters and incidents raised for these instances.  By mapping the configuration parameters as instance properties, we can slice-and-dice and group various AWS instance by leveraging the EM12C Config search feature. The following configuration properties and metrics are collected for these Resource types.

Resource Type

Configuration Properties

Metrics

EBS Resource

Volume Id, Volume Type, Device Name, Size, Availability Zone

Response: Status

Utilization: QueueLength, IdleTime

Volume Statistics: ReadBrandwith, WriteBandwidth, ReadThroughput, WriteThroughput

Operation Statistics: ReadSize, WriteSize, ReadLatency, WriteLatency

EC2 Resource

Instance ID, Owner Id, Root Device type, Instance Type. Availability Zone

Response: Status

CPU Utilization: CPU Utilization

Disk I/O:  DiskReadBytes, DiskWriteBytes, DiskReadOps, DiskWriteOps, DiskReadRate, DiskWriteRate, DiskIOThroughput, DiskReadOpsRate, DiskWriteOpsRate, DiskOperationThroughput

Network I/O : NetworkIn, NetworkOut, NetworkInRate, NetworkOutRate, NetworkThroughput

RDS Resource

Instance ID, Database Engine Name, Database Engine Version, Database Instance Class, Allocated Storage Size, Availability Zone

Response: Status

Disk I/O:  ReadIOPS, WriteIOPS, ReadLatency, WriteLatency, ReadThroughput, WriteThroughput

DB Utilization:  BinLogDiskUsage, CPUUtilization, DatabaseConnections, FreeableMemory, ReplicaLag, SwapUsage

Custom Home Pages

As mentioned above, we have custom home pages for these target types that include basic configuration information,  last 24 hours availability, top metrics and the incidents generated. Here are few snapshots.

EBS Instance Home Page:


EC2 Instance Home Page:


RDS Instance Home Page:


Further Reading:

1)      AWS Plugin download

2)      Installation and  Read Me.

3)      Screenwatch on SlideShare

4)      Extensibility Programmer's Guide

5)      Amazon Web Services

About

"Zero to Cloud" Blog is dedicated to Enterprise Private Cloud Solution.
Zero To Cloud Resource Page

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today