Wednesday, August 24, 2011

What we can Thottle in WSO2 Stratos(1.5.1 Release) Cloud Environment - Tomcat server Based throttling

What we can Throttle in WSO2 Stratos(1.5.1 Release) Cloud Environment - Tomcat server Based throttling
In wso2 stratos throttling we will be able to throttle few parameters related to service and bandwidth usages. In this post i will briefly describe the parameters that we can throttle with wso2 stratos 1.5.1 release.


01. Registry Resource Volume
    For Registry usages we will be able to throttle following parameters
     Registry incoming data actions - put/ importResource/ restore
     Registry outgoing data actions - dump/ get
02. Service Bandwidth
     Throttle the service incoming and out going message sizes to the  Web Services(Axis2 Service/  JAX-WS Service/ Jar Service/ Jar Service) hosted at wso2 Stratos
     Application Server.For each incoming and outgoing messages throttling agent check whether that tenant is exceeded incoming and outgoing bandwidths. then only that allow users to invoke services.We can use two parameters(incoming/ outgoing) related to service bandwidth for throttling rules. For this throttling agent use Handler extended from AbstractHandler and that handler act as a listener for service invocations.
     Service incoming action
     Service outgoing action
03. webApp bandwidth
     Throttle the service incoming and out going based on message sizes to the Web Application Archive (.war) files hosted in Application server.For this webApp throttling we use valve extended from CarbonTomcatValve.That valve act as a listener and check whether tenant allow it or not. Here we can use two parameters(incoming/ outgoing) related to webApp bandwidth for throttling rules.
     webApp incoming action
     webApp outgoing action
04. User Count
     Number of users per given tenant.


So all together we will be able to throttle 7 actions as follows for given tenant.
01. Registry incoming data actions - put/ importResource/ restore
02. Registry outgoing data actions - dump/ get
03. Service incoming action
04. Service outgoing action
05. webApp incoming action
06. webApp outgoing action
07. User count per tenant

See original post

Usage metering and throttling in cloud computing - introduction for Users/Developers

Here in this post i will describe how to use usage metering and throttling in cloud environment. For this post i will use WSO2 stratos which is a complete Platform-as-a-Service for private and public clouds. Lets see how we do usage metering and throttling in stratos.

What is WSO2 Stratos ?

WSO2 Stratos is a complete SOA and developer platform offered as a self-service, multi-tenant, elastic runtime for private and public cloud infrastructures. What that means is that our complete SOA platform - now enhanced with Tomcat and Webapp support - is available as a  "cloud native" runtime that you can either use on the Web (yes - you can try it out right now), on Amazon VPC, or on your own internal private cloud based on Ubuntu Enterprise Cloud, Eucalyptus and (coming soon) vmWare vSphere. It is a complete Platform-as-a-Service for private and public clouds.

Download stratos source and more documents available at http://wso2.org/library/stratos

Post on how to build stratos 1.5.1 source available at

http://sanjeewamalalgoda.blogspot.com/2011/08/how-to-build-wso2-stratos-151-from.html

Sign up for a free account at  stratos private cloud https://stratoslive.wso2.com

What is Tenant ?

In stratos we used term tenant. What is tenant? it’s like an organization (sanjeewa.com) and it may few users (like departments within organization). There is administrator for each tenant and others are users. Administrator can allow users to use services and he is the person who governs the entire system for tenant. See following diagram for understanding tenant.

Tenant

Figure: Tenant and its users

Why we need Usage and Throttling ?

WSO2 stratos throttling component is the only one tomcat server based throttling module. And WSO2 Stratos 1.5.1 provides many new features like metering throttling and billing. So with WSO2 Stratos you will be able to measure, throttle and bill the server usage. Its really important to have reliable billing/ throttling model for cooperate service providers. Stratos 1.5.1 provides complete solution for web services with pricing model. So we will look at this usage and throttling model in detail. So this process has 2 main actions.

1. Before user perform some action we will check whether he is allow to do it or not(Ex adding new service/ service invocation).

2. After performing some action we keep it record (sanjeewa.com tenant used 100kb service Bandwidrh)

See following diagram for overview of usage and throttling.

sss 

Figure : Usage And Throttling Overview

Usage Agent

Usage agent is responsible for measure parameters and publishes them into Business Activity monitor server(Where we store data and monitor). for each and every tenants agent measure some important parameters related to their usage of bandwidth and resources(Service/webApp bandwidth, Registry usage, User count). This usage metering process use some advanced listening technologies to avoid slows down or blocks entire process.

