Visio-QlikView Load Balancing Scenariosqlikview.oxs.ru/install/Goods/QVDocumentation/Enterprise...

QlikView Load Balancing Scenarios

OverviewThis document shows several scenarios for load balancing clustered servers with

QlikView 9 and above. It is intended to act as a guide for discussions and

architecture planning for large deployments. These scenarios are not best

practices, but are instead examples of configurations that provide distinct

advantages for different scalability scenarios.

The subsequent pages in this document describe the scenarios. Please note: while

all of these scenarios depict two (2) QlikView Servers clustered together, the same

capabilities apply to clusters of 3-to-n servers. A 2-server cluster was shown on

each scenario to simplify the diagram and discussion to the relevant points.

It is assumed that the audience is familiar with the QlikView architecture and

clustering concepts prior to reading these scenarios.

Author: BPN, QlikTech NA

© 2010 QlikTech International AB. All rights reserved. QlikTech, QlikView, Qlik, Q, Simplifying Analysis for Everyone, Power of Simplicity, New Rules, The Uncontrollable Smile and other QlikTech products and services as well as their respective logos are

trademarks or registered trademarks of QlikTech International AB. All other company names, products and services used herein are trademarks or registered trademarks of their respective owners. The information published herein is subject to change without notice.

This publication is for informational purposes only, without representation or warranty of any kind, and QlikTech shall not be liable for errors or omissions with respect to this publication. The only warranties for QlikTech products and services are those that are set

forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting any additional warranty.


Key Features of QlikView for Load BalancingLoad balancing has been available with QlikView prior to version 9, but it required external

hardware and software to make it work, namely an NLB or switch device to determine the load

balancing methodology and to route the traffic accordingly.

With QlikView 9 and above, the QlikView AccessPoint now has the capability of performing

most of these capabilities for us, and goes beyond the traditional features with its new

document awareness capability. The ability for the AccessPoint to determine whether or not a

document is already loaded in memory on each of the clustered servers means that it can now

accommodate unbalanced clusters of servers. Meaning, we can take advantage of certain

applications (QlikView documents) only residing on some of the servers and not others.

This allows us to configure clusters that provide the traditional failover and redundancy, but

can also be dedicated to certain applications. It is important to note that when an application

(QlikView document) is loaded on one server but not the other server in a cluster, the server

with the application loaded in memory will receive all of the sessions requesting that

application, until that server has no availability, at which time the other server will load the

application into memory and begin serving requested sessions. The pre-loading of

applications into the servers is what drives this behavior. This functionality is not yet built into

the QlikView Management Console. This means manual pre-loading or an external process

to pre-load will be needed until this feature is integrated into the QEMC.

Scenarios 1 and 2 are the most popular with large QlikView deployments, but the other

scenarios are also useful when dealing with more specific technical requirements.






SAN/NAS/Shared Disk


Goal is equal distribution of load

When you need high availability and

resiliency both

When the web traffic for AJAX clients

and custom web apps is light enough to

not need dedicated AccessPoints

Server Availability

Round robin

Session counts

RAM/CPU available

When would you use this:

Pros:

Cons:

Scenario #1:

Balanced cluster utilizing NLB or switch and resident AccessPoints

Equally distributes load based on any

of the methodologies in diagram

Can use most NLB and switch

technologies

One AccessPoint can go down and the

cluster still runs

Needs load balancing hardware/

software

This scenario uses AccessPoint

resident on each server, causing some

cannibalization of RAM/CPU for web

services

Users

QlikView Apps: A,B,C,D,E

Balance Methods:

NLB Device(s)

or Switch

Apps A,B,C,D,E

pre-loaded

Apps A,B,C,D,E

pre-loaded

QlikView Server 1 QlikView Server 2

AccessPoint 1 AccessPoint 2






Note: AccessPoints are

resident on the QlikView

servers in this scenario

SAN/NAS/Shared Disk



When you need high availability and

resiliency both

When the web traffic for AJAX clients

and custom web apps is heavy enough

to need dedicated AccessPoints

Server Availability

Round robin

Session counts

RAM/CPU available


Pros:

Cons:

Scenario #2:

Balanced cluster utilizing NLB or switch and dedicated AccessPoints

Equally distributes load based on any

of the methodologies in diagram

Can use most NLB and switch

technologies

