URL Redirection System for the Mirror Network

From Apache OpenOffice Wiki
Revision as of 10:10, 28 March 2010 by B michaelsen (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
  • Status: Brain storming

Introduction

Background

The OpenOffice.org Mirror Network consists of several mirror servers spreading over the world. Each mirror server has its own URL. Meanwhile, Download Central could not list all mirror servers in its Web page.

One of the possible solutions is to utilize URL Redirection. URL Redirection is one of the techniques to guide users to appropriate Web site based on certain criteria.

With URL Redirection, a download request by a user could be automatically transferred to one of the mirror servers closely located to the user.

Goals

  • Running 24 hours, 7 days.
  • Ease of use for users, mirror server administrators, operators, members of release engineering team network administrators, and staffs of the mirror project.
  • Ability to measure statistics of requests.
  • others, ...

URL Redirection System

Deployment

To keep the system run around 24 hours, 7 days, at least two servers would be necessary. Each server could be located in individual county for some reasons:

  • Blackout.
  • System might crash, parts might get broken, ...
  • Load balancing.

Deployment of redirector 2008-12-11 by tora.png

Network Diagram

The URL Redirection system would be composed of several servers:

  • Mirror servers
  • Subversion server
  • URL Redirection servers
  • DNS servers
  • Some PCs

Network diagram of redirector 2008-12-11 by Tora.png

Users' view

  1. A user visits a download Web page such as Download Central, OpenOffice.org download, and click on one of the links to download a OpenOffice.org.
  2. User's PC make a DNS query to resolve an IP address.
  3. DNS server responses with two IP addresses: IPs of Redirector #1 and #2.
  4. User's PC randomly choose one of the IP addresses and make a request to the Redirector addressed by the IP address.
  5. Redirector #x processes the request and responses with a HTML page if the request pointing to a directory or responses with a new location addressing to one of the mirror server.
  6. User's Web browser does rendering the HTML page or starting to download the file.

Mirror server administrators' view

  1. An administrator checks out a Subversion repository of mirror site configurations.
  2. The administrator locally update the configurations and then checks in the modifications.
  3. The SVN module in each redirection server periodically updates its local repository by getting the modifications.
  4. The SVN module updates DB with the latest data.
  • Activities of modification are openly kept under surveillance with Subversion Web browsing system.

Staffs and developers' view

  1. A staff updates mirror site configuration with Subversion.
  2. A developer creates new version of the system and upload the program to the staging server in the redirection server.
  3. Testers conduct a test of the new version.
  4. An operator switches the production server and staging server.
  5. The operator switches back them if something goes wrongly.

Network administrators' view

  1. A network administrator tweak DNS entries to make all requests address to one of the redirection servers if planed blackout is coming or a task of maintenance is scheduled.
  2. The network administrator makes it back after the things are finished.

Life Cycle

Stages

  1. Migration to MirrorBrain, launching the initial small system.
  2. Migration of mirror site configurations to OpenOffice.org Subversion server.
  3. Launching the second redirection server.
  4. Enhancing the system.
  5. Closing when the system becomes no longer needed.
Personal tools