EMC SourceOne Bandwidth Issues
I have a customer that recently implemented EMC SourceOne Archiving solution. In all sites, but one the client is running great. Unfortunately the office having the issues houses the CFO, CEO and President of the company. The office has a 1.5M T1 connection to the remote site housing the Exchange Server, as well as the SourceOne Management Server.
In this particular office when SourceOne is running we see a 100% saturation of the 1.5M T1 line causing other applications in the office to have latency issues. On a normal day to day basis without SourceOne running, the connection hovers around 500 to 600k.
There are 4 clients is this office that require SourceOne. Currently just a single client can cause the results mentioned above. Has anyone seen this type of behavior before? The mailboxes were cached at the remote site housing the Exchange Server, as well as the SourceOne Management Server before bringing them online in the office they were to be used. Unfortunately we are still seeing SourceOne doing something in the background to cause network latency.
We are currently working with EMC, but unfortunately we have not seen any progress. I apologize if my description is not very clear. If more information is needed I would be glad to provide it. I will also say that I know next to nothing about SourceOne aside from the minimal exposure during the troubleshooting efforts. Any help would be greatly appreciated.
Thanks,
--Mick--
In this particular office when SourceOne is running we see a 100% saturation of the 1.5M T1 line causing other applications in the office to have latency issues. On a normal day to day basis without SourceOne running, the connection hovers around 500 to 600k.
There are 4 clients is this office that require SourceOne. Currently just a single client can cause the results mentioned above. Has anyone seen this type of behavior before? The mailboxes were cached at the remote site housing the Exchange Server, as well as the SourceOne Management Server before bringing them online in the office they were to be used. Unfortunately we are still seeing SourceOne doing something in the background to cause network latency.
We are currently working with EMC, but unfortunately we have not seen any progress. I apologize if my description is not very clear. If more information is needed I would be glad to provide it. I will also say that I know next to nothing about SourceOne aside from the minimal exposure during the troubleshooting efforts. Any help would be greatly appreciated.
Thanks,
--Mick--
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Very strange...
Well. Until you know what process is using the bandwidth and where the remote data is going there’s not a whole lot you can do.
Tools like Microsoft systernals tcpview and Process Monitor running while the issue is occurring may shed some light on these unknowns.
But without any information you could try this.
If you are able to identify the target where the data is being sent to/from, and the process creating the connection is using DNS then you could try a trick like editing the host file of the server to give the DNS target a dummy IP address. This way each time the process attempts to start (causing all the bandwidth to get used) It will not be able to connect to the remote host and fail.
Well. Until you know what process is using the bandwidth and where the remote data is going there’s not a whole lot you can do.
Tools like Microsoft systernals tcpview and Process Monitor running while the issue is occurring may shed some light on these unknowns.
But without any information you could try this.
If you are able to identify the target where the data is being sent to/from, and the process creating the connection is using DNS then you could try a trick like editing the host file of the server to give the DNS target a dummy IP address. This way each time the process attempts to start (causing all the bandwidth to get used) It will not be able to connect to the remote host and fail.
ASKER
We do know that the target the remote hosts are connecting back to is the primary exchange server. The problem is that we have been unable to identify what process is causing this connection to utilize the full 1.5M T1 connection.
We also have not noticed any sort of updating on the client side that can help with the identification when the bandwidth is being crushed. We have tried enabling logging on the client side as directed by EMC, but unfortunately EMC has not been able to determine anything from the logs.
--Mick--
We also have not noticed any sort of updating on the client side that can help with the identification when the bandwidth is being crushed. We have tried enabling logging on the client side as directed by EMC, but unfortunately EMC has not been able to determine anything from the logs.
--Mick--
ASKER
LITUP
It appears that S1 was functioning properly and that the T1 connection just could not handle S1 as well as the rest of their applications. Being that what you mentioned first in this thread is what we did at first to limit the replication impact of S1 on our network, I will give you the points. Thanks for your comments.
It appears that S1 was functioning properly and that the T1 connection just could not handle S1 as well as the rest of their applications. Being that what you mentioned first in this thread is what we did at first to limit the replication impact of S1 on our network, I will give you the points. Thanks for your comments.
ASKER
This does limit the initial bandwidth impact S1 would have when archiving emails. It turns out the network connection we are running on can not support this application as is.
ASKER
I did fail to mention that we have tried this as well with no results. We have tried to let the machines sync at night, as well as on the weekends with no results. The issues does not happen every day nor does it happen on the same days. It really is a hit or miss type issue that makes it difficult to reproduce for EMC support.
Thanks for the comment.
--Mick--