Blog | On the Web | About me

Search 

Just a couple of weeks ago I started my study of cloud computing infrastructure. After IBM announced the availbilty of the new WebSphere Portal AMI on Amazon EC2 I couldn't wait to test the new toy so I got one.

My EC2 instance has been running for some days now


Image:Early experience with portal based on IBM new Portal on Amazon infrastructure - Technical report

I can tell that as of today it costed to me just 29,66 $ for uninterrupted runtime plus some experiment (I created a temporary clone to test snapshots and volumes but kept them running just for a couple of hours).


This means that so far I've been exploiting this setup for as little as 2.5 $ / day (everything included, storage, power, network bandwidth).


Also I can tell I'm using the "small" instance that offers:

  • 1,7 Gb of memory
  • 160 Gb local storage (that gets destroy if the instance is terminated)
  • 6 Gb of permanent EBS (elastic block space) storage that holds my db2 and websphere portal profile.

This is impressive, isn't it ?


But let's get technical.


I've been doing some experiment here's what I found out that may help you in your testing or may help the IBM team to improve the AMI.


AMI Installation process


At the first startup of the AMI everything works perfectly as described in the PDF guide IBM prepared for the offering.


The process is simple, straightforward and based on a SLES autoyast wizard:

1.        Choose your root password
2.        Choose your virtuser password (the default portal/was administrator for the AMI, stored in a file based WAS user registry)
3.        Select which storage option you want (use local/non persistent storage or attach a new or existing EBS volume)
4.        Wait for the "portal localization process" to complete the update for was/instance files

All of this takes at most 40 minutes, then you're ready.


So far everything is good


WebSphere Portal Running in development mode brings you "troubles"


Since the release of WPS 6.1 you can
run a task (enable-develop-mode-startup-performance ) to enable portal startup to be faster for development.
My experience is that a list of applications that SHOULD be running (ajax proxy config, feed searchlist etc) are disabled and cannot be lazy-started by the portal.


I'm wokring to define a "better" inclusion/exclusion list that will make the portal fully functional even in development mode.


The solution at this time is either to disable fast startupt, to manally enable needed components in the was console or to start all the apps from the console after ther portal started.


IBM HTTP Server filesystem: could be moved to the "persistent storage"


The AMI uses a /mnt/portalfs directory to store all the content that could be made persistent across instance launch (instance creation).


At this time only the wp_profile and db2inst1 database directory are brought to this filesystem.


I would suggest (and I've done it on my image) to also move IBM HTTP Server directories (conf / htdocs) to this filesystem replacing the original directories with symbolic links.


This is allowing me to preserve custom configurations at HTTP server level (let's say ... changes in httpd.conf, static files in htdocs etc.)


I suppose such a "trick" can also help with WAS Plugin files.


I'll work a bit more around this.


The "Site Wizard", power to the users (but with care)


I've been playing around with the site wizard since it's release just after portal 6.1 has been made available.


For those who don't know it... the
site wizard allows users to create their very own "virtual portals" without need of intervention from the IT / Portal staff.

This is going to be a great feature at some point but a few things to think about emerged during my tests.


The provided "templates" that are available in Site Wizard allow users to create basic portals with or without WCM functionality.


The process is pretty straightforward and it's based to a new API which allows the site wizard portlet to:
  • Create a virtual portal using an XMLAccess file
  • Eventually import WCM libraries to support the new virtual portal
  • Setup groups and users for access control of the new site
  • Offer the user a link to visit the new portal.

(there's a lot more but it would take a full article).


What I found out (and that's important for your "normal" portals too) is that if you share a "concrete" portlet in multiple virtual portals the virtual portal administrators can change the portlet "configure mode" data affetting all the instances in the portal and other virtual portals.


I suppose this is not something you want to happen so I'm looking into it to se if there's a way to create copies of the concrete portlet that are local to the virtual portal. This can be done for sure. It will just take some time to fully analyze the issue.


Finally... even if this feature is very interesting I'm thinking it's a bit "complex" to manage. For instance adding a new template requires a lot of work from technicall skilled people. I'm trying to figure out if a "scripting shell" can be created to manipulate and provision virtual portals in an easier way.


I'll keep you posted.



That's all for now.


If you're interested in Portals and Clouds please stay tuned.


More is coming in a few weeks.



Comments (4)
Daniele Vistalli February 25th, 2009 21:38:38