Atom and Molecule Sizing Considerations

Private Atom Cloud Operations 101
Agenda
• Introduction
– AtomSphere Overview
– What is a Private Atom Cloud?
• Private Cloud Architecture
• Planning Your Cloud
• Installing and Configuring Your Cloud
• Managing Your Cloud
– Monitoring
– Backup and Disaster Recovery
– Sizing and Capacity Management
2
Confidential
Worldwide Technical Training
Introduction
AtomSphere Overview
3
Confidential
Worldwide Technical Training
What is AtomSphere?
• Cloud-based data and application integration-as-a-service platform
• Graphical integration development environment
• Develop and manage integration processes from a single web-based
console
• Deploy and run integrations anywhere: cloud or on-premises
• Single instance, multi-tenant platform
4
Confidential
Worldwide Technical Training
Graphical integration workflow modeling
5
Confidential
Worldwide Technical Training
Build > Deploy > Manage
1
Build
Using the AtomSphere
library of connectors and
maps, visually design
your integration
processes and load them
into a lightweight,
dynamic run-time engine
called an “Atom” for
execution
2
Deploy
Deploy your Atoms to the
AtomSphere for SaaS,
PaaS, or cloud
integration or safely
behind your firewall for
on-premises applications
Hosted
Download
6
Dell - Internal Use - Confidential
3
Manage
Monitor and maintain the
status of all your
deployed Atoms,
integration processes
and trading partners,
regardless of location,
using a feature-rich webbased dashboard
All integration use cases solved on an integrated
enterprise-grade platform
Integration
Application
integration
ETL
SOA framework
• Parallel processing
• Enable SOA
• Bulk fast load
• Real-time
• Join from multiple
sources
• Event-based
• connect.boomi.com
• Change Data
Capture (CDC)
- Cloud web service
Master data
EDI/B2B
• Trading partner
management
• EDI data mapping
• Trading partner
enablement
• Library of EDI
document
standards
Master data
management
Data quality
• Multi-domain
• Loqate
• Bi-directional
• SDK for provider of
choice
• Real-time
• Multi-department,
multi-application
API management
Platform
Boomi molecule
Environments
Business rule engine
• Load balancing
• High availability
• Disaster recovery
• Seamless promotion
between development/
QA/production
• Perform complex multi-step
validation and business logic
Advanced user security
7
Dell - Internal Use - Confidential
Introduction
What is a Private Atom
Cloud?
8
Confidential
Worldwide Technical Training
Private Cloud – The Big Idea
• Private clouds allow partners to provide a hosted integration runtime
engine for their customers
• Single, shared engine that all customers will use
• Clustered for high availability and scalability
• Partner provides, monitors, and manages infrastructure to support
runtime engine
9
Confidential
Worldwide Technical Training
Private Cloud – Why?
• Partners can configure resources, quotas, and governance rules to
best fit customer requirements
• Process and retain customer data within partner’s control/infrastructure
(policy compliance, contractual agreements, SLA)
• Single, shared runtime engine is easier to manage and support vs.
separate engines for each customer
• More efficient use of infrastructure resources
10
Confidential
Worldwide Technical Training
Private Cloud – Strategy and Limitations
• Provide sufficient, available general purpose integration processing
capacity in response to demands
– Must monitor and trend infrastructure and application usage to keep up with
demand
– Not dynamically elastic, nodes do not automatically provision
• Configurable quotas & governance limits protect quality of service and
prevent individual tenants from monopolizing the cloud
• Shared runtime environment – “one size fits most”
– Customers with exceptional processing demands/requirements may still
require separate runtimes (either hosted by partner or installed on-premises
by the customer)
• Note: Your cloud will NOT be an option for customers that must
integrate with resources within their local network
• No limit to number of accounts or processes; just need to scale
capacity to meet demand
11
Confidential
Worldwide Technical Training
Private Cloud
Architecture
12
Confidential
Worldwide Technical Training
Terminology
• Atom – Single-tenant, single-node (non-clustered) runtime engine
• Molecule – Single-tenant, multiple-node (clustered) runtime engine
• Cloud – Multiple-tenant, multiple-node (clustered) runtime engine
• Process – An AtomSphere integration workflow
• Execution – An instance of a Process running on a runtime engine
• JVM – A single operating system Java process
• Node – A single JVM running as part of a molecule/cloud cluster
• Forked Execution – Each process execution runs in its own, temporary
JVM
• SOA Worker – Persistent JVM for short-lived real time processes (e.g.
web services)
13
Confidential
Worldwide Technical Training
Deployment Architecture
128-bit encryption
(metadata only)
Public Internet
Dell Boomi
Platform
Other
Cloud
Apps
Data
External firewall
Private Cloud Molecule
App Server 1
w/ Node 1
NFS
Multicast/
Unicast
App Server 2
w/ Node 2
NFS
Clustered NAS / SAN Shared Storage
Molecule config, data, history
14
Dell - Internal Use - Confidential
App Server N
w/ Node N
NFS
Partner Infrastructure
Multicast/
Unicast
Understanding Forked Process Execution
Node 1 App Server
Node JVM
Heap
Thread
Process
Execution
Process
Execution
Forked JVM
Heap
15
Confidential
Thread
Forked JVM
Heap
Thread
Worldwide Technical Training
Publishing Web Services
Public Internet
Inbound web
service requests
https://connect.yourcloud.com
External firewall
Load balancer/
reverse proxy
Partner Infrastructure
Private Cloud Molecule
Embedded
web server
App Server 1
https://192.168.1.1:9093
16
Dell - Internal Use - Confidential
App Server 2
https://192.168.1.2:9093
App Server N
https://192.168.1.3:9093
General Behavior Observations
• Forked Executions
– Prevent a single rogue process from monopolizing resources and
compromising the entire cloud
– Every process execution spins up new forked execution JVM. Note some
latency experienced.
• SOA Workers
– SOA Workers avoid forked execution latency for low-response-time
requests by establishing a persistent JVM per account dedicated to
handling web services requests. The SOA Worker JVMs are distributed
across the cluster.
• Load Balancing
– For scheduled/manual executions, the cluster uses internal algorithms to
run execution on least busy node
– For real time/web services requests, an external load balancer distributes
requests across the cluster according to node availability and any
configurable rules
17
Confidential
Worldwide Technical Training
General Behavior Observations (cont.)
• Clustering
– Cluster elects one node as “head” node (typically just the first node service
started)
– Head node responsible for distributing scheduled executions and
communicating with AtomSphere platform
– Unresponsive nodes are automatically removed from the cluster
– If head node goes down, the cluster automatically elects a new head node
• Account Attachments
– Accounts are not assigned to specific nodes – any process from any
account can run on any node
– Accounts can attach to the same cloud multiple times to be associated with
multiple environments (e.g. “Accounting Production” and “Human
Resources Production”)
18
Confidential
Worldwide Technical Training
Cloud and Tenant Security
• Each tenant’s processes are confined to their account directories within
the molecule share; can’t see or modify other tenants’ data or
configuration
• Configurable policy files restrict JVM access to local server and
network resources
• Persisted data is not encrypted by the application; recommend disklevel encryption if required
• Communication with AtomSphere platform is SSL encrypted
• Enable user authentication for web services publishing
• Only expose HTTPS ports for web services publishing; configure web
server with SSL cert
• Can disable custom scripting and/or custom connector development
• Basic server access control to node and shared file system resources
19
Confidential
Worldwide Technical Training
Planning Your Cloud
20
Confidential
Worldwide Technical Training
System Prerequisites (Highlights)
• Nodes
– Servers can be physical or virtual
– Same OS and architecture (Linux vs. Windows, 32-bit vs. 64-bit)
• Java
– Oracle JDK 6 or 7 (Oracle distribution only; not JRE)
– For Linux: no symlinks, Java must be pre-installed
• Shared file system
– Mount/path location to share must be same across nodes
– Must support file locking (e.g. NFS with NLM support)
• Network
– Recommend using Multicast for inter-node cluster communication if
configured in network
• For full list see Reference Guide, “Atom Cloud System Requirements”
21
Confidential
Worldwide Technical Training
Additional Considerations
• Production vs. Test Cloud
– Consider providing separate clouds designated as “production” vs. “test” –
connection licensing, different SLAs
• Publishing web services
–
–
–
–
Load balancing outside private cloud
Firewall rules to allow inbound traffic
“Friendly” DNS entry (e.g. “connect.yourcloud.com”)
Enable SOA Workers
• Monitoring and Alerting (more later)
• Backup/Disaster Recovery (more later)
22
Confidential
Worldwide Technical Training
Installing and
Configuring Your Cloud
23
Confidential
Worldwide Technical Training
General Installation Steps
1. Create new logical cloud via AtomSphere UI (designate as
Production or Test – cannot change later).
2. Download cloud molecule installer.
3. Execute molecule installer from first node (arbitrary) to create
molecule share and node service (associate with new logical cloud,
point to common file share location).
4. On each additional node, execute node service install script from
molecule share.
5. Start node service on each node.
6. Share new cloud with customer accounts via Account Groups
(AtomSphere UI).
24
Confidential
Worldwide Technical Training
Common Global Runtime Configurations
• General Performance
– Working Data Local Storage Directory – Nodes should use local
directory on app server for temp files instead of traversing network to
shared file system
– Max Forked Execution Time in Cloud – Max time a given process
execution is allowed to run (e.g. 24 hours)
– Max Simultaneous Forked Executions per Node – Additional will be
queued. Related settings for max queued executions and queued execution
timeout
• Memory
– Node JVM size – Typically relatively low because does not actually
process data
– Forked execution JVM size – JVM that will actual process data. Consider
with # max forked executions above
25
Confidential
Worldwide Technical Training
Common Global Runtime Configurations
• Disk Storage
– Purge schedule – Max days for which container & process logs, temp
data, and document data will be retained
– Atom Data & Process Execution Directory Level – Number of nested
execution history directory levels to avoid exceeding max files per directory
allowed by OS; recommend setting to “2”
– Compress History after x Days – Days after which process logs and
document data will be compressed; recommend setting to “2”
26
Confidential
Worldwide Technical Training
Common Per-Account Quota Configurations
• Note: All will have a global default with the option to override per account. Can
be used to grant additional throughput to individual accounts.
• General Performance
– Account Concurrent Execution Limit – Max concurrent executions per
account
• Disk Storage
– Disk Space Monitoring – Max disk space a given account is allowed to
consume (prevents runaway processes) (optimistically high, intended for
exception cases)
• Web Services Publishing
– Enable/Max SOA Workers – Whether customer accounts can have SOA
Workers enabled and how many
– HTTP Request Rate – Max requests per second
– SOA Worker Max Running Executions – Max concurrent low latency
executions, additional will be queued
– SOA Worker Max Execution Time – Max processing time per low latency
execution
27
Confidential
Worldwide Technical Training
Managing Your Cloud
Monitoring
28
Confidential
Worldwide Technical Training
Monitoring Best Practices
• Server Utilization
– Basic infrastructure monitoring – Server availability, CPU utilization, disk
usage, RAM utilization, disk I/O wait, network throughput
– Metrics should be monitored for point-in-time anomalies and trends over
time
• Disk Storage
– Shared file server monitoring
– Per-account disk space monitoring quotas
• Node/Cluster Health
– Monitor node service executable
– Use JMX API to monitor JVM statistics for point-in-time anomalies and
trends for time
– General Java metrics (e.g. heap space, # threads, # open files)
– Boomi-specific (e.g. # current executions, # queued executions, # missing
schedules, out of memory)
– Monitor node views files for errors and recent updates from all expected
nodes
29
Confidential
Worldwide Technical Training
Monitoring Best Practices (cont.)
• General Application Health
– AtomSphere platform alerts for Cloud offline (via email or WS API) – Cloud
not communicating with AtomSphere platform
– Monitor node container logs for SEVERE entries
• General Process Execution
– “Heartbeat” integration processes: scheduled and real time processes to
verify processes are executing as expected
– Command line/services – “Rogue” forked execution OS processes contain
account and execution ID
• Web Services Publishing
– Cloud’s HTTP Server Log – Endpoints invoked, client IP, execution ID,
response time
– SOA Dashboard (UI) – Summary statistics, trends, # requests per endpoint
– Proxy/load balancer – Ping availability of nodes
30
Confidential
Worldwide Technical Training
Managing Your Cloud
Backup and Disaster
Recovery
31
Confidential
Worldwide Technical Training
Backup and Disaster Recovery Best Practices
• The molecule cluster itself provides “localized” high availability and
failover. Disaster Recovery refers to catastrophic, data-center level
outages.
• Recommendation is to mirror the single logical cloud molecule.
– DO NOT install a second logical “standby” cloud molecule and attempt to
reattach/redeploy processes.
• Replicate (real time or periodically):
– Shared file system – Mirror entire molecule directory to DR site (note: large
number of small files)
– Node application servers – Virtual machines make snapshots and rebuilds
easy. Note node servers contain no persistent data.
• Failover
32
– Ideally DR site is exact replica of production with respect to host names, IP
addresses, Java paths, file share mounts, etc.
– Failover is a manual procedure: 1) stop all production node services if still
running; 2) start DR node services. DO NOT run both at the same time.
– If publishing web services, be sure to failover firewall, DNS, and load
balancer routing as necessary.
Confidential
Worldwide Technical Training
Managing Your Cloud
Sizing and Capacity
Management
33
Confidential
Worldwide Technical Training
Sizing and Capacity Management Strategies
• Objective is to provide sufficient processing capacity to meet usage
demands while maintaining a satisfactory service level for everyone
• Actual usage monitoring and trending is critical. Processing capacity is
not linear with # accounts or processes
• Establish baselines and define acceptable thresholds to identify
anomalies and anticipate processing demands
• For customers with exceptional processing requirements (very large
files, very high volumes, narrow SLAs, etc.), need to evaluate
investment of hosting separate dedicated runtime vs. recommending
customer hosts itself.
34
Confidential
Worldwide Technical Training
Recommended Minimum Initial Configurations for Production
Cloud
Node/Server Specs
Application Config
• # Nodes: 2-3
• Node JVM: 1Gb
• Node Servers
• Forked Execution JVM: 512Mb1Gb
–
–
–
–
CPU: 4-8
RAM: 4-8Gb
Disk: 50-100Gb (for temp)
OS: 64 bit
• Shared file system disk: 200500Gb
• Purge schedule (max): 7-14 days
• Max Simultaneous Forked
Executions per Node: 3-7 (to be
considered with RAM & CPU)
Account Quotas
• Disk Usage: 50Gb
• Account Concurrent Execution
Limit: 5
35
Confidential
Worldwide Technical Training
The Building Blocks - Scarce resources present the challenge
Computer
Node JVM
CPU
Memory
Heap
Forked
JVM
Heap
Forked
JVM
Heap
Hard Disk
36
Confidential
Worldwide Technical Training
Options for Increasing
Processing Capacity
37
Confidential
Worldwide Technical Training
Option 1 – Increase Forked JVM Heap Size
• More working memory per execution JVM
Computer
Node JVM
CPU
Memory
Heap
Forked
JVM
Heap
Forked
JVM
Heap
Hard Disk
38
Confidential
Worldwide Technical Training
Option 2 – Increase Computer (CPU, Memory, Hard Disk)
• More CPU = More simultaneous executions
• More Memory/Hard Disk = More data at the same time
Computer
CPU
Node
JVM
CPU
Heap
Memory
Hard Disk
39
Confidential
Forked
JVM
Heap
Forked
JVM
Heap
Worldwide Technical Training
Option 3 – Increase Number of Computers (Nodes)
• Increased resources and reduced contention. Also increases JVMs.
Computer
Node JVM
CPU
Memory
Hard Disk
40
Confidential
Heap
Forked
JVM
Heap
Forked
JVM
Heap
Worldwide Technical Training
Processing Scenarios
41
Confidential
Worldwide Technical Training
Many simultaneous process executions
• Contended Resource: CPU
– Best: Increase number of computers (Option 3)
– Also good: Increase number of CPUs per computer (Option 2)
• Contended Resource: Memory/Heap
– Good: Increase Memory per computer (Option 2)
42
Confidential
Worldwide Technical Training
High volume of documents
• Contended Resource: Hard Disk
– Good: Increase Hard Disk (Option 2)
• Contended Resource: Memory/Heap
– Good: Increase Heap per JVM (Option 1)
– Also good: Increase Memory per computer (Option 2)
43
Confidential
Worldwide Technical Training
Very large documents
• Contended Resource: Memory/Heap
– Best: Increase Heap per JVM (Option 1)
– Also good: Increase Memory per computer, assuming more Heap per JVM
(Option 2)
• Contended Resource: Hard Disk
– Good: Increase Hard Disk (Option 2)
44
Confidential
Worldwide Technical Training
High volume of real-time requests
• Contended Resource: CPU
– Best: Use SOA Workers (persistent JVM for short-lived web services
requests) or even multiple SOA Workers for a given tenant
45
Confidential
Worldwide Technical Training
Questions?
46
Confidential
Worldwide Technical Training
Thank you!
47
Confidential
Worldwide Technical Training
There are many factors that go into runtime environment sizing
• Hardware Specifications
–
–
–
–
Memory?
CPUs?
Disk space?
Number of machines?
• Runtime Engine
– Single Atom vs. clustered Molecule?
– Normal or forked execution?
• Integration Design
– Use of subprocesses?
– Parallel processing (Flow Control)?
– Threads or [JVM] Processes?
48
Confidential
Worldwide Technical Training
Definition of key terms
• “Process” – A AtomSphere integration process
• “Execution” – An instance of a Process running on an Atom, singlethreaded
• “JVM” – A single operating system process (running Java)
• “Cluster” – One or more JVM's working together as a logical
molecule/cloud
• “Node” – A single molecule/cloud JVM running as part of a cluster
• “Computer” – A single computer, physical or virtual
• “Atom” – A single-tenant, single-node AtomSphere runtime engine
• “Molecule” – A single-tenant, multiple-node AtomSphere runtime engine
• “Cloud” – A multiple-tenant, multiple-node AtomSphere runtime engine
• “Forked Execution” – A separate, special-purpose JVM running a single
Process Execution
49
Confidential
Worldwide Technical Training
Definition of key terms (cont.)
• “CPU” – A processor in a computer (physical cores, not virtual i.e.
hyperthreading)
• “Memory” or “RAM” – The transient working memory available for the
CPU (typically MB or GB)
• “Hard Disk” or “Storage” – The persistent long term data storage
available on the computer (typically GB or TB)
• “Heap” – The transient working memory for a JVM (subset of Memory
which is owned/managed by a Java process)
• “GC” (Garbage Collection) – The algorithm used by Java to manage
the Heap usage, constantly running in the background
• “Thread” – An executing code path within a JVM
50
Confidential
Worldwide Technical Training
Representative Enterprise Integration
strategy leveraging Dell Boomi
Dell Boomi
Platform
Cloud services
AtomSphere®
Integration
On premises applications and data silos
API
management
MDM
Master data
management
• Single instance multitenant PaaS
• Global monitoring and management
• Elastic runtime scalability
• Administration
• Centralized development
• Platform APIZ
• Crowd-sourced mapping, transformation
and regression testing
• API management
• Crowd-sourced multi-domain modeling
• Data governance
• Data quality
• Predictive Assistance
• Integration life-cycle management
EDI B2B
Provider and consumer layer
Web service publishing
SOAP & REST
Business process layer
Message brokering
</>
Canonical modeling
Certified AS2
client & listener
Open standard JMS
client & listener
Portals, mobility and “internet of things”
Native application
connectors
Orchestration
Cleanse/enrich
Service composition
Translation
Business
rules engine
Exception Handling
Standards based
technology connectors
51
Dell - Internal Use - Confidential
Trading partner management
Option 1 – Increase JVM Heap Size
• More working memory for a single JVM
Computer
CPU
JVM
Memory
Heap
Hard Disk
Thread
52
Confidential
Worldwide Technical Training
Option 3 – Increase Threads (Parallel Processing)
• More tasks happening simultaneously
Computer
CPU
JVM
Heap
Memory
Thread
Thread
Thread
Hard Disk
53
Confidential
Worldwide Technical Training
Option 4 – Increase JVMs (Forked Executions)
• More working memory and threads across multiple JVMs
• Less contention for GC
Computer
Node JVM
CPU
Heap
Thread
Memory
Forked JVM
Hard Disk
54
Confidential
Heap
Thread
Forked JVM
Heap
Thread
Worldwide Technical Training
Copyrights and Trademarks
© 2015 Dell Inc.
ALL RIGHTS RESERVED.
This guide contains proprietary information protected by copyright. The software described in this guide is furnished under a software license or
nondisclosure agreement. This software may be used or copied only in accordance with the terms of the applicable agreement. No part of this
guide may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any
purpose other than the purchaser’s personal use without the written permission of Dell Inc.
The information in this document is provided in connection with Dell products. No license, express or implied, by estoppel or otherwise, to any
intellectual property right is granted by this document or in connection with the sale of Dell products. EXCEPT AS SET FORTH IN THE TERMS
AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, DELL ASSUMES NO LIABILITY WHATSOEVER
AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT
SHALL DELL BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING,
WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF
THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF DELL HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Dell
makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to
make changes to specifications and product descriptions at any time without notice. Dell does not make any commitment to update the information
contained in this document.
If you have any questions regarding your potential use of this material, contact:
Dell Inc.
Attn: LEGAL Dept
5 Polaris Way
Aliso Viejo, CA 92656
Refer to our web site (software.dell.com) for regional and international office information.
Patents
This product is protected by U.S. Patent # 8,533,661 and # 8,589,207. Additional Patents Pending.
Trademarks
Dell, the Dell logo, Dell Boomi, Dell Boomi AtomSphere, AtomSphere, Atom, and AtomShpere Integration Cloud are trademarks of Dell Inc. and/or
its affiliates. Other trademarks and trade names may be used in this document to refer to either the entities claiming the marks and names or their
products. Dell disclaims any proprietary interest in the marks and names of others.
55
Confidential
Worldwide Technical Training