Multi-Tenancy: Da Teoria à Prática, do DB ao Middleware

Multitenancy: Da teoria à realidade, Do DB ao Middleware

Bruno Borges

Principal Product Manager

Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 3

Bruno Borges

Principal Product Manager - Middleware

Desenvolvedor, Gamer

Entusiasta em Java Embedded e JavaFX

Twitter: @brunoborges


The following is intended to outline our general product

direction. It is intended for information purposes only, and

may not be incorporated into any contract. It is not a

commitment to deliver any material, code, or functionality,

and should not be relied upon in making purchasing

decisions. The development, release, and timing of any

features or functionality described for Oracle’s products

remains at the sole discretion of Oracle.


Multi-tenancy


Multiple Apps e Single App Uma aplicação e um banco de dados

Cliente 1

Cliente 2

Cliente 3

Cliente 4

APP DB

… where client_id = ?


Multiple Apps e Single App

Um único banco de dados (schema) e uma única instância da

aplicação

– Todos os dados de todos os clientes na mesma base

– Recursos de banco compartilhados com todos

Clientes que possuem mais dados podem prejudicar clientes menores

– Dificuldade em realizar backups por clientes

Backup de todo o banco pode ser custoso, demorado

– Lógica específica para separação dos dados dos clientes

Uma aplicação e um banco de dados


Multiple Apps e Single App Uma aplicação, múltiplos bancos de dados

Cliente 1

Cliente 2

Cliente 3

APP

DB 1

DB 2

DB 3

...lookup(“jdbc/db1”);

múltiplos DS:



Múltiplos bancos de dados/schemas e uma única aplicação

– Maior complexidade em administrar N bases/schemas

– Separação dos dados de forma lógica/física

– Dificuldade em customizar

Como trabalhamos hoje?


DB 3

Multiple Apps e Single App Múltiplas aplicações e múltiplos bancos de dados

Cliente 1

Cliente 2

Cliente 3

APP 1

DB 2

SSO com redirect

APP 2

APP 3

DB 1



Múltiplas bases/schemas e múltiplas instâncias de app

– Maior custo em infraestrutura

– Dificuldade em manutenção/customização

– Escalabilidade complexa

Como trabalhamos hoje?


Multi-tenancy: do jeito certo


Uma instância, múltiplos tenants de dados Como devemos fazer?

Cliente 1

Cliente 2

Cliente 3

Cliente 4

APP

getConnection(“pdb1”);

CDB

PDB

1

PDB

2

PDB

3

PDB

4

1 único DS


Oracle Database 12c


Private Database Cloud Architectures Using Oracle Database 11g

Dedicated Databases

share servers and OS

Virtual Machines

share servers

Schema Consolidation

share servers, OS and database

Increasing Consolidation


Private Database Cloud Architectures Using Oracle Database 12c

Dedicated Databases

share servers and OS

Virtual Machines

share servers

Pluggable Databases

share servers, OS and database

Increasing Consolidation


Oracle Database Architecture Requires memory, processes and database files

System Resources


New Multitenant Architecture Memory and processes required at container level only

System Resources


OLTP benchmark comparison

Only 3GB of memory vs. 20GB memory used for 50 databases

Pluggable databases scaled to over 250 while separate database instances maxed at 50

Pluggable vs Separate Databases Highly Efficient: 6x Less H/W Resource, 5x more Scalable


Managing Shared Resources Resource management for consolidated databases

High Priority

Medium Priority

Low Priority


Expand Cluster to Support Flexible Consolidation Model

Services

Single SGA per

CDB Instance

Improved Agility With Changing Workloads

Node1

CDB Instance 1

Node2

CDB Instance 2

Multitenant Container Database (CDB)


Services

Single SGA per

CDB Instance

Expand Cluster to Support Flexible Consolidation Model

Node1

CDB Instance 1

Node2

CDB Instance 2

Node3

CDB Instance 3

Improved Agility With Changing Workloads

Multitenant Container Database (CDB)


GOLD

SILVER

BRONZE

RAC, Data Guard, Daily Incrementals

Data Guard, Daily Incrementals

Weekly Full Backups

Managing Database Service Level Tiers Change tiers as databases become more mission critical


Fast Provisioning Pluggable databases can be quickly provisioned from seed

0

5

10

15

20

25

Non CDB PDB Clone PDB using Copy-on-Write File

System

Time Taken to Provision New Database


