blog.virtualtacit.com

Normally I wouldn’t comment on such topics as Archiving, as that subset of the IT world tends to be quite spiritless. But to lessen the head banging across the globe I thought I would spell out some fundamental tweaks to lessen the large ingest woes within EX. What is assumed, however, is a basic understanding of what is involved in an EX implementation. Here is what we got, in situations where you are moving from a competitive archive solution to EX there is a certain amount of finesse that needs to be massaged into the EX configuration. Assuming that all the archived data has been puked from the other archive system onto a temp exchange server for ingestion into EX please take note of such considerations…

• Your message center volume sizes must be small enough to force closure by EX in a reasonably amount of time. In most situations other than this, 90MB is appropriate. But unless you message center drive is large enough EX will fill up that drive during the initial bulk load. So what are your options-
  • Move the message center drive to the container drive or resize the message center drive to accommodate the initial ingest. The container drive is usually sized large enough as this is ultimately where your archived emails end up.
  • Change the following registry value to force closure of your container volumes after 2 hours. The default behavior is to close the volume after the allotted capacity (in this case 20MB) or 5 days of inactivity.
    [HKEY_LOCAL_MACHINE\SOFTWARE\OTG\EmailXtender\RecordParms]

    “DirIdleTimeOut”=dword:00001c20, set DWORD to 7200 seconds for 2 hours

  • Other options noted here, detailed below…
    • Navigate to the registry HKLM\PSoftware\OTG\EmailXtender, perform changes in the following registry keys in that path..
      • MaxNumIndexProcesses (original value 4 change hexidecimal to 6 or 8 ) No more than 8 This will speed up indexing
      • MsgVaultDays ( originally set to 1 change hexidecimal value to 0)
      • MsgVaultHours (original value 0 can change hexidecimal to 1)
      • MsgVaultMins (originally set to 0 can change hexidecimal to value of 15, 30, etc.)
      • If you use MsgVaultMins then you should keep MsgVaultDays to 0 and MsgVaultHours to 0. All the MsgVault keys refer to how often we will create a folder in Emailxtract. The more often we create folders the less objects will be created in the folders and it will increase performance.
      • MaxRetryUpd (originally set to 60 change decimal value to 15, 10, or lower  Do not change to 0)
      • IndexIterationTime (originally set to 600 change decimal value to a value like 300, 200, 100 etc.  Do not change to 0)
      • Purpose of this key is how often EX goes through the IndexDropDir to see if there is anything that it needs to process

• What about throughput? Besides your obvious quick wins here, ie. more cpu, mem, seperate LUNs/spindles for each operation, here are a few other options to try.
  • Separate your initial archive tasks by distribution lists within Exchange. Create say 4 DL’s with your site mailbox’s even distributed among them. Point one archive task within EmailXtract to one DL, another archive task to another DL and so on.
  • Other options noted here, detailed below..
    For optimum performance it is recommended that MSMQ (ie:C:\WINDOWS\system32\msmq), Operating System (ie: C:\WINDOWS), Index Directory (ie: E:\Program Files\OTG\EmailXtender\EmailVault_Index), Message Center (ie: E:\Program Files\OTG\EmailXtender\MsgCenter), Payload if you’re running big Extract tasks (ie: E:\Program Files\OTG\EmailXtender\payload), Container (ie: E:\EmailXtender), Mail Root Drop directory if you process Bloomberg or IM (ie: C:\Inetpub\mailroot\Drop), and possibly SQL server (ie: C:\Program Files\Microsoft SQL Server) be located on separate SPINDLES.

    You can use this step to locate or move the Index drive
    ————————————————————————————–
    Stop all services. Copy Emailvault_index directory to new drive. Create a new string key in regedit under HKEY_local_machine\software\otg\emailXtender called Indexdir and put the new drive letter in this. Restart services and indexing will start to place files in the new drive.
    A path can also be entered in this string (Indexdir) to reflect the new directory path. If a directory path is listed, it is important to know that the emailvault_index directory will be created at service startup as well as the 3 working subdirectories, indexdir, baddir, and dropdir. Once this is created, the data from the previous location should be copied into each newly created directory having the same name.

    You can use this process to relocate the Payload directory
    ——————————————————————————————-
    Make sure that there are no active Extract tasks, close Extract completely (make sure it is not running on the system tray)
    Use regedit to edit the key in HKLM\Software\OTG\Emailxtender Payload key: enter the location of the Payload directory.

    You can use this process to relocate the Message Center
    ——————————————————————————————
    Disconnect connection mailbox and make sure that there are no active Extract tasks running.
    Close all open volumes and ensure that all Qs are zero
    Stop all EmailXtender services
    Use regedit to edit the key in HKLM\Software\OTG\Emailxtender MsgVaultDir key: enter the location of the Message Center directory.
    Restart all EmailXtender services

    You can use this process to relocate the MailRoot\Drop directory
    ——————————————————————————————————-
    Reinstall IIS on the desired directory
    Use regedit to edit the key in HKLM\Software\OTG\Emailxtender SMTP_DropDir key: enter the location of the SMTP Drop directory.
    You can move MSMQ using the applet on Control Panel; you will have to reboot the system. Please make sure that all volumes are closed and all Qs are empty.
    You can select the new Containers location using the EmailXtender administrator GUI.

