Oracle Remote Listeners in the Cloud | the way we see it

Oracle Remote Listeners in the Cloud

Dynamic database access within a database cloud

Oracle Based Big Data Strategy | the way we see it

Oracle Remote Listeners in the cloud

Name author(s): Johan Louwers, Peter Lengkeek

Oracle Based Big Data Strategy | the way we see it

Preface / Introduction
With the rise and maturing of cloud concepts enterprises do adopt more and more
cloud concepts. Enterprises do use public and private clouds in a rapidly growing
pace. Public clouds are not appropriate for every type of company due to the
nature of the business or the legal requirements on data security. To ensure
enterprises that are not able to make use of public clouds can still benefit of the
concepts of cloud the private cloud concept is winning in popularity over
traditional data center technologies.
By using a private cloud concept some new, or hidden, challenges come to light.
One of the often hidden challenges with hosting a large set of databases is the
correct connection of applications to the correct database. Too often still done
manually and decentralized in an error prone and labour intensive process.
As the concept of cloud and specifically the concept of database as a service
introduces a decoupling of the traditionally relative hard bounding between hosts,
databases and services there is the need to revisit the architectural principles of
how applications connect to databases.
An already existing technology in the form of remote listeners provide a solution
to this issue. Within this whitepaper a outline of how to use and configure remote
listeners in a Database as a Service concept is given.
Capgemini has deployed numerous solutions based upon cloud principles for
large enterprises as part of Capgemini Enterprise IT rationalization programs. For
more information about this topic please contact Capgemini.

ii

Oracle Based Big Data Strategy | the way we see it

Table of Contents
1

Database as a Service

1.1 Conceptual view on cloud computing

1.2 Conceptual view on IaaS

1.3 Conceptual view on PaaS

1.4 Conceptual view on SaaS

1.5 Conceptual view on DBaaS

Remote listeners

2.1 Remote listeners deployment architecture

2.2 Remote listeners network setup

2.3 Database registration flow

2.4 Client request flow

Configuration examples

11

3.1 Database parameter remote_listener

11

3.2 Local tnsnames.ora file

11

3.3 Local /etc/resolv.conf file

11

iii

1 Database as a Service
The concept of DataBase as a Service, DBaaS, is part of the more generic Platform as a
Service, PaaS concept within cloud computing. To be able to have the full picture of Oracle
remote listeners and the role they play in cloud computing, and more specific in DBaaS, it is
important to understand both concepts
1.1
Conceptual view on cloud computing
Cloud computing is a term which has been used widely within the IT industry and often without
the proper definition setting of what is considered cloud. A general description of cloud
computing has been given by NIST, National Institute of Standards and Technology, which
described cloud computing in the following terms:
cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to
a shared pool of configurable computing resources (e.g., networks, servers, storage,
applications and services) that can be rapidly provisioned and released with minimal
management effort or service provider interaction.
The IT industry has broken cloud computing down into a number of, growing, subcategories
which include IaaS (Infrastructure as a Service), PaaS (Platform as a Service) and SaaS
(Sofwtare as a Service). DBaaS (DataBase as a Service) is seen as a subcategory of Platform as
a Service.

Figure 1.A
Cloud computing, with a focus on the relevant parts for this whitepaper, can be visualized as
shown in figure 1.A.
1.2
Conceptual view on IaaS
IaaS or Infrastructure as a Service is part of the more generic concept of cloud computing. With
the concept of IaaS a cloud provider provides raw computing capacity and basic storage and
networking capabilities to customers. Commonly IaaS is delivered in the form of a cloud-hosted
virtual instance of an operating system.
Example of IaaS providers are Amazon web Services, Microsoft Azure and Oracle Cloud.

