The reason I like the thought of a read or write database selection, is the ability to move dev systems into staging by simply assigning the VM to the correct domain for it's life-cycle.
Maybe I can convince a dev to pick up read/write separation. It can't be that tough, our inhouse distributed app does it with simple DSNs in a text file. Key thing being I want to tie the two sites as closely as possible and limit WAN talk. It would be nice to even have a secondary storage at the remote site and control local vs replicated templates/snapshot for DR purposes. So many decisions to make, haha. Thanks for all your help. ----- Original Message ----- From: "Marcus Sorensen" <shadow...@gmail.com> To: dev@cloudstack.apache.org Sent: Friday, October 18, 2013 9:10:34 AM Subject: Re: regions If you were to set up two cloudstacks (prod and dev), both authing to the same LDAP, at different sites, that would probably work, regardless of whether they're tied together as regions. If regions is LDAP compatible that might alleviate the manual account replication issue. On Fri, Oct 18, 2013 at 9:55 AM, Kelcey Jamison Damage <kel...@backbonetechnology.com> wrote: > you would be surprised that in some Ops environments having to only remember > one site url is worth it. > > I was hoping that with LDAP and the account structure I I could be 'root' > across all regions. I could provide the client a separate yet co-managed dev > environment at their site. Maintain their production in the main cloud, and > limit traffic over the IPSEC link. > > My only concern with putting a clustered management member at their site and > making it a dedicated extension of their domain, was all the traffic over the > tunnel for the database. Which brings up the question, can we specify a > read-only database for cloudstack? as in read from here, write to there? > > Because if that's possible then it makes no sense for me to use regions at > all. > > Thanks > > ----- Original Message ----- > > From: "Marcus Sorensen" <shadow...@gmail.com> > To: dev@cloudstack.apache.org > Sent: Friday, October 18, 2013 8:46:52 AM > Subject: Re: regions > > To answer your last question, a region is a grouping of zones, so you > can't have multiple regions manage the same zone. You can have > multiple mgmt servers manage the same zone though. > > You could deploy a management server as a part of a mgmt server > cluster in another site, assuming it had access to the database and > access to the vm hosts/management network. Or you could deploy a full > cluster, complete with vm hosts and database in the other site. You > can then link your sites together as regions, but per the email I'm > not sure it buys you anything yet except for a link at the top of the > page that lets you switch between being logged in to one site's mgmt > page or another. > > On Fri, Oct 18, 2013 at 9:24 AM, kel...@backbonetechnology.com > <kel...@backbonetechnology.com> wrote: >> I was under the impression that from the UI you could select the current >> region and view/manipulate resources. >> >> I was planning on using this to deploy a region for local dev work at a >> client's office, but maintain admin authority. Simply allowing tasks to be >> processed locally to them. >> >> Perhaps I miss-interpreted the use of regions. >> >> Does this mean I need to set the remote office as a dedicated cluster and >> have all that management traffic over the site to site link? >> >> Thanks. >> >> Sent from my HTC >> >> ----- Reply message ----- >> From: "Marcus Sorensen" <shadow...@gmail.com> >> To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org> >> Subject: regions >> Date: Fri, Oct 18, 2013 8:13 AM >> >> Thanks for the reply. >> >> On Fri, Oct 18, 2013 at 8:46 AM, Kishan Kavala <kishan.kav...@citrix.com> >> wrote: >>> >>>> -----Original Message----- >>>> From: Marcus Sorensen [mailto:shadow...@gmail.com] >>>> Sent: Friday, 18 October 2013 4:28 AM >>>> To: dev@cloudstack.apache.org >>>> Subject: regions >>>> >>>> I'm looking for more information on use cases for regions. I've been >>>> through: >>>> >>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/AWS- >>>> Style+Regions+Functional+Spec >>>> >>> [KK] Requirements doc has some info on use cases [1] >>>> And I've set up two management servers as separate regions. From what I >>>> can >>>> tell, I'm not sure why I'd want to use it. 1) accounts need to be >>>> replicated >>>> manually, and >>> [KK] Account sync need not be manual. Currently it is expected that sync is >>> done outside CS. Either though integrating with directory service or using >>> a portal layer above. >>> Alex Ough started a discussion [2] to use messaging framework to sync >>> account data >> >> Ok, that's good to know. To me this is pretty much the one thing from >> a management perspective that would differentiate regions vs >> standalone clusters. If a cloud operator has the means to manage >> external accounts on their own then they can also easily deploy >> multiple standalone management clusters and treat them as endpoints >> with the same amount of effort. If they don't, then regions become >> really useful if the feature handles account sync. >> >>> >>> 2)I can't make an API call to one MS to deploy in another region >>> [KK] AWS also doesn't support making API call to another region. You need >>> select an end_point before making an API call. >> >> Sure, but I don't generally think of CloudStack in terms of what AWS >> does or doesn't do. It never really occurs to me that a feature might >> do or not do something because it's what AWS does. I think we do that >> a bit too much. At any rate, I was just looking for reasons from a >> management perspective to use regions over standalone management >> clusters; if I have to choose an endpoint then at least in this regard >> it doesn't matter if that endpoint is a standalone cloudstack install >> or a region. >> >>> >>>> (or at least I don't see a documented way to do this). Between those two >>>> limitations, it means I could also set up two standalone management >>>> servers >>>> and they'd function the same, aside from the slight UI change of having >>>> another >>>> region listed in the UI. I realize there are GSLB and portable IP >>>> features, but >>>> they're not mentioned in the functional spec.I'm just looking for the >>>> differences from a management perspective and I don't see much. >>> [KK] GSLB spec [3]. EIP spec [4] >> >> Thanks. I also see that in some of the docs there are unimplemented >> things. I realize that it's a work in progress. Portable IPs look to >> be a feature within a region, and not cross-region, so this feature >> would apply to standalone mgmt servers, each being their own >> standalone region, correct? >> >> In a nutshell, if a cloud operator is managing their own accounts >> outside of CS, and has no intentions of buying a netscaler, there is >> currently no reason to link multiple sites into regions. Just treat >> each standalone site as its own endpoint. Is this a correct >> assessment? Also, it seems fairly straightforward to link two sites >> together into regions later as the feature gains more functionality, >> correct? >> >>> >>> [1] >>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/AWS-Style+Regions >>> [2] >>> http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201310.mbox/browser >>> [3] >>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/GSLB+%28Global+Server+Load+Balancing%29+Functional+specification+and+Design+Document >>> >>> [4] >>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/portable+public+IP >>> >
