3.1 Planning Your Configuration

Solstice HA configuration involves planning for hardware as well as software. The hardware planning includes decisions about network connections, disk space requirements, disk sizes, and the systems that will be used. You will make decisions about the type of configuration (symmetric or asymmetric), makeup of the disksets, and file system layout.

This subsection first presents a list of the questions you will consider when planning your configuration. You are then given detailed information about each step in the planning. The planning questions and information about planning may not be useful in every situation. Your site's configuration may involve special planning.

You should also become familiar with "Configuration Rules That Improve Reliability" on page 3-23, and "Configuration Restrictions" on page 3-26 before planning the configuration.

The following is a list of questions to consider when planning a configuration. A detailed discussion of each question follows the list.

1. How many public network connections will be made and what will be the names of the connections? See Section 3.1.1, "Network Configuration," on page 3-3.

2. What are the names of the physical hosts and logical hosts? See Section 3.1.2, "Physical and Logical Host Names," on page 3-8.

3. What data services will be provided from the configuration? See Section 3.1.3, "Data Services," on page 3-9.

4. How much existing data will be migrating to the multi-host disks? See Section 3.1.4, "Planning Your Disk Requirements," on page 3-9.

5. What effect will mirroring have on the amount of multi-host data? See Section 3.1.5, "Mirroring," on page 3-10.

6. What will be the use of trans devices in the configuration? See Section 3.1.6, "Trans Devices," on page 3-10.

7. How many hot spares will be allocated for use by multi-host disks? See Section 3.1.7, "Hot Spares," on page 3-11.

8. How much extra disk space will be added for growth? See Section 3.1.8, "Disk Space Growth," on page 3-11.

9. How much disk space is required for multi-host disks? See Section 3.1.9, "Total Storage Requirement," on page 3-12.

10. What size and number of disk drives will be used for multi-host data? See Section 3.1.10, "Size and Number of Disk Drives," on page 3-12.

11. How many SPARCstorage Arrays are needed for the multi-host disks? See Section 3.1.11, "Number of SPARCstorage Arrays," on page 3-13.

12. What size servers are necessary for your configuration? See Section 3.1.12, "Size of Servers," on page 3-13.

13. Where will the servers be located and what power resources are necessary? See Section 3.1.13, "Power Sources and Location for Configurations," on page 3-15.

14. Will the configuration be symmetric or asymmetric? See Section 3.1.14, "Type of Configuration," on page 3-17.

15. How much data will be placed on the local disks? See Section 3.1.15, "Data on Local Disks," on page 3-17.

16. What file system hierarchy are you planning for the configuration? See Section 3.1.16, "Planning Your Multi-host File System Hierarchy," on page 3-18.

17. What is the size and layout of the file system and the metadevices that will be placed on multi-host disks? See Section 3.1.17, "File System Size and Disk Layout," on page 3-19.

18. How many multi-host disks will be placed in each of the disksets? See Section 3.1.18, "Size of Disksets," on page 3-19.

19. What will your naming convention be for metadevices and in which manner will they be created? See Section 3.1.19, "Metadevice Naming and Creation," on page 3-21.

20. How will the data be migrated to the multi-host disks? See Section 3.1.20, "Migrating Existing Data," on page 3-23.

21. What is the backup strategy for the data on the multi-host disks? See Section 3.1.21, "Backing Up Multi-host Data," on page 3-23.

3.1.1 Network Configuration

You must have at least one public network connection to a local area network and two private network connections between the systems. Additional public local area networks can be added.

Solstice HA uses logical network interfaces to establish a mapping between several logical host names and a single physical network interface. This enables one of the physical interfaces to respond to multiple logical host names. The physical network interface on the host that currently has the logical interface configured is the one that services packets destined for that logical interface.

In a symmetric configuration, when each diskset is mastered by its respective default master host, there is only one logical host name associated with a physical network connection. However, when a takeover occurs, two logical host names will be associated with one physical network connection.

If another physical network connection is added, a unique logical host name must also be assigned to the connection on each of the machines. These will also move to the sibling during a switchover or takeover.

A unique host name must be assigned for each logical host on each public network. This requires two logical host names per network for symmetric configurations but only one logical host name per network for asymmetric configurations.

This logical naming may lead to many host names. Thus, you may find it useful to adopt a suffix naming convention in assigning the host names for multiple networks. In Figure 3-1, the last octet of the network number was

appended to the logical host name to distinguish it from the other logical host name (201). You could also use the Ethernet interface name such as qe0 as a naming suffix.

Figure 3-1