Creating Databases for Test and Development Fast, flexible copy and snapshot of pluggable databases


Isolation and multitenancy

Fast provisioning and cloning

Secure and highly available

No application changes

Manage many as one

Greater resource utilization

Performant and scalable

Lower IT costs

Nova Arquitetura Multitenant Ideal para consolidar Cloud Databases


Integração DB 12c com Oracle WebLogic Server


Integração WebLogic com Pluggable Databases

• Integrando WebLogic Server

com Pluggable Databases

• Integração suave e coerente

• Suporte a MultiTenancy com

conexão automática ao PDB

(tenant) usando Set Container

Maior densidade e escalabilidad, Multi-Tenancy

Get Connection

Tenant1

Set Container

PDB1

Set Container

PDB2

Data Source

WebLogic Cluster

Mgd Svr 2 Mgd Svr 1

App 1

App 2

App 1

App 2 Get Connection

Tenant2

Container Database

PDB1

Tenant

1

PDB2

Tenant

2

…


WebLogic Domain 2 WebLogic Domain 1

Container Database

PDB

1

PDB

2

PDB

3

PDB

6

PDB

4

PDB

5

DS1 DS2 DS3 DS6 DS4 DS5

Integração WebLogic com PDB: 1 Datasource por PDB/Tenant

Pluggable databases aparecem

como bancos normais no

WebLogic

No WebLogic, configure um

datasource por PDB/Tenant

Maior Densidade e Escalabilidade na Camada de Dados


WebLogic Domain 1

Container Database

PDB

1

PDB

2

PDB

3

PDB

6

PDB

4

PDB

5

Datasource

Integração WebLogic com PDB: Troca de Conexão entre PDBs

No WebLogic, configure um único

datasource com conexões a todos os

tenants no banco de dados

Crie um callback handler com o label

da conexão para chamar setContainer

nas conexões

Habilita multi-tenancy nas camadas de

dados e aplicação

Permite maior densidade e

escalabilidade nas camadas de dados

e aplicação

– Melhor uso de recursos

Maior Densidade e Escalabilidade, Suporte a Multi-tenancy

Application 1: getConnection(Tenant5)

1

1

1

2

2 2

4 4 5

Connection

Label

Callback

Handler

setContainer()


Application Continuity – JDBC Replay Improved Resiliency for Better User Experience

RAC Cluster

GridLink Data Source

WebLogic Cluster

Machine 2

Managed

Server 2

Machine 1

Managed

Server 1

Machine 1 RAC

Node 1

Listener

ONS

Machine

3 Down

RAC

Node 3

Listener

ONS

Machine 2 RAC

Node 2

Listener

ONS

1. FAN Down Event:

“Node 3 Down”

2. Create Connection to

Surviving Node;

Replay if safe

Leverage feature supported in DB 12c

– Generic and GridLink datasources

DB exceptions captured at datasource layer

– Examples: RAC node failure, transient DB problem

Automatically replay requests

– Transparent to application

– Read and write requests supported

– No XA Transaction support

Benefit: Better end user experience


Application Continuity Notes

Active Gridlink and Generic datasources, 12c driver only

Leverages JDBC replay, re-implemented in 12c DB

Enabled with use of

oracle.jdbc.replay.OracleDataSourceImpl driver class

– When connection is taken from pool, “begin” is called

– JDBC calls are “remembered” through commit

– When connection is put back in the pool, “end” is called

On failure, new connection is automatically created

– Transparent to application!

– Replay is already complete when connection is given to app

How it Works in WebLogic

Limitations :cannot use

with XA, PLSQL, proxy

authentication, DRCP


Feature

WLS 10.3.6/12.1.1/12.1.2 WLS 10.3.6/12.1.1 WLS 12.1.2 WLS 10.3.6/12.1.1 WLS 12.1.2

with 11g drivers

with 11gR2 DB with 11g drivers

with 12c DB with 12c drivers

with 11gR2 DB

with 12c

drivers

with 11gR2

DB

with 12c drivers

with 12c DB with 12c drivers

with 12c DB

JDBC replay (read/write) No No No No

Yes (Read&Write w

Active GridLink only, no XA transactions)

Yes (Read&Write w

Active GridLink and Generic DataSource, no XA transactions )

Pluggable Database (PDB) No Yes (Except Set

Container) No No Yes Yes

Dynamic switching between PDBs No No No No No Yes

Database Resident Connection pooling (DRCP) No No No Yes No Yes

