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 >>
