This AMA is now closed
Hi! I'm Jacob Shepard a Product Marketing Manager on Atlassian’s Enterprise Team. We know that moving to Data Center is no small task. To do so effectively demands extensive planning and a team effort. We understand you might have a lot of questions so that’s why we’re hosting our first-ever Panel AMA on October 24th from 1:00pm-3:00pm PST!
Who is on the Panel?
Denise Unterwurzacher: Senior Operations Engineer
Kevin Allen: Senior Technical Account Manager
Katie Shoemaker: Customer Success Manager
Here's how it works:
Add your questions below any time before or during the AMA. Feel free to @ mention specific panelists in your question if you would like. Be sure to take a look at other community member’s questions and up-vote those that you find interesting.
At 1:00 pm PST on Thursday you can expect to see answers from the panel start rolling in. Watch the page and be ready to add follow-up questions and discuss further with other Community members. We'll wrap the event at 3:00 pm PST, but will be sure to answer any questions we didn't get to.
Thanks for feedback! We are increasing our cross-product approach to development, so you will start to see a general trend towards consistency.
We are currently exploring a few areas around health and insights within Data Center. We’d be happy to chat more to learn more about your use case. Please let Anthony, your TAM, know if you are interested and we will connect you with the product team.
Also, I believe that he has recently added a document for you in TAM Cloud that touches on some of this.
Great question! Officially, no.
TAMs work under pretty tight privacy guidelines. We take a lot of commonly/publicly available information, synthesize it based on our experience and our Teams experience, evaluate what our developers and engineers are working on, then run it all through the lens of client context. In short, we take the general nature of this kind of question and refine it down to its root issues and address those. Likely this document is so specific it would be of little value beyond harnessing some links that you may already have.
That said, you can get the outcome of this process, but you'd need to subscribe to the TAM service https://www.atlassian.com/enterprise/tam.
Alternatively work with a lead or Senior consultant from your current Solution Partner. They may not have all the access to roadmaps or direct access to the product teams, but they can still help build a solid plan to help with rollouts, architecture, general solutions, and are experienced enough to identify work-arounds for experiences like this.
Also, don't forget to comment on, watch, and vote for issues on jira.atlassian.com. It does matter.
What's the plan for better support for DR in Data Center? The current copying of a snapshot of the data dir to a file system doesn't work well if the file system is on the other side of a continent. I'd love to see Jira and Confluence have a way to replicate attachments to another location. Happy to run another process on the remote side
This is something the product teams are exploring at the moment. As @Kevin Allen mentioned to Matt earlier, we’d love to learn more about your needs in this area. If you are interested in chatting with our product teams more about this, let us know and we’ll reach out to you via email in the next week or so.
Having said that, if you use AWS Cloudformation, there is an unsupported tool called the Backup Machine, that we use to take snapshots of both database and filesystem and push those snapshots across regions. We then use the 'clone' cloudformation templates to restore the snapshots, both for creating staging environments, and for DR.
You could also look into use EFS DataSync to sync your data to another EFS in a different region, and fail over to using that as your file system in a DR scenario. This is new functionality that was just released in May, and we haven't as yet done any internal testing with it as far as I'm aware.
Yes you are correct, we do not support AWS AutoScaling today. The only way we use or support autoscaling today is to ensure a minimum number of nodes in the cluster. We set min and max node counts to the same value, and if we have to terminate a node, or AWS terminates one (which can happen at any time), the autoscaling group will kick in and bring a new node into service to replace it.
The reason autoscaling in response to events like high CPU doesn't work very well is that new nodes start up with no index. It can take time for them to pull a working index from an existing node, eg on some of our larger instances it can take up to an hour. That means that if you scaled up in response to high CPU, your new node would only become available (and usable) after 1 hour.
Instead of autoscaling in response to thresholds, you could look into autoscaling based on load. Eg if your higher load times are 9-5pm CST, you could scale to add additional nodes around 8am PST, and destroy them when the load drops.
However, bear in mind with Jira that the new node won't have an index but _will_ be in the load balancer, so your users may report problems while the index is recovering. For Confluence though, the node won't come into service until the index restore is complete.
We are continuing to collect feedback on autoscaling, so please watch and add any commentary on this ticket for Jira. We will share any updates on future support here and in other related tickets. Thanks!
Hi Mikael, On the TAM team, we always joke that our number one answer is “it depends!”
That definitely applies here, but here’s some general guidance to influence your decision.
What you bring over on one node, is going to get replicated. I strongly encourage my teams to make efforts to clean up prior to a migration. If performance is good, or only lessened by being on an overloaded Server instance, then you are probably OK to proceed as you’ve described, but this is not my preferred path.
A couple of reasons (I'm sure I or the team will think of others):
I prefer to size out (include forecasted organic issue/artifact growth AND any M&A or consolidation work) and setup a clean environment. Think greenfield, all new. Migrate your cleaned data into a single node DC. Turn it on and compare your performance metrics, then add nodes based on the load you are comfortable with in your DC environment.
Hi Kevin and Katie, planning to migrate to DC using Jira 8.5.x or later and using our own hardware, I would like to build a prototype DC cluster beginning with a single server connected to my Dev database and continuing my rollout in this manner so I do not have to move data as I go from Dev to Stage to Prod. Is this approach possible?
Katie, my Prod database is copied to my Dev and Stage databases on a weekly basis so we always have a recent copy of Prod data for testing purposes.
Perhaps I was not clear in my request and I am sorry that I was not. My question should have said, can I use my DC for Dev and connect it to my Dev database?
Then if this approach is possible, I would like to perform the same process as I build my Stage DC and connect it to my Stage database, then followed by building my Prod DC and connecting it to my Prod database.
In each of these migrations, I plan to begin with one node and add nodes as needed.
Has this approach been used by any clients?
Thank you for explaining. We actually recommend what you're suggesting, mirroring prod to test, as long as you are using a DEV license or evaluation license. This guide has some pretty detailed instructions on how to do this, including the license change. https://confluence.atlassian.com/adminjiraserver/creating-a-test-environment-for-jira-966063324.html
Happy to help any further!
Hi Christian. We’d love to understand a bit more about your use case or reason for this request.
Is this in regards to supporting the ability to log into applications without having to go through an SSO mechanism, such as an Okta integration or another SSO IDP? Is it related to wanting support for multiple IDPs (at the same time), or more about allowing local _and_ SAML auth, as described here?
If you can expand further about your use case, we’d be happy to help! Thanks!
What is the correct way to refresh a testing environment from a production environment?
OR: After transferring data from a production environment via xml-Export, how do i get rid of the node references in the database which result in a lot of error messages in the log?
It's generally beneficial to get a Solutions Partner or TAM to help you with this. Most (maybe all) partners have a baseline automation harness that they customize for their customer engagements. No one wants to manually build out nodes through numerous cycles of experimentation and testing.
If that’s not available from your partner or you don’t have the budget, there are a few things you can do here to make your life easier:
Use the native Database tools vs XML - generally more reliable and faster
Automate - see above
Adopt templates from providers like AWS and Azure
Use Community to collaborate with other admins that have the same tool stack as you, share templates and recipes
There’s an existing feature request related to your ask: https://jira.atlassian.com/browse/JRASERVER-42916
But this is also mitigated in Jira versions from 8.1 on: https://jira.atlassian.com/browse/JRASERVER-69033
In addition to Kevin’s response, if you use AWS Cloudformation, there are ‘clone’ cloudformation templates that allow you to easily create testing environments from snapshots of production data.
There is also a public tool call the Backup Machine that my team built to automate the process of creating those snapshots.
For more information on how they all fit together, check out this webinar.
Regarding deleting the extra nodes, there is a workaround in the bug which Kevin linked (https://jira.atlassian.com/browse/JRASERVER-42916) which you can use to delete the old nodes from the database, if you’re not yet on Jira 8. We’d recommend doing that periodically on your production instance if you use AWS Cloudformation and are therefore destroying and recreating nodes frequently.
How is the feature looking about supporting Microsoft SQL Server feature "Always On Availability Groups". We're looking into it for our switch to datacenter with fully high availability (proxy, application servers, file share and databases). I know the latest JDBC driver supports this feature, but does the Atlassian software support it? For example will it work without issues if a database server reboots/loses connection.
It has been possible to use SQL Server’s Always On Availability Groups since Jira 7.5.0, as that was shipped with JDBC driver version 6.2.1: https://jira.atlassian.com/browse/JRASERVER-43873
There is some more information in that ticket, however it does note that it’s not an officially supported configuration.
While Confluence hasn’t made any public statements regarding Always On Availability Groups, it has bundled JDBC driver version 6.3.0 since Confluence 6.4.0, so any Confluence version 6.4.0 or higher should also be compatible (though also unsupported).
Bear in mind, there are a few rules of thumb regarding non standard database configurations:
What is your favorite or most unknown/hidden easter egg in any of the Atlassian applications?
I would like the option to change our Confluence's favorite Color and Character to something else, open a feature request? /s
Serious question, with the recent acquisition of Code Barrel and strategic partnerships with companies like Slack, can we expect any features with these plugins to be built in or possible enhanced? One example that comes to mind is in JSD there is the the default "Automation" option for projects, but if you have Automation for Jira installed there is an additional option for that plugin ("Project Automation").
Huge shout-out to Kevin Allen and Anthony Ferrari, they have been instrumental to our organization by guiding us on the correct path to use Atlassian products.
Easter Egg, etc:
Hmm, it’s well documented, but probably the most underused/ Easter eggy type of feature is per user settings in Jira and Confluence. As a solution partner, I used to harp on this constantly and wrote a couple of blogs about it.
Feature request: Maybe a Premier Support ticket, personally I’d stick with Blue
It’s likely a bit early for us to talk about these plans, even as your TAM. I know this one is important to you and we will keep you in the loop as best we can. Exciting stuff and glad to have that team back with Atlassian.
Thanks Eric! You’re a pleasure to work with!
Some of my favourite easter eggs:
Will you work on a better description of self-managed CDN network for Jira DC. As DC is our mitigation to our current single server load problems, but CDN should be our mitigation to our far away remote side performance problems. But the current available documentation is far away form being complete/detailed enough to build up a private/own managed CDM network.
Hey Michael! Thanks for posting... As you know, support for CDN is a fairly new addition to DC. For a long time, Data Center didn't bring much to the table in terms of geographically distributed teams, so I'm super pleased to see that come to the forefront in the form of CDN support.
Because it is such a new feature we are still in the process of making sure the feature set does exactly what our customers need it to do. Can you, or any other readers, share particular things you are looking to CDN for that you may not fully understand based on looking at our current documentation? How would you like to see our CDN support grow?
With this feedback we can continue to perfect the role that CDN plays in the DC implementation.
Specifically looking at Confluence here: When moving from Server to data-center there is a noticeable increase in just the Application license cost (not including any add-ons) and the main selling point is "The main distinction is that Server runs on a single node, while Data Center allows you to run on multiple nodes." per this Atlassian Blog. This is in addition to the recent increase in your base cost beginning this month. My question is as we move forward can we expect Atlassian to do more "included" enhancements (add-ons) and not rely so heavily on the community and other vendors to sell them? It would be nice if we had functionality built into the product since its not a question of whether it can be done (since they are already doing it).
At the server level it makes sense because the cost is extremely reasonable and Atlassian is not (at least for Confluence) ready for Enterprise size cloud usage; therefore, upgrading to Data-Center quickly moves into the executive spotlight as you look at overall upgrade cost (hardware, Application License, and add-ons).
Looking forward to hearing from the team!
Hey William, good question! If you look back on how Data Center has progressed since it's introduction ~5 years ago, you'll see a kind of evolution occur. Early on, like you said, much of the value of Data Center was simply in the architecture (high availability, performance at scale from horizontal scaling, instant scalability, etc.).
But over the past few years we've started to make Data Center more than just the architecture. With things like project archiving and zero-downtime upgrades in Jira, and read-only mode and analytics for Confluence customers are starting to see Atlassian grow Data Center into a enterprise platform that includes enhanced hardware and enhanced software. I think you'll continue to see Data Center move in this direction.
It will be any specific documentation for configuring synchrony in confluence version 6 ( 6.5 - 6.15 ). Currently moving to datacenter testing the oldest EOL ( current version 6.5 ) even if synchrony is running we have the following issue:
" postConfigToSynchrony [Collab editing plugin] Synchrony connection failure: Could not generate/verify AppID/Secret for real-time collaboration service at http://localhost:8091/synchrony/v1 "
Comparing with Confluence 7 it is a lot easier to configure it even with different ports.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events