How to rebalance your workload using DB2 utilities in a ... - IDUG

How to rebalance your workload using

DB2 utilities in a cloud environment

Dale McInnis, IBM Canada Ltd.

Session Code: D16

Thursday November 19, 2015: 08:00 – 09:00

Platform: Linux, UNIX, Windows

2

Disclaimer

© 2015 IBM Corporation

© Copyright IBM Corporation 2015. All rights reserved.

U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

THE INFORMATION CONTAINED IN THIS PRESENTATION IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY. WHILE EFFORTS WERE

MADE TO VERIFY THE COMPLETENESS AND ACCURACY OF THE INFORMATION CONTAINED IN THIS PRESENTATION, IT IS PROVIDED

“AS IS”WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. IN ADDITION, THIS INFORMATION IS BASED ON IBM'S CURRENT

PRODUCT PLANS AND STRATEGY, WHICH ARE SUBJECT TO CHANGE BY IBM WITHOUT NOTICE. IBM SHALL NOT BE RESPONSIBLE

FOR ANY DAMAGES ARISING OUT OF THE USE OF, OR OTHERWISE RELATED TO, THIS PRESENTATION OR ANY OTHER

DOCUMENTATION. NOTHING CONTAINED IN THIS PRESENTATION IS INTENDED TO, NOR SHALL HAVE THE EFFECT OF, CREATING ANY

WARRANTIES OR REPRESENTATIONS FROM IBM (OR ITS SUPPLIERS OR LICENSORS), OR ALTERING THE TERMS AND CONDITIONS OF

ANY AGREEMENT OR LICENSE GOVERNING THE USE OF IBM PRODUCTS AND/OR SOFTWARE.

IBM's statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM's sole discretion. Information

regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision.

The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or

functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any

future features or functionality described for our products remains at our sole discretion.

IBM, the IBM logo, ibm.com, Information Management, DB2, DB2 Connect, DB2 OLAP Server, pureScale, System Z, Cognos, solidDB, Informix,

Optim, InfoSphere, and z/OS are trademarks or registered trademarks of International Business Machines Corporation in the United States, other

countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or

™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks

may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at “Copyright and

trademark information” at www.ibm.com/legal/copytrade.shtml

Other company, product, or service names may be trademarks or service marks of others.

Agenda

• What is multi-tenancy?

• Rebalance usage scenarios

• Sample Multi-tenancy Deployment models with DB2

3


What is Multi-tenancy?

• Multi-tenancy means different things to different people

• Multi-tenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client-organizations (tenants)1

• In the Infrastructure-as-a-Service context, multi-tenancy means that multiple OS instances can run on the same physical hardware through hypervisor technology

• CCIs from softlayer

• In the Software-as-a-Service context, multi-tenancy means that multiple customers run off of one live instance of software

• SQLDB Premium plan

• In the Database-as-a-Service context, multi-tenancy could mean that multiple customers co-exists in the same physical database

• dashDB Entry

4


1wikipedia

What is Multi-tenancy?

• One must clearly articulate:

• What is the tenant?

• What is being shared?

• What degree of isolation between tenants is required?

• Why deploy a Multi-tenant environment? - A paradigm shift due to:

• Consolidation

• Cost Saving

• Cloud movement

• Delivering of *-as-a-Service model5


6

Factors that influence a Multi-tenant Architecture

Economic Considerations

• Applications optimized for a

shared approach tend to require

a larger development effort

than applications designed

using a more isolated approach

(because of the relative

complexity of developing a

shared architecture), resulting

in higher initial costs. Because

they can support more tenants

per server, however, their

ongoing operational costs tend

to be lower.

© 2015 IBM Corporation6

7


© 2015 IBM Corporation7

Tenant Considerations

� The number, nature, and needs

of the tenants you expect to

serve all affect your data

architecture decision in different

ways


Security Considerations

• As your application will store sensitive tenant data, prospective

customers will have high expectations about security, and your service

level agreements (SLAs) will need to provide strong data safety

guarantees. A common misconception holds that only physical isolation

can provide an appropriate level of security. In fact, data stored using a

shared approach can also provide strong data safety, but requires the

use of more sophisticated design patterns,.e.g. FGAC (Fine-Grained

Access Control)

8



Regulatory Considerations

• Companies, organizations, and governments are often subject to

regulatory law that can affect their security and record storage needs.

