WormBase Infrastructure
Contents
The WormBase Infrastructure
This document describes the WormBase infrastructure including hardware and software configuration.
General network topology
The network topology of the WormBase site looks like this:
REQUEST
| (Non-accelerated / non-cached reqeuests)
|---------------------------------------------------------------------------
| | | | |
| | | | |
|---------|---------| | | | |
| | | | | | |
| | | | | | |
| \/ | | | | |
| squid | | | | |
| | | www (fe) | | | |
| \/ | | | | |
| load balancer | | | | |
| | | | | | |
|---------|---------| | | | |
| | | | |
| | | | |
|------------------------------| | | | |
| | | \/ \/ \/ \/
|-----------| |-----------| |-----------| |-----------| |-----------| |-----------| |-----------|
| | | | | | | | | | | | | | | |
| httpd | | httpd | | httpd | | httpd | | httpd/ace | | biomart | | future |
| unc | | vab | | crestone | | blast | | aceserver | | | | |
------------- ------------- ------------- ------------- ------------- ------------- -------------
The WormBase infrastructure is composed of:
- a pool of partially redundant web servers running GBrowse, each with all required GBrowse databases
- a pool of partially redundant web servers running the web application
- a pool of redundant database servers running AceDB and MySQL
- a caching/load balancing server that distributes requests to the server pool, aggressively caching responses
- major services are either served on dedicated hosts (GBrowse) or as VirtualHosts on specific servers (wiki, blog, forums)
Servers-at-a-glance
Production Nodes (GBrowse)
| primary name | aliases/other FQDNs | ports* | services | primary purpose | hosted components | acedb? | GFF mysql? | backup |
|---|---|---|---|---|---|---|---|---|
| wb-web1.oicr.on.ca |
ssh: 22 httpd: 80, 8080 |
apache, mysql | no | yes | monthly | |||
| wb-web2.oicr.on.ca |
ssh: 22 httpd: 80 |
apache, mysql | no | yes | never | |||
| wb-web3.oicr.on.ca |
ssh: 22 httpd: 80 |
apache, mysql | no | yes | never | |||
| wb-web4.oicr.on.ca |
ssh: 22 httpd: 80 |
apache, mysql | no | yes | never | |||
| wb-social.oicr.on.ca |
ssh: 22 httpd: 80, 8080, 8081 |
apache, mysql | community components | blog (80), forums (8080), wiki (8081) | no | no | weekly | |
| wb-mining.oicr.on.ca |
ssh: 22 httpd: 80 mysql: 3306 |
apache, mysql, acedb | data mining | yes | yes | monthly |
Development servers
| primary name | aliases/other FQDNs | tasks | ports* | services |
|---|---|---|---|---|
| dev.wormbase.org | wb-dev.oicr.on.ca |
|
ssh: 22 httpd: 80 |
apache, mysql, gbrowse |
'* Firewall exceptions in boldface'
Production nodes
"Production nodes" or "live servers" are the servers that provide all the functionality at www.wormbase.org.
TODO: memcached servers nginx description
web1
This server acts as a proxy for the entire wormbase.org site as well as a standard web node. It fields requests for wormbase.org on port 80 using the reverse-proxy daemon "nginx". nginx distributes requests across a pool of partially redundant webservers, caching the result to accelerate future requests. Principal log files for the site are located here.
wb-web[1-4].oicr.on.ca
cname: none
These four servers act as redundant cluster nodes. Each runs our web app as a standalone FCGI process bound to a TCP socket.
wb-mining.oicr.on.ca
cname: mining.wormbase.org
BLAST and BLAT requests are handled by blast.wormbase.org. Requests for blast analyses at blast.wormbase.org do not pass through the proxy server on fe. blast.wormbase.org is also capable of handling requests load balancing requests but the redirector on fe.wormbase.org is not currently configured for this. Port 80 for blast.wormbase.org is open in the firewall.
wb-social.oicr.on.ca
cname: blog.wormbase.org cname: forums.wormbase.org cname: wiki.wormbase.org
wb-biomart.oicr.on.ca
cname: biomart.wormbase.org
biomart.wormbase.org serves WormMart. Requests to biomart.wormbase.org do not pass through the proxy server on fe.
Development nodes
WormBase also maintains two development nodes.
dev.wormbase.org (brie3)
dev.wormbase.org is the current development server at WormBase. It maintains a CVS-checked out version of the source and database tarballs that is used to automatically push software and new databases onto the production nodes and mirror servers (described below). dev.wormbase.org also hosts the WormBase FTP site, aliased to ftp.wormbase.org.
crestone.cshl.org
crestone hosts the WormBase rearchitecture. Please don't junk it up with files -- disk space is at a premium!
Frozen release servers
freeze1 -- https://freeze1.wormbase.org:8333/
ws100.wormbase.org 143.48.220.44 ws110.wormbase.org 143.48.220.62 ws120.wormbase.org 143.48.220.46 ws130.wormbase.org 143.48.220.65
freeze2 -- https://freeze2.wormbase.org:8333/
ws140.wormbase.org 143.48.220.55 ws150.wormbase.org 143.48.220.66 ws160.wormbase.org 143.48.220.67
brie6 -- https://brie6.cshl.edu:8333/
ws170.wormbase.org 143.48.220.208 ws180.wormbase.org 143.48.220.69 ws190.wormbase.org 143.48.220.192
be1.wormbase.org -- https://be1:8333/
none currently
Typical request flow / infrastructure rationale
The WormBase infrastructure and design decisions are best understood by following requests through the system.
Static pages
First, consider a request for the home page, index.html. This request is recieved at www.wormbase.org by the squid server running on port 80. If this is the first request for the home page (unlikely!), squid passes the request to an instance of the load balancer script. This script rewrites the URL and sends it to one of the back end servers, unc or vab. The back end server returns the page to fe.wormbase.org which caches it in memory and on disk and returns it to the user. Subsequent requests are served directly from the cache, bypassing the back end servers altogether.
Dynamic pages
Consider a request for a typical gene page, unc-2. This request is recieved at www.wormbase.org by the squid server. Assuming that this is the first access of the unc-2 gene page during this release cycle, the load balancer sends the request to either unc.wormbase.org or vab.wormbase.org. The returned page is cached by the squid server and returned to the client.
It is important to note that the Gene page contains dynamically generate images. These images are now generated using absolute URLs. Thus, when a cached gene page is loaded, the client can correctly request the image from the appropriate back end server. For this to work correctly, the back end servers *must* be registered with DNS and have port 80 open in the firewall.
Special cases
- POST requests
Because squid uses URLs as identifiers in the cache, any page view that results from a POST action will not be cached.
- GBrowse (/db/seq/gbrowse)
Requests for Gbrowse (/db/seq/gbrowse) are not cached. Images created by gbrowse_img (such as those embedded on the Gene Summary and Clone pages) *are* cached as these can be considerably more "static" than individual GBrowse views. See the section "Access Control Lists" for additional details. Currently, requests for Gbrowse are handled exclusively by vab.wormbase.org.
- Mailing list archives (/mailarch/)
- RSS feeds (/rss/* and /private/manage_newsfeeds)
- Access log statistics (/stats/)
- The Feedback form (/db/misc/feedback)
These items are all handled directly by unc.wormbase.org (redirection is handled at the level of the redirector on fe.wormbase.org).
- The Cache Manager CGI
The Cache Manager CGI is only available from fe.wormbase.org:81. Note you must be "on localhost" in order to use this statistics viewer.