The following worksheets show the information for the primary and secondary public networks for the configuration shown in Figure 3-1.

Table 3-1

Primary Network Name: primary-net1	Primary Network Number: 192.9.200
Host Name: host1 host2	Physical Host Name IP Address: 192.9.200.100 192.9.200.101	Network Interface: le0 le0
Host Name: logicalhost1 logicalhost2	Logical Host Name IP Address: 192.9.200.110 192.9.200.111

In Table 3-1 the physical host name of a server on the primary network is by convention the nodename reported by the uname -n command. Similarly, a logical host name on the primary network is used as the name of the logical host associated with specific Solstice HA data services, and as the name of the diskset containing the data.

Table 3-2

Secondary Network Name: secondary-net2	Secondary Network Number: 192.9.201
Host Name: host1-201 host2-201	Physical Host Name IP Address: 192.9.201.100 192.9.201.101	Network Interface: qe0 qe0
Host Name: logicalhost1-201 logicalhost2-201	Logical Host Name IP Address: 192.9.201.110 192.9.201.111

The information in the worksheets in Table 3-1 and Table 3-2 can be used to make entries in the /etc/inet/networks, /etc/inet/host, and /etc/inet/netmasks files as well as the corresponding name services tables and maps. It can also be useful when configuring your Solstice HA systems with hasetup(1M).

Solstice HA systems require two private networks for normal operation. These networks are implemented on SunFastEthernet cards with point-to-point cables between the two Solstice HA systems. Only Solstice HA private traffic appears on these networks.

Two class C network numbers (204.152.64 and 204.152.65) have been reserved for private network use by the servers. The same network numbers are used by all Solstice HA systems.

One way you may wish to form the host names used on these networks is by appending a suffix of -priv1 (for 204.152.64) and -priv2 (204.152.65) to the physical host name. An example of this is illustrated in the Table 3-3.

Table 3-3

IP Address	Host Name	Network Interface
204.152.64.1	host1-priv1	be0
204.152.65.1	host1-priv2	be1
204.152.64.2	host2-priv1	be0
204.152.65.2	host2-priv2	be1

These names must be entered in the /etc/inet/hosts file of both of the Solstice HA servers, but not in the host table of the network name service because they are private.

In addition to /etc/inet/hosts these private host names must appear in the /.rhosts file of both Solstice HA systems to allow hasetup(1M) to communicate between the two systems during configuration.

Finally, you must assign IP addresses and host names for the terminal concentrator and the administration workstation.

Some points to consider when planning network connections are:

• You must create a mapping of the network name to the hardware. For example, a sample mapping would include the IP address (192.9.201.2), the host name (host2-221), and hardware network interface name (qe0). This information is used in the network configuration files. Refer to Chapter 7, "Setting Up Name Services and Networks," for additional information.
• The bandwidth requirements at your site may affect the number of public networks you configure.
• There are network administration issues to consider, including those for data-intensive applications. Refer to the SMCC NFS Server Performance and Tuning Guide (part number 801-7289) for additional information.

• By default the two private networks will be assigned class C network numbers 204.152.64 and 204.152.65. These network numbers can be changed during configuration.

3.1.2 Physical and Logical Host Names

You must select host names for the two Solstice HA servers and a logical host name for each of the logical hosts. In an asymmetric configuration, you will only need one logical host name.

Some points to consider when selecting physical and logical host names are:

• You must select a primary host name for each server. These host names are entered as part of the Solaris 2.4 installation.
• You must select a logical host name for each logical host. In a symmetric configuration there are two logical hosts, while there is only one in an asymmetric configuration. These names are entered when you create the configuration using hasetup(1M).

---

Note - The primary logical host name and the diskset name must be the same string value.

---

• There must be two private host names for each server for the Solstice HA software to communicate across the two private network connections. A possible naming convention is to use suffixes to show the association between the private host names and the host names. An example of the suffixes used would be host1-priv1 and host1-priv2. It is not necessary to follow such a host name convention. The names must be manually entered in the /etc/inet/host file and you must create /etc/hostname.be[01] files on each server.
• If additional public networks are used, you must create a secondary host name for each server and for each of the logical hosts for each such network. For example, if you are setting up a symmetric configuration with four public networks you will need to assign 20 host names and IP addresses for the Solstice HA configuration. This includes two physical host names and two logical host names for each network. In addition you will need four host names and IP addresses for the private networks.
• If you change the host name of a machines with existing disksets, the Solstice DiskSuite configuration (all your data) will become inaccessible.

3.1.3 Data Services