Investigate the regulatory environments that your prospective

customers occupy in the markets in which you expect to operate, and

determine whether they present any considerations that will affect

your decision.

9



Skill Set Considerations

• Designing single-instance, multi-tenant architecture is still a very new

skill, so subject matter expertise can be hard to come by. If your

architects and support staff do not have a great deal of experience

building SaaS applications, they will need to acquire the necessary

knowledge, or you will have to hire people that already have it. In some

cases, a more isolated approach may allow your staff to leverage more

of its existing knowledge of traditional software development than a

more shared approach would.

10


Agenda




11


Rebalance workloads usage scenarios

• Server rebalancing

• Plan upgrade

• Compute Elasticity

• Resource Utilization

• Storage Elasticity

12

Server RebalancingServer RebalancingServer RebalancingServer Rebalancing

• IBM CDS has determined that most users will utilize the

free cloud service for only a short period of time.

• This resulted in a substantial amount of under utilized

resources.

• As such, CDS will overprovision its servers leading to the

possibility that a server becomes over utilized.

• There may be a need to move a database from one server

provider to another server provider to ensure the workload is

balanced evenly across the entire set of server providers.

• This assumes there is a way to accurately determine which

tenant us consuming the resources, which include CPU,

Memory, Storage, IO Bandwidth and NIC bandwidth. 13

Plan change Plan change Plan change Plan change

• There is a business requirement to support users migrating

between free and pay plans, as well as within the different

pay plans.

• Other reasons that will require a plan change includes

exceeding the current plan’s

• Storage

• CPU

• Memory

14

Compute ElasticityCompute ElasticityCompute ElasticityCompute Elasticity

• There is a need to be able to alter the server’s compute

resources due to either an increase or decrease in workload.

• Each plan offering’s CPU resources are statically allocated,

however over time the resources will need to be more flexible

and resize as required.

15

Resource UtilizationResource UtilizationResource UtilizationResource Utilization

• Today resources are assigned to individuals in a haphazard

method, with no knowledge of the expected usage pattern

for the user. As such, we have seen a wide range of usage

patterns on our service providers.

• We need an approach that can ensure our resource

utilization remains high without overcommitting on a

frequent basis.

• To ensure even resource utilization, we need both current

as well as historical data on resource consumption from all

of our service providers.

16

Storage ElasticityStorage ElasticityStorage ElasticityStorage Elasticity

• Each plan has defined storage limits, however when a

customer exceeds the predetermined maximum they

should not be forced to a new plan.

• Being in the cloud gives us the ability to elastically alter the

storage model to suit the customer’s needs if the rest of

the plan’s features meets the customer’s needs.

• If a tenant is on a service provider that is running low on

storage it would be desirable to move this tenant to a

service provide with either more storage capacity or

storage utilization.

17

Agenda




18


19

Multitenancy Deployment Models with DB2

Isolation Sharing

DB2

Instance

DB

OS

Hardware

Tenant Tenant

Logical

DB

Logical

DB

Logical

DB

Logical

DB

Option 4:

Shared DB

DB2

Instance

DB

OS

Hardware

Tenant Tenant

Logical

DB

Logical

DBSchemaSchema

DB2

Instance

DB

OS

Hardware

Tenant Tenant

Table

RowRow RowRow

Tenant Tenant

Option 5:

Shared Table

DB2

Instance

DB

OS

Hardware

Tenant Tenant

Table

RowRow RowRow

Tenant TenantOption 3:

Shared Instance

DB2

Instance

DB

Tenant

OS

Hardware

DB

Tenant

DB2

Instance

DB

Tenant

OS

Hardware

DB

Tenant

DB2

Instance

DB

Tenant

OS

Hardware

DB

Tenant

DB2

Instance

DB

Tenant

OS

Hardware

DB

Tenant

DB2

Instance

DB

Tenant

OS

Hardware

DB2

Instance

DB

Tenant

OS

Option1:

Shared H/W

DB2

Instance

DB

Tenant

OS

Hardware

DB2

Instance

DB

Tenant

OS

DB2

Instance

DB

Tenant

OS

Hardware

DB2

Instance

DB

Tenant

OS

DB2

Instance

DB

Tenant

OS

DB2

Instance

DB

Tenant

OS

Hardware

DB2

Instance

DB

Tenant

OS

Hardware

