The RepliStorExchange module you are using has become the old method of performing the failover with ReplIStor and Exchange.
With ReplIStor 6.2, there is a version 2 of the RepliStorExchange module. This version proves for a much better and natural method of failing over Exchange.
How long have you left the Source server before peroforming the DeleteDataDir? Does the Target site get Blocked or are you trying to 'clean' things up immediately after?
Typically, you would not want that much data in the Kernel Cache on a failover. If you have that much, it means ~330 MB in changes have not been replayed on the Target, which is now the new production machine.
Although the test you are doing is intereting to see what is going to happen upon a failover, it is not consisitent with the way RepliStor handles the I/O on a machine. If you have 330MB in the Kernel Cache/Logs, then it means either your bandwidth is not sufficient for what you are try to accomplish. Or, you simply overloaded the box with "not so practical" I/O and did the failover.
dramjass
151 Posts
0
April 12th, 2007 06:00
With ReplIStor 6.2, there is a version 2 of the RepliStorExchange module. This version proves for a much better and natural method of failing over Exchange.
How long have you left the Source server before peroforming the DeleteDataDir?
Does the Target site get Blocked or are you trying to 'clean' things up immediately after?
Typically, you would not want that much data in the Kernel Cache on a failover. If you have that much, it means ~330 MB in changes have not been replayed on the Target, which is now the new production machine.
Although the test you are doing is intereting to see what is going to happen upon a failover, it is not consisitent with the way RepliStor handles the I/O on a machine. If you have 330MB in the Kernel Cache/Logs, then it means either your bandwidth is not sufficient for what you are try to accomplish. Or, you simply overloaded the box with "not so practical" I/O and did the failover.