Connecting to Services on a Cluster Using Load Balancer

A load balancer includes one or more backend sets to route incoming traffic to backend servers. The backend set is a logical entity that includes:

• A list of backend servers, to which traffic is directed by the load balancer. In Big Data Service, the cluster nodes are the backend servers. A backend server is typically identified by an IP address and a port.
• A load balancing policy, which tells the load balancer how to distribute incoming traffic to the backend servers.
• A health check policy, to test the health and availability of backend servers.
• Optional Secure Sockets Layer (SSL) handling, to establish an encrypted link between a client and a server.
• Optional session persistence configuration. Session persistence isn't used in the scenario described below.

A load balancer also has one or more listeners, to accept incoming traffic. Listeners route traffic to backend sets, which route traffic to backend servers.

These instructions tell how to create a load balancer that can be used as the front end for accessing Apache Ambari. Hue, and JupyterHub from a web browser. Youcan connect to the services by using the load balancer's IP address or hostname, plus the port where a service runs, for example:

• https://<load-balancer-ip-or-hostname>:7183 for Apache Ambari
• https://<load-balancer-ip-or-hostname>:8889 for Hue
• https://<load-balancer-ip-or-hostname>:8000 for JupyterHub.

You can create a public load balancer (in a public subnet), which allows access from the public internet; or you can create a private load balancer (in a private subnet), which allows access from your private VCN. For a private load balancer, you must set up private access from the VCN, for example by using a bastion host or by using Oracle FastConnect service or Oracle IPSec VPN service. However, for simplicity, these instructions tell how to create a public load balancer.

Specifically, you do the following:

• Create a load balancer.
• Create three backend sets, one for Apache Ambari. Hue, and JupyterHub.
• Add one backend server to each backend set. A backend server is the cluster node where the service runs, plus the port where the service listens for requests.
• Create three listeners, one for Apache Ambari. Hue, and JupyterHub.
• Configure SSL for the backend sets and for the listeners, thus implementing end-to-end SSL.

For complete documentation about Oracle Cloud Infrastructure load balancers, see Overview of Load Balancing.

• A Big Data Service cluster running in a Virtual Cloud Network (VCN) with an internet gateway and a public regional subnet (for a public load balancer).

• Security rules that allow incoming traffic to the ports where services run in the cluster: Apache Ambari (port 7183), Hue (port 8889), and JupyterHub (port 8000). See Defining Security Rules.

• Admin access to manage load balancers. For examples, see "Let network admins manage load balancers" in Common Policies.

• SSH access to the cluster. You must be able to connect to nodes on your cluster to download self-signed SSL certificates that are stored on the cluster. To do this, prior to creating a load balancer, you must set up your environment to allow that access. For example you can use Oracle FastConnect or Oracle IpSec VPN, you can set up a bastion host, or you can map private IPs to public IP addresses. See Connecting to Cluster Nodes with Private IP Addresses.

• A DNS domain (optional if using self-signed SSL certificates or required if using SSL certificates from a certificate authority (CA)). For information about using DNS in Oracle Cloud Infrastructure, see Overview of DNS.

• SSL certificates, used for authentication.

  • Self-signed certificates from the cluster are required.

  • Certificates issued by a trusted certificate authority are recommended. You must have a DNS domain (as previously mentioned) to obtain certificates from a certificate authority.

  See STEP 1 (Ambari): Obtain SSL Certificates for Apache Ambari.

• A list of the private IP addresses of the nodes where the services run on your cluster.

  • In a highly available (HA) cluster, the services run on the following nodes:

    • Apache Ambari runs on the first utility node.
    • Hue and JupterHub run on the second utility node.

  • In a non-HA cluster, all the services run on the first (and only) utility node.

This topic tells you how to implement end-to-end SSL for your load balancer. The load balancer accepts SSL encrypted traffic from clients, and it encrypts traffic to the backend servers. To do this, you must associate SSL certificate bundles with the listeners and with the backend servers.

