Overview of the Example

This example shows how to take advantage of DiskSuite features that provide higher availability, greater capacity, and improved performance.

• Higher availability - In the example, mirroring ensures data will remain available even if a system board, controller, or disk drive fails. UFS logging significantly shortens the time the data is unavailable after scheduled downtime, a system crash, or a power failure.
• Greater capacity - Concatenation of disks, RAID, and striping increase capacity and ease the administrative load by combining many disks into a few large metadevices.

• Improved performance - UFS logging (trans devices) helps performance by decreasing the number of synchronous disk writes. Striping aids performance by automatically spreading the disk traffic across multiple disks.

The example uses the following:

• Software

  · The Solaris 2.x distribution

  · Third-party packages

  · DiskSuite and DiskSuite Tool packages

• File Systems

  · One Gbyte of system data and third-party packages

  · Four Gbytes of user data

• Databases

  · Four Gbytes of read-write data

  · Six Gbytes of read-mostly data

• Hardware (see Figure A-1)

  · One SPARCserver 1000^(TM) (with two internal 535-Mbyte disks and four system boards)

  · Three Disk Tower 1000s (each with 16 535-Mbyte disks)

The example uses the following functionality from DiskSuite:

• Metadevice state database replicas
• Concatenations
• Stripes
• Mirrors
• RAID
• UFS logging
• Hot spares

Figure A-1 illustrates the hardware configuration.

Figure A-1

Planning for Availability

The key to the DiskSuite type of availability is the replication or mirroring of data so that no one piece of hardware stands between the application's referencing the data and the media that contains the data.

When planning the configuration, availability of the data is achieved by:

• Disk drive availability - achieved by setting up mirrors across different disk drives.
• Controller availability - achieved by setting up mirrors across different controllers.
• System board availability - achieved by setting up mirrors across controllers on different system boards.

The hierarchy representation of the hardware shown in Figure A-2 helps illustrate the best availability when planning mirrors. An example use of the illustration would be to find a disk to mirror the data on c4t0. Selecting any other disk on any controller will ensure the data is available in the event of a single disk failure. But if you want the data available in the event of a controller failure, select a disk not connected to controller c4.Figure A-2 shows that any disk connected to the other controllers would keep the data available in the event of a disk or controller failure. Mirroring across system boards would further maximize data availability in this configuration. Because

c4 is connected to the second system board, selecting a disk attached to a different system board keeps the data available in the event of a system board, controller, or disk failure.

Figure A-2

Planning the Layout of the Data

The following steps are used to plan the layout of the configuration:

1. Plan the location of Solaris 2.x and the third-party software.

   The two internal 535-Mbyte disks, c0t0 and c0t1, will be used for the Solaris 2.x distribution, third-party software, and DiskSuite packages.

   To provide greater availability, the two internal disks will be mirrored. The mirrors should be to disks on a different controller and, if possible, a different system board. Disks c12t0 and c12t1 were selected.

To further help availability, a 16-Mbyte slice will be reserved on one of the local disks for a UFS log. The /usr and /opt file system will share this log. Like the disks, the log will be mirrored. The log will be 16 Mbytes rather than the recommended minimum of one Mbyte because larger logs help performance on heavily used file systems. But the larger log will take a little longer to scan during reboot, perhaps as long as eight seconds. The log will be mirrored to help ensure availability.

2. Plan the location of the other file systems and databases.

   The 535-Mbyte disks in the Disk Tower 1000s are too small to hold any one of the databases or file systems. Concatenation, striping and RAID devices will be used to create metadevices that are large enough to hold the data.

   The file system that contains four Gbytes of user data will be a concatenation. To increase performance, the concatenation will be spread across as many controllers as possible. All t0 and t1 disks on controllers c4, c5, c6, and c7 will be used. Additionally, the data will be mirrored to disks attached to different controllers. In this case, all t0 and t1 disks on c8, c9, c10, and c11 will be used as mirrors.

   To increase availability by speeding system reboots, the file system will be logged. A 64-Mbyte slice will be allocated on c8t0 for the log, rather than the recommended maximum of eight Mbytes because larger logs help performance on heavily used file systems. However, the larger log may slow reboots by as much as 24 seconds, while the log is scanned. The log will be mirrored to help ensure availability.

   The 4-Gbyte read-write database will be striped to enhance performance. The data will be located on all t2 and t3 disks on controllers c4, c5, c6, and c7. To increase availability, the data will be mirrored to all t2 and t3 disks on controllers c8, c9, c10, and c11.

   In this example, there is not enough disk space to mirror the 6-Gbyte read-mostly database. A mirror is preferable because it provides greater availability and has better write performance than a RAID device. However, due to space and cost constraints, creating a large RAID device is a viable alternative. A RAID device provides better availability than a simple concatenation or stripe. All the disks on controllers c1, c2, and c3 will be used for the 6-Gbyte, read-mostly database. (It's important to keep in mind that the actual usable size of the RAID device will be only 5 1/2 Gbytes because the equivalent of one disk's worth of space is used for parity.)

3. Plan the location of hot spares.

   The use of hot spares makes all the mirrors and the RAID device more available. Disks c12t2 and c12t3 will be used as hot spares.