As an example let say some web service hosted by sanjeewa.com try to invoke by some client so this invocation takes 100kb service bandwidth. So we will store this entry this tenant(sanjeewa.com) got service bandwidth of 100kb at this time

Usage Summery generator

Summery generator component responsible for summarize captured data. And after collecting raw data we do sorting and summarization periodically and store those records in database. Those records are available per hourly, monthly, daily, quarterly and annually.

As example after hour we will put above 100kb entry to hourly table. Then at the end of the day it will go to daily table with corresponding day of month.

Throttling Manager

Throttling is used to avoid excess usage of resources and bandwidth. Throttling manager periodically check the usage records(The data captured by above mentioned usage agent) available and evaluate throttling rules and define set of actions for each and every tenant. These actions are contain what tenants can do what cannot do what are the error messages that we have to show them. Those rules are written in drools. Drools is a business rule management system (BRMS) with a forward chaining inference based rules engine, more correctly known as a production rule system, using an enhanced implementation of the Rete algorithm. Using a rules engine can lower an application's maintenance and extensibility costs by reducing the complexity of components that implement complex business logic. So inside WSO2 stratos throttling component is use drools for throttling configurations and provide user interface to change rules in easier way. After evaluating Throttling rules for each tenant we will store the validation information(What tenant allow to do and what should block) in registry with tenant ID

Example :Throttling manager check the monthly data available in monthly service bandwidth table and check the Drool correspond to that tenant(Drool specify the service bandwidth allow to this user and actions when limit exceeding). If that user didn’t exceed limit it will put entry to registry saying sanjeewa.com is allow to service invocation else it will put entry saying not allowed.

Throttling Agent

Throttling agent is acting as a supervising agent who check the actions taken by users. Basically this will check registry entry for given tenant (Put by throttling manager). To achieve higher performance throttling agent use in memory implementation. It will take copy of registry entries and keep it cached. So reading validation information from cache is much faster than reading registry.

As an example When some tenant/users try to invoke web service this agent check the corresponding registry entry for user weather he is allow to do this or not. If he can do agent will allow to do it otherwise it will prompt message to user saying the issue.

See original post

How to configure usage in Cloud Environment using Stratos – User Guide

 

Here in this post i hope to discuss how to set up wso2 Stratos with usage metering. In this post i will mainly focus on how to setup and fine tuning parameters for usage metering. If you need more information on usage metering and throttling see my previous post from here. First you need to understand few terms

Usage Agent – Component which measures resource usage(use listening technology) and store it (Publish it to other server to record it).This usage metering process use some advanced listening technologies to avoid slows down or blocks entire process.

As an example let say some web service(hosted by sanjeewa.com) is invoked by some client. so this invocation takes 100kb service bandwidth. So usage agent will store this entry this tenant(sanjeewa.com) got service bandwidth of 100kb at this time

In order to usage metering work properly we have to do few configurations in stratos services.Usage metering is based on simple concept that is listening. There few listeners to listen the actions performed by user and those listeners  report what they heard to some other server(Business Activity Monitor). And those record will be store there in some ordered format.We will first identify those listeners.

01. Registry Listener – This listener will listen to each and every action related to registry(get, put, add, delete etc.. ) Then store them as bandwidth usage.

02. User Add Listener – This listener is there to listen user adding actions and keep updating user count of tenants

03. Service/Web App bandwidth listener – This listener is mainly listen to incoming and out going message sizes and store those data as bandwidth usages. For this listener usage agent use tomcat valve data statics.

See following Diagram for overview of usage metering process

Usageagentt

Figure : Overview Of Usage Metering Process

Data publisher – Data publisher is available inside the usage agent.When usage agent starts Data publisher creates the connection to the end point of BAM. In order to do this we have to provide Server URL of BAM instance running on.Let see how we do this configuration.This usage metering process happens at each and every stratos service so usage agent is available in every service of stratos. You can see carbon.xml file in every service inside the repository/conf folder. In carbon.xml file you will see following entry

<BamServerURL>https://bam.cloud-test.wso2.com:9447/services/</BamServerURL>

You have to give correct BAM server URL with /services part. you will see this URL when bam server starts up.Then only usage agent will be able to publish data to BAM.

