CHAPTER 4 |
Deployment Scenarios |
This chapter provides a case study from which three different scenarios--consumers, virtual hosting, and horizontal scalability--are prepared.
SIMS concepts will be described within the context of a common usage model: a case study of a company deploying SIMS as its email system. By describing the SIMS concepts around the various scenarios that come out of the case study, this chapter should provide a context for these concepts.
Topics in this chapter include:
|
|
Defining a case study |
|
|
Consumer hosting scenario |
|
|
Virtual hosting scenario |
|
|
Horizontal scalability virtual hosting scenario |
The first step for defining a case study is to define the requirements and configurations of the subscribers that are to be hosted by a service provider. This section identifies these criteria.
See "Delegated Management Administration" on page 107 for domain hosting feature components and specifications, including the Delegated Management Console and Domain Management server.
The scenarios in this case study assume that only native Internet clients are being supported, using the standard Internet email protocols (SMTP, RFC822, MIME, IMAP, POP3, and so on.).
This case study uses an SP called Bridge Corporation: a rapidly expanding SP (telecommunication and Internet) company. Bridge uses two domains: bridge.com for its internal mail and bridge.net for its customers.
Bridge's Services
The following are the types of services that the example SP, Bridge Corporation, will provide for its subscribers:
|
|
Email hosting |
|
|
Web site hosting |
|
|
Delegated Management hosting |
|
|
Electronic commerce hosting |
|
|
Mail applications |
This case study uses four different email subscribers:
stream.com
| Summary: Medical group. |
Users: Approximately 150 employees.
Email Usage: Ownership and control of electronic distribution of company approved news bulletins and specialized mail distribution lists.
green.gov
Summary: Environmental organization with interests in extensive research.
Users: 20,000 spread among three permanent offices in the U.S., Mexico, and South Africa. 5,000 who work primarily in the field, at research and consumer sites.
Email Usage: Email is a primary means of corporate communication, including a variety of departmental distribution lists.
forest.edu
Summary: Regional community college.
Users: 100 full time staff and faculty, 75 to 100 interim and visiting faculty. 3,000 to 6,000 students, all at a single site.
Email Usage: Administration uses email to distribute class schedule and other announcements. Faculty use at their discretion. Email accounts offered to all students while they are actively enrolled.
ocean.org
Summary: Non-profit scientific research organization.
Users: 30 employees at a single site.
Email Usage: Internet savvy. It uses email to communicate with other organizations interested in their research, and to issue newsletters to contributors.
In these scenarios, all of the user and domain properties are stored in a Directory Service. Objects are retrieved from the Directory through the Internet Standard Lightweight Directory Access Protocol (LDAP).
The Directory Information Tree (DIT) is organized to provide a simple algorithmic mapping between distinguished names and Internet domain names. See "Directory Services" on page 71 for definitions on distinguished names.
The DIT for this case study is shown in FIGURE 4-1.
FIGURE 4-1 Directory Information Tree for the Bridge SP Case Study
The Directory Component (DC) tree is rooted at the name O=Internet. Each of the components of the domain name is mapped to a domain component relative distinguished name. TABLE 4-1 shows the mapping of the subscriber names that are used in this case study
TABLE 4-1 Domain Distinguished Names (DN)
Traditionally, the SPs have provided access, such as email and other Internet-based services to the consumers or residential.
See "SIMS Topology" on page 11" for Enterprise and SP messaging topology for the SIMS system.
FIGURE 4-2 shows the configuration for the consumer hosting of email services.
Historically, the SP provides the consumer with just a plain, unprotected IP router. The consumer operates and maintains their own application servers, including the email server, DNS server, and (if needed) LDAP server. For their own protection, the consumer must operate through a firewall that filters out undesirable packets and insulates the organization's internal network from the Internet. Notice that for many organizations, especially small ones, the email server may actually be the firewall system.
FIGURE 4-2 shows only a single mail server per consumer. Organizations larger than 100 members or more usually deploy separate hosts for their direct connection to the Internet (the MX-based host) and for their mailboxes.
Recall that each mapping from a domain name to an IP address is called a record in DNS. Among several types of records is the MX record, which is short for Mail Exchange. To process an email message, a mail server program such as sendmail looks for this record of the destination address before checking other types of records. An example of an MX record in the master DNS database for the domain that is to receive the email is MX 10 mailhost. The DNS database, in turn, is a file that contains mappings from the name of a domain or a host to an IP address. The host which keeps this database is called the DNS server.
This ensures that if the MX-based host is attacked from the outside, users within the organization will be able to read their mail and exchange new email with each other. Many sites will use multiple MX-based hosts, for reliability if not for improved bandwidth. And even modestly sized companies will use multiple internal mail servers, as fits their own internal organization.
A consumer site connects to the SP Point of Presence through either leased line or dialup. In leased line access, the consumer has a permanent physical connection between their network and the SP. This provides the most reliable service, and is required if the consumer is hosting interactive services like HTTP, FTP, or Remote Access. Popular mechanisms include analog leased line, Digital Direct Data service, T1, Fractional T1, and T3. Newer mechanisms that are currently growing in popularity include cable modems, DSL, and ATM.
In Dialup access, however, there is no connection between the consumer site and the SP except when there is traffic. For very small sites or organizations that have very little Internet traffic, this can be much cheaper than a leased line. The most common mechanisms are analog dialup over standard telephone lines and ISDN.
This email server is associated with mail access systems. The SP consumers who wish to read their mail will need to connect to this server. IMAP/POP proxy could be configured here.
The SP operates a DNS server that provides the following services:
|
|
Primary master server for the SP's own domain, bridge.net |
|
|
Designate as the root server for all consumers |
|
|
Primary master server for consumers who do not wish to maintain their own public DNS server |
|
|
Secondary server for consumers who prefer to maintain their own public server. |
The consumer hosting scenario shows an SMTP relay host that is managed by the SP. This can offer a number of value added services, for which the SP may charge additional fees.
The relay host can be configured as a low precedence MX host for the consumer's domains. This allows the relay host to accept and hold the consumer's email when their mail server is down.
Certain low volume consumers use dialup access, as explained above. The relay host provides message storage for these consumers when they are not connected. These sites must periodically poll the relay host to retrieve their incoming email.
The relay host imposes a significant management burden on the SP. Consumer email may live on this server for an indefinite time, raising issues of backup and failure recovery. If one of the consumer servers fails because of being swamped, then the consumer's email may roll over to the SP's relay host. Because of this, most SPs do not offer a relay host for those consumers that are hosting their own email server.
In the consumer hosting scenario, the LDAP Directory server is located at the consumer's site, which can be operated by the consumer. Currently, most organizations do not expose their LDAP servers to the public network for security reasons.
Consumer hosting required a separate mail server to be supported by the SP for each domain. While this architecture is well understood and easy to manage, it is not cost effective for small domains. In addition, as the number of domains increases, the management of the individual services becomes increasingly unwieldy. For this reason, virtual hosting that supports a single mail server which can support many domains would be the choice.
The goal of virtual hosting is to provide an environment in which the difference between physical versus virtual hosting is transparent to the consumers.
FIGURE 4-3 shows the architecture for the virtual hosting topology. The difference between the consumer hosting scenario and the virtual hosting scenario is that the virtual scenario uses fewer number of servers to service the domains for which it is hosting.
The resources used at the consumer site are the same as used at a consumer hosting scenario, where the consumer's mail servers are moved to the SP's site. Ideally, the consumer should not need to make any changes to the configuration. This may not be achievable, however, because of the limitations in IMAP, POP3, and SMTP.
Most business consumers who purchase email outsourcing will use the same type of connections to connect to the SP site.
These servers provide the interface to the consumers, including POP3 and IMAP message storage and retrieval, SMTP message submission, and (if offered) HTML-based mail client services.
As shown in FIGURE 4-3, green.gov is assigned to the first mail server, stream.com and forest.edu is assigned to the second mail server, and stream.com (again) and ocean.org and are assigned to the third mail server.
In a classical Internet email server, the domain name is discarded when the messages are delivered into the message store. This behavior is still supported, and is called the Canonical Domain for the server. In addition, the server supports any number of hosted domains, where the server preserves the domain name when the messages are delivered into the message store.
An SP will normally set the canonical domain to its own domain name, for example, bridge.net. If this server is being used for both residential users and outsourcing users, then it may makes sense to assign the home users to the canonical domain, and the outsourcing users to an appropriate hosted domain. If the server has only outsourcing users, then the canonical domain may be empty or used only for administrative mailboxes.
The two SMTP relay hosts provide the mail interface to non-consumers. Their function is essentially identical to that used in the consumer hosting.
All incoming email is directed to these hosts via MX records, and is then forwarded to the specific server via the routing tables in the IMTA. All outgoing email is directed to these hosts via the routing tables in the consumer email servers.
The LDAP directory is used by the IMTA to retrieve local user and group address information. When the IMTA receives a message, it uses the directory information to determine where the message should be delivered. The message store uses the directory services to authenticate users logging into their mailboxes. The message store also obtains information about user message quota limits and message store type (IMAP or POP).
In general allocating a server in a virtual hosting scenario that is capable of supporting the entire user base is not practical. Distributing different domains over different servers does distribute the load, but it requires that all users for a domain be contained on the same server.
Adding horizontal scalability to virtual hosting provides the following benefits:
|
|
Domains can span over more than one email server, either to improve availability or because the domain has too many users to be supported by a single server. |
|
|
New users can be added to whichever server has the lowest load. A new server can be brought online and immediately start supporting new users from all domains, without having to move existing users to the new server. |
|
|
Authentication and Web Access services (HTML to email) can be off-loaded from the backend email servers. |
FIGURE 4-4 shows the architecture for horizontally scalability scenario. There are two fundamental changes from the consumer hosting scenario. First, each mail server is now responsible for more than one single consumer domain, just as was the case with the virtual hosting that was described in the previous chapter. Second, instead of connecting to general purpose email servers, the consumers connect to Proxy servers, which hide the underlying distribution of consumers across multiple backend message store servers.
The resources used at the consumer site are the same as used in a consumer hosting scenario, where the consumer's mail servers are moved to the SP's site. Ideally, the consumer should not need to make any changes to the configuration. This may not be achievable, however, because of limitations in IMAP, POP3, and SMTP.
Most business consumers who purchase email outsourcing will use the same type of connections to connect to the SP site.
These servers provide the interface to the consumers, including POP3 and IMAP message retrieval, SMTP message submission, and (if offered) HTML-based mail client services. The proxy servers insulate the end users from the underlying mail server architecture, as well as off loading some computation from the message stores servers.
The POP3 and IMAP services are true proxy servers. For each connection, they authenticate the user, consult the Directory Services to determine which message store server contains the consumers INBOX and folders, open a connection to the message store server, and then drop into a pass through mode, relaying packets between the client and the real server.
The SMTP service functions as a relay. Messages for other SP consumers are routed to the appropriate message store server; however, messages for users outside the SP are routed to one of the relay hosts.
Note that the Proxy servers are identical, except for their node name and IP addresses. The only persistent data are messages in the IMTA queues. If needed, servers may be added to support the load.
The message store servers hold each user's inbox and personal folders. The Proxy servers and the SMTP relay hosts are the only hosts that connect directly to the message store servers.
The two SMTP relay hosts provide the mail interface to non-consumers. All incoming email is directed to these hosts through MX records. All outgoing email is directed to these hosts via the routing tables in the Proxy servers. Their function is very similar to that used in the consumer hosting.