All about /etc/rc file

The /etc/rc file contains commands that the storage system executes at boot time to configure the system.

What startup commands do  

Startup commands are placed into the /etc/rc file automatically after you run the setup command or the Setup Wizard.

Commands in the /etc/rc file configure the storage system to
1) Communicate on your network 
2) Use the NIS and DNS services 
3) Save the core dump that might exist if the storage system panicked before it was booted

Default /etc/rc file contents

To understand the commands used in the /etc/rc file on the root volume, examine the following sample /etc/rc file, which contains default startup commands:

#Auto-generated /etc/rc 

hostname filerA
ifconfig e0 `hostname`-0
ifconfig e1 `hostname`-1
ifconfig a0 `hostname`-a0
ifconfig a1 `hostname`-a1
route add default MyRouterBox
routed on
savecore

Explanation of default /etc/rc contents 

Description : hostname filerA
Sets the storage system host name to "filerA."

Description : 
ifconfig e0 `hostname`-0 
ifconfig e1 `hostname`-1
ifconfig a0 `hostname`-a0

ifconfig a1 `hostname`-a1
Sets the IP addresses for the storage system network interfaces with a default network mask.
The arguments in single backquotes expand to "filerA" if you specify "filerA" as the host name during setup. The actual IP addresses are obtained from the /etc/hosts file on the storage system root volume. If you prefer to have the actual IP addresses in the /etc/rc file, you can enter IP addresses directly in /etc/rc on the root volume.

Description: route add default MyRouterBox

Specifies the default router. You can set static routes for the storage system by adding route commands to the /etc/rc file. The network address for MyRouterBox must be in /etc/hosts on the root volume.
 

Description : routed on

Starts the routing daemon.
  

Description: savecore
Saves the core file from a system panic, if any, in the /etc/crash directory on the root volume. Core files are created only during the first boot after a system panic.

BaseBoard Management Controller (BMC) setup

You can manage your storage system locally from an Ethernet connection by using any network interface. However, to manage your storage system remotely, the system should have a Remote LAN Module (RLM) or Baseboard Management Controller (BMC). These provide remote platform management capabilities, including remote access, monitoring, troubleshooting, and alerting features.

cherrytop# bmc setup

The Baseboard Managment Controller (BMC) provides remote managment capabilities
including console redirection, logging and power control.
It also extends autosupport by sending down filer event alerts

Would you like to configure the BMC? (y/n)? y
Would you like to enable DHCP on BMC LAN interface? (y/n)? n
Please enter the IP address for the BMC [0.0.0.0]: x.x.x.x
Please enter the netmask for the BMC [0.0.0.0]: x.x.x.x
Please enter the IP address for the BMC gateway [0.0.0.0]: x.x.x.x
Please enter the gratuitous ARP Interval for the BMC [10 sec (max 60)]:

The BMC is setup successfully.

The following commands are available; for more information
type "bmc help "
bmc help 

bmc setup 

bmc status 

bmc test
bmc reboot

This can be done online and is transparent to the Filer/servers connected to the NetApp Array. 

 

How to expand an A- SIS enabled volume that is nearing the "vol size" limit

WARNING: If this is being performed to free up space to bring a LUN back online, another method of cleaning up space should be considered, such as deleting snapshots and disabling automatic snapshots until a maintenance window can be scheduled as the 'undo' process can take a significant amount of time.

To increase the size of an A-SIS enabled volume beyond the maximum limit for A-SIS, the A-SIS service must be turned off and the changes undone. Undoing A-SIS will re-inflate the file system and could require more disk space than is available in the A-SIS enabled volume. There is no way to expand the volume size until the undo is completed, so the recommended course of action is to create and use a temporary volume and migrate data necessary to free enough space for the re-inflation to complete.WARNING: Once the volume is grown beyond the maximum size supported for A-SIS, A-SIS will be disabled.

WARNING: Disabling A-SIS will require additional disk space as files will be undeduplicated.

WARNING: Using "sis undo" may require rebaselining of snapmirror or snapvault relationships.

Complete the following steps to undo A-SIS:

Note: The undo must be performed from diag mode. The sis undo command can take some time (hours) based on how much data is being un-deduped and the filer type.

1- Enter df -s
Note the space saved, this is the amount of space that will be necessary for the re-inflation.
2 - Enter df
Note the available space. If it is not greater than or equal to the space saved found in the previous output, space will need to be cleared using other methods to complete the undo (e.g., deleting Snapshots or migrating data).
3 - Enter sis off
4 - Enter priv set diag
5 - Enter sis undo

Once the undo is complete, the volume will be a normal FlexVol volume that can be expanded.

When trying to access the filer using a NetBIOS alias, error message: Decrypt integrity check failed

When trying to access the filer's NetBIOS alias, the following error messages are generated:


[auth.trace.authenticateUser.krbReject:info]: AUTH: Login attempt from 10.20.1.13 rejected by Kerberos.
[cifs.trace.GSSinfo:info]: AUTH: notice- Could not authenticate user.
[cifs.trace.GSSinfo:info]: AUTH: notice- Decrypt integrity check failed.


Issue
The Active Directory had a stale computer account that had the same name as the NetBIOS alias used to contact the filer. The NetBIOS alias may have been created in the Active Directory during vFiler testing, but the account had not been removed.


Check the following:
1. Check for another account in the same AD forest that has the same name as the filer. This can either be a stale account (left over from a previous situation), or another machine.


2. The reason you can connect when you specify an IP address is that the client uses NTLM instead of Kerberos in that situation. When the client gets a Kerberos ticket, it is most likely getting a ticket for the wrong machine.

How to Reboot / Reset an HP Blade iLO2

Every once and awhile an iLO2 Remote Control session will get "stuck". By this I mean when you try to connect, it will say that there is a session already in progress. A reboot of the iLO2 will clear this state. To restart the iLO2, follow these steps.

* From the Web Administration page for the iLO2, you should be on the System Status tab by default 
* Click Diagnostics on the left hand side
* On the bottom of this page is a Reset button for the iLO2

Moving the Root Volume in NetApp

When you move the root volume you need to do the following:

* Create a new aggregate on the array for that root volume.
* Copy the root volume to the new aggregate.
* Destroy the original root volume and its containing aggregate.
* Check th eInstallation Requirements, Quick Start, and Reference Guide to determine the minimum root volume size for your system model.


Steps:
1. Check the output from sysconfig -r to ensure that adequate size for the root volume is available on the storage array where you want the root volume.

2. Create a new aggregate for the new root volume. This command creates an aggregate to contain a FlexVol root volume:
cherry-top# aggr create aggr_new -r 14 -T FCAL -r raid_dp -d 0a.23 0a.24 0a.25

3. Create a FlexVol for the root volume:
cherry-top# vol create vol0_new aggr_new -s 30g

4. Vol copy or ndmpcopy to copy the root volume to the new root volume:
yellow# ndmpcopy /vol/vol0 /vol/vol0_new
if its a volcopy then restrict it to prevent data access while you are moving the root volume:
cherry-top# vol restrict vol0_new

5. Specify that the volume named volroot will become the root volume after the next reboot:
cherry-top# vol options vol0_new root

6. Reboot the system and check the system integrity:
cherry-top# reboot


7. Check the system to ensure vol options
cherry-top# vol status


8. Offline/destroy the original root volume and destroy the aggregate
cherry-top# vol offline vol0
cherry-top# vol destroy vol0
cherry-top# aggr offline aggr_old
cherry-top# aggr destroy aggr_old

Error message: Ndmpcopy: Authentication failed for source

There are several reasons for ndmpcopy to fail:

•The password for both the source and destination filer are not given:
ndmpcopy -sa root: -da root: filer1:/vol1 filer:/vol1

•Authentication depending on the authentication type: challenge or text. With Data ONTAP 6.1 and earlier, an authentication error will occur if ndmpcopy tries to authenticate using md5.

•The source pathname is invalid. The following is an output from the 'ndmpcopy' command when the source path name is invalid:

Solution:
1.Set the options ndmpd.authtype to "challenge" on the source and destination. Data ONTAP 6.1 and earlier versions require ndmpcopy authentication to be set to TEXT.