Planning a configuration requires deciding which data services to run. The two types of data services supported are HA-NFS and HA-DBMS.

Some points to consider when deciding which data services to use are:

• Both of these services can be run on the same configuration.
• HA-NFS provides highly available NFS file service. This means the failure of one of the systems in a configuration causes the HA-NFS client to experience a brief delay while the takeover is in progress.
• HA-DBMS provides highly available DBMS service. Currently HA-ORACLE is the only supported HA-DBMS. HA-ORACLE client applications experience a database recovery interruption in the service during either switchover or takeover. Because database transactions are "stateful," the client applications may need to re-establish the state of their transactions after either a switchover or takeover.

3.1.4 Planning Your Disk Requirements

You should add up the amount of data that you want to move to the Solstice HA configuration. Double that amount to allow space for mirroring. You may also want to consider growth and hot spare capacity.

Some points to consider when planning the amount of data are:

• When you are calculating the amount of data to migrate to Solstice HA, you should keep in mind the sizes of disks available for the SPARCstorage Arrays (currently, 1.05 Gbytes and 2.1 Gbytes). If the file systems or table spaces you are moving do not fit evenly on these disks, you should plan to use an extra disk and concatenate the slices with Solstice DiskSuite.
• Under some circumstances, there may be an advantage to merging several smaller file systems into a single larger file system. This will reduce the number of file systems to administer and may help speed up takeovers if one of the hosts fails.
• The size of the dump media (backup system) may influence the size of the file systems in Solstice HA configurations.

3.1.5 Mirroring

All multi-host disks must be mirrored in Solstice HA configurations. This enables the configuration to tolerate single-component failures.

Some points to consider when mirroring multi-host disks are:

• Each submirror must be in a different SPARCstorage Array.
• With two-way mirroring, the amount of disk space needed will double.
• Three-way mirroring is supported by Solstice DiskSuite. However only two-way mirroring is required for Solstice HA. If you perform three-way mirroring, the amount of disk space required will triple.
• Under Solstice DiskSuite mirrors are made up of other metadevices such as concatenations or stripes. In large configurations there may be a large number of metadevices. For example, seven metadevices are created for each logging UFS file system. Refer to the SPARCcluster High Availability Software Administration Guide for additional information about accommodating the large number of metadevices you may have.
• If you mirror metadevices of a different size, your mirror capacity will only be the size of the smallest submirror.
• When a new device is added to an existing diskset, another device of the same size must be added to mirror the data.

For additional information about mirroring, refer to the Solstice DiskSuite 4.0 Administration Guide.

3.1.6 Trans Devices

Trans devices are composed of a UFS log and a UFS master. Under Solstice HA both the log and master must be mirrored. The mirrors should be constructed following the mirroring guidelines given in Section 3.1.5, "Mirroring."

Some points to consider about trans devices are:

• Because the log and master devices often perform I/O at the same time, you would want to place them on separate drives in order to minimize the disk seek activity.
• Logs should reserve one Mbyte of space for every 100 Mbytes of the trans master device space.

3.1.7 Hot Spares

Solstice DiskSuite's hot spare facility automatically replaces failed submirror components, provided that a suitable spare component is available and reserved. Hot spares are temporary fixes, allowing you to schedule a time when the systems are less busy to perform maintenance on the failed component.

Some points to consider when planning for hot spares are:

• If you are going to use hot spares, at least one should be assigned to each diskset.
• Hot spares are useful for assuring the availability of critical data.
• New devices can be added to an existing diskset at any time to be used as hot spares.
• When deciding on the location of hot spares you must consider whether you are attempting to protect your data from media, tray, system board, or SPARCstorage Array failure.

For additional information about hot spares, refer to the Solstice DiskSuite 4.0 Administration Guide.

3.1.8 Disk Space Growth

When planning your data needs when moving to the Solstice HA platform, you may want to consider growth.

Some points to consider when planning for growth are:

• It will require less administration time to add disks during initial configuration than when the system is in service.
• You may want to leave empty slots in the SPARCstorage Arrays during initial configuration. This will allow the addition of disks later. If additional slots are not available, you may be in a situation where you must move SPARCstorage Arrays or reconfigure all the metadevices.
• When your site needs additional SPARCstorage Arrays, you may have to reconfigure your data to prevent mirroring within a single SPARCstorage Array chassis. The easiest way to add SPARCstorage Arrays without reorganizing data is to add them in pairs, if you are in a situation where all the existing SPARCstorage Array chassis are full.

3.1.9 Total Storage Requirement

