Chapter 5 Deployment Design

During the deployment design phase of the solution life cycle, you design a high-level deployment architecture and a low-level implementation specification, and prepare a series of plans and specifications necessary to implement the solution. Project approval occurs in the deployment design phase.

This chapter contains the following sections:

• About Deployment Design

• Deployment Design Methodology

• Estimating Processor Requirements

• Identifying Performance Bottlenecks

• Optimizing Resources

• Managing Risks

About Deployment Design

Deployment design begins with the deployment scenario created during the logical design and technical requirements phases of the solution life cycle. The deployment scenario contains a logical architecture and the quality of service (QoS) requirements for the solution. You map the components identified in the logical architecture across physical servers and other network devices to create a deployment architecture. The QoS requirements provide guidance on hardware configurations for performance, availability, scalability, and other related QoS specifications.

Designing the deployment architecture is an iterative process. You typically revisit the QoS requirements and reexamine your preliminary designs. You take into account the interrelationship of the QoS requirements, balancing the trade-offs and cost of ownership issues to arrive at an optimal solution that ultimately satisfies the business goals of the project.

Deployment Design Methodology

As with other aspects of deployment planning, deployment design is as much an art as it is a science and cannot be detailed with specific procedures and processes. Factors that contribute to successful deployment design are past design experience, knowledge of systems architecture, domain knowledge, and applied creative thinking.

Deployment design typically revolves around achieving performance requirements while meeting other QoS requirements. The strategies you use must balance the trade-offs of your design decisions to optimize the solution. The methodology you use typically involves the following tasks:

• Estimating processsor requirements. Deployment design often begins with portal sizing in the logical architecture. Start with the use cases and modify your estimates accordingly. Also consider any previous experience you have with designing enterprise systems.

• Estimating processsor requirements for secure transport. Study the use cases that require secure transport and modify CPU estimates accordingly.

• Replicating services for availability and scalability. Once you are satisfied with the processor estimates, make modifications to the design to account for QoS requirements for availability and scalability. Consider load balancing solutions that address availability and failover considerations.

  During your analysis, consider the trade-offs of your design decisions. For example, what affect does the availability and scalability strategy have on serviceability (maintenance) of the system? What are the others costs of the strategies?

• Identifying bottlenecks. As you continue with your analysis, examine the deployment design to identify any bottlenecks that cause the transmission of data to fall beneath requirements, and make adjustments.

• Optimizing resources. Review your deployment design for resource management and consider options that minimizes costs while fulfilling requirements.

• Managing risks. Revisit your business and technical analyses with respect to your design, making modifications to account for events or situations that might not have been foreseen in the earlier planning.

Estimating Processor Requirements

With a baseline figure established in the usage analysis, you can then validate and refine that figure to account for scalability, high availability, reliability, and good performance:

Steps to Estimate Processor Requirements

Steps

1. Customize the Baseline Sizing Figures

2. Validate Baseline Sizing Figures

3. Refine Baseline Sizing Figures

4. Validate Your Final Figures

   The following sections describe these steps.

Customize the Baseline Sizing Figures

Establishing an appropriate sizing estimate for your Portal Server deployment is an iterative process. You might wish to change the inputs to generate a range of sizing results. Customizing your Portal Server deployment can greatly affect its performance.

After you have an estimate of your sizing, consider:

• LDAP Transaction Numbers

• Application Server Requirements

LDAP Transaction Numbers

Use the following LDAP transaction numbers for an out-of-the-box portal deployment to understand the impact of the service demand on the LDAP master and replicas. These numbers change once you begin customizing the system.

• Access to authless anonymous portal - 0 ops

• Login by using the Login channel - 2 BINDS, 2 SRCH

• Removing a channel from the Portal Desktop - 8 SRCH, 2 MOD

• Reloading the Portal Desktop - 0 ops

Application Server Requirements

One of the primary uses of Portal Server installed on an application server is to integrate portal providers with Enterprise JavaBeans^TM architecture and other J2EE^TM technology stack constructs, such as Java Database Connectivity (JDBC^TM) and J2EE^TM Connector Architecture (JCA), running on the application server. These other applications and modules can consume resources and affect your portal sizing.

Validate Baseline Sizing Figures

Now that you have an estimate of the number of CPUs for your portal deployment, use a trial deployment to measure the performance of the portal. Use load balancing and stress tests to determine:

• Throughput, the amount of data processed in a specified amount of time

• Latency, the period of time that one component is waiting for another component

• Maximum number of concurrent sessions

Portal samples are provided with the Portal Server. You can use them, with channels similar to the ones you will use, to create a load on the system. The samples are located on the Portal Desktop.

Use a trial deployment to determine your final sizing estimates. A trial deployment helps you to size back-end integration to avoid potential bottlenecks with Portal Server operations.

Refine Baseline Sizing Figures

Your next step is to refine your sizing figure. In this section, you build in the appropriate amount of headroom so that you can deploy a portal site that features scalability, high availability, reliability and good performance.

Because your baseline sizing figure is based on so many estimates, do not use this figure without refining it.

When you refine your baseline sizing figure:

• Use your baseline sizing figure as a reference point.

• Expect variations from your baseline sizing figure.

• Learn from the experience of others.

• Use your own judgement and knowledge.