4. Plan the location of metadevice state database replicas.

   A minimum of three metadevice state database replicas are required in Solstice DiskSuite configurations. This ensures the necessary two replicas will be available in the event of a single replica failure. Because a failure could occur because of a disk, controller, or system board failure, replicas will be placed on disks attached to three different system boards to help ensure availability.

   The state database replicas will share the same slice as the UFS logs. Because the logs are spread across different system boards, the availability goals are met. The replicas will be placed on c0t0d0s7, c8t0d0s7, and c12t0d0s7.

Figure A-3 shows the layout of the data in the example configuration.

Figure A-3

Figure A-4 shows a hardware view of the data layout.

Figure A-4

Setting Up the Configuration Using DiskSuite Tool

To use DiskSuite Tool to set up the configuration shown in Figure A-4, perform the following steps:

1. Partition the slices.

   You should partition all slices before you start DiskSuite Tool. Use the format(1M) command to partition the disks.

Table A-1

Slice	Size (Mbytes)	Use
c0t0d0s0	14.49	root (/)
c0t0d0s1	32.27	swap
c0t0d0s3	126.33	/usr/openwin
c0t0d0s4	87.50	/var
c0t0d0s5	131.66	/opt
c0t0d0s6	99.80	/usr
c0t0d0s7	17.64	State database (2 Mbytes), UFS log (16 Mbytes)
c0t1d0s2	--	/usr/opt, contains third-party software
c1, c2, and c3	--	RAID metadevices, the entire disk is s2
c4t0d0s0	471	User data, mirror metadevices
c4t0d0s7	64	UFS log
c4t1, c4t2, c4t3,c5, c6, and c7	--	User data, mirror metadevices, the entire disk is formatted as s2.
c8t0d0s7	64	Mirror of UFS log
c8t0d0s6	2	State database
c8t1, c8t2, c8t3, c9, c10, and c11	--	User data, mirror metadevices, the entire disk is formatted as s2.
c12t1d0s2	535	Mirror for c0t1d0
c12t2 and c12t3	--	Hot Spares
c12t0	--	Slice so it can be used to mirror data on c0t0.

2. Start DiskSuite Tool.

   When the disks are partitioned you can start the DiskSuite Tool (metatool(1M)).

3. Create state database replicas.

   When DiskSuite Tool starts, a warning message dialog box will display. The message is telling you there are no metadevice state database replicas. Point to the OK button and click the left button.

   Use the instructions in the section "Creating the Initial State Database Replicas" on page 222 to create the state database replicas. The slices c0t0d0s7, c8t0d0s7, and c12t3d0s7 will be used for the state database replicas.

4. Create mirrors.

   You will first use the instructions in "Mirroring File Systems You Cannot Unmount" on page 110, to mirror the root (/), /usr, /opt, and swap file systems.

   The remaining mirrors can be built using the instructions in "Creating Mirrors" on page 95. The four-Gbyte read-write database will be striped. You would use the instructions in "Striped Metadevices" on page 68 to see how to stripe. The four-Gbyte mirror of user data is a concatenation. You would use the instructions in "Concatenated Metadevices" on page 63 to learn how to build concatenations.

5. Create RAID device.

   The six-Gbyte RAID device will be created using the instructions found in "Creating RAID Metadevices" on page 199.

6. Create UFS logging (Trans) devices.

   You are logging two separate file systems. The 16-Mbyte log is for the /usr and /opt file systems and a 64-Mbyte log is for the four Gbytes of user data. To log the /usr and /opt file systems and the four-Gbyte user data, you would use the instructions in "How to Set Up UFS Logging on an Existing File System" on page 146.

7. Create hot spare pools.

   To create the two hot spares using the c12t2d0 and c12t3d0 disks, use the instructions found in the section "Defining Hot Spares" on page 168.

8. Associate hot spare pools.

   To associate the two hot spares with all the mirrors and the RAID use the instructions found in the section "Associating Hot Spare Pools" on page 172. You must repeat the instructions for each of the mirrors and RAID devices in the configuration.

9. Setup databases on the RAID device and the mirror.

   Refer to the documentation that comes with the database product you are using. The RAID metadevice and mirror can be treated as any other device.

10. Run newfs(1M) on the file system that contains the user data. When all the metadevices and hot spares are created, you must invoke the newfs command on the file system that contains the user data. For example:

# newfs /dev/md/rdsk/dn

In the above example, dn is the metadevice name of the Trans device where the four Gbytes of user data will reside.

11. Edit /etc/vfstab file.

    Entries for the four Gbytes of mirrored user data must be made in the /etc/vfstab file. This entry will have the following format:

/dev/md/dsk/dn /dev/md/rdsk/dn /usr_data ufs 4 yes --

12. Export file systems.

    Any file systems or databases that will be shared across the network must be exported. For instance if you want to export /usr, you would put a line similar to the following into the /etc/dfs/dfstab file:

share -F nfs -d "/usr" /dev/md/dsk/dn

This line may be different, depending on how your system is networked.

You would then export the /usr file system with the shareall(1M) command:

# shareall