blob: 4f4b04f1ae498b1ca5bd086949e3f1e574f9513c [file] [log] [blame]
type=page
status=published
title=Checklist for Deployment
prev=planning.html
~~~~~~
= Checklist for Deployment
[[GSPLG00003]][[abfeq]]
[[checklist-for-deployment]]
== 3 Checklist for Deployment
This appendix provides a checklist to get started on evaluation and
production with the {productName}.
[[sthref7]][[checklist]]
=== Checklist
[[sthref8]][[sthref9]]
Table 3-1 Checklist
[width="100%",cols="<23%,<77%",options="header",]
|===
|Component/Feature |Description
|Application
a|Determine the following requirements for the application to be deployed.
* Required/acceptable response time.
* Peak load characteristics.
* Necessary persistence scope and frequency.
* Session timeout in `web.xml`.
* Failover and availability requirements.
For more information see the link:performance-tuning-guide.html#GSPTG[
{productName} Performance Tuning Guide].
|Hardware
a|
* Have necessary amounts of hard disk space and memory installed.
* Use the sizing exercise to identify the requirements for deployment.
For more information see the link:release-notes.html#GSRLN[{productName} Release Notes]
|Operating System
a|
* Ensure that the product is installed on a supported platform.
* Ensure that the patch levels are up-to-date and accurate.
For more information see the link:release-notes.html#GSRLN[{productName} Release Notes]
|Network Infrastructure
a|
* Identify single points of failures and address them.
* Make sure that the NICs and other network components are correctly configured.
* Run `ttcp` benchmark test to determine if the throughput meets the requirements/expected result.
* Setup `ssh` based your preference.
For more information see the link:installation-guide.html#GSING[{productName} Installation Guide].
|Back-ends and other external data sources
|Check with the domain expert or vendor to ensure that these data sources
are configured appropriately.
|System Changes/Configuration
a|
* Make sure that changes to `/etc/system` and its equivalent on Linux
are completed before running any performance/stress tests.
* Make sure the changes to the TCP/IP settings are complete.
* By default, the system comes with lots of services pre-configured. Not
all of them are required to be running. Turn off services that are not
needed to conserve system resources.
* On Solaris, use `Setoolkit` to determine the behavior of the system.
Resolve any flags that show up.
For more information see the link:performance-tuning-guide.html#GSPTG[{productName} Performance Tuning Guide].
|Installation
a|
* Ensure that these servers are not installed on NFS mounted volumes.
* Check for enough disk space and RAM when installing {productName}.
|{productName} Configuration
a|
* Logging: Enable access log rotation.
* Choose the right logging level. WARNING is usually appropriate.
* Configure Jakarta EE containers using the Administration Console.
* Configure HTTP listeners using the Administration Console.
* Configure ORB threadpool using the Administration Console.
* If using Type2 drivers or calls involving native code, ensure that
mtmalloc.so is specified in the LD_LIBRARY_PATH.
* Ensure that the appropriate persistence scope and frequency are used
and they are not overridden underneath in the individual Web/EJB modules.
* Ensure that only critical methods in the SFSB are checkpointed.
For more information on tuning, see the link:performance-tuning-guide.html#GSPTG[{productName} Performance Tuning Guide].
For more information on configuration, see the link:administration-guide.html#GSADG[{productName} Administration Guide].
|Load balancer Configuration
a|
* Make sure the Web Server is installed.
* Make sure the load balancer plug-in into the Web Server is installed.
* Make sure patch checks is disabled.
* Lower the value of the `KeepAliveQuery` parameter. The lower the
value, the lower the latency is on lightly loaded systems. The higher
the value, the higher the throughput is on highly loaded systems.
|Java Virtual Machine Configuration
a|
* Initially set the minimum and maximum heap sizes to be the same, and
at least one GB for each instance.
* See http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html[
Java Hotspot VM Options]
(`http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html`)
for more information.
* When running multiple instances of {productName}, consider creating
a processor set and bind {productName} to it. This helps in cases
where the CMS collector is used to sweep the old generation.
|Configuring time-outs in the load balancer
a|
* Response-time-out-in-seconds - How long the load balancer waits before
declaring a {productName} instance unhealthy. Set this value based on
the response time of the application. If set too high, the Web Server
and load balancer plug-in wait a long time before marking a {productName} instance as unhealthy. If set too low and {productName}'s
response time crosses this threshold, the instance will be incorrectly
marked as unhealthy.
* Interval-in-seconds - Time in seconds after which unhealthy instances
are checked to find out if they have returned to a healthy state. Too
low a value generates extra traffic from the load balancer plug-in to
{productName} instances and too high a value delays the routing of
requests to the instance that has turned healthy.
* Timeout-in-seconds - Duration for a response to be obtained for a
health check request. Adjust this value based on the traffic among the
systems in the cluster to ensure that the health check succeeds.
|Configuring time-outs in {productName}
a|
* Max-wait-time-millis - Wait time to get a connection from the pool
before throwing an exception. Default is 6 s. Consider changing this
value for highly loaded systems where the size of the data being
persisted is greater than 50 KB.
* Cache-idle-timeout-in-seconds - Time an EJB is allowed to be idle in
the cache before it gets passivated. Applies only to entity beans and
stateful session beans.
* Removal-timeout-in-seconds - Time that an EJB remains passivated (idle
in the backup store). Default value is 60 minutes. Adjust this value
based on the need for SFSB failover.
|Tune VM Garbage Collection (GC)
a| Garbage collection pauses of four seconds or more can cause intermittent
problems in persisting session state. To avoid this problem, tune the VM
heap. In cases where even a single failure to persist data is
unacceptable or when the system is not fully loaded, use the CMS
collector or the throughput collector.
These can be enabled by adding: +
`<jvm-options>-XX:+UseConcMarkSweepGC</jvm-options>`
This option may decrease throughput.
|===