To calculate the total storage requirement for Solstice HA you should compute the amount of existing data that you are migrating. That number must be multiplied by two for mirroring.

Some points to consider when calculating the total storage requirement are:

• A small fraction of each disk will be used by Solstice DiskSuite for metadevice state database replicas and for UFS logging. Typically this is less than 10 to 20 Mbytes per disk. The UFS logging space will only be necessary if you are creating UNIX file systems.
• The number of hot spares that will be used in each diskset counts towards the total amount of storage required.
• You must round up on a per file system basis. For example, if you have four file systems that contain three Gbytes each, you will need two 2.1 Gbyte drives for each file system, or a total of 16 Gbytes, eight 2.1 Gbyte drives. If you simply add the amount of file system space, you would conclude incorrectly that only 12 Gbytes of disk space, or six drives are needed.
• To simplify administration, use the default disk slicing performed by hasetup(1M). The default slicing gives you a single large slice in addition to small slices for a metadevice state database and a UFS log. While you can repartition the disk to create additional smaller slices, you may find the administrative overhead of tracking the partition tables and metadevices time consuming.

3.1.10 Size and Number of Disk Drives

Two sizes of disks are supported in SPARCstorage Arrays: 1.05 Gbyte and 2.1 Gbyte. Calculate the number of drives needed by dividing the total amount of storage required by the size of disk selected.

Some points to consider when deciding which size drives to use are:

• If you use lower capacity drives you can have more spindles, which increases potential I/O bandwidth. This assumes the disks have the same I/O rates.
• Using higher capacity disks means fewer devices are required in the configuration, which can help speed up takeovers. This is because takeover time is dependent on the number of drives being taken over.

• Using higher capacity disks can also reduce the chances of a disk failure, because fewer drives translates to lower aggregate failure rate.
• You should keep in mind that during configuration, space may automatically be allocated on the multi-host disks for Solstice DiskSuite metadevice state database replicas and at your option for possible UFS logs. These disk slices are very small, roughly a few Mbytes.
• To determine the number of disks needed, the total disk capacity you have selected is divided by the disk size. For example, if you need 40 Gbytes of total multi-host data storage, you would use 20 2.1-Gbyte disks.

3.1.11 Number of SPARCstorage Arrays

The minimum number of SPARCstorage Arrays required in a Solstice HA configuration is three. This minimum configuration means three sets of metadevice state database replicas are available to protect the configuration information in the event one SPARCstorage Array fails.

Some points to consider when deciding how many SPARCstorage Arrays to use are:

• When additional SPARCstorage Arrays are in a configuration, administration flexibility is available when one of the arrays fails.
• It is recommended the disks placed in the SPARCstorage Arrays be divided evenly between chassis, trays, and buses within the trays.
• Future growth of the multi-host data is easier to perform if there are empty slots in the SPARCstorage Arrays. You may want to consider planning the number of SPARCstorage Arrays so that growth can easily be accommodated.

3.1.12 Size of Servers

After you have decided the data services, number and size of each instance of data to be exported by the data service type, and the amount of data to be stored on the local and multi-host disks, selection of the hardware platform becomes easy.

Some points to consider when deciding which size servers should be used are:

• SPARCserver 1000s can be used if the configuration includes three to eight SPARCstorage Arrays. Otherwise, use SPARCcenter 2000s, which can have up to 20 SPARCstorage Arrays attached.
• Determining whether to use two SPARCserver 1000 or two SPARCcenter 2000 configurations will depend on your requirements for SPARCstorage Array storage, CPU cycles, memory, and other site-specific needs. The following table shows the physical limits and some other factors to consider.

Table 3-4

Components	SPARCserver 1000 Minimum	SPARCserver 1000 Maximum	SPARCcenter 2000 Minimum	SPARCcenter 2000 Maximum	Notes
System Boards	2	4	3	10
CPUs	4	8	6	20	Maximum of 2 per System Board
Memory	128 Mbytes	2 Gbytes	256 Mbytes	5 Gbytes	512 Mbytes maximum per System Board
SBus Slots	6	12	12	40	See Note 1
SPARCstorage Arrays	3	8	3	20	See Note 2
Storage Capacity					See Note 3
- Number of Disks	14	240	20	600	30 per SPARCstorage Array
- 1.05 Gbyte Disks	14.7 Gbytes	252 Gbytes	21 Gbytes	630 Gbytes
- 2.1 Gbyte Disks	29.4 Gbytes	504 Gbytes	42 Gbytes	1.26 Tbytes