• For listeners, you can use signed SSL certificates issued by a trusted certificate authority or you can use self-signed certificates that you download from the cluster. We recommend that you use signed SSL certificates from a certificate authority to provide the highest level of security.
  Note
  
  This topic uses the phrases "CA-signed SSL certificate" or just "CA-signed certificate" to refer to signed SSL certificates obtained from a certificate authority.
• For backend sets, use the self-signed certificates that you download from the cluster.

Obtain one of the following certificates:

• Certificate-Authority (CA)-signed SSL certificates
• Self-signed SSL certificates

You can purchase CA-signed SSL certificates from a trusted certificate authority such as Symantec, Thawte, RapidSSL, or GeoTrust. See the documentation from your chosen certificate authority for information about obtaining and managing certificates.

To obtain SSL certificates from a certificate authority, you usually have to have a DNS domain. For information about using DNS in Oracle Cloud Infrastructure, see Overview of DNS.

Self-signed SSL certificates are included in your cluster. They're located in the following directory in each utility node:

/var/lib/ambari-server/keys

List the contents of the /var/lib/ambari-server/keys directory.

[opc@<your-cluster-name>-un0 (or -un1) ~]$ ls /var/lib/ambari-server/keys
...
https.crt
https.key
...

From the /var/lib/ambari-server/keys directory you can find:

• Public certificate: https.crt
• Private SSL key: https.key

From the /etc/security/serverKeys/ directory, you can find: CA certificate: bdsOracleCA.crt

For more information about using SSL with load balancers, see SSL Certificate Management.

1. Open the navigation menu and click Networking. Then click Load Balancers.
2. Under Compartment, select a compartment select the compartment where you want to create the load balancer. Then click Create Load Balancer.
3. For Select Load Balancer Type, click Load Balancer and then click Create Load Balancer.

4. On the Add Details page of the Create Load Balancer workflow, enter the following information:

   • Load Balancer Name: Enter a name to identify the load balancer.

   • Choose Visibility Type: Click Public to create a load balancer that will be accessible from the public internet.

     You could choose instead to select Private to create a load balancer that's accessible only from your private network, but for simplicity these instructions describe how to create a public load balancer.

   • Choose Total Bandwidth: Select Small.

   • Virtual Cloud Networking in <compartment>: Click the Select a virtual cloud network list and select the VCN where your cluster is running. If the network is in a different compartment, click Change Compartment and select the compartment from the list.

   • Subnet in <compartment>: Click the Select a subnet list and select a public subnet in your VCN to use for the load balancer. (A public subnet is required for a public load balancer.) If the subnet is in a different compartment, click Change Compartment and select the compartment from the list.

   • Use Network Security Groups to Control Traffic: Leave this box unchecked.

5. Click Next.

6. On the Choose Backends page of the workflow, enter the following information to create a backend set (with health policy) for Apache Ambari:

   • Specify a Load Balancing Policy: Accept the default Weighted Round Robin.

   • Select Backend Servers: Skip this option. You'll add a backend server later.

   • Specify Health Check Policy: Enter the following for the health check policy for this Apache Ambari backend set:

     • Protocol: Select HTTP.

     • Port: Enter 7183, which is the port on which Apache Ambari listens.

     • URL Path (URI): Keep the default slash (/).

   • Use SSL: Leave this box unchecked. You'll configure SSL for this backend set later.

7. Click Next.

8. On the Configure Listener page, enter the following information:

   • Listener Name: Enter a name for the listener, for example cm-listener.

   • Specify the type of traffic your listener handles: Select HTTP. You'll change this to HTTPS later.

   • Specify the Port Your Listener Monitors for Ingress Traffic: Enter 7183.

9. Click Submit. When the large load balancer status icon at the top of the Load Balancer Details page is green, you can continue with the steps below. It may take a few minutes to create the load balancer.

