Guide to Scaling OpenLDAP

Transcription

2 Table of Contents 1 INTRODUCTION TRADITIONAL OPENLDAP DATA STORES Escalating Database Demands The Cost of Updates Redundant Replicas of the Directory Data Store Deployment Complexity The Costs of Database Redundancy Database Replication Overhead The Hidden Costs of Database Replicas MYSQL CLUSTER AS A DATA STORE FOR OPENLDAP Maintaining Redundancy MySQL Cluster CGE: Smart Network Database MySQL Cluster Architecture Efficient Synchronous Replication Distributed Data Storage to Reduce Costs Geographical Redundancy Simplified Design and Deployment Integrating Directories with MySQL Cluster Scaling OpenLDAP with MySQL Cluster Carrier Grade Edition CONCLUSION REFERENCES ABOUT SYMAS...13 Copyright 2009, Symas Corporation Page 2 of 13

3 1 Introduction Both enterprises and telecommunications companies are reaching new users and building new revenue streams by deploying large-scale directory services over converged telecommunications, enterprise and public networks. These services rely on LDAP Directories as mission critical components of the overall service delivery infrastructure. Directories are used to authenticate and authorize devices and users to the network, and ensure each receives access to the right set of personalized services, with a high quality customer experience. A directory that fails to perform results in missed SLAs and service downtime, in addition to significant risks to both enterprise and user security and privacy. Not only is customer satisfaction adversely affected, but revenue is compromised and the enterprise's brand can be damaged. The directories used by many Communications Service Providers need to scale to 100+ million entries, billions of data points, higher transaction rates and constant updates with strict availability requirements. With the exponential growth in users, devices and services relying on the network, coupled with the need to store richer attributes for each, the performance and scalability of the directory becomes mission critical. New services are at the heart of this need to re-examine the scalability of directories. For example, to ensure portability, contact address books used for wireless applications are now often stored in a directory on the network, rather than on a mobile device itself. Subscriber profiles are becoming richer as they capture network preference and media objects alongside traditional customer contact and service entitlement data. Adding just 1KB of additional data to the profile of 30 million subscribers adds an additional 30GB to the directory. To address such challenges, MySQL has collaborated with industry leading LDAP Directory communities and vendors to integrate the carrier-grade, real-time MySQL Cluster database with LDAP Directory Servers. The OpenLDAP Driver for MySQL Cluster (technically referred to as backndb ) enables OpenLDAP to use MySQL Cluster Carrier Grade Edition as its data store. MySQL Cluster has been widely deployed for subscriber databases within Communications Service Provider networks. Extending this capability, MySQL Cluster Carrier Grade Edition can serve as the back-end data store for OpenLDAP directory servers, allowing users to preserve and enhance their existing investments in OpenLDAP technology, while delivering the required performance and scalability. It allows operators to embark on initiatives that fully exploit user and network data that is currently distributed across legacy applications and networks. In order to deploy a range of next generation, highly personalized services delivered over communications networks; operators need to expose subscriber and network data in a standardized way. Subscriber profiles are becoming richer as they capture network preference and media objects alongside traditional customer profile and service entitlement data. At the same time security and auditing requirements force data to be more transactional in nature. Using industry standard LDAP directories with MySQL Cluster serving as the data store, operators can leverage standard LDAP interfaces for authentication and authorization of devices and subscribers with real-time performance, carrier-grade availability. OpenLDAP, with MySQL Cluster, is a total solution that reduces cost, risk and complexity for large, transaction-intensive directory applications. Copyright 2009, Symas Corporation Page 3 of 13

