Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

IBM Connections – Managing Growth and Expansion

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.

  • Login to see the comments

  • Be the first to like this

IBM Connections – Managing Growth and Expansion

  1. 1. Toronto, June 6-7 2016 IBM Connections Managing Growth and Expansion What to do when you start growing Victor Toal ToalSystems
  2. 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. 3. Let’s look at some samples of Environments 3 #engageug
  4. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 15. Add HTTP Server
  16. 16. Adding to the Application Layer Add some WebSphere “We need more servers!”
  17. 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. 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. 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. 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. 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. 22. How To Add A New Cluster 22 #engageug
  23. 23. The Database Layer There is a New Player in Town And It’s Called “Mo Data”
  24. 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. 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. 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. 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. 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. 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. 30. Adding to the File System Layer We have the issue of “I NEED MORE ROOM or “YOUR FILE SERVER IS SLOOOOOOOW”
  31. 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. 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. 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. 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. 35. Last but not least THANK THE GUYS and GALS THAT PAID FOR THIS SHINDIG Thank our sponsors!
  36. 36. PLATINUM & SPOTLIGHT SPONSORS GOLD SPONSORS SILVER SPONSORS BRONZE SPONSORS

×