3 Example Deployments Using the Proxy Server

This chapter describes some example deployments to help familiarize you with how the proxy server works.

This chapter includes the following sections:

3.1 Deciding Your Proxy Deployment Type

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.

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?

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."

3.2 Supported Proxy Deployments

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:

3.2.1 Configuration 1: 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 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.

3.2.2 Configuration 2: Simple Distribution

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 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.

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. 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

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.

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."

3.2.4 Configuration 4: Distribution with Load Balancing

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

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 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."

3.2.5 Configuration 5: Distribution with Failover Between Data Centers

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

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.

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."

3.2.6 Configuration 6: Enterprise User Security

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

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 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."

3.2.7 Configuration 7: Multiple Replicated Proxies

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.

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 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.

3.2.8 Configuration 8: Virtualization

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 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.

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."