Jira Datacentre - Geo Specific Nodes

Dariusz Nowak

Hello,

My organisation is currently Jira user on Server license (1000 users) - our server is located in AWS London region and we identified an issue that users from APAC region got very slow connectivity to our Jira instance. This is caused simply by the fact of geographic location - takes a long time to go through half of the world.

We started thinking about options on how we can resolve this issue. I've understood one of the options is Jira Cloud (for sure there is some CDN for that) however we got a lot of custom plugins and modifications that are not available on Jira Cloud. Another option is Jira DataCentre - and got a few questions about that one.

I've understood there is no way of doing Geo-clustering (active/active), this is only available for DR (so I can have a replica in another AWS region but will not be active). However, I believe it can work like that:

* We got 1 server in EMEA

* We got 1 server in APAC

* These servers sharing Users Database (via LDAP)

Few questions now:

* They both will have different URL yes?

* APAC users will access APAC server (500) and EMEA users will access EMEA server (500). Is that means I need now license for 2000 users or can split my existing 1000 users license? There will be no crossovers (users from APAC don't need to access EMEA logs etc.)

* Is they are any shared elements between servers apart from users? For example, can I have the same issue type/flow between them (modify 1, copy to another)

* In case of migration 1 got one big server now, assuming when will create 2nd and will tell: Project X goes to APAC, project Z stays in EMEA what are my migration options?

* We also using service desk - how it works in that case, again got 50 agents, 25 will be in APAC, 25 in EMEA - can I split it without buying new licenses?

Thanks

Dariusz

 

Nic Brough -Adaptavist-

>Another option is Jira DataCentre - and got a few questions about that one.

>I've understood there is no way of doing Geo-clustering

Correct, although it is on Atlassian's to-do list.

Note that Data Centre is for high availability and it sounds like you are worried more about speed due to geographic separation - as you have gone with two separate servers, you may not need to think about Data Centre at all.  Two servers, one local to each set of users may well be performant enough. 

>* They both will have different URL yes?

Yes, they will be separate systems, with a shared user-base.

>* APAC users will access APAC server (500) and EMEA users will access EMEA server (500).

>* We also using service desk - how it works in that case, again got 50 agents, 25 will be in APAC, 25 in EMEA - can I split it without buying new licenses?

You will need two separate licences, 500 users on each server, and then for the Service Desk, two more 25 user licences for each server.  You will need to buy new licences for these.

>* Is they are any shared elements between servers apart from users? For example, can I have the same issue type/flow between them (modify 1, copy to another)

You can copy things between servers, but the two servers will not be sharing these things, they'll just be having copies made, and that, of course allows them to diverge.

  If it's config items, there are a couple of Apps on the marketplace that can make it a lot easier to keep config in line (and by config, I do mean things like workflows).  

There is also nothing to stop you "integrating" the two servers with other shared resources (mail, chat, source control etc). 

>* In case of migration 1 got one big server now, assuming when will create 2nd and will tell: Project X goes to APAC, project Z stays in EMEA what are my migration options?

You could try this manually, but don't, it's really hard work and error prone.  Two options though:

1. As above, use one of the configuration migration Apps to move the config and then issues around.
2. I don't know if it would be suitable, but rather than migrate, have a think about "synchronisation" instead - again, there are a couple of Apps on the marketplace that do this, and they basically replicate projects.  So when a user is in a sync project in EMEA and they make a change, a similar project in APAC is updated with their changes.  They can do this quite quickly, so rather than having to move a project, or have people from one region log in to the (slow for them) server in the other region, you can cross-update projects locally and have the changes shown remotely.  You would not be doing "migrations" between the two at all this way.