4 2 Traditional OpenLDAP Data Stores OpenLDAP directory databases have commonly been hosted on the same physical system as the directory server itself. To meet both availability and performance levels, multiple copies (replicas) of the database servers are typically deployed. However, the massive growth in data volumes, coupled with more frequent updates and higher performance demands presents challenges to this approach for certain classes of directory workloads. 2.1 Escalating Database Demands With the introduction of the first standard Directory Database Model (the X.500 Data Model), technology has been developed for storing the underlying data using various storage devices and technologies. The range of approaches goes from text-based flat-files using the standard data interchange format to implementations built on top of Relational Database Management Systems (RDBMSs). There are advantages and disadvantages to each storage technique, depending on the deployment environment. Traditional databases used as directory data stores provide very good storage capabilities with "transaction" wrappers that provide high levels of data integrity during additions and updates. However, the basic design of the OpenLDAP directory server associates a dedicated copy of the database to a running instance of the server software, typically hosted on the same system. Many of these databases do not offer the low level logic to maintain data integrity across requests and updates from multiple OpenLDAP servers, which causes challenges in environments with large directory databases storing and managing dynamic data: Each database server must have all the data for which it may be queried in its local database (referrals across servers are very time-consuming and rarely acceptable) Each database server must process all updates affecting any entries it contains To ensure required performance levels are achieved with these very dynamic workloads, each OpenLDAP directory server typically needs a very large memory (RAM) to hold the directory database in its in-memory cache (RAM), which can increase the cost of the system. 2.1 The Cost of Updates For the largest OpenLDAP deployments, there are specific performance and scalability challenges. In terms of processing overhead, it is much more expensive to update (add, delete, or change) a database record than to read it. This is true of any database system where atomicity, consistency, isolation, and durability (ACID) properties are required. ACID properties guarantee that database transactions are processed reliably. In many database applications a transaction often involves multiple database updates and the design principle of a transaction wrapper and ACID properties provides the ability to consistently undo partial updates, should the transaction fail. The data in a directory database is generally stored in physical structures on storage devices that update multiple physical files when an entry is changed. The storage approaches are all quite different, but even the simplest uses indexes that are independent from the underlying persisted data store. An example of such situation is where an update requires the server to update two (or more) separate files. As a result, directory designers rely, when possible, on database products for the ACID capabilities that wrap the directory's transactions. ACID properties represent a layer of necessary overhead that makes these writes (updates) more costly when compared to reads (queries). Depending on the complexity of the underlying data Copyright 2009, Symas Corporation Page 4 of 13

5 mappings, database updates to the OpenLDAP directory may be from 3-to-10 times as demanding as database accesses to the OpenLDAP directory. There is really no upper bound on this complexity as configurations allow unlimited indexing of entries. The challenge this presents is that OpenLDAP directory servers require databases to handle the increased overhead of updates, with a resulting increase in system cost. 2.2 Redundant Replicas of the Directory Data Store In most OpenLDAP deployments, there are redundant copies (replicas) of the database, which is driven by two powerful design considerations: First, servers and their associated storage systems fail due to hardware, software or configuration faults. Recovery options include either configuring a server and storage system and restore the directory databases on-line from a backup, or having a warm standby backup system ready for immediate deployment. Clearly, for a production database servicing a mission-critical LDAP Directory, finding a server and restoring from a backup tape is unacceptable. It can take hours or days to load the data from the backup and, in the meantime, applications relying on the LDAP server will be unavailable. The only real option is for users to maintain standby servers containing replicas of the master directory database, maintained in parallel and readily available to assume processing in the event of the primary master server failing. The other reason for users to create replicas of OpenLDAP data stores is to meet performance requirements. Despite changing workload requirements driven by on-line applications, typical data stores for OpenLDAP directories process more reads (queries) than writes (updates). These queries are completely independent from one another, and have no impact across replicas. Rather than configure one or two powerful central query servers, it is often more cost effective to distribute less expensive database replicas across the network. Each replica handles its associated load and can be managed independently for capacity and reliability Deployment Complexity This approach results in multiple master directory database servers being deployed. To process database updates, each master server accepts requests from users and applications. Database replication mechanisms must be implemented to coordinate updates across these distributed databases, and provide the logic necessary to ensure data integrity. Called Multi-Master Replication, this capability supports both technical and organizational requirements for distributed master server capabilities. The larger, more mission-critical, and complex the data store of the OpenLDAP directory, the more likely there are to be numerous replicas of the data store under the control of multiple master directory servers. As a result, the overall cost and management overhead of providing the directory data store services can quickly escalate. Copyright 2009, Symas Corporation Page 5 of 13

6 M= Master. R = Replica. H = Hub. R/O = Read-Only Figure 1: Database deployment complexity and cost grows as the OpenLDAP directory data store scales 2.3 The Costs of Database Redundancy While redundant OpenLDAP data stores provide a good solution for some environments, they can present significant challenges for the larger data sets which are increasingly becoming common in carrier infrastructures. The data store replication overhead and cost of the replica servers themselves can outweigh the benefits for more dynamic applications Database Replication Overhead When directory database replicas (copies) receive requests from OpenLDAP servers to update entries, they are forwarded to the designated master server which is responsible for maintaining the master database. The master OpenLDAP directory server processes the change and updates its master directory database. Changes are then propagated (replicated) to all of the subordinate replicas. The replica receives an update request from the master server and processes it into its local copy of the database. There are several mechanisms for propagating these changes from master to replicas, but the goal is to ensure that these changes are made as quickly as possible, while maintaining data integrity across the database replicas. There is a cost associated with the mechanism that propagates these updates to the database replicas. The replication process must ensure that each server receives and updates its local database, in order to deliver data consistency across the OpenLDAP environment. This database replication overhead can reduce the overall throughput of the directory database server infrastructure for the most dynamic applications The Hidden Costs of Database Replicas In addition to the replication overhead, there is also the cost of the actual update to each of the replicas. Once the update (add, delete, or modify) is sent via the replication mechanism, the replica database server has to process it. Each update request from the master to a replica is an update Copyright 2009, Symas Corporation Page 6 of 13

