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
