The Fei's Tech Notes: January 2012

Thursday, January 12, 2012

Updating ports in existing profiles

Use the updatePorts.ant script to change ports in an installed profile.

Before you begin

Each profile template has its own updatePorts.ant script.
The updatePorts.ant script for application server profiles is in the app_server_root/profileTemplates/template_name/actions directory. To use the script, you have to identify which profile to update.

Avoid trouble: You should only run this script if the profile is unfederated and if the configuration is the same structure as it was when the profile was created. For example, this script is ideal for changing ports for an unfederated application server profile after you created the profile but before you altered its configuration. For all other situations, use the techniques described in "Setting port numbers kept in the serverindex.xml file using scripting".gotcha

About this task

Use the following procedure to become familiar with using the updatePorts.ant script. Each step is an exercise that results in reassigning ports using a particular method that the updatePorts.ant script supports.
Look at steps for all of the operating systems mentioned. The differences are mainly in the extension of the script file and the direction of the directory delimiters. For example, Linux^® shell scripts (*.sh) and other commands require a ./ before the command to tell the operating system that the command is in the current working directory.

Procedure

Assign nonconflicting ports to the AppSrv01 profile. The ANT script assigns nonconflicting ports by default. No special arguments are needed. Identify the fully qualified directory paths, profile name, unique node name, and unique cell name. Then issue the command.
1. Create the Java properties file encoded in ISO8859-1 file encoding, to assign nonconflicting port values to the application server profile. For this example, assume that the system is a Linux operating system and that you create the following /TMP/was_props/appserver.props properties file.
```
WAS_HOME=/opt/IBM/WebSphere/AppServer 
was.install.root=/opt/IBM/WebSphere/AppServer
profileName=AppSrv01
profilePath=/opt/IBM/WebSphere/AppServer/profiles/AppSrv01
templatePath=/opt/IBM/WebSphere/AppServer/profileTemplates/default
nodeName=appserver_node01
cellName=appserver_cell01
hostName=myserver.ibm.com
```
2. Open a command shell window.
3. Change directories to the /opt/IBM/WebSphere/AppServer/bin directory.
```
cd /opt/IBM/WebSphere/AppServer/bin
```
  (Or, if the product is installed to a non-default directory, change directories to the app_server_root/bin directory.)
4. Issue the command.
```
./ws_ant.sh -propertyfile /TMP/was_props/appserver.props \
            -file /opt/IBM/WebSphere/AppServer/profileTemplates/default/actions/updatePorts.ant
```
5. Open the administrative console and view the changed port assignments. To view the port assignments, click Servers > Application servers > server_name > [Communications] Ports.
6. Run the script again and view the ports. Are they the same as before?
The resulting dynamically assigned port values apply to all of the ports currently assigned to the AppSrv01 profile, for every server listed in the serverindex.xml file for the profile node name. Each port receives a new nonconflicting value. None of the old port value assignments are used because the port values are in use at the time of the new assignment.
Assign default ports to the AppSrv02 profile. The ANT script assigns nonconflicting ports by default. The defaultPorts=true special argument is needed. Identify the fully qualified directory paths, profile name, unique node name, and unique cell name. Then issue the command.
1. Create the Java properties file encoded in ISO8859-1 file encoding, to assign default port values to the application server profile. For this example, assume that the system is a Windows^® operating system and that you create the following C:\temp\was_props\appserver.props properties file.
```
WAS_HOME="C:/Program Files/IBM/WebSphere/AppServer" 
was.install.root="C:/Program Files/IBM/WebSphere/AppServer"
profileName=AppSrv02
profilePath="C:/Program Files/IBM/WebSphere/AppServer/profiles/AppSrv02"
templatePath="C:/Program Files/IBM/WebSphere/AppServer/profileTemplates/default"
nodeName=appserver_node02
cellName=appserver_cell02
hostName=myserver2.ibm.com
defaultPorts=true
```
  Use double quotation marks around a Windows path name with spaces. Do not use quotation marks around the path name if there are no spaces in the path.