Note 1 - Each server requires two SunFastEtherent SBus cards to be installed for the private networks. The SPARCcenter 2000-based configurations also require two FSBE/S cards to be installed on each server for the private disks, tape drives, and CD-ROM drives, along with at least one SBus card for the client network. Depending on your client network needs, you may require additional client network interfaces.

Note 2 - Each SPARCstorage Array uses one SBus slot on each server. Each FC/S SBus card only supports a single FC/OM in Solstice HA configurations. You must calculate these SBus cards into the total SBus slot requirement.

Note 3 - The storage capacity minimum for the SPARCserver 1000 is 14 disks. The minimum for the SPARCcenter 2000 is 20 disks, Availability is improved if the disks are divided as evenly as possible across the three SPARCstorage Arrays.

---

Note - The maximums of 240 disks in the SPARCserver 1000 and 600 disks in the SPARCcenter 2000 configurations are based on fully-populated SPARCstorage Arrays. This may not be suitable for your needs from a SCSI bus loading perspective.

---

3.1.13 Power Sources and Location for Configurations

You must decide what kind of power sources will be used to provide power to the servers and SPARCstorage Arrays. You may choose to use an uninterruptable power supply (UPS). If the power system at your site is reliable you may not need to take precautions.

Highest availability will be obtained if the key components of the HA system have independent power sources. For this discussion, independent power sources means that power failure of one source will not cause power failure in another source. For example, multiple UPS systems will have independent power failures since they have no critical component in common. Separate branch circuits are typically not independent since they share a common main circuit breaker somewhere along the way.

You might want to use multiple UPS systems to protect your system against failures in any one UPS. Those with lower availability requirements may find one UPS satisfactory. Those unconcerned with power failures may find commercial power acceptable.

The requirement for ongoing system operation in light of partial power failure is that at least one processor and a majority of the disk drives survive the partial power failure. This is most easily done by ensuring that power to each

processor is from an independent source and that power to the SPARCstorage Arrays is such that a majority of the drives survive failure of one power source. Three power sources are sufficient for the typical Solstice HA configuration.

• The first for a server and one SPARCstorage Array.
• The second for the other server and another SPARCstorage Array.
• The third for the last SPARCstorage Array.

Additional SPARCstorage Arrays should be distributed evenly across the three power sources or additional independent power can be supplied.

The two processors are each attached to separate power sources while the three SPARCstorage Arrays are also attached to separate power sources (it is acceptable for one storage array and one processor to share a power source). Configurations with more than three SPARCstorage Arrays can attach them to the three power sources in turn, keeping the distribution even so no single power source controls half or more of the disks. This ensures a majority of the disks will survive partial power failure, which is important because of the availability of the metadevice state database replicas.

Now if these sources are truly independent it should be unlikely that more than one of them should fail. However, in the unlikely event that all power sources fail it is difficult to control the sequence in which power is restored. Lacking this control it is possible for the processors to boot before the SPARCstorage Arrays and so be unable to access the disks. In this case the processor must reboot to access the disks. In some rare circumstances the processors may be unable to obtain access to the disks and manual intervention may be required.

Some points to consider when deciding the location are:

• The two Solstice HA servers can be located a maximum of 100 meters apart.
• You may want to separate the servers and connect them to different power sources.
• You may want to separate the servers so they are not both located under the same sprinkler system zone (if you have more than one computer room or more than one sprinkler zone).
• You may want to separate the servers into different air conditioning cooling zones (if you have more than one computer room or more than one cooling zone).

3.1.14 Type of Configuration

Solstice HA allows configurations to be either symmetric or asymmetric. In the symmetric configuration, each system masters one of the two disksets and makes one or more data services available from that diskset. In the event of a failure, the remaining system takes control of both disksets and provides all the data services.

In an asymmetric configuration there is only one diskset and all data services run from that diskset on only one of the hosts. The second host is a hot standby that is ready to assume control of the diskset and provide the data services in the event of a failure.

Some points to consider when deciding whether to have a symmetric or asymmetric configuration are:

• In an asymmetric configuration, one host will be idle until the other host goes down and a failover occurs.
• An asymmetric configuration is more likely to avoid an overload after a switchover.
• In a symmetric configuration, both hosts are actively providing data services until a failure of one of the systems occurs.
• In a symmetric configuration you may experience overload of a server following a failover. You must plan and monitor usage to avoid an overload.

3.1.15 Data on Local Disks

Each of the Solstice HA systems must have the same software available on the local disks. This includes the Solaris operating environment, all Solstice HA software, all Solstice DiskSuite software and all ORACLE software if you are running HA-DBMS.

