Upload
sworna-vidhya-mahadevan
View
230
Download
0
Embed Size (px)
Citation preview
8/13/2019 SUP 2.0 Sizing Guide WP
http://slidepdf.com/reader/full/sup-20-sizing-guide-wp 1/12
WHITE PAPER
www.sybase.com
Sybase® Unwired Platform 2.0Sizing Guide – Workflow and Cache Synchronization
8/13/2019 SUP 2.0 Sizing Guide WP
http://slidepdf.com/reader/full/sup-20-sizing-guide-wp 2/12
TABLE OF CONTENTS
1 Introduction
1 Functions of Sybase Unwired Platform
1 Mobile Workflow Enablement
1 Architecture of Mobile Workflow Deployment
2 Mobile Synchronization Applications
2 Cache Synchronization Deployment
3 Cache Synchronization Architecture
4 Sizing Fundamentals and Terminology
5 Initial Sizing for Workflow Applications
5 Assumptions
6 Business Scenario
6 Data Object Structure
6 Key Considerations for the Sizing Analysis
6 Initial Sizing for Cache Applications 6 Assumptions
6 Business Scenario
6 Data Object Structure
7 Key Considerations for the Sizing Analysis
9 Appendix
9 Deployment Options
10 Physical I/O Subsystems
10 Network Latency
10 Feedback
8/13/2019 SUP 2.0 Sizing Guide WP
http://slidepdf.com/reader/full/sup-20-sizing-guide-wp 3/12
1
INTRODUCTION
This document is designed for service providers and enterprises that plan to deploy Sybase Unwired Platform
(SUP) and need to understand the different technology options and sizing considerations. Prior to deploying SUP,
you will need to make several technology decisions based on the requirements of your mobile application(s). These
technologies impact downstream sizing estimates for each component of the system. This paper will help define the
questions and answers related to technologies and sizing that everyone should ask prior to deploying SUP. Making
these assessments and decisions early in the process is essential in ensuring a successful project rollout.
Sizing guidance for the SUP messaging and replication nodes and associated data tier nodes are supplied
separately for the case of deploying the data tier on its own hardware (see the white paper “Sizing Fundamentals and
Terminology” for more information on the deployment options). The SAP® sizing numbers for the SUP server and data
tier must be taken together to account for the entire solution.
The memory requirements given in the sizing guidance is the suggested memory for the respective tier including
the operating system. If the solution is deployed on a single host, the memory requirements for both nodes should
be combined. The minimum memory requirement for any one host is 8 GB. When the nodes are deployed separately
and the sizing for a tier is shown to be below the minimum, use the minimum as the guidance for each node. For
example, if a small deployment is planned and the SUP node requires 4 GB and the data tier 4 GB, a single host install
would require 8 GB and a two host install would require 8 GB on the SUP node and 8 GB on the data tier.
FUNCTIONS OF SYBASE UN WIRED PLATFORM
Individuals and businesses develop mobile applications for specific user needs ranging from teams of service
workers who use devices for industry-specific applications to consultants who track time and expenses on a mobile
device for synchronization to a back-office system at a later time. SUP provides capabilities that support these mobile
scenarios as well as cross-industry applications, such as customer relationship management, human resources, supply
chain management, business intelligence, and product lifecycle management, and industry-specific applications
tailored for the service provider, chemical/pharmaceutical, and utilities industries.
SUP supports two major types of mobile application deployment configurations:
• Mobile workflow enablement
• Mobile synchronization applications
– Custom-designed applications using synchronization and caching in a stand-alone mode
– Mobile applications using synchronization with the Data Orchestration Engine (DOE)
Mobile Workflow Enablement
SUP provides Mobile Workflow technologies that enable mobile device users to be workflow participants. SUP provides
the last-mile connectivity for workflow applications, allowing the mobile user to start and respond to back-end
enterprise requests within a generic framework. Mobile Workflow utilizes the concept of a container on the device. A
container is a native application with a Web browser plug-in and built-in SDK for connectivity, guaranteed messaging,
caching and security. Mobile Workflow relies on messaging between the server and a container on the devices that
invokes either on-line operations to the back-end or cached Mobile Business Object (MBO) data in the SUP server.
Architecture of Mobile Workflow Deployment
In the workflow architecture, changes to back-end workflows (generally sent via data change notifications (DCN))
result in the creation of messages that are sent to the messaging server for dispatch. Spooled messages that meet
a specified set of matching criteria are placed in a queue for processing by plugins to the messaging transformer
component, which augment the message with application-specific data or processing instructions.
8/13/2019 SUP 2.0 Sizing Guide WP
http://slidepdf.com/reader/full/sup-20-sizing-guide-wp 4/12
2
Figure 1. Mobile Workflow Architecture
Once transformed, the augmented message may be queued for transmission to the mobile device when the device
next connects to the SUP server, or the message may be sent to the device directly. These messages are stored in the
device’s in-box where they await the us er’s actions. When a user reviews an in-box message, the appropriate form is
loaded by the workflow application, and the user may perform application-provided actions (such as approving an
expense request).
The device user’s responses are sent back to the messaging s erver. Depending on the application, the response
action may be queued, or may result in a synchronous action; this behavior is different from outbound message
transformations, which are always queued. Regardless of whether the response action is queued or performed
immediately, the application communicates with the SUP server to perform the action’s unit of work.
Mobile Synchronization Applications
Synchronization applications provide transactional consistency between the mobile device, the middleware and
the back-end system. These custom applications are designed and built to suit specific business scenarios from
the ground up or could start with a bespoke application and adapted with a large degree of customization. Several
application requirements must be considered to determine the best set of SUP technologies to employ with the
associated sizing. Application designs that fail to take these criteria into account may have challenges meeting their
key performance indicators (KPI).
Cache Synchronization Deployment
Cache synchronization allows mapping mobile data and service objects to SAP Remote Function Calls (RFCs) using
Java Connector (JCO) and to other non-SAP data sources such as databases and Web services. When SUP is used in
a stand-alone manner for data synchronization it utilizes an efficient bulk transfer and data insertion technologybetween the middleware cache and the device database known as replication-based synchronization (RBS).
2
Messaging Service SUP Data Service
Message Processor
Device Messaging
Device Inbox
Application(s)
EIS
ConsolidatedDatabase
Mobile Device Message Interceptor DCN Servlet
DCN ServletTransformerQueue
Transformer
Response Processor
ResponseQueue
Responder
DB
MMS
DS
JMSHost
J M
S B r i d g e
8/13/2019 SUP 2.0 Sizing Guide WP
http://slidepdf.com/reader/full/sup-20-sizing-guide-wp 5/12
3
In a stand-alone deployment the mobile application is designed such that the developer specifies how to load data
from the back-end into the cache and then filters and downloads cache data using device supplied parameters. The
mobile content model and the mapping to the back-end are directly integrated.
This style of coupling between device and back-end queries implies that the back-end must be able to respond to
requests from the middleware based on user supplied parameters and serve up mobile data appropriately. Normally,
some mobile-specific adaptation is required within SAP Business Application Programming Interfaces (BAPI).
Because of the direct nature of application parameter mapping and RBS protocol efficiencies, cache synchronization
deployment is ideal:
• with large payloads to devices (may be due to mostly disconnected scenarios)
• where ad hoc data downloads might be expected
• for SAP or non-SAP back-ends
Large payloads, for example, can occur in task worker (service) applications that must access large product catalogs
or where service occurs in remote locations and workers might synchronize once a day. While RBS synchronization
benefits from middleware caching, direct coupling requires the back-end to support an adaptation where mobile user
data can be determined.
Cache Synchronization Architecture
The goal of synchronization is to keep views (i.e. the state) of data consistent between multiple tiers essentially
using bi-directional synchronization. The assumption is that if data changes on one tier (e.g. the enterprise system-
of-record) that all other tiers interested in that data (mobile devices, intermediate staging areas/caches and so on) will
eventually be synchronized to have the same data/state on that system.
The SUP server keeps data synchronized between the device and the back-end by maintaining records of device
synchronization activity in its consolidated database along with any cached data that may have been retrieved from
the back-end or pushed from the device. The SUP server employs several components in the synchronization chain.
• The Relay Server is a single point of contact for devices and is a specialized reverse proxy that avoids opening
inbound ports in the firewall to the SUP server. The outbound enabler opens a bidirectional communicationchannel from inside the firewall outward to the Relay Server.
• Mobile Channel Interfaces provide a conduit for data both from and to remote devices. These conduits vary based
on their approach (synchronous, asynchronous) and quality of services (proprietary or standards based)
– The Messaging Channel serves as the abstraction to all device-side notifications (BES, APNS and others) so that
when changes to back-end data occur devices can be notified of their changes
– The Replication Channel serves as the conduit over which data is replicated between device and the mobile
middleware. This is an efficient database row replication technology.
• Mobile Middleware Services (MMS) role is to arbitrate and manage communications between device requests
from the mobile channel interfaces in the form that is suitable for transformation to a common MBO service
request and a canonical form of enterprise data.
• Data Services (DS) is the conduit to enterprise data and operations within the f irewall or hosted in the cloud.
8/13/2019 SUP 2.0 Sizing Guide WP
http://slidepdf.com/reader/full/sup-20-sizing-guide-wp 6/12
4
Figure 2. Cache Synchronization Architecture
Once a mobile application model is designed it can be deployed to the SUP server where it operates as part of a
specialized container managed application interfacing with the MMS and DS components. Cache data and messages
are persisted in the databases in the data tier. Changes made on the device are passed to the MMS component and
replayed against the DS interfaces with the back-end. Data that changes on the back-end is replicated to the devicedatabase. The Unified Agent Service acts as a central control and monitoring facility for the server.
The SUP/DOE option is currently only available with the SAP CRM application or other custom applications
written by Sybase or SAP and is not reflected in this document. Please refer to the specific application sizing
guides for further guidance on SUP/DOE.
SIZING FUNDAMENTALS AND TERMINOLOGY
For the purpose of this guide, we assume that you are familiar with sizing fundamentals. You can find more
information at http://service.sap.com/sizing –> Sizing –> General Sizing Procedures.
This section explains the most important sizing terms, as these terms are used extensively in this document.
Sizing
Sizing means determining the hardware requirements of an SAP application, such as the network bandwidth,
physical memory, CPU processing power and I/O capacity. The size of the hardware and database is influenced by both
business aspects and technological aspects. The number of users using the various application components and the
data load they put on the server must be taken into account.
Cluster DB
User Agent DB
AdvantageMessaging DB
MBS Client
Application(s)
Mobile Devices
SUP Data Tier(Active/Passive HA)
Public Network DMZ Private Network
UltraLite
RBS Client
UltraLite
Relay
Servers
LDAP Server
Unwired Server (Clustered)
Enterprise Information Systems
Outbound Queue
Inbound Queue
Messaging Channel Container Services
Replication Channel
Unified Agent Service
MobiLink
SybaseControl Center
JMSHost
M o b i l e M i d d l e w a r e
S e r v i c e s
D a t a S e r v i c e s
DataChange
Notification
ConnectionPools
JAAS
ConsolidatedDatabase
SAP Applications
Databases
SOAP/REST
Services
UnwiredWorkspace
L o a d B a l a n c e r
R e l a y
S e r v e r
O u t b o u n
d E n a b l e r
R e l a y S e r v e r
O u t b o u n d E n a b l e r
R e l a y S e r v e r
O u t b o u n d E n a b l e r
8/13/2019 SUP 2.0 Sizing Guide WP
http://slidepdf.com/reader/full/sup-20-sizing-guide-wp 7/12
5
Benchmarking
Sizing information can be determined using SAP Standard Application Benchmarks and scalability tests
(www.sap.com/benchmark). Released for technology partners, benchmarks provide basic sizing recommendations
to customers by placing a substantial load upon a system during the testing of new hardware, system software
components and relational database management systems (RDBMS). All performance data relevant to the system,
user and business applications are monitored during a benchmark run and can be used to compare platforms.
SAP Application Performance Standard
The SAP Application Performance Standard (SAPS) is a hardware-independent unit that describes the performance
of a system configuration in the SAP environment. It is derived from the Sales and Distribution (SD) Benchmark, where
100 SAPS is defined as the computing power to handle 2,000 fully business processed order line items per hour. (For
more information about SAPS, see www.sap.com/benchmark –> SAPS).
Initial Sizing
Initial sizing refers to the sizing approach that provides statements about platform-independent requirements of
the hardware resources necessary for representative, standard delivery SAP applications. The initial sizing guidelines
assume optimal system parameter settings, standard business scenarios, and so on.
Expert Sizing
This term refers to a sizing exercise where customer-specific data is analyzed and used to put more detail on the
sizing result. The main objective is to determine the resource consumption of customized content and applications
(not SAP standard delivery) by comprehensive measurements. For more information, see http://service.sap.com/sizing
–> Sizing Guidelines –> General Sizing Procedures –> Expert Sizing.
Configuration and System Landscaping
Hardware resource and optimal system configuration greatly depend on the requirements of the customer-specific
project. Considerations include the implementation of distribution, security, and high availability solutions by different
approaches using various third-party tools. In the case of high availability through redundant resources, for example,
the final resource requirements must be adjusted accordingly.
Some best practices may be valid for a specific combination of operating system and database. To provide guidance,
SAP created the SAP NetWeaver® configuration guides (http://service.sap.com/instguides –> SAP NetWeaver).
INITIAL SIZING FOR WORKFLOW APPLICATIONS
Assumptions
The Hybrid Workflow Container is suitable for simple, small payload scenarios. You will need to remap workflow
scenarios that exceed these characteristics to native custom applications.
Planners should determine the specific application demand on the server(s) to properly estimate the sizing for
workflow. These factors affect the sizing calculations for workflow:
• Total user population that are assigned workflows
• Rate at which workflows are executed (number of application requests per hour)
• Latency of operations executed in the middleware (on-line, cached MBOs and back-end)
• Size of the data sent between the server and the device
The combination of these factors reflects the application load on the server based on the rate of messages. When
comparing your deployment to the business scenarios presented in this paper, your deployment should be adjusted
based on variances in these factors.
8/13/2019 SUP 2.0 Sizing Guide WP
http://slidepdf.com/reader/full/sup-20-sizing-guide-wp 8/12
6
Business Scenario
The business example for the workflow application is a simple application to approve sales orders. A back-end
process starts with a push from the back-end workflow system to SUP via a data change notification. This notification
signals the start of a mobile workflow and is sent through SUP to the specific device/user registered for this
workflow. The device responds by changing the approved field to indicate the status and an asynchronous action is
passed on to the back-end and the workflow is implicitly terminated. The total messages for this workflow scenario
are two per complete workflow — initialization and response/termination. The workflow response rate is one
workflow per hour per user.
Data Object Structure
To trigger the mobile workflow, a message must be sent form
the back-end to the SUP server and routed to the device. The single
dimensional object used in the message in this case is a simple
approval object without any further references. The payload size in
this scenario is 50Kb per workflow message.
Key Considerations for the Sizing AnalysisWithin any workflow at least two messages are involved, one from
the back-end and a response from the device. Extra on-line invocations to the mobile middleware may occur during
the workflow but are not accounted for in this sizing. Larger payloads will increase the time to move and marshal
data throughout the system (small payloads are recommended).
Table 1 Workflow Reference Sizing reflects a push f rom the back-end and a response from the device. Care should be
taken to account for on-line interactions from the device within the context of the workflow (if the application allows
for that pattern).
CATEGORY WORKFLOWSPER HOUR
SIZING
SERVER SAPS MEMORY IN GB DATA TIER SAPS DATA TIER
MEMORY IN GB
Small 1,000 500 4 350 4
Medium 5,000 2,500 4 1,750 4
Large 10,000 5,000 8 3,500 8
Very large 20,000 10,000 8 7,000 8
Table 1. Workflow Reference Sizing
The number of registered users in the system has a relatively minor impact on sizing or performance (roughly 2
percent degradation in throughput for 10,000 users as measured on the same hardware).
INITIAL SIZING FOR CACHE APPLICATIONS
Assumptions
Business Scenario
This business scenario uses a service order management application that allows customers to place service-
order requests in the back office of a s ervice company. The requests are stored in a back-end system, along with
information such as the customer’s address, contact information, details of the product to be serviced, and so on.
After the customer places a request, the appropriate field representative receives the order request.
Data Object Structure
For the sizing measurements, each order request contains one header record and ten item records. The header
record corresponds to one order request (User ID, Order type and so on), and the ten items correspond to three order
activities, two object lists and five components. So, each instance of the order data object corresponds to 11 rows in
the database.
8/13/2019 SUP 2.0 Sizing Guide WP
http://slidepdf.com/reader/full/sup-20-sizing-guide-wp 9/12
7
The customer data in this sizing example contains one header record and three items. The header record
corresponds to customer details, and the three items correspond to three contact details. So, each instance of the
customer data object corresponds to four rows in the database.
In our scenario, order requests in the back-end system can be newly created, deleted or changed. In other terms, the
instances can be inserted, deleted or modified in the back-end database.
Data is exchanged between the client devices and the back-end in the form of messages. Each message contains
the changes in the instance, message type (insert, delete, modified) and other details. The data used in this sizing
example had the follow change characteristics during the performance runs:
• For each insert message, one header record and its ten item records were created.
• For each delete message, one header record and its ten item records were deleted.
• For each modified message, one header record and two item records were changed, namely one activity record
and one object list.
•
•
••
•
•
•
Figure 3. Synchronization Reference Model
Key Considerations for the Sizing Analysis
Two key processes influence the resource consumption in this architecture scenario. Both the data change
notification (DCN) and the synchronization are considered to be integral parts of the same scenario where a balance
of changes from the back-side is applied along with device-side changes.
1. Initial Download
This phase is considered to be an administrative roll-out phase accomplished prior to normal operation so the sizing
numbers for that phase are not reflected in this guide.
2. DCN
During this phase DCNs are sent from the back-end to the cache and the payload of the change is also sent in the
same message. As the DCN arrives in the cache the SUP server determines the difference between that change
notification and what is already in the cache and applies the differences to the cache. The sizing for this phase is
reflected in Table 3. Synchronization Cache Data Change Notification Sizing.
8/13/2019 SUP 2.0 Sizing Guide WP
http://slidepdf.com/reader/full/sup-20-sizing-guide-wp 10/12
8
3. Client Synchronization
There are two synchronization stages where the client initiates synchronization. First uploading any changes
they have made to the sales orders and line items, and applying those changes to the back-end, and second
downloading subsequent changes. The sizing for these two stages is calculated and described separately because
the sizes are usually quite different. The processing in our disconnected scenario is calculated during two distinct
times — during the morning when back-end changes are retrieved from the server and in the evening when
devices changes are uploaded. The sizing for the download is described in Table 4 while the upload phase is
reflected in Table 5.
SUP 2.0 architecture provides for device uploads and transactions to the back-end in the same synchronization
cycle as downloads (this behavior will be changed in future releases). In this scenario no server-side notifications
are sent; all clients synchronize when the user is ready.
Because the disconnected scenario calls for DCN (night), delta download (morning), and delta upload (evening)
to occur at mutually exclusive periods of time, the higher of the sizing requirements can be used for deployment.
In a case where DCN and synchronization occur during the same period (as in a mostly connected scenario) the
sizing should account for the higher of the upload/download synchronization sizing (since upload and download are
executed as a single transaction in this version) plus the adjustment for additional concurrent DCN activity.
The following information describes the payload and number of objects associated with the payload for each
process phase. The T-Shirt sizing for DCN and the two synchronization phases follow.
PHASE TOTAL PAYLOADTRANSFER
INSERT OBJECTS DELETE OBJECTS MODIFIED OBJECTS
Initial load (Rolloutphase not reflected insizing)
31 Mb 4,400 N/A N/A
DCN (back officeprocessing)and downloadsynchronization
2.3 Mb 160 160 80
Uploadsynchronization(End of day sync)
1.4 Mb N/A N/A 200
Table 2. Stand-alone Per Device Data Characteristics
DCN metrics in Table 3 depict the total DCN activity to upload the entire delta payload to a client. The DCN actual
activity used to push the delta payload to a client is broken down into 400 distinct operations. While a single DCN
could push the entire payload it may prove to be more efficient to provide finer grained operations to improve
concurrency.
CATEGORY DCN ACTIVITYCLIENT PAYLOADS
PER HOUR
SIZING
SERVER SAPS MEMORY IN GB DATA TIER SAPS DATA TIERMEMORY
Small 300 2,500 4 3,750 4
Medium 500 4,000 8 6,250 8
Large 1,000 8,250 16 12,500 16
Very large 2,000 16,250 16 27,750 16
Table 3. Synchronization Cache Data Change Notification Sizing
8/13/2019 SUP 2.0 Sizing Guide WP
http://slidepdf.com/reader/full/sup-20-sizing-guide-wp 11/12
9
CATEGORY DOWNLOADSYNCHRONIZATIONSPER HOUR
SIZING
SERVER SAPS MEMORY IN GB DATA TIER SAPS DATA TIERMEMORY
Small 1,000 250 4 1,500 4
Medium 2,000 500 8 3,000 8
Large 3,000 1000 8 4,500 8
Very large 5,000 1,500 16 7,500 16
Table 4. Synchronization Cache Download Delta Synchronizations
CATEGORY UPLOADSYNCHRONIZATIONSPER HOUR
SIZING
SERVER SAPS MEMORY IN GB DATA TIER SAPS DATA TIERMEMORY
Small 1,000 3,250 4 4,500 4
Medium 2,000 6,250 8 8,750 8
Large 3,000 9,500 8 13,000 8
Very large 5,000 16,000 16 21,750 16
Table 5. Synchronization Cache Upload Change Synchronizations
APPENDIX
Deployment Options
For small or medium-sized deployments it may make economic sense to host all of the SUP components on the
same physical hardware. When high availability is required a Microsoft cluster and some form of highly available
storage tier can be employed to allow for failover. This configuration works as an active/passive cluster where only one
of the nodes is active at one time. Both nodes should be identically sized to take over the entire work stream.
Figure 4. Active/Passive Cluster
Storage TierNAS or SAN
DMZWeb App Zone
Default DB
Messaging DB
Tx Log
Monitoring DB
3 U
3 U
3 U
3 U
12 U
SUP Node 1
Active
Passive
MS Cluster
RSOE
....
SUP Node 2
RSOE
....
Relay ServerFarm
(HA)
LoadBalancers
8/13/2019 SUP 2.0 Sizing Guide WP
http://slidepdf.com/reader/full/sup-20-sizing-guide-wp 12/12
www.sybase.com
Sybase, Inc.
Worldwide Headquarters
One Sybase Drive
Dublin, CA 94568-7902
U.S.A
1 800 8 sybase
Copyright © 2011 Sybase, Inc. All rights reserved. Unpublished rights reserved under U.S. copyright laws. Sybase andthe Sybase logo are trademarks of Sybase, Inc. or its subsidiaries. ® indicates registration in the United States ofAmerica. SAP, the SAP logo and SAP NetWeaver are the trademarks or registered trademarks of SAP AG in Germanyand in several other countries. All other trademarks are the property of their respective owners. 08/11
In larger deployments some advantage can be gained by breaking out the data tier from the SUP tier and sizing
each separately. This configuration may allow for sizing each tier independently, which makes the most of smaller,
less expensive, hardware on the tier. In these more demanding cases it is necessary to vertically scale the database
tier (use more powerful hardware) and horizontally scale (add more hardware) in the tier. Normally two active
nodes provide sufficient processing power to fully meet the database physical I/O limits on the data tier. In hosted
environments or larger deployments the SUP tier can be virtualized taking advantage of economies of s cale. Failures
on a single node can be managed by spreading the load across more than one other virtualized server so that each
node is not required to be completely capable of assuming the full cluster load.
Figure 5. Active/Active Cluster
Physical I/O Subsystems
All the current SUP application types are heavily reliant on one or more forms of persistence in the middle tier. This fact
implies that the scalability of the server is a direct reflection of the properties of the physical storage infrastructure.
Two main physical data storage systems (the Advantage Database Service for messaging and the Consolidated
Database) are on SUP and one (Consolidated Data Store) in DOE. To increase the throughput on the storage subsystems
separate all three physical I/O contenders and their associate logs onto separate disk spindles or RAID systems.
Faster storage (i.e., SSD) can dramatically improve the performance of the SUP cluster beyond the quoted metrics
(potentially by as much as 50 percent or more). If SSDs are used it is important to use a compatible operating system
that provides SSD TRIM support, which as of the date of this publication is Windows Server 2008 R2. Follow vendor
recommendations for disabling disk defragmentation and other forms of dis k caching for optimal SSD performance
and life.
Network Latency
All the reference numbers are for LAN-based device communication. 3G or Wi-Fi networks have different response
times and should be taken into account when considering individual download speeds. Application-specific testing is
required to adequately test performance.
FEEDBACK
Send any feedback on this document to [email protected].
Internal Network DMZWeb App Zone(SUP Cluster)
SUP Node 1
Primary Server
Monitor Server
Secondary Server
RSOE
....
SUP Node 2
RSOE
....
Relay ServerFarm(HA)
Load
Balancers
SUP Data TierCDB/Messaging Cluster