7 transaction. The processing of that update transaction is not radically different than the processing the master server had to do in order to update the master database. As a result, the replica database servers need to be nearly as powerful (and expensive) as the master servers themselves because they have to handle similar levels of update load. It also means that distributing the update load across multiple master database servers is rarely a load-balancing solution because the updates ultimately have to be reflected on each of the masters and all of the replicas anyway. Multi-master solutions can help manage peak loads on particular servers but the aggregate load must be supported also. 3 MySQL Cluster as a Data Store for OpenLDAP On-Line applications, especially within the telecommunications industry, demand directory databases that can scale to 100+ million entries with much higher update rates. The challenge confronting many OpenLDAP developers and administrators today is how to maintain the performance and availability benefits of creating redundant replicas of the directory database, while overcoming the challenges of increased performance overhead, management complexity and cost. It is clear that the architectural model of each OpenLDAP directory server managing its own unique database is no longer viable for the emerging set of large and dynamic directory-based applications. 3.1 Maintaining Redundancy To address the challenges of growing directory databases, hosting OpenLDAP directory data in a database that is shared over a network, transparently providing directory database services, can significantly increase scalability and simplify administration, while at the same time, reducing the costs of redundancy and updates for the most dynamic and write-intensive directory applications. Due to the explosion in available bandwidth and CPU power, as well as cheaper and faster storage (RAM, Disk, SSD), distributed database solutions have become viable for hosting the datastore of an OpenLDAP directory. By using this approach, the number of database replicas can be reduced while lowering the cost of maintaining the database. This solution also provides redundancy features and services that guarantees the most demanding OpenLDAP directory requirements. This is accomplished by eliminating unnecessary copies of the directory data store and the processing needed to maintain those copies, while delivering on the availability and performance requirements. Delegating the management of the OpenLDAP directory data to dedicated, high-availability clustered database technologies addresses the issue of replication overhead and database integrity, freeing up directory servers. All database updates are propagated by extremely efficient and trustworthy mechanisms, at a lower cost and with less overhead of traditional methods. 3.2 MySQL Cluster CGE: Smart Network Database MySQL Cluster 1 is a real-time database that combines the flexibility of a high availability relational database with the low TCO of open source. It features a shared-nothing distributed architecture with no single point of failure to assure % availability, allowing users to meet their most demanding mission-critical application requirements. Its flexible design, supporting both in-memory and disk based data, delivers consistent, millisecond response times with the ability to service tens of thousands of transactions per second. MySQL Cluster supports the ability to perform many administrative tasks online without affecting service, such as scaling processing and data storage, 1 For more information on MySQL Cluster including datasheets, whitepapers, webinars and case studies, please refer to Copyright 2009, Symas Corporation Page 7 of 13

8 performing back-ups, updating database schemas and upgrades of hardware and software within the cluster. MySQL Cluster eliminates the need for expensive shared storage, and runs on a range of commodity hardware and OS platforms, making it the most open and cost-effective database solution for mission critical applications anywhere. Figure 2: The MySQL Cluster architecture delivers carrier-grade availability and performance, without the traditional carrier-grade price MySQL Cluster Architecture MySQL Cluster CGE (Carrier Grade Edition) consists of three different types of nodes, each providing specialized services within the cluster. Data Nodes are the main nodes of the cluster. They provide the following functionality to the cluster: Data storage and management of both in-memory and disk-based data Automatic and user defined partitioning of data Synchronous replication of data between data nodes Transactions and data retrieval Automatic fail over Resynchronization after failure By storing and distributing data in a shared-nothing architecture, i.e. without the use of a shared-disk, if a data node happens to fail, there will always at least one additional data node storing the same information. This allows for requests and transactions to continue to be satisfied without interruption. Data nodes can also be added on-line, allowing for unprecedented scalability of data storage. Copyright 2009, Symas Corporation Page 8 of 13

