You are lucky, your Connections platform is experiencing rapid growth – now what? How to you determine when you have grown to where you need to build out the service? How do you grow WebSphere or the File Service Space? How do you add additional Web Servers or is it better to add a proxy server? Learn how to judge and decide what you need to change – and how to then implement it.

1. Toronto, June 6-7 2016
IBM Connections
Managing Growth and
Expansion
What to do when you start growing
Victor Toal
ToalSystems

2. What will we talk about today?
• What does a “Normal” Environment look like?
• Identify where you need to grow
• Why would you want to change/grow?
• What Components do you have and what do
you do about them?
Let’s Go!
2
#engageug

3. Let’s look at some samples of Environments
3
#engageug

4. Architecture – Non Clustered
Web Layer
Application Layer
Services Layer
User HTTP Traffic
Connections Server 1
Deployment Manager
Application Node1
DB2 Server File Server Share
Shared File Services
Web Server 1
Access to shared
file repository
DB Access Share File Services
CNX5.ToalSys.Social
Connections 5.0 Architecture
Non-Clustered
Non Clustered Components:
Connections URL: http://cnx5.toalsys.social
Server1: CNXSrv01.intranet.toalsys.com
HTTP: HTTP01.intranet.toalsys.com
DB2: dbSrv01.intranet.toalsys.com
File server: space01.intranet.toalsys.com
Connections Data File Share: fileserver.toalsys.socialcnxdata
OR
D:IBMConnectionsDatashared

5. Architecture - Clustered
Web Layer
Application Layer
Services Layer
User HTTP Traffic
Connections Server 1
Deployment Manager
Application Node1
Connections Server 1
Application Node2
DB2 Server File Server Share
Shared File Services
Web Server 1
Access to shared
file repository
DB Access Share File Services
CNX5.ToalSys.Social
Connections 5.0 Architecture
Clustered
Clustered Components:
Connections URL: http://cnx5.toalsys.social
Server1: CNXSrv01.intranet.toalsys.com
Server2: CNXSrv02.intranet.toalsys.com
HTTP: HTTP01.intranet.toalsys.com
DB2: dbSrv01.intranet.toalsys.com
File server: space01.intranet.toalsys.com
Connections Data File Share: fileserver.toalsys.socialcnxdata

6. Identify Where You Need To Grow
Connections has 4 Distinct Layers
• WEB IHS, Proxy Server
• APPLICATION WebSphere
• DATABASE DB2, SQL, Oracle
• FILE SYSTEM Local file system,
remote file system
6
#engageug

7. Reasons For Growth
• More users
• More engagement
• Business uptick
• Integration of Connections into business
processes causes increased usage
• External collaboration causes you to drastically
increase your number of communities
• To create redundancy and resiliency in your
environment
• To simply make operations easier
7
#engageug

8. First Things first
Review Performance Tuning
If you do not tune your environment, adding
complexity will possibly kill it.
• Connections 5.0 performance tuning guide
https://goo.gl/YNbWRr
• Connections 4.5 performance tuning guide
https://goo.gl/l3oHrT
• Review the Post Install Tasks in the Connections
WIKI
• http://goo.gl/gPJ7FF
8
#engageug

9. Identify The Weak Link
• Just looking at CPU and memory is not enough
• Each Component has different characteristics
• One weakness can impact another layer,
masking the actual problem
• Sometime Network can impact performance –
routing, DNS, network links, network cards …
• Example: a slow SANS EVA might impact file
performance, but in reality it is a network issue
that shows itself as a slow file system.
9
#engageug

10. The Web Layer
Components making up the web layer:
• IHS
• Proxy Servers
• Load Balancers
• Any other connected Web Services
(STProxy, ICMail/Email tie-in)
10
#engageug

11. Adding To the Web Layer
Why Another Web Server?
Moving an IHS on to a separate server
Adding an additional/second IHS
11
#engageug

12. Adding To the Web Layer … continued
• Have you done your homework in terms of
performance? Often tweaking the
httpd.conf can greatly improve
performance
• Multiple HTTP servers will necessitate
adding load balancing / switching
capability in front of the web servers
12
#engageug

13. Adding To the Web Layer … continued
• If you are looking at adding redundancy then you
need to make sure you are not just kicking the
vulnerability can down the rad by now relying on a
singular device in front of two web servers …
• But – most systems have a single point of failure
someplace, it simply depends on WHAT part and
HOW LIKLEY is it to fail and HOW IT FITS INTO
OPERATIONS.
• Example: which device is more likely to experience
changes and require a reboot: a Windows server
running IHS or a dedicated load balancing HW
device?
13
#engageug

14. Adding To the Web Layer … continued
• Adding another HTTP Server:
• Install IBM HTTP server on new machine – use
the same configuration settings as the existing
server!
• Add another unmanaged node, setup and
configure the HTTP server/web server
• Remap all application modules to add the new
IHS
• Generate the Plug-in, propagate it, restart IHS
and then restart Connections WebSphere
servers
14
#engageug

15. Add HTTP Server

16. Adding to the Application Layer
Add some WebSphere
“We need more servers!”

17. Adding to the Application Layer -
WebSphere
Let me ask again:
Have you done any real performance tuning?
Links:
• Connections 5.0 performance tuning guide
https://goo.gl/YNbWRr
• Connections 4.5 performance tuning guide
https://goo.gl/l3oHrT
• Review the Post Install Tasks in the Connections
WIKI
• http://goo.gl/gPJ7FF
17
#engageug