In case you guys missed it, NetApp offered a shakeup back in July about the ability of their V-series line to de-dupe their competitors primary storage, noted here. I would have to agree with the general consensus that deduplication has its place and its place aint’ on primary storage. Applying de-dupe to secondary, tertiary storage and backup operations is really the meat behind this features punch.

The goal here is to provide your production data with the means to achieve high throughput, low latency execution, right? What you are doing is permeating your critical business infrastructure with an operation that is known to degrade performance. Not to mention this doesn’t in any way, shape or form provide the customer with an end to end, low maintenance, SUPPORTED solution. As a customer you must decide whether or not your investment in your array (whether EMC, HP, HDS, IBM, etc)  is all for not. 

By fronting your array with the V-series essentially strips all management capabilities of your array and reduces it to JBOD. Your investment is no longer an investment. E-labs, EMC’s own interoperability entity, works with associated vendors to resolve issues for qualified configurations. These support agreements run deep with various vendors but NetApp, particularly the V-series, is not one of them.

So here is what NetApp suggests:

· Support for de-duplication of primary data on third party storage arrays from EMC, HDS, HP, and others when connected to NetApp V-Series Virtualization systems.

· NetApp de-duplication, a feature of the Data ONTAP operating system provided at no cost on FAS systems, is now also offered free with the V-Series.

· End-to-end de-duplication including primary data, as opposed to other vendors’ de-duplication of only backup or archive environments.

· Improved business efficiency and reduced data management complexity using V-Series with non-NetApp storage arrays.

· De-duplication helps improve space efficiency and reduce raw storage requirements.

· By using V-Series with de-duplication, customers are able to better control their heterogeneous data growth while reducing costs and simplifying data management.

· More than 10,000 NetApp systems and 2,500 customers running NetApp de-duplication technology.

· All NetApp storage technologies will include de-duplication by the end of 2008.

Ok so here’s the rub when it comes to data de-dupe on NetApp Filers:

· Active snapshots? sorry you can’t de-dupe 

·Severe volume limitations are imposed as part of the 3D process

· No de-dupe over FlexVols, Aggregates, or Filers.

· Backup to tape inflates data to pre-dedupe size

· Since de-duplication is a post-process operation, NetApp offers no reduction of capacity requirements for initial purchase of new systems.

· No reclamation of space in block based storage (FC and iSCSI)

· Scheduling complications are now a reality. Avoiding periods of snapshotting, replication, archiving and general heavy work loads can be difficult.

· NetApp says “If there is very little new data, run de-duplication infrequently, because it doesn’t make sense to unnecessarily consume CPU resources.” http://www.netapp.com/us/library/technical-reports/tr-3505.html

·  De-duplication itself is free, but are SnapVault and SnapMirror?  Should I remind you that nothing in life is free.

De-dupe, like every other storage feature, whether its EMC, NetApp, DataDomain,etc, has its positives and negatives. Just make sure you as a customer look beyond the marketing wooglie booglie and understand the technology you are depending on.

One last thought, if you do decide to turn on NetApp 3D please take 10 minutes to fill out a “I told you so” form that releases any wrong doing from NetApp  when your performance dips below the equator, http://www.crn.com/storage/209901632, I kid you not….