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

Reply via email to