Date
1 - 7 of 7
Can I control the behavior of cf scale
|
Jiaxin Shi
Hi, I have a cf deployment, each runner can run 4 instances at the same time.
Assume I want to scale out from 1 runner to 2 runners, I wish runners can behave like this runner1, 4 instances -> runner1, 4 instances , runner2, 2 instances -> runner1, 2 instances , runner2, 2 instances Assume I want to scale in from 2 runners to 1 runner, I wish runners can behave like this runner1, 2 instances , runner2, 2 instances -> runner1, 4 instances , runner2, 2 instances -> runner1, 4 instances , runner2 closed But the only command I know is "cf scale", which can only control the total instances number.
|
|
|
|
John Feminella <jxf@...>
Are "runner1" and "runner2" just two applications? Could you get what you
toggle quoted messageShow quoted text
want through a blue-green deployment by scaling (2,2) -> (4,2) -> (4,0)? best, ~ jf
On Wed, Aug 10, 2016, 02:50 Jiaxin Shi <shijiaxin.cn(a)gmail.com> wrote:
Hi, I have a cf deployment, each runner can run 4 instances at the same
|
|
|
|
Jiaxin Shi
after I read more documents, I think what I want is "Evacuation".
Recreates the app instances on another VM ,waits until they are healthy, and then shuts down the old instances.
|
|
|
|
John Feminella <jxf@...>
Why do you want to recreate the app instances on another VM? Generally that
toggle quoted messageShow quoted text
is a detail the platform will be doing for you. best, ~ jf
On Thu, Aug 11, 2016 at 9:09 PM Jiaxin Shi <shijiaxin.cn(a)gmail.com> wrote:
after I read more documents, I think what I want is "Evacuation".
|
|
|
|
Jiaxin Shi
I want to increase runner VM or delete runner VM.
When I increase runner VM , I wish to make instances running on different VMs. When I delete runner VM , I wish to migrate instances from that VM to other VM. I just want to know whether Cloud Foundry can support this? Whether there are always 4 instances? Is it possible that CF deletes runner VM, then there are only 2 instances at that moment, and 2 instances cannot handle all the traffic?
|
|
|
|
Yitao Jiang
when you use bosh to update the runner vm, the instances will
toggle quoted messageShow quoted text
automatically migrate to another runner vm. You need to make sure you have enough vm(to be more specifically the resources ) to hold the instances. And for the downtime of App, there's chances that the instances of an app within same runner vm
On Fri, Aug 19, 2016 at 10:09 AM, Jiaxin Shi <shijiaxin.cn(a)gmail.com> wrote:
I want to increase runner VM or delete runner VM. --
Regards, Yitao
|
|
|
|
Eric Malm <emalm@...>
Hi, Jiaxin,
toggle quoted messageShow quoted text
Let's handle these cases separately. When you shut down a DEA or a Diego Cell gracefully (say, as BOSH does when updating or deleting a VM), it will attempt to get replacements for its app instances scheduled and running on other VMs before it shuts down the instances it hosts. We call this process "evacuation". As Yitao pointed out, if you have the spare capacity in your deployment for those replacement instances, this evacuation procedure should prevent any downtime for the application. In your case, even if you have all 4 app instances on the same DEA or Diego Cell when it starts to shut down, the system will schedule 4 replacement instances on other VMs and get them running before the original 4 instances are stopped. The other thing you've asked about is rebalancing to improve instance anti-affinity when more capacity is available. Currently, neither the DEAs nor Diego do that, but this kind of active rebalancing is of great interest to the Diego team and is something we intend to work on in the near future. If you want to attempt this rebalancing manually, you can determine some placement information about your instances from the app-stats endpoint (/v2/apps/:guid/stats) on CC's API. The response will include the IP of the host for each instance. You could then use the `cf restart-app-instance` command to restart instances one by one by their index. On the Diego runtime, at least, instance anti-affinity across availability zones and hosts is the most important placement factor, so if there is sufficient capacity, the replacement instances will be placed on VMs with fewer instances of that app. Of course, this manual rebalancing procedure is less than ideal, which is one reason the Diego team is quite interested in having the platform handle it on your behalf. Moreover, the goal would also be to perform the rebalancing in a safer way, ideally similar to the "evacuation" concept above except for individual app instances instead of all the instances on a particular VM. Thanks, Eric, CF Runtime Diego PM
On Thu, Aug 18, 2016 at 9:28 PM, Yitao Jiang <jiangyt.cn(a)gmail.com> wrote:
when you use bosh to update the runner vm, the instances will
|
|
|