2. Open a DOS command window.
3. Change directories to the C:\Program Files\IBM\WebSphere\AppServer\bin directory.
```
cd "C:\Program Files\IBM\WebSphere\AppServer\bin"
```
  (Or, if the product is installed to a non-default directory, change directories to the app_server_root/bin directory.)
4. Issue the command.
```
ws_ant.bat -propertyfile C:\temp\was_props\appserver.props
 -file "C:\Program Files\IBM\WebSphere\AppServer\profileTemplates\default\actions\updatePorts.ant"
```
5. Open the administrative console and view the changed port assignments. To view the port assignments, click Servers > Application servers > server_name > [Communications] Ports.
6. Run the script again and view the ports. Are they the same as before?
The resulting assigned port values are the same each time because the values are the default values. This method does not resolve conflicting port assignments. To view all port assignments for a profile, see the C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv02\config\cells\appserver_cell02\nodes\appserver_node02\serverindex.xml file. Issue the netstat -a command to see all ports in use on the machine.
Assign ports starting at 2050 to the AppSrv03 profile. The ANT script assigns nonconflicting ports by default. The startingPort=2050 special argument is needed. Identify the fully qualified directory paths, profile name, unique node name, and unique cell name. Then issue the command.
1. Create the Java properties file encoded in ISO8859-1 file encoding, to assign default port values to the application server profile. For this example, assume that the system is an AIX^® operating system and that you create the following /usr/tmp/was_props/appserver.props properties file.
```
WAS_HOME=/usr/IBM/WebSphere/AppServer 
was.install.root=/usr/IBM/WebSphere/AppServer
profileName=AppSrv03
profilePath=/usr/IBM/WebSphere/AppServer/profiles/AppSrv03"
templatePath=/usr/IBM/WebSphere/AppServer/profileTemplates/default"
nodeName=appserver_node03
cellName=appserver_cell03
hostName=myserver3.ibm.com
startingPort=2050
```
2. Open a command shell window.
3. Change directories to the /usr/IBM/WebSphere/AppServer/bin directory.
```
cd /usr/IBM/WebSphere/AppServer/bin
```
  (Or, if the product is installed to a non-default directory, change directories to the app_server_root/bin directory.)
4. Issue the command.
```
./ws_ant.sh -propertyfile /usr/tmp/was_props/appserver.props \
            -file /usr/IBM/WebSphere/AppServer/profileTemplates/default/actions/updatePorts.ant
```
5. Open the administrative console and view the changed port assignments. To view the port assignments, click Servers > Application servers > server_name > [Communications] Ports.
6. Run the script again and view the ports. Are they the same as before?
After using the -startingPort option, the resulting dynamically assigned port values are not the same each time because the ANT script assigns nonconflicting port values starting from the startingPort number (port 2050 in this case). This method resolves conflicting port assignments.
Use a port definition property file to assign ports to the AppSrv04 profile. The ANT script assigns nonconflicting ports by default. The portsFile=/opt/was/portdefs.our_appsrv_ex.props special argument is needed. Identify the fully qualified directory paths, profile name, unique node name, and unique cell name. Then issue the command.
1. Create the Java properties file encoded in ISO8859-1 file encoding, to assign nonconflicting port values to the application server profile.
  Assume that you create the following /opt/was/portdefs.our_appsrv_ex.props properties file:
```
WC_defaulthost=19080
WC_adminhost=19060
WC_defaulthost_secure=19443
WC_adminhost_secure=19043
BOOTSTRAP_ADDRESS=22809
SOAP_CONNECTOR_ADDRESS=28880
IPC_CONNECTOR_ADDRESS=9633
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=29401
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=29403
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=29402
ORB_LISTENER_ADDRESS=39100
DCS_UNICAST_ADDRESS=39353
SIB_ENDPOINT_ADDRESS=37276
SIB_ENDPOINT_SECURE_ADDRESS=37286
SIB_MQ_ENDPOINT_ADDRESS=45558
SIB_MQ_ENDPOINT_SECURE_ADDRESS=45578
SIP_DEFAULTHOST=45060
SIP_DEFAULTHOST_SECURE=45061
```
  Note: The ports used in the port definition property file should reflect the template type. The ports in this example are for the default template type, and they might vary for other template types. The management template has three different portdef.props files, one for each servertype. They are adminagent.portdef.props, dmgr.portdef.props and jmgr.portdef.props. They can be modelled after the portdef.props file found in the template directory.
  Assume that you create the following /TMP/was_props/appserver.props properties file:
```
WAS_HOME=/opt/IBM/WebSphere/AppServer 
was.install.root=/opt/IBM/WebSphere/AppServer
profileName=AppSrv04
profilePath=/opt/IBM/WebSphere/AppServer/profiles/AppSrv04
templatePath=/opt/IBM/WebSphere/AppServer/profileTemplates/default
nodeName=appserver_node04
cellName=appserver_cell04
hostName=myserver4.ibm.com
portsFile=/opt/was/portdefs.our_appsrv_ex.props
```
2. Open a command shell window.
3. Change directories to the /opt/IBM/WebSphere/AppServer/bin directory.
```
cd /opt/IBM/WebSphere/AppServer/bin
```
  (Or, if the product is installed to a non-default directory, change directories to the app_server_root/bin directory.)
4. Issue the command.
```
./ws_ant.sh -propertyfile /TMP/was_props/appserver.props \
            -file /opt/IBM/WebSphere/AppServer/profileTemplates/default/actions/updatePorts.ant
```
5. Open the administrative console and view the changed port assignments. To view the port assignments, click Servers > Application servers > server_name > [Communications] Ports.
6. Run the script again and view the ports. Are they the same as before?
The resulting assigned port values are from a props file. Therefore, the values do not change. This method does not resolve conflicting port assignments.

Results

This procedure results in four different methods of port assignments with the updatePorts.ant script.

What to do next

You can change port values in a variety of ways. The install command and the silent installation response file also support setting port values in the same manner as described in this article. In fact, the two installation methods use the same options:

-OPT PROF_defaultPorts= No value is required. The equal sign is a standardization misnomer.
-OPT PROF_startingPort="nnnn"
-OPT PROF_portsFile="path_to_portsdef.props file"
If you omit one of the preceding arguments when calling the install command or leave one of the preceding arguments out of your silent response file, the default action is to assign nonconflicting port values.

The use of the exact same options for a graphical user interface installation and a silent installation is no coincidence. Most WebSphere^® Application Server component installation programs are implementations of the Common Install Engine for WebSphere Application Server. The use of the exact same actions for the ANT script is also because of the same pervading design theme, which is to simplify your installation experience.

Sunday, January 8, 2012

10 ways to build a solid capacity planning effort

#1: Start small

Many a capacity-planning effort fails after a few months because it encompassed too broad a scope too early on. This is especially true for shops that have had no previous experience in this area. It is wise to start with just a few of the most critical resources — say, processors or bandwidth — and to gradually expand the program as you gain more experience.

#2: Speak your customers’ language

When requesting workload forecasts from your developers and especially your end-user customers, discuss the forecasts in terms that the developers and customers understand. For example, rather than asking for estimated increases in processor utilization, ask how many additional concurrent users are expected to be using the application or how many of a specific type of transaction is likely to be executed during peak periods.

#3: Consider future platforms

When evaluating tools to be used for capacity planning, keep in mind new architectures that your shop may be considering and select packages that can be used on both current and future platforms. Some tools that appear well suited for your existing platforms may have little or no applicability to planned architectures. This consideration should extend not just to servers, but to disk arrays, tape equipment, desktop workstations, and network hardware.

#4: Share plans with suppliers

