[
https://issues.apache.org/jira/browse/CLOUDSTACK-6047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13945655#comment-13945655
]
ASF subversion and git services commented on CLOUDSTACK-6047:
-------------------------------------------------------------
Commit d56b45a1c3ce13bdec837a8701beb936220f34ee in cloudstack's branch
refs/heads/4.4 from [~yasker]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d56b45a ]
CLOUDSTACK-6047: Fix timeout issue when try to execute aggregated commands
Add executeInVR() with timeout interface to VirtualRouterDeployer
AggregationControlCommand with Action.Finish may take longer than normal command
since it would execute all the commands in one execution, and it may result in
SSH timeout for SshHelper or other mechanism communicate with VR.
Introduce an new executeInVR() interface with added timeout period for waiting
FinishAggregationCommand to complete execution.
> Make Virtual Router to aggregate execution of commands
> ------------------------------------------------------
>
> Key: CLOUDSTACK-6047
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6047
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller, Virtual Router
> Reporter: Sheng Yang
> Assignee: Sheng Yang
> Priority: Blocker
> Fix For: 4.4.0
>
>
> Currently VR has an scalability issue during the large deployment. Everytime
> when VR need to be re-create or reboot, CloudStack would send lots of
> programming commands to it. VR would treat them as individual commands then
> execute them. In large deployment, it would take tens of minutes or even
> hours to complete all the necessary updates, like setup DHCP and programming
> firewall.
> For example, in the past, everytime we setup DHCP in VR, we need to restart
> dnsmasq service for every programming, which is very time consuming. Though
> we've introduced a way to reload without restart dnsmasq, but the same issue
> existed with apache2 and other services as well. And every SSH to VR would
> also time consuming.
> The new approach of reprogramming VR, would help greatly on this issue, and
> hopefully great reduce the VR programming time. It would introduce a
> mechanism to "aggregate" the commands to be executed, and do it in one batch
> inside VR. And restart the related services(if necesary) only after the whole
> batch is completed. The configuration would be transfer to VR in one piece as
> well, eliminate any unnecessary ssh.
> We would expect in such scenario, most configuration would only be text
> update and involve no more time consuming operations. We would leave every
> possible time consuming operation to the end of execution of aggregated
> commands.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
