On Tue, Oct 11, 2016 at 10:22 AM, Lakmal Warusawithana <lak...@wso2.com> wrote:
> > On Tue, Oct 11, 2016 at 10:06 AM, Manjula Rathnayake <manju...@wso2.com> > wrote: > >> Hi Sanjeewa, >> >> Are you suggesting an API manager deployment pattern using containers? >> Container per tenant and per gateway, key manager etc? >> > > Yes. With C5 APIM we will have per tenant gateway, store, publisher, > keymanger etc. > > >> >> thank you. >> >> On Mon, Oct 10, 2016 at 9:06 PM, Malaka Silva <mal...@wso2.com> wrote: >> >>> Hi Sanjeewa, >>> >>> My understanding is gateway pool is not tenant specific and will not be >>> returned but rather terminated? >>> >>> On Mon, Oct 10, 2016 at 8:01 PM, Sanjeewa Malalgoda <sanje...@wso2.com> >>> wrote: >>> >>>> Hi All, >>>> Starting this mail thread to continue discussion on "speedup instance >>>> activate time when we move ahead with container based deployments". As of >>>> now all of us are working on speedup server start time and deploy instances >>>> on demand with the help of load balancer. Please note that this is not >>>> alternative/replacement to effort on starting server faster(2 secs or >>>> less). This is about make request serving more faster even with small >>>> server startup time. >>>> >>>> When we do container based deployment standard approach we discussed so >>>> far was, >>>> >>>> - At the first request check the tenant and service from URL and do >>>> lookup for running instances. >>>> - If matching instance available route traffic to that. >>>> - Else spawn new instance using template(or image). When we spawn >>>> this new instance we need to let it know what is the current tenant and >>>> data sources, configurations it should use. >>>> - Then route requests to new node. >>>> - After some idle time this instance may terminate. >>>> >>>> *Suggestion* >>>> If we maintain hot pool(started and ready to serve requests) of servers >>>> for each server type(API Gateway, Identity Server etc) then we can cutoff >>>> server startup time + IaaS level spawn time from above process. Then when >>>> requests comes to wso2.com tenants API Gateway we can pick instance >>>> from gateway instance pool and set wso2.com tenant context and data >>>> source using service call(assuming setting context and configurations is >>>> much faster). >>>> >>>> *Implementation* >>>> For this we need to implement some plug-in to instance spawn process. >>>> Then instead of spawning new instance it will pick one instance from >>>> the pool and configure it to behave as specific tenant. >>>> For this each instance running in pool can open up port, so load >>>> balancer or scaling component can call it and tell what is the tenant and >>>> configurations. >>>> Once it configured server close that configuration port and start >>>> traffic serving. >>>> After some idle time this instance may terminate. >>>> >>>> This approach will help us if we met following condition. >>>> (Instance loading time + Server startup time + Server Lookup) *>* >>>> (Server Lookup + Loading configuration and tenant of running server from >>>> external call) >>>> >>>> Any thoughts on this? >>>> >>> > My concern is practical issues with adding these intelligent into current > Load Balancers ( not all loadbalancers support extendibility ). And people > can used deferent loadbalancer with their preferences. > If we are doing this, we should do this in network loadbalancer level (in k8s/docker-swarm/dc-os). Ideally if we done this correctly we can do vertical scaling as well. Then no need to worry about sessions etc. Other third party load balancers anyway fronted these network load balancers. > > >>>> Thanks, >>>> sanjeewa. >>>> -- >>>> >>>> *Sanjeewa Malalgoda* >>>> WSO2 Inc. >>>> Mobile : +94713068779 >>>> >>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>> :http://sanjeewamalalgoda.blogspot.com/ >>>> <http://sanjeewamalalgoda.blogspot.com/> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> >>> Best Regards, >>> >>> Malaka Silva >>> Senior Technical Lead >>> M: +94 777 219 791 >>> Tel : 94 11 214 5345 >>> Fax :94 11 2145300 >>> Skype : malaka.sampath.silva >>> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 >>> Blog : http://mrmalakasilva.blogspot.com/ >>> >>> WSO2, Inc. >>> lean . enterprise . middleware >>> https://wso2.com/signature >>> http://www.wso2.com/about/team/malaka-silva/ >>> <http://wso2.com/about/team/malaka-silva/> >>> https://store.wso2.com/store/ >>> >>> Don't make Trees rare, we should keep them with care >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Manjula Rathnayaka >> Technical Lead >> WSO2, Inc. >> Mobile:+94 77 743 1987 >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Lakmal Warusawithana > Director - Cloud Architecture; WSO2 Inc. > Mobile : +94714289692 > Blog : http://lakmalsview.blogspot.com/ > > -- Lakmal Warusawithana Director - Cloud Architecture; WSO2 Inc. Mobile : +94714289692 Blog : http://lakmalsview.blogspot.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