If you plan to use your capacity-planning products across multiple platforms, it is important to inform your software suppliers of your plans. During these discussions, make sure that add-on expenses — the costs for drivers, agents, installation time and labor, copies of licenses, updated maintenance agreements, and the like — are all identified and agreed upon up front. Reductions in the costs for license renewals and maintenance agreements can often be negotiated based on all of the other additional expenses.

#5: Anticipate nonlinear cost ratios

One of my esteemed college professors was fond of saying that indeed we live in a nonlinear world. This is certainly the case when it comes to capacity upgrades. Some upgrades will be linear in the sense that doubling the amount of a planned increase in processors, memory, channels, or disk volumes will double the cost of the upgrade. But if the upgrade approaches the maximum number of cards, chips, or slots that a device can hold, a relatively modest increase in capacity may end up costing an immodest amount for additional hardware. This is sometimes referred to as the knee of the curve, where the previous linear relationship between cost and capacity suddenly accelerates into exponential increases.

#6: Plan for occasional workload reductions

A forecasted change in workload may not always cause an increase in the capacity required. Departmental mergers, staff reductions, and productivity gains may result in some production workloads being reduced. Similarly, development workloads may decrease as major projects become deployed. Although increases in needed capacity are clearly more likely, reductions are possible. A good guideline to use when questioning users about future workloads is to emphasize changes, not just increases.

#7: Prepare for the turnover of personnel

One of the events that undermines a capacity-planning effort early on is to have the individual most responsible for, and most knowledgeable about, the overall program leave the company. Regardless of the preventative measures taken, there is no guarantee that attrition will not occur. But there are several actions that can mitigate the impact. One action to take is to carefully interview and select an individual who in your best judgment appears unlikely to leave your firm anytime soon. You should also ensure that the process is thoroughly documented. If resources are available, training a backup person is another way to mitigate turnover. Finally, in extreme cases, an employment contract may be used to sustain ongoing employment of a key individual.

#8: Strive to continually improve the process

One of the best ways to continually improve the effectiveness of the capacity-planning process is to set a goal to expand and improve at least one part of it with each new version of the plan. Possible enhancements could include the addition of new platforms, centralized printers, or remote locations. A new version of the plan should be created at least once a year and preferably every six months.

#9: Institute a formal capacity-planning program

Some shops initiate a capacity-planning program in a very informal manner to simply get something started. There is nothing wrong with this approach if the intent is merely to overcome inaction and to start the ball rolling. This can also help raise awareness of the need to evolve this initial effort into a formal capacity-planning program. The one major drawback to this method is that all too often shops that start out with this approach never progress beyond it. At some point soon after initiating a capacity-planning effort, a formal process needs to be put in place.

#10: Market the lesser-known benefits of capacity planning

In addition to being able to predict when, how much, and what type of additional hardware resources will be needed, a comprehensive capacity-planning program offers four lesser known benefits that should be marketed to infrastructure managers and IT executives. These benefits are:

Strengthened relationships with developers and end users. The process of identifying and meeting with key users to discuss anticipated workloads usually strengthens the relationships between IT infrastructure staff and customers. Communication, negotiation, and a sense of joint ownership can all combine to nurture a healthy, professional relationship between IT and its customers.
Improved communications with suppliers. Suppliers are generally like any other support group in that they do not enjoy last-minute surprises. Involving key suppliers and support staffs with your capacity plans can promote effective communications among these groups. It can also make their jobs easier in meeting deadlines, reducing costs, and offering additional alternatives for capacity upgrades.
Increased collaboration with other infrastructure groups. A comprehensive capacity plan by necessity will involve multiple support groups. Network services, technical support, database administration, operations, desktop support, and even facilities may all play a role in capacity planning. In order for the plan to be thorough and effective, all these various groups must support and collaborate with each other.
Promotion of a culture of strategic planning as opposed to tactical firefighting. By definition, capacity planning is a strategic activity. To do it properly, one must look forward and focus on the plans of the future instead of the problems of the present. One of the most significant benefits of developing an overall and ongoing capacity-planning program is the institutionalizing of a strategic-planning culture.

