How Does Server Uptime Schedule Work?
Google Cloud bills on a per second basis of compute resources only when they are on. By leveraging the itopia uptime server VM instance scheduling you could significantly reduce your overall cloud infrastructure cost.
For example: If your company only works during regular business hours, you can schedule server VM instances to turn on at 8 AM and turn off at 8 PM thus reducing the amount of hours consumed in a month by half.
Secondary (Backup) Domain Controller Uptime
If you enabled Secondary Domain Controller when deploying to cloud, you can configure an uptime schedule for the server to turn on for a couple of hours a day (e.g. 12AM - 2AM) to sync the data with the main DC. The schedule is the best practice to have the server up to date and to save cost.
Please keep in mind that the main DC must be turned on at the time of the sync with the Secondary DC.
You can also create the schedules based on your needs for the rest of the servers.
See steps below on how to accomplish this in 5 minutes or less.
1. In the Cloud manager menu, go to "Server uptime" and click on the "Add" button on the top right corner to add a schedule.
2. Enter a Server uptime schedule "Name" and "Description".
2. Select server VM instances you want the schedule to apply to.
We recommend to schedule the Domain Controller (pdc server) to turn on a little sooner than the rest of the servers to give it enough time to start the services and avoid it not joining the domain. 5 min before the rest of the servers should be enough.
3. In the Uptime Events, either click in the time block you want to add a start/stop/reset event, or hit add on the right.
4. In the add event schedule, you'll first choose the action: Start, Stop, Reset
Start command: Powers on VM Instance
Stop command: Stopping an instance causes Compute Engine to send the ACPI Power Off signal to the instance. Modern guest operating systems are configured to perform a clean shutdown before powering off in response to the power off signal. Compute Engine waits a short time for the guest to finish shutting down and then transitions the instance to the
Reset command: Performing a reset on your instance is similar to doing a hard reset on your computer where you might press a reset button or press and hold the power button. Resetting an instance forcibly wipes the memory contents of the machine and resets the virtual machine to its initial state. The instance does not perform a clean shutdown of the guest OS. Throughout this process, the instance remains in
5. Then Select the Days you want the action to take place on.
6. Then you'll choose the time and hit save.
Below is an example of what the events would look like.
The schedule can be deleted or modified anytime from the Server Uptime menu. You can also temporarily disable the schedule if you mark it and hit Disable button.
Schedules can be then enabled back clicking Enable button.
Please note that with our scheduling module you can create different uptime settings for every day and define the criteria for each server separately or select the same for all servers.
Always turn-on the Primary Domain Controller (xxxPDC001), 5 minutes before any other server in the environment.
The main DC must be turned on for the Secondary (backup) DC can sync correctly. When creating an uptime schedule for other servers, adjust it the way the main DC and the secondary DC are both on when syncing.
What To Do If Your Servers Aren’t Powering On
If the servers are not booting correctly via Server Uptime Schedule, please check if the startup script is completing successfully.
To do this, navigate to https://console.cloud.google.com/ and login.
Access your Google Project in which your deployment was built. In this example, we’re selecting the Itopia project.
Click on the Navigation Menu → Compute Engine --> VM Insances
In the VM Instances section, double click on the VM who’s logs you are trying to retrieve. In this example, we’ll be clicking on rchrbrk001
In the VM Instances details section, click on Serial Port 1
In order to verify that your server has booted successfully, look for the following line
GCEMetadataScripts: Finished running startup scripts.
If the server was recently powered on, then it should be towards the end of the log. If you’re not seeing it immediately, there is a high chance that it is still being processed. Click on the REFRESH button every few minutes to view the updated logs.
If you see that the startup script has finished successfully as per the below screenshots, then your server has booted successfully.
If you do not see that the startup script has finished successfully, then as stated previously, you should refresh that logging page every few minutes. If the startup script never finishes, regardless of how often you have refreshed, then there is a high possibility that your server is corrupted, and will need to be restored/rebuilt.