In our first installment, Jamie discussed how for some organizations, the worst thing that can happen to them is unbridled success. As companies move their operations to the Internet, they play a balancing act of getting and keeping users while supplying them with a worthwhile service. This installment will deal with specific examples of how this balance can be achieved, whether you run a web server, e-mail server, or database server:
Specific Examples of Horizontal and Vertical Scaling
This section will show you how to scale three specific applications horizontally and vertically; Apache web server, an E-mail solution, and a MySQL database. By using this design philosophy, you will see why it is so important to be able to scale your applications.
• Apache Web Server
Since every company on the Internet runs a web site, Apache is a good example of an application that can scale to meet demands. A typical example is a company running a web server at www.company123.com. All requests are served by one main web server. To scale this horizontally, install another server with the exact same configuration and data files, but with a different IP address than the first server. Then change the DNS name www.company123.com to point to two A records, the two IP addresses of the servers. This is an effective round-robin scheme. If one server dies, you can either change the DNS name for www.company123.com, or add a second virtual interface to the box that is still running.
In order to scale this web server vertically, you could install extra servers such as images.company123.com and cgi.company123.com. Users would continue to connect to www.company123.com, but all of the HTML can point to images.company123.com to serve graphics, or cgi.company.com to serve cgi scripts. This way any changes you need to make are completely transparent to the user: they don't need to know what's happening behind the scenes. If one of the images servers becomes overloaded, just add another images.company123.com, which gives you the ability to scale both horizontally and vertically. Using this strategy, you should be able to scale to meet any demand.
• E-mail Solutions
E-mail can be both one of the easiest and most difficult applications to scale. Commercial software available from Netscape and Software.com has the capability to scale right out of the box. It is also possible to scale e-mail with freeware products such as sendmail and qpopper.
The basic way to run an e-mail server is to have one main server provide services in three areas: outgoing mail, incoming mail, and mail (POP or IMAP) retrieval. For a small organization, running all three on one main mail server may work well, but as growth occurs, e-mail is one of the first things to feel the effects of system overload. E-mail is an application that always has to run perfectly, making it a good candidate for horizontal and vertical scaling.
The first step in scaling e-mail is to break out all three services onto different servers. One server can handle outgoing mail, one handles incoming mail, and one stores the mail that users retrieve. In the case of outgoing mail, users would have to configure their e-mail clients to use a specific outgoing mail server name, such as mail-out.company123.com. Incoming mail is handled through an MX record for your domain. In this case, point your company's MX record to mx.company123.com. Lastly, the mail store could be called something like pop.company123.com. Clients could then connect to this server to retrieve mail.
With this design strategy, it is easy to add extra servers in almost any area. If the outgoing mail server becomes overloaded, install a second one, and use DNS to point your clients to both of them. The major difficulty in this strategy is the mail store. Using a freeware e-mail POP or IMAP solution makes it difficult to balance users across different mail stores. If you can only have one mail store, this server would need to have abundant resources to handle demand. A possible way around this problem is to give users specific incoming e-mail servers, such as pop-accounting.company123.com or pop-east.company123.com. That way you can install multiple servers to serve each division, avoiding the difficulties of scaling one big server to handle all of the e-mail requests. The same concept applies to databases as other applications. You can install multiple servers with the same data.
• MySQL and Other Databases
By now it should be apparent how to scale any application. MySQL is a freeware database that is often used in conjunction with the Apache web server to do user authentication, store information, or dynamically generate content. The same concept applies to databases as other applications. You can install multiple servers with the same data. Individual users or the web servers could connect to them in a round-robin fashion. Alternatively, if a user authentication database is heavily used, it can be broken out into its own server. The web server could point to the database on the server auth.company123.com for authentication, or content.company123.com for dynamically generated content.
Putting it all together
Just about any application can be designed so that it can scale both horizontally and vertically. Detailed knowledge of both the application software and the hardware it will run on makes the job of scaling an application much easier. The benefits from this design are enormous as your servers will experience increased uptime and your organization will have greater user satisfaction. By using this design strategy, your organization will be able to handle the demands of exponential growth.
Jamie Wilson has worked in the online adult industry for well over a year. He specializes in Solaris, Unix, and Web consulting, as well as providing content to adult webmasters. He can be reached for follow-up inquiries at jamie@jtwis.com, or for adult content please visit www.jtwis.com/content