• Examine other factors in your deployment.

  If the Portal Server deployment involves multiple data centers on several continents and even traffic, you need a higher final sizing figure than if you have two single data centers on one continent with heavy traffic.

• Plan for changes.

  A portal site is likely to experience various changes after you launch it. Changes you might encounter include the following:

  • An increase in the number of channels

  • Growth in the user base

  • Modification of the portal site’s purpose

  • Changes in security needs

  • Power failures

  • Maintenance demands

    Considering these factors enables you to develop a sizing figure that is flexible and enables you to avoid risk when your assumptions regarding your portal change following deployment.

    The resulting figure ensures that your portal site has:

  • Scalability high availability, reliability and high performance

  • Room for whatever you want to provide

  • Flexibility for adjusting to changes

Validate Your Final Figures

Use a trial deployment to verify that the portal deployment satisfies your business and technical requirements.

Identifying Performance Bottlenecks

Before reading the section on memmory consumption and it’s affect on performance, read the following document on tuning garbage collection with the Java Virtual Machine, version 1.4.2:

http://java.sun.com/products/hotspot/index.html

Memory Consumption and Garbage Collection

Portal Server requires substantial amounts of memory to provide the highest possible throughput. At initialization, a maximum address space is virtually reserved but does not allocate physical memory unless needed. The complete address space reserved for object memory can be divided into the young and old generations.

Most applications suggest using a larger percentage of the total heap for the new generation, but in the case of Portal Server, using only one eighth the space for the young generation is appropriate, because most memory used by Portal Server is long-lived. The sooner the memory is copied to the old generation the better the garbage collection (GC) performance.

Even with a large heap size, after a portal instance has been running under moderate load for a few days, most of the heap appears to be used because of the lazy nature of the GC. The GC performs full garbage collections until the resident set size (RSS) reaches approximately 85 percent of the total heap space; at that point the garbage collections can have a measurable impact on performance.

For example, on a 900 MHz UltraSPARCIII^TM, a full GC on a 2 GB heap can take over ten seconds. During that period of time, the system is unavailable to respond to web requests. During a reliability test, full GCs are clearly visible as spikes in the response time. You must understand the impact on performance and the frequency of full GCs. In production, full GCs go unnoticed most of the time, but any monitoring scripts that measure the performance of the system need to account for the possibility that a full GC might occur.

Measuring the frequency of full GCs is sometimes the only way to determine if the system has a memory leak. Conduct an analysis that shows the expected frequency (of a baseline system) and compare that to the observed rate of full GCs. To record the frequency of GCs, use the vebose:gc JVM^TM parameter.

Optimizing Resources

You can optimize resources by using the following:

• Hardware Accelerator

• Sun Enterprise Midframe Line

Hardware Accelerator

SSL-intensive servers, such as the SRA Gateway, require large amounts of processing power to perform the encryption required for each secure transaction. Using a hardware accelerator in the Gateway speeds up the execution of cryptographic algorithms, thereby increasing the performance speed.

The Sun Crypto Accelerator 1000 board is a short PCI board that functions as a cryptographic co-processor to accelerate public key and symmetric cryptography. This product has no external interfaces. The board communicates with the host through the internal PCI bus interface. The purpose of this board is to accelerate a variety of computationally intensive cryptographic algorithms for security protocols in e-commerce applications.

See the Sun Java System Portal Server 6 Secure Remote Access 2005Q4 Administration Guide for more information on the Sun Crypto Accelerator 1000 board and other accelerators.

---

Note –

The Sun Crypto Accelerator 1000 board supports only SSL handshakes and not symmetric key algorithms. This is not generic to all other cryptographic accelerators. Other cryptographic accelerators are on the market and some of them can support symmetric key encryption.

You could use a hardware accelerator on the Netlet Proxy and Rewriter Proxy machine and derive some performance improvement.

---

Sun Enterprise Midframe Line

Normally, for a production environment, you would deploy Portal Server and SRA on separate machines. However, in the case of the Sun Enterprise^TM midframe machines, which support multiple hardware domains, you can install both Portal Server and SRA in different domains on the same Sun Enterprise midframe machine. The normal CPU and memory requirements that pertain to Portal Server and SRA still apply; you would implement the requirements for each in the separate domains.

In this type of configuration, pay attention to security issues. For example, in most cases the Portal Server domain is located on the intranet, while the SRA domain is in the DMZ.

Managing Risks

This section contains a few tips to help you in the sizing process.

• A business-to-consumer portal requires that you deploy SRA to use the Gateway and SSL. Make sure you take this into account for your sizing requirements. Once you turn on SSL, the performance of the portal can be up to ten times slower than without SSL.

• For a business-to-employee portal, make sure that you have a user profile that serves as a baseline.

• For any portal, build in headroom for growth. This means not just sizing for today’s needs, but future needs and capacity. This includes usual peaks after users return from a break, such as a weekend or holiday, or if usage is increased over time because the portal is more “sticky.”

• If you are deploying your portal solution across multiple geographic sites, you need to fully understand the layout of your networks and data centers

• Decide what type of redundancy you need. Consider items such as production down time, upgrades, and maintenance work. In general, when you take a portal server out of production, the impact to your capacity should be no more than one quarter of the overall capacity.

• In general, usage concurrencies for a business-to-employee portal are higher than a business-to-consumer portal.