Friday, January 6, 2012

Solaris NIS configuration

Notes from /usr/lib/netsvc/yp/ypstart:

# When to start ypserv :
#       The value of $domain is non-null *and*
#       The directory /var/yp/$domain exists *and*
#       There is an executable ypserv in $YPDIR
#
# When to start ypbind :
#       The value of $domain is non-null *and*
#       There is an executable ypbind in $YPDIR *and*
#       The directory /var/yp/binding/$domain exists.

NIS client configuration

1. Run domainname to see if an NIS domainname is returned. If a value is not returned, run domainname NIS_domainname and create /etc/defaultdomain containing the name of the NIS domainname.

2. Create a directory named /var/yp/binding/`domainname` if one does not already exist.

3. If you want the NIS client to broadcast for a NIS server (note: there must be a NIS server on your subnet), start NIS with /usr/lib/netsvc/yp/ypstart. If you want to manually specify one or more NIS server(s) to use, run ypinit -c and then /usr/lib/netsvc/yp/ypstart. Note that each manually specified NIS server must have an entry in /etc/hosts.

4. Modify the name service switch file (/etc/nsswitch.conf) to use the NIS databases. You may want to copy /etc/nsswitch.nis over /etc/nsswitch.conf. Make sure to modify the "hosts:" line in /etc/nsswitch.conf if you want to use DNS for hostname resolution:

hosts: dns nis files

NIS slave configuration

1. Run /usr/sbin/ypinit -s NIS_master to transfer the NIS maps from the NIS master to the NIS slave. NIS_master must be present in /etc/hosts.

2. Edit /var/yp/binding/`domainname`/ypservers and add the hostname of the NIS slave to ensure that ypbind binds to the local host.

3. Stop and restart NIS services via /usr/lib/netsvc/yp/ypstop and /usr/lib/netsvc/yp/ypstart

Miscellaneous NIS notes

The NIS line length limit is 1024 characters.

Starting NIS:
/usr/lib/netsvc/yp/ypstart

Stopping NIS:
/usr/lib/netsvc/yp/ypstop

To stop NIS at system boot, remove the file /etc/defaultdomain.

NIS troubleshooting:
If NIS appears to hang when pushing maps from the NIS master to NIS slave servers, check the contents of /var/yp/ypxfr.log. "touch" the file if it is not created.

"Create clnt failure: RPC: Program not registered"
If you receive this error when attempting to change a user's password, the rpc.yppasswdd daemon is not running on the NIS master server. It is located in /usr/lib/netsvc/yp
More information: http://www.netsys.com/sunmgr/1998-08/msg00030.html

"passwd (NIS): Couldn't change passwd/attributes for user"
The rpc.yppasswdd daemon is probably running, but it is not pointing to the directory containing the NIS maps. By default, rpc.yppasswdd looks for NIS maps in /var/yp. If NIS maps are in /var/yp/maps, for example, use the following command to start rpc.yppasswdd:
/usr/lib/netsvc/yp/rpc.yppasswdd -D /var/yp/maps
More information:
http://aa11.cjb.net/sun_managers/2000/01/msg00160.html

"No response from ypxfr on host"
Check /var/yp/ypxfr.log. It is possible that the /var file system on the remote host is full.
Thu May 31 10:33:16: Transferred map ypservers from host (2 entries).
write: No space left on device

Maps are pushed from the master server to the slave servers via the make utility and the NIS Makefile located in /var/yp. Maps are pulled from the master server via the ypxfr utility.

Push maps from master server:
cd /var/yp
make

List NIS maps:
ypcat -x
-- or --
ypwhich -x

List of NIS servers:
ypcat ypservers

Which NIS server are you bound to?
ypwhich

Forcing ypbind to use a particular NIS server:
/usr/lib/netsvc/yp/ypbind -ypsetme
ypset NIS_server
ypwhich (to confirm NIS server)