DB2

Instance

DB

Tenant

Option2:

Shared OS

DB2

Instance

DB

Tenant

OS

Hardware

DB2

Instance

DB

Tenant

DB2

Instance

DB

Tenant

OS

Hardware

DB2

Instance

DB

Tenant

DB2

Instance

DB

Tenant

OS

Hardware

DB2

Instance

DB

Tenant

Rebalancing Option1: Tenant per OS• Issues:

• Prone to “Noisy Neighbor” issues

• Challenging to guarantee SLA for H/W resources

• Minimize Impact

• Limit H/W resources per OS

• Resolution

• Move entire OS to another H/W deployment

• Can be completely masked from the end user

• LPAR Mobility (AIX)

• VMWare vMotion

DB2

Instance

DB

Tenant

OS

Hardware

DB2

Instance

DB

Tenant

OS

DB2

Instance

DB

Tenant

OS

Hardware

DB2

Instance

DB

Tenant

OS

DB2

Instance

DB

Tenant

OS

Hardware

DB2

Instance

DB

Tenant

OS

DB2

Instance

DB

Tenant

OS

DB2

Instance

DB

Tenant

OS

Hardware

Rebalancing Option2: Tenant per Instance

• Issues:

• Same as previous

• Share OS resources (IP Address, memory)

• OS level patch affects all tenants

• Minimize Impact

• Utilize OS enabled work load management

• Resolution

• Implement HADR setting up standby on other H/W deployment

• Issue controlled takeover to move the primary DB

• Backup and restore DB to a new H/W deployment

• Outage required from start of backup to end of restore

DB2

Instance

DB

Tenant

OS

Hardware

DB2

Instance

DB

Tenant

DB2

Instance

DB

Tenant

OS

Hardware

DB2

Instance

DB

Tenant

DB2

Instance

DB

Tenant

OS

Hardware

DB2

Instance

DB

Tenant

DB2

Instance

DB

Tenant

OS

Hardware

DB2

Instance

DB

Tenant

Rebalancing Option 3: Tenant per Physical database• Issues:


• All tenants competing for DB2 instance level resource

• Homogeneous DB2 registry settings for all tenants

• Instance outage affects all tenants

• DB2 Patches affects all tenants

• Minimize Impact

• Utilize DB2 work load Management

• Resolution

• Implement HADR setting up standby on other H/W deployment

• Issue controlled takeover to move the primary DB

• Backup and restore DB to a new H/W deployment

• Outage required from start of backup to end of restore

DB2

Instance

DB

Tenant

OS

Hardware

DB

Tenant

DB2

Instance

DB

Tenant

OS

Hardware

DB

Tenant

DB2

Instance

DB

Tenant

OS

Hardware

DB

Tenant

DB2

Instance

DB

Tenant

OS

Hardware

DB

Tenant

Rebalancing Option 4: Tenant per Schema• Issues:


• Competing for shared DB resources

• Homogeneous DB level configuration for all tenants

• Name collisions – each tenant must use a unique schema name

• Difficult to provide Point In Time (PIT) recovery support per tenant

• Any outage affects all tenants

• Requires more complex security measure to be implemented

• Requires most complex work load management configuration

• Minimize Impact

• Utilize DB2 Work Load Management

• Resolution

• Backup the tablespace and use “Transportable Schemas” to move the

schema to a new database

• Utilize db2move to export the data and create the schema on a new

database

DB2

Instance

DB

OS

Hardware

Tenant Tenant

Logical

DB

Logical

DB

Logical

DB

Logical

DB

DB2

Instance

DB

OS

Hardware

Tenant Tenant

Logical

DB

Logical

DBSchemaSchema

DB2 Utilities to assist with multi-tenant deployments

• Control the resources

• WorkLoad Manager

• Rebalance the tenants

• Transportable Schemas

• db2move

• HADR

24

Workload Management (WLM)

• The monitoring and control of work executing on a database

system to:

• Maximize system efficiency and/or throughput

• Achieve business performance objectives


WLM Concepts Overview

DB2 Workload

• Serves as the primary point of control for submitters of work and

routes work to Service Classes

DB2 Service Class

• Serves as the primary point of resource control for executing work

DB2 Threshold

• Provides limits to control behaviors of database activities based on

predictive and reactive elements

DB2 Work Action Set & Work Class Set

• Provides ability to discriminate between different types of database

