You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Kishan Kavala <Ki...@citrix.com> on 2013/10/03 13:47:57 UTC
[Proposal] Improve VR upgrades
During CS upgrade, VRs are required to be upgraded to use newer systemVm template .
The current VR upgrade procedure has following limitations:
- takes 'long' time and the time exponentially increases with the size of the cloud
- no way to sequence upgrade of different parts of the cloud, i.e., specific clusters or pods or even zones
- there is no way to determine when a particular customer's services (e.g. VR) will be upgraded with the upgrade interval
Goals for this feature are to address the above issues
1. Give admin control to sequence the upgrade of the cloud by:
- Infrastructure hierarchy: by Cluster, Pod, and Zone etc.
- Administrative hierarchy: by Tenant or Domain
2. Minimize service interruption to users
3. Improve the speed of the upgrade time by making as many upgrade operations in parallel as possible
I've created JIRA ticket:
https://issues.apache.org/jira/browse/CLOUDSTACK-4793
thanks,
Kishan
Re: [Proposal] Improve VR upgrades
Posted by Daan Hoogland <da...@gmail.com>.
looks alright Kishan,
two litle remarks
Alex is mentioning redundant router. Can we add some kind of spec that
the redundant pair is guaranteed not to be upgraded at the same time?
As for the downloading the template to primary storage before
rebooting; I think it is safe to download it to all primary storage
immediately without regard.
On Wed, Oct 23, 2013 at 6:46 PM, Alex Huang <Al...@citrix.com> wrote:
> +1. That's the way to do it with no downtime. Tighter control needs to be formed on the VR to VR version compatibility though. It's one reason I always support that we break VR into smaller pieces. Redundant VRs work great as routing but then if you have to handle DHCP, DNS, Load Balancing, and others with it then it becomes orders of magnitude harder to get right.
>
> --Alex
>
>> -----Original Message-----
>> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
>> Sent: Thursday, October 3, 2013 1:38 PM
>> To: dev
>> Subject: Re: [Proposal] Improve VR upgrades
>>
>> At Schuberg Philis we are looking at supporting HA redundant virtual routers
>> to be able to upgrade without any downtime. I don't think there is any other
>> way to go in the future, for multi-tenant corporate environments.
>> Upgrading will then mean destroying the redundant pair one by one while
>> waiting with destroying the second one till the first is back up.
>>
>> Of course this is not usefull for other systemvms then the router vms. Do you
>> see a place for this in your design, Kishan?
>>
>> As for Chip's concern; another implementation would be to allow for a
>> versioned vm/ms interface, instead of a backwards compatible one. Any way
>> it is a matter to deal with somehow.
>>
>> Daan
>>
>>
>>
>> On Thu, Oct 3, 2013 at 5:21 PM, Chip Childers
>> <ch...@sungard.com>wrote:
>>
>> > On Thu, Oct 03, 2013 at 11:47:57AM +0000, Kishan Kavala wrote:
>> > > During CS upgrade, VRs are required to be upgraded to use newer
>> > > systemVm
>> > template .
>> > > The current VR upgrade procedure has following limitations:
>> > > - takes 'long' time and the time exponentially increases with the
>> > > size
>> > of the cloud
>> > > - no way to sequence upgrade of different parts of the cloud, i.e.,
>> > specific clusters or pods or even zones
>> > > - there is no way to determine when a particular customer's services
>> > (e.g. VR) will be upgraded with the upgrade interval
>> > >
>> > > Goals for this feature are to address the above issues
>> > >
>> > > 1. Give admin control to sequence the upgrade of the cloud by:
>> > > - Infrastructure hierarchy: by Cluster, Pod, and Zone etc.
>> > > - Administrative hierarchy: by Tenant or Domain 2. Minimize
>> > > service interruption to users 3. Improve the speed of the upgrade
>> > > time by making as many upgrade
>> > operations in parallel as possible
>> > >
>> > > I've created JIRA ticket:
>> > > https://issues.apache.org/jira/browse/CLOUDSTACK-4793
>> > >
>> > > thanks,
>> > > Kishan
>> > >
>> >
>> > This proposal sounds great, but the devil will be in the
>> > implementation details. To do this as rolling, we'd need to ensure
>> > backward compat with agent>MS communications, right?
>> >
>> > -chip
>> >
RE: [Proposal] Improve VR upgrades
Posted by Alex Huang <Al...@citrix.com>.
+1. That's the way to do it with no downtime. Tighter control needs to be formed on the VR to VR version compatibility though. It's one reason I always support that we break VR into smaller pieces. Redundant VRs work great as routing but then if you have to handle DHCP, DNS, Load Balancing, and others with it then it becomes orders of magnitude harder to get right.
--Alex
> -----Original Message-----
> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> Sent: Thursday, October 3, 2013 1:38 PM
> To: dev
> Subject: Re: [Proposal] Improve VR upgrades
>
> At Schuberg Philis we are looking at supporting HA redundant virtual routers
> to be able to upgrade without any downtime. I don't think there is any other
> way to go in the future, for multi-tenant corporate environments.
> Upgrading will then mean destroying the redundant pair one by one while
> waiting with destroying the second one till the first is back up.
>
> Of course this is not usefull for other systemvms then the router vms. Do you
> see a place for this in your design, Kishan?
>
> As for Chip's concern; another implementation would be to allow for a
> versioned vm/ms interface, instead of a backwards compatible one. Any way
> it is a matter to deal with somehow.
>
> Daan
>
>
>
> On Thu, Oct 3, 2013 at 5:21 PM, Chip Childers
> <ch...@sungard.com>wrote:
>
> > On Thu, Oct 03, 2013 at 11:47:57AM +0000, Kishan Kavala wrote:
> > > During CS upgrade, VRs are required to be upgraded to use newer
> > > systemVm
> > template .
> > > The current VR upgrade procedure has following limitations:
> > > - takes 'long' time and the time exponentially increases with the
> > > size
> > of the cloud
> > > - no way to sequence upgrade of different parts of the cloud, i.e.,
> > specific clusters or pods or even zones
> > > - there is no way to determine when a particular customer's services
> > (e.g. VR) will be upgraded with the upgrade interval
> > >
> > > Goals for this feature are to address the above issues
> > >
> > > 1. Give admin control to sequence the upgrade of the cloud by:
> > > - Infrastructure hierarchy: by Cluster, Pod, and Zone etc.
> > > - Administrative hierarchy: by Tenant or Domain 2. Minimize
> > > service interruption to users 3. Improve the speed of the upgrade
> > > time by making as many upgrade
> > operations in parallel as possible
> > >
> > > I've created JIRA ticket:
> > > https://issues.apache.org/jira/browse/CLOUDSTACK-4793
> > >
> > > thanks,
> > > Kishan
> > >
> >
> > This proposal sounds great, but the devil will be in the
> > implementation details. To do this as rolling, we'd need to ensure
> > backward compat with agent>MS communications, right?
> >
> > -chip
> >
RE: [Proposal] Improve VR upgrades
Posted by Kishan Kavala <Ki...@citrix.com>.
Spec for this feature is available at [1]. For 4.3, as mentioned in the spec, enough flexibility is provided but the communication with older version systemVms will be limited.
Please provide your feedback.
[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Improve+SystemVm+upgrades
> -----Original Message-----
> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> Sent: Friday, 4 October 2013 2:08 AM
> To: dev
> Subject: Re: [Proposal] Improve VR upgrades
>
> At Schuberg Philis we are looking at supporting HA redundant virtual routers to
> be able to upgrade without any downtime. I don't think there is any other way
> to go in the future, for multi-tenant corporate environments.
> Upgrading will then mean destroying the redundant pair one by one while
> waiting with destroying the second one till the first is back up.
>
> Of course this is not usefull for other systemvms then the router vms. Do you
> see a place for this in your design, Kishan?
>
> As for Chip's concern; another implementation would be to allow for a
> versioned vm/ms interface, instead of a backwards compatible one. Any way it
> is a matter to deal with somehow.
>
> Daan
>
>
>
> On Thu, Oct 3, 2013 at 5:21 PM, Chip Childers
> <ch...@sungard.com>wrote:
>
> > On Thu, Oct 03, 2013 at 11:47:57AM +0000, Kishan Kavala wrote:
> > > During CS upgrade, VRs are required to be upgraded to use newer
> > > systemVm
> > template .
> > > The current VR upgrade procedure has following limitations:
> > > - takes 'long' time and the time exponentially increases with the
> > > size
> > of the cloud
> > > - no way to sequence upgrade of different parts of the cloud, i.e.,
> > specific clusters or pods or even zones
> > > - there is no way to determine when a particular customer's services
> > (e.g. VR) will be upgraded with the upgrade interval
> > >
> > > Goals for this feature are to address the above issues
> > >
> > > 1. Give admin control to sequence the upgrade of the cloud by:
> > > - Infrastructure hierarchy: by Cluster, Pod, and Zone etc.
> > > - Administrative hierarchy: by Tenant or Domain 2. Minimize
> > > service interruption to users 3. Improve the speed of the upgrade
> > > time by making as many upgrade
> > operations in parallel as possible
> > >
> > > I've created JIRA ticket:
> > > https://issues.apache.org/jira/browse/CLOUDSTACK-4793
> > >
> > > thanks,
> > > Kishan
> > >
> >
> > This proposal sounds great, but the devil will be in the
> > implementation details. To do this as rolling, we'd need to ensure
> > backward compat with agent>MS communications, right?
> >
> > -chip
> >
Re: [Proposal] Improve VR upgrades
Posted by Daan Hoogland <da...@gmail.com>.
At Schuberg Philis we are looking at supporting HA redundant virtual
routers to be able to upgrade without any downtime. I don't think there is
any other way to go in the future, for multi-tenant corporate environments.
Upgrading will then mean destroying the redundant pair one by one while
waiting with destroying the second one till the first is back up.
Of course this is not usefull for other systemvms then the router vms. Do
you see a place for this in your design, Kishan?
As for Chip's concern; another implementation would be to allow for a
versioned vm/ms interface, instead of a backwards compatible one. Any way
it is a matter to deal with somehow.
Daan
On Thu, Oct 3, 2013 at 5:21 PM, Chip Childers <ch...@sungard.com>wrote:
> On Thu, Oct 03, 2013 at 11:47:57AM +0000, Kishan Kavala wrote:
> > During CS upgrade, VRs are required to be upgraded to use newer systemVm
> template .
> > The current VR upgrade procedure has following limitations:
> > - takes 'long' time and the time exponentially increases with the size
> of the cloud
> > - no way to sequence upgrade of different parts of the cloud, i.e.,
> specific clusters or pods or even zones
> > - there is no way to determine when a particular customer's services
> (e.g. VR) will be upgraded with the upgrade interval
> >
> > Goals for this feature are to address the above issues
> >
> > 1. Give admin control to sequence the upgrade of the cloud by:
> > - Infrastructure hierarchy: by Cluster, Pod, and Zone etc.
> > - Administrative hierarchy: by Tenant or Domain
> > 2. Minimize service interruption to users
> > 3. Improve the speed of the upgrade time by making as many upgrade
> operations in parallel as possible
> >
> > I've created JIRA ticket:
> > https://issues.apache.org/jira/browse/CLOUDSTACK-4793
> >
> > thanks,
> > Kishan
> >
>
> This proposal sounds great, but the devil will be in the implementation
> details. To do this as rolling, we'd need to ensure backward compat
> with agent>MS communications, right?
>
> -chip
>
Re: [Proposal] Improve VR upgrades
Posted by Chip Childers <ch...@sungard.com>.
On Thu, Oct 03, 2013 at 11:47:57AM +0000, Kishan Kavala wrote:
> During CS upgrade, VRs are required to be upgraded to use newer systemVm template .
> The current VR upgrade procedure has following limitations:
> - takes 'long' time and the time exponentially increases with the size of the cloud
> - no way to sequence upgrade of different parts of the cloud, i.e., specific clusters or pods or even zones
> - there is no way to determine when a particular customer's services (e.g. VR) will be upgraded with the upgrade interval
>
> Goals for this feature are to address the above issues
>
> 1. Give admin control to sequence the upgrade of the cloud by:
> - Infrastructure hierarchy: by Cluster, Pod, and Zone etc.
> - Administrative hierarchy: by Tenant or Domain
> 2. Minimize service interruption to users
> 3. Improve the speed of the upgrade time by making as many upgrade operations in parallel as possible
>
> I've created JIRA ticket:
> https://issues.apache.org/jira/browse/CLOUDSTACK-4793
>
> thanks,
> Kishan
>
This proposal sounds great, but the devil will be in the implementation
details. To do this as rolling, we'd need to ensure backward compat
with agent>MS communications, right?
-chip