In this step, you'll save your SSL files as bundles, which you'll use later to configure SSL for backend sets and listeners. You'll create different bundles, depending on the type of cluster and the source of your SSL certificates. The use cases are:

• Use case A: HA cluster that uses a CA-signed certificate
• Use case B: Non-HA cluster that uses a CA-signed certificate
• Use case C: HA cluster that uses only the self-signed certificates from the cluster
• Use case D: Non-HA cluster that uses only a self-signed certificate from the cluster

Each use case requires one to three certificate bundles. The table below shows all possible bundles, although you only have to create the ones required for your use case. The instructions following the table tell you which bundles to create for your use case.

To create the bundles:

1. On the left side of the Load Balancer Details page, under Resources, click Certificates.

   Refer to the Steps to complete for each use case table, below, to find your use case. Then refer to the Complete These Steps column to find which of the subsequent steps you must follow to create the bundle or bundles for your use case.

   Notice that:

   • Use case A requires three bundles; use cases B and C each require two bundles; and use case D requires only one bundle.

   • All the use cases require one or two bundles with self-signed certificates. Use cases A and B also require a bundle with a CA-signed certificate.

   Steps to complete for each use case

   Use Case	Type of Cluster	Complete These Steps
   A	HA CA-Signed Certificate	2: Create a bundle with a CA-signed certificate 3: Create a bundle with the self-signed certificate from the first utility node 4: Create a bundle with the self-signed certificate from the second utility node
   B	non-HA CA-Signed Certificate	2: Create a bundle with a CA-signed certificate 3: Create a bundle with the self-signed certificate from the first utility node
   C	HA	3: Create a bundle with the self-signed certificate from the first utility node 4: Create a bundle with the self-signed certificate from the second utility node
   D	Non-HA	3: Create a bundle with the self-signed certificate from the first utility node

2. Create a bundle with a CA-signed certificate. You must create this bundle if you have either of the following use cases:

   • Use Case A: HA cluster with a CA-signed certificate
   • Use Case B: Non-HA cluster with a CA-signed certificate

   Create the bundle:

   1. Click Add Certificate.

   2. On the Add Certificate page, enter the following information:

      • Certificate Name: Enter lb-ca-signed-cert (or a name of your choice).

      • SSL Certificate: Add your CA-signed SSL certificate.

      • Specify CA Certificate: Check this box, and then add your CA certificate.

      • Specify Private Key: Check this box, and then add the private key associated with the SSL certificate you added in the SSL Certificate field, above.

   3. Click Add Certificate, and then click Close in the Work Request Submitted dialog box. It may take a few moments for the bundle to be added to the Certificates table.

3. Create a bundle with the self-signed certificate from the first utility node. You must create this bundle for all the use cases:

   • Use Case A: HA cluster with a CA-signed certificate
   • Use Case B: Non-HA cluster with a CA-signed certificate
   • Use Case C: HA cluster with only the self-signed certificates from the cluster
   • Use Case D: Non-HA cluster with only a self-signed certificate from the cluster

   Create the bundle:

   1. Remain on the Certificates page. Click Add Certificate.

   2. On the Add Certificate page, enter the following information:

      • Certificate Name: Enter node0-self-signed-cert (or a name of your choice).

      • SSL Certificate: Add the self-signed SSL certificate for the first utility node that you downloaded from the cluster.

      • Specify CA Certificate: Check this box, and then add the CA certificate that you downloaded from utility node. For example, bdsOracleCA.crt).

      • Specify Private Key: Check this box, and then add the private key associated with the SSL certificate you added in the SSL Certificate field, above, that is, the node.hue.key you downloaded from the first utility node.

   3. Click Add Certificate, and then click Close in the Work Request Submitted dialog box. It may take a few moments for the bundle to be added to the Certificates table.

