2. About Me
• PMC member Apache Axis, Committer Synapse
& Web Services
• Member, Apache Software Foundation
• Co-author, Axis2 Web Services
• Director of Architecture, WSO2 Inc
• Blog: http://blog.afkham.org
• Twitter: afkham_azeez
2
3. Agenda
• A brief look at the WSO2 platform
• Carbon clustering for scalability & availability
• WSO2 Elastic Load Balancer
• Worker node & management node separation
• Deployment synchronization
• Logging
• Lazy loading
3
4. WSO2 Offerings
• WSO2 Carbon
• Full platform of servers for deployment on-premise, in private or public cloud
• Products share a consistent architecture and core platform services (e.g. logging,
management, security, identity, caching) through OSGi and the “Carbon Core”
• Includes ESB, AppServer, Data Services, Governance, Identity, Business Process,
and more
• WSO2 Stratos
• Platform-as-a-Service (PaaS) Foundation
• Supports running servers as elastic, metered, billed, multi-tenant with self-service
• Including all Carbon Servers, PHP, Jetty, and a growing list through a standard Cartridge
model
• WSO2 StratosLive
• http://stratoslive.wso2.com
• WSO2’s Public PaaS
• An instance of Stratos running in the cloud with all Carbon Servers available
4
5. Consistent Architecture
• Carbon: A consistent set of class-leading enterprise servers
• The same products run either on-premise or in the cloud, single-tenant or multi-
tenant
• Utilize the same Carbon core runtime for a seamless experience
• Stratos: A cloud platform for enterprise, hybrid and public deployment
• Extends the deployment to support full self-service, elastic scaling, metering and
billing
• Supports Carbon and native server runtimes
• Including Java and non-Java servers such as Jetty and PHP
• Re-uses the same core Carbon architecture to offer core PaaS services including:
• Identity, Logging, File, Relational Storage, Column Storage, Code Deployment, etc
• Both projects share a common set of OSGi modules and a core runtime
architecture
5
10. Dynamic membership
• No predefined members
• Nodes can join & leave
Dynamic group
M1 M2 N
Join
M3 M4
10
11. Hybrid membership
• Some predefined (well-known) members, and some
dynamic members
• Nodes can join & leave
• Membership revolves around the static members
Hybrid group
Dynamic members Static members N
Join (IP,
M5 M6 M1 M2 Port)
M7 M3 M4
11
13. Well-known Address (WKA) based
membership management
Hybrid group
Dynamic members Static members
M6
M5
WK1 N
WK2
Notify Join (IP,
Port)
M7 WK3 WK4
13
14. Multicast vs. WKA
Multicast WKA
All nodes should be in the same subnet Nodes can be in different networks
All nodes should be in the same multicast
domain No multicasting requirement
Multicasting should not be blocked
No fixed IP addresses or hosts required At least one well-known IP address or host
required
Failure of any member does not affect New members can join with some WKA
membership discovery nodes down, but not if all WKA nodes are
down
Does not work on IaaSs such as Amazon IaaS-friendly
EC2
Requires keepalived, elastic IPs or some
other mechanism for remapping IP
addresses of WK members in cases of
failure
14
15. Multicast vs. WKA – how to decide?
• Multicast
• Cluster is going to be setup in a network where
multicasting is allowed
• WKA
• Cloud based deployment
• Members are distributed across datacenters &
regions
• Multicasting blocked
15
16. Configuring Clustering
<parameter name="membershipScheme">multicast | wka</parameter>
Parameters related to multicast based membership discovery
<parameter name="mcastAddress">228.0.0.4</parameter>
<parameter name="mcastPort">45564</parameter>
<parameter name="mcastFrequency">500</parameter>
Parameters that describe the local member
<parameter name="domain">wso2.carbon.domain</parameter>
<parameter name="localMemberHost">127.0.0.1</parameter>
<parameter name="localMemberPort">4000</parameter>
<parameter name="properties">…
16
19. Elastic Load Balancer 2.0
• New sysadmin-friendly configuration language
• High performance PassThrough transport
• Tenant-aware load balancing
• Ability to dedicate clusters for tenants (private
jet mode)
• Improved auto-scaler
• Separate IaaS-aware Cloud controller takes care of
spawning new instances on different IaaSs
19
23. Private Jet mode
• Analogy
• Economy class
• no SLA management, only elasticity
• Business class
• elasticity plus SLA guarantees
• Private Jet
• Guaranteed isolated VMs or machines for a specific
tenant
• Still elastically scaled
27. Management & Worker Node Separation
• Proper separation of concerns - management nodes
specialize in management of the setup while worker nodes
specialize in serving requests to deployment artifacts
• Only management nodes are authorized to add new artifacts
into the system or make configuration changes
• Worker nodes can only deploy artifacts & read configuration
• Lower memory foot in the worker nodes because the
management console related OSGi bundles are not loaded
• Improved security - management nodes can be behind the
internal firewall & be exposed to clients running within the
organization only, while worker nodes can be exposed to
external clients.
27
28. Deployment Synchronization
• DepSync allows you to synchronize
deployment artifacts across nodes in a cluster
• Also includes meta data synchronization
28
32. Worker Node Config
- Create worker node
ant createWorker
Buildfile: /Users/azeez/software/wso2carbon-core-4.0.2/bin/build.xml
createWorker:
[input] You are about to delete all the front-end components from the server
runtime. Do you really want to proceed? (y, [n])
32
34. WorkerNode Config – carbon.xml
• <!--
• Host name or IP address of the machine hosting this server
• e.g. www.wso2.org, 192.168.1.10
• This is will become part of the End Point Reference of the
• services deployed on this server instance.
• -->
• <HostName>appserver.wso2.com</HostName>
34
