On Tue, Feb 21, 2012 at 10:18 AM, Nirmal Fernando <nir...@wso2.com> wrote:
> Hi All, > > I need your views on following. > > In the Agent side we need to have a configuration file (say > instances_config.xml) which specifies the paths and names of the instances > belong to domains. > > I thought to have following structure: > > Value of the path attribute should change like this: > <domain name="wso2.as.domain"> > <instance name="wso2as-4.1.0-SNAPSHOT" > path="/home/nirmal/Desktop/wso2as-4.1.0-SNAPSHOT/bin/wso2server.sh"/> > <instance name="wso2as-4.1.0-SNAPSHOT" > path="/home/nirmal/Temp/wso2as-4.1.0-SNAPSHOT/bin/wso2server.sh"/> > ..... > </domain> > <domain name="wso2.bps.domain"> > <instance name="wso2bps-4.1.0-SNAPSHOT" > path="/home/nirmal/Desktop/wso2bps-4.1.0-SNAPSHOT/bin/wso2server.sh"/> > <instance name="wso2bps-4.1.0-SNAPSHOT" > path="/home/nirmal/Temp/wso2bps-4.1.0-SNAPSHOT/bin/wso2server.sh"/> > ..... > </domain> > ..... > > WDYT? > > PS: It is my understanding that the autoscaler component passes the > 'domain name' to the "Autoscaler Service", when it wants to scale. > > > > > On Mon, Feb 20, 2012 at 9:31 PM, Selvaratnam Uthaiyashankar < > shan...@wso2.com> wrote: > >> On Mon, Feb 20, 2012 at 8:17 PM, Nirmal Fernando <nir...@wso2.com> wrote: >> > Hi Shankar, >> > >> > On Mon, Feb 20, 2012 at 5:34 PM, Selvaratnam Uthaiyashankar >> > <shan...@wso2.com> wrote: >> >> >> >> Hi Nirmal, >> >> >> >> Good progress!. we can do a review on the work already done. >> > >> > >> > Thanks, will arrange a review this week. >> > >> >> >> >> >> >> Did you try the agent in windows? >> > >> > >> > No, I didn't! >> > >> >> >> >> Is it using any native code? >> > >> > >> > It needs to use native code in cases like spawning a new JVM (in Ubuntu >> we >> > need /bin/sh to run the script 'wso2server.sh' in windows we need to >> run the >> > batch file. >> > But I believe this can be handled within the code it self by checking >> the OS >> > name and execute appropriate commands! >> > >> >> >> >> >> >> See some comments below. >> >> >> >> On Sat, Feb 18, 2012 at 11:10 PM, Nirmal Fernando <nir...@wso2.com> >> wrote: >> >> > Hi All, >> >> > >> >> > I've started to implement 'new autoscaler architecture' [1] on >> February >> >> > 8th. >> >> > After having a discussion with Azeez, we came up with three >> milestones >> >> > for >> >> > the first iteration. >> >> > >> >> > >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> >> > >> >> > M1: Make a WS call spawns a new JVM instance & make the new instance >> >> > joins >> >> > the cluster with hard coded Agents. >> >> > >> >> > M2: Finish Agent registration related parts and spawn a new instance >> in >> >> > a >> >> > selected Agent. >> >> > >> >> > M3: Let current autoscaler component calls 'AutoscalerService' and >> >> > spawns a >> >> > new JVM instance in a selected Agent. Also applying WS security. >> >> > >> >> > >> >> > >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> >> > >> >> > I've attached set of images which depicts different stages of new >> >> > architecture. Reading order of images is as follows: >> >> > >> >> > agent-reg --> autoscaler --> spawn --> cluster >> >> > >> >> > >> >> > M1 is already finished. >> >> > >> >> > I've almost done the Agent registration (M2) aspect. >> >> > >> >> > What it does now? >> >> > >> >> > AgentManagementService and AutoscalerService should be deployed in >> the >> >> > back-end server. (say: IP is 192.168.1.2) >> >> > >> >> > AgentService should be deployed in machines (i.e. where new JVM >> >> > instances >> >> > will be spawned). (say: IP is 192.168.1.3) >> >> > >> >> > AgentService do a web service call (eg: curl -X GET >> >> > http://localhost:8080/axis2/services/AgentService/agent) to >> >> > AgentManagementService and get registered. Then >> AgentManagementService >> >> > stores the URL (eg: >> >> > http://192.168.1.3:8080/axis2/services/AgentService/) of >> >> > that particular request. >> >> > >> >> > When autoscaler API (implementing this is M3) wanted to spawn a new >> >> > instance >> >> > (JVM or EC2 or anything else), it should call AutoscalerService (eg: >> >> > curl >> >> > --data "instanceName=as" -X POST >> >> > http://192.168.1.2:8080/axis2/services/AutoscalerService/instance). >> Then >> >> > AutoscalerService decides which kind of instance to spawn. >> >> > >> >> > If AutoscalerService decides to spawn a JVM instance, it creates a >> new >> >> > JVMAdaptor instance. JVMAdaptor then calls (eg: curl -X GET >> >> > http://192.168.1.2:8080/axis2/services/AgentManagementService/agent) >> >> > AgentManagementService in order to pick an Agent. >> AgentManagementService >> >> > picks an Agent in a round robin manner and sends back that Agent's >> EPR >> >> > (http://192.168.1.3:8080/axis2/services/AgentService/) to >> JVMAdaptor. >> >> > Then >> >> > JVMAdaptor does a web service call to that particular AgentService >> and >> >> > asked >> >> > it to spawn the requested instance (instance is yet hard coded). >> >> > >> >> > Spawned instance then joins the cluster. >> >> > >> >> > >> >> > Current observations: >> >> > >> >> > Currently starting instance aspect is done. >> >> > >> >> > I've tested this using 2 machines, and starting instance works fine. >> >> > >> >> > It is observed that the spawned JVM instances get killed when you >> issue >> >> > 'ctrl+c' in the terminal where axis2 running. But when I killed >> >> > axis2server.sh process only, the new JAVA process wasn't get killed. >> To >> >> > avoid process get killing when issue ctrl+c, we might need to handle >> >> > SIGINT >> >> > [2]. Can't we be happy with the fact that it doesn't get killed after >> >> > killing axis2server.sh? >> >> >> >> JVMs (which were created) should live even if you kill the agent. >> >> >> > >> > Yes, but the problem is how you kill! If you use kill -9 and kills Axis2 >> > related process (Axis2 is where Agent Service is deployed), spawned JVM >> > instances aren't get killed. >> > Anyway will research a bit more, I understand that spawned instance >> should >> > never get killed, unless it is asked to! >> > >> >> >> >> > >> >> > >> >> > Work to be done: >> >> > >> >> > Terminating and finding instance aspects should be addressed. >> >> >> >> You have to keep track of which JVMs/VMs created by the autoscaler. >> >> Otherwise you will not be able to stop them when you want to scale >> >> down. I believe, this information should be stored/kept with >> >> "autoscaler service". >> > >> > >> > I have started to implement this part today! According to the design >> > 'Autoscaler Service' is only responsible for >> > deciding the type of instance it should be spawned. That is a JVM >> instance >> > or an EC2 instance or something else. Thus, it keeps track of >> > the type of instance spawned. >> > >> > It is JVM Adaptor which keeps track of instances spawned in each Agent. >> >> +1. It should be JVM adapter for JVM instances and EC2 adapter for EC2 >> instance, etc. >> >> Shankar >> >> >> > >> > And it is respective Agent Service that kills an instance, upon a >> request! >> > >> > >> >> >> >> >> >> > The 'sad side' (when things go wrong) should be addressed. >> >> > AgentServices should know EPR of AgentManagementService (this is hard >> >> > coded >> >> > now). Should read from a config file? >> >> >> >> +1 fore reading from config file. >> > >> > >> > Great! >> > >> >> >> >> >> >> >> >> > JVMAdaptor should keep a map of Agent EPR to AgentService client, to >> >> > avoid >> >> > creating multiple clients to access the same Agent. >> >> > AgentService should keep a count of spawned instances and get itself >> >> > unregistered if it can't handle any new instances (threshold value >> >> > should be >> >> > decided). And when it feels (another threshold) that it can handle >> new >> >> > instances it should register again. >> >> > Autoscaler API should be designed. >> >> > Should port EC2 client to EC2Adaptor. >> >> > Should test the whole scenario. >> >> > >> >> > >> >> > I appreciate your comments/thoughts on above facts. >> >> > >> >> > >> >> > [1] >> >> > >> http://mail.wso2.org/mailarchive/architecture/2011-October/006414.html >> >> > >> >> > [2] http://www.cons.org/cracauer/sigint.html >> >> > >> >> > >> >> > >> >> > -- >> >> > >> >> > Thanks & regards, >> >> > Nirmal >> >> > >> >> > Software Engineer- Platform Technologies Team, WSO2 Inc. >> >> > Mobile: +94715779733 >> >> > Blog: http://nirmalfdo.blogspot.com/ >> >> >> >> >> >> >> >> -- >> >> S.Uthaiyashankar >> >> Senior Architect & Senior Manager >> >> WSO2 Inc. >> >> http://wso2.com/ - "lean . enterprise . middleware" >> >> >> >> Phone: +94 714897591 >> > >> > >> > >> > >> > -- >> > >> > Thanks & regards, >> > Nirmal >> > >> > Software Engineer- Platform Technologies Team, WSO2 Inc. >> > Mobile: +94715779733 >> > Blog: http://nirmalfdo.blogspot.com/ >> >> >> >> -- >> S.Uthaiyashankar >> Senior Architect & Senior Manager >> WSO2 Inc. >> http://wso2.com/ - "lean . enterprise . middleware" >> >> Phone: +94 714897591 >> > > > > -- > > Thanks & regards, > Nirmal > > Software Engineer- Platform Technologies Team, WSO2 Inc. > Mobile: +94715779733 > Blog: http://nirmalfdo.blogspot.com/ > -- Thanks & regards, Nirmal Software Engineer- Platform Technologies Team, WSO2 Inc. Mobile: +94715779733 Blog: http://nirmalfdo.blogspot.com/
_______________________________________________ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