9 Application Nodes are the applications connecting to the database. This can take the form of an application leveraging the high performance NDB API, such as LDAP servers via a driver to MySQL Cluster. MySQL Servers can be deployed which perform the function of SQL interfaces into the data stored within a cluster. Thus, applications can simultaneously access the data in MySQL Cluster using a rich set of interfaces, such as SQL, LDAP and web services. Moreover, additional Application nodes can be added online. Management Nodes manage and make cluster configuration information available to other nodes. The Management Nodes are used at startup and when there is a system reconfiguration. Management Nodes can be stopped and restarted without affecting the ongoing execution of the Data and Application Nodes. By default, the Management Node also provides arbitration services, in the event there is a network failure which leads to a split-brain or a cluster exhibiting networkpartitioning. With this distributed architecture, where dependencies have been minimized, applications continue to run and data remain consistent, even if any one of the data, application, or management nodes fail Efficient Synchronous Replication MySQL Cluster CGE provides an additional layer of intelligence and automation not found in databases that have traditionally been used to store OpenLDAP data. MySQL Cluster stores the database on a cluster of data nodes and transparently propagates all updates to the cluster via its synchronous replication mechanism. It uses an internal, secure, ACID compliant two-phase commit protocol that is substantially more efficient than traditional database replication. Clusters can also be distributed across geographically disparate sites and kept in sync using an asynchronous replication protocol. As a result, users can deploy MySQL Cluster to host the data store of the OpenLDAP directory, and take advantage of the in-built replication mechanisms to maintain multiple copies of the data. As a result, DBAs can implement replication with significantly less effort and lower cost than traditional approaches. Cluster allows simple, fast and secure replication of data updates Figure 3: MySQL Distributed Data Storage to Reduce Costs MySQL Cluster simplifies sharing copies of the data across OpenLDAP servers. Performance is tuned for shared access and users can easily establish the optimum number of physical data nodes needed to support multiple database replicas, with the required levels of redundancy and performance. Copyright 2009, Symas Corporation Page 9 of 13

10 As a real-time database, MySQL Cluster meets the most stringent latency requirements of communications applications by storing data in memory. This serves to minimize the impact of moving data from a local data store co-hosted on a directory server to a centrally accessed networked database. Traditional OpenLDAP deployments, co-locate the directory and the database on the same server, requiring expensive SMP hardware. As MySQL Cluster can distribute the database across several servers, while maintaining fast access to data storage, the overall memory and system cost can be substantially reduced Geographical Redundancy The ability to withstand site failures by replicating the database of the directory across multiple remote locations is an important capability for many deployments. Geographic Replication with conflict detection and resolution is available as an option with MySQL Cluster, allowing OpenLDAP directory databases to be efficient synchronized across multiple data centers. Figure 4: Geographic Replication extends % database availability across remote locations Simplified Design and Deployment With traditional OpenLDAP data stores, users must carefully configure and deploy master database servers and their replicas to conform to the update limitations of the database server replication protocol. Applications have to be engineered to write changes to one master database server, while reads can be performed on any of the replica database servers. Using MySQL Cluster as the data store for the OpenLDAP directory, writes can happen on any OpenLDAP server connected to MySQL Cluster. This significantly boosts the write performance of the directory data store and is of great importance to feature-rich next generation communications services and networks MySQL Cluster guarantees the integrity of updates, independent of server relationships or network configuration, thereby simplifying the design and deployment of highly available, highly scalable OpenLDAP directories. Copyright 2009, Symas Corporation Page 10 of 13

11 3.3 Integrating Directories with MySQL Cluster Using MySQL Cluster as the OpenLDAP directory data store requires no modifications to the OpenLDAP server or to its applications, ensuring compatibility with existing directory services. An interface to MySQL Cluster takes advantage of the directory server features. Furthermore, directory data managed by MySQL Cluster is also accessible for applications wanting access to it via native NDB and SQL application programming interfaces. 3.4 Scaling OpenLDAP with MySQL Cluster Carrier Grade Edition MySQL Cluster can be used as a data store for directories responsible for the authentication and authorization of devices and subscribers within Communications Service Providers applications. Target deployments would typically involve OpenLDAP directories demanding frequent look-ups and modification of subscriber data, typically with 100m+ entries. MySQL Cluster offers: 1. Seamless scalability upgrade, with no changes to the LDAP applications 2. High rates of directory lookups (reads), 3. High rates of directory updates (writes). Prior to MySQL Cluster, the only real alternative for these demanding OpenLDAP directories were very large SMP systems with vast memory capacity (RAM) acting as a cache for directory data. Using MySQL Cluster as the OpenLDAP data store, a distributed cluster of data nodes, based on commodity systems can each handle a subset of the directory database. By distributing RAM across nodes, the costs per-gb and per-system are greatly reduced. These benefits can be achieved without any significant administrative overhead, while maintaining transparency to the directory service's users and applications, and by preserving and enhancing the inherent value of directory services in the enterprise and telco environment. This approach provides very high levels of performance with massive scalability and predictability. It also dramatically reduces the cost of acquisition, deployment and management of these very large OpenLDAP directory databases. Figure 5: Simplified scaling to handle the most demanding OpenLDAP directory database workloads Copyright 2009, Symas Corporation Page 11 of 13