4. Create a bundle with the self-signed certificate from the second utility node. You must create this bundle if you have either of the following use cases:

   • Use Case A: HA cluster with a CA-signed certificate
   • Use Case C: HA cluster with only self-signed certificates from the cluster

   Create the bundle:

   1. Remain on the Certificates page. Click Add Certificate.

   2. On the Add Certificate page, enter the following information:

      • Certificate Name: Enter node1-self-signed-cert (or a name of your choice).

      • SSL Certificate: Add the self-signed SSL certificate for the second utility node that you downloaded from the cluster.

      • Specify CA Certificate: Check this box, and then add the CA certificate that you downloaded from utility node. For example, bdsOracleCA.crt).

      • Specify Private Key: Check this box, and then add the private key associated with the SSL certificate you added in the SSL Certificate field, above, that is, the node.hue.key you downloaded from the second utility node.

   3. Click Add Certificate, and then click Close in the Work Request Submitted dialog box. It may take a few moments for the bundle to be added to the Certificates table.

1. On the left side of the Certificates page, under Resources, click Backend Sets. The backend set you created in STEP 2: Create the Load Balancer is displayed in the Backend Sets table, with a name like bs-lb-<date-timestamp>, for example, bs_lb_2020-0928-1136.

2. Click the action menu at the end of the row containing this backend set, and select Edit.

3. Enter the following information.

   • Name: Read-only. This name was created for you.
   • Traffic Distribution Policy: Accept the default Weighted Round Robin.

   • Use SSL: Select this box, then, under Certificate Name, select node0-self-signed-cert. Use this bundle for all use cases. It's the bundle containing the self-signed SSL certificate for the first utility node of the cluster.

   • Verify Peer Certificate: Check this box.
   • Verify Depth: Set to 1, or select another number to indicate maximum depth for certificate chain verification.
   • Session Persistence: Accept the default Disable Session Persistence.

4. Click Update Backend Set, and then click Close in the Work Request Submitted dialog box. When complete, a cipher suite name is added to the Cipher Suite field for the backend set. It may take a few moments.

1. Remain on the Backed Sets page and click Create Backend Set again. On the Create Backend Set page, enter the following information.

   • Name: Provide a name, for example, hue-backend-set.

   • Traffic Distribution Policy: Accept the default Weighted Round Robin.

   • Use SSL: Select this box, then, under Certificate Name, select the certificate bundle for your use case:

     • For HA clusters, select node1-self-signed-cert.

       This is the bundle containing the self-signed SSL certificate for the second utility node of the cluster.

     • For non-HA clusters, select node0-self-signed-cert.

       This is the bundle containing the self-signed SSL certificate for the first utility node of the cluster.

   • Verify Peer Certificate: Check this box.
   • Verify Depth: Set to 1, or select another number to indicate maximum depth for certificate chain verification.
   • Session Persistence: Accept the default Disable Session Persistence.

   • Health Check: Enter the following information:

     • Protocol: Select TCP.

     • Port: Enter 8889, which is the port on which Hue listens.

2. Click Create Backend Set, and then click Close in the Work Request Submitted dialog box. It might take a few moments for the backend set to be added to the Backend Sets table.

1. Remain on the Backend Sets page and click Create Backend Set again. On the Create Backend Sets page, enter the following information.

   • Name: Provide a name, for example, data-studio-backend-set.
   • Traffic Distribution Policy: Accept the default Weighted Round Robin.

   • Use SSL: Select this box, then, under Certificate Name, select the certificate bundle for your use case:

     • For HA clusters, select node1-self-signed-cert.

       This is the bundle containing the self-signed SSL certificate for the second utility node of the cluster.

     • For non-HA clusters, select node0-self-signed-cert.

       This is the bundle containing the self-signed SSL certificate for the first utility node of the cluster.

   • Verify Peer Certificate: Check this box.
   • Verify Depth: Set to 1, or select another number to indicate maximum depth for certificate chain verification.
   • Session Persistence: Accept the default Disable Session Persistence.

   • Health Check: Enter the following information:

     • Protocol: Select HTTP.

     • Port: Enter 30000, which is the port on which Big Data Studio listens.

     • URL Path (URI): Enter a slash (/).

