"Your mission, should you choose to accept it, is to deploy the largest LDAP directory in the world." This challenge was presented to me upon joining NetNumber, a startup located in Lowell, Massachusetts. NetNumber is engaged in building a potentially massive directory that will be used to map telephone numbers to Internet addresses. Possible uses of such a directory include:
The primary users of such a directory would include phone switches (PBXs), voicemail platforms, and unified-messaging platforms. To illustrate how this might work, imagine that you work for a company that has replaced its aging PBX with one of the new IP-enabled PBX switches such as the 3Com NBX. You pick up your phone and dial the number of one of your suppliers in Taiwan. Rather than simply handing off the call to the public switched telephone network (PSTN), guaranteeing a hefty toll charge, the IP-PBX software issues an LDAP query, retrieves the addresses associated with the phone number, and contacts your supplier's IP-PBX over the Internet to set up the phone call. Other than the cost of the bandwidth used during your call, the phone call is free.
While the overall concept of our directory is simple, the fact that there are over a billion phone numbers in use around the world affected our directory design in two ways. First, a billion numbers is a great deal of data, especially when each number could have many addresses associated with it. For example, a single phone number might have addresses for email, voicemail, voice-over-ip, and a domain. The second issue was one of scale: Once IP communications reach critical mass, we could expect thousands of LDAP queries to bombard our servers every second. We knew, therefore, we would need an LDAP server with a world-class database engine married to an industrial-strength protocol server.
Another important design element involves the manner in which data might be distributed across multiple directories. Distributing the data across multiple directories can be considered a good thing because it decreases the burden on any given directory server. However, our requirement to allow reverse-lookups (i.e., give me the telephone number related to this email address) mandated that the number of directory partitions stay relatively small. (Since the directory would be partitioned across phone numbers, reverse-lookups would require each directory partition to be queried until the desired data was located.)
After much deliberation, we settled on an initial design that called for three directory partitions, each having at least one mirror for performance and fault tolerance. Partitioning would be accomplished by implementing two physical tiers: DNS servers and LDAP servers. DNS servers would form the top tier and, given a phone number, would point to the LDAP server authoritative over that number. As far as which LDAP directory to deploy, there was really only one choice: Oracle Internet Directory (OID). While there are several other directory products that would be excellent choices for small- to medium-size implementations, only OID could provide the database muscle required by our application.
|
Related Reading 
|
In addition, only OID included the ability to partition data files, and to access data from multiple clustered servers. Whereas most LDAP servers perform well only when the entire directory is loaded into memory, OID takes advantage of the underlying Oracle database's ability to efficiently shuttle data between disk and memory. For example, we utilized Oracle's partitioned cache to specify which tables should stay in cache, which should always be accessed on disk, and which should be moved in and out of cache as needed. Finally, we would take advantage of OID's multi-tier architecture to deploy the LDAP server and database layers on different server clusters.
Our directory implementation would consist of a shallow, wide tree with a single parent node. The exact notation of the parent node is still under debate. NetNumber recently submitted a proposal to the Internet Corporation for Assigned Names and Numbers (ICANN) to run a global .tel registry for the purpose of telephone number registration. The telephone numbers form the leaf nodes of the tree, upon which various object classes would hang. A single access-control attribute at the parent node allows public access to all leaf nodes. For example, a query to determine the Session Initiation Protocol (SIP) address for phone number 1-123-456-7890 using the LDAP URL format would look as follows:
ldap://<hostname or IP address>:389/e164=11234567890,
dc=tel?sipuri?base
In our labs, we tested several highly scalable configurations of the directory, including the application of Oracle Parallel Server to the OID database. For our first deployment, however, we opted to run both the LDAP server and database on a single 6-CPU Sun Enterprise 4500 server with dual fiber links to an EMC Symmetrix storage system. In order to provide a high level of availability, we deployed a duplicate system and wrote custom scripts to maintain a standby database on the second server. We then loaded the directory with 10 million test nodes (one node = one phone number) and, over the course of a month, proceeded to bombard the server with 330 million LDAP queries. Outside of a five minute loss of service, the OID server performed admirably, producing an average response time of 130 milliseconds.
After many months of planning and testing, I would like to be able to report that our LDAP directories are ready for global deployment. However, recent standards proposals within the Telephone Number Mapping (ENUM) working group of The Internet Engineering Task Force (IETF) dictate that DNS reside at both tiers of a telephone number registry. DNS in the second tier is far less flexible than LDAP, and eliminates the possibility of reverse-lookups. However, in the interest of providing standards-based services to its customers and partners, NetNumber has recently deployed the world's first ENUM-compliant telephone number registry under the domain e164.com. NetNumber is also an active participant in the ENUM working group.
Like LDAP, DNS has never been deployed on such a massive scale, which leads me to issue a challenge of my own: Your mission, Oracle, should you choose to accept it, is to build a next-generation DNS server much like what you've done with LDAP. We'll be waiting.
Alan Beaulieu is a Principal Software Engineer with NetNumber, and is currently responsible for leading the design, development and operations of NetNumber's Oracle database and LDAP directory products. Prior to joining NetNumber in January 2000, Mr. Beaulieu ran his own consulting practice, specializing in the design, construction, and implementation of large, mission-critical data warehouses for major financial services companies in the Boston area. Mr. Beaulieu holds a degree in Operations Research Engineering from Cornell University. He can be reached by email at alanb@netnumber.com.
Copyright © 2007 O'Reilly Media, Inc.