IBM BS029ML Self Help Guide - Page 45

Scalability, 2.5.2 Guidance regarding vertical and horizontal scaling, Vertical clustering

Page 45 highlights

2.5.1 Scalability As mentioned previously, the ability to scale WebSphere Portal Server V6.0.1, or any other WebSphere Application Server for that matter, is essentially achieved by clustering. Clustering allows requests to be Workload Managed (WLM'ed) between a number of cloned copies of the concerned application. In addition, when architected correctly, clustering addresses redundancy and fault tolerance. Overall Portal scalability will be accomplished by clustering at the various different tiers of the architecture, both horizontally and vertically where permitted. Usually, a platform's capacity must be capable of handling a realistic amount of transactions over a projected time frame. 2.5.2 Guidance regarding vertical and horizontal scaling Ultimately, as client load increases, even a properly tuned WebSphere Portal Server will reach a point at which throughput reaches a maximum. After this point, throughput remains fairly constant while response times degrade as further clients attempt to access the solution. Eventually, a saturation point will be reached. The number of concurrent active clients at the saturation point represents the maximum active client concurrency for the solution. Adding more nodes into a cluster is one way of scaling an application to achieve the goals defined by the non-functional requirements (NFRs). Vertical clustering Vertical clustering should be considered for a number of reasons: To fully utilize the processing power of modern SMP servers Local redundancy Horizontal clustering By contrast, horizontal clustering should be considered for the following reasons: To achieve scalability beyond the limitation of individual servers Redundancy and reliability Hardware failover Horizontal scaling is especially effective in environments that contain many smaller, less powerful machines. Client requests that would overwhelm a single small machine can be distributed over several machines in the solution. Failover is another benefit of horizontal scaling. If a machine becomes unavailable, its work can be routed to other machines containing cluster members. By contrast, vertical cloning benefits Symmetric Multi-Processing (SMP) systems and should be implemented when system resources are found to be underutilized. For Java, systems with multiple processors typically outperform multiple systems with fewer processors, when comparing the total number of processors. A general rule of thumb has always been to allocate a single Java Virtual Machine (JVM) to a single processor. Traditionally, this was based on the constraint that the compaction phase of Garbage Collection (GC) was single threaded. Recent versions of the JVM have, however, minimized this restriction, potentially allowing a greater number of JVMs to run given the total number of available processors. It is also worth remembering that there are a number of JVMs associated with the Deployment Manager and NodeAgent (a NodeAgent is required for each individual physical node participating in the cell) when running Portal Server V6.0.1 in a clustered environment. Chapter 2. Architecture and planning 31

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242

Chapter 2. Architecture and planning
31
2.5.1
Scalability
As mentioned previously, the ability to scale WebSphere Portal Server V6.0.1, or any other
WebSphere Application Server for that matter, is essentially achieved by clustering.
Clustering allows requests to be Workload Managed (WLM'ed) between a number of cloned
copies of the concerned application. In addition, when architected correctly, clustering
addresses redundancy and fault tolerance.
Overall Portal scalability will be accomplished by clustering at the various different tiers of the
architecture, both horizontally and vertically where permitted. Usually, a platform’s capacity
must be capable of handling a realistic amount of transactions over a projected time frame.
2.5.2
Guidance regarding vertical and horizontal scaling
Ultimately, as client load increases, even a properly tuned WebSphere Portal Server will
reach a point at which throughput reaches a maximum. After this point, throughput remains
fairly constant while response times degrade as further clients attempt to access the solution.
Eventually, a saturation point will be reached. The number of concurrent active clients at the
saturation point represents the maximum active client concurrency for the solution. Adding
more nodes into a cluster is one way of scaling an application to achieve the goals defined by
the non-functional requirements (NFRs).
Vertical clustering
Vertical clustering should be considered for a number of reasons:
±
To fully utilize the processing power of modern SMP servers
±
Local redundancy
Horizontal clustering
By contrast, horizontal clustering should be considered for the following reasons:
±
To achieve scalability beyond the limitation of individual servers
±
Redundancy and reliability
±
Hardware failover
Horizontal scaling is especially effective in environments that contain many smaller, less
powerful machines. Client requests that would overwhelm a single small machine can be
distributed over several machines in the solution. Failover is another benefit of horizontal
scaling. If a machine becomes unavailable, its work can be routed to other machines
containing cluster members.
By contrast, vertical cloning benefits Symmetric Multi-Processing (SMP) systems and should
be implemented when system resources are found to be underutilized. For Java, systems
with multiple processors typically outperform multiple systems with fewer processors, when
comparing the total number of processors.
A general rule of thumb has always been to allocate a single Java Virtual Machine (JVM) to a
single processor. Traditionally, this was based on the constraint that the compaction phase of
Garbage Collection (GC) was single threaded. Recent versions of the JVM have, however,
minimized this restriction, potentially allowing a greater number of JVMs to run given the total
number of available processors. It is also worth remembering that there are a number of
JVMs associated with the Deployment Manager and NodeAgent (a NodeAgent is required for
each individual physical node participating in the cell) when running Portal Server V6.0.1 in a
clustered environment.