2.Find the encrypted password for a user, using the following command:
ndmpd password ndmpuser

Find the source password:
fas270cl1-ca-n2> ndmpd password ndmpuser
password RtafEaSBeZEP31ws

Find the destination password:
fas270cl1-ca-n1> ndmpd password ndmpuser
password bHzZT0u3VFnIAeKD

3.Now retry the NDMP copy, specifying the passwords on the host and destination filers:

ndmpcopy -sa root:[passwd] -da root:[passwd] filer1:/vol1 filer2:/vol1

EMC Centera/CAS/OBS

What is EMC Centera?

The EMC Centera is the world's first magnetic hard disk-based WORM data storage device, providing Write Once Read Many functionality to applications that require data to be stored on a non-rewriteable, non-erasable storage medium.

By using traditional magnetic hard disks as its storage medium, the EMC Centera offers greater performance over other archival media types such as optical and tape. EMC developed the Centera to address the storage of fixed content data, the fastest growing data type today.

What is Fixed Content Data?

Fixed content data is any digital asset that is created once, never modified, and must be retained for reference throughout its life cycle and retention period as required by regulatory agencies.

The recent explosion in the creation of fixed content has created a demand for a new category of storage devices designed to provide fast, secure on-line access to this data with long-term availability. The EMC Centera represents this new category of data storage devices known as Content Addressed Storage (CAS).

What is Content Addressed Storage?

Content Addressed Storage is a method of data storage that stores and retrieves a data object by its content address within the storage system, rather than by its actual file name at some physical location.

The benefit of a content addressable approach to storage is that an object is stored in such a way that it is authenticated and unalterable. In addition, objects cannot be deleted prior to the expiration of its defined retention period.

 

How Content Addressed Storage Works

When an application delivers a data object to the EMC Centera, the API calculates a 128-bit “claim check” that is uniquely derived from the objects binary representation. The metadata for the object, which includes filename, creation date, etc., is inserted into an XML file called a C-Clip Descriptor File (CDF), which in turn has its content address calculated. The Centera repository then stores the object and a mirror copy.

Once two copies of the object and CDF are stored in the repository, the Content Address is returned to the application. Future access to the data object occurs when the application submits the CDFs Content Address to the Centera repository via the API. The data is then returned back to the application. The Centera file system architecture eliminates directory structures, pathnames, and URL references to filenames and only uses the C-Clip Content Address as a reference.

How EMC Centera Provides WORM Functionality

The C-Clip Content Address of a data object assures the authenticity of that object. If an object is retrieved and altered, the Centera API produces a new CDF with a new content address for the altered object. The original object remains in its original form at its original content address and is still accessible by its original address.

This feature of Centera provides a level of versioning integrity that standard file servers and operating systems cannot provide. Additionally, Centera features an operational mode where an object cannot be deleted prior to the expiration date of a defined retention period. These non-rewriteable and non-erasable properties of the EMC Centera give the Write Once Read Many attributes required for compliance with SEC 17a-4, Sarbanes-Oxley, HIPAA, FDA, and many others.

Centera Hardware Architecture

Comprised of Redundant Arrays of Independent Nodes (RAIN), every node in a Centera contains a CPU, network interface, and 3TB of raw storage, and is interconnected with all other nodes in the cabinet via a private LAN. Each node executes an instance of CentraStar, the Centera operating software, in one of two operational modes to act as either a storage node or an access node.

The storage nodes provide the physical storage of data objects and C-Clip Descriptor Files and the access nodes provide the means for interaction between the application server and the storage nodes. Throughput and storage requirements of the application will determine how many access nodes vs. storage nodes must be configured at the time of installation of the EMC Centera.

Fault Tolerance

The EMC Centera is based around a “no single-point-of-failure” platform and can be serviced in a non-disruptive manner. Every component of the Centera has built-in redundancy. This includes hard drives, power supplies, AC power connectors, cooling fans, and network adapters and associated cable interconnects.