18. Adding to the Application Layer …
continued
What can you do?
• Add additional nodes – on existing servers
as well as on new WebSphere servers
• Add more cluster members (servers) – on
any node
• Expand vertically – adding additional
WebSphere instances and federating them
in is simple
18
#engageug

19. Adding to the Application Layer …
continued
What you cannot do:
• CAN’T move Connections applications from one
server/JVM to another. Apps will no longer work,
upgrades become impossible
• CAN’T change from your current deployment
(small, medium, large) to another type of
deployment. If you need to do this, consider it to
be a migration -> parallel build and cut-over.
• CAN’T cluster WebSphere over a WAN
connection – too slow
19
#engageug

20. Adding to the Application Layer …
continued
If adding a physical WebSphere server:
• Make sure you set it up the same way as the
existing servers – same drive/folder configuration,
database ODBC drivers at same location, member
of SPNEGO config, etc. Turn off firewall on server
• Federate the Node to the Deployment Manager, you
don’t have to add the default server and apps to the
deployment manager
• Make sure that server is up and running correctly,
review the logs after running the addNode.bat/.sh
command
20
#engageug

21. Adding to the Application Layer …
continued
• When adding Was servers – add them as cluster
members on a new node -> they get all the same
applications and settings. All default Connections
Apps will work right away
• CCM … Cognos … Docs … Surveys/FEB … ->
they don’t work out of the box, you need to do
actual installation tasks on the new server
• If you are creating NEW WebSphere servers
always create them as clusters, even if they are
not actually clustered with another server -> that
way you can cluster them in the future.
21
#engageug

22. How To Add A New Cluster
22
#engageug

23. The Database Layer
There is a New Player in Town
And It’s Called
“Mo Data”

24. Adding to the Database Layer
Here is our usual first question:
If your reason to add to the database layer is
performance - have you looked into all the
available performance tuning options?
i/o performance is everything for any database
server, tweaking logging and archiving can
make an enormous difference in performance
24
#engageug

25. Adding to the Database Layer …
continued
• IBM documentation does suggest an
individual DB2 instance for each database
(for large, busy systems)
• But if your dB server is already
busy/struggling, then adding an additional
instance will only further degrade
performance
• If you want to just spread the databases over
multiple servers -> that is an easy task
25
#engageug

26. Adding to the Database Layer …
continued
• Build any new servers the same as your
originating server, that way moving/restoring
databases to them is much easier -> otherwise
you get to do a redirected restore
• Add the same user accounts and password on
new DB2 servers
• Any new server must be the same or a newer
version/FP level of DB2. Your database will be
upgraded to the latest version once you restore it
to the new server
• You cannot import/restore a database to a server
with a lower DB2 release – this will not work.
26
#engageug

27. Adding to the Database Layer …
continued
• If you restore a database to a new DB2 instance, it
keeps all of the original settings …i.e. back-ups,
logging settings, etc.
• Any Instance-wide settings should be
copied/implemented in the new instance
• If you have a busy environment, consider building
more than one additional server/instance. It does add
to the complexity but if you plan the disk space right
(SANS can be tricky) you can gain allot in terms of
performance
• Homepage and metrics are great candidates to be
moved to a separate server all by themselves – the
domino effect of that can improve overall performance
27
#engageug

28. Adding to the Database Layer …
continued
• Consider a common log file archive strategy
for all DB2 instances
• Make sure all your servers are backed-up the
same way and in the same frequency
• Restores are always a battle of calculated
data loss …
• Clustered DB2 is part of the Connections
DB2 license – if you feel you absolutely need
it, get an experienced professional to design
it, build it and MOST IMPORTANT teach you
how to maintain it
28
#engageug

29. Adding to the Database Layer …
continued
• Review and update all the correct DB2
related variables in WebSphere: IBM
console – Resources – JDBC – Data
sources
• Each database is entered as a distinctive
data source
29
#engageug

30. Adding to the File System Layer
We have the issue of
“I NEED MORE ROOM
or
“YOUR FILE SERVER IS
SLOOOOOOOW”

31. Adding to the File System
Can you guess my first question?
Performance Tuning anyone?
• What kind of tuning … mainly OS/SANS/i/o of
your infrastructure
• Adding direct file upload/download via the
IBM HTTP servers can greatly improve i/o
stats … WAS is slow and will impact overall
performance of your i/o layer
31
#engageug

32. Adding to the File System … continued
• Just adding to the overall file space is OK – if
you have the space and the performance for
it
• Files on disk get stored in different sub-
folders depending on the date they were
added
• Older files are often accessed much less
frequently than more recent files
• Strategy – if you have multiple SANS
environments you can take advantage of that
32
#engageug

33. Adding to the File System … continued
• Use multiple mount points for each upload
(Files, Wikis, Activities) to spread the
load/io over multiple systems
• Take the folders of Files (analysis is key)
and move it to a slower/older/less
important SANS drive/share.
• This require documentation of the actions
you took
33
#engageug

34. Adding to the File System … continued
• Review back-up and restore procedures
• I personally prefer to move all files of a
service rather than re-point individual
subfolders …. Less complexity and easier
to understand -> it’s WebSphere variables
34
#engageug

35. Last but not least
THANK THE GUYS and GALS THAT PAID
FOR THIS SHINDIG
Thank our sponsors!

36. PLATINUM & SPOTLIGHT SPONSORS
GOLD SPONSORS
SILVER SPONSORS
BRONZE SPONSORS