- 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
System Controller Configuration
The system controller configuration consists of the system controller disk, console, OpenBoot_ parameters, SMS-SVC user configuration, network, operating system, NTP, and SMS software. Many improvements have been made in SMS software version 1.3, including ssh support for file propagation, enhanced access control, and ssh configuration through the smsconfig tool. In addition to security improvements, SMS software version 1.3 fixes many bugs, improves failover functions, and utilizes the HASRAM (memory chips that keep static information even if power is lost) as a backup to the I2 network. Therefore, we recommend that you use SMS software version 1.3 instead of version 1.2.
Configuring Boot Disks
Each system controller is configured from the factory with the operating system and Solaris_ Volume Manager software (formerly, Solstice DiskSuite_ software) for mirroring boot drives. We highly recommend that you do not change this pre-installed configuration or replace it with other volume management products.
The initial configuration uses the first slice of the boot disk to install the root file system and adds the second slice only for swap space. In this configuration, the fourth and fifth slices of the boot disk contain the Solaris Volume Manager state databases. Sun Services completes the configuration of the boot disk configuration on site, using the Sun Services Engineering scripts (EIS Enterprise Installation Standards) to sync and attach Solaris Volume Manager metadevices. If a site has an established JumpStart_ server, this should be used to initially boot and install the domain's operating system. If this is not the case, a file system can be configured on slice seven for initial installations using a Flash archive. Initial communication to the system controller boot server by the domains can be done through the I1 internal network.
System controllers have two internal 18-gigabyte disk drives that are mirrored using Solaris Volume Manager software. The EIS CD contains a script, SF15k-sc-bootdisks-start.sh, that assumes the disk is already formatted with the default partitioning. The script sets up Solaris Volume Manager slices and state databases, and the script SF15k-sc- bootdisks-finish.sh completes the process by syncing and attaching the metadevices. The following table shows the default system controller configuration.
TABLE 0-1 Default System Controller Configuration
|
Partition |
Size MB |
Mount Point |
Description |
|
0 |
8192 |
/ |
Root file system |
|
1 |
2048 |
|
Primary swap |
|
4 |
11.5 |
|
SVM state DB |
|
5 |
11.5 |
|
SVM state DB |
|
7 |
8192 |
/export/install |
Optional install images |
Configuring NTP
Network Time Protocol, generally referred to as NTP, is designed to synchronize the time and date of a client to a time server. If the site has established an NTP configuration to a stratum primary and secondary server, this can be used for the domain and system controller clients. If this is not the case, the system controller can be configured as the NTP server and the domain configured as the NTP client. Before running any applications on the domains, the NTP configuration should be completed and tested.
To initially configure the time on the system controller, you can use the setdate command in the system controller sms-svc account /opt/SUNWSMS/bin/setdate. The spare system controller will synchronize its time internally using the SMS processes. After setting the system controller's date and time, you can set up the domains to use NTP from the system controllers for synchronization of their clocks.
Initially, the recommendation was that the system controller should not use NTP to set its own clock because no offset adjustments will be made, and the virtual TOD values stored on the domain could get skewed. Many installations, however, require their domain times to be synchronized with a time server other than the system controller. Therefore, the system controller and the spare system controller must be able to synchronize their clocks using NTP to another time server, as well. For a detailed procedure for configuring the main system controller, spare system controller, and the domains as NTP clients, refer to the Sun BluePrints OnLine article "Using NTP on the Sun Fire 15K/12K Servers."
Configuring System Controller sms-svc User
The sms-svc user account should not be configured to have platform administrative privileges as well as domain administrative privileges for each domain. The use of the sms-svc account should be discouraged because it is a shared account and its use makes accountability difficult. You should delegate the sms-svc functionality for the platform and domains to specific system administrators and then lock the sms-svc account. Additionally, it is not a good practice to assign the system controller's root user account the same SMS privileges as the sms-svc user account. Any configuration on the platform should be done by the system administer logging into the account with platform privileges for consistency. The EIS CD provides a script that configures the sms-svc user account as described here, and it should run on each system controller.
Managing System Controller Failover
System controller failover is managed by the daemons running on the primary and the secondary system controller. These daemons communicate across the private network that is built into the Sun Fire 15K/12K server frames called the I2 network. It is a preferred practice, and it is crucial to the highly available environment, for the Sun Fire 15K/12K servers to always have failover enabled, and for the data between the two system controllers to always be in sync. Both system controllers should always be running the same versions of OS and SMS, and they should be maintained at the same patch level. Schedule periodic system controller failover tests during off-hour maintenance windows, especially after any changes are made. Tests should include using the SMS set failover force command as well as the halt command for each controller's logon session.
Managing the System Controller Operating System
The system controller operating system and the SMS software are vital to the availability of the Sun Fire 15K/12K servers. A complete and current backup image of the system controller boot disk can prevent unnecessary downtime and possible platform outages. You should create this backup image at regular intervals and after applying any OS or SMS patch updates. SMS software provides the smsbackup and smsrestore utilities to preserve the current SMS software configuration state and history data. It is imperative that you execute an smsbackup after each system configuration change and before applying a new release of SMS software. You can automate this process through the configuration as a cron job, being sure not to store the smsbackup images on the system controllers themselves.
SMS software patches are considered mandatory and might require change control planning to maintain current levels.
Open System Controller (Non-SMS Qualified Software)
System controllers are dedicated components used only for controlling and monitoring the Sun Fire 15K/12K platforms, and they must run at peak performance. The system controllers are used to manage environmental changes and must react in a timely manner to critical events to prevent hardware failures. For this reason, we recommend that you do not install non-SMS software on system controllers.
If it is absolutely necessary for you to install non-SMS software on system controllers, there is a procedure for verification. The Open System process requires a specific setup and validation. Examples of non-SMS software used on the system controllers could include arpwatch (monitors modifications to the arp table), backup agents, and monitoring agents. It is the customer's (system administrator's) responsibility to ensure that adequate system controller resources are available to support all SMS functions and all other software packages that are being installed on the system controller.
The SUNWexplo package is typically the only additional software package that is added to system controllers. The Sun_ Explorer software scripts are used for acquiring static system configuration information for servicing and supportability. These scripts do not impede the performance or affect the functions of the system controllers.