activities


27

� Dispatcher controls CPU usage through shares and limits

● CPU limit

● Maximum percentage of absolute system CPU resources that the

service class can consume

● Shares

● Portion of CPU usage allocated to a service class

Workload Manager Dispatcher


27

Other

Processes

OS

Database

DB2 Instance

Operating System

Service

Class A

Service

Class B

Service

Class C

30%

50%

20%

DB2

Workload A1

Workload A2

Workload A3

Workload A4

User Requests

User Requests

User Requests

User Requests

Limit

Shares

28

WLM Dispatcher Configuration Across Instances


28

Reserve 80%

system CPU

Reserve 20%

system CPU

Tenant 1We have tenants per

OS or Instance. We

want to reserve cpu

for each tenant

workload

Tenant 2

db2 update dbm cfg using wlm_dispatcher YESdb2 alter service class sysdefault user class CPU_LIMIT 80

Tenant 1 in DB2

Instance1

Tenant2 in DB2

Instance2


Tenant2 in DB2

Instance2


WLM Dispatcher configuration Within an Instance

• Soft CPU Shares

• Imposes a soft limit when there is competition for CPU use

• Hard CPU Shares

• Imposes a hard limit when there is competition for CPU use


29

db2 update dbm cfg using wlm_dispatcher YES wlm_disp_cpu_shares YEScreate service class DAILY cpu limit 50create service class IMPORTANT HARD under DAILY cpu shares 7000create service class CASUAL SOFT under DAILY cpu shares 3000

IMPORTANT (7000 hard shares) CASUAL (3000 soft shares)

7

3

10

Both service

classes using to

their maximum

allocation

If “IMPORTANT” has no

usage, “CASUAL” can pick

up unused portions – limited

to 50% of available CPU

Relocate a tenant to another service provider which Relocate a tenant to another service provider which Relocate a tenant to another service provider which Relocate a tenant to another service provider which

has more storage has more storage has more storage has more storage

Tenancy Model Any DB Tenant

Model Target

Single DB Tenant

Target

Multi-Tenant DB

Target

Any DB Tenant

model Source

db2look/db2move

Transportable

Schemas

Single DB Tenant

Source

Backup/Restore

HADR

Multi-Tenant DB

Source

Backup / Restore*

HADR*

30

There are several options available to move data between servers and/or

plans. However, the tenancy model of both the source and target will limit the

technology that can be used to actually perform the data movement. The

following table reflects which options are possible based on the tenancy model

*All tenants are moved together

Backup/Restore DB2 backup and restore utilities provide the ability to move an entire database from any service

provider to another. The restore target can be a different hardware configuration, including more

storage. This method would require an outage as availability of the database being moved must be

stopped once the database backup image has been restored to the new service provider and

rollforward processing is about to commence. The scope of the relocation is at the database level of

granularity.

• Step 1. Perform an online backup of the database on the original service provider

db2 backup db bludb online to <local file system>

• Step 2. Copy the backup image from the local file system on the original service provider to a

local file system on the new service provider

• Step 3. Restore the database on the new service provider

db2 restore db bludb from <local file system>

• Step 4. Shut down the database on the original service provider

db2 deactivate db bludb

• Step 5. Copy the archived and active log files generated since the backup was performed

• Step 6. Rollforward through the log files

db2 rollforward db bludb to end of logs and stop

• Step 7. Activate the new database

db2 activate db bludb

• Step 8. The original database on the original service provider can be removed

db2 drop db bludb 31

Transportable Schema

• The objective of this solution is to provide an integrated method to transport entire schemas / table spaces from one database into another database

• This has been achieved through extensions to the DB2 RESTORE utility

• The approach will restore the tablespaces, recreate the schema and then attach the tablespace containers to the target database

32

Transport Sets Prereq

33

tablespace4

schema4

tablespace6tablespace2 tablespace3 tablespace5tablespace1

schema3

schema5

schema1

schema2

works works works

doesn’t work

Transportable Schema Example• In the current multi-tenant deployments each tenant is assigned a unique schema and all data is

stored in a separate table space. This allows for the exploitation of DB2’s transportable schema

capability. In transporting a database schema involves taking a backup image of a database and restoring

the schema to a different existing database. When the schema is transported, the database objects will

be recreated and the data will be restored to the new database. The target schema must not already

exists in the target database.

