oracle traffic director on exalogic configuring vips oracle traffic director on exalogic –...

Download Oracle Traffic Director on Exalogic Configuring VIPs Oracle Traffic Director on Exalogic – Configuring

Post on 28-May-2020

1 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

  • Oracle Traffic Director on Exalogic – Configuring VIPs

    An Oracle White Paper

    March 2014

    Oracle Traffic Director on Exalogic – Configuring VIPs Executive Overview ........................................................................... 2

    Introduction ....................................................................................... 2

    Exalogic Terminology ........................................................................ 5

    Shared Versus Multiple Cloud Account .............................................. 6

    OTD Topology Overview ................................................................... 6

    Scenario 1 – OTD as Reverse Proxy to External Clients ............... 7

    Scenario 2 – OTD for Internal Load Balancing ............................... 7

    Scenario 3 – Combined Topology with Exadata ............................ 7

    OTD Topology Details ....................................................................... 7

    Scenario 1a – OTD with External Load Balancer ........................... 8

    Scenario 1b – OTD with External Failover Group VIP .................. 12

    Scenario 2a – OTD with Internal VIP (Shared Cloud Account)..... 16

    Scenario 2b – OTD with Internal VIP (Multiple Cloud Accounts) .. 17

    Scenario 3 – Combined Exadata Topology .................................. 19

    OTD Installation and Failover Groups .............................................. 21

    Conclusions ..................................................................................... 22

  • Oracle Traffic Director on Exalogic – Configuring VIPs

    2

    Executive Overview

    Oracle Traffic Director is a powerful Layer-7 Application Delivery Controller (aka software load

    balancer), capable of large-scale deployments and of flexible enough to handle the multitude

    of various request types that might go through it. It adds a number of key capabilities, such as

    intelligent routing, compression, and content caching, among others. Couple with Exalogic’s

    low-latency and high throughput Infiniband networking, the result is an ideal environment for

    hosting Fusion Middleware applications. Oracle Traffic Director can be set up to handle all

    incoming requests from the outside world, as well as internal traffic going from component to

    component internally. When properly set up, it can dramatically reduce traffic on a customer’s

    network, by keeping much of the internal application “chatter” entirely within an Exalogic

    system. This paper covers the various techniques used to set up Oracle Traffic Director to

    achieve success.

    Introduction

    This paper is to be used in conjunction with existing product documentation. The topologies

    presented here are representations of the recommended topology, as suggested by the

    documentation. What we add is the Exalogic part – how to apply the concepts using a

    Virtualized Exalogic rack. This paper will showcase 3 common scenarios where Oracle Traffic

    Director would be recommended, as well as two common variations of how these would be

    implemented on Exalogic. The use of Oracle Traffic Director to terminate SSL – one of its

    primary use cases – is orthogonal to this topic, and is thus omitted. Nothing depicted here

    prevents SSL from being added into any of these scenarios.

    Before the scenarios are introduced, some background material is covered. This is mostly

    because we need a mapping between the concepts proposed in the Oracle Traffic Director

    documentation, and those within Exalogic used to create a working topology.

    In terms of usage, this paper assumes that the primary use case for Oracle Traffic Director will

    be as a software load balancer for Oracle Fusion Middleware. Oracle Traffic Director can be

    for simple JEE applications running inside WebLogic Server, as well as complex SOA Suite

    components, or Oracle Applications, which require components to communicate with each

    other. Because Oracle Traffic Director must run in a highly available manner, in order to

    prevent it being a single point of failure, we define Virtual IP addresses for use. These VIPs

  • Oracle Traffic Director on Exalogic – Configuring VIPs

    3

    are the entry point to one or more instances of Oracle Traffic Director, which then does the

    load balancing, for the purpose of hiding the back end servers from the outside.

    Because Oracle Traffic Director is typically set up for high availability (active or passive), the

    use of OTD Failover Groups can be part of the setup as well. It is thus important to fully

    understand the various networks available on Exalogic, when to apply these to a particular VM,

    and how to configure the most common topologies where OTD is of benefit.

    The introduction below will start with the OTD topology, as presented in the documentation:

    Figure 1 -- Oracle Traffic Director Topology

  • Oracle Traffic Director on Exalogic – Configuring VIPs

    4

    Having a look at the general topology presented above, it is fairly easy to map the various

    OTD, web, and application servers (depicted as machines) to Virtual Machines running inside

    an Exalogic rack. Each component can be represented as a v-server, based on built-in or

    custom templates and types. However, it is not quite as easy to map other Exalogic cloud

    concepts, such as Accounts, networks, Distribution Groups, Infiniband, Private V-Nets, and so

    on and forth. This paper will attempt to fill those voids.

  • Oracle Traffic Director on Exalogic – Configuring VIPs

    5

    Exalogic Terminology

    A (very) brief description of some of the Exalogic Elastic Cloud terms that will be used in this paper

    appears in this section. By no means is this list comprehensive.

     V-server – A virtual machine. In the Exalogic world, a V-server is a given a resource limit

    (CPU/Memory/Storage), and is granted access to one or more networks. It runs on a single

    Exalogic compute node at a time.

     Distribution Group – This is an anti-affinity concept within Exalogic. By provisioning more than 1

    V-server into the same distribution group, Exalogic will guarantee that the V-servers are physically

    running on separate compute nodes.

     Virtual Data Center (VDC) – Exalogic’s top level container for all virtualized resources within an

    Exalogic rack. The VDC contains all networks and cloud accounts created on the entire rack.

     VDC Cloud Account – An account is NOT a username/password combination. Instead, it is an

    allocation of resources and access to networks. Accounts are how Exalogic divvies up resources by

    group, line of business, or function. Users (one or more) have access to accounts, and can thus

    share responsibilities within a private cloud scenario.

     Failover Group – Oracle Traffic Director mechanism for surfacing a Virtual IP (VIP). This VIP is

    able to “float” between OTD instances in an active/passive configuration. If the primary OTD

    instance becomes unavailable, the VIP seamlessly moves to the backup instance.

     “Public”, “Client” or EoIB Network – A network that has external connectivity outside of the

    Exalogic rack. Typically this will be the network that v-servers use to get access to resources outside

    of Exalogic, over the 10Gbe pipe. Each Exalogic rack can host numerous public networks, which

    allows segregation of applications and application components. NOTE: the “public” part does not

    necessarily connote “public internet”. It simply means outside Exalogic.

     Private v-net – A network created entirely within the scope of an account. This network can span

    ONLY V-servers within a particular account. It provides an internal network, utilizing Infiniband,

    for which V-servers can communicate. It cannot be accessed from outside Exalogic, and cannot

    traverse accounts.

     Infiniband Partitions – Because Infiniband is a fabric-based technology, this means that its

    collective bandwidth is pooled. The concept of partitions allows for separation of traffic, without

    loss of overall capacity. By using partitions (Exalogic does natively), we are able to define multiple

    network “swim lanes” that cannot see each other’s traffic, without having to “slice up” the overall

    40Gbps. Partitions are not explicitly created by end users, but rather implicitly by means of creating

    “Private V-Nets” and by using the in-built Infiniband networks.

     IPoIB-vserver-shared-storage – This network is available to be provisioned to each Virtual

    Machine. Having this network provisioned allows a VM to access the ZFS-based shared storage

    inside Exalogic. This is important for OTD, as the product installation and instance homes can and

  • Oracle Traffic Director on Exalogic – Configuring VIPs

    6

    should be stored outside of the VM root disk. This is the case for all Oracle Fusion Middleware

    products, and OTD is no exception.

     IPoIB-default – One of the networks available to the Exalogic rack is the default,

Recommended

View more >