Remote Sites

Remote Sites

It would be wonderful if Gigabit could be run to all of your facilities. But the truth is that often you are not able to deploy that speed, because of cost or physical locations of buildings. Once networking speeds get below 100 Megabit, you will no longer be able to use native X windows and must consider deploying products that compress presentation data. Microsoft RDP will do this, along with Citrix Metaframe, tight-VNC, and NX/Nomachine.

Most of the products the author has tested that compress data seem to become usable around 100K of speed. Dialup connections will work, but repaints will be tedious and not very efficient. A good formula to use is to multiply the number of concurrent users at each remote site by 100 to get a rough estimate of bandwidth required. Using this formula, 3 concurrent users would require roughly 300K of bandwidth. Remember too, that very possibly print jobs will be running on the same circuit, which will consume bandwidth as well. The user community will perceive 'slowness' mostly in the user presentation itself. Print jobs that take a bit longer are not normally noticed. So, one might consider running two circuits to remote sites and splitting the user sessions on one, and the print jobs on the other. That way if massive print jobs are sent, the users won't notice and can continue working. It should be noted as well that some bandwidth management products such as Citrix have designed their software to support printer connectivity that is also compressed.

The most important issue with remote sites is stability and uptime. When you centralize all of your software, it's critical that the network be available or users will not be able to log into the servers and do their job. Many people do not care how it works, just that it's reliable. Consider all of your options such as T1 connections, DSL, and cable modems and then select the solution that seems like the best fit. One effective method is to create a list of all available networking methods, and then create a chart that clearly spells out the features and speed available within each category. As the line becomes cheaper, it normally becomes slower. The decision makers need to understand that at a certain point presentation and software application speed will start to degrade. It is also important to obtain from the vendor exact service levels for each of the connection methods. Commercial and business lines often will guarantee a minimum amount of bandwidth. Regular home-use circuits often are rated for 'burst rates' and run considerably slower than the specifi ed rate.

Some remote users will be using wireless connections. They too will require an application that will perform compression, and should be considered as well. Cellular wireless broadband is providing plenty of bandwidth these days to run with centralized computers.

Thin Client Network Connections

Once you have performed the steps as outlined previously, you will need to finalize your design for the thin clients themselves. If your current deployment is only capable of 10 Megabit, you will definitely want to upgrade the wiring and move to a minimum of 100 Megabit. 100 Megabit provides plenty of bandwidth for very crisp response time from the servers, and mouse and user interface response is excellent. At the time of this writing, running Gigabit to the desktop has not been tested by the author; but if your thin clients support that speed that is an excellent buffer and should provide even greater capabilities. If users are using devices such as laptops, always encourage them to use a wired connection in the office. In the case of X windows, it will avoid having to use a licensed bandwidth compression interface.

At the time of this writing, Gigabit connections to the desktop are becoming more and more commonplace. If part of your deployment is a redesign of the network, run the highest-rated wiring that you are allowed. The author is anticipating that Gigabit thin clients will become available very shortly. More and more software is making use of the 3-dimensional capabilities of thin client video cards, and each step in this direction requires additional bandwidth.

Testing the Network

Anyone that has supported users knows that often they will discover things that the technical staff never anticipated. It's important to turn that into a positive, and isolate as many problems as possible before final deployment. It's effective to place a few thin clients at each of your sites, and on each of the networking technologies that you have selected and perform their regular day-to-day duties. Some types of connections such as X windows sessions are not stateless, and will drop if the network under-performs. If you are considering a new vendor for networking hardware, they should allow you to install demo devices and test them on your infrastructure. Be mindful that sales people sometimes over sell their products or don't understand exactly your design goals, so a real-world test with their hardware before major purchases is always a good idea.

Summary

In this chapter we see that though the complexity of networking cannot be stated strongly enough, it is important to design a rock-solid and stable network before your deployment begins. Follow standard methods and designs and work with your hardware vendors to make the best possible use of their equipment. Once you plug the thin client in the wall, you will be excited at the things to come and will be ready to configure the application servers.

Read Review on this Book 

This book is available for purchase at packtpub.com Linux Thin Client Networks Design and Deployment