Shinydrive Network Deployment Configuration Options

Introduction

When deploying Shinydrive in your network environment, it’s important to look at the overall environment and where there are potential issues. Once you have a clear picture of where the potential issues could be, you can develop strategies to test and mitigate them. We will outline a sample of a simple and reliable configuration, an advanced configuration, and a configuration that is not recommended.

Simple and Reliable Configuration

The minimal model is best for small deployments or as a starting step for a larger deployment. Shinydrive works best when on the same machine as Content Server. One important reason is how “chatty” cws and sd-csws are. These calls are best handled at a local machine level, reducing network traffic and also reducing the risk of connectivity issues. With this setup, you will be able to clearly identify if there is an issue with clients connecting to the Shinydrive server as there is only one HTTP stream (per client). The red pipes in the diagram represent the risk areas in an environment. If all of those risks are on a local machine, it will dramatically reduce the risk of a link in the “chain” breaking, which would cause a poor user experience (disconnections, errors in operations, etc.).

Advanced Configuration

The advanced model is best for large deployments with a need for load balancing client requests due to the number of users accessing content. This model is fantastic for high availability and fault protection, but it comes with risks that need to be assessed. Each red pipe and arrow outside of the machines represent areas of connectivity concern. The connection between Machine 1 (Content Server Database) and Machine 3 could fault meaning the machine cannot access the Content Server database, which would mean the end-user ends up with an error. The same could happen with the EX Store connection. Even a load balancer can lead to loss of connectivity mid switch. These are some of the expected risks when deploying with a similar model, you will need to ensure you have tests to ensure those streams don’t break and if they do, how to identify it. Shinydrive does a great job in its current form detecting a break between the client and the Shinydrive Server, if it is not able to reach the server, it will go into offline mode. Conversely, it is difficult for Shinydrive to detect failures in connectivity between Content Server and web services or between Content Server and its database or EX Store. It should also be noted that in this setup. The Shinydrive Server needs to always be identical to the others. Please see our Administrators Manual for more information on how to achieve that.

Not Recommended Configuration

This model, though very similar to the “Simple and Reliable Configuration” model, imposes new and unnecessary risks. As mentioned, the cws and sd-csws services are very chatty. Separating those services from Content Server can lead to losses in communication, which would result in users receiving errors when they are doing their day-to-day operations. That means more calls to IT and frustrated users.

Conclusion

You need to have testing, verification, and knowledge if you veer away from the simple model.

Every additional switch, load balancer, and external connection has a chance to fail. The key is being able to identify where the failure happened, why, and how to prevent it through various diagnostics and monitoring utilities. It’s easier to start simple and build up versus starting advanced and trying to find which link in the chain broke.