When we test beta builds on our vetting cluster, we typically will let the data extracts run, usually against a testing DB first, then against our production database server for a few limited runs to avoid impacting operations too heavily. It's useful to do so, in my view, because not only do you ensure that your hosts are configured properly with the correct drivers and such, but you also ensure that the new version of Tableau Server will properly process your data extracts when you upgrade your production instance.
From a data perspective, if your data is running at precise times and changes constantly, it's going to be difficult to compare data viz values between Prod and Test, since the timing on the extracts will not necessarily line up. We typically focus more on whether the view loads at all, whether the layout looks correct, whether we can interact with it like we normally could, etc. For live connections in workbooks, it's much easier to compare the two.
Tip: Make sure you disable Subscriptions on your test cluster! Otherwise, it's spam city for your users.
Thanks for your reply. Unfortunately, this will not work for me, for two reasons;
1) Because the issue we are testing for is a performance issue, so we have to fully load the test system with users for an extended period of time (1-3 weeks) to determine whether the upgrade we are testing will actually fix the problem we are seeing on the Production server
2) The "test" server is actually an enhanced server environment. What we would like to do, following the 1-3 week test, is to replace the production server with the test server and make the former production server our new test instance. So, we need to actually maintain the full data load on both servers for an extended time.
Given the above, I am looking for a way to mitigate the impact of the dual data impact to the Hadoop cluster. Hence, the question regarding using a share dive set up between the two servers.
Hmm, okay. I guess my question is, what's the nature of the performance issue? Is it that specific vizzes load slowly in your current Tableau Server version that you expect to see an improvement in with the newer version? Or is it more general, such as server-wide performance impacts to the overall user experience? Since you proposed the idea of sharing the TDEs between Tableau Server instances, it seems safe to assume that you're not interested in a full production load, including users logging in, viewing vizzes, publishing, and extract refreshes running concurrently. If you don't care about any performance issues being caused by refreshing data extracts, then I would recommend simply disabling your extract refresh schedules on the test server, at least for your Hadoop content, so that you don't continue harassing Hadoop with extra requests. Then focus on hammering on the vizzes with your test users or automated processes for your performance testing.
There was a bug in Tableau 10 that is supposed to be fixed in 10.1, This bug causes the data engine backgrounders to overrun the server activities causing users to be unable to connect to the server. Since we can't test the fix unless we are doing data extract refreshes along with user access to those data sources and workbooks, we need to build and maintain a mirror environment for an extended period. See issues 572502 & 575935.
Katherine, I looked up both those issue numbers and they don't appear to be related to backgrounders running concurrently with user activity. Could you let me know what your Case number(s) is/are?
Nevermind, I found it. Will reply back...
So yeah--I'm not seeing indications of those issue numbers specifically being a problem of contention between Backgrounders and user activity. In general, if you're running Backgrounders on the same machines as VizQL, Application Server, Repository, etc etc, then they certainly can be impactful to the user experience, but that's always something admins have had to manage by resource balancing between nodes, or scheduling extracts and such during off-hours.
Given that, my recommendation would not be to try and share a drive between the two separate Tableau Server clusters. I don't think that it should be necessary for you to do what you need, there's no supported way I know of to isolate just TDEs on a share without modifying all your data sources...and it's generally just asking for trouble. What I would suggest instead is this:
1. Stand your new hosts up running Tableau 10.
2. Restore a backup (with the --no-config parameter) to the test cluster. Disable all schedules.
3. Confirm that you can reproduce the performance issue you have on your production cluster.
4. Upgrade the test cluster to 10.1, and see if the performance issue still reproduces.
5. Do all your other testing--refresh extracts in a controlled way, check your vizzes, TabJolt stuff, etc.
6. Perform your migration (more steps involved in this, clearly, but that's another topic).