Master and slave servers are distinguished by their ability to effect permanent changes to NIS maps. Changes may be made to an NIS map on a slave server, but the next map transfer from the master will overlay this change.

Thursday, January 5, 2012

Solaris Expanding a File System on the Fly using SVM

May 16, 2008 by sun4u

By Joseph Gan
A metadevice consists of one or more devices (slices). It can be expanded by adding slices. Then, it can be grown to fill a larger space while the file system is in use.
However, not all UNIX file systems (UFS) can be expanded this way. The concatenation is good only for small random I/O and for even I/O distribution. On the other hand, striping is advantageous for large sequential I/O and for uneven I/O distribution, because striping will increase performance by accessing data in parallel.
Note: If you wish to expand a file system to be a single striped metadevice, you can’t do it on the fly. You have to dismount the file system, then copy or “move” over to a new partition.

How to Expand a File System With a Single Stripe, On the Fly

First, the file system has to be created and mounted as a one-way mirror metadevice; as in this example, with d80 mounted by /opt:

# metastat d80
   d80: Mirror
       Submirror 0: d81
         State: Okay
       Pass: 1
       Read option: roundrobin (default)
       Write option: parallel (default)
       Size: 10261520 blocks

   d81: Submirror of d80
       State: Okay
       Size: 10261520 blocks
       Stripe 0: (interlace: 32 blocks)
           Device              Start Block  Dbase State        Hot Spare
           c1t12d0s0                  0     No    Okay
           c1t13d0s0               1520     No    Okay
           c1t14d0s0               1520     No    Okay
           c1t15d0s0               1520     No    Okay

Next, use the metattach command to dynamically concatenate a new slice, /dev/dsk/c0t1d0s1, to the end of the existing submirror of d80, d81:

# metattach d81 c0t1d0s1

   # metastat d80
   d80: Mirror
       Submirror 0: d81
         State: Okay
       Pass: 1
       Read option: roundrobin (default)
       Write option: parallel (default)
       Size: 10261520 blocks

   d81: Submirror of d80
       State: Okay
       Size: 10261520 blocks
       Stripe 0: (interlace: 32 blocks)
           Device              Start Block  Dbase State        Hot Spare
           c1t12d0s0                  0     No    Okay
           c1t13d0s0               1520     No    Okay
           c1t14d0s0               1520     No    Okay
           c1t15d0s0               1520     No    Okay
       Stripe 1:
           Device              Start Block  Dbase State        Hot Spare
           c0t1d0s1                   0     No    Okay

Then, use the growfs command to expand the mounted file system ( /opt) onto the raw metadevice /dev/md/rdsk/d80:

# growfs -M /opt /dev/md/rdsk/d80