1.3
Conceptual view on PaaS
PaaS or Platform as a Service is part of the more generic concept of cloud computing. Next to
the concept of IaaS (infrastructure as a Service) and SaaS (Software as a Service) PaaS is one of
the main three conceptual verticals within cloud computing. Within the concept of PaaS a
software platform is delivered to customer, for example, a middleware platform or a database.
Depending on the model in which PaaS is delivered the end-customer of the PaaS concept has
access to the operating system (IaaS) layer or has only access to the delivered software platform
and access to the operating system is limited or non-existing.
Examples of PaaS providers are Google, Red Hat and Oracle Cloud.
1.4
Conceptual view on SaaS
SaaS or Software as a Service is part of the more generic concept of cloud computing. Next to
the concept of IaaS (infrastructure as a Service) and PaaS (Platform as a Service) Saas is one of
the main three conceptual verticals within cloud computing. Within the concept of SaaS the
customer will be delivered a fully functional software product without having the need to know
about, care about or interact with operating systems and/or middleware and databases.
Examples of SaaS providers are Netsuite, Salesforce and Oracle On Demand.
1.5
Conceptual view on DBaaS
DBaaS or Database as a Service is a subpart of platform as a service. Within the concept of
Database as a Service the customer is delivered a database without the direct need to have
knowledge about the operating system and the way the operating system is hosted. The
customer gets access to the database directly and is responsible for managing the database
internally. In this concept DBaaS provider is responsible to ensure the technical foundation for
running the database in line with the agreed SLAs is guaranteed. Commonly customers do not
have direct access to the operating system or other layers below the database.

2 Remote listeners
Oracle defines Remote Listeners in the official documentation in the following terms:
A remote listener is a listener residing on one computer that redirects connections to a
database instance on another computer. Remote listeners are typically used in an Oracle Real
Application Clusters (Oracle RAC) environment. You can configure registration to remote
listeners, such as with Oracle RAC, for dedicated or shared server environments.
For remote listeners the analogy can be made with DNS services for the resolving of hostnames
to IP addresses. The concept of DNS is that you request connection information to a remote by
the DNS server who will return the IP address information as a response to your request. As
DNS servers are centrally organized you only need one point of entry to request the IP address
for a domain name. In the same a client can request the connection string to a database by
asking the remote listener for it. The response from the remote listener will be connection
details to the database.
The advantage of using remote listeners is that clients do not need to maintain a local set of
connection details and do not need to update this local information when the location of the
database changes. The client will always request the information from the remote listener who
will provide the accurate and up-to-date information to the client who can act upon this
information by establishing a connection to the database.
2.1
Remote listeners deployment architecture
Remote listeners can be deployed and used for multiple scenarios within this document an
outline is given for a single site DBaaS Database as a Service cloud.
As remote listeners will be playing a vital role within your database as a service architecture
and will have a vital role in connecting clients to the database it is important to ensure you do
not create a single point of failure. It is advisable to create a set of remote listeners. In the below
example, Fig2.1, a set of 3 remote listeners has been deployed. The number 3 is selected to
ensure that when one of the remote listeners fails there is still a high available situation.
It is important to note that remote listeners are positioned by Oracle as an additional role for a
database server and not necessarily a dedicated role. Due to the criticality of remote listeners in
a large database as a service landscape remote listeners are in this case positioned as a
standalone solution. This is not directly in line with the architectural views of Oracle however
for a large database as a service deployment considered the best solution to ensure availability.

Fig2.1

When deploying remote listeners in a database as a service concept the changes are high that
machines will be deployed on virtual machines. It is important to understand that remote
listeners should not form a single point of failure To ensure that they will not become a single
point of failure even though you already have a triple setup there is the need to ensure that the
remote listeners are, in the used virtualized database as a service example, are not placed in the
same virtual machine but all have their own virtual machine and the used virtual machines do
not use the same physical hardware. By ensuring this, the loss of a virtual machine or even a
physical host will not lead to the full loss of the remote listener service.
Remote listeners are by default not a clustered solution. This means that when a database is
registering to a single remote listener this information will not be propagated to the other
remote listeners in the set. To ensure that a database will register itself to all remote listeners
that are available as shown in figure Fig.2.2.

Fig2.2

