In order the get the most out of the best practices developed by Google, you’ll want to do a general overview of every networking topic and then reference individual sections during implementation. If you reach a point in the process where you’re second guessing your actions, it’s time to go back and learn from the mistakes and improvements made by those who went through the migration before you.
Moving your organization over to the Google Apps platform involves four distinct phases. First, you’ll need to evaluate the setup and performance of your network before deployment so that you can easily observe changes that take place during the migration. Next, you’ll optimize your network settings for Google Apps by configuring IPv4 addresses, DNS, firewalls, mail servers, and more. Third, you’ll set up an environment for users all across the network. Last, you’ll monitor the new system and troubleshoot problems as they arise.
Before you move your entire organization to the Google Apps platform, you’ll need to evaluate your network to see if it’s ready to meet the unique load and capacity demands. The best way to do this is to create a test environment where you can measure a variety of variables without taking any risks with your organization’s time or productivity. If you’ve already put Google Apps into place, testing in a sandbox can still prepare you for future expansions or changes. The main goal of all testing is to discover problems at firewalls, routers, and other components responsible for managing traffic in your network.
Knowing every point at which users in your organization will be accessing Google Apps is crucial to testing. First, you’ll need to mark down the name and type of Internet access at the location. For example, this could be, “Austin Office #2, DS3.” Next, you’ll need to mark down the percentage of bandwidth used at both average and peak hours. You’ll then need to get the same peak and average percentages for your firewalls, DNS servers, and proxy servers.You can then use all this data to measure capacity and determine if upgrades are required.
Google Apps uses many different hostnames and URIs for its servers, and they do sometimes change. You can make sure your locations can resolve these servers by following two simple steps:
Your list of domains will not likely be comprehensive, but testing the samples will give you a clear indication of whether or not your locations are resolving the hostnames correctly.
Reaching mail.google.com will be vital to the reliable use of Google Apps, and you can test for solid connections from each of your location by doing a simple ping test. It’s especially important to test that your users on VLANs can connect to the server. If you notice any lag or failed connection, you’ll need to investigate each hop to find out where the problem is occurring.
By using the Hping tool test over a period of time, you can check to see that your TCP and UDP connections to the Google Apps servers will be reliable when it’s time for users at your organization to perform work on the platform. This test can negatively affect network performance, so it’s best that you run them at off hours. If you have the time, run the Hping test for all the hostnames you used in DNS testing.
Like the TCP tests, using the iperf tool to evaluate WAN bandwidth can be very resource intensive, so it’s best to conduct these tests during off hours. This is the point where you’ll find out if there are any internal bottlenecks or problems within each of your local networks. This test is not meant to check connectivity between your systems and the Google App servers. Use, ‘% iperf -c CLIENT IP ADDRESS -d’ for remote locations connected to the WAN, and % iperf -s’ for the network egress location.
If you need more information about where to get testing tools or how to use the commands, reference this Google Apps guide or other online sources. The more comprehensive your testing is, the more prepared you will be for deployment.