Then these metered usage data will be available for any decision making process. Users(Tenants) can view their usage and super administrator can can view all tenants usages. Throttling manager use those records  to check whether users exceeded their allowed limits or not.

There are some other important parameters to configure for publisher.Those parameters are used configure to how we accumulate, how often we publish them to Bam kind of things. Since those configurations are developer level changes i will discuss it on separate post.

See original post

How to configure throttling in Cloud Environment using WSO2 Stratos – Users Guide

 

Here in this post i hope to discuss how to set up wso2 Stratos with throttling. In this post i will mainly focus on how to setup and fine tuning parameters for throttling and usage metering. If you need more information on usage metering and throttling see my previous post from here. First you need to understand few terms.If you need to understand more on throttling on Cloud environment please refer the this post on Amila Maharachchi’s Blog 

Throttling Manager – Manage, Evaluate what users can do and cannot do based on their subscription plans and their current usage.

Throttling Agent – This component detects user actions and allow them to do it or block it based on the Validation information generated by throttling manager

Usage Plan- There 4 types of usage plans available at WSO2 services. According to usage plan users will allow different volume of resources and service usage.(Demo/SMB/Professional/Enterprise). You will see more information on usage plans available at WSO2 StratosLive from here.

So we have to configure few things in order to work properly

01. How often throttling manager executes. Throttling manager periodically evaluates the tenants usage of resources(Service/webApp bandwidth, Registry usage, User count) and check it with their maximum allowed limit. After that process it store this validation data on registry. Here we can configure when start this evaluation process and how often we do this. To configure this we have to change configuration file( throttling-config.xml ). Before that you have to set up WSO2 Stratos properly(Manager/ IS/ any other services). Then go to inside of manager/repository/conf folder. There you will see throttling-config.xml file and that file has following entries.

<parameters>

<parameter name="interval">60</parameter>

<!--minutes = If This set to negative(-) value then throttling manager excecution will disable-->

<parameter name="delay">15</parameter>

</parameters>

interval parameter is there to specify the time frequency(in minutes) of executing throttling manager.According to this configuration it says execute rules after 60 minutes. With this configuration Manager will detect any excess usage of resources within one hour. after each 60 minutes It will call Data services and get current usage of each and every tenant and updating their actions(What they are allow to do or what they are not allowed)

delay parameter is there to define when to start first rule execution.According to this configuration server will run first throttling rule execution after 15 minutes time of server started.

15 minutes and 60 minutes are recommended values. But if you need much more accuracy you can reduce that interval value(But its advisable use some value more than 3 minutes otherwise it will causes to performance drop). And also remember reducing this time always causes to higher CPU Usage. If you don't need to run throttling manager you can disable it by setting negative value for  interval parameter. If you plan to run manager instance without throttling you can use this configuration.

02. How other Services allow to use Throttling manager. In order to  use throttling manager by services we have to modify configuration in each and every services that we use(Appserver/ IS/ BAM/ DSS etc..). Those services need to access throttling manager at WSO2 Stratos Manager. In that case we have to modify throttling-agent-config.xml file. That file has following content.

<throttlingAgentConfig xmlns="http://wso2.com/carbon/multitenancy/throttling/agent/config">

<parameters>

<parametername="managerServiceUrl">https://cloud-test.wso2.com/services/</parameter>

<parameter name="userName">admin</parameter>

<parameter name="password">admin</parameter>

</parameters>

</throttlingAgentConfig>

managerServiceUrl – is the URL of manager running on. Manager services URL. you will see this URL when manager starts up at terminal. by default this will set to local host.

userName – Here we have to specify Stratos Manager server super admin user name (By default it will be admin)

password  Here we have to specify Stratos Manager server super admin password (By default this will be admin)

This configuration is used by other services except manager to run the throttling rules at manager. As an example when we try to add new user identity server will call manager throttling manager to report new user adding. Otherwise within one hour of throttling rule execution time tenant user may add any number of users. To avoid such misuses we use this technique.

03. How to write throttling rules. For each usage plans we have to specify the upper limit of resource and service usage. And then if any user try to go beyond that limit throttling agent will stop that action immediately. As example if Demo account is allow to add 1 users we have to specify it in throttling rules. You will see throttling-rules.drl file inside manager/repository/conf. At first time manager takes rules from that file and store it in registry. Only super admin user for stratos manager allow to change throttling rules. If you logged in as super Admin you will see throttling menu. by clicking it you will see throttling rules editor window where you can write rules. There is other blog post on how to write throttling rules if you are interested please refer it .

