Server vs DataCenter on AWS?

[Vanja Petreski]

Hi guys,

Tutorials and documents for deploying JIRA on AWS are talking about DataCenter version of JIRA (https://s3.amazonaws.com/quickstart-reference/atlassian/jira/latest/doc/jira-software-data-center-on-the-aws-cloud.pdf).

We want to deploy DataCenter at some point on AWS, but for the time being we first want to make POC and test it with JIRA Server before migrating to DataCenter.

My question is - is possible to deploy / host JIRA Server on AWS, are installation and procedures described in the above document applicable to JIRA Server, if yes are there any differences in the sense of installation, deployment and behaviour and can we later easily migrate to DataCenter?

Thanks!

Vanja

[mattfrankenfield]

I would suggest using the EFS even with the single AWS instance as it will make the migration easier once you are ready to setup the auto-scaling cluster with data center. 

[Mike Rathwell]

Rather late to this party but when running Jira on AWS with EFS volumes I ran into a latency issue.... which caused me to migrate to EBS. Perhaps with the active-active of datacenter the latency problem goes away... 

EFS was my preferred choice but ended up being bad juju.

[Jeff Everett]

Hi @Mike Rathwell-

Can you share any metrics on the size of your instance? 

Generics like users or projects would be helpful, but ideally throughput on the EBS volume.

EFS is easy to get up and running but I'm curious if we'll be able to provision sufficient IOPS.

Thanks in advance!

Jeff

[Mike Rathwell]

Hi @Jeff Everett

SO... i have a 500 user instance but it is pounded heavily and has a lot of massively expensive groovy listeners and automation stuff in it. I have a 500GB volume for Jira (don't get me started on why that has to be so large but a change is coming) and a 25GB volume for Confluence with no extra throughput provisioned. I've never seen the burst balance drop below 98% on either of those volumes. The rough days are the sprint planning days where a lot of users are viewing the same issues (each having far too many groovy calculated fields) and automations to force things to happen on even mundane issue changes ALONG WITH enterprise agile poker. Some boards in use during these festivals span literally dozens of projects.

As noted before, I was NEVER hitting I/O or IOPS limits and don't even on the heavy days. I seldom see volume I/O above 2Mb/s or IOPS above 200. Always turned out to be latency. AWS came back with some suggestions that feel like "here, try this" so I went EBS. 

I think if you're going Data Center (which requires EFS on AWS to work) you'd be fine as it is far more likely that you'll have a non-busy resource available for a given operation.

One thing I did recently as I was running out of CPU (which caused a whole raft of other issues with eating DB connections, swamping disk, etc) was increase my instance size AND changed from an m4 to a c5 instance type. This seems to have more disk I/O available to it as well since I DO now see burst balance consumed once in a while and not like the seldom times it dropped below 100% as it was before.

[Jeff Everett]

Thanks much for the details Mike! 

I hadn't understood the issue might be on latency rather than IOPS.  Hadn't realized this from my first read, so this is a particularly valuable insight. 

We're also on a 500 user instance, but with a smaller data set and less intense automation from the sounds of it, so I'm at least hopeful that EFS will cover our usage.

Thanks again!

Jeff

[Mike Rathwell]

Hey @Jeff Everett,

Yes, it DOES sound like you could go EFS. As I mentioned originally, that was my first choice for a variety of reasons:

• No provisioning for size; just make a volume and mount it
  • No need to monitor volume usage. It's as big as it needs to be.
  • I found it amusing with the EFS volumes to do a "df -h" and get back 8 exabytes available.
  • While $/GB are higher, the monthly bill was actually a bit lower. You only pay for exactly the space you use whereas an EBS volume allocates a specific amount you pay for the whole thing by size every month. if one was at 100% utilization, the EBS would be less $/GB but 100% utilization is typically a Bad Thing.
• Multi AZ availability - this was a big one.
  • As I noted, I am running Jira and Confluence containerized. My images are aggressively stateless and location agnostic with details for the "where/what/when" configured in the ECS task definitions.
  • While not (currently) on Data Center which would seamlessly run through an AZ outage, in my case, if an AZ outage occurred and could be lengthy, a relatively quick recovery would be:
    • Spin a new EC2 instance in the region on a different AZ. My "user data" had a one time on start "go get the volumes and mount them" which automagically reconnected the ECS volumes for the applications
    • Register the new EC2 instance with ECS (great way to run containers and I use ECR for the registry so always can find the images)
    • Start the same task definitions as they were using named volumes (the EFS volumes that were available in the AZ I started the EC2 instance in) and connected to the same multi-AZ RDS database.
    • In tests, I could execute that recovery manually in 15 minutes. Yes, it was an "outage" but often shorter than when Something Bad happens to an AZ. Had I stayed ECS, I had a small backlog project to script the recovery with AWS CLI commands that I could run from basically anywhere, either on my "management" t2.micro linux host or, if I could get at that depending on the AWS failure, pull the script from GitHub (I actually use AWS CodeCommit) and run wherever I had AWS CLI installed or just... install it)
    • If an outage did occur, I wouldn't bother to "revert" to the original AZ when it came back; just leave it where it was until the next time Something Bad Happened.
• Overall Management
  • I rather like that the EFS volume management is not buried in the EC2 console. Clear separation.
  • Being "newer" the UI was less cluttered and just generally more pleasant to use than the EBS volume console. Subjectively, the UI seems to ease the angst of "Do I REALLY want to push 'go' on this command" since it was clearer and less cluttered.
  • The aforementioned lack of having to manage for utilization. One cleaned up to reduce the bill but did not have to because something would break if a volume filled.
  • Note: the cookbook Lamda stacks to back up and recover EFS volumes are a bit... convoluted... but also had a backlog to simplify that in my own way and methodology once I figured out what that was (likely a simpler scripted S3 sync)

When I go Data Center (will be sometime in the next year as I just paid this year's maintenance and it's a non-trivial exercise besides) I am looking forward to regaining these EFS benefits.

[Madhu Cynix]

The main distinction is that Server runs on a single node, while Data Center allows you to run on multiple nodes. When your Server instances grow, and your organization's ability to build products and deliver services puts an increasingly demanding load on them, you might need a better way to stay ahead.  Take your career to new heights of success with an AWS Training

[Vanja Petreski]

Thanks guys!

[Jobin Kuruvilla [Adaptavist]]

Yes, you can install JIRA Server on AWS. And later migrate to Datacenter.

The instructions will be similar but you don't need a load balancer and multiple nodes.Check out https://confluence.atlassian.com/adminjiraserver071/installing-jira-applications-802592161.html

[MattS]

It's not an officially supported platform in https://confluence.atlassian.com/display/AdminJIRAServer072/Supported+platforms but plenty of people are using it, and if Data Center works there, JIRA Server products should work as well

[Mike Rathwell]

I have Jira server running containerized using AWS ECS with underlying EC2 instances on EBS volumes and RDS in the PostgreSQL personality. Runs great.

[David Shapiro]

What kind of monthly costs are you seeing?

[Mike Rathwell]

I don't run the billing so only have a high level view of that but, after buying Reserved Instances for my prod and test envs, and careful sizing I am keeping it ~$1500/mo for the whole thing (all elements used considered and not just the basic EC2, EBS, RDS kinda stuff)

[David Shapiro]

Thanks for sharing your estimate