You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Karl Harris <ka...@sungard.com> on 2014/02/03 18:03:26 UTC
Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual
Router for VPC email 2 of 2
After discussion with my colleagues questions about initial
configuration of the open network redundant routers and the
applicability of the existing bash scripts (cloud-early-config) to the
setup of VPC redundant routers have generated.
Some setup first: In the bash script cloud-early-config there is a
function named setup_redundant_router which makes copies of several
template files. The template files are used to configure keepalived
and conntrackd. The template copies are edited, via sed editor, using
environment variables ($ROUTER_PR, $ETH0_IP,$NAME, etc.) which are
obtained from the kernel of the current running linux image using the
virtual file system /proc/cmdline.
I'm sure keepalived and conntrackd can be used for starting and
control of VPC redundant routers. However the setup of keepalived and
conntrackd for VPC needs setup parameters which are dynamic because a
VPC can have N number of redundant router pairs, not just the fixed
number parsed from proc/cmdline in the running kernel.
Am I correct in this analysis?
If so, given the dynamic nature of the VPC redundant router
configurations: Is using a setup_VPC_redundant_router bash function,
similar to the existing open network function mentioned above, the
most appropriate way to setup the keepalived or conntrackd
configuration files for VPC redundant routers in the
cloud-early-script? It seems to me reading the parameters from the
kernel will require a unwieldy set of kernels to match the N private
network redundant router pairs configured by the enduser.
Comments, questions, clarifications?
Karl
In the bash script ea
On Mon, Jan 27, 2014 at 11:25 AM, Daan Hoogland <da...@gmail.com> wrote:
> 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 <ka...@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 <da...@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
>>> <sa...@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 <da...@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
>>>>> <sa...@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.harris@sungard.com
>>>>> >wrote:
>>>>> >
>>>>> >> ---------- Forwarded message ----------
>>>>> >> From: Daan Hoogland <da...@gmail.com>
>>>>> >> Date: Wed, Jan 15, 2014 at 2:51 PM
>>>>> >> Subject: Re: rvr4vpc
>>>>> >> To: Karl Harris <ka...@sungard.com>
>>>>> >> Cc: Christopher Litsinger <ch...@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 <ka...@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.hoogland@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
>
--
Karl O. Harris
Cloud Software Engineer
Sungard Availability Services
Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual
Router for VPC email 2 of 2
Posted by Sheng Yang <sh...@yasker.org>.
On Mon, Feb 3, 2014 at 9:03 AM, Karl Harris <ka...@sungard.com> wrote:
> After discussion with my colleagues questions about initial
> configuration of the open network redundant routers and the
> applicability of the existing bash scripts (cloud-early-config) to the
> setup of VPC redundant routers have generated.
>
>
> Some setup first: In the bash script cloud-early-config there is a
> function named setup_redundant_router which makes copies of several
> template files. The template files are used to configure keepalived
> and conntrackd. The template copies are edited, via sed editor, using
> environment variables ($ROUTER_PR, $ETH0_IP,$NAME, etc.) which are
> obtained from the kernel of the current running linux image using the
> virtual file system /proc/cmdline.
>
> I'm sure keepalived and conntrackd can be used for starting and
> control of VPC redundant routers. However the setup of keepalived and
> conntrackd for VPC needs setup parameters which are dynamic because a
> VPC can have N number of redundant router pairs, not just the fixed
> number parsed from proc/cmdline in the running kernel.
>
> Am I correct in this analysis?
>
Correct.
If you take a look at etc. keepalived.conf.templ, it contained:
virtual_ipaddress {
[ROUTER_IP] brd [BOARDCAST] dev eth0
}
It's the place you need to assign every gateway IP to the keepalived
knowledge, and the IP would be transfer between MASTER/BACKUP if fail-over
happened.
In isolated network, the guest IP is determined when you start up router,
which can be obtained from cloudstack cmdline. But for VPC, when router is
up, there is no guest nic, only public nic.
So the most important thing is still, determine when would you like to
setup keepalived and conntrackd. You would need send separate commands for
it(probably in vpc_guestgw.sh), rather than cloud-early-setup.
> If so, given the dynamic nature of the VPC redundant router
> configurations: Is using a setup_VPC_redundant_router bash function,
> similar to the existing open network function mentioned above, the
> most appropriate way to setup the keepalived or conntrackd
> configuration files for VPC redundant routers in the
> cloud-early-script? It seems to me reading the parameters from the
> kernel will require a unwieldy set of kernels to match the N private
> network redundant router pairs configured by the enduser.
>
No. cloud-early-setup is only a place fit isolated network. You would need
get the configuration done in other places.
Also you need to think about when would you like to start the second
router. Because without guest network, they cannot sync through VRRP(at
least in the current design).
--Sheng
>
>
> Comments, questions, clarifications?
>
> Karl
>
>
> In the bash script ea
> On Mon, Jan 27, 2014 at 11:25 AM, Daan Hoogland <da...@gmail.com>
> wrote:
> > 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 <ka...@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 <da...@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
> >>> <sa...@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.hoogland@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
> >>>>> <sa...@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.harris@sungard.com
> >>>>> >wrote:
> >>>>> >
> >>>>> >> ---------- Forwarded message ----------
> >>>>> >> From: Daan Hoogland <da...@gmail.com>
> >>>>> >> Date: Wed, Jan 15, 2014 at 2:51 PM
> >>>>> >> Subject: Re: rvr4vpc
> >>>>> >> To: Karl Harris <ka...@sungard.com>
> >>>>> >> Cc: Christopher Litsinger <ch...@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.harris@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.hoogland@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
> >
>
>
>
> --
> Karl O. Harris
> Cloud Software Engineer
> Sungard Availability Services
>
Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual
Router for VPC email 2 of 2
Posted by Daan Hoogland <da...@gmail.com>.
H Karl,
I wouldn't say so. The network is redundant by instantiation and not
by design I would say. Maybe you are thinking of an other
implementation then you are. I haven't read any recent docs by you so
maybe I lack context. I would say that the network(s) are plain (sdn)
networks and the redundancy is implemented in the
VpcVirtualApplianceManager.
sorry I can't chip in at the moment. Hope you'll let me know when you
are up to partitioning the problem.
regards,
On Wed, Feb 12, 2014 at 3:38 PM, Karl Harris <ka...@sungard.com> wrote:
> Would implementing a VPC Redundant Router Network Guru using the an
> extension of the NetworkGuru interface be an appropriate way to create a
> VPC network with redundant routers. It seems that extending Network Guru
> interface or extending one of it's children eg the abstract class
> GuestNetworkGuru would be a appropriate design path.
>
> Comments?
>
> Karl
>
>
>
> On Mon, Feb 3, 2014 at 2:58 PM, Daan Hoogland <da...@gmail.com>wrote:
>
>> On Mon, Feb 3, 2014 at 8:50 PM, Sheng Yang <sh...@yasker.org> wrote:
>> > On Mon, Feb 3, 2014 at 11:27 AM, Karl Harris <karl.harris@sungard.com
>> >wrote:
>> >
>> >> On Mon, Feb 3, 2014 at 2:03 PM, Daan Hoogland <daan.hoogland@gmail.com
>> >> >wrote:
>> >>
>> >> >
>> >> > On 03 Feb 2014, at 19:45, Karl Harris <ka...@sungard.com>
>> wrote:
>> >> >
>> >> > > On Mon, Feb 3, 2014 at 12:54 PM, Daan Hoogland <
>> >> daan.hoogland@gmail.com
>> >> > >wrote:
>> >> > >
>> >> > >>
>> >> > >> On 03 Feb 2014, at 18:03, Karl Harris <ka...@sungard.com>
>> >> wrote:
>> >> > >>
>> >> > >>> After discussion with my colleagues questions about initial
>> >> > >>> configuration of the open network redundant routers and the
>> >> > >>> applicability of the existing bash scripts (cloud-early-config) to
>> >> the
>> >> > >>> setup of VPC redundant routers have generated.
>> >> > >>>
>> >> > >>>
>> >> > >>> Some setup first: In the bash script cloud-early-config there is a
>> >> > >>> function named setup_redundant_router which makes copies of
>> several
>> >> > >>> template files. The template files are used to configure
>> keepalived
>> >> > >>> and conntrackd. The template copies are edited, via sed editor,
>> using
>> >> > >>> environment variables ($ROUTER_PR, $ETH0_IP,$NAME, etc.) which
>> are
>> >> > >>> obtained from the kernel of the current running linux image using
>> the
>> >> > >>> virtual file system /proc/cmdline.
>> >> > >>>
>> >> > >>> I'm sure keepalived and conntrackd can be used for starting and
>> >> > >>> control of VPC redundant routers. However the setup of keepalived
>> and
>> >> > >>> conntrackd for VPC needs setup parameters which are dynamic
>> because a
>> >> > >>> VPC can have N number of redundant router pairs, not just the
>> fixed
>> >> > >>> number parsed from proc/cmdline in the running kernel.
>> >> > >>>
>> >> > >>> Am I correct in this analysis?
>> >> > >> Karl, I think not. There is only one router in a vac, it routes for
>> >> all
>> >> > >> networks in the virtual private cloud. Am I misreading your
>> >> description.
>> >> > >
>> >> > > Ok then a VPC should contain a single router containing N+1 (N+2 if
>> >> > using a
>> >> > > VPN connection) nic's? Where N is the number of private networks.
>> >> > And I would like to see N+3 as it will allocate another when a private
>> >> > gateway is defined. That is why I proposed to pre-allocate this nic
>> to be
>> >> > able to predict mic-ids, i.e. eth<#>.
>> >> >
>> >> > >
>> >> > > If so then my original question still holds in the sense that the
>> nic's
>> >> > > need to be created in the VM kernel based on the number of private
>> >> > networks
>> >> > > desired?
>> >> >
>> >> > Yes
>> >> >
>> >> > > I found the method update_System_Vm_Templates in the jar file
>> >> > > Upgrade410to420 in cloud-engine-schema/src/com/cloud/upgrade/dao
>> which
>> >> > > seems to point to a set of pre-configured VM images.
>> >> > I can not find the method you describe but these preconfigured images
>> are
>> >> > the ones used for all the system vms. That would be secondary storage
>> >> vms,
>> >> > console proxy vms and indeed the router vms.
>> >> >
>> >> > Based on the discussion above the the configuration part of the VPC
>> >> redundant router is:
>> >>
>> >> 1. Collecting the correct data required to configure the nics. (Is this
>> >> part already in the VPC setup code? I will look for it, pointers will be
>> >> helpful.)
>> >>
>> >
>> > vpc_guestgw.sh
>> and VpcVirtualNetworkApplianceManager and -Impl and their ancestors
>>
>>
>> >
>> >
>> >> 2. Based on the hypervisor/vm types configure the nic(s) on the router
>> VM
>> >> using the data collected above (Same question as in 1 above is this code
>> >> already in place?). My guess is to start with a preconfigured template
>> and
>> >
>> > configure the vm based on the number of nics and any other appropriate
>> data.
>> >>
>> >
>> > Yes.
>> >
>> >
>> >> 3. Configuring conntrackd and keepalived after the router vm (nics)
>> have
>> >> been configured and the router(s) started or restarted? I still need to
>> >> work through this.
>> >>
>> >
>> > Likely you would need this.
>> >
>> > Don't know if keepalived can be start if there is no virtual IP
>> definition.
>> >
>> > You also need to think about what to do second router(or the router pair)
>> > when the last tier of VPC has been destroyed.
>> >
>> > --Sheng
>> >
>> >
>> >>
>> >>
>> >>
>> >>
>> >> >
>> >> > >>
>> >> > >>> If so, given the dynamic nature of the VPC redundant router
>> >> > >>> configurations: Is using a setup_VPC_redundant_router bash
>> function,
>> >> > >>> similar to the existing open network function mentioned above, the
>> >> > >>> most appropriate way to setup the keepalived or conntrackd
>> >> > >>> configuration files for VPC redundant routers in the
>> >> > >>> cloud-early-script? It seems to me reading the parameters from the
>> >> > >>> kernel will require a unwieldy set of kernels to match the N
>> private
>> >> > >>> network redundant router pairs configured by the enduser.
>> >> > >>>
>> >> > >>>
>> >> > >>> Comments, questions, clarifications?
>> >> > >>
>> >> > >>>
>> >> > >>> Karl
>> >> > >>>
>> >> > >>>
>> >> > >>> In the bash script ea
>> >> > >>> On Mon, Jan 27, 2014 at 11:25 AM, Daan Hoogland <
>> >> > daan.hoogland@gmail.com>
>> >> > >> wrote:
>> >> > >>>> 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.harris@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.hoogland@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
>> >> > >>>>>> <sa...@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.hoogland@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
>> >> > >>>>>>>> <sa...@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.harris@sungard.com
>> >> > >>>>>>>>> wrote:
>> >> > >>>>>>>>>
>> >> > >>>>>>>>>> ---------- Forwarded message ----------
>> >> > >>>>>>>>>> From: Daan Hoogland <da...@gmail.com>
>> >> > >>>>>>>>>> Date: Wed, Jan 15, 2014 at 2:51 PM
>> >> > >>>>>>>>>> Subject: Re: rvr4vpc
>> >> > >>>>>>>>>> To: Karl Harris <ka...@sungard.com>
>> >> > >>>>>>>>>> Cc: Christopher Litsinger <
>> christopher.litsinge@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.harris@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.hoogland@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
>> >> > >>>>
>> >> > >>>
>> >> > >>>
>> >> > >>>
>> >> > >>> --
>> >> > >>> 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
>> >>
>>
>>
>>
>> --
>> Daan
>>
>>
>
>
> --
> Karl O. Harris
> Cloud Software Engineer
> Sungard Availability Services
--
Daan
Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual
Router for VPC email 2 of 2
Posted by Sheng Yang <sh...@yasker.org>.
Hi Karl,
An separate way to VR to configure keepalived/conntrackd besides
cloud-early-setup is a must without doubt.
But a separate API may not be necessary.
So here is the question: can keepalived/conntrackd used independently
regardless of network setup?
I think the answer for now is no. I believe everything can be done along
with the network setup scripts in the VR(not cloud-early-setup, but e.g.
vpc_guestgw.sh which is called dynamically because it's also unknown when
boot up), since they have dependency. Currently one network is redundant or
not is defined by network offering, which WON'T change after network
create. And there is no switch to say "disable RvR" after RvR network
recreated unless network offering would be changed. The redundancy would
involve how to create and maintain the second router, I think keep it as it
is should be fine.
So the setup keepalived/conntrackd can be a part of
SetupGuestNetworkCommand API for VPC.
Does this make sense?
And there are something more you may need to think of. Configure
keepalived/conntrackd is fairly straightforward, but as I said before, when
to create the second router and how to maintain them is a bigger problem in
my mind. Because there is no guest network to run VRRP at the time VPC VR
creation.
--Sheng
On Thu, Feb 20, 2014 at 7:35 AM, Karl Harris <ka...@sungard.com>wrote:
> All,
>
> Here's what I've got so far with partitioning the problem.
>
> There are 3 main areas I've found so far along with a proposal for
> implementation.
>
>
>
> Keepalived:
>
> As Is:
>
> Current VRR network configuration setup is assumed by the existing code to
> be static. A single Keepalived config template file is edited at router VM
> boot time. The script cloud-early-config.sh and other BASH scripts are used
> to edit the template. The output of the edits is a keepalived.conf file
> used to configure the Keepalived application when the router VM boots.
>
> Desired:
>
> Ability (API, Java wrapper?) to configure/reconfigure Keepalived as the
> number of NIC's and other parameters change, a type of CRUD functionality
> along with start/stop/restart, which will allow the configuration state of
> network to be realized in the CloudStack database and NOT embedded
> statically in a combination of keepalived.conf.tmpl, hypervisorbased VM
> images and the actual edited keepalived.conf file. The operational state
> of the network is obviously kept by keepalived and conntrackd as well at
> the virtual router application itself.
>
>
> Conntrackd:
>
> As Is:
> Current Router state is managed by Conntrackd which is setup similarly to
> Keepalived using cloud-early-config.sh BASH script.
>
> Desired:
>
> Similarly to keepalived above: Ability (API, Java wrapper?) to do
> CRUD,start,stop,restart on Conntrackd network configuration.
>
>
> CloudStack Java code:
>
> As is:
>
> CloudStack only allows Virtual redundant routers for a single, static
> configuration for public networks mainly because of the lack of the ability
> to the existing code to dynamically
> change the configuration of the keepalived and conntrackd applications. As
> mentioned in a previous thread, it appears most, if not all, of the JAVA
> code used for public network redundant routers is available to use for
> implementation of VPC virtual redundant routers if the ability to
> dynamically reconfigure the network configuration of keepalived and
> conntrackd can be realized. Obviously additions to the JAVA code will need
> to be made to utilize the new CRUD functionality for keepalived and
> contrackd. As mentioned previously most if not all of the information is
> already in the MySQL database accessible via DAO/VO's
>
> Desired:
>
> CloudStack to be able to manipulate the keepalived and conntrackd
> applications to allow for dynamic configuration of VPC networks(s) which
> require virtual redundant router capability.
>
>
>
>
> Comments on this partitioning of the issues?
>
> Did I miss any major part?
>
>
>
>
> On Thu, Feb 13, 2014 at 3:12 PM, Sheng Yang <sh...@yasker.org> wrote:
>
> > Hi Karl,
> >
> > From Network Guru part of view, there is no VPC or isolated network guru.
> > Guru is per network type, e.g. public network, guest network, control
> > network, mgmt network. So VPC contained one public and multiple guest
> > network, which would be created by each guru accordingly. By this means,
> > VPC or isolated network is not a guru.
> >
> > The configuration of VR is done in VirtualNetworkApplianceManager and
> > VPCVirtualNetworkApplianceManager, which would be called by Virtual
> Router
> > element and VPC virtual router element. And they've already passed all
> the
> > information VR needed for VPC. I think every information you needed to
> > configure keepalived and conntrackd should be already there, except
> > redundant_router=1 parameter.
> >
> > For original redundant router implementation, there are two major parts
> of
> > code I've heavily modified: how to start two routers in one
> network(through
> > findOrDeployVirtualRouterInGuestNetwork()), and how to program
> them(through
> > cmdline parameter in the VR). I think the VPC implementation would face
> the
> > same issues as well. You can take a look at current implementation and
> > follow the code flow, to see if it would help you.
> >
> > --Sheng
> >
> > On Wed, Feb 12, 2014 at 11:15 AM, Karl Harris <karl.harris@sungard.com
> > >wrote:
> >
> > > On Wed, Feb 12, 2014 at 9:38 AM, Karl Harris <karl.harris@sungard.com
> > > >wrote:
> > >
> > > > Would implementing a VPC Redundant Router Network Guru using the an
> > > > extension of the NetworkGuru interface be an appropriate way to
> create
> > a
> > > > VPC network with redundant routers. It seems that extending Network
> > Guru
> > > > interface or extending one of it's children eg the abstract class
> > > > GuestNetworkGuru would be a appropriate design path.
> > > >
> > > > Comments?
> > > >
> > > > Karl
> > > >
> > > I know the configuration of the VM which implement the redundant
> routers
> > > are handled via BASH scripts and the environment variables int the VM
> > > images are used to configure the conntrackd and keepalived applications
> > via
> > > SED in bash scripts. I am looking for a clean way to pass the variable
> > > number of NIC's and then generate the LINK and IGNORE configuration
> > > commands for conntrackd.
> > >
> > > The Network Guru mentioned above seemed like an interesting place to
> > look,
> > > even though it's used to work with the DAO's for the NetworkElements.
> > >
> > > Karl
> > >
> > >
> > > >
> > > > On Mon, Feb 3, 2014 at 2:58 PM, Daan Hoogland <
> daan.hoogland@gmail.com
> > > >wrote:
> > > >
> > > >> On Mon, Feb 3, 2014 at 8:50 PM, Sheng Yang <sh...@yasker.org>
> wrote:
> > > >> > On Mon, Feb 3, 2014 at 11:27 AM, Karl Harris <
> > karl.harris@sungard.com
> > > >> >wrote:
> > > >> >
> > > >> >> On Mon, Feb 3, 2014 at 2:03 PM, Daan Hoogland <
> > > daan.hoogland@gmail.com
> > > >> >> >wrote:
> > > >> >>
> > > >> >> >
> > > >> >> > On 03 Feb 2014, at 19:45, Karl Harris <karl.harris@sungard.com
> >
> > > >> wrote:
> > > >> >> >
> > > >> >> > > On Mon, Feb 3, 2014 at 12:54 PM, Daan Hoogland <
> > > >> >> daan.hoogland@gmail.com
> > > >> >> > >wrote:
> > > >> >> > >
> > > >> >> > >>
> > > >> >> > >> On 03 Feb 2014, at 18:03, Karl Harris <
> > karl.harris@sungard.com>
> > > >> >> wrote:
> > > >> >> > >>
> > > >> >> > >>> After discussion with my colleagues questions about
> initial
> > > >> >> > >>> configuration of the open network redundant routers and the
> > > >> >> > >>> applicability of the existing bash scripts
> > (cloud-early-config)
> > > >> to
> > > >> >> the
> > > >> >> > >>> setup of VPC redundant routers have generated.
> > > >> >> > >>>
> > > >> >> > >>>
> > > >> >> > >>> Some setup first: In the bash script cloud-early-config
> there
> > > is
> > > >> a
> > > >> >> > >>> function named setup_redundant_router which makes copies of
> > > >> several
> > > >> >> > >>> template files. The template files are used to configure
> > > >> keepalived
> > > >> >> > >>> and conntrackd. The template copies are edited, via sed
> > editor,
> > > >> using
> > > >> >> > >>> environment variables ($ROUTER_PR, $ETH0_IP,$NAME, etc.)
> > which
> > > >> are
> > > >> >> > >>> obtained from the kernel of the current running linux image
> > > >> using the
> > > >> >> > >>> virtual file system /proc/cmdline.
> > > >> >> > >>>
> > > >> >> > >>> I'm sure keepalived and conntrackd can be used for
> starting
> > > and
> > > >> >> > >>> control of VPC redundant routers. However the setup of
> > > >> keepalived and
> > > >> >> > >>> conntrackd for VPC needs setup parameters which are dynamic
> > > >> because a
> > > >> >> > >>> VPC can have N number of redundant router pairs, not just
> the
> > > >> fixed
> > > >> >> > >>> number parsed from proc/cmdline in the running kernel.
> > > >> >> > >>>
> > > >> >> > >>> Am I correct in this analysis?
> > > >> >> > >> Karl, I think not. There is only one router in a vac, it
> > routes
> > > >> for
> > > >> >> all
> > > >> >> > >> networks in the virtual private cloud. Am I misreading your
> > > >> >> description.
> > > >> >> > >
> > > >> >> > > Ok then a VPC should contain a single router containing N+1
> > (N+2
> > > if
> > > >> >> > using a
> > > >> >> > > VPN connection) nic's? Where N is the number of private
> > networks.
> > > >> >> > And I would like to see N+3 as it will allocate another when a
> > > >> private
> > > >> >> > gateway is defined. That is why I proposed to pre-allocate this
> > nic
> > > >> to be
> > > >> >> > able to predict mic-ids, i.e. eth<#>.
> > > >> >> >
> > > >> >> > >
> > > >> >> > > If so then my original question still holds in the sense that
> > the
> > > >> nic's
> > > >> >> > > need to be created in the VM kernel based on the number of
> > > private
> > > >> >> > networks
> > > >> >> > > desired?
> > > >> >> >
> > > >> >> > Yes
> > > >> >> >
> > > >> >> > > I found the method update_System_Vm_Templates in the jar file
> > > >> >> > > Upgrade410to420 in
> > cloud-engine-schema/src/com/cloud/upgrade/dao
> > > >> which
> > > >> >> > > seems to point to a set of pre-configured VM images.
> > > >> >> > I can not find the method you describe but these preconfigured
> > > >> images are
> > > >> >> > the ones used for all the system vms. That would be secondary
> > > storage
> > > >> >> vms,
> > > >> >> > console proxy vms and indeed the router vms.
> > > >> >> >
> > > >> >> > Based on the discussion above the the configuration part of the
> > VPC
> > > >> >> redundant router is:
> > > >> >>
> > > >> >> 1. Collecting the correct data required to configure the nics.
> (Is
> > > >> this
> > > >> >> part already in the VPC setup code? I will look for it, pointers
> > will
> > > >> be
> > > >> >> helpful.)
> > > >> >>
> > > >> >
> > > >> > vpc_guestgw.sh
> > > >> and VpcVirtualNetworkApplianceManager and -Impl and their ancestors
> > > >>
> > > >>
> > > >> >
> > > >> >
> > > >> >> 2. Based on the hypervisor/vm types configure the nic(s) on the
> > > >> router VM
> > > >> >> using the data collected above (Same question as in 1 above is
> this
> > > >> code
> > > >> >> already in place?). My guess is to start with a preconfigured
> > > template
> > > >> and
> > > >> >
> > > >> > configure the vm based on the number of nics and any other
> > appropriate
> > > >> data.
> > > >> >>
> > > >> >
> > > >> > Yes.
> > > >> >
> > > >> >
> > > >> >> 3. Configuring conntrackd and keepalived after the router vm
> > (nics)
> > > >> have
> > > >> >> been configured and the router(s) started or restarted? I still
> > need
> > > to
> > > >> >> work through this.
> > > >> >>
> > > >> >
> > > >> > Likely you would need this.
> > > >> >
> > > >> > Don't know if keepalived can be start if there is no virtual IP
> > > >> definition.
> > > >> >
> > > >> > You also need to think about what to do second router(or the
> router
> > > >> pair)
> > > >> > when the last tier of VPC has been destroyed.
> > > >> >
> > > >> > --Sheng
> > > >> >
> > > >> >
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> >
> > > >> >> > >>
> > > >> >> > >>> If so, given the dynamic nature of the VPC redundant router
> > > >> >> > >>> configurations: Is using a setup_VPC_redundant_router bash
> > > >> function,
> > > >> >> > >>> similar to the existing open network function mentioned
> > above,
> > > >> the
> > > >> >> > >>> most appropriate way to setup the keepalived or conntrackd
> > > >> >> > >>> configuration files for VPC redundant routers in the
> > > >> >> > >>> cloud-early-script? It seems to me reading the parameters
> > from
> > > >> the
> > > >> >> > >>> kernel will require a unwieldy set of kernels to match the
> N
> > > >> private
> > > >> >> > >>> network redundant router pairs configured by the enduser.
> > > >> >> > >>>
> > > >> >> > >>>
> > > >> >> > >>> Comments, questions, clarifications?
> > > >> >> > >>
> > > >> >> > >>>
> > > >> >> > >>> Karl
> > > >> >> > >>>
> > > >> >> > >>>
> > > >> >> > >>> In the bash script ea
> > > >> >> > >>> On Mon, Jan 27, 2014 at 11:25 AM, Daan Hoogland <
> > > >> >> > daan.hoogland@gmail.com>
> > > >> >> > >> wrote:
> > > >> >> > >>>> 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.harris@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.hoogland@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
> > > >> >> > >>>>>> <sa...@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.hoogland@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
> > > >> >> > >>>>>>>> <sa...@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.harris@sungard.com
> > > >> >> > >>>>>>>>> wrote:
> > > >> >> > >>>>>>>>>
> > > >> >> > >>>>>>>>>> ---------- Forwarded message ----------
> > > >> >> > >>>>>>>>>> From: Daan Hoogland <da...@gmail.com>
> > > >> >> > >>>>>>>>>> Date: Wed, Jan 15, 2014 at 2:51 PM
> > > >> >> > >>>>>>>>>> Subject: Re: rvr4vpc
> > > >> >> > >>>>>>>>>> To: Karl Harris <ka...@sungard.com>
> > > >> >> > >>>>>>>>>> Cc: Christopher Litsinger <
> > > >> christopher.litsinge@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.harris@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.hoogland@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
> > > >> >> > >>>>
> > > >> >> > >>>
> > > >> >> > >>>
> > > >> >> > >>>
> > > >> >> > >>> --
> > > >> >> > >>> 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
> > > >> >>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Daan
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > 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
>
Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual
Router for VPC email 2 of 2
Posted by Karl Harris <ka...@sungard.com>.
All,
Here's what I've got so far with partitioning the problem.
There are 3 main areas I've found so far along with a proposal for
implementation.
Keepalived:
As Is:
Current VRR network configuration setup is assumed by the existing code to
be static. A single Keepalived config template file is edited at router VM
boot time. The script cloud-early-config.sh and other BASH scripts are used
to edit the template. The output of the edits is a keepalived.conf file
used to configure the Keepalived application when the router VM boots.
Desired:
Ability (API, Java wrapper?) to configure/reconfigure Keepalived as the
number of NIC's and other parameters change, a type of CRUD functionality
along with start/stop/restart, which will allow the configuration state of
network to be realized in the CloudStack database and NOT embedded
statically in a combination of keepalived.conf.tmpl, hypervisorbased VM
images and the actual edited keepalived.conf file. The operational state
of the network is obviously kept by keepalived and conntrackd as well at
the virtual router application itself.
Conntrackd:
As Is:
Current Router state is managed by Conntrackd which is setup similarly to
Keepalived using cloud-early-config.sh BASH script.
Desired:
Similarly to keepalived above: Ability (API, Java wrapper?) to do
CRUD,start,stop,restart on Conntrackd network configuration.
CloudStack Java code:
As is:
CloudStack only allows Virtual redundant routers for a single, static
configuration for public networks mainly because of the lack of the ability
to the existing code to dynamically
change the configuration of the keepalived and conntrackd applications. As
mentioned in a previous thread, it appears most, if not all, of the JAVA
code used for public network redundant routers is available to use for
implementation of VPC virtual redundant routers if the ability to
dynamically reconfigure the network configuration of keepalived and
conntrackd can be realized. Obviously additions to the JAVA code will need
to be made to utilize the new CRUD functionality for keepalived and
contrackd. As mentioned previously most if not all of the information is
already in the MySQL database accessible via DAO/VO's
Desired:
CloudStack to be able to manipulate the keepalived and conntrackd
applications to allow for dynamic configuration of VPC networks(s) which
require virtual redundant router capability.
Comments on this partitioning of the issues?
Did I miss any major part?
On Thu, Feb 13, 2014 at 3:12 PM, Sheng Yang <sh...@yasker.org> wrote:
> Hi Karl,
>
> From Network Guru part of view, there is no VPC or isolated network guru.
> Guru is per network type, e.g. public network, guest network, control
> network, mgmt network. So VPC contained one public and multiple guest
> network, which would be created by each guru accordingly. By this means,
> VPC or isolated network is not a guru.
>
> The configuration of VR is done in VirtualNetworkApplianceManager and
> VPCVirtualNetworkApplianceManager, which would be called by Virtual Router
> element and VPC virtual router element. And they've already passed all the
> information VR needed for VPC. I think every information you needed to
> configure keepalived and conntrackd should be already there, except
> redundant_router=1 parameter.
>
> For original redundant router implementation, there are two major parts of
> code I've heavily modified: how to start two routers in one network(through
> findOrDeployVirtualRouterInGuestNetwork()), and how to program them(through
> cmdline parameter in the VR). I think the VPC implementation would face the
> same issues as well. You can take a look at current implementation and
> follow the code flow, to see if it would help you.
>
> --Sheng
>
> On Wed, Feb 12, 2014 at 11:15 AM, Karl Harris <karl.harris@sungard.com
> >wrote:
>
> > On Wed, Feb 12, 2014 at 9:38 AM, Karl Harris <karl.harris@sungard.com
> > >wrote:
> >
> > > Would implementing a VPC Redundant Router Network Guru using the an
> > > extension of the NetworkGuru interface be an appropriate way to create
> a
> > > VPC network with redundant routers. It seems that extending Network
> Guru
> > > interface or extending one of it's children eg the abstract class
> > > GuestNetworkGuru would be a appropriate design path.
> > >
> > > Comments?
> > >
> > > Karl
> > >
> > I know the configuration of the VM which implement the redundant routers
> > are handled via BASH scripts and the environment variables int the VM
> > images are used to configure the conntrackd and keepalived applications
> via
> > SED in bash scripts. I am looking for a clean way to pass the variable
> > number of NIC's and then generate the LINK and IGNORE configuration
> > commands for conntrackd.
> >
> > The Network Guru mentioned above seemed like an interesting place to
> look,
> > even though it's used to work with the DAO's for the NetworkElements.
> >
> > Karl
> >
> >
> > >
> > > On Mon, Feb 3, 2014 at 2:58 PM, Daan Hoogland <daan.hoogland@gmail.com
> > >wrote:
> > >
> > >> On Mon, Feb 3, 2014 at 8:50 PM, Sheng Yang <sh...@yasker.org> wrote:
> > >> > On Mon, Feb 3, 2014 at 11:27 AM, Karl Harris <
> karl.harris@sungard.com
> > >> >wrote:
> > >> >
> > >> >> On Mon, Feb 3, 2014 at 2:03 PM, Daan Hoogland <
> > daan.hoogland@gmail.com
> > >> >> >wrote:
> > >> >>
> > >> >> >
> > >> >> > On 03 Feb 2014, at 19:45, Karl Harris <ka...@sungard.com>
> > >> wrote:
> > >> >> >
> > >> >> > > On Mon, Feb 3, 2014 at 12:54 PM, Daan Hoogland <
> > >> >> daan.hoogland@gmail.com
> > >> >> > >wrote:
> > >> >> > >
> > >> >> > >>
> > >> >> > >> On 03 Feb 2014, at 18:03, Karl Harris <
> karl.harris@sungard.com>
> > >> >> wrote:
> > >> >> > >>
> > >> >> > >>> After discussion with my colleagues questions about initial
> > >> >> > >>> configuration of the open network redundant routers and the
> > >> >> > >>> applicability of the existing bash scripts
> (cloud-early-config)
> > >> to
> > >> >> the
> > >> >> > >>> setup of VPC redundant routers have generated.
> > >> >> > >>>
> > >> >> > >>>
> > >> >> > >>> Some setup first: In the bash script cloud-early-config there
> > is
> > >> a
> > >> >> > >>> function named setup_redundant_router which makes copies of
> > >> several
> > >> >> > >>> template files. The template files are used to configure
> > >> keepalived
> > >> >> > >>> and conntrackd. The template copies are edited, via sed
> editor,
> > >> using
> > >> >> > >>> environment variables ($ROUTER_PR, $ETH0_IP,$NAME, etc.)
> which
> > >> are
> > >> >> > >>> obtained from the kernel of the current running linux image
> > >> using the
> > >> >> > >>> virtual file system /proc/cmdline.
> > >> >> > >>>
> > >> >> > >>> I'm sure keepalived and conntrackd can be used for starting
> > and
> > >> >> > >>> control of VPC redundant routers. However the setup of
> > >> keepalived and
> > >> >> > >>> conntrackd for VPC needs setup parameters which are dynamic
> > >> because a
> > >> >> > >>> VPC can have N number of redundant router pairs, not just the
> > >> fixed
> > >> >> > >>> number parsed from proc/cmdline in the running kernel.
> > >> >> > >>>
> > >> >> > >>> Am I correct in this analysis?
> > >> >> > >> Karl, I think not. There is only one router in a vac, it
> routes
> > >> for
> > >> >> all
> > >> >> > >> networks in the virtual private cloud. Am I misreading your
> > >> >> description.
> > >> >> > >
> > >> >> > > Ok then a VPC should contain a single router containing N+1
> (N+2
> > if
> > >> >> > using a
> > >> >> > > VPN connection) nic's? Where N is the number of private
> networks.
> > >> >> > And I would like to see N+3 as it will allocate another when a
> > >> private
> > >> >> > gateway is defined. That is why I proposed to pre-allocate this
> nic
> > >> to be
> > >> >> > able to predict mic-ids, i.e. eth<#>.
> > >> >> >
> > >> >> > >
> > >> >> > > If so then my original question still holds in the sense that
> the
> > >> nic's
> > >> >> > > need to be created in the VM kernel based on the number of
> > private
> > >> >> > networks
> > >> >> > > desired?
> > >> >> >
> > >> >> > Yes
> > >> >> >
> > >> >> > > I found the method update_System_Vm_Templates in the jar file
> > >> >> > > Upgrade410to420 in
> cloud-engine-schema/src/com/cloud/upgrade/dao
> > >> which
> > >> >> > > seems to point to a set of pre-configured VM images.
> > >> >> > I can not find the method you describe but these preconfigured
> > >> images are
> > >> >> > the ones used for all the system vms. That would be secondary
> > storage
> > >> >> vms,
> > >> >> > console proxy vms and indeed the router vms.
> > >> >> >
> > >> >> > Based on the discussion above the the configuration part of the
> VPC
> > >> >> redundant router is:
> > >> >>
> > >> >> 1. Collecting the correct data required to configure the nics. (Is
> > >> this
> > >> >> part already in the VPC setup code? I will look for it, pointers
> will
> > >> be
> > >> >> helpful.)
> > >> >>
> > >> >
> > >> > vpc_guestgw.sh
> > >> and VpcVirtualNetworkApplianceManager and -Impl and their ancestors
> > >>
> > >>
> > >> >
> > >> >
> > >> >> 2. Based on the hypervisor/vm types configure the nic(s) on the
> > >> router VM
> > >> >> using the data collected above (Same question as in 1 above is this
> > >> code
> > >> >> already in place?). My guess is to start with a preconfigured
> > template
> > >> and
> > >> >
> > >> > configure the vm based on the number of nics and any other
> appropriate
> > >> data.
> > >> >>
> > >> >
> > >> > Yes.
> > >> >
> > >> >
> > >> >> 3. Configuring conntrackd and keepalived after the router vm
> (nics)
> > >> have
> > >> >> been configured and the router(s) started or restarted? I still
> need
> > to
> > >> >> work through this.
> > >> >>
> > >> >
> > >> > Likely you would need this.
> > >> >
> > >> > Don't know if keepalived can be start if there is no virtual IP
> > >> definition.
> > >> >
> > >> > You also need to think about what to do second router(or the router
> > >> pair)
> > >> > when the last tier of VPC has been destroyed.
> > >> >
> > >> > --Sheng
> > >> >
> > >> >
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >> >
> > >> >> > >>
> > >> >> > >>> If so, given the dynamic nature of the VPC redundant router
> > >> >> > >>> configurations: Is using a setup_VPC_redundant_router bash
> > >> function,
> > >> >> > >>> similar to the existing open network function mentioned
> above,
> > >> the
> > >> >> > >>> most appropriate way to setup the keepalived or conntrackd
> > >> >> > >>> configuration files for VPC redundant routers in the
> > >> >> > >>> cloud-early-script? It seems to me reading the parameters
> from
> > >> the
> > >> >> > >>> kernel will require a unwieldy set of kernels to match the N
> > >> private
> > >> >> > >>> network redundant router pairs configured by the enduser.
> > >> >> > >>>
> > >> >> > >>>
> > >> >> > >>> Comments, questions, clarifications?
> > >> >> > >>
> > >> >> > >>>
> > >> >> > >>> Karl
> > >> >> > >>>
> > >> >> > >>>
> > >> >> > >>> In the bash script ea
> > >> >> > >>> On Mon, Jan 27, 2014 at 11:25 AM, Daan Hoogland <
> > >> >> > daan.hoogland@gmail.com>
> > >> >> > >> wrote:
> > >> >> > >>>> 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.harris@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.hoogland@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
> > >> >> > >>>>>> <sa...@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.hoogland@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
> > >> >> > >>>>>>>> <sa...@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.harris@sungard.com
> > >> >> > >>>>>>>>> wrote:
> > >> >> > >>>>>>>>>
> > >> >> > >>>>>>>>>> ---------- Forwarded message ----------
> > >> >> > >>>>>>>>>> From: Daan Hoogland <da...@gmail.com>
> > >> >> > >>>>>>>>>> Date: Wed, Jan 15, 2014 at 2:51 PM
> > >> >> > >>>>>>>>>> Subject: Re: rvr4vpc
> > >> >> > >>>>>>>>>> To: Karl Harris <ka...@sungard.com>
> > >> >> > >>>>>>>>>> Cc: Christopher Litsinger <
> > >> christopher.litsinge@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.harris@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.hoogland@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
> > >> >> > >>>>
> > >> >> > >>>
> > >> >> > >>>
> > >> >> > >>>
> > >> >> > >>> --
> > >> >> > >>> 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
> > >> >>
> > >>
> > >>
> > >>
> > >> --
> > >> Daan
> > >>
> > >>
> > >
> > >
> > > --
> > > 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
Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual
Router for VPC email 2 of 2
Posted by Sheng Yang <sh...@yasker.org>.
Hi Karl,
>From Network Guru part of view, there is no VPC or isolated network guru.
Guru is per network type, e.g. public network, guest network, control
network, mgmt network. So VPC contained one public and multiple guest
network, which would be created by each guru accordingly. By this means,
VPC or isolated network is not a guru.
The configuration of VR is done in VirtualNetworkApplianceManager and
VPCVirtualNetworkApplianceManager, which would be called by Virtual Router
element and VPC virtual router element. And they've already passed all the
information VR needed for VPC. I think every information you needed to
configure keepalived and conntrackd should be already there, except
redundant_router=1 parameter.
For original redundant router implementation, there are two major parts of
code I've heavily modified: how to start two routers in one network(through
findOrDeployVirtualRouterInGuestNetwork()), and how to program them(through
cmdline parameter in the VR). I think the VPC implementation would face the
same issues as well. You can take a look at current implementation and
follow the code flow, to see if it would help you.
--Sheng
On Wed, Feb 12, 2014 at 11:15 AM, Karl Harris <ka...@sungard.com>wrote:
> On Wed, Feb 12, 2014 at 9:38 AM, Karl Harris <karl.harris@sungard.com
> >wrote:
>
> > Would implementing a VPC Redundant Router Network Guru using the an
> > extension of the NetworkGuru interface be an appropriate way to create a
> > VPC network with redundant routers. It seems that extending Network Guru
> > interface or extending one of it's children eg the abstract class
> > GuestNetworkGuru would be a appropriate design path.
> >
> > Comments?
> >
> > Karl
> >
> I know the configuration of the VM which implement the redundant routers
> are handled via BASH scripts and the environment variables int the VM
> images are used to configure the conntrackd and keepalived applications via
> SED in bash scripts. I am looking for a clean way to pass the variable
> number of NIC's and then generate the LINK and IGNORE configuration
> commands for conntrackd.
>
> The Network Guru mentioned above seemed like an interesting place to look,
> even though it's used to work with the DAO's for the NetworkElements.
>
> Karl
>
>
> >
> > On Mon, Feb 3, 2014 at 2:58 PM, Daan Hoogland <daan.hoogland@gmail.com
> >wrote:
> >
> >> On Mon, Feb 3, 2014 at 8:50 PM, Sheng Yang <sh...@yasker.org> wrote:
> >> > On Mon, Feb 3, 2014 at 11:27 AM, Karl Harris <karl.harris@sungard.com
> >> >wrote:
> >> >
> >> >> On Mon, Feb 3, 2014 at 2:03 PM, Daan Hoogland <
> daan.hoogland@gmail.com
> >> >> >wrote:
> >> >>
> >> >> >
> >> >> > On 03 Feb 2014, at 19:45, Karl Harris <ka...@sungard.com>
> >> wrote:
> >> >> >
> >> >> > > On Mon, Feb 3, 2014 at 12:54 PM, Daan Hoogland <
> >> >> daan.hoogland@gmail.com
> >> >> > >wrote:
> >> >> > >
> >> >> > >>
> >> >> > >> On 03 Feb 2014, at 18:03, Karl Harris <ka...@sungard.com>
> >> >> wrote:
> >> >> > >>
> >> >> > >>> After discussion with my colleagues questions about initial
> >> >> > >>> configuration of the open network redundant routers and the
> >> >> > >>> applicability of the existing bash scripts (cloud-early-config)
> >> to
> >> >> the
> >> >> > >>> setup of VPC redundant routers have generated.
> >> >> > >>>
> >> >> > >>>
> >> >> > >>> Some setup first: In the bash script cloud-early-config there
> is
> >> a
> >> >> > >>> function named setup_redundant_router which makes copies of
> >> several
> >> >> > >>> template files. The template files are used to configure
> >> keepalived
> >> >> > >>> and conntrackd. The template copies are edited, via sed editor,
> >> using
> >> >> > >>> environment variables ($ROUTER_PR, $ETH0_IP,$NAME, etc.) which
> >> are
> >> >> > >>> obtained from the kernel of the current running linux image
> >> using the
> >> >> > >>> virtual file system /proc/cmdline.
> >> >> > >>>
> >> >> > >>> I'm sure keepalived and conntrackd can be used for starting
> and
> >> >> > >>> control of VPC redundant routers. However the setup of
> >> keepalived and
> >> >> > >>> conntrackd for VPC needs setup parameters which are dynamic
> >> because a
> >> >> > >>> VPC can have N number of redundant router pairs, not just the
> >> fixed
> >> >> > >>> number parsed from proc/cmdline in the running kernel.
> >> >> > >>>
> >> >> > >>> Am I correct in this analysis?
> >> >> > >> Karl, I think not. There is only one router in a vac, it routes
> >> for
> >> >> all
> >> >> > >> networks in the virtual private cloud. Am I misreading your
> >> >> description.
> >> >> > >
> >> >> > > Ok then a VPC should contain a single router containing N+1 (N+2
> if
> >> >> > using a
> >> >> > > VPN connection) nic's? Where N is the number of private networks.
> >> >> > And I would like to see N+3 as it will allocate another when a
> >> private
> >> >> > gateway is defined. That is why I proposed to pre-allocate this nic
> >> to be
> >> >> > able to predict mic-ids, i.e. eth<#>.
> >> >> >
> >> >> > >
> >> >> > > If so then my original question still holds in the sense that the
> >> nic's
> >> >> > > need to be created in the VM kernel based on the number of
> private
> >> >> > networks
> >> >> > > desired?
> >> >> >
> >> >> > Yes
> >> >> >
> >> >> > > I found the method update_System_Vm_Templates in the jar file
> >> >> > > Upgrade410to420 in cloud-engine-schema/src/com/cloud/upgrade/dao
> >> which
> >> >> > > seems to point to a set of pre-configured VM images.
> >> >> > I can not find the method you describe but these preconfigured
> >> images are
> >> >> > the ones used for all the system vms. That would be secondary
> storage
> >> >> vms,
> >> >> > console proxy vms and indeed the router vms.
> >> >> >
> >> >> > Based on the discussion above the the configuration part of the VPC
> >> >> redundant router is:
> >> >>
> >> >> 1. Collecting the correct data required to configure the nics. (Is
> >> this
> >> >> part already in the VPC setup code? I will look for it, pointers will
> >> be
> >> >> helpful.)
> >> >>
> >> >
> >> > vpc_guestgw.sh
> >> and VpcVirtualNetworkApplianceManager and -Impl and their ancestors
> >>
> >>
> >> >
> >> >
> >> >> 2. Based on the hypervisor/vm types configure the nic(s) on the
> >> router VM
> >> >> using the data collected above (Same question as in 1 above is this
> >> code
> >> >> already in place?). My guess is to start with a preconfigured
> template
> >> and
> >> >
> >> > configure the vm based on the number of nics and any other appropriate
> >> data.
> >> >>
> >> >
> >> > Yes.
> >> >
> >> >
> >> >> 3. Configuring conntrackd and keepalived after the router vm (nics)
> >> have
> >> >> been configured and the router(s) started or restarted? I still need
> to
> >> >> work through this.
> >> >>
> >> >
> >> > Likely you would need this.
> >> >
> >> > Don't know if keepalived can be start if there is no virtual IP
> >> definition.
> >> >
> >> > You also need to think about what to do second router(or the router
> >> pair)
> >> > when the last tier of VPC has been destroyed.
> >> >
> >> > --Sheng
> >> >
> >> >
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> >
> >> >> > >>
> >> >> > >>> If so, given the dynamic nature of the VPC redundant router
> >> >> > >>> configurations: Is using a setup_VPC_redundant_router bash
> >> function,
> >> >> > >>> similar to the existing open network function mentioned above,
> >> the
> >> >> > >>> most appropriate way to setup the keepalived or conntrackd
> >> >> > >>> configuration files for VPC redundant routers in the
> >> >> > >>> cloud-early-script? It seems to me reading the parameters from
> >> the
> >> >> > >>> kernel will require a unwieldy set of kernels to match the N
> >> private
> >> >> > >>> network redundant router pairs configured by the enduser.
> >> >> > >>>
> >> >> > >>>
> >> >> > >>> Comments, questions, clarifications?
> >> >> > >>
> >> >> > >>>
> >> >> > >>> Karl
> >> >> > >>>
> >> >> > >>>
> >> >> > >>> In the bash script ea
> >> >> > >>> On Mon, Jan 27, 2014 at 11:25 AM, Daan Hoogland <
> >> >> > daan.hoogland@gmail.com>
> >> >> > >> wrote:
> >> >> > >>>> 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.harris@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.hoogland@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
> >> >> > >>>>>> <sa...@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.hoogland@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
> >> >> > >>>>>>>> <sa...@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.harris@sungard.com
> >> >> > >>>>>>>>> wrote:
> >> >> > >>>>>>>>>
> >> >> > >>>>>>>>>> ---------- Forwarded message ----------
> >> >> > >>>>>>>>>> From: Daan Hoogland <da...@gmail.com>
> >> >> > >>>>>>>>>> Date: Wed, Jan 15, 2014 at 2:51 PM
> >> >> > >>>>>>>>>> Subject: Re: rvr4vpc
> >> >> > >>>>>>>>>> To: Karl Harris <ka...@sungard.com>
> >> >> > >>>>>>>>>> Cc: Christopher Litsinger <
> >> christopher.litsinge@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.harris@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.hoogland@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
> >> >> > >>>>
> >> >> > >>>
> >> >> > >>>
> >> >> > >>>
> >> >> > >>> --
> >> >> > >>> 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
> >> >>
> >>
> >>
> >>
> >> --
> >> Daan
> >>
> >>
> >
> >
> > --
> > Karl O. Harris
> > Cloud Software Engineer
> > Sungard Availability Services
> >
> >
>
>
> --
> Karl O. Harris
> Cloud Software Engineer
> Sungard Availability Services
>
Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual
Router for VPC email 2 of 2
Posted by Karl Harris <ka...@sungard.com>.
On Wed, Feb 12, 2014 at 9:38 AM, Karl Harris <ka...@sungard.com>wrote:
> Would implementing a VPC Redundant Router Network Guru using the an
> extension of the NetworkGuru interface be an appropriate way to create a
> VPC network with redundant routers. It seems that extending Network Guru
> interface or extending one of it's children eg the abstract class
> GuestNetworkGuru would be a appropriate design path.
>
> Comments?
>
> Karl
>
I know the configuration of the VM which implement the redundant routers
are handled via BASH scripts and the environment variables int the VM
images are used to configure the conntrackd and keepalived applications via
SED in bash scripts. I am looking for a clean way to pass the variable
number of NIC's and then generate the LINK and IGNORE configuration
commands for conntrackd.
The Network Guru mentioned above seemed like an interesting place to look,
even though it's used to work with the DAO's for the NetworkElements.
Karl
>
> On Mon, Feb 3, 2014 at 2:58 PM, Daan Hoogland <da...@gmail.com>wrote:
>
>> On Mon, Feb 3, 2014 at 8:50 PM, Sheng Yang <sh...@yasker.org> wrote:
>> > On Mon, Feb 3, 2014 at 11:27 AM, Karl Harris <karl.harris@sungard.com
>> >wrote:
>> >
>> >> On Mon, Feb 3, 2014 at 2:03 PM, Daan Hoogland <daan.hoogland@gmail.com
>> >> >wrote:
>> >>
>> >> >
>> >> > On 03 Feb 2014, at 19:45, Karl Harris <ka...@sungard.com>
>> wrote:
>> >> >
>> >> > > On Mon, Feb 3, 2014 at 12:54 PM, Daan Hoogland <
>> >> daan.hoogland@gmail.com
>> >> > >wrote:
>> >> > >
>> >> > >>
>> >> > >> On 03 Feb 2014, at 18:03, Karl Harris <ka...@sungard.com>
>> >> wrote:
>> >> > >>
>> >> > >>> After discussion with my colleagues questions about initial
>> >> > >>> configuration of the open network redundant routers and the
>> >> > >>> applicability of the existing bash scripts (cloud-early-config)
>> to
>> >> the
>> >> > >>> setup of VPC redundant routers have generated.
>> >> > >>>
>> >> > >>>
>> >> > >>> Some setup first: In the bash script cloud-early-config there is
>> a
>> >> > >>> function named setup_redundant_router which makes copies of
>> several
>> >> > >>> template files. The template files are used to configure
>> keepalived
>> >> > >>> and conntrackd. The template copies are edited, via sed editor,
>> using
>> >> > >>> environment variables ($ROUTER_PR, $ETH0_IP,$NAME, etc.) which
>> are
>> >> > >>> obtained from the kernel of the current running linux image
>> using the
>> >> > >>> virtual file system /proc/cmdline.
>> >> > >>>
>> >> > >>> I'm sure keepalived and conntrackd can be used for starting and
>> >> > >>> control of VPC redundant routers. However the setup of
>> keepalived and
>> >> > >>> conntrackd for VPC needs setup parameters which are dynamic
>> because a
>> >> > >>> VPC can have N number of redundant router pairs, not just the
>> fixed
>> >> > >>> number parsed from proc/cmdline in the running kernel.
>> >> > >>>
>> >> > >>> Am I correct in this analysis?
>> >> > >> Karl, I think not. There is only one router in a vac, it routes
>> for
>> >> all
>> >> > >> networks in the virtual private cloud. Am I misreading your
>> >> description.
>> >> > >
>> >> > > Ok then a VPC should contain a single router containing N+1 (N+2 if
>> >> > using a
>> >> > > VPN connection) nic's? Where N is the number of private networks.
>> >> > And I would like to see N+3 as it will allocate another when a
>> private
>> >> > gateway is defined. That is why I proposed to pre-allocate this nic
>> to be
>> >> > able to predict mic-ids, i.e. eth<#>.
>> >> >
>> >> > >
>> >> > > If so then my original question still holds in the sense that the
>> nic's
>> >> > > need to be created in the VM kernel based on the number of private
>> >> > networks
>> >> > > desired?
>> >> >
>> >> > Yes
>> >> >
>> >> > > I found the method update_System_Vm_Templates in the jar file
>> >> > > Upgrade410to420 in cloud-engine-schema/src/com/cloud/upgrade/dao
>> which
>> >> > > seems to point to a set of pre-configured VM images.
>> >> > I can not find the method you describe but these preconfigured
>> images are
>> >> > the ones used for all the system vms. That would be secondary storage
>> >> vms,
>> >> > console proxy vms and indeed the router vms.
>> >> >
>> >> > Based on the discussion above the the configuration part of the VPC
>> >> redundant router is:
>> >>
>> >> 1. Collecting the correct data required to configure the nics. (Is
>> this
>> >> part already in the VPC setup code? I will look for it, pointers will
>> be
>> >> helpful.)
>> >>
>> >
>> > vpc_guestgw.sh
>> and VpcVirtualNetworkApplianceManager and -Impl and their ancestors
>>
>>
>> >
>> >
>> >> 2. Based on the hypervisor/vm types configure the nic(s) on the
>> router VM
>> >> using the data collected above (Same question as in 1 above is this
>> code
>> >> already in place?). My guess is to start with a preconfigured template
>> and
>> >
>> > configure the vm based on the number of nics and any other appropriate
>> data.
>> >>
>> >
>> > Yes.
>> >
>> >
>> >> 3. Configuring conntrackd and keepalived after the router vm (nics)
>> have
>> >> been configured and the router(s) started or restarted? I still need to
>> >> work through this.
>> >>
>> >
>> > Likely you would need this.
>> >
>> > Don't know if keepalived can be start if there is no virtual IP
>> definition.
>> >
>> > You also need to think about what to do second router(or the router
>> pair)
>> > when the last tier of VPC has been destroyed.
>> >
>> > --Sheng
>> >
>> >
>> >>
>> >>
>> >>
>> >>
>> >> >
>> >> > >>
>> >> > >>> If so, given the dynamic nature of the VPC redundant router
>> >> > >>> configurations: Is using a setup_VPC_redundant_router bash
>> function,
>> >> > >>> similar to the existing open network function mentioned above,
>> the
>> >> > >>> most appropriate way to setup the keepalived or conntrackd
>> >> > >>> configuration files for VPC redundant routers in the
>> >> > >>> cloud-early-script? It seems to me reading the parameters from
>> the
>> >> > >>> kernel will require a unwieldy set of kernels to match the N
>> private
>> >> > >>> network redundant router pairs configured by the enduser.
>> >> > >>>
>> >> > >>>
>> >> > >>> Comments, questions, clarifications?
>> >> > >>
>> >> > >>>
>> >> > >>> Karl
>> >> > >>>
>> >> > >>>
>> >> > >>> In the bash script ea
>> >> > >>> On Mon, Jan 27, 2014 at 11:25 AM, Daan Hoogland <
>> >> > daan.hoogland@gmail.com>
>> >> > >> wrote:
>> >> > >>>> 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.harris@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.hoogland@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
>> >> > >>>>>> <sa...@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.hoogland@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
>> >> > >>>>>>>> <sa...@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.harris@sungard.com
>> >> > >>>>>>>>> wrote:
>> >> > >>>>>>>>>
>> >> > >>>>>>>>>> ---------- Forwarded message ----------
>> >> > >>>>>>>>>> From: Daan Hoogland <da...@gmail.com>
>> >> > >>>>>>>>>> Date: Wed, Jan 15, 2014 at 2:51 PM
>> >> > >>>>>>>>>> Subject: Re: rvr4vpc
>> >> > >>>>>>>>>> To: Karl Harris <ka...@sungard.com>
>> >> > >>>>>>>>>> Cc: Christopher Litsinger <
>> christopher.litsinge@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.harris@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.hoogland@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
>> >> > >>>>
>> >> > >>>
>> >> > >>>
>> >> > >>>
>> >> > >>> --
>> >> > >>> 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
>> >>
>>
>>
>>
>> --
>> Daan
>>
>>
>
>
> --
> Karl O. Harris
> Cloud Software Engineer
> Sungard Availability Services
>
>
--
Karl O. Harris
Cloud Software Engineer
Sungard Availability Services
Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual
Router for VPC email 2 of 2
Posted by Karl Harris <ka...@sungard.com>.
Would implementing a VPC Redundant Router Network Guru using the an
extension of the NetworkGuru interface be an appropriate way to create a
VPC network with redundant routers. It seems that extending Network Guru
interface or extending one of it's children eg the abstract class
GuestNetworkGuru would be a appropriate design path.
Comments?
Karl
On Mon, Feb 3, 2014 at 2:58 PM, Daan Hoogland <da...@gmail.com>wrote:
> On Mon, Feb 3, 2014 at 8:50 PM, Sheng Yang <sh...@yasker.org> wrote:
> > On Mon, Feb 3, 2014 at 11:27 AM, Karl Harris <karl.harris@sungard.com
> >wrote:
> >
> >> On Mon, Feb 3, 2014 at 2:03 PM, Daan Hoogland <daan.hoogland@gmail.com
> >> >wrote:
> >>
> >> >
> >> > On 03 Feb 2014, at 19:45, Karl Harris <ka...@sungard.com>
> wrote:
> >> >
> >> > > On Mon, Feb 3, 2014 at 12:54 PM, Daan Hoogland <
> >> daan.hoogland@gmail.com
> >> > >wrote:
> >> > >
> >> > >>
> >> > >> On 03 Feb 2014, at 18:03, Karl Harris <ka...@sungard.com>
> >> wrote:
> >> > >>
> >> > >>> After discussion with my colleagues questions about initial
> >> > >>> configuration of the open network redundant routers and the
> >> > >>> applicability of the existing bash scripts (cloud-early-config) to
> >> the
> >> > >>> setup of VPC redundant routers have generated.
> >> > >>>
> >> > >>>
> >> > >>> Some setup first: In the bash script cloud-early-config there is a
> >> > >>> function named setup_redundant_router which makes copies of
> several
> >> > >>> template files. The template files are used to configure
> keepalived
> >> > >>> and conntrackd. The template copies are edited, via sed editor,
> using
> >> > >>> environment variables ($ROUTER_PR, $ETH0_IP,$NAME, etc.) which
> are
> >> > >>> obtained from the kernel of the current running linux image using
> the
> >> > >>> virtual file system /proc/cmdline.
> >> > >>>
> >> > >>> I'm sure keepalived and conntrackd can be used for starting and
> >> > >>> control of VPC redundant routers. However the setup of keepalived
> and
> >> > >>> conntrackd for VPC needs setup parameters which are dynamic
> because a
> >> > >>> VPC can have N number of redundant router pairs, not just the
> fixed
> >> > >>> number parsed from proc/cmdline in the running kernel.
> >> > >>>
> >> > >>> Am I correct in this analysis?
> >> > >> Karl, I think not. There is only one router in a vac, it routes for
> >> all
> >> > >> networks in the virtual private cloud. Am I misreading your
> >> description.
> >> > >
> >> > > Ok then a VPC should contain a single router containing N+1 (N+2 if
> >> > using a
> >> > > VPN connection) nic's? Where N is the number of private networks.
> >> > And I would like to see N+3 as it will allocate another when a private
> >> > gateway is defined. That is why I proposed to pre-allocate this nic
> to be
> >> > able to predict mic-ids, i.e. eth<#>.
> >> >
> >> > >
> >> > > If so then my original question still holds in the sense that the
> nic's
> >> > > need to be created in the VM kernel based on the number of private
> >> > networks
> >> > > desired?
> >> >
> >> > Yes
> >> >
> >> > > I found the method update_System_Vm_Templates in the jar file
> >> > > Upgrade410to420 in cloud-engine-schema/src/com/cloud/upgrade/dao
> which
> >> > > seems to point to a set of pre-configured VM images.
> >> > I can not find the method you describe but these preconfigured images
> are
> >> > the ones used for all the system vms. That would be secondary storage
> >> vms,
> >> > console proxy vms and indeed the router vms.
> >> >
> >> > Based on the discussion above the the configuration part of the VPC
> >> redundant router is:
> >>
> >> 1. Collecting the correct data required to configure the nics. (Is this
> >> part already in the VPC setup code? I will look for it, pointers will be
> >> helpful.)
> >>
> >
> > vpc_guestgw.sh
> and VpcVirtualNetworkApplianceManager and -Impl and their ancestors
>
>
> >
> >
> >> 2. Based on the hypervisor/vm types configure the nic(s) on the router
> VM
> >> using the data collected above (Same question as in 1 above is this code
> >> already in place?). My guess is to start with a preconfigured template
> and
> >
> > configure the vm based on the number of nics and any other appropriate
> data.
> >>
> >
> > Yes.
> >
> >
> >> 3. Configuring conntrackd and keepalived after the router vm (nics)
> have
> >> been configured and the router(s) started or restarted? I still need to
> >> work through this.
> >>
> >
> > Likely you would need this.
> >
> > Don't know if keepalived can be start if there is no virtual IP
> definition.
> >
> > You also need to think about what to do second router(or the router pair)
> > when the last tier of VPC has been destroyed.
> >
> > --Sheng
> >
> >
> >>
> >>
> >>
> >>
> >> >
> >> > >>
> >> > >>> If so, given the dynamic nature of the VPC redundant router
> >> > >>> configurations: Is using a setup_VPC_redundant_router bash
> function,
> >> > >>> similar to the existing open network function mentioned above, the
> >> > >>> most appropriate way to setup the keepalived or conntrackd
> >> > >>> configuration files for VPC redundant routers in the
> >> > >>> cloud-early-script? It seems to me reading the parameters from the
> >> > >>> kernel will require a unwieldy set of kernels to match the N
> private
> >> > >>> network redundant router pairs configured by the enduser.
> >> > >>>
> >> > >>>
> >> > >>> Comments, questions, clarifications?
> >> > >>
> >> > >>>
> >> > >>> Karl
> >> > >>>
> >> > >>>
> >> > >>> In the bash script ea
> >> > >>> On Mon, Jan 27, 2014 at 11:25 AM, Daan Hoogland <
> >> > daan.hoogland@gmail.com>
> >> > >> wrote:
> >> > >>>> 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.harris@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.hoogland@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
> >> > >>>>>> <sa...@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.hoogland@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
> >> > >>>>>>>> <sa...@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.harris@sungard.com
> >> > >>>>>>>>> wrote:
> >> > >>>>>>>>>
> >> > >>>>>>>>>> ---------- Forwarded message ----------
> >> > >>>>>>>>>> From: Daan Hoogland <da...@gmail.com>
> >> > >>>>>>>>>> Date: Wed, Jan 15, 2014 at 2:51 PM
> >> > >>>>>>>>>> Subject: Re: rvr4vpc
> >> > >>>>>>>>>> To: Karl Harris <ka...@sungard.com>
> >> > >>>>>>>>>> Cc: Christopher Litsinger <
> christopher.litsinge@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.harris@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.hoogland@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
> >> > >>>>
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>> --
> >> > >>> 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
> >>
>
>
>
> --
> Daan
>
>
--
Karl O. Harris
Cloud Software Engineer
Sungard Availability Services
Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual
Router for VPC email 2 of 2
Posted by Daan Hoogland <da...@gmail.com>.
On Mon, Feb 3, 2014 at 8:50 PM, Sheng Yang <sh...@yasker.org> wrote:
> On Mon, Feb 3, 2014 at 11:27 AM, Karl Harris <ka...@sungard.com>wrote:
>
>> On Mon, Feb 3, 2014 at 2:03 PM, Daan Hoogland <daan.hoogland@gmail.com
>> >wrote:
>>
>> >
>> > On 03 Feb 2014, at 19:45, Karl Harris <ka...@sungard.com> wrote:
>> >
>> > > On Mon, Feb 3, 2014 at 12:54 PM, Daan Hoogland <
>> daan.hoogland@gmail.com
>> > >wrote:
>> > >
>> > >>
>> > >> On 03 Feb 2014, at 18:03, Karl Harris <ka...@sungard.com>
>> wrote:
>> > >>
>> > >>> After discussion with my colleagues questions about initial
>> > >>> configuration of the open network redundant routers and the
>> > >>> applicability of the existing bash scripts (cloud-early-config) to
>> the
>> > >>> setup of VPC redundant routers have generated.
>> > >>>
>> > >>>
>> > >>> Some setup first: In the bash script cloud-early-config there is a
>> > >>> function named setup_redundant_router which makes copies of several
>> > >>> template files. The template files are used to configure keepalived
>> > >>> and conntrackd. The template copies are edited, via sed editor, using
>> > >>> environment variables ($ROUTER_PR, $ETH0_IP,$NAME, etc.) which are
>> > >>> obtained from the kernel of the current running linux image using the
>> > >>> virtual file system /proc/cmdline.
>> > >>>
>> > >>> I'm sure keepalived and conntrackd can be used for starting and
>> > >>> control of VPC redundant routers. However the setup of keepalived and
>> > >>> conntrackd for VPC needs setup parameters which are dynamic because a
>> > >>> VPC can have N number of redundant router pairs, not just the fixed
>> > >>> number parsed from proc/cmdline in the running kernel.
>> > >>>
>> > >>> Am I correct in this analysis?
>> > >> Karl, I think not. There is only one router in a vac, it routes for
>> all
>> > >> networks in the virtual private cloud. Am I misreading your
>> description.
>> > >
>> > > Ok then a VPC should contain a single router containing N+1 (N+2 if
>> > using a
>> > > VPN connection) nic's? Where N is the number of private networks.
>> > And I would like to see N+3 as it will allocate another when a private
>> > gateway is defined. That is why I proposed to pre-allocate this nic to be
>> > able to predict mic-ids, i.e. eth<#>.
>> >
>> > >
>> > > If so then my original question still holds in the sense that the nic's
>> > > need to be created in the VM kernel based on the number of private
>> > networks
>> > > desired?
>> >
>> > Yes
>> >
>> > > I found the method update_System_Vm_Templates in the jar file
>> > > Upgrade410to420 in cloud-engine-schema/src/com/cloud/upgrade/dao which
>> > > seems to point to a set of pre-configured VM images.
>> > I can not find the method you describe but these preconfigured images are
>> > the ones used for all the system vms. That would be secondary storage
>> vms,
>> > console proxy vms and indeed the router vms.
>> >
>> > Based on the discussion above the the configuration part of the VPC
>> redundant router is:
>>
>> 1. Collecting the correct data required to configure the nics. (Is this
>> part already in the VPC setup code? I will look for it, pointers will be
>> helpful.)
>>
>
> vpc_guestgw.sh
and VpcVirtualNetworkApplianceManager and -Impl and their ancestors
>
>
>> 2. Based on the hypervisor/vm types configure the nic(s) on the router VM
>> using the data collected above (Same question as in 1 above is this code
>> already in place?). My guess is to start with a preconfigured template and
>
> configure the vm based on the number of nics and any other appropriate data.
>>
>
> Yes.
>
>
>> 3. Configuring conntrackd and keepalived after the router vm (nics) have
>> been configured and the router(s) started or restarted? I still need to
>> work through this.
>>
>
> Likely you would need this.
>
> Don't know if keepalived can be start if there is no virtual IP definition.
>
> You also need to think about what to do second router(or the router pair)
> when the last tier of VPC has been destroyed.
>
> --Sheng
>
>
>>
>>
>>
>>
>> >
>> > >>
>> > >>> If so, given the dynamic nature of the VPC redundant router
>> > >>> configurations: Is using a setup_VPC_redundant_router bash function,
>> > >>> similar to the existing open network function mentioned above, the
>> > >>> most appropriate way to setup the keepalived or conntrackd
>> > >>> configuration files for VPC redundant routers in the
>> > >>> cloud-early-script? It seems to me reading the parameters from the
>> > >>> kernel will require a unwieldy set of kernels to match the N private
>> > >>> network redundant router pairs configured by the enduser.
>> > >>>
>> > >>>
>> > >>> Comments, questions, clarifications?
>> > >>
>> > >>>
>> > >>> Karl
>> > >>>
>> > >>>
>> > >>> In the bash script ea
>> > >>> On Mon, Jan 27, 2014 at 11:25 AM, Daan Hoogland <
>> > daan.hoogland@gmail.com>
>> > >> wrote:
>> > >>>> 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.harris@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.hoogland@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
>> > >>>>>> <sa...@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.hoogland@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
>> > >>>>>>>> <sa...@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.harris@sungard.com
>> > >>>>>>>>> wrote:
>> > >>>>>>>>>
>> > >>>>>>>>>> ---------- Forwarded message ----------
>> > >>>>>>>>>> From: Daan Hoogland <da...@gmail.com>
>> > >>>>>>>>>> Date: Wed, Jan 15, 2014 at 2:51 PM
>> > >>>>>>>>>> Subject: Re: rvr4vpc
>> > >>>>>>>>>> To: Karl Harris <ka...@sungard.com>
>> > >>>>>>>>>> Cc: Christopher Litsinger <ch...@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.harris@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.hoogland@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
>> > >>>>
>> > >>>
>> > >>>
>> > >>>
>> > >>> --
>> > >>> 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
>>
--
Daan
Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual
Router for VPC email 2 of 2
Posted by Sheng Yang <sh...@yasker.org>.
On Mon, Feb 3, 2014 at 11:27 AM, Karl Harris <ka...@sungard.com>wrote:
> On Mon, Feb 3, 2014 at 2:03 PM, Daan Hoogland <daan.hoogland@gmail.com
> >wrote:
>
> >
> > On 03 Feb 2014, at 19:45, Karl Harris <ka...@sungard.com> wrote:
> >
> > > On Mon, Feb 3, 2014 at 12:54 PM, Daan Hoogland <
> daan.hoogland@gmail.com
> > >wrote:
> > >
> > >>
> > >> On 03 Feb 2014, at 18:03, Karl Harris <ka...@sungard.com>
> wrote:
> > >>
> > >>> After discussion with my colleagues questions about initial
> > >>> configuration of the open network redundant routers and the
> > >>> applicability of the existing bash scripts (cloud-early-config) to
> the
> > >>> setup of VPC redundant routers have generated.
> > >>>
> > >>>
> > >>> Some setup first: In the bash script cloud-early-config there is a
> > >>> function named setup_redundant_router which makes copies of several
> > >>> template files. The template files are used to configure keepalived
> > >>> and conntrackd. The template copies are edited, via sed editor, using
> > >>> environment variables ($ROUTER_PR, $ETH0_IP,$NAME, etc.) which are
> > >>> obtained from the kernel of the current running linux image using the
> > >>> virtual file system /proc/cmdline.
> > >>>
> > >>> I'm sure keepalived and conntrackd can be used for starting and
> > >>> control of VPC redundant routers. However the setup of keepalived and
> > >>> conntrackd for VPC needs setup parameters which are dynamic because a
> > >>> VPC can have N number of redundant router pairs, not just the fixed
> > >>> number parsed from proc/cmdline in the running kernel.
> > >>>
> > >>> Am I correct in this analysis?
> > >> Karl, I think not. There is only one router in a vac, it routes for
> all
> > >> networks in the virtual private cloud. Am I misreading your
> description.
> > >
> > > Ok then a VPC should contain a single router containing N+1 (N+2 if
> > using a
> > > VPN connection) nic's? Where N is the number of private networks.
> > And I would like to see N+3 as it will allocate another when a private
> > gateway is defined. That is why I proposed to pre-allocate this nic to be
> > able to predict mic-ids, i.e. eth<#>.
> >
> > >
> > > If so then my original question still holds in the sense that the nic's
> > > need to be created in the VM kernel based on the number of private
> > networks
> > > desired?
> >
> > Yes
> >
> > > I found the method update_System_Vm_Templates in the jar file
> > > Upgrade410to420 in cloud-engine-schema/src/com/cloud/upgrade/dao which
> > > seems to point to a set of pre-configured VM images.
> > I can not find the method you describe but these preconfigured images are
> > the ones used for all the system vms. That would be secondary storage
> vms,
> > console proxy vms and indeed the router vms.
> >
> > Based on the discussion above the the configuration part of the VPC
> redundant router is:
>
> 1. Collecting the correct data required to configure the nics. (Is this
> part already in the VPC setup code? I will look for it, pointers will be
> helpful.)
>
vpc_guestgw.sh
> 2. Based on the hypervisor/vm types configure the nic(s) on the router VM
> using the data collected above (Same question as in 1 above is this code
> already in place?). My guess is to start with a preconfigured template and
configure the vm based on the number of nics and any other appropriate data.
>
Yes.
> 3. Configuring conntrackd and keepalived after the router vm (nics) have
> been configured and the router(s) started or restarted? I still need to
> work through this.
>
Likely you would need this.
Don't know if keepalived can be start if there is no virtual IP definition.
You also need to think about what to do second router(or the router pair)
when the last tier of VPC has been destroyed.
--Sheng
>
>
>
>
> >
> > >>
> > >>> If so, given the dynamic nature of the VPC redundant router
> > >>> configurations: Is using a setup_VPC_redundant_router bash function,
> > >>> similar to the existing open network function mentioned above, the
> > >>> most appropriate way to setup the keepalived or conntrackd
> > >>> configuration files for VPC redundant routers in the
> > >>> cloud-early-script? It seems to me reading the parameters from the
> > >>> kernel will require a unwieldy set of kernels to match the N private
> > >>> network redundant router pairs configured by the enduser.
> > >>>
> > >>>
> > >>> Comments, questions, clarifications?
> > >>
> > >>>
> > >>> Karl
> > >>>
> > >>>
> > >>> In the bash script ea
> > >>> On Mon, Jan 27, 2014 at 11:25 AM, Daan Hoogland <
> > daan.hoogland@gmail.com>
> > >> wrote:
> > >>>> 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.harris@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.hoogland@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
> > >>>>>> <sa...@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.hoogland@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
> > >>>>>>>> <sa...@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.harris@sungard.com
> > >>>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> ---------- Forwarded message ----------
> > >>>>>>>>>> From: Daan Hoogland <da...@gmail.com>
> > >>>>>>>>>> Date: Wed, Jan 15, 2014 at 2:51 PM
> > >>>>>>>>>> Subject: Re: rvr4vpc
> > >>>>>>>>>> To: Karl Harris <ka...@sungard.com>
> > >>>>>>>>>> Cc: Christopher Litsinger <ch...@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.harris@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.hoogland@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
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> 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
>
Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual
Router for VPC email 2 of 2
Posted by Karl Harris <ka...@sungard.com>.
On Mon, Feb 3, 2014 at 2:03 PM, Daan Hoogland <da...@gmail.com>wrote:
>
> On 03 Feb 2014, at 19:45, Karl Harris <ka...@sungard.com> wrote:
>
> > On Mon, Feb 3, 2014 at 12:54 PM, Daan Hoogland <daan.hoogland@gmail.com
> >wrote:
> >
> >>
> >> On 03 Feb 2014, at 18:03, Karl Harris <ka...@sungard.com> wrote:
> >>
> >>> After discussion with my colleagues questions about initial
> >>> configuration of the open network redundant routers and the
> >>> applicability of the existing bash scripts (cloud-early-config) to the
> >>> setup of VPC redundant routers have generated.
> >>>
> >>>
> >>> Some setup first: In the bash script cloud-early-config there is a
> >>> function named setup_redundant_router which makes copies of several
> >>> template files. The template files are used to configure keepalived
> >>> and conntrackd. The template copies are edited, via sed editor, using
> >>> environment variables ($ROUTER_PR, $ETH0_IP,$NAME, etc.) which are
> >>> obtained from the kernel of the current running linux image using the
> >>> virtual file system /proc/cmdline.
> >>>
> >>> I'm sure keepalived and conntrackd can be used for starting and
> >>> control of VPC redundant routers. However the setup of keepalived and
> >>> conntrackd for VPC needs setup parameters which are dynamic because a
> >>> VPC can have N number of redundant router pairs, not just the fixed
> >>> number parsed from proc/cmdline in the running kernel.
> >>>
> >>> Am I correct in this analysis?
> >> Karl, I think not. There is only one router in a vac, it routes for all
> >> networks in the virtual private cloud. Am I misreading your description.
> >
> > Ok then a VPC should contain a single router containing N+1 (N+2 if
> using a
> > VPN connection) nic's? Where N is the number of private networks.
> And I would like to see N+3 as it will allocate another when a private
> gateway is defined. That is why I proposed to pre-allocate this nic to be
> able to predict mic-ids, i.e. eth<#>.
>
> >
> > If so then my original question still holds in the sense that the nic's
> > need to be created in the VM kernel based on the number of private
> networks
> > desired?
>
> Yes
>
> > I found the method update_System_Vm_Templates in the jar file
> > Upgrade410to420 in cloud-engine-schema/src/com/cloud/upgrade/dao which
> > seems to point to a set of pre-configured VM images.
> I can not find the method you describe but these preconfigured images are
> the ones used for all the system vms. That would be secondary storage vms,
> console proxy vms and indeed the router vms.
>
> Based on the discussion above the the configuration part of the VPC
redundant router is:
1. Collecting the correct data required to configure the nics. (Is this
part already in the VPC setup code? I will look for it, pointers will be
helpful.)
2. Based on the hypervisor/vm types configure the nic(s) on the router VM
using the data collected above (Same question as in 1 above is this code
already in place?). My guess is to start with a preconfigured template and
configure the vm based on the number of nics and any other appropriate data.
3. Configuring conntrackd and keepalived after the router vm (nics) have
been configured and the router(s) started or restarted? I still need to
work through this.
>
> >>
> >>> If so, given the dynamic nature of the VPC redundant router
> >>> configurations: Is using a setup_VPC_redundant_router bash function,
> >>> similar to the existing open network function mentioned above, the
> >>> most appropriate way to setup the keepalived or conntrackd
> >>> configuration files for VPC redundant routers in the
> >>> cloud-early-script? It seems to me reading the parameters from the
> >>> kernel will require a unwieldy set of kernels to match the N private
> >>> network redundant router pairs configured by the enduser.
> >>>
> >>>
> >>> Comments, questions, clarifications?
> >>
> >>>
> >>> Karl
> >>>
> >>>
> >>> In the bash script ea
> >>> On Mon, Jan 27, 2014 at 11:25 AM, Daan Hoogland <
> daan.hoogland@gmail.com>
> >> wrote:
> >>>> 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.harris@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.hoogland@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
> >>>>>> <sa...@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.hoogland@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
> >>>>>>>> <sa...@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.harris@sungard.com
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> ---------- Forwarded message ----------
> >>>>>>>>>> From: Daan Hoogland <da...@gmail.com>
> >>>>>>>>>> Date: Wed, Jan 15, 2014 at 2:51 PM
> >>>>>>>>>> Subject: Re: rvr4vpc
> >>>>>>>>>> To: Karl Harris <ka...@sungard.com>
> >>>>>>>>>> Cc: Christopher Litsinger <ch...@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.harris@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.hoogland@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
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> 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
Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual Router for VPC email 2 of 2
Posted by Daan Hoogland <da...@gmail.com>.
On 03 Feb 2014, at 19:45, Karl Harris <ka...@sungard.com> wrote:
> On Mon, Feb 3, 2014 at 12:54 PM, Daan Hoogland <da...@gmail.com>wrote:
>
>>
>> On 03 Feb 2014, at 18:03, Karl Harris <ka...@sungard.com> wrote:
>>
>>> After discussion with my colleagues questions about initial
>>> configuration of the open network redundant routers and the
>>> applicability of the existing bash scripts (cloud-early-config) to the
>>> setup of VPC redundant routers have generated.
>>>
>>>
>>> Some setup first: In the bash script cloud-early-config there is a
>>> function named setup_redundant_router which makes copies of several
>>> template files. The template files are used to configure keepalived
>>> and conntrackd. The template copies are edited, via sed editor, using
>>> environment variables ($ROUTER_PR, $ETH0_IP,$NAME, etc.) which are
>>> obtained from the kernel of the current running linux image using the
>>> virtual file system /proc/cmdline.
>>>
>>> I'm sure keepalived and conntrackd can be used for starting and
>>> control of VPC redundant routers. However the setup of keepalived and
>>> conntrackd for VPC needs setup parameters which are dynamic because a
>>> VPC can have N number of redundant router pairs, not just the fixed
>>> number parsed from proc/cmdline in the running kernel.
>>>
>>> Am I correct in this analysis?
>> Karl, I think not. There is only one router in a vac, it routes for all
>> networks in the virtual private cloud. Am I misreading your description.
>
> Ok then a VPC should contain a single router containing N+1 (N+2 if using a
> VPN connection) nic's? Where N is the number of private networks.
And I would like to see N+3 as it will allocate another when a private gateway is defined. That is why I proposed to pre-allocate this nic to be able to predict mic-ids, i.e. eth<#>.
>
> If so then my original question still holds in the sense that the nic's
> need to be created in the VM kernel based on the number of private networks
> desired?
Yes
> I found the method update_System_Vm_Templates in the jar file
> Upgrade410to420 in cloud-engine-schema/src/com/cloud/upgrade/dao which
> seems to point to a set of pre-configured VM images.
I can not find the method you describe but these preconfigured images are the ones used for all the system vms. That would be secondary storage vms, console proxy vms and indeed the router vms.
>
>>
>>> If so, given the dynamic nature of the VPC redundant router
>>> configurations: Is using a setup_VPC_redundant_router bash function,
>>> similar to the existing open network function mentioned above, the
>>> most appropriate way to setup the keepalived or conntrackd
>>> configuration files for VPC redundant routers in the
>>> cloud-early-script? It seems to me reading the parameters from the
>>> kernel will require a unwieldy set of kernels to match the N private
>>> network redundant router pairs configured by the enduser.
>>>
>>>
>>> Comments, questions, clarifications?
>>
>>>
>>> Karl
>>>
>>>
>>> In the bash script ea
>>> On Mon, Jan 27, 2014 at 11:25 AM, Daan Hoogland <da...@gmail.com>
>> wrote:
>>>> 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 <ka...@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.hoogland@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
>>>>>> <sa...@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.hoogland@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
>>>>>>>> <sa...@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.harris@sungard.com
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>>> From: Daan Hoogland <da...@gmail.com>
>>>>>>>>>> Date: Wed, Jan 15, 2014 at 2:51 PM
>>>>>>>>>> Subject: Re: rvr4vpc
>>>>>>>>>> To: Karl Harris <ka...@sungard.com>
>>>>>>>>>> Cc: Christopher Litsinger <ch...@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.harris@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.hoogland@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
>>>>
>>>
>>>
>>>
>>> --
>>> Karl O. Harris
>>> Cloud Software Engineer
>>> Sungard Availability Services
>>
>>
>>
>
>
> --
> Karl O. Harris
> Cloud Software Engineer
> Sungard Availability Services
Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual
Router for VPC email 2 of 2
Posted by Karl Harris <ka...@sungard.com>.
On Mon, Feb 3, 2014 at 12:54 PM, Daan Hoogland <da...@gmail.com>wrote:
>
> On 03 Feb 2014, at 18:03, Karl Harris <ka...@sungard.com> wrote:
>
> > After discussion with my colleagues questions about initial
> > configuration of the open network redundant routers and the
> > applicability of the existing bash scripts (cloud-early-config) to the
> > setup of VPC redundant routers have generated.
> >
> >
> > Some setup first: In the bash script cloud-early-config there is a
> > function named setup_redundant_router which makes copies of several
> > template files. The template files are used to configure keepalived
> > and conntrackd. The template copies are edited, via sed editor, using
> > environment variables ($ROUTER_PR, $ETH0_IP,$NAME, etc.) which are
> > obtained from the kernel of the current running linux image using the
> > virtual file system /proc/cmdline.
> >
> > I'm sure keepalived and conntrackd can be used for starting and
> > control of VPC redundant routers. However the setup of keepalived and
> > conntrackd for VPC needs setup parameters which are dynamic because a
> > VPC can have N number of redundant router pairs, not just the fixed
> > number parsed from proc/cmdline in the running kernel.
> >
> > Am I correct in this analysis?
> Karl, I think not. There is only one router in a vac, it routes for all
> networks in the virtual private cloud. Am I misreading your description.
Ok then a VPC should contain a single router containing N+1 (N+2 if using a
VPN connection) nic's? Where N is the number of private networks.
If so then my original question still holds in the sense that the nic's
need to be created in the VM kernel based on the number of private networks
desired? I found the method update_System_Vm_Templates in the jar file
Upgrade410to420 in cloud-engine-schema/src/com/cloud/upgrade/dao which
seems to point to a set of pre-configured VM images.
>
> > If so, given the dynamic nature of the VPC redundant router
> > configurations: Is using a setup_VPC_redundant_router bash function,
> > similar to the existing open network function mentioned above, the
> > most appropriate way to setup the keepalived or conntrackd
> > configuration files for VPC redundant routers in the
> > cloud-early-script? It seems to me reading the parameters from the
> > kernel will require a unwieldy set of kernels to match the N private
> > network redundant router pairs configured by the enduser.
> >
> >
> > Comments, questions, clarifications?
>
> >
> > Karl
> >
> >
> > In the bash script ea
> > On Mon, Jan 27, 2014 at 11:25 AM, Daan Hoogland <da...@gmail.com>
> wrote:
> >> 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 <ka...@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.hoogland@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
> >>>> <sa...@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.hoogland@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
> >>>>>> <sa...@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.harris@sungard.com
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> ---------- Forwarded message ----------
> >>>>>>>> From: Daan Hoogland <da...@gmail.com>
> >>>>>>>> Date: Wed, Jan 15, 2014 at 2:51 PM
> >>>>>>>> Subject: Re: rvr4vpc
> >>>>>>>> To: Karl Harris <ka...@sungard.com>
> >>>>>>>> Cc: Christopher Litsinger <ch...@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.harris@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.hoogland@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
> >>
> >
> >
> >
> > --
> > Karl O. Harris
> > Cloud Software Engineer
> > Sungard Availability Services
>
>
>
--
Karl O. Harris
Cloud Software Engineer
Sungard Availability Services
Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual Router for VPC email 2 of 2
Posted by Daan Hoogland <da...@gmail.com>.
On 03 Feb 2014, at 18:03, Karl Harris <ka...@sungard.com> wrote:
> After discussion with my colleagues questions about initial
> configuration of the open network redundant routers and the
> applicability of the existing bash scripts (cloud-early-config) to the
> setup of VPC redundant routers have generated.
>
>
> Some setup first: In the bash script cloud-early-config there is a
> function named setup_redundant_router which makes copies of several
> template files. The template files are used to configure keepalived
> and conntrackd. The template copies are edited, via sed editor, using
> environment variables ($ROUTER_PR, $ETH0_IP,$NAME, etc.) which are
> obtained from the kernel of the current running linux image using the
> virtual file system /proc/cmdline.
>
> I'm sure keepalived and conntrackd can be used for starting and
> control of VPC redundant routers. However the setup of keepalived and
> conntrackd for VPC needs setup parameters which are dynamic because a
> VPC can have N number of redundant router pairs, not just the fixed
> number parsed from proc/cmdline in the running kernel.
>
> Am I correct in this analysis?
Karl, I think not. There is only one router in a vac, it routes for all networks in the virtual private cloud. Am I misreading your description?
>
> If so, given the dynamic nature of the VPC redundant router
> configurations: Is using a setup_VPC_redundant_router bash function,
> similar to the existing open network function mentioned above, the
> most appropriate way to setup the keepalived or conntrackd
> configuration files for VPC redundant routers in the
> cloud-early-script? It seems to me reading the parameters from the
> kernel will require a unwieldy set of kernels to match the N private
> network redundant router pairs configured by the enduser.
>
>
> Comments, questions, clarifications?
>
> Karl
>
>
> In the bash script ea
> On Mon, Jan 27, 2014 at 11:25 AM, Daan Hoogland <da...@gmail.com> wrote:
>> 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 <ka...@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 <da...@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
>>>> <sa...@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 <da...@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
>>>>>> <sa...@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.harris@sungard.com
>>>>>>> wrote:
>>>>>>>
>>>>>>>> ---------- Forwarded message ----------
>>>>>>>> From: Daan Hoogland <da...@gmail.com>
>>>>>>>> Date: Wed, Jan 15, 2014 at 2:51 PM
>>>>>>>> Subject: Re: rvr4vpc
>>>>>>>> To: Karl Harris <ka...@sungard.com>
>>>>>>>> Cc: Christopher Litsinger <ch...@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 <ka...@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.hoogland@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
>>
>
>
>
> --
> Karl O. Harris
> Cloud Software Engineer
> Sungard Availability Services