When drives fail, CentraStar, the Centera operating software, will transparently remove them from the cluster. Objects are regenerated from the current mirror to a new mirror to ensure that a fully redundant mirror copy of the content is always available. Data integrity checking runs in the background and continuously recalculates the content addresses of all the objects and compares the calculations to the content addresses originally stored in the C-Clip Descriptor File.
Scalability

A single Centera 19” rack cabinet can hold 8, 16, 24, or 32 nodes to provide 5.4TB – 43.2TB in mirrored mode, or 18.3TB – 73.4TB in parity-protected mode. For scalability beyond 73.4TB, multiple Centera cabinets can be configured as a single cluster, offering hundreds of Terabytes of total storage capacity in a single Centera storage pool.

When new storage units are added to the cluster and powered on, they are automatically “auto-discovered” and join the cluster. No reconfiguration or downtime is necessary to add capacity.

NetApp Telnet : Too many users logged in! Please try again later

You can log out the session blocking your log on attempt by running the following command.  
You can just execute the following command to remotely logout the user and free up the session.

rsh (hostname)  -l root:(password) logout telnet

NetApp - Theory of Aggregate

NetApp's Aggregate is a DataONTAP feature that combines one or more Raid Groups(RG)  into a pool of disk space that can be used to create multiple volumes in different flavors. Newly added disks are assigned to the spare pool and a new aggregate or an existing aggregate that requires more space will then be pulled from the spare pool.

Unlike other Storage arrays where you create LUN from a specific RG, DataONTAP creates volumes within the available space in the aggregate across multiple RG. DataONTAP dynamically stripes the volumes across the aggregates within the Raid Groups. When disks are added to the aggregate they will either go into an existing RG that is not yet full or into a new RG if all the existing groups are full. By default RG are created as RAID-DP(dual parity drives) with stripes of 14+2 for FC/SAS disks and 12+2 for SATA disks. If you want to separate your "Vol0" in a separate aggregate, usually its aggr0 with a minimum of 3 disks for RAID-DP.

Aggregates have snapshots, snap reserve & snap schedule just like any other volumes. Aggregates may either be mirrored or unmirrored. A plex is a physical copy of the WAFL storage within the aggregate. A mirrored aggregate consists of two plexes;(A plex may be online or offline unmirrored aggregates contain a single plex. In order to create a mirrored aggregate, you must have a filer configuration that supports RAID-level mirroring. When mirroring is enabled on the filer, the spare disks are divided into two disk pools. When an aggregate is created, all of the disks in a single plex must come from the same disk pool, and the two plexes of a mirrored aggregate must consist of disks from separate pools, as this maximizes fault isolation.

An aggregate may be online, restricted, or offline. When an aggregate is offline, no read or write access is allowed. When an aggregate is restricted, certain operations are allowed (such as aggregate copy, parity recomputation or RAID reconstruction) but data access is not allowed. 

Creating an aggregate

Aggregate has a finite size of 16TB raw disk with 32 bit DataONTAP. By default, the filer fills up one RAID group with disks before starting another RAID group. Suppose an aggregate currently has one RAID group of 12 disks and its RAID group size is 14. If you add 5 disks to this aggregate, it will have one RAID group with 14 disks and another RAID group with 3 disks. The filer does not evenly distribute disks among RAID groups.

To create an aggregate called aggr1 with 4 disks 0a.10 0a.11 0a.12 0a.13 from a loop on fiber channel port 0a use the following command:

netapp> aggr create -d  0a.10 0a.11 0a.12 0a.13

Expanding an aggregate

To expand an aggregate called aggr1 with 4 new disks use the following command:

netapp> aggr add aggr1 -d  0a.11 0a.12 0a.13 0a.14

Destroying an aggregate

Aggregates can be destroyed but there are restrictions if volumes are bounded to the aggregate. Trying to destroy an aggr with volumes will throw an error but this can be overridden with the -f flag. It is recommended to go over each and every volume and destroying it before using the -f option to avoid any potential data loss. Aggregates can be destroyed much like any volumes but it needs to be taken offline.

To destroy an aggregate aggr1 use the following command:

netapp> aggr offline aggr1

netapp> aggr destroy aggr1