See original post

How to build wso2 stratos 1.5.1 from the source

WSO2 Stratos is the most complete, enterprise-grade, open PaaS, with support for more core services than any other available PaaS today.
WSO2 Stratos provides the core cloud services and essential building blocks for example federated identity and single sign-on, data-as-a-service and messaging-as-a-service and more, required for developing SaaS and cloud applications.
Here below i will describe how to build stratos 1.5.1 from source.
You will find more information on wso2 stratos main page from this Link
Download stratos source from the hosted location
$ wget http://dist.wso2.org/products/stratos/1.5.1/wso2-stratos-1.5.1-src.zip

unzip content into some given location
unzip wso2-stratos-1.5.1-src.zip

go inside the extracted folder and start build it on line
stratos151src@sr2:~/stratos151src$mvn clean install

if it fails due to some reason(may be due to on line repo problems) follow the below guide lines.
In order to build carbon products we need to build axis2 first if that is not available at online repos

stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/dependencies/axis2/1.6.1-wso2v1
Then build dependencies
And continue build in following order with given commands
stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/dependencies$ mvn clean install

stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/orbit$ mvn clean install -Dmaven.test.skip=true

stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/service-stubs$ mvn clean install -Dmaven.test.skip=true
You must build carbon core with tests so use following command
stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/core$ mvn clean install

Before build components we have to little change for stratos pom.xml file. Due to the error in pom file location of
org.wso2.carbon.tenant.dispatcher folder.

So lets see how we can do that modification
Go to stratos folder as follows
stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/components/stratos$ vi pom.xml

Do the following change
replace line
org.wso2.carbon.tenant.dispatcher/3.2.0
with
org.wso2.carbon.tenant.dispatcher/1.5.1

Then build components
stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/components$mvn clean install

Then we have to build features
stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/features$mvn clean install

Then we have to build products and services
stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/products$ ls
as  bam  bps  brs  carbon  cep  css  dss  esb  greg  gs  is  lb  manager  mb  ms  pom.xml  wsf

here you will see available products inside products folder
if you need to build appserver product and service use the following command. same way you can do this for other products as well

stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/products/as/4.1.1$mvn clean install
Then built packs will be available on following location
stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/products/as/4.1.1/modules/distribution/service/target








See original post

Tuesday, August 23, 2011

SSL enabled JConsole to monitor a WSO2 Carbon Server Securely

Written by Denis Weerasiri

WSO2 Products like WSO2 AS, ESB, BPS etc. are MBeans enabled servers such that they can be monitored via JMX clients. JConsole is a graphical JMX monitoring client which comes as a part of JDK.
Recently I had to securely monitor a remote WSO2 carbon server.
But the problem is, now any remote user can implement a MBean on the target server and use System.exit() from the client end to kill the Carbon server. So we need to harden  (or secure and restrict) the communication between client and server.
So I used jConsole via a SSL tunnel which enforces client authentication and RMI-registry authentication. Here’re the steps I took to solve the problem.
Note - Feel free to shout back in case you need more clarifications. In some steps I assumed the audience is aware of JMX, public key cryptography etc.

Content

Applied for
  • Carbon 3.2.0 (or above) based products (WSO2 BPS 2.1.0, WSO2 AS 4.1.0, WSO2 ESB 4.0.0 etc)

  • Sun JDK 1.6.0_24


