unixpowered.com

This list focuses mostly on mirror operations. I use Solaris Volume Manager quite a bit when mirroring internal drives. There are tons of additional features and commands, if you use SVM for  things other than mirroring. In that case you might want to look at check out Solaris Volume Manager Administration Guide.

Create database replicas:
metadb -f -a -c [number_of_replicas] [device]
metadb -f -a -c 3 c0t0d0s7

Delete all database replicas from device:
metadb -d [device]
metadb -d c0t0d0s7

Display status of database replicas:
metadb -i
metadb -i

Display metadevice status:
metastat
metastat

Create simple concat/stripe metadevice:
metainit -f [concat_metadevice] 1 1 [device]
metainit -f d21 1 1 c0t0d0s1

Create a mirror with one submirror:
metainit [mirror_metadevice] -m [submirror_metadevice]
metainit d20 -m d21

Attach a submirror to one sided mirror:
metattach [mirror_metadevice] [submirror_metadevice]
metattach d20 d22

Detach a submirror from a mirror:
metadetach [mirror_metadevice] [submirror_metadevice]
metadetach d20 d22

Clear a metadevice:
metaclear [metadevice]
metaclear d22

Offline a submirror:
metaoffline [mirror_metadevice] [submirror_metadevice]
metaoffline d20 d22

Online a submirror:
metaonline [mirror_metadevice] [submirror_metadevice]
metaonline d20 d22

Enable a failed component:
metareplace -e [metadevice] [device]
metareplace -e d21 c0t0d0s1

Rename a metadevice:
metarename [old_metadevice] [new_metadevice]
metarename d20 d30

Switch metadevice names:
metarename [metadevice_1] [metadevice_2]
metarename -x d20 d30

Configure system for root metadevice:
metaroot [metadevice]
metaroot d10 Continue Reading

This is an oldie, but a goodie. For some reason I was asked about it 3 times in a span of a week. Suppose your system was not shut down cleanly and it refuses to come up. During bootup fsck refuses to run, complaining about corrupt superblock. So, what do you do? First, get the alternate superblock locations and then run fsck using one of the alternate superblocks.

To get alternate superblock locations do:

newfs -Nv /dev/rdsk/c0t0d0s3

This will not actually format the slice. It will only print what it would do, if it was actually formating the slice. Basically, it is newfs dry run. It will also give you locations of alternate superblocks on the slice. I guess it should be mentioned that if you used non-default values while formating the slice originally, and you did not make a note of those values, this might not give you valid superblock numbers.

After you have your alternate superblock numbers you can use them to help out fsck (in this case superblock I am using is in block 8192):

fsck -y -F ufs -o b=8192 /dev/rdsk/c0t0d0s3

It might not hurt to run the above with -n option instead of -y to make sure it produces the results you are looking for.

Hopefully, the filesystem is not hosed so badly that it can not be repaired. This was more of an issue when Solaris did not have ufs logging. Nevertheless, it does not hurt to know this for one of those emergencies. Continue Reading

Starting with Solaris 9 there is a very handy tool called logadm that makes management of any log files a breeze. Syslog and messages files, among others, are managed by logadm which is called from root’s crontab.
Logadm reads /etc/logadm.conf file to figure out what it needs to do. By default there are following entries in logadm.conf:

/var/log/syslog -C 8 -P 'Wed Apr 8 02:10:22 2009' -a 'kill -HUP `cat /var/run/syslog.pid`'
/var/adm/messages -C 4 -P 'Fri Apr 10 02:10:15 2009' -a 'kill -HUP `cat /var/run/syslog.pid`'
/var/cron/log -c -s 512k -t /var/cron/olog
/var/lp/logs/lpsched -C 2 -N -t '$file.$N'
/var/fm/fmd/errlog -M '/usr/sbin/fmadm -q rotate errlog && mv /var/fm/fmd/errlog.0- $nfile' -N -s 2m
smf_logs -C 8 -s 1m /var/svc/log/*.log
/var/adm/pacct -C 0 -N -a '/usr/lib/acct/accton pacct' -g adm -m 664 -o adm -p never
/var/log/pool/poold -N -a 'pkill -HUP poold; true' -s 512k

Logadm provides -w switch which will write an entry into logadm.conf file that reflects current command line arguments. Of course logadm.conf can be edited using text editor, if that is the preferred method. If that’s the case, -V option can validate syntax of logadm.conf for you. Another handy option is -n which will cause logadm to do a dry run without actually performing the log rotation.

Other useful switches are:

• -b and -a which allow specification of pre and post rotation commands to execute
• -e sends error messages to a specific address instead of sending it to the owner of the crontab
• -r removes entry from logadm.conf for a specific log file
• -o sets different owner for the new log file from the original
• -g sets different group for the new log file from the original
• -m sets different permissions for the new log file from the original

For the whole story on logadm check out logadm man page.

Continue Reading

Link aggregation takes a bunch of network interfaces and creates a big pipe out of them.

Aggregation also provides redundancy. If all interfaces but one go down, the server will remain connected to the network.

Before starting make sure that:

• interfaces to be aggregated are of the following type: xge, e1000g, and bge
• interfaces to be aggregated are not plumbed
• they run in full duplex mode at the same speeds
• eeprom’s local-mac-address? variable is set to true

The following will create aggr1 interface with bge1 as one of its members:

bash-3.00# dladm create-aggr -d bge1 1

Next plumb the aggregate interface, configure an IP address on it and bring it up:

bash-3.00# ifconfig aggr1 plumb 192.168.1.5 netmask 255.255.255.0 up

At this point you can list aggregations:

bash-3.00# dladm show-aggr
key: 1 (0x0001) policy: L4      address: 0:3:ba:56:7f:ba (auto)
           device       address                 speed           duplex  link    state
           bge1         0:3:ba:56:7f:ba   0     Mbps    unknown down    standby

Now add bge0 as a second member of aggr1 aggregation interface and list aggregate interfaces:

bash-3.00# dladm add-aggr -d bge0 1
bash-3.00# dladm show-aggr
key: 1 (0x0001) policy: L4 address: 0:3:ba:56:7f:ba (auto)
           device       address                 speed           duplex  link    state
           bge1         0:3:ba:56:7f:ba   0     Mbps    unknown down    standby
           bge0         0:3:ba:56:7f:b9   1000  Mbps    full    up      attached

To keep the configuration persistent across reboots, create /etc/hostname.aggr1 with appropriate content and remove any hostname.* files pertaining to the interfaces that are now members of aggr1.

To have link aggregation working properly you need to have the switch to which server is connected to properly configured with LACP.

Another thing to consider is load balancing policy for outgoing traffic. You can load balance on layers 2,3 and 4. Load balancing policy can be changed using dladm command. Here is a quick example that will modify load balancing policy to combination of L3 and L4:

bash-3.00# dladm modify-aggr -P L3,L4 1
bash-3.00# dladm show-aggr -L
key: 1 (0x0001) policy: L3,L4 address: 0:3:ba:56:7f:ba (auto)
                LACP mode: off  LACP timer: short
    device    activity timeout aggregatable sync  coll dist defaulted expired
    bge1      passive  short   yes          no    no   no   no        no
    bge0      passive  short   yes          no    no   no   no        no

And finally, command that will allow you to see utilisation of individual links within aggregation. Note the %ipkts column, I did not have LACP turned on on the switch at that time:

bash-3.00# dladm show-aggr -s
key: 1  ipackets  rbytes      opackets   obytes          %ipkts %opkts
           Total        2723785   2287233197  1481682   710633551
           bge1 618712    115674760   870443    636559150       22.7    58.7
           bge0 2105073   2171558437  611239    74074401        77.3    41.3

More info on link aggregation is here. Continue Reading

Finally, I got tired of remembering which network interfaces is configured on my Netra test box. So I do not have to remember which interface to plug cable into I configured IPMP on the box. IPMP provides link redundancy among multiple network interfaces in multipathing group. IPMP is not meant to be full fledged load balancing solution, though it will spread outgoing traffic across the interfaces.

I have put my two hme interfaces into a multipathing group. The group has a failover IP address assigned to it. Initially this address will be assigned to hme0. If hme0 fails, the address will automatically move to the other interface in the failover group.

First I edited /etc/hostname.hme0:

unreal-hme0 netmask + broadcast + deprecated -failover group unrealgrp1 up addif unreal netmask + broadcast + failover up

This configures physical hme0 with IP address of 192.168.11.6, which will not fail over and puts hme0 in unrealgrp1 multipathing group. It will additionally configure a virtual IP address of 192.168.11.5 which will failover when hme0 link goes down. Deprecated means the IP address 192.168.11.5 will not be used as source address for any outgoing packets.

Then I edited /etc/hostname.hme1:

unreal-hme1 netmask + broadcast + deprecated -failover group unrealgrp1 up

Similarly, hme1 will be configured with IP address of 192.168.11.7 and as a member of unrealgrp1 multipathing group. Again, 192.168.11.7 is marked as deprecated so it will not be used for outgoing packets. Finally I made sure my hosts file is correct:

bash-3.00# cat /etc/hosts
127.0.0.1 localhost
192.168.11.5 unreal loghost
192.168.11.6 unreal-hme0
192.168.11.7 unreal-hme1

And here is the result:

bash-3.00# ifconfig -a
lo0: flags=2001000849 mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=9040843 mtu 1500 index 2
inet 192.168.11.6 netmask ffffff00 broadcast 192.168.11.255
groupname unrealgrp1
ether 8:0:20:d9:ac:c
hme0:1: flags=1000843 mtu 1500 index 2
inet 192.168.11.5 netmask ffffff00 broadcast 192.168.11.255
hme1: flags=19040803 mtu 1500 index 3
inet 192.168.11.7 netmask ffffff00 broadcast 192.168.11.255
groupname unrealgrp1
ether 8:0:20:d9:ac:d

Essentially IP address 192.168.11.5 “floats” among interfaces. If I were to unplug hme0, 192.168.11.5 would fail over to hme1. Failure is detected on link loss. There are some tunable parameters in /etc/default/mpathd.

This is all I needed. Of course, there is much more to IPMP: you can setup test system, that your system will test for reachability, detection of interfaces missing on boot, etc. Sun has much more info on it here. Continue Reading