Ask Octopus Episode #14 - Configure your HA Cluster
You may already have an existing Octopus Server that you wish to make highly available. The process to migrate to Octopus High Availability is the same as the process detailed in High Availability Implementation Guide, except your existing server will be the first node in the cluster. Migrating to HA will involve:
- Moving the SQL Server Database to a dedicated SQL Server.
- Moving all the task logs, packages, artifacts, imports, event exports etc., to a shared storage folder (BLOB data).
- Configuring a load balancer.
This guide is generic and purposely avoids mentioning specific technologies such as Azure File Storage, AWS RDS SQL Server, etc. Please see our High Availability Implementation Guide for more details.
Prep Work
These actions will require downtime. You can do prep work to keep the downtime to a minimum.
Moving the database
Moving the SQL Server database involves performing a backup and restore of the database. That backup and restore have to occur during the outage window.
You can prepare for that by doing the following:
- Provision the SQL Server Instance (if it doesn’t already exist).
- Create the SQL Server user Octopus will use to log into SQL Server (if it doesn’t already exist).
After the SQL Server has been provisioned and the user has been created, you’ll want to ensure Octopus Deploy can connect to the SQL Server. It is important to do this on the server hosting Octopus Deploy with the same user the Octopus Deploy Windows Service is running as. If the Octopus Deploy Windows Service is running as a Local System
any administrator account should work for this test.
$userName = ""
$password = ""
$newSQLServer = ""
if ([string]::IsNullOrWhiteSpace($userName) -eq $true){
Write-Host "No username found, using integrated security"
$connectionString = "Server=$newSQLServer;Database=master;integrated security=true;"
}
else {
Write-Host "Username found, using SQL Authentication"
$connectionString = "Server=$newSQLServer;Database=master;User ID=$userName;Password=$password;"
}
$sqlConnection = New-Object System.Data.SqlClient.SqlConnection
$sqlConnection.ConnectionString = $connectionString
Write-Host "Attempting to connect to $newSQLServer"
$sqlConnection.Open()
Write-Host "Connection successful. Closing connection."
$sqlConnection.Close()
You can run that script using the Octopus Deploy script console. If you are using a SQL Login, you’ll want to change the user’s password after your run your tests as that password will appear in the task log.
Moving BLOB data
Most of the BLOB data (task logs, artifacts, packages, imports, event exports etc) stored on the file system can be copied to the new location prior to the outage window. Doing so will reduce the amount of copying you have to do during the outage windows. In addition, you can make sure your Octopus Deploy instance can use that shared location by running a test script to create and delete a file.
- Provision the shared storage folder.
- Use the script console to ensure Octopus can connect to the shared folder and create files.
$filePath = "YOUR DIRECTORY"
New-Item "$filePath\file.txt" -ItemType file
Remove-Item "$filepath\file.txt"
- Run a tool such RoboCopy to copy the folder contents.
An example PowerShell script using RoboCopy will be:
robocopy C:\Octopus\TaskLogs \\your-file-share\OctopusHA\TaskLogs /mir /r:5
robocopy C:\Octopus\Artifacts \\your-file-share\OctopusHA\Artifacts /mir /r:5
robocopy C:\Octopus\Packages \\your-file-share\OctopusHA\Packages /mir /r:5
robocopy C:\Octopus\Imports \\your-file-share\OctopusHA\Imports /mir /r:5
robocopy C:\Octopus\EventExports \\your-file-share\OctopusHA\EventExports /mir /r:5
Configure load balancer
Octopus Deploy must sit behind a load balancer when configured in HA mode. We recommend creating a new URL for your Octopus HA cluster. For example, if the current URL for your Octopus Instance is octopus.your-domain.local
, the load-balanced URL could be octopus-ha.your-domain.local
.
The advantage of a new URL is:
- You can still access each server directly (if need be).
- The process of redirecting users and applications to the new URL should only need to be done once.
- You can configure and test it before the outage window, along with working through any connection issues.
Outage windows
The below steps will cause an outage in Octopus Deploy. With all the prep work, the outage window should be small. If possible, we recommend making these change off-hours. In addition, you don’t have to do them all in one outage window. You can move the database in one outage window, and the file system in the other outage window.
During your outage window, perform the following steps (skip the sections that don’t apply).
- Ensure you have a backup of your master key.
- Enable Maintenance Mode to prevent anyone from deploying or making changes during the upgrade.
- Stop the Octopus Deploy windows service.
Move the database
- Back up the database.
- Restore the database on the new SQL Server.
- On your Octopus Server, run the following command to update the connection string (where “VALUE” is your connection string).
Set-Location "C:\Program Files\Octopus Deploy\Octopus"
& .\Octopus.Server.exe database --connectionString="VALUE"
Move the file storage
- Run RoboCopy one final time to pick up any new files.
- Run the following command to update the paths.
Set-Location "C:\Program Files\Octopus Deploy\Octopus"
$filePath = "YOUR ROOT DIRECTORY"
& .\Octopus.Server.exe path --clusterShared "$filePath"
& .\Octopus.Server.exe path --artifacts "$filePath\Artifacts"
& .\Octopus.Server.exe path --taskLogs "$filePath\TaskLogs"
& .\Octopus.Server.exe path --nugetRepository "$filePath\Packages"
& .\Octopus.Server.exe path --imports "$filePath\Imports"
& .\Octopus.Server.exe path --eventExports "$filePath\EventExports"
& .\Octopus.Server.exe path --telemetry "$filePath\Telemetry"
Your version might not have all the above paths. Remove them from the script if you are running an older version of Octopus.
Imports
was added in 2021.1Telemetry
was added in 2020.xClusterShared
was added in 2020.x
After moving database and file storage
After you finish moving the database and file storage, it is time to turn back on your Octopus Deploy instance.
- Turn back on the Octopus Deploy instance. If the instance fails to start, that indicates a database connection issue.
- Log in to your instance.
- Navigate to previous deployments. If you cannot see the task logs, that indicates a file storage issue.
- Perform a couple of test deployments.
- Assuming all goes well, disable maintenance mode.
- Notify everyone of the new URL (if there is one).
Adding additional nodes
After configuring a load balancer and moving the database and files, adding a new node is trivial.
- Create a new server to host Octopus Deploy.
- Install the same version by downloading it from our download archive.
- When the Octopus Manager loads, click the
Add this instance to a High Availability cluster
and follow the wizard. - Add that server to your load balancer.
Help us continuously improve
Please let us know if you have any feedback about this page.
Page updated on Wednesday, October 4, 2023