Testing database applications: A special use of snapmirror resync on NETAPP

Testing software applications that run on a database can sometimes change or corrupt the database. To ensure that you do not lose data while testing such applications, you can copy the data to another volume for testing purposes, break the SnapMirror relationship and return the destination volume to writable state, and run the test application on it. Upon completion of the test, you can resynchronize the source and the destination volume.

Before you begin

Ensure that SnapMirror is enabled on the source and destination systems.

About this task

In the following procedure, you can use a combination of the snapmirror break and snapmirror resync commands to perform the following tasks:

• Make a destination volume writable for testing.
• Restore the newly writable volume to its original state if further testing is required.

Steps

1. Create or choose a volume or qtree to be used as a destination for the volume or qtree containing the database. (This example uses a volume called Test_vol.)
2. On the destination system, enter the following command to make the destination writable.snapmirror break Test_vol
   For a qtree, the path must be specified as shown in the following example. You must ensure that the qtree is quiesced before breaking the relationship.

   dst> snapmirror quiesce /vol/dst_vol/Testqtree
   dst> snapmirror break /vol/dst_vol/Testqtree

3. Run the application on the data in the former destination (Test_vol).
4. Check the data in the former destination (Test_vol).
5. As required, choose one of the actions from the following table.

   If...	Then...
   The data has been altered in some way that is not useful and you want to import a fresh copy of the data for further testing.	From the destination system, enter the following command:snapmirror resync Test_vol Note: For a qtree, the path must be specified as shown in the following example: src> snapmirror resync dst_system:/vol/dst_vol/Testqtree /vol/src_vol/Testqtree SnapMirror makes the former destination volume into a SnapMirror destination again and updates the destination with the latest data.
   The data has not been altered adversely, or you wish to stop testing.	The task is completed.

6. Repeat Steps 3, 4, and 5, until you are satisfied with the testing.

VSC 4.01 on Win2008R2 with vCenter - Plugin Error

HTTP ERROR 403

Problem accessing /register.html. Reason:

    FORBIDDEN

Cause:

I changed my AD domain admin account password and when I tried accessing the plugin it failed with the following error.


HTTP ERROR 403
Problem accessing /register.html. Reason:

    FORBIDDEN

FIX:

Use https://localhost:8143/Register.html with an uppercase "R" to re-register plugins!

Configuring a Netapp FAS to forward syslog messages

You would like to configure your Netapp FAS controller to forward its syslog error messages to a remote syslog server.

Cause:

By default all messages are logged to the console and to the /etc/messages file.  You must manually setup logging to a remote syslog server.

Solution:

You can use the following procedure to configure the Netapp FAS controller to forward messages to a remote syslog server.  The default configuration is to log error (*.err) and kernel (kern.*) messages to the remote syslog server.  Informational messages will still be sent to the console and the /etc/messages file.

1)      Connect to the Netapp FAS Controller etc$ share

a.       \\netapp_name\etc$

2)      Check for existing syslog.conf file in the etc$ share

a.       If the file does not exist copy the syslog.conf.sample file to syslog.conf

      3)      Open the syslog.conf file in a text editor

a.       You only need to edit one of the items circled in red or green as shown in the following screenshot, I recommend editing the line circled in red.

b.      Each section of the syslog.conf file demonstrates how you can manipulate the syslog configuration.  The information circled in purple is meant to point out the association between the description and the configuration line.  These require more advanced syslog server configuration, and are not covered in this article.

 

4)      Edit the syslog.conf file as needed.

a.       Basically, remove the comment indicator (#), and replace adminhost with the ip address or host name of the remote syslog server.

b.      If you need to log to multiple syslog servers use multiple lines.

c.       Here is an example showing how to log to two different servers, one by ip address, the other by FQDN.

d.      Save the file.

e.       The Netapp Controller will automatically detect the change to the syslog.conf file and load it; this may take a couple of minutes. When the change has completed, a syslog message similar to the following will be displayed:

Wed Jan 28 09:17:12 EST [syslogd:info]: syslogd: restarted

5)      You can now configure the remote syslog server to accept the incoming messages.

Configuring DNS on a NetApp Storage System

Here is the processes to enable DNS without having to use the NetApp system’s initialsetup command. This came in handy for me when I was doing some testing in my lab and overlooked setting it up during the initial config. With the latest OnCommand you can not edit these settings via the gui.

a. Create or confirm the system’s /etc/resolv.conf file with nameserver entries:

nameserver <dns-server-ip-address>
nameserver <dns-server-ip-address>

b. Set the following options on the NetApp storage system’s command line:

toaster> options dns.enable on
toaster> options dns.domainname <DNS domain name>

c. Edit the NetApp storage system’s /etc/rc file with the following entries so the DNS options are persistent across system reboots:

options dns.domainname <DNS domain name>
options dns.enable on

d. Please ensure that the NetApp storage system’s /etc/nsswitch file has the hosts entry that looks like this:
hosts: files dns nis