Some points to consider when planning for data on the local disks are:

• If you have sufficient disk space, you can optionally mirror the data on the local disks. However mirroring the local disks may decrease availability because you are not mirroring across controllers. The mirroring is not necessary because the local data is replicated on the local disks of the two servers in the Solstice HA configuration.

• During installation of the Solaris operating environment you will be instructed to leave adequate space for three Solstice DiskSuite metadevice state database replicas and for a UFS file system log. Sun recommends you use Slice 4 of the boot disk for the three replicas. See Chapter 5, "Solaris 2.4 Installation" for instructions on setting up the metadevice state database replicas.
• The root slice (/) of the local disk must be large enough to accommodate the Solaris 2.4 system components that reside in root along with any components of any additional software packages that are installed. The root slice must also have enough inodes for the various files and directories as well as the device inodes in /devices and symbolic links in /dev. Refer to Section 5.2, "Selecting the Size of the Root Slice," on page 5-2 for detailed information about the size of the root slice.
• Solstice HA is supported only on the Solaris 2.4 Hardware Release 395 operating system. It will not run on earlier or later versions of Solaris.

3.1.16 Planning Your Multi-host File System Hierarchy

Regardless of whether you are running HA-ORACLE or HA-NFS you are required to have multi-host UNIX file systems. These file systems must be mirrored file systems set up with UFS logging. This will affect your metadevice configuration.

You must design a hierarchy of mount points for these file systems. These will be entered in the /etc/opt/SUNWhadf/hadf/vfstab.logicalhost file. Refer to Section 10.3, "Setting Up HA-NFS," on page 10-10 for detailed instructions.

Solstice HA conventions require that a small file system be created and mounted on /logicalhost. The size this file system is a minimum of 10 Mbytes. This file system will contain the directory named statmon.

Some points to consider when planning your multi-host file system layout are:

• The file system that contains /logicalhost/statmon cannot be grown.
• You must create mount points (file systems) other multi-host file systems at the /logicalhost level. You can grow these file systems using the Solstice DiskSuite growfs(1M) command.

• Your application may dictate a file system hierarchy and naming convention. Solstice HA has no restrictions about the file system naming, provided it begins with /logicalhost and it does not conflict with the /logicalhost/statmon directory.

3.1.17 File System Size and Disk Layout

After deciding on data services, you must decide the number and size of each instance of these types. For example, if you decide to run only HA-NFS, you must determine the number and size of the file systems that will be exported.

If you plan to use the Solstice HA configuration for existing data that is not mirrored, you will need twice the amount of currently used disk space. If the data is already mirrored, the space required is approximately equal. The DiskSuite requirement for metadevice state database replicas and for UNIX file system (UFS) logging is about one percent of each of the multi-host disks.

Ideally, the load on each diskset in a symmetric Solstice HA configuration should be balanced. The data services should be balanced on each of the disksets. This makes configuration easier and the performance of each system would be similar. Balancing the load may not be possible at every site.

Some points to consider when deciding on file system size and disk layout are:

• Ideally, the minimum file system size is the size of the disk. This will make general administration and Solstice DiskSuite administration easier and will allow greater flexibility in meeting space requirements for users.
• If you share UFS logs among several file systems, keep in mind that if a UFS panic or a log I/O problem occurs each of the file systems that are sharing the log must be checked by fsck(1M) before a takeover can be completed.

3.1.18 Size of Disksets

During initial configuration, the hasetup command automatically attempts to place the same number of disks in each diskset of a symmetric configuration.

The following example helps to explain the process you should use to determine the number of disks to place in each diskset. In this example there are existing applications running over NFS (two file systems of five Gbytes each) and several ORACLE databases (one five Gbytes and one 10 Gbytes).

Table 3-5

Use	Data	Disk Storage Needed	Drives Needed
nfs1	5 Gbytes	3x2.1 Gbyte disks * 2 (Mirror)	6
nfs2	5 Gbytes	3x2.1 Gbyte disks * 2 (Mirror)	6
oracle1	5 Gbytes	3x2.1 Gbyte disks * 2 (Mirror)	6
oracle2	10 Gbytes	5x2.1 Gbyte disks * 2 (Mirror)	10

Table 3-5 shows the calculations used to determine the number of drives needed in the example configuration. The number needed is 28, which would be divided as evenly as possible among each of the three SPARCstorage Arrays. Note that the five Gbyte file systems were given an additional Gbyte of disk space because the number of disks needed was rounded up.

