With the opening of our APAC datacenter, we have added support for geo-location to Lab on Demand.  Simply put, geo-location uses the IP address of the computer running your lab or the address of your exit gateway to determine your location worldwide, and subsequently, identify the best datacenter in which to launch your lab.

This is 100% transparent to users, administrators, and managers.  It’s automatic.  It just works.

How it works

Labs have a setting known as Datacenter Availability.  This indicates which datacenters contain copies of which lab files.  For a lab to be considered launch-able in each datacenter, all the lab files must be replicated to that datacenter.

When lab files are available in at least one datacenter in a region, the lab is said to be available in that region.

When a lab is launched through the LMS, the lab instance records the user’s IP address.  This IP address is then passed to Lab on Demand as part of the lab launch sequence.  During the lab launch sequence, a geographic lookup is performed on the user’s IP address from a current geo-location database.  This returns information such as the global coordinates, the city, and state.

This information is then used to calculate the closest region geographically and provide a launch hint.  The launch hint tells Lab on Demand which region is preferred.  Lab on Demand will then attempt to launch the lab in the preferred region, taking into consideration load balancing if the region contains multiple datacenters.  If a given region is unsuitable to launch the lab, the next closest location will be used.  Reasons that could cause a region to be unsuitable include capacity, availability of content, and current load.

Geo-Location and the LOD API

The LOD API has been extended to include the ability to pass both an IP address and a region.  When an IP address is passed, the most appropriate launch region is identified using the method above.  When a region is passed, that region is considered mandatory, and the lab is launched only in that region.  If the lab is not available in the requested region, the lab launch fails.

If both the region and IP are omitted, the lab launch is not subject to geo-location and can be launched from any available region where the lab is stored.

Overriding defaults

There are several ways that the default behavior can be overridden.  API based customers, (customers who launch via our API not our LMS) can provide a region when launching via the API.  This will force the lab launch to occur in the desired region.

Additionally, a series of overrides are implemented with Lab on Demand.  For situations where specific countries, cities, or even IP ranges need to be targeted at specific regions, we can configure rules that, for example, ensure launches in Tokyo always launch in North America, even though it might be closer to APAC.  Over time, this will enable us to tune geo-location or respond to world events.

Implementing geo-location

If you are a customer using the OneLearn Training Management System, geo-location is automatic.  You do not need to do anything.

If you are a customer launching labs via our API, you should be passing the client IP address specified in the API documentation listed above.  Passing the IP will trigger geo-location and ensure you launch in the best region.

If you are a lab author, ensure your lab is replicated to all regions, and users of your lab leveraging geo-location will launch from the best region.

Helpdesk and Support

Users with appropriate permissions can access geo-location data as part of supporting lab activities.  This includes classroom instructors and anyone with access to the lab monitoring tools within Lab on Demand.

We support searching based on location data as shown below.

geo-location display

geo-location map

Finally, access to who can view lab instance location data is governed by permissions, and organizations can only view data for lab instances they own.

Next Steps

As we move forward with geo-location, several new features are planned.  These include:

  1. Geo-location based on the closest Azure Datacenter for labs running in Azure.
  2. Incorporation of ping times and route information in calculations.
  3. Visual representation of launch activity over time.
  4. Visual representation of lab latency over time.
  5. Live views of connection status from global hotspots to individual datacenters.