The following in an example of how to transport Schema S1 in table space T1 from database D1 on Host

H1 to database D2 to Host H2

• Step 1: Take an online backup of the primary database

H1: db2 backup db d1 online to <local file system>

• Step 2. Copy the backup image from the local file system on the original service provider to a local

file system on the new service providers

• Step 3. Transport the schema from the backup image into the target database

H2: db2 restore db D1 tablespace (T1) schema (S1) online transport into D2

• Step 4. Drop the schema from the original DB

CALL SYSPROC.ADMIN_DROP_SCHEMA('SCHNAME', NULL, 'ERRORSCHEMA', 'ERRORTABLE')

• Step 5. Update client’s reverse proxy information 34

What will be transported• Tables / CGTTs / MQTs / ‘normal + stats’ Views

• Generated columns

• Expression

• Identity

• Row change timestamp

• Row change token

• UDFs / UDTs + generated functions

• Constraints

• Check

• Foreign key

• Unique / primary

• Functional dependency

• Indexes

• Triggers

• Sequences

• Procedure – not external routine executable

• Object authorizations / privileges / Security / Access control / Audit

• Table Statistics + profiles / hints (plan lockdown)

• Packages35

36

What will NOT be transported

• Created Global variables

• Aliases

• Jobs

• Index extensions

• Hierarchical tables, typed tables, typed views

• Nicknames

• Structured types

• methods

• Servers

• Wrappers

• Functional mappings & templates

• OLE DB External functions

• sourced Procedures

• XML - sysxmlstrings and sysxmlpaths collisions an issue

DPF and pureScale environments are not be supported

Db2look / db2moveThe db2move utility retrieves a list of all user tables in the source database and then exports

these tables in PC/IXF format. The PC/IXF files can be transferred, imported or loaded to the

target database on another system. The db2look utility captures the DDL for database objects

in the source database, and apply it to recreate those objects in the target database.

Step 1. Export data from the source database into data files

db2move bludb export -sn <source schema>

db2look -d bludb -e -z <source schema> -o db2look.out

Step 2. Transfer the data files to the target system