2. Click Create Backend Set, and then click Close in the Work Request Submitted dialog box. It might take a few moments for the backend set to be added to the Backend Sets table.

1. Remain on the Backend Sets page. In the Backend Sets table, click the name of the backend set for Apache Ambari, for example bs_lb_2020-0928-1136. (Remember, the wizard assigned this name to the first backend set.)
2. On the left side of the Backend Set Details page, under Resources, click Backends. Then click Add Backends.
3. On the Add Backends page, select IP Addresses at the top of the page, and enter the following information:
   • IP Address: Enter the private IP address of the first utility node of your cluster, for example 10.2.0.106.
   • Port: Enter 7183, which is port where Apache Ambari listens.
   • Weight: Accept the default value 1.
4. Click Add, and then click Close in the Work Request Submitted dialog box. It might take a few moments for the backend server to be added to the Backends table.

1. Click Backend Sets in the breadcrumbs at the top of the page to return to the Backend Sets page. In the Backend Sets table, click the name of the backend set you created for Hue, for example hue-backend-set.
2. On the left side of the Backend Set Details page, under Resources, click Backends. Then click Add Backends.
3. On the Add Backends page, select IP Addresses at the top of the page, and enter the following information:
   • IP Address: Enter the private IP address of the second utility node for an HA cluster or the first (and only) utility node for a non-HA cluster, for example 10.2.0.100.
   • Port: Enter 8889, which is the port on which Hue listens.
   • Weight: Accept the default value 1.
4. Click Add, and then click Close in the Work Request Submitted dialog box. It might take a few moments for the backend server to be added to the Backends table.

1. Click Backend Sets in the breadcrumbs at the top of the page to return to the Backend Sets page. In the Backend Sets table, click the name of the backend set you created for Big Data Studio, for example data-studio-backend-set.

2. On the left side of the Backend Set Details page, under Resources, click Backends. Then click Add Backends.

3. On the Add Backends page, select IP Addresses at the top of the page, and enter the following information:

   • IP Address: Enter the private IP address of the second utility node for an HA cluster or the first (and only) utility node for a non-HA cluster, for example 10.2.0.106.
   • Port: Enter 30000, for the port where Big Data Studio listens.
   • Weight: Accept the default value 1.

4. Click Add, and then click Close in the Work Request Submitted dialog box. It might take a few moments for the backend server to be added to the Backends table.

1. Click Load Balancer Details in the breadcrumbs at the top of the page. On the left side of the Load Balancer Details page, under Resources, click Listeners. Notice that the Listeners table includes the listener you created for Apache Ambari in STEP 2: Create the Load Balancer, for example, cm-listener.

2. Click the action menu at the end of the row containing the listener, and select Edit.

3. On the Edit Listener page, enter the following information:

   • Name: Read-only.

   • Protocol: Select HTTPS.

   • Port: Enter 7183, which is the port on which Apache Ambari listens.

   • Use SSL: Select this box, then, under Certificate Name, select the certificate bundle for your use case:

     • If you're using CA-signed SSL certificates, select: lb-ca-signed-cert

       This is the bundle containing the CA-signed SSL certificate. Use this for both HA and non-HA clusters.

     • If you're using the self-signed certificate from the cluster only, select: node0-self-signed-cert

       This is the bundle containing the self-signed SSL certificate for the first utility node of the cluster. Use this for both HA and non-HA clusters.

   • Verify Peer Certificate : Leave this box unchecked.

   • Backend Set: From the list, select the backend set you created for Apache Ambari in STEP 2: Create the Load Balancer, for example, bs_lb_2020-0928-1136. (Remember, the wizard assigned this name when you created it.)

4. Click Create Listener, and then click Close in the Work Request Submitted dialog box. It might take a few moments for the listener to be added to the Listeners table.

