Migrating Atlassian Suite to new hardware

[Neil Taylor]

Hello All!

I am in a new position where I am administrating JIRA/Confluence/Crowd for a larger organization. Our current environment is pretty maxxed out on resources currently and I have been given new machines to move everything onto and I'm trying to work out the best plan to move everything seamlessly and thought maybe some other users might have some good ideas.

The main things - we cannot lose any data. Downtime has to be contrained to weekends. We must thoroughly test the new environment before fully switching to it.

About the current environment - we have 3 machines currently running these applications and all three machines are running Microsoft Server 2003 R2 x32:

Machine 1: Microsoft SQL Server 2008 - Databases for Crowd and JIRA

Machine 2: Hosts JIRA (4.4.4) and Crowd (2.4.0)

Machine 3: Confluence (3.5.6) which is linked to Postgresql which is on the same server

A little about our system load: We currently have around 1400 users in crowd. JIRA has about 150k issues and about 50 projects. JIRA and WIKI tend to go down every couple days from what I can tell, it is because of running out of memory. Both are currently only able to have about 1GB of ram dedicated to them due to the hardware restrictions (the new hardware I can build virtual machines with a far higher amount of ram - my host has 128GB)

My new environment is flexible - I can create a number of virtual machines and am open to suggestions if someone things the current structure should be changed. I can also continue on Server 2003 or I could move to Server 2008.

Any ideas/help/advice would be greatly appreciated.

Thanks!!!

[twong_atlassian · Accepted solution]

Some reference docs:

https://confluence.atlassian.com/display/DOC/Migrating+Confluence+Between+Servers

What I would do:

Pre-Work:

• Create a reverse proxy that resolves to the existing machines.
  • Test the heck out of this.
  • Make a DNS change that changes the public names of the existing services to this reverse proxy.
• Create 3 new databases in the destination SQL Server 2k8 machine.
• Restore nightly backups corresponding to the 3 services (confluence/jira/crowd) to the newly created databases

Testing Cycle

• Deploy new copies of each instance, making configuration changes as necessary to re-resource the services to the appropriate level of system resources.
• Ensure that each instance can connect to each other properly and integrate with each other correctly.

Deployment

• Schedule ahead a time a maintenance window over the weekend. Ensure that your userbase is well informed.
• Come the window,
  • Shutdown all affected services, take db backups, move all the files (attachments directories and such) to the destination.
  • Restart affected services with an announcement that each service is running in a degraded state and any chances will not be kept in this state.
  • Shutdown destination services, restore the backups, then restart. Test the heck out of this.
  • Make a change to your reverse proxy toggling the destinations servers from your prod to your new servers.
  • End the Maintenance window.

At first sign of problem

• Make an executive decision to either press on and troubleshoot or rollback the reverse proxy change, thus, toggling the old state back.