Remote Listeners for Oracle DBaaS

8/15/2019 Remote Listeners for Oracle DBaaS

http://slidepdf.com/reader/full/remote-listeners-for-oracle-dbaas 1/13

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




ii

Preface / IntroductionWith 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 donemanually and decentralized in an error prone and labour intensive process.

As the concept of cloud and specifically the concept of database as a serviceintroduces 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.




iii

Table of Contents1 Database as a Service 4

1.1 Conceptual view on cloud computing 4

1.2 Conceptual view on IaaS 4

1.3 Conceptual view on PaaS 5

1.4 Conceptual view on SaaS 5

1.5 Conceptual view on DBaaS 5

2 Remote listeners 6

2.1

Remote listeners deployment architecture 6

2.2 Remote listeners network setup 8

2.3 Database registration flow 9

2.4 Client request flow 9

3 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



4

1 Database as a ServiceThe 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 minimalmanagement 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.



5

1.3 Conceptual view on PaaSPaaS 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 tothe 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 forrunning the database in line with the agreed SLA’s is guaranteed. Commonly customers do not

have direct access to the operating system or other layers below the database.



6

2 Remote listenersOracle 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 byasking 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 belowexample, 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 howeverfor a large database as a service deployment considered the best solution to ensure availability.

Fig2.1



7

When deploying remote listeners in a database as a service concept the changes are high thatmachines 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 isregistering 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



8

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 ofremote 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 solutionhowever are excluded from this document.

In this example we have 4 network types; every network type will be / can be separated intodifferent 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 ofremote listeners within the Database as a Service concept.

Fig2.4



9

2.3 Database registration flowTo 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 client’s 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 thehostname 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 ofthose 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.



10

As an example, if you need to connect your appdevserver0 which resides in the DCN networkto 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> !hostnameAppdevserver0.dcn.company.comSQL>SQL> conn username/password@db_cloud.company.com/TESTDATASTOREConnected.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.



11

3 Configuration examplesThroughout 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 fordevelopment, 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



12

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

to-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 Capgemini’s leading global resources on Oracle Engineered Systems and

converged infrastructure in combination with Big-Data and high availability database andapplication 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 andresearcher 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 aService 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.

Documents

Remote Listeners for Oracle DBaaS