1. Click Backend Sets in the breadcrumbs at the top of the page to return to the Backend Sets page.
2. On the left side of the page, under Resources, click Listeners.
3. Click Create Listener.
4. On the Create Listener page, enter the following information:

   • Name: Enter a name for the listener, for example, hue-listener.

   • Protocol: Select HTTPS.

   • Port: Enter 8889, which is the port on which Hue listens.

   • Use SSL: Select this box, then, under Certificate Name, select the certificate bundle for your use case:

     • If you're using a CA-signed certificate, select lb-ca-signed-cert.

       This is the bundle containing the CA-signed SSL certificate for the load balancer host.

     • If you're using only self-signed certificates with an HA cluster, select: node1-self-signed-cert,

       This is the bundle containing the self-signed SSL certificate for the second utility node of the cluster.

     • If you're using only the self-signed certificate with a non-HA cluster, select node0-self-signed-cert.

       This is the bundle containing the self-signed SSL certificate for the first utility node of the cluster.

   • Verify Peer Certificate : Leave this box unchecked.

   • Backend Set: From the list, select the backend set you created for Hue in STEP 5: Create a Backend Set for Hue, for example, hue-backend-set.

5. Click Create Listener, and then click Close in the Work Request Submitted dialog box. It might take a few moments for the listener to be added to the Listeners table.

1. Remain on the Listeners page. Click Create Listener again.

2. On the Create Listener page, enter the following information:

   • Name: Enter a name for the listener, for example, data-studio-listener.

   • Protocol: Select HTTPS.

   • Port: Enter 30000, which is the port on which Big Data Studio listens.

   • Use SSL: Select this box, then, under Certificate Name, select the certificate bundle for your use case:

     • If you're using a CA-signed certificate, select lb-ca-signed-cert.

       This is the bundle containing the CA-signed SSL certificate for the load balancer host.

     • If you're using only self-signed certificates with an HA cluster, select: node1-self-signed-cert,

       This is the bundle containing the self-signed SSL certificate for the second utility node of the cluster.

     • If you're using only the self-signed certificate with a non-HA cluster, select node0-self-signed-cert.

       This is the bundle containing the self-signed SSL certificate for the first utility node of the cluster.

   • Verify Peer Certificate : Leave this box unchecked.

   • Backend Set: From the list, select the backend set you created for Big Data STEP 6: Create a Backend Set for Big Data Service Studio in, for example, data-studio-backend-set.

3. Click Create Listener, and then click Close in the Work Request Submitted dialog box. It might take a few moments for the listener to be added to the Listeners table.

It might take a few minutes for the backend sets and listeners to be ready to receive requests. On the left side of the page, under Resources, click Backend Sets. In the Backend Sets table, check the status in the Health column. When the status for all the backend sets are OK, you can use the load balancer.

To open the services included in this load balancer:

1. Find the IP address or the hostname used for your load balancer.

   • IP address:

     The IP address is listed in the Load Balancer Information panel at the top of the load balancer pages in the console.

   • DNS hostname:

     After the load balancer is created and it's been given an IP address, you or another administrator must add a DNS entry to your DNS name servers, to resolve the hostname (for example, bds-frontend.mycompany.com) to the public IP address of the load balancer. Then, the services registered in the load balancer is accessible by using that hostname, for example, bds-frontend.mycompany.com:7183 for Apache Ambari.

     For information about using DNS in Oracle Cloud Infrastructure, see Overview of DNS.

2. In a web browser, enter the address as follows:

   • To use the load balancer's IP address: https://<load-balancer-ip>:<port>.

   • To use the load balancer's hostname in a domain: https://<hostname>:<port>.

   That is, for Apache Ambari:

   • https://<load-balancer-ip>:7183
   • https://<hostname>:7183
   For Hue:

   • https://<load-balancer-ip>:8889
   • https://<hostname>:8889
   For Big Data Studio:

   • https://<load-balancer-ip>:30000
   • https://<hostname>:30000