Celerra Scripting Guidelines - EMC Celerra Command Reference Manual

Using Celerra Command Scripts
Celerra scripting
guidelines
Table 1
Issue
Scheduling
Command sequencing
Sleep statements
Pipe and grep
Return code check
498
Celerra Network Server Command Reference Manual
The following table lists guidelines to keep in mind when creating
Celerra command scripts.
Scripting guidelines
Action
NAS Database Backups:
The Celerra Network Server backs up the NAS database that stores specific configuration
information required for each Data Mover every hour, at one minute after the hour. During part of
the backup, the database is locked, and some commands that rely on the database might not
have access. EMC recommends that command scripts avoid starting at one minute after the hour.
Note that scripts with complex commands that run for an extended period may overlap the backup
period.
The duration of the backup may vary. Use the following Linux command to check the state of the
backup process prior to executing scripts: ps -ef | grep nasdb_backup. If a lock condition occurs,
wait a few minutes and retry.
Replication:
If you are using the Celerra Replicator restartable checkpoint feature to protect from out-of-sync
issues, please be aware that the system uses a CRON job to determine if a restartable checkpoint
needs to be refreshed at 25 minutes after the hour. This process may generate a checkpoint
refresh, depending on the state of the replication session. During a checkpoint refresh, the
database is locked. If another operation requires a conflicting lock, it receives an "unable to
acquire locks" error. If this occurs, wait a few minutes and retry.
In version 5.4, the checkpoint refresh process is sequential and may impact performance. Version
5.5 supports concurrent checkpoint refreshes, which are less resource-intensive.
Some commands must lock the database in order to execute. If multiple user-entered commands
or scripts are active at the same time, some of these commands may lock the database and
prevent other commands from executing. To avoid this, you should sequence commands
whenever possible.
Some processes within a script can take time to complete. Use proper timing and adequate sleep
statements to prevent timing-related issues.
Piping script outputs through grep is a helpful tool to check the status of the script. Use periodic
checks to grep for file or database locked messages, timeouts, resource unavailable warnings,
and other failure or success messages, and use this information to check status, pause the script,
or halt it. Detailed information about error messages can be found in the Error Messages Guide.
All commands return a UNIX-style return code (for example: 0 for success or 1 for failure) or a
text-based status code (for example, done) which can be used to help determine if the command
completed or if there was an error or a conflict with the NAS database backup, or other commands
being run. If a lock condition occurs, wait a few minutes and retry. If you create and run scripts, be
sure to incorporate return code checks and verify for proper return codes from individual
operations.