Private Atom Cloud Operations 101. 2 Confidential Worldwide Technical Training Agenda Introduction...

Private Atom Cloud Operations 101

2 Confidential Worldwide Technical Training

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


Introduction

AtomSphere Overview


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


Graphical integration workflow modeling

6 Dell - Internal Use - Confidential

Build > Deploy > Manage

Deploy

Deploy your Atoms to the AtomSphere for SaaS, PaaS, or cloud integration or safely behind your firewall for on-premises applications

Hosted

Download

2 Manage

Monitor and maintain the status of all your deployed Atoms, integration processes and trading partners, regardless of location, using a feature-rich web-based dashboard

3Build

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

1


Platform

Application integration

SOA framework

• Enable SOA

• Real-time

• Event-based

• connect.boomi.com

- Cloud web service

ETL

• Parallel processing

• Bulk fast load

• Join from multiple sources

• Change Data Capture (CDC)

Boomi molecule• Load balancing• High availability• Disaster recovery

Environments• Seamless promotion

between development/QA/production

Advanced user security

Business rule engine• Perform complex multi-

step validation and business logic

EDI/B2B

• Trading partner management

• EDI data mapping

• Trading partner enablement

• Library of EDI document standards

API management

Integration Master data

Master data management

• Multi-domain

• Bi-directional

• Real-time

• Multi-department, multi-application

Data quality

• Loqate

• SDK for provider of choice

All integration use cases solved on an integrated enterprise-grade platform


Introduction

What is a Private Atom Cloud?


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


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


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


Private Cloud Architecture


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)


Private Cloud Molecule

Partn

er In

frastru

cture

Deployment Architecture

128-bit encryption(metadata only)

Data

Public In

tern

et

External firewall

Dell Boomi Platform

App Server 1w/ Node 1

Other Cloud Apps

App Server 2w/ Node 2

App Server Nw/ Node N

Multicast/

Unicast

Multicast/Unicast

NFS NFSClustered NAS / SAN Shared Storage

Molecule config, data, history

NFS


Understanding Forked Process Execution

Node 1 App Server

Node JVM

Heap Thread

Forked JVM

Heap Thread

Forked JVM

Heap Thread

Process Execution

Process Execution


Private Cloud Molecule

Partn

er In

frastru

cture

Publishing Web ServicesPublic In

tern

et

External firewall

App Server 1https://192.168.1.1:9093

App Server 2https://192.168.1.2:9093

App Server Nhttps://192.168.1.3:9093

Embedded web server

Load balancer/ reverse proxy

Inbound web service requests

https://connect.yourcloud.com


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


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”)


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 disk-level 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


Planning Your Cloud


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”


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)


Installing and Configuring Your Cloud


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).


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


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”


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


Managing Your Cloud

Monitoring


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


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


Managing Your Cloud

Backup and Disaster Recovery


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– 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.


Managing Your Cloud

Sizing and Capacity Management


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.


Recommended Minimum Initial Configurations for Production CloudNode/Server Specs

• # Nodes: 2-3

• Node Servers– CPU: 4-8– RAM: 4-8Gb– Disk: 50-100Gb (for temp)– OS: 64 bit

• Shared file system disk: 200-500Gb

Application Config

• Node JVM: 1Gb

• Forked Execution JVM: 512Mb-1Gb

• 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


The Building Blocks - Scarce resources present the challenge

Hard Disk

Memory

CPU

Computer

Node JVM

Heap

Forked JVM

Heap

Forked JVM

Heap


Options for Increasing Processing Capacity


Option 1 – Increase Forked JVM Heap Size

Hard Disk

Memory

CPU

Computer

Node JVM

Heap

Forked JVM

Heap

Forked JVM

Heap

• More working memory per execution JVM


Option 2 – Increase Computer (CPU, Memory, Hard Disk)• More CPU = More simultaneous executions

• More Memory/Hard Disk = More data at the same time

Hard Disk

Memory

CPU

Computer

Node JVMHea

p

Forked JVM

Heap

Forked JVM

Heap

CPU


Option 3 – Increase Number of Computers (Nodes)• Increased resources and reduced contention. Also increases

JVMs.

Hard Disk

Memory

CPU

Computer

Node JVM

Heap

Forked JVM

Heap

Forked JVM

Heap


Processing Scenarios


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)


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)


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)


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


Questions?


Thank you!


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?


Definition of key terms

• “Process” – A AtomSphere integration process

• “Execution” – An instance of a Process running on an Atom, single-threaded

• “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


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


Representative Enterprise Integration strategy leveraging Dell Boomi

Portals, mobility and “internet of things”

EDI B2B

On premises applications and data silos

Cloud services

• Single instance multitenant PaaS

• Elastic runtime scalability

• Centralized development

• Crowd-sourced mapping, transformation and regression testing

• Crowd-sourced multi-domain

modeling

• Predictive Assistance

• Integration life-cycle management

• Global monitoring and management

• Administration

• Platform APIZ

• API management

• Data governance

• Data quality

Provider and consumer layer

Web service publishing SOAP & REST

Certified AS2 client & listener

Open standard JMSclient & listener

Native applicationconnectors

Standards based technology connectors

Trading partner management

Business process layer

Exception Handling

Business rules engine

Cleanse/enrichOrchestration

TranslationService

composition

Dell BoomiPlatform

AtomSphere®

IntegrationAPI management

MDMMaster data management

Canonical modeling

Message brokering</>


Option 1 – Increase JVM Heap Size

• More working memory for a single JVM

Hard Disk

Memory

CPU

Computer

JVM

Heap

Thread


Option 3 – Increase Threads (Parallel Processing)• More tasks happening simultaneously

Hard Disk

Memory

CPU

Computer

JVM

Heap

Thread

Thread

Thread


Option 4 – Increase JVMs (Forked Executions)• More working memory and threads across multiple JVMs

• Less contention for GC

Hard Disk

Memory

CPU

Computer

Node JVM

Heap

Forked JVM

Heap

Forked JVM

Heap

Thread

Thread Thread


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.

PatentsThis 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.

http://software.dell.com/

Private Atom Cloud Operations 101. 2 Confidential Worldwide Technical Training Agenda Introduction...

Documents

Transcript of Private Atom Cloud Operations 101. 2 Confidential Worldwide Technical Training Agenda Introduction...