/dev/md/rdsk/d80: 12336320 sectors in 8116 cylinders of 19 tracks,
   80 sectors
           6023.6MB in 129 cyl groups (63 c/g, 46.76MB/g, 5888 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
 32, 95872, 191712, 287552, 383392, 479232, 575072, 670912, 766752, 862592,
 958432, 1054272, 1150112, 1245952, 1341792, 1437632, 1533472, 1629312,
 1725152, 1820992, 1916832, 2012672, 2108512, 2204352, 2300192, 2396032,
 2491872, 2587712, 2683552, 2779392, 2875232, 2971072, 3064352, 3160192,
 3256032, 3351872, 3447712, 3543552, 3639392, 3735232, 3831072, 3926912,
 4022752, 4118592, 4214432, 4310272, 4406112, 4501952, 4597792, 4693632,
 4789472, 4885312, 4981152, 5076992, 5172832, 5268672, 5364512, 5460352,
 5556192, 5652032, 5747872, 5843712, 5939552, 6035392, 6128672, 6224512,
 6320352, 6416192, 6512032, 6607872, 6703712, 6799552, 6895392, 6991232,
 7087072, 7182912, 7278752, 7374592, 7470432, 7566272, 7662112, 7757952,
 7853792, 7949632, 8045472, 8141312, 8237152, 8332992, 8428832, 8524672,
 8620512, 8716352, 8812192, 8908032, 9003872, 9099712, 9192992, 9288832,
 9384672, 9480512, 9576352, 9672192, 9768032, 9863872, 9959712, 10055552,
 10151392, 10247232, 10343072, 10438912, 10534752, 10630592, 10726432,
 10822272, 10918112, 11013952, 11109792, 11205632, 11301472, 11397312,
 11493152, 11588992, 11684832, 11780672, 11876512, 11972352, 12068192,
 12164032, 12257312,

Now the file system (/opt) has been expanded dynamically, but it contains two stripes: stripe 0, which is the original one, and stripe 1, which is the expanded one.
The next step is to create a single stripe metadevice d82, which is the same size as the submirror d81.
In the following example, we create a stripe with three 2.1-Gbyte disks:

# metainit d82 1 3 c0t11d0s2 c0t12d0s2 c0t13d0s2
   d82: Concat/Stripe is setup

   # metastat d82
   d82: Concat/Stripe
       Size: 12457920 blocks
       Stripe 0: (interlace: 32 blocks)
           Device              Start Block  Dbase
           c0t11d0s2                  0     No
           c0t12d0s2               1520     No
           c0t13d0s2               1520     No

Then, add the metadevice d82 as the second submirror to d80, and resync will automatically take place:

# metattach d80 d82
   d80: submirror d82 is attached

   # metastat d80
   d80: Mirror
       Submirror 0: d81
         State: Okay
       Submirror 1: d82
         State: Resyncing
       Resync in progress: 20 % done
       Pass: 1
       Read option: roundrobin (default)
       Write option: parallel (default)
       Size: 12336320 blocks
   ......

After the resync is complete, we have the following two-way mirrors:

# metastat d80
   d80: Mirror
       Submirror 0: d81
         State: Okay
       Submirror 1: d82
         State: Okay
       Pass: 1
       Read option: roundrobin (default)
       Write option: parallel (default)
       Size: 12336320 blocks

   d81: Submirror of d80
       State: Okay
       Size: 12336320 blocks
       Stripe 0: (interlace: 32 blocks)
           Device              Start Block  Dbase State        Hot Spare
           c1t12d0s0                  0     No    Okay
           c1t13d0s0               1520     No    Okay
           c1t14d0s0               1520     No    Okay
           c1t15d0s0               1520     No    Okay
       Stripe 1:
           Device              Start Block  Dbase State        Hot Spare
           c0t1d0s1                   0     No    Okay

   d82: Submirror of d80
       State: Okay
       Size: 12336320 blocks
       Stripe 0: (interlace: 32 blocks)
           Device              Start Block  Dbase State        Hot Spare
           c0t11d0s2                  0     No    Okay
           c0t12d0s2               1520     No    Okay
           c0t13d0s2               1520     No    Okay

Finally, you can detach the submirror d81 from d80, and remove it completely:

# metadetach d80 d81
   # metaclear d81

   # metastat d80
   d80: Mirror
       Submirror 1: d82
         State: Okay
       Pass: 1
       Read option: roundrobin (default)
       Write option: parallel (default)
       Size: 12336320 blocks

   d82: Submirror of d80
       State: Okay
       Size: 12336320 blocks
       Stripe 0: (interlace: 32 blocks)
           Device              Start Block  Dbase State        Hot Spare
           c0t11d0s2                  0         No        Okay
           c0t12d0s2               1520     No        Okay
           c0t13d0s2               1520     No        Okay

Now, you have dynamically expanded the file system (/opt) with a single stripe metadevice.

Please note: This procedure must be done during a quiet period, or the file system must be locked, in order to avoid possible changes to the file system during the sync. You can use the fuser -u command to check that no one is using the file system. If users are logged on overnight in their logging directory, the system admin could write-lock the file system if it is possible. In that case, users can still read files in the directory. As long as no one creates files during the sync, everything will be fine.