good reason to skip it for a next version, let's look into it anyway, as we don't want to burn any of our ships.
On Mon, Jan 27, 2014 at 4:53 PM, Karl Harris <karl.har...@sungard.com> wrote: > All, > > At first redundant DHCP seemed like a good idea. I did some cursory > research and the more I read the more I'm convinced it may be > more trouble than its worth for the first implementation. I'll talk > with some of our Systems Engineer's here and get a broader > perspective. > > There seems to be only a single implementation of an open source DHCP > server that will handle the synchronization required for redundant > servers. > > Karl > > > On Fri, Jan 24, 2014 at 5:47 PM, Daan Hoogland <daan.hoogl...@gmail.com> > wrote: >> Saurav, >> >> Not sure how this happens now, but it is definateluy something we >> want. For the static conf files it won't be much of a problem. The >> firewall/loadbalences won't be much of a problem, they are fire and >> forget configurations of the ms that can just be sent to both. The >> dhcp is a challange. I am not sure if it is solved for the plain rvr >> now but it should be solved for that as well. >> >> On Fri, Jan 24, 2014 at 3:53 PM, Saurav Lahiri >> <saurav.lah...@sungard.com> wrote: >>> Daan, >>> I was wondering if you had not shared your thoughts, but looks like I had >>> missed your mail. >>> >>> I agree that redundant dhcp or dns would be good to have. What I meant was, >>> it appears that by just enabling RVR there is no way to auto sync >>> configuration between the master and slave nodes with regard to dhcp, >>> loadbalancer and firewall(specifically the dhcp lease file, haproxy,cfg and >>> iptables configuration). So just enabling RVR does not ensure high >>> availability for these services. Is there a way cloudstack autosyncs >>> configuration? >>> >>> For the routing portion this is not an issue as the participating routers >>> learn the route through known protocols. >>> >>> Thanks >>> Saurav >>> >>> >>> On Fri, Jan 17, 2014 at 2:37 AM, Daan Hoogland >>> <daan.hoogl...@gmail.com>wrote: >>> >>>> Saurav, I don't see why you can't benefit from having other services >>>> redundant as well. Vpn might be a problem as the source ip of a >>>> redundant router pair on a vpn might give a problem (maybe there is an >>>> implementation) but why wouldn't you want redundant dhcp or dns >>>> services? As I understand it these are used at Schuberg Philis at the >>>> moment. will double check when I get a chance. >>>> >>>> regards, >>>> Daan >>>> >>>> >>>> >>>> On Thu, Jan 16, 2014 at 1:33 PM, Saurav Lahiri >>>> <saurav.lah...@sungard.com> wrote: >>>> > Daan, >>>> > So looking at what is available today for guest network, the Redundant VR >>>> > can be enabled only for the source nat service. I guess the mention of >>>> the >>>> > source nat router is in relation to that. I could be wrong though. It >>>> > appears that the other services like vpn, dhcp, dns do not benefit much >>>> > from the RVR capability. Can you clarify if thats correct? >>>> > >>>> > Thanks >>>> > Saurav >>>> > >>>> > >>>> > On Thu, Jan 16, 2014 at 2:27 AM, Karl Harris <karl.har...@sungard.com >>>> >wrote: >>>> > >>>> >> ---------- Forwarded message ---------- >>>> >> From: Daan Hoogland <daan.hoogl...@gmail.com> >>>> >> Date: Wed, Jan 15, 2014 at 2:51 PM >>>> >> Subject: Re: rvr4vpc >>>> >> To: Karl Harris <karl.har...@sungard.com> >>>> >> Cc: Christopher Litsinger <christopher.litsi...@sungard.com> >>>> >> >>>> >> >>>> >> H Karl, >>>> >> >>>> >> Thanks for sharing. I didn't want to initiate this but I encourage you >>>> >> to share this on the dev list (not in jira) as things are only >>>> >> considered 'discussed' if they passed by there. >>>> >> >>>> >> You speak of '1 Get configuration data on Source Nat Router', I don't >>>> >> understand why you call the router by this designation. 'Source Nat' >>>> >> is only one of it's many possible functions. >>>> >> >>>> >> Apart from the design principles I shared with you I have so far only >>>> >> a technical implementation detail so far. That is to reserve the >>>> >> (eth2) interface for the private gateway on the vpc (r)vr. This way >>>> >> the inteface to configure are somewhat predictable. >>>> >> >>>> >> As for the design principle to have a statefull router (reboot proof) >>>> >> the idea is to implement a configuration file that will be uploaded to >>>> >> the router after which a self-config command is send that will >>>> >> implement the details of configuring the interfaces, haproxy and >>>> >> keepalived and maybe more. I think your current assessment of the >>>> >> working of the RVRs is accurate but it will not be workable for an >>>> >> implementation for vpc's as they have an unpreditable number of >>>> >> interfaces. >>>> >> >>>> >> to bad you can't make it next thursday, >>>> >> Daan Hoogland >>>> >> >>>> >> >>>> >> On Wed, Jan 15, 2014 at 3:25 PM, Karl Harris <karl.har...@sungard.com> >>>> >> wrote: >>>> >> > Daan, >>>> >> > >>>> >> > Sorry for the delayed response but as Christopher mentioned to you in >>>> his >>>> >> > email I am getting my head around the CloudStack software. >>>> >> > Since I am new to CloudStack but "old" to enterprise level JAVA the >>>> task >>>> >> is >>>> >> > large but not impossible. I have no experience with running CloudStack >>>> >> but >>>> >> > considerable experience designing and maintaining large JAVA >>>> >> applications. >>>> >> > >>>> >> > I've created what I believe is a very high level abstract of how the >>>> >> current >>>> >> > guest VRR's are created for guest networks with the intent of making >>>> this >>>> >> > abstract >>>> >> > more detailed. >>>> >> > >>>> >> > 1 Get configuration data on Source Nat Router selected as a redundant >>>> >> > router >>>> >> > 1.1 Public and Guest network identified. >>>> >> > 2 Both routers are provisioned >>>> >> > 2.1 Software trys different, regions(?),zones,pods,clusters,hosts >>>> in >>>> >> > that order as the location of the router. Log maximum "distance" >>>> apart. >>>> >> > 3 Keepalived is configured >>>> >> > 4 Both routers are started >>>> >> > 5 Keepalived is started >>>> >> > >>>> >> > Obviously there is much more that is happening under each of the steps >>>> >> > above. My intent is to complete this detailed "as is" listing as much >>>> as >>>> >> we >>>> >> > can. Then using the "as is" description/sequence >>>> >> > make a "to-be" addition for VPC's. When I get a consensus on WHAT >>>> needs >>>> >> to >>>> >> > be implemented for the VRR in VPC then develop HOW best to implement >>>> the >>>> >> > "to-be" addition with the >>>> >> > existing JAVA code as well as what additional classes need to be >>>> >> > extended/implemented/created. >>>> >> > >>>> >> > Comments, critiques and changes to the above sequence are encouraged. >>>> >> > >>>> >> > I plan on posting this to the dev-list/Jira very soon. >>>> >> > >>>> >> > I have been using this functional spec as a guide, after discussing >>>> this >>>> >> > with our Systems Engineering people this spec meets our requirements. >>>> >> > >>>> >> > Do you have an implementation in mind? >>>> >> > >>>> >> > We have an internal Cloud Meeting with conflicts with the cloudstack >>>> >> "day" >>>> >> > next week so I will not be in attendence. >>>> >> > >>>> >> > Karl >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > On Tue, Jan 14, 2014 at 4:35 PM, Daan Hoogland < >>>> daan.hoogl...@gmail.com> >>>> >> > wrote: >>>> >> >> >>>> >> >> Hello overthere in the states, >>>> >> >> >>>> >> >> Tomorow I will start some experimenting with redundant vpc routers. >>>> >> >> This is to check up on any findings and requirements that you might >>>> >> >> have on this. Once again I would not like to waste work on this as it >>>> >> >> is really a globally usable feature that is probably universal. >>>> >> >> >>>> >> >> please let me know your status on this. >>>> >> >> >>>> >> >> If any of you are coming to the cloudstack day in London next week, >>>> >> >> let's meetup next thursday. >>>> >> >> >>>> >> >> kind regards, >>>> >> >> Daan Hoogland >>>> >> >> >>>> >> > >>>> >> > >>>> >> > >>>> >> > -- >>>> >> > Karl O. Harris >>>> >> > Cloud Software Engineer >>>> >> > Sungard Availability Services >>>> >> > >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Karl O. Harris >>>> >> Cloud Software Engineer >>>> >> Sungard Availability Services >>>> >> >>>> >>>> >> > > > > -- > Karl O. Harris > Cloud Software Engineer > Sungard Availability Services