One AccessPoint can go down and the

cluster still runs

Web traffic processing separated from

QlikView servers, given them more

processing capacity for QVWs

Needs load balancing hardware/

software

Need servers for AccessPoint (virtual

or physical)

Users


Balance Methods:

NLB Device(s)

or Switch

Apps A,B,C,D,E

pre-loaded

Apps A,B,C,D,E

pre-loaded

QlikView Server 1 QlikView Server 2






AccessPoint 1 AccessPoint 2

Note: AccessPoint

servers are separate

from QlikView Servers

in this scenario

SAN/Shared Disk

Server sizes are the same


Don’t want to use NLB or switch

Server Availability

Round robin

RAM available

Document load

status


Pros:

Cons:

Scenario #3:

Balanced cluster utilizing QlikView AccessPoint

Equally distributes load based on

methodologies in diagram

No additional hardware/software

needed as this is standard with

QlikView Server

Doesn’t favor one server over the other

if they are of different sizes

Single AccessPoint is a potential single

point of failure

Users


Balance Methods:

Apps A,B,C,D,E

pre-loaded

QlikView Server 1

AccessPoint

Apps A,B,C,D,E

pre-loaded

QlikView Server 2







Note: AccessPoint can

be on dedicated server

or resident on one of the

two QlikView Servers in

the diagram

Goal is primary server with clustered

secondary server providing failover

Primary server RAM/CPU sufficient for

all production sessions


Pros:

Cons:

Scenario #4:

Full failover cluster utilizing QlikView AccessPoint



QlikView Server

Not utilizing secondary server unless

primary server maxes RAM/CPU or

becomes unavailable


point of failure







SAN/Shared Disk

Server Availability

Round robin

RAM available

Document load

status

Users


Balance Methods:

Apps A,B,C,D,E

pre-loaded

QlikView Server 1

AccessPoint

No apps pre-

loaded

QlikView Server 2





the diagram

Dedicate sessions for apps A & B to

Server1, sessions for apps D & E to

Server2, and app C to both servers

equally

One server may be larger than the other

and might be dedicated to the larger

apps in this scenario, while still partially

sharing the load on common apps


Pros:

Cons:

Scenario #5:

Unbalanced AccessPoint cluster with overlap

Can take advantage of committing

larger apps to larger servers

Failover still accommodated on both

servers



QlikView Server

Need to manually load apps A & B on

just Server 1 and apps D & E on just

Server 2

Unbalanced cluster means one of the

servers could reach max capacity

before loading app on the other server

and sharing load


point of failure







SAN/Shared Disk

Server Availability

Round robin

RAM available

Document load

status

Users


Balance Methods:

Apps A,B,C

pre-loaded

QlikView Server 1

AccessPoint

Apps C,D,E

pre-loaded

QlikView Server 2





the diagram

Server1 is larger than Server2, but you

still want to cluster them to distribute

some of the load and provide failover


Pros:

Cons:

Scenario #6:

Unbalanced AccessPoint cluster with subset

Can take advantage of committing

larger apps to larger servers


servers



QlikView Server

Need to manually load apps D & E on

just Server 1




and sharing load


point of failure







SAN/Shared Disk

Server Availability

Round robin

RAM available

Document load

status

Users


Balance Methods:

Apps A,B,C,D,E

pre-loaded

QlikView Server 1

AccessPoint

Apps A,B,C

pre-loaded

QlikView Server 2





the diagram

When each server is owned by a separate

department and they want to maintain

their own performance

One server is much larger than the others

and can accommodate larger apps


Pros:

Cons:

Scenario #7:

Mutually Exclusive Cluster


servers

More predictable performance and

scaling if audiences are separate for

servers

Manual pre-loading of apps is needed

for each server




and sharing load


point of failure







SAN/Shared Disk

Server Availability

Round robin

RAM available

Document load

status

Users


Balance Methods:

Apps A,B,C

pre-loaded

QlikView Server 1

AccessPoint

Apps D, E

pre-loaded

QlikView Server 2





the diagram

Visio-QlikView Load Balancing Scenariosqlikview.oxs.ru/install/Goods/QVDocumentation/Enterprise...

Documents

Transcript of Visio-QlikView Load Balancing Scenariosqlikview.oxs.ru/install/Goods/QVDocumentation/Enterprise...