|C H A P T E R 9|
Activating System Options
Note: When a compliance license expires or is removed, the system will maintain compliance rules, but no new compliance file volumes can be created. Refer to About Compliance Archiving Software for more information about the Compliance Archiving software.
7. If activating the File Replicator software, enter separate licensing information to the mirrored server, as described under Activating File Replicator Software on the Remote Server.
About the Sun StorageTek File Replicator Option
When mirroring is configured, you can duplicate any or all of the file volumes from one appliance or gateway system onto another. You control which volumes are mirrored. The source server is called the "active server" and the target server is called the "mirror server."
If the active server fails, you can break the mirror on the mirror server, and then make the mirrored file volume available for users, switching from the active server to the mirror server. This operation is called promoting a mirror volume.
Mirroring is accomplished through a large mirror buffer to queue file-system transactions for transfer to the mirror system. In practice, the mirror server lags the active server by a short time period, but because the processing is transaction-oriented, the integrity of the mirror file system is guaranteed, even during network interruptions or system outages.
File volumes on the mirror server have a partition type of NBD (Network Block Device), which identifies the software module that provides the network transport for file replication. If a mirror file volume is promoted, its partition type is SFS2 (Server File System version 2, a proprietary NAS file system), or SFS2EXT for a segment, like all other file volumes.
When checkpoints are created on the active server, the checkpoints get copied to the mirror server. This can be useful for scheduled backups, or to provide a read-only checkpoint to specific users or applications.
Caution:When the cluster is in failover mode (that is, one server is in the ALONE state and the other server is in the QUIET state) or any degraded state, do not perform any mirror management operations. Bring the cluster to the NORMAL state before doing any of the mirror management operations.
When setting up your systems, designate the roles of the ports connecting the mirroring servers to one another. Then configure mirroring on the active and mirror servers using the Web Administrator interface (see About Mirroring the Mirror Buffer). Configure each system independently.
The active and mirror systems' ports can be on different local subnets. For more information about configuring Transmission Control Protocol/Internet Protocol (TCP/IP), see About Configuring Network Ports.
If you have created an isolated network to carry the mirroring traffic, use addresses in the range reserved for private use, such as 192.1xx.x.x. For example, assign the active system's mirror link interface to 192.1xx.1.1, and assign the mirror system's mirror link interface to 192.1xx.1.2.
This enables the servers to communicate with each other over networks that are not directly connected to their local interfaces. For more information about completing this process, see Managing Routes.
Note: File volumes must be greater than 1 gigabyte, a minium of 1046 megabytes, to be mirrored. A file volume of exactly 1 gigabyte (1024MB) does not have enough available capacity to enable mirroring.
The mirror buffer stores file-system write transactions while they are being transferred to the mirror server. The file volume free space on the active server is reduced by the allocation size of the mirror buffer.
The size of the mirror buffer depends on a variety of factors, but must be at least 100 megabytes, and the mirror buffer can never be more than half of the remaining free space on any given file volume.
In a normal scenario, create a mirror buffer that is approximately 10 percent of the size of the file volume you are mirroring. The size you specify depends on how much information is being written to the file volume rather than the size of the file volume. As a rule of thumb, the size of mirror buffer is directly proportional to the frequency of writes to the file volume and inversely proportional to the speed of the network connection between the two servers.
If there is high write activity to the file volume and a slow network connection between the two mirror servers, create a mirror buffer that is approximately 25 to 30 percent of the size of the file volume you are mirroring.
The size of the mirror buffer cannot be dynamically increased. To increase the size of the mirror buffer, you have to break the existing mirror and create the mirror again with the new mirror buffer size.
After you have activated the Sun StorageTek File Replicator option (see Activating System Options), you must also activate the option on the remote server that contains file volumes you want to mirror.
You can add to some of the properties of a mirror file volume that is not in the In Sync state. You cannot change the values that were specified when the mirror file volume was created. You canonly specify information that was not specified when the mirror file volume was created. For example, you can add a password if no password was set, but you cannot modify a password.
If the connection between the two servers is down for some time, or the mirror buffer is too small to handle the number of writes to the master file volume, the mirror might show signs of cracking. You can recognize this when the mirror begins replicating again, and the Sync Status on the File Replicator > Manage Mirrors panel is no longer In Sync.
The mirror file volume will go off-line until the replication is finished. View the Sync Status field in the Manage Mirrors panel to view the replication percentage completed (Initializing Mirror Buffer percent-complete).
If the replication cannot complete (typically because the original server died, or a logical unit number (LUN) was lost), the mirror is cracked. Contact Sun Services to step through the process of rebuilding the mirror.
In the File Replicator > Set Threshold Alert panel, you can set the threshold alert for all mirrored file volumes. The threshold alert is the percentage of mirror buffer use at which a warning is sent to designated recipients.
The mirror buffer stores file-system write transactions while they are being transferred to the mirror server. Increases in write activity to the active server or a damaged network link can cause the transference of write transactions to the mirror server to "back up" in the mirror buffer. If the mirror buffer overruns because of this process, the mirror is cracked and no further transactions occur between the active server and the mirror server until the mirror is re-established. When full communication is restored, the system begins the mirror resync process until the mirrored file volume is back in sync.
To avoid overrunning the buffer, the system sends warnings through email notification, the system log file, Simple Network Management Protocol (SNMP) traps, and the LCD panel when the mirror buffer is filled to certain threshold percentages.
For example, if you set the Mirroring Buffer Threshold 1 to be 10 percent and the Alert Reset Interval to two hours, the first alert is issued when the mirror buffer is 10 percent full. The system will not issue the Threshold 1 alert again for the next two hours. If at that time the mirror buffer usage is still beyond the 10 percent threshold (but not beyond Thresholds 2 or 3), the Threshold 1 alert is issued again.
To promote a file volume on the mirror server (for example, if the file volume on the active server is unavailable), you must first break the mirror connection. Break the mirror connection on the active server rather than on the mirror server as described in the following procedure. However, if the active server is down and you cannot access it to break the connection, you can break the mirror connection from the mirror server instead.
You are prompted to confirm that you want to break the mirror connection. After the mirror connection is broken, it disappears from the mirroring table in this panel. To promote the file volume, you must access the Manage Mirrors panel on the mirror server. For more information, see Promoting a Mirrored File Volume.
If the active server fails, the mirror server provides high availability for mirrored file volumes. To make a mirrored file volume available to network users, you must promote the file volume. You must first break the mirror connection, then promote the mirrored file volume and configure its access rights. After a mirror connection is broken and the mirrored file volume promoted, the original and mirrored file volumes are completely independent.
To promote a file volume on the mirror server, you must first break the mirror connection. See Breaking the Connection and Promoting a Mirrored File Volume for instructions. Then:
This feature is particularly useful for compliance-enabled file volumes, which can be renamed only at the time of promotion. Volumes that are not mirrored (in other words, that are not compliance-enabled) can be renamed at any time.
Unless you rename a compliance-enabled file volume when you promote it, you cannot mirror that volume back onto the original active server, because the original file (by the same name) will already be on that server.
It might take several minutes to complete this process. A status message is displayed when the process is complete. For the mirrored file volume to be promoted, the volume must have reached an In Sync state at some point. If the mirrored file volume was out of sync when it is successfully promoted, the volume will be mounted as a read-only volume. Before write-enabling the volume, run the fsck command to make any necessary repairs.
After you break the mirror connection, the system performs a file-system check. If the system finds errors during this check, the file volume promotion process could take longer to complete. Data integrity is not guaranteed if the mirror is out of sync during the promotion process.
After you promote the file volume, you might need to reconfigure access rights. Microsoft Server Message Block (SMB) share information is carried over, but you must configure any Network File System (NFS) file volume access and NFS exports for this file volume again. For more information on setting up NFS exports, see About Setting Up NFS Exports.
1. Define the access list for each iSCSI LUN you want to promote, referring to Creating an iSCSI Access List for instructions.
4. In the Promote iSCSI LUN panel, specify the iSCSI target IQN identifier for the LUN to be promoted (Name field), the name of the file volume where the promoted LUN resides (that is, the name of the file volume as it was promoted), and the access list used for the LUN. Refer to Promote iSCSI LUN Window for further details.
This procedure describes how to reestablish a mirror connection after the active server fails and you promote the file volume on the mirror server. The promoted file volume is now the most up-to-date version and functions completely independently of the out-of-date file volume on the active system. To recreate the mirror connection, you must mirror the up-to-date file volume back to the active server, and then mirror the file volume back to the mirror server as you did originally.
In the examples that follow, Server 1 is the original active server that failed and contains the out-of-date volume, and Server 2 is the original mirror server that now contains the up-to-date volume.
1. Make sure the mirror on Server 1 is broken, referring to Breaking the Mirror Connection on the Active Server.
2. Delete the out-of-date file volume on Server 1, as detailed under Deleting the Out-of-Date File Volume From Server 1.
3. Mirror the up-to-date file volume from Server 2 back to Server 1, described under Mirroring the Up-to-Date File Volume From Server 2 to Server 1.
4. Change the role on Server 2 (see Changing Volume Roles).
Caution:Before completing the following step, make sure you selected the out-of-date file volume on the active server. Also make sure that the up-to-date file volume on the mirror server has been verified and promoted.
See Changing Volume Roles for more information.
An administrator can switch roles between an active file volume and the mirror volume. Changing volume roles enables the active volume to function as the mirror volume and vice versa; however, the original configuration on each volume remains unchanged. Changing roles is not a disaster recovery function.
About the Compliance Archiving Option
The Compliance Archiving software helps a company address business practices and regulatory compliance rulings regarding the retention and protection of information. Such rulings and frameworks for records retention and protection include the Security and Exchange (SEC) Regulation 17 CFR § 240.17a-4 (17a-4), Sarbanes Oxley Act, BASEL II, and numerous data protection and privacy directives.
The Compliance Archiving software was designed in consultation with information-management compliance and enterprise content management industry experts to help address the most stringent requirements for electronic storage media retention and protection. Compliance Archiving software uses WORM (write once, read many) files in accordance with compliance rules.
To ensure the strongest possible enforcement of your data retention policies, it is essential that you provide for the physical security of your NAS device. Software-controlled data retention is no stronger than the physical safeguards used to control access to the system's hardware.
For a technical overview of the features and programming interface for the Compliance Archiving software, see Appendix C.
To change compliance archiving settings, see Configuring the Compliance Archiving Software.
The Compliance Archiving software enforces compliance archiving guidelines for data retention and protection, on NAS appliances and gateway systems. Compliance archiving can be enforced in both a less stringent form (referred to as "advisory enforcement") and in a stringent form (referred to as "mandatory enforcement").
You enable the enforcement of compliance archiving guidelines separately for each file volume, and you must do so when the file volumes is initially created. Follow the instructions under Creating a File Volume or Segment Using the Create File Volumes Panel to create a compliance-enabled volume.
Caution: Do not enable compliance archiving on file volumes that will be used by applications and users that are not aware of the different data retention rules enforced by the Compliance Archiving software.
When enabling the Compliance Archiving software, be sure that the NAS server's system clock and the client system's server clock are synchronized. You can synchronize the NAS server to an external time source using NTP, as described in About Time Synchronization. A time difference between a client and the NAS server could cause the server to apply the default retention period when a client requests a retention time shorter than the clock skew.
For Sun StorageTek 5310 and Sun StorageTek 5320 NAS appliances and gateway systems, proper operation of the Compliance Archiving software requires the correct physical configuration of the NAS appliance hardware. In particular, the redundant array of independent disks (RAID) controller must not be connected to any device or network, other than a private Fibre Channel connection to the NAS server, and (for non-gateway configurations), connections to any expansion units. There are no such requirements for Sun StorageTek 5210 NAS appliances.
Caution: After you enable compliance archiving with mandatory enforcement on a file volume, that volume cannot be deleted, renamed, or have compliance archiving disabled or downgraded to advisory enforcement.
Note: Decreasing the retention time and removing retained files before the retention period has expired must be performed by the root user from a trusted host.See Managing Trusted Hosts.
When a compliance-enabled file volume with advisory enforcement is upgraded to mandatory enforcement, the default retention period for that volume becomes permanent. This can be changed on the Edit Properties panel.
Compliance auditing provides a text-based log for attempted efforts to modify or delete data (with or without proper authority) and is enabled through the use of the Data Retention Audit Service (DRAS) API, which includes the following features:
Note: A request to write to a retained file might not be written to the audit log. This can occur if you use an application that attempts to determine the access permissions before writing to a file. The application does not issue a write request if write permission is not available for a retained file.
The audit logs for each compliance-enabled file volume reside in a hidden directory called .audit$ in that volume's root directory. The audit log must be accessed by a root user from a trusted host, or by a Windows domain administrator if you are running CIFS in domain mode. See Managing Trusted Hosts for more information.
Audit log records are text-based and can be accessed through network protocols, including Network File System (NFS) and Common Internet File System (CIFS). The .audit$ directory must be included in the share path for the contents to be viewed by clients running Windows 2000 or XP. Refer to About Shares for details about creating shares.
Compliance file volumes reserve an amount of free space to guarantee that auditable operations on the volume can be logged. When the free space remaining on a compliance file volume falls below this limit, auditable operations will not be executed. A message will be logged indicating that there is not enough space to execute both the operation and the audit, and a warning email will be sent, if email has been configured on the system.
About the Assured Delete Option
The Assured Delete feature, also referred to as data shredding, secure delete, or true delete, provides a secure way of deleting data. When it is enabled, files that are removed cannot be recovered by searching through the storage on the disks.
In volumes without the Assured Delete feature, deleting a file does not actually remove any data. Instead, deleting a file only unlinks the file from its parent directory. The file system then reuses the pages when needed. The data on those pages remains on the disk until overwritten when the pages are reused. Until this occurs, sensitive data can be recovered with efforts such as examination of the disks.
When a system is configured to use Assured Delete, deleting a file causes the file system to first overwrite the file's data pages several times with data patterns before unlinking them from the parent directory. The data pages are released for reuse but no longer contain the original data.
The Assured Delete feature can be configured for any volume except for system volumes. When it is enabled, a hidden directory is created called the shredder. When a user deletes a file from that volume, the file is placed in the shredder and the data blocks for the file are overwritten a specified number of times. When the overwrite operations are complete, the file is moved to the attic directory where it is then unlinked and the data pages can be reclaimed for use by the file system.
The number of times the data blocks are overwritten can be specified, from the default of three times to the maximum of seven times. The data patterns used in the overwrite operation are the following: first pass is 0x00, the last is 0x55, and all passes between the first and last are random patterns.
The status subcommand displays whether Assured Delete is enabled for the volume, and if so, the number of overwrite operations performed on shredded files. Also, the status subcommand displays the current number of files in the shredder directory for the specified volume.