Enable remote JMX monitoring for Carbon
    Once you start a WSO2 Carbon instance, default JMX Server is started as bound to localhost.
    Refer the Carbon console log.

    You can modify these ports at $CARBON_HOME/repository/conf/carbon.xml. See

    But to enable remote access, the JMX server should be unbound from localhost and bound to a remotely accessible IP address. This can be done by modifying $CARBON_HOME/repository/conf/advanced/jmx.xml. Modify the to the preferred IP address.

    Once the server is restarted, any external user can remotely monitor the Carbon instance via the exposed ports.
    See the console log to make sure, whether the modifications were applied correctly.

    Now the problem is using this exposed URL, a remote user can implement a MBean on the target server and use System.exit() from the client end to kill the Carbon instance. So we need to harden  (or secure and restrict ) the communication between client and server.

    Enforcing SSL
    Next step is to adding SSL to the communication.
    First of all we need to create a certificate which is used to encrypt the communication between JMX client and JMX server. For the simplicity we can use the keytool shipped with JDK to generate a self-signed certificate which will be used by the Carbon instance.
    Note - For more information on keytool refer http://download.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html

    Use the following command to generate the certificate.
    Note - you can prefer any place to keep the certificates. In as Carbon developers we use this location to store as a best-practice.

    During this operation, a public and private key pair and a certificate which is signed by the private key is generated.

    Now we need to export this self-signed certificate which is used by the JMX server and import it into trust store of our JMX client. In our case it’s jConsole. To do that use the following steps.
    1. Export the certificate to file called jConsole.cert

    2. Securely transfer jconsole.cert to the machine where the JMX client is installed

    3. Import the jconsole.cert to a truststore used by jConsole using the following command


    Now all the configurations are set for enforce SSL communication. Now the Carbon instance and jConsole need to be restarted with relavant JVM options.
    • Use the following command to start the Carbon instance with the mentioned JVM options.
      Note - Here the keystore password is what is specified while generating the self-signed certificate for Carbon instance.

    • To start jConsole


    Now the next step is to enforce SSL client authentication.

    Enforcing SSL client authentication

    To enable SSL client authentication, what we have to do is same as enforcing SSL communication.
    All we have to do is generate the self-signed certificate for jConsole and export that certificate and import it back to a trust store used by the Carbon instance.

    Use the following command to generate the certificate.

    Now Export the certificate to file called jconsole_client.cert.

    Then securely transfer jconsole_client.cert to where the Carbon instance is running.

    Now import jconsole_client.cert to the trust store used by Carbon instance using the following command.

    Now all the configurations are set for enforce SSL communication and SSL client authentication. Now the Carbon instance and jConsole need to be restarted with relavant JVM options.
    • Use the following command to start the Carbon instance with the mentioned JVM options.
      Note - Here the keystore password is what is specified while generating the self-signed certificate for Carbon instance.


    • To start jConsole use the following command


    Enforcing RMI-registry authentication

    Now RMI-registry which is remotely accessible from a separate port (in the above description it’s 9999) also need to be enforced with SSL client authentication. As we have all configured the trust stores and keystores in both client and server end, only requirement to enable RMI-registry authentication is to add the following JVM option to the WSO2 Carbon instance starting script.

    eg - 

    See original post

    WSO2 BPS 2.1.0 Available for Download

    Written by Denis Weerasiri


    The WSO2 Business Process Server(BPS) team is pleased to announce the release of 2.1.0 version of the Open Source Business Process server. WSO2 BPS 2.1.0 is based on WSO2 Carbon 3.2.0 which is the OSGi-based component framework allows the complete set of WSO2 products to leverage shared components, ensuring a consistent set of features between products, a consistent user experience, and reusing of identical components. You can find the release note for WSO2 BPS 2.1.0 from here.

    Two fresh products; WSO2 MB and WSO2 CEP also were released with the existing set of products.

    Few excerpts from the WSO2 BPS 2.1.0 release note...
    • WSO2 Business Process Server (BPS) is an easy-to-use Open Source Business Process Server that executes business processes written following WS-BPEL standard. WS-BPEL is emerging as the defacto standard for composing multiple synchronous and asynchronous web services into collaborative and transactional process flows which increase the flexibility and agility of your Service Oriented Architecture. WSO2 BPS is powered by Apache ODE and available under Apache Software License v2.0. WSO2 BPS provides a complete Web based graphical console to deploy, manage and monitor business process and process instances.

    • WSO2 BPS is developed on top of the revolutionary Carbon platform (Middleware a' la carte), and is based on the OSGi framework to achieve the better modularity for you SOA. Carbon platform contains lots of new features and many other optional components that can be used to customize or enhance the functionalities provided by BPS to suits you SOA needs. In addition to installing optional components you can uninstall unwanted features without any trouble.
      WSO2 team recently released 3.2.0 version of WSO2 Carbon platform which is the OSGi-based component framework allows the complete set of products to leverage shared components, ensuring a consistent set of features between products, a consistent user experience, and reusing of identical components.

    • An open source product, WSO2 BPS is available under the Apache Software License (v2.0) . This includes all of the extra integration and management functionality as well.

    See original post

     

    Copyright 2009 All Rights Reserved Revolution Two Church theme modified by Milinda Pathirage