Each of the HA-NFS file systems and the HA-ORACLE databases will be placed on separate servers. This is because of the processing power necessary for the applications, the correlation in time of access (I/O), and possibly other site-specific factors. Because the two servers are made up of identical hardware, it may be beneficial to balance the loads evenly between the servers.

Table 3-6

Logical host (diskset)	Data Services	Disks	SPARCstorage Array 1	SPARCstorage Array 2	SPARCstorage Array 3
logicalhost1	nfs1/oracle1	12	4	4	4
logicalhost2	nfs2/oracle2	16	5	6	5

Initially, four disks on each SPARCstorage Array will be assigned to logicalhost1 and five or six disks on each will be assigned to logicalhost2. The four disks in logicalhost1 will be distributed evenly across the three trays (and six buses) in the SPARCstorage Arrays. Similarly, the five or six drives will be spread across the six buses of each tray (using slots 2 and 7 of each tray and slot 3 of tray 1 and 2. This distribution gives the

maximum number of buses for each diskset. In Figure 3-2 the disk allocation is illustrated, as the disks are labeled with the name of the diskset (1 for logicalhost1 and 2 for logicalhost2.)

Figure 3-2

No hot spares have been assigned to either diskset. A minimum of one hot spare for each diskset would allow one drive to be hot spared (restoring full two-way mirroring). However, there would be a short interval of one-way mirroring on at least some data when a tray is pulled from the SPARCstorage Array to make a repair. Larger configurations that use additional SPARCstorage Arrays might allow a tray to contain drives for only one diskset. This would provide a better opportunity to use hot spares.

A point to consider when deciding the size of disksets is:

• In an asymmetric configuration there is only one diskset. All multi-host disks will be placed in the single diskset.

3.1.19 Metadevice Naming and Creation

It is important to determine the number of metadevice names needed for your configuration before setting up the configuration because if the number needed exceeds 128 you must edit the /kernel/drv/md.conf file.

Changes to the /kernel/drv/md.conf file do not take affect until a reconfiguration reboot is performed. The md.conf files on each server must be identical.

---

Note - The Solstice DiskSuite 4.0 Administration Guide tells you the only modifiable field in the /kernel/drv/md.conf file is the nmd field. You can also modify the md_nsets field from 4 to 3.

---

To calculate the number of metadevice names needed, determine the larger of the number of metadevice names to be used in either diskset (do not add the requirements of the disksets).

If you follow the naming convention suggested "Managing the Metadevice Name Space" on page 9-6, you should allocate 10 metadevice names per UFS logging file system. Do not forget the small file system mounted on /logicalhost. If you are using raw mirrored metadevices (for example, for HA-ORACLE), you should allocated 10 metadevice names per three mirrored devices.

You should set nmd in /kernel/drv/md.conf to the larger of either diskset. If you modify md.conf you should also set md_nsets to 3 (rather than the default 4, Solstice HA uses at most 3 disksets, the local set and two multi-host disksets). This will help conserve on inodes in the root file system (and so the space that must be allocated in the root file system). If you are going to change the nmd value, it should be raised in factors of two (that is, 128, 256, 512, or 1024).

These values will be used to help determine the size of your root file system. SeeTable 5-4 for a list of the root file system sizes.

Some points to consider when naming and creating metadevices include:

• You must read and use all information in Chapter 12 of the Solstice DiskSuite 4.0 Administration Guide. This chapter covers all the configuration guidelines and considerations for performance, availability, capacity, security, and compatibility.
• Metadevices can be created using either the Solstice DiskSuite commands or the Solstice DiskSuite Tool graphical user interface, metatool(1M). The metatool has certain limitations which are documented in the Solstice DiskSuite Tool 4.0 User's Guide.

3.1.20 Migrating Existing Data

During initial configuration, the hasetup command will optionally repartition all drives. All data on the drives will be lost. Thus, you cannot simply move data into the Solstice HA configuration by connecting existing disks that contain data.

A point to consider when planning to move existing data to the multi-host disks is:

• You can use ufsdump(1M) and ufsrestore(1M) to migrate data to Solstice HA servers.
• When migrating ORACLE databases to a Solstice HA configuration, use the method recommended by ORACLE.

3.1.21 Backing Up Multi-host Data

Before loading data on the multi-host disks in a Solstice HA configuration you should have a plan in place for backing up the data. Sun recommends you use Solstice Backup or ufsdump and ufsrestore to backup your SPARCcluster High Availability configuration.

A point to consider when planning a strategy for backup of multi-host data is:

• If you are converting your backup method from Online: Backup^(TM) to Solstice Backup^(TM), special considerations exist because there is no interoperability between the products. The primary decision for the system administrator is whether or not the files backed up with Online: Backup will be available online after Solstice Backup is in use. Refer to the Solstice Backup 4.1.2 Administration Guide for additional details about conversion.

3.2 Configuration Rules That Improve Reliability

The rules discussed in this section help ensure that your Solstice HA configuration is highly available. These rules also help determine what number of disks and controllers are appropriate for your configuration.

• The two systems must have identical local hardware. This means if one SPARCserver 1000 is configured with two local disks, the sibling SPARCserver 1000 must also have two local disks.
• Multi-host disks must be connected identically on the two servers.

• The two systems must have identical network interface configurations. That means the systems must have the same number and type of private and public network connections. For example, if one node in your configuration has two SunFastEthernet Adapter cards, the sibling systems must have the same.
• At least three SPARCstorage Arrays are required to build a highly available system. That means each of the servers in the configuration must have enough system boards and Fibre Channel SBus cards installed to support a minimum of three multi-host SPARCstorage Arrays.
• In a configuration that has more than three SPARCstorage Arrays, the metadevice state database replicas will be distributed among the multi-host disk strings so that half of the replicas plus one are accessible when a single hardware failure occurs (for example, disk, controller, power supply, or cable).

---

Note - During initial configuration, metadevice state database replicas are automatically placed on multi-host disks by the hasetup command. Placement of replicas on the local boot disks is a manual procedure.

---

• Do not mirror the root (/), swap, /usr, /var, or /opt file systems, which reside on local disks. The second server in the configuration acts as a replication for the data on these file systems. Other file systems that reside on local disks and contain important data can be mirrored.
• The /usr, /var, and /opt file systems can be logged to improve boot performance.
• At least two local disks must be attached to each system. One disk will be used for the Solaris 2.4 distribution, Solstice HA, and Solstice DiskSuite. The second local disk can be used for the ORACLE software distribution. The boot disk must also have three metadevice state database replicas.

• You must have the same number of multi-host Fibre Channel SBus cards attached to each system in the Solstice HA configuration. You must also ensure that the Fibre Channel SBus cards are cabled symmetrically.

• You must have two private networks. Interfaces be0 and be1 are reserved for these private network interfaces. During initial configuration, the hasetup command will look for be0 and be1.

3.3 Configuration Restrictions

The following are not supported in Solstice HA configurations:

• Do not configure the Solstice HA servers as mail servers, because sendmail(1M) is not supported in a Solstice HA environment. No mail directories should reside on Solstice HA servers.
• Do not configure Solstice AutoClient^(TM) or diskless clients that are served by Solstice HA servers (that is, the directory for diskless clients should not exist on Solstice HA systems).
• Do not configure Solstice HA systems as routers (gateways). If the system goes down, the clients cannot find an alternate router and recover.
• Do not configure Solstice HA systems as NIS or NIS+ servers. Solstice HA servers can be NIS or NIS+ clients.
• On Solstice HA systems, users should not locally access Solstice HA file systems that are NFS exported. The reason for this restriction is:

  · Local locking interferes with the ability to kill(1M) and restart lockd(1M). Between the kill and the restart, a blocked local process would be granted the lock, which prevents the client machine that owns that lock from reclaiming it.

• Solstice HA does not support either Secure NFS or Kerberos.
• Do not run any applications on either server that access the HA-NFS file systems.
• The file system containing the Solstice HA /logicalhost/statmon directory cannot be grown using the DiskSuite growfs(1M) command. Refer to "Planning Your Multi-host File System Hierarchy" on page 3-18 for additional information.
• The network time protocol (NTP), which is not shipped by Sun Microsystems, cannot be run on Solstice HA systems.
• A Solstice HA configuration cannot be used to provide a highly available boot or install service to client systems.
• A diskset must have disks in each of the three SPARCstorage Arrays. No SPARCstorage Array can contain 50 percent or greater of the disks in a diskset.
• File system quotas are not supported.

• Solstice HA does not support the use of the loopback file system (lofs) on the Solstice HA servers.
• Since Solstice HA requires mirroring, the RAID 5 feature in the Solstice DiskSuite product is not supported.
• The SPARCstorage Array NVRAM feature is not supported in Solstice HA configurations.
• HA-NFS requires that all NFS client mounts be "hard" mounts.
• Because Solstice DiskSuite does not support Sun Prestoserve^(TM), it cannot be used in a Solstice HA configuration.