As stated, remote listeners are not a clustered solution, they are deployed as a set of remote
listeners however they do work individually and not in a clustered mode. For high availability
reasons there is the need to have all the remote listeners work as a single entity which is broken
down in multiple assets, the individual remote listeners in this case. By ensuring the set of
remote listeners is seen as a single entity by the clients they will only have a single point of
contact to request connection information to a database.

Fig2.3

As shown in figure Fig2.3 a network load balancer is placed in front of the set of remote
listeners. The VIP address which is exposed to the clients is the main entry point to the set of
remote listeners. You will only have to communicate the VIP address of the remote listener to
the users and not the individual remote listener names.
2.2
Remote listeners network setup
Within the general setup of remote listeners for a private DBaaS, DataBase as a Service concept
we do use 3 types of networks all for their own purpose. In the full deployment of a DBaaS
private cloud there are more types of networks that play a vital role in the end-to-end solution
however are excluded from this document.
In this example we have 4 network types; every network type will be / can be separated into
different network segments to assure segregation between different systems. For example;
development, test, acceptance and production. Used network types are:

Internal database network (IDN)

Used to connect databases to the remote listeners.
Remote listener network (RLN)
Used to connect remote listeners to the load balacer.
User database network (UDN)
Used to connect clients to (A) the load balancer (B) to the databases.
Data Center Network (DCN)
Not a network as such however in this example it represents the entire datacenter
network in which application servers and clients reside. In a real-world example this
network will exists out of multiple segregated networks segments.

Below image, Fig2.4, shows the full deployment of the mentioned networks in the end
solutions. Excluded from this image are network firewalls and other networks that do play a
role in the Database as a Service concept who are however not directly related to the role of
remote listeners within the Database as a Service concept.

Fig2.4

2.3
Database registration flow
To ensure clients can use the remote listener it is vital that databases inform the remote listener
where they reside and how they can be reached. It is important to understand that how they can
be reached should be seen from the clients point of view and in this case this means from the
user database network or udn.company.com network.
When a database is started it will check the database parameter remote_listener. If a value is
found the PMON process will try to register at the remote listener instance. In the used example
the value of the parameter is remote_listener is REMOTE_LISTENER as shown below.
Example:
SQL> show parameter remote_listener
NAME
TYPE
VALUE
------------------------------------ ----------- --------------remote_listener
string
REMOTE_LISTENER

In this case the value REMOTE_LISTENER refers to a reference in the local tnsnames.ora
file which contains the 3 remote listeners where the database needs to register itself. Important
to note is that the hosts are registered without a domain in this case. This means that your
operating system running the database needs to be able to find the host based upon only the
hostname and needs to be able to ensure it finds the correct remote listener host in the correct
network segment, in our example case *.IDN.company.com
Example:
REMOTE_LISTENER=(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=remote_lis_0)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=remote_lis_1)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=remote_lis_2)(PORT=1521))
)
)

2.4
Client request flow
When looking at the client side of the remote listener process a client (for example an
application server) will contact the remote listener, the remote listener will inform the client
about the exact connection details of the database. A handoff will take place and the connection
will be established between the client and the database.
In our example case the client will contact db_cloud.company.com which is a network load
balancer and not a remote listener. Reason for this is that, due to the vital role of the remote
listeners in the architecture, there is the need for a high available solution.
The load balancer will balance the load over the three remote listeners and will select one to
send a specific request to. The load balancer can use a round-robin algorithm or a least
connection algorithm to balance the load over the three remote listeners. Also a combination of
those can be used. The load balancer will need to be configured with a VIP address on the front
to be able to be contacted on db_cloud.company.com on the front of the load balancer and a
SNAT address to ensure the correct route back to the client.
When the client requests a connection to a database based upon the service name it will do so
against db_cloud.company.com. This means that you do not need to have any other details then
the name of db_cloud.company.com and the instance name you want to connect to.

As an example, if you need to connect your appdevserver0 which resides in the DCN network
to a database instance named TESTDATASTORE you can do so by connecting to
db_cloud.company.com . In the below example you see how the connection is established.
Example:
SQL>
SQL> !hostname
Appdevserver0.dcn.company.com
SQL>
SQL> conn username/password@db_cloud.company.com/TESTDATASTORE
Connected.
SQL>
SQL> select instance_name,host_name from v$instance;
INSTANCE_NAME
HOST_NAME
---------------- ------------------------TESTDATASTORE
dbhost_0656.udn.company.com

