This chapter describes some example deployments to help familiarize you with how the proxy server works.
This chapter includes the following sections:
There are many types of deployment in which the proxy can be used successfully. The two most common types of deployment with the proxy are
Load balancing
Distribution
To decide which type of deployment to use, consider where and how your data is stored and how much data do you handle.
If all your data is stored on a replicated data store, then use a deployment with load balancing. See Section 3.2.1, "Configuration 1: Simple Load Balancing."
If your data is partitioned or if you have a large database and want to split your data so that it is partitioned on different data sources, then use a deployment with distribution. See Section 3.2.2, "Configuration 2: Simple Distribution."
You can define more complex deployment scenarios that layer load balancing and distribution. The main question is, do you need load balancing, or distribution, or both?
If you need to deploy data centers in different geographical locations, then you could deploy failover between two load-balanced data centers. See Section 3.2.3, "Configuration 3: Failover Between Data Centers."
If you want to use distribution, but also want the data partitions to be replicated, then you can deploy the proxy server using distribution, which routes to a load balancer. See Section 3.2.4, "Configuration 4: Distribution with Load Balancing."
If you want to use distribution with the data partitions replicated, but for availability and disaster recovery you want the partitions to not only be replicated in one data center but also want to replicate the data centers in two different geographical locations, then you could deploy an architecture similar to Section 3.2.5, "Configuration 5: Distribution with Failover Between Data Centers."
Note:
To map entries to a specific partition, add a global index catalog to the deployment by using distribution. Adding a global index catalog helps minimize the use of broadcasts.For information about configuring a global index catalog, see Section 23.7, "Configuring Global Indexes Using the Command Line."
This section describes the various deployment configurations that are supported by Oracle Unified Directory. Use these examples to familiarize yourself with how the proxy works.
This section contains the following example configurations:
Section 3.2.3, "Configuration 3: Failover Between Data Centers"
Section 3.2.4, "Configuration 4: Distribution with Load Balancing"
Section 3.2.5, "Configuration 5: Distribution with Failover Between Data Centers"
Section 3.2.7, "Configuration 7: Multiple Replicated Proxies"
When you deploy the proxy for load balancing, all requests that the proxy receives are routed to one of the remote LDAP servers. As illustrated in Figure 3-1, the remote LDAP servers are replicated and contain the same data. The number of supported remote LDAP servers is not limited.
The requests are routed to one of the remote LDAP servers based on the load balancing algorithm set during deployment.
The load balancing algorithms are:
failover
generic
optimal
proportional
saturation
searchfilter
For more information about the different load balancing algorithms, see Section 12.2, "Understanding Load Balancing Using the Proxy."
The algorithm can be bypassed by a client connection affinity. If you set client connection affinity, the proxy uses the load balancing algorithm for the first request, but for the following request will disregard the load balancing algorithm set and will try to reuse the same route for a new operation on the same client connection, for example, depending on the type of client affinity set. For more information, see Section 21.1.4.7, "Setting Client Connection Affinity."
The advantages of using load balancing deployment are the high availability of the data, as well as an adapted workload on the remote LDAP servers. For example, if one of the remote LDAP servers in your configuration becomes unavailable, the load balancing will route the request to another remote LDAP server. In this case, the failure is not visible to the client and there is no service disruption.
You can easily configure a simple load balancing deployment during the proxy installation.
When you deploy the proxy for simple distribution, the data is split into partitions. Each partition of data is held on a separate remote LDAP server, as illustrated in Figure 3-2. Here, LDAP Server A...L is a server that holds entries for users whose names start with A through L. Similarly, LDAP Server M…Z holds entries for users whose names start with M through Z. All requests that the proxy receives are routed to the remote LDAP server which contains the appropriate data.
The number of remote LDAP servers onto which the data is partitioned depends on the size of the database that you are splitting. Figure 3-2 shows simple distribution algorithm with two partitions, but you can configure more.
The requests are routed to one of the remote LDAP servers based on the distribution algorithm set during deployment.
The distribution algorithms are:
capacity
numeric
lexico
dnpattern
For more information about the different distribution algorithms, see Section 12.3, "Understanding Data Distribution Using the Proxy."
The advantage of a deployment using distribution is that you can scale the number of updates per second. To diminish the number of broadcasts when using distribution, you can add a global index catalog. For information about the global index catalog, see Section 23.7, "Configuring Global Indexes Using the Command Line."
A simple distribution deployment can be easily configured during the proxy installation.
When you configure failover between data centers, you are essentially deploying two levels of load balancers within the proxy. In this deployment, the data centers are replicated and the remote LDAP servers within the data centers are also replicated. The first load balancing element of the deployment can be either failover or saturation. The example assumes failover algorithm is selected for the initial load balancing element.
As illustrated in Figure 3-3, all of the requests are routed by the failover load balancer through the main route, to a second load balancing element, which sends the request to a server within Data Center 1. Here, LDAP Server A...L is a server that holds entries for users whose names start with A through L. If Data Center 1 goes down or is degraded, then the traffic is routed by the failover load balancer to the backup route, to a server in Data Center 2.
Figure 3-3 Failover Between Data Centers
The requests are routed to the remote LDAP servers within the data centers based on the load balancing algorithm set. The load balancing algorithm can be different for each data center. For example, you can set the load balancing in Data Center 1 as proportional
, while the load balancing algorithm in Data Center 2 is set as saturation
.
This type of deployment is typically used when deploying in two geographical areas. This adds high availability of data to a simple load balancing deployment, since not only are the remote LDAP servers replicated, but the data centers are also replicated.
Typically, you would have the two data centers in two different geographical locations. This way, if there was a problem in one location, the data center in the other location would act as backup. Another example would be setting the first load balancer to saturation
. This way, if Data Center 1 in one geographical location (for example in one time-zone) becomes saturated, the other data center can pick up the excess traffic.
For more information about the different load balancing algorithms, see Section 12.2, "Understanding Load Balancing Using the Proxy."
For more information about deploying this configuration, see Section 12.2.1, "Failover Load Balancing."
For an example use case, see Section 25.4, "Configuring Failover Between Data Centers Example."
In a deployment that includes distribution and load balancing, the data is split into partitions, and the data is replicated on the remote LDAP servers. Requests sent to the proxy are first distributed to the partition in which the data is stored, then the request is routed to one of the remote LDAP servers, depending on the load balancing algorithm set. The remote LDAP servers holding the partitioned data are replicated.
As illustrated in Figure 3-4, when the proxy receives a requests, it is filtered by the distribution to the correct partition. Here, LDAP Server A...L is a server that holds entries for users whose names start with A through L. Similarly, LDAP Server M…Z holds entries for users whose names start with M through Z. For example, a request for entry with a cn such as Garry
would be forwarded to partition 1, to the servers with data from A..L
. The load balancer then forwards the request to one of the replicated remote LDAP servers.
Figure 3-4 Distribution with Load Balancing
The requests are routed to the remote LDAP servers within the data centers based on the load balancing algorithm set. For more information about the different load balancing algorithms, see Section 12.2, "Understanding Load Balancing Using the Proxy."
The advantages of this deployment are the speed of the updates, because of the distribution of data, and high availability of the data.
For more information about the different distribution algorithms, see Section 12.3, "Understanding Data Distribution Using the Proxy."
For more information about the different load balancing algorithms, see Section 12.2, "Understanding Load Balancing Using the Proxy."
For more information about deploying this configuration, see Chapter 12, "Understanding the Proxy, Distribution, and Virtualization Functionality."
In a deployment that includes distribution with failover load balancing between two data centers, the data is split into partitions, where each partition is managed through a failover load balancing route. As illustrated in Figure 3-5, not only are the remote LDAP servers holding the partitioned data replicated within the data center, but in addition, the data centers are replicated, with one of the two acting as the backup. Here, LDAP Server A...L is a server that holds entries for users whose names start with A through L. Similarly, LDAP Server M…Z holds entries for users whose names start with M through Z.
Figure 3-5 Distribution with Failover Between Data Centers
In other words, requests sent to the proxy are first distributed to the partition in which the data is stored. For example, a request for entry with a cn such as Garry
would be forwarded to partition 1. The failover load balancer then forwards the request through the main route, depending on the load balancing algorithm set, to one of the one of the remote LDAP servers holding the data for A..L
.
In the deployment illustrated in Figure 3-5, Data Center 2 acts as a backup, and is only used on failure of the first data center. However, this same deployment could be configured to use saturation
, rather than a failover load balancer. This way, if Data Center 1 in one geographical location (for example in one time-zone) becomes saturated, the other data center can pick up the excess traffic.
The advantages of this deployment are the speed of the reads through the distribution algorithm, and the high availability offered since the remote LDAP servers are replicated, and one data center acts as a backup.
For more information about the different load balancing algorithms, see Section 12.2, "Understanding Load Balancing Using the Proxy."
For more information about the different distribution algorithms, see Section 12.3, "Understanding Data Distribution Using the Proxy."
For an example use case, see Section 25.5, "Configuring Distribution with Failover Between Data Centers Example."
When you deploy the proxy for Enterprise User Security (EUS), the configuration details are stored locally in the Oracle Unified Directory directory server, and the remote external LDAP directory contains only the Enterprise Users and the Enterprise Groups details.
As illustrated in Figure 3-6 the remote external LDAP directory contains only the Enterprise Users and the Enterprise Groups details.
Figure 3-6 Proxy Enterprise User Security
The requests are routed to one of the remote LDAP servers based on the load balancing algorithm set during deployment.
The load balancing algorithms are:
failover
optimal
proportional
saturation
For more information about the different load balancing algorithms, see Section 12.2, "Understanding Load Balancing Using the Proxy."
To deploy the proxy for Enterprise User Security, see Chapter 31, "Integrating Oracle Unified Directory with Oracle Enterprise User Security."
To prevent a Single Point of Failure, you should ensure that your deployment is redundant. Typically, this can be done by installing a third party hardware load balancer, as illustrated in Figure 3-7.
Using a hardware load balancer, you can manage multiple proxy instances on separate physical machines or in different geographical locations.
When running multiple proxy instances in a distribution deployment with a global index catalog, the global index catalog should be replicated. For more information about replicating the global index catalog, see Section 23.7.2, "Replicating Global Index Catalogs."
To configure this proxy deployment, see "Setting Up the Proxy Server" section in the Installing Oracle Unified Directory.
You can use Oracle Unified Directory's virtualization features to create different views of your back-end data and to retrieve data from virtual directories and data sources.
Note:
To use the virtual directory capabilities described here, you must have a validOracle Directory Service Plus
license.For example,
If you have client-side DNs and attributes that do not map with the server-side DNs and attributes, then you can use DN Renaming to rename client-side DNs and attributes to match the values in the server.
For example, your client expects ou=org, dc=server, dc=com
entries, but the LDAP server contains ou=people, dc=server, dc=com
entries.
When the client makes a request, a DN Renaming workflow element applies a DN renaming transformation to the entry DN and to attributes containing either DNs or Name And Optional UIDs syntax. After the result is returned to the client, the DN and attributes are changed back to match what the client requested.
If you need to rename or replace the relative distinguished name (RDN) values from a source directory to Oracle Unified Directory, then you can use RDN Changing.
If the data structure of your LDAP client application differs from the data structure of an LDAP repository, then you can use transformation to display that physical data in a different way. A transformation performs a specific action in a certain direction (during the request, during the response, or both).
For example, your client application has a myuseraccountcontrol
attribute with activated
and deactivated
values that you must transform to a nsAccountLock
attribute with false
and true
values on a DSEE (SunONE) back end. You would be required to map the read and write operations.
You could create a Transformation workflow element that defines where (source or client) Oracle Unified Directory interacts with the data and in which direction the transformation is applied.
For more information about these, and other, virtualization features for your proxy deployment, see Chapter 12, "Understanding the Proxy, Distribution, and Virtualization Functionality."
For information about configuring these features, see Chapter 24, "Configuring Virtualization."