| Highwinds Software Product Documentation: Typhoon, Twister, Tornado, Hurricane, and Cyclone | ||
|---|---|---|
| <<< Previous | Chapter 4. Tornado Configuration Guide | Next >>> |
For several years, Highwinds Software has offered Chaining in both the Twister and Typhoon products. Chaining was an attempt to solve the problem of vast storage costs and does an adequate job in some circumstances, but falls short in many others. Chaining is not spool sharing in the conceptual sense, but it does provide a way to share articles among multiple chaining slaves. Several downsides to chaining make it impractical in most situations:
Chaining Slaves must have 33%-50% as much disk storage as the Chaining Master.
Chaining Slaves are not optimized for article sharing.
Chaining was designed when Usenet volumes were less than 1/10th they are today.
Tornado picks up where Chaining leaves off.
Tornado provides the following:
Spool Sharing (Direct SAN, shared FS (UFS, QFS, VXFS), or IP)
Spool Aggregation
Optional Article Caching
Seamless Failover
Redesigned Overview System for faster NNTP XOVER requests
Intimate knowledge of back end articles avoiding the need for NNTP based requests.
Tornado is comprised of two components that run on separate physical servers, Tornado Front End (the customer facing side), and Tornado Back End (the "spool manager", per se). Tornado Front End acts as a customer facing server to a Tornado Back End by handling all of the Usenet client requests, while at the back-end, the Tornado Back End server stores and accesses all of the Usenet articles. Tornado Front End handles all overview requests (NNTP XOVER) by reading off of its local, optimized overview system, greatly reducing the workload the Tornado Back End has to handle. When a client requests an article, Tornado Front End can read off what it thinks is local disk. If that fails, the request forwards to one of 256 Tornado Back Ends where the article is retrieved and delivered to the client over the IP network.
Since Tornado Front End can communicate with up to 256 back-end servers and it has intimate knowledge of the completeness and spool layout of up to 3 of those servers, Tornado Front End allows load balancing and increased article completeness. Furthermore, Tornado Front End has a timestamp associated with each article it has knowledge of and can offer arbitrary retention to different classes of users. For example, say the back-end server farm had 60 days of retention for a certain group, yet non-premium users should only be shown 7; Tornado Front End can support this scenario.
Tornado Front End successfully offloads all of the following from a Tornado Back End server (or off an otherwise front-end Twister server):
Network Connects and Disconnects
Authentication
Overview Lookup and Caching
Without the additional overhead of these tasks, Tornado Back End servers are significantly more available to handle spool requests and management.
| <<< Previous | Home | Next >>> |
| Tornado Configuration Guide | Up | Tornado Benefits |