As you learned in this chapter, there's a great deal of design and decision making required when choosing your system platform. The approach you take is important because your platform choice will have a
The reason for this is that different platforms have differing limitations and capabilities. If, for example, you choose an x86-based processor from Intel that has a 4GB memory limit, then your application design needs to follow a horizontal system architecture model ”that is, you need many smaller servers to get over memory limitations.
Also, consider the costs associated with going for smaller model servers in your
It's better to have a redundant system than a system that has too much
If tuning websphere
Each topology has its place and its pros and cons, mostly dependent on or driven by three key factors: scalability, reliability (availability), and performance. In this chapter I examine each topology from a top-down perspective and focus on what each design entails, cover what its benefits and trade-offs are, and suggest different WebSphere
Like most topics I've discussed so far in this book, cost is the most prohibitive factor. If cost wasn't an issue, I'm sure most of us would go for the most scalable and reliable system. However, as we all know, cost benefit realization is an important analytical process that should be weighed against each design to
A WebSphere implementation, from the physical view at the highest level, can be broken into four main components:
Web server or Web
Application server or application/business tier
Database server or data tier
Suppose your application server was operating at greater than 70 percent utilization and customers were starting to notice a performance degradation. You could scale your application or business tier either vertically (i.e., add more CPUs, memory, disk, network interfaces, etc.) or horizontally (i.e., add more servers). As you'll see in detail in this chapter, both approaches have pros and cons, and although the choice may appear to be simple for resolving your performance issues, the answer isn't always straightforward.
Not all applications that
Yes, this works for smaller applications, which may happen to be
In the following sections, you'll look at vertical and horizontal scaling in a little more detail,
of a system or a system's components
Figure 5-1 illustrates an example of horizontal scaling.
Figure 5-1: Horizontal scaling example with WebSphere
As you can tell from Figure 5-1, horizontal scaling is a relatively straightforward approach to extending a WebSphere environment from the point of view of a basic or noncomplex J2EE application running within WebSphere. However, once you start to need to look at ensuring that users' data is
You'll explore the concepts of
involves scaling "upward" within your existing servers. That is, you add in, or upgrade, additional processing power, memory, disks, and so on within existing servers rather than purchase additional servers (which is what is involved in horizontal scaling). This form of platform scaling is best suited to large applications that require centralized, workhorse-type servers to be able to process large
Vertical scaling is also the optimal choice for sites that are short on support resources. Generally speaking, the more servers that you have to manage, the more support processes and resources you need to have in place to adequately manage your many horizontally scaled servers. More infrastructure can also cost more from a facilities management point of view ”more rack space, more power requirements, more networking infrastructure, and so on. Therefore, the decision to vertically scale or horizontally scale may be based on factors other than application architecture requirements.
You'll need to consider vertical scaling in the way you configure your WebSphere server and, depending on your application architecture, in the way you design your application. What this means is that it's all very well to purchase a server with plenty of memory, but you need to
The same considerations apply to CPUs. There's no benefit to having a system with ten CPUs and, due to some form of application design limitation, only being able to operate a single JVM instance of your application and effectively wasting nine CPUs!
One downside to vertical scaling for the majority of WebSphere
At the end of the day, the best design uses a mixture of horizontal and vertical scaling. This satisfies availability requirements as well as scalability and performance requirements for application environments:
Multiple servers support redundancy and availability, and aid in scalability.
The servers can be upgraded or vertically scaled to support growing application-processing demands.
A mixture of horizontal and vertical scaling can also provide the best of both
Figure 5-2 highlights a basic vertically and horizontally scaled application environment.
Figure 5-2: Example of a horizontally and vertically scaled environment
Figure 5-2 illustrates how customer traffic and requests are distributed to a
That said, if you're looking to roll out a smaller WebSphere implementation, you should conduct a return on investment (ROI) analysis on the costs associated with the additional infrastructure. In Chapter 2 you looked at some examples for ROI analysis. When lined up against the costs associated with actually having downtime, the result from the ROI model may suggest that it isn't
I know systems managers who are responsible for small WebSphere production environments running on x86 clone machines. Their train of thought is that, if the server dies, all they need to do is run down to the local PC shop and pick up the new replacement part(s), install it, and then restore the data from the last backup. The cost for that replacement part may be only a few hundred dollars, and given the general low complexity of these types of systems, installing the part and bringing the system up again may take only as long as 30 to 90 minutes.
For this reason, having additional servers to cater for redundancy may not be an issue for some sites.