Trying autoscaling on CloudStack

[mawmaz]

Hi, I wanted try Autoscaling feature based on this guide. I installed the platform few times with the tutorial from @rohityadavcloud from their blog on Ubuntu 22.04 LTS.

However I think I'm missing or don't fully understand something in the network setup(s) that would make this work, I've read the documentation a few times and I still don't understand which CIDR or IPs are you supposed to fill in. My network is on 192.168.1.0/24 range.

1. I downloaded CentOS 7 template according to the first steps
2. I followed the guide by adding an isolated network with source-nat from guest network with a gateway and dns of 192.168.1.1, and acquired a public IP at 192.168.1.145 (it shows cidr as 192.168.1.0/24)
3. I go into the public IP and configured the load balancer for port 80 with Autoscale enabled as http load balancer, then exposing the http service from the firewall in the same place
4. Finishing the network setup by permitting outgoing traffic for the isolated network
5. Continuing by creating Autoscale VM Group exactly as told and confirmed 2 VMs initialized.

The problem came after this in which I can't ping then public IP of 192.168.1.145 which was supposed to be accessible for http request, even with telnet on port 80 it still doesn't return anything.

Can anyone tell what are my mistakes from any side of the config whether it be from the cloudstack or the network? Also the powerstate of the host is disabled if that's significant to help.
Any help will be appreciated, thanks.

[weizhouapache]

do the guest network and public IP both use 192.168.1.0/24 ?

[mawmaz]

Yes, I was when I submitted this thread.

I'm afraid that was my fault of understanding, a few hours back I realized that Guest network should've matched the guest CIDR or at least a different IP set from the public IP, now the Autoscaling is working as intended. Using 10.1.1.0/24 for guest network and 192.168.x.x for the chosen public IP.

However I had a weird behavior:

1. when I disabled the autoscale group (for maintenance scenario), it didn't expunge the existing VMs.
2. Also another one where I rebooted the whole system, the existing autoscale VMs from previous session are turned off and the autoscale group just chooses to create new ones instead. I heard this was a common problem on cloudstack where instances aren't automatically turned back up after a system reboot so it might be related to that.
3. Just to add another one as well when I expunged all the previous autoscale VM from machine 1-5, the autoscale group just created number 6 onwards instead of repeating from 1.

[weizhouapache]

1. when I disabled the autoscale group (for maintenance scenario), it didn't expunge the existing VMs.

the monitoring, scale up/down are disabled.
existing VMs will not be touched. (I believe users do not expect the VMs to be expunged)

2. Also another one where I rebooted the whole system, the existing autoscale VMs from previous session are turned off and the autoscale group just chooses to create new ones instead. I heard this was a common problem on cloudstack where instances aren't automatically turned back up after a system reboot so it might be related to that.

yes, the stopped VM is not considered as a working vm, so AS group will spin up a new vm.

You can update the VM to HA enabled in multiple ways

• stop vm and update it to ha-enabled, or
• create service offerin with HA-enabled, or
• set global configuration "force.ha" to true, and so on

3. Just to add another one as well when I expunged all the previous autoscale VM from machine 1-5, the autoscale group just created number 6 onwards instead of repeating from 1.

yes, the name of the autoscale vms use consequent number.
IMHO, using vms with same number in the name is confusing

[mawmaz]

Thanks for the help.

Another problem occurred now, the autoscale group aren't scaling at all when I used ApacheBench from the guide, the VMs CPU barely does anything but the virtual router had a hard time managing it. Meaning I still did something wrong with the network setup. Because when I accessed the Public IP it should've output a "hello world" on http when creating my group using a shell script for the CentOS template and instead it outputs error 503 with the message "no server are able to handle that".

So it's either the network setup was still wrong or CentOS template wasn't able to execute the shell script to create a http server. As if the requests where held back in the VR.

[weizhouapache]

Another problem occurred now, the autoscale group aren't scaling at all when I used ApacheBench from the guide, the VMs CPU barely does anything but the virtual router had a hard time managing it. Meaning I still did something wrong with the network setup. Because when I accessed the Public IP it should've output a "hello world" on http when creating my group using a shell script for the CentOS template and instead it outputs error 503 with the message "no server are able to handle that".

@mawmaz
it may be due to EOL of centos7
you can try with some cloud images (ubuntu, rocky, almalinux, etc) and adapt the userdata

[mawmaz]

How will I know if the template instances are actually able to run the userdata script? It's a big dilemma at the moment deciding where the problem comes from, because on one hand we know that the requests from ApacheBench are stuck at the VR and not going through the Autoscale Group instances.

I also don't know where to find template OS that have the same function as in the guide where it'll automatically retrieve the userdata from the CloudStack VR and perform specified actions during start-up.

[weizhouapache]

@mawmaz
You can find cloud images of various OS distributions on the internet, for example Ubuntu, Debian, Rocky, Alma, OracleLinux
All these images use cloud-init which can get userdata from CloudStack VR during first start-up

I use ubuntu 24 or ol8 cloud-images in my testing