As can be seen in the above example you connect to db_cloud.company.com and after the
connection is created the actual connection is not to db_cloud.company.com but rather to a
database on the host dbhost_0656.udn.company.com.

10

3 Configuration examples
Throughout the document a number of configuration examples are used. For your convenience
they are shortly described again below.
3.1
Database parameter remote_listener
If you want PMON to register with a remote listener, configure
the REMOTE_LISTENER parameter in the initialization parameter file to locate the remote
listener. In the example case the parameter remote_listener is set to a listener alias with the
value REMOTE_LISTENER which is resolved to the listener protocol addresses via the
tnsnames.ora file on the database server.
Example:
SQL> show parameter remote_listener
NAME
TYPE
VALUE
------------------------------------ ----------- --------------remote_listener
string
REMOTE_LISTENER

3.2
Local tnsnames.ora file
To enable PMON to resolve the value remote_listener parameter to the listener protocol
addresses the listener alias needs to be know in the local tnsnames.ora file. As we use three
separate remote listeners to be able to ensure high availability all three needs to be mentioned in
an address_list.
Example:
REMOTE_LISTENER=(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=remote_lis_0)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=remote_lis_1)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=remote_lis_2)(PORT=1521))
)
)

3.3
Local /etc/resolv.conf file
As shown in the example of the tnsnames.ora file we do not use a fully qualified name,
meaning we only use a hostname and not the combination of a hostname and domain name.
Main reason for this is that in real-life situations you most likely have multiple zones for
development, test, acceptance and production. However, you do want to maintain a single
template for your operating system and database deployments. When your local Linux
operating system needs to lookup, for example, remote_lis_0, it needs to be informed it needs to
search in IDN.company.com. To enable the system to do so ensure the below configuration is
present in your local /etc/resolv.conf configuration file.
Example:
search idn.company.com

11

About the authors

Johan Louwers
Johan Louwers has worked as a developer, administrator, manager, project
manager, managing consultant and senior architect within several IT companies
and IT departments. He specializes in Oracle technology, infrastructure
technology, and IT strategy and has been advising and actively working with a
large range of customers and companies to help enterprises excel in their dayto-day operations and provide them with cutting-edge technology and solutions.
His is currently a managing consultant and chief architect at Capgemini. Specialized in Oracle
technology, infrastructure solutions and cloud computing, Johan has been selected by
Capgemini to be one of the global Capgemini Experts and thought leaders, providing active
advice and support to enterprises around the globe.
He is one of Capgeminis leading global resources on Oracle Engineered Systems and
converged infrastructure in combination with Big-Data and high availability database and
application solutions.
He spearheads Capgemini cloud initiatives around Oracle public cloud and Oracle Run, a
cloud-based hosting platform specifically designed within the Capgemini datacenters to provide
an Oracle optimised cloud platform for customers using Oracle VM, Oracle Linux and Oracle
Enterprise Manager.
Johan actively maintains a blog, johanlouwers.blogspot.com, and he is an active developer and
researcher in the fields of big-data, map-reduce, hadoop, HDFS, Linux technology and
datacenter optimization and has interest in security, database technology and open source
technology.

Peter Lengkeek
Peter Lengkeek is the founder and CEO of Scott Tiger Oracle & Cronacle
Consultancy and is an active senior Oracle Database Administrator and Oracle
cloud technical consultant. Peter has supported customers in a wide range of
industries and is currently an external consultant working dedicated for
Capgemini.
Within his role within Capgemini is responsible for a number of services around Database as a
Service concepts from both a technical as well as a functional and procedural points of view.
He has a strong vision on deployment of private database concepts within Enterprises.
Peter is currently primarily focussing on Oracle technology for private cloud concepts and is
also working on concepts where Oracle and the Openstack platform join forces to provide the
best possible integration between multiple private and public clouds.

12