Oracle Notification Service (ONS) auto configuration No No No No No

Yes (Active GridLink

only)

Global Database Services (GDS) No

Yes (Active GridLink only) No No

Yes (Active GridLink only)

Yes (Active GridLink only)

JDBC 4.1 (using ojdbc7.jar files & JDK 7) No No Yes Yes Yes Yes


Elasticidade com Dynamic Clusters


Dynamic Clusters Configuração simplificada

Configuração inicial do Cluster Operações para aumentar o cluster

Server 1

Dynamic Cluster 1

Server 2

Server Template

Server 1

Dynamic Cluster 1

Server 2

Server Template

Server 3 Server 4

Server 5 Server 6

Server 7 Server 8


Dynamic Clusters Wizard

Processo interativo passo-a-passo

Criação simples de Cluster

Dinâmico

Resultados:

– Cluster com Servidores Dinâmicos

– Template de Servidor

– Mapeamento de máquinas

– Mapeamento de portas e endereços


Server Template

Uso primário para Dynamic Clusters

– Também pode ser usado com Managed Servers configurados

Servidores herdam mudanças dinamicamente

Variáveis:

– ${id} instance id

– ${serverName}

– ${clusterName}

– ${domainName}

– ${system-property-name}


Comandos de WLST para Dynamic

Clusters

– shrink (clusterName, numServers=1,

block=true, updateConfiguration=false)

– expand (clusterName, numServers=1,

block=true, updateConfiguration=false)

Comandos de notificações WLDF WLST

– Permite auto-scaling

Integração para OVM

Novo MBean ClusterLifecycleRuntime

– getNextServerName()

– getNumberRunningServers()

– getNumberShutdownServers()

– startNextServer()

– startServers(int numberToStart)

– shutdownLastServer()

– shutdownServers(int numberToShutdown)

– shutdownServers(int numberToShutdown,

int timeout, boolean ignoreSessions)

What’s Next for Dynamic Clusters


Mais “What’s Next” para Dynamic Clusters

Machine Mappings

– Max servers per machine

– Machine weight

– Machine-based cluster size increase

Listen Addresses

– IP address ranges

– List of available IP addresses


Elasticidade com Configuração Simplificada de JMS

Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Presented under Non-Disclosure Agreement – Do not Redistribute 42

Administração Cloud Nativa Simplicidade e Escalabilidade de JMS

WebLogic JMS para clouds on-premise

– Cluster-targeted JMS Servers and Stores

Benefícios

– Flexible scaling of messaging services

– Much simpler config/subdeployments

– JMS enabled on Dynamic Clusters

Expand to meet capacity demand

Contract to increase efficiency

Elastic JMS Cluster

JMS JMS JMS JMS

Contract

Expand

JMS JMS JMS JMS

JMS JMS JMS JMS

JMS JMS JMS JMS


Configuração JMS…12.1.1 e Antes

Server 1

JMS Server 1

JMS Store 1

JMS Module

Target=cluster

Subdeployment = JMS Server

1, JMS Server 2, JMS Server 3,

…

Server 2

JMS Server 2

JMS Store 2

Server 3

JMS Server 3

JMS Store 3

JMS Server 3

JMS Store 3

Cluster

JMS Server 1

JMS Store 1

JMS Server 2

JMS Store 2

Config.xml

<JMS Server 1>

<target=managed

server 1>

</JMS Server 1>

<JMS Server 2>

<target=managed

server 2>

</JMS Server 2>

<JMS Server 3>

<target=managed

server 3>

</JMS Server 3>

…


Configuração JMS…WebLogic 12.1.2 Simplicidade e Escalabilidade

Server 1

JMS Server 1

JMS Store 1

Server 2 Server 3

Cluster

JMS Server 1

JMS Store 1

JMS Server 1

JMS Store 1

JMS Server 1

JMS Store 1

JMS Module

Target=cluster

Subdeployment = JMS Server 1

Config.xml

<JMS Server 1>

<target=cluster>

</JMS Server 1>

Limitations No UOO, UOW, no SAF agents/Bridges on Dynamic/mixed

Clusters

No migration


PERGUNTAS?


OBRIGADO!

@brunoborges

blogs.oracle.com/brunoborges

Multi-Tenancy: Da Teoria à Prática, do DB ao Middleware

Technology

Transcript of Multi-Tenancy: Da Teoria à Prática, do DB ao Middleware