- Recommendations for Applying Preferred Practices
- Principals of Mission-Critical Implementations
- Physical Environment
- Internal Network Planning
- External Network Planning
- System Controller Configuration
- Platform and Domain Administration
- Security
- Error Analysis and Diagnosis
- Platform and Domain Configuration
- Dynamic Reconfiguration
- References
- Related Resources
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Platform and Domain Administration
We recommend that you have Sun Support Services perform the initial installation and test of the Sun Fire 15K/12K hardware and software. The installation will use the Enterprise Installation Standards (EIS) CD installation checklist and scripts. The EIS CD is an internal Sun toolkit designed to help Sun Services engineers perform consistent installations that can be supported easily. The EIS CD is available only to Sun Service engineers, however, you can validate that the installation used the EIS methodology by checking the EIS log files in the /var/sun directory. These log files show the installation date, EIS version used, and the actions selected during the setup. This installation should be followed by a Sun Professional Services Application Readiness Service (ARS) to test, document, and prepare the platform and domains for mission critical application deployment. The Sun Fire 15K/12K servers operational runbook, testing procedures, and build specifications are included with this service.
Sizing and Allocating Memory
Properly sizing and testing applications before deploying them in the production environment should identify the appropriate memory resource requirements. Internally, Sun Microsystems has many resources dedicated to helping customers properly size specific applications prior to deployment, including Sun_ ONE applications, SAP, PeopleSoft, and ORACLE®, to name a few. Remember, with dynamic reconfiguration (DR), memory can be added online; however, this should not be used as a remedy for poor planning and poor application sizing up front.
You can adjust the Solaris /etc/system parameters to optimize domains that require large memory models. These parameters are documented in other Sun BluePrints OnLine publications such as "Configuring and Tuning Databases on the Solaris Platform." Before using the parameters in the production domain, fully test all modifications to the Solaris /etc/system parameters on a separate non-production domain, and install the test domain with all target applications and cluster software replicated as closely to the production domain as is possible. In addition, ensure that frequent checks and monitoring software are in place to detect memory shortages, leaks, and excessive scanning of memory pages. This is especially important in domains that run many concurrent database instances, which is now commonly done on Sun Fire 15K/12K platforms.
From a hardware perspective, memory DIMMS within each domain of the platform should have a consistent footprint. Therefore, try to design domains with CPU/Memory boards that contain, for example, all 1-gigabyte DIMMS or all 256-megabyte DIMMS. This also eases the planning of resources and DR operations in a consolidated system.
Configuring the Dump Device
The dump device is used when the Solaris OE panics and writes an image of the system memory (physical memory, not virtual or swapped-out memory) to the designated dump device. Usually, this device is designated as the primary swap device. When the system is rebooted after the panic, the operating system performs a savecore dump and then writes the contents to a file on a mounted file system in the /var/crash/'uname -n' directory. To manage and change the dump device configuration, use the dumpadm command.
There might be other configuration exceptions to consider if the system is using VERITAS Volume Manager with root encapsulation or if the system is being mirrored with Solaris Volume Manager software. In these cases, refer to the latest documentation on http://sunsolve.sun.com for detailed configurations. The main consideration is to make the dump device big enough to hold the entire core dump. This can vary by the size of the memory that is configured, but to play it safe, configure the dump device at least 4 gigabytes. Because no hard rules exist, test it to see if it creates usable savecore files. You can do this by setting the autoboot parameter to true and using the sync command at the OpenBoot prompt. Then, check the savecore vmcore.x and unix.x files. If space in the file system is a concern for storing the vmcore.x and unix.x files, you can change the location of both the dump device and the savecore directory with the dumpadm command.
Configuring Swap
In most instances, application requirements dictate swap space allocation. Some applications, such as SAP, require large amounts of swap space. Sometimes, more space is allocated than is actually needed because of overly conservative recommendations by the application vendor. From a performance perspective, swap space makes a difference only when you are short of physical memory. If the system is not paging, it makes no difference how much swap space you allocate. However, the consequences of running out of swap when a system needs it can have extremely detrimental effects on availability. This is especially true with large domains running many applications or database instances. Therefore, we recommend that you allocate a lot more space for swap than you expect to need to cope with usage peaks. In addition, when you add applications to existing Sun Fire 15K/12K production domains, review and modify the swap space accordingly. Systems with Oracle 9i databases and Solaris 8 OE that will use dynamic reconfiguration (DR) might also require additional swap.
In the absence of any vendor application-specific swap space requirements, the current practice is to configure swap to be equal to the amount of configurable memory on each CPU/Memory board, and to double that the amount for domains that are doing DR operations. (Note that these are the minimum estimations, not absolute recommendations.) For example, if the Sun Fire 15K/12K domains have two CPU/Memory boards, each configured with 8 gigabytes of memory (16 gigabytes, total, for the domain), then the swap should be 16 gigabytes. If DR is being considered in the domain, configure the swap to be twice the maximum amount of configurable memory on one CPU/memory board or, in this example, 32 gigabytes for the domain. The DR detach operation uses swap space for draining the pagable memory contained on the board that is being removed from the domain.
Keeping OS Software Up-to-Date
Because Sun Fire 15K/12K applications generally require large memory models and high performance, we recommend that you use the most recent Solaris OE version and update that the application will support to take advantage of this. If the application will support it, we recommend the use of Solaris 9 OE to obtain the best possible performance.
In most cases, system kernel parameters are dependent on the application requirements, and any changes should be well tested before you deploy them in a production environment. Some Sun Fire 15K/12K system parameters are required for performing DR operations on domains. These parameters are described in "Dynamic Reconfiguration" on page 27.
Keeping Firmware Current
The firmware levels on all system boards should be identical to each other. Always use the latest firmware available for the version of SMS being used, even if it means you have to downgrade a board. Each CPU/Memory board contains two fproms that must be maintained. Because the CPU/Memory boards on the Sun Fire 15K/12K, the Sun Fire 6800/4810/4800, and the Sun Fire 1280 servers are the same, they should be flashed to the same levels if there are plans to swap or use common components for maintenance purposes. Additionally, the system controller's OBP and POST must be flash updated to the same levels.