scp migration/* db2inst1@<target host>://mnt/blumeta0/home/db2inst1/migration

Step 3. Create the user tables in the target database

sed -i 's/<source schema>/<target schema>/g' db2look.out

sed -i 's/<source schema>/<target schema>/g' db2move.lst

db2 -tvf db2look.out

Step 4. Import data files to the target database

db2move bludb import -io replace

37

db2move examples

Example 1 – Move all tables in schema1 from MYDB1 to database MYDB2

db2move MYDB1 export -aw -l /tmp/lobs -sn schema1db2move MYDB2 import -io replace_create -l /tmp/lobs

Example 2 – Move all tables in schema1 from MYDB1 to database MYDB2

db2move MYDB1 COPY -sn schema1 -co TARGET_DB MYDB2 USER myuser1 USING mypass

Example 3 Example 3 Example 3 Example 3 – Duplicate schema schema1 from source database dbsrc to

target database dbtgt, rename the schema to newschema1 on the target,

and map source table space ts1 to ts2 on the target

db2move dbsrc COPY -sn schema1 -co TARGET_DB dbtgt USER myuser1 USING mypass1 SCHEMA_MAP ((schema1,newschema1)) TABLESPACE_MAP ((ts1,ts2), SYS_ANY))

38

HADR

• DB2 HADR technology permits the creation of a secondary copy of the

database which is kept in sync with the original automatically. Similar

to Backup/Restore allows us to move an entire DB from any service

provider to another provider, with minimal interruption. The scope of

the relocation is at the database level of granularity.

• If the service provider is not using HADR for availability, then the

procedure would be to setup/configure a Principal standby; once it is in

peer state perform a role reversal to promote the principal standby to

become the primary database.

• If the service provider is already using HADR for availability, the

procedure would be to setup an Auxiliary standby; once it is in sync

perform a role reversal to promote the auxiliary standby to become the

primary database.

39

Moving from one HADR cluster to another HADR clusterIf a service provider is already in an HADR cluster that does not have sufficient resources to meet the

customer’s demands then it is possible to move this data to a new HADR cluster using a pair of auxiliary

standbys. Two auxiliary standbys would be added to the existing HADR cluster and once these machines

are caught up with the current primary, one will be chosen as the new primary while the other will

become the new principal standby. The original primary and principal will be orphaned from the new

topology and thus the database can be dropped.

To add a pair of Auxiliary standbys to an existing HADR cluster a recent backup image of the primary

machine must be used. The database will have to be restored to the new service providers and the

database configuration on the HADR primary must be updated to reflect the new HADR members. Once

the Auxiliary standbys are caught up a role reversal “normal takeover” can be issued to promote one of

the new service providers as the HADR primary and the other new service provider will become the

principal standby. The steps to follow are:

Environment:

Primary Host = H1, Primary Host HADR Port = P1,

Principal Standby Host = H2, Principal Standby HADR Port = P2

Auxiliary Host 1 = H3, Auxiliary Host HADR Port 1 = P3

Auxiliary Host 2 = H4, Auxiliary Host HADR Port 2 = P4

40

Primary

Principal standby

Auxiliary standby

Hostname: host4

Port: p4

Hostname: host2

Port: p2

Hostname: host3

Port: p3

Host name: host1

Port: p1

Auxiliary standby

SY

NC

SUPERASYNC

HADR Multiple Standby Example

SY

NC

Primary

Principal standby

Moving from one HADR cluster to another HADR clusterStep 1. Take an online backup of the primary database

H1: db2 backup db bludb online to <local file system>

Step 2. Copy the backup image from the local file system on the original service provider to a local file

system on the new service providers

Step 3. Restore the database on both service providers

H3: db2 restore db bludb from <local file system>

H4: db2 restore db bludb from <local file system>

Step 4. Update the database configuration to reflect the current HADR Topology and activate HADR

on both new auxiliary standbys

H3: db2 update db cfg for bludb using HADR_LOCAL_HOST H3

H3: db2 update db cfg for bludb using HADR_LOCAL_SVC P3

H3: db2 update db cfg for bludb using HADR_TARGET_LIST H4:P4

H3: db2 start hadr on db bludb as standby

H4: db2 update db cfg for bludb using HADR_LOCAL_HOST H4

H4: db2 update db cfg for bludb using HADR_LOCAL_SVC P4

H4: db2 update db cfg for bludb using HADR_TARGET_LIST H3:P3

H4: db2 start hadr on db bludb as standby 42

Moving from one HADR cluster to another HADR clusterStep 5. Update the HADR Target list on the primary to include the new auxiliary standby

H1: db2 update db cfg for bludb using HADR_TARGET_LIST H2:P2 | H3:P3 | H4:P4

Step 6. Monitor the auxiliary standby until the log gap is small

H3:db2pd –hadr -db bludb | grep ‘PRIMARY_LOG_FILE, PAGE,

POS|STANDBY_LOG_FILE,PAGE,POS’

H4:db2pd –hadr -db bludb | grep ‘PRIMARY_LOG_FILE, PAGE,

POS|STANDBY_LOG_FILE,PAGE,POS’

Step 7. Once the auxiliaries is caught up perform a role reversal on the auxiliary standby

H3:db2 takeover on db bludb

At this time the new HADR cluster will consist of only H3 and H4.

Step 8. Cleanup the original service providers

H1: db2 deactive db bludb

H1: db2 drop db bludb

H2: db2 deactive db bludb

H2: db2 drop db bludb

43

Current SQLDB Planned Offerings

Plan Name Original small plan Entry (aka free) plan Premium

Max Data

capacity

(Free 2GB); Max

10GB

(Free 100MB); Max 5GB 500GB

Hardware

Sharing

Database (Shared

VM)

Bare Metal Shared VM

Tenant Model Instance – Multiple

DBs per instance

Schema per instance Database per instance

Security and

compliance

• Data Encryption

• SSL

• Data Encryption

• DDL

• Data Masking

• Compliance Reporting

• Audit Reporting

Availability and

Disaster

Recovery

1 daily automated

backup

Point in Time

recovery (5 days)

Zero data loss

architecture

• 1 daily automated

backup

• Restore to last

backup (for all

tenants)

• 5 Automated / User initiated backups

• Point in Time recovery (20 days)

• HA Replica

• 2 DR replicas

Localization Local codesets /

Langs

Local codesets / Langs User specified, ~30 langs

Max Concurrent

Connections

20 10 100

Current dashDB Plan Offerings

Plan Name Entry Enterprise 1TB Enterprise 4TB Enterprise 12TB

Max Data capacity (Free 1GB); Max

20GB

1TB 4TB 12TB

Hardware Sharing Bare Metal Shared VM Bare Metal Bare Metal

Tenant Model Schema per user Single DB Single DB Single DB

Security and

compliance

Data Encryption

SSL

Data Encryption

SSL

Data Encryption

SSL

Data Encryption

SSL

Availability and

Disaster Recovery

1 daily automated

backup

Restore to last

backup (for all

tenants)

Point in Time

recovery (3 days)

Zero data loss

architecture

1 daily automated backup

Restore to last backup

(for all tenants)

Recovery from 3 days


Restore to last backup (for all

tenants)



Restore to last backup (for all

tenants)


Localization Local codesets /

Langs

Local codesets / Langs Local codesets / Langs Local codesets / Langs

Max concurrent

connections

Unlimited Unlimited Unlimited Unlimited

11/19/2015

Lessons learnt from deploying dashDB / SQLDB

1. Extensive monitoring is required

2. Reserve Proxy / DNS is required

3. Determine what the SLAs should be

4. Implement WLM to control resource consumption

46


Extensive Monitoring Cloud Service Provider perspective:

• Provisioning on new service instances, i.e. can customers still create new service

instances (databases, Hadoop clusters, etc.)

• Service availability, i.e. can consumers still interact with existing service

instances (connect to a database and run a query, run a Hadoop job, etc)

• Component Monitoring, i.e. do all the components under the covers operate

correctly (is the database process running, is ldap up, is the disk full, the CPU

usage within limits, etc.)

• Capacity monitoring, i.e. do we still have enough excess capacity to deal with

additional consumer requests for new instances or extra workload capacity

• Log Management, i.e. collect all logs, retain them for compliance reasons,

analyze then, fire of log monitoring alerts if needed

47


Extensive Monitoring Cloud Service Consumer perspective

• Monitoring of the individual cloud services that we have dependencies on

• Is the database connection alive, are queries returning with acceptable response times

• Is the HTTP service running and within operating boundaries (memory, request/second served, etc)

• Status page of service providers, are there reported problems that will impact me?

• Monitoring of the overall status of the application

• Monitor the main flow of the application, e.g. the sales funnel in a commerce app, can I still select a product,

check it out and make a credit card payment

• Consistency checks: e.g. do request and response line up, does total credit card income match total sold in my

database

• Monitor the end-user behavior

• Incoming application service requests, e.g. HTTP request to the web site, are they out of normal bounds,

promotion is going viral

• Capacity, do I need to scale up to additional capacity and on what aspects of my application (DB, HTTP,

backend code, etc.)

• Application security aspects: failed login attempts, unusual SQL, configuration changes, server access, DOS

monitoring

• Be aware of Service Provider maintenance windows

48


Reserve Proxy / DNS

• Publish IP/Hostname to clients

• All connections come through reverse proxy host to resolve public

IP/Hostname to current backend IP/Hostname

• Public Domain example HA Proxy

49


Requirements to enable rebalancing of workload• Ability to move the back end server without notification to the end

user

• Reverse Proxy (HA Proxy)

• DNS lookup

• Ability to isolate a tenants data from all other tenants

• Lowest level granularity possible today is the schema / table space

• Recommend to keep 1 to 1 mapping of schemas to table spaces (not

enforceable by DB2 today)

• Ability to restrict resource consumption

• Minimize effect of noisy neighbors

• Utilize WLM Policies to enforce CPU and Memory consumption

• Utilize table space definitions to ensure storage consumption

• Not possible today to restrict I/O utilization

50


Recommendations

• Ensure Reverse Proxy and DNS are in place before initial

deployment

• Be prepared to monitor systems closely to ensure SLAs are

being meet

• Build in regular maintenance windows on a scheduled

basis, e.g. 1 hour weekly with a 4 hour monthly window.

• Do not need to use all of these windows, but have the option to do

so

• Implement HADR for ESE systems to allow for very fast

redeployments with minimal interruption

51


Dale McInnisIBM Canada Ltd.

[email protected]

How to rebalance your workload using DB2 utilities in a cloud environment

Session: D16Please fill out your session

evaluation before leaving!

How to rebalance your workload using DB2 utilities in a ... - IDUG

Documents

Transcript of How to rebalance your workload using DB2 utilities in a ... - IDUG