12 MySQL Cluster Carrier Grade Edition's transparent replication and back-up services also extend these benefits from large, dynamic OpenLDAP directory database to smaller high-value OpenLDAP directory. It makes a great deal of sense to migrate a production OpenLDAP directory data store off traditional database technologies to MySQL Cluster Carrier Grade Edition, long before the growth of the OpenLDAP directory database makes scalability of the data store a major issue. Once that relatively simple conversion is complete, users can grow the directory database using the superior scalability of MySQL Cluster without impacting the directory client applications. 4 Conclusion The growth of on-line services in both enterprise and telecommunications networks is driving a radical change in the way directory servers store and maintain their data. Update rates are increasing, the amount of data being stored for each entry is growing while availability and performance demands are becoming ever more stringent. This demands different database design and implementation philosophies. In many existing environments, the OpenLDAP directory and the database are deployed on the same host. The server has to be equipped with sufficient RAM to act as a cache for the database, thereby supporting response time requirements, and must be powerful enough to process updates quickly. As OpenLDAP directory databases grow in size and updates become more frequent, so a higher load is placed on each directory server. Many OpenLDAP directory database environments deploy multiple redundant systems, comprising masters and replicas, in order to meet availability and performance demands. However, a database replication overhead can be incurred in order to maintain data consistency across database replicas. These conditions cause spiraling hardware requirements, along with increased operational costs and complexity, while reducing business agility. Using the OpenLDAP Driver for MySQL Cluster Carrier Grade Edition, the data store of the OpenLDAP directory can be decoupled from the OpenLDAP directory server, and presented as a shared resource over the network using the real-time, carrier-grade MySQL Cluster database. Using MySQL Cluster's in-built mechanisms for data replication and its real time design, users can increase the performance and availability of their database serving OpenLDAP with lower replication overhead, reduced management complexity and savings in hardware costs. Developers do not need to concern themselves with database replication technologies or High Availability mechanisms, and their applications continue to work unchanged, providing a seamless upgrade to existing OpenLDAP environments. MySQL Cluster Carrier Grade Edition, with associated Professional and Training Services, makes an ideal solution to address the scalability challenges of the most dynamic and fast growing OpenLDAP applications. 5 References OpenLDAP: Symas: MySQL Cluster on the web: MySQL Cluster Datasheet: Copyright 2009, Symas Corporation Page 12 of 13

13 6 About Symas Symas Corporation was founded in The Founders originally set out to develop industryleading and proprietary User Management software. The challenge of collecting, organizing, and auditing all the information about who has access to enterprise information technology is daunting. None of the offerings at the time offered practical solutions and the founders of Symas had an approach that offered unique advantages and real hope of tackling the challenge. This class of technology presents database challenges poorly addressed by Relational Data Base Management Systems (RDBMSs). These challenges were much more directly addressed by the features of Internet Standard LDAP directory data base management software. In 1999 Symas elected to base its development on the then relatively young Open Source Software project, OpenLDAP. The project was working to prepare the University of Michigan's Open Source LDAP server software for broader deployment. It needed significant work on portability, architecture, and functionality. Starting from the beginning, Symas contributed continuously and heavily to the OpenLDAP project as a maintainer and developer. With limited traction for its User Management efforts, the company evolved to survive the Dot-Bomb, doing custom programming, consulting, and continuing to provide enhancements and updates to OpenLDAP. Ultimately, the company focused all its efforts in building a commercial technical support, training, and consulting company around OpenLDAP. Today, Symas is committed to helping enterprises introduce new directory database applications for security, identity and network management and assisting them in converting existing directories to OpenLDAP. As enterprise demand has increased, Symas has responded by increasing its support and strengthening its commercial OpenLDAP offerings. The result is Symas OpenLDAP, the leading distribution of OpenLDAP and associated Open Source technologies. Companies like Yahoo!'s Zimbra unit, Sendmail, MDSI, Ventyx, Airwide, EMC, Sun, and Fidelity National Information Systems rely on Symas and Symas OpenLDAP for directory technology integrated into their offerings. Copyright 2009, Symas Corporation. Symas is a registered trademark in the U.S. and in other countries. Other products mentioned may be trademarks of their companies. Copyright 2009, Symas Corporation Page 13 of 13