1. Administering Oracle Unified Directory
  2. Overview of Oracle Unified Directory
  3. Understanding Deployments Using the Proxy Server

3 Understanding Deployments Using the Proxy Server

The prime role of a proxy server is to route LDAP requests from clients to directory servers that are deployed in a directory services topology.

The following topics provide some example deployments to help familiarize you with how the proxy server works:

3.1 Understanding Your Proxy Deployment Type

There are several kinds of scenarios in which you can deploy a proxy server successfully. It is essential to understand the different deployment types to build a network as per your requirement.

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.

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 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 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 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. See Configuring Global Indexes Using the Command Line.

3.2 Supported Proxy Deployments

Use the examples in the following sections to familiarize yourself with how the proxy works and the various deployment configurations that are supported by Oracle Unified Directory:

3.2.1 Configuration 1: Simple Load Balancing

Load balancing is a strategy to optimize performance by distributing incoming requests across multiple resources. This in turn prevents any single resource from being overloaded. The example illustrates how to set up a simple load balancing.

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.

Figure 3-1 Simple Load Balancing

Description of Figure 3-1 follows
Description of "Figure 3-1 Simple Load Balancing"

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 Overview of 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. See 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.

3.2.2 Configuration 2: Simple Distribution

Data distribution allows you to scale your directory across multiple servers. Each server is responsible for only a part of the data. Therefore, a distributed topology can hold large number of data than would be possible with a single server.

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.

Figure 3-2 Simple Distribution

Description of Figure 3-2 follows
Description of "Figure 3-2 Simple Distribution"

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 Overview of 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. See Configuring Global Indexes Using the Command Line

A simple distribution deployment can be easily configured during the proxy installation.

3.2.3 Configuration 3: Failover Between Data Centers

When you configure failover between data centers, you are essentially deploying two levels of load balancers within the proxy. This enables you to enhance the high availability.

Let’s examine a failover scenario. In this deployment topology, 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

Description of Figure 3-3 follows
Description of "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.

See Also:

3.2.4 Configuration 4: Distribution with Load Balancing

When you configure distribution with load balancing, data is split into partitions. In addition, the data is replicated on the remote LDAP servers.

In such a situation, the 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

Description of Figure 3-4 follows
Description of "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 Overview of 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.

See Also:

3.2.5 Configuration 5: Distribution with Failover Between Data Centers

You can configure a topology that includes distribution with failover load balancing. In such a scenario, data is split into partitions between two data centers, where each partition is managed through a failover load balancing route.

Consider the following scenario. 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

Description of Figure 3-5 follows
Description of "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.

See Also:

3.2.6 Configuration 6: Enterprise User Security

When you configure 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


Description of Figure 3-6 follows
Description of "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 Overview of Load Balancing Using the Proxy.

To deploy the proxy for Enterprise User Security, see Integrating Oracle Unified Directory with Oracle Enterprise User Security.

3.2.7 Configuration 7: Multiple Replicated Proxies

You use a hardware load balancer to manage multiple proxy instances on separate physical machines or in different geographical locations.

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.

This example illustrates how to use a hardware load balancer to manage multiple proxy instances.

Figure 3-7 Multiple Proxy Instances

Description of Figure 3-7 follows
Description of "Figure 3-7 Multiple Proxy Instances"

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 Replicating Global Index Catalogs.

To configure this proxy deployment, see Setting Up Oracle Unified Directory as a Proxy Server section in the Installing Oracle Unified Directory.

3.2.8 Configuration 8: Virtualization

You can use the virtualization feature of Oracle Unified Directory 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 valid Oracle 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.

See Also: