Hyper-V Failover Cluster FAILURE(S)
-
This post is deleted! -
@kyle said in Hyper-V Failover Cluster FAILURE(S):
@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):
@kyle said in Hyper-V Failover Cluster FAILURE(S):
We have slowly been getting our documentation as we run into it.
You mean you have extortion going on and no one has called the FBI yet? Why won't they give the docs?
We get them as we run into issues requiring the need for certain things. They essentially kept everything and only provided necessary information as needed. They were actually holding all MS licensing until the SR. Admin demanded they turn that over.
But just demand it all. By law, they have no options.
-
@kyle said in Hyper-V Failover Cluster FAILURE(S):
Essentially they are ensuring they are needed until the very end as the end game is to ensure all IT is brought in house instead of through a MSP.
Yes, that's called extortion and is very illegal.
-
This post is deleted! -
This post is deleted! -
This post is deleted! -
This post is deleted! -
I've only ever had a Drobo as a SAN for a backup target, so I have very little practical experience here - but I'd guess either the switch or the SAN itself is where the problem lies.
-
@dashrender said in Hyper-V Failover Cluster FAILURE(S):
@kyle said in Hyper-V Failover Cluster FAILURE(S):
@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):
@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):
@kyle said in Hyper-V Failover Cluster FAILURE(S):
Essentially they are ensuring they are needed until the very end as the end game is to ensure all IT is brought in house instead of through a MSP.
Yes, that's called extortion and is very illegal.
So if we know that there is extortion, we know that there is a federal crime afoot, and we know that the CEO would fire you if you exposed it... I think that puts some big pieces together.
I only believe that because I am only a contractor right now and the "New Guy". I have pointed out several issues and they are all known and we are addressing them slowly but it is so tedious.
My biggest concern is that our Hyper-V Cluster keeps failing after we made IP changes and they claim the two issues are unrelated.
I've only ever had a Drobo as a SAN for a backup target, so I have very little practical experience here - but I'd guess either the switch or the SAN itself is where the problem lies.
We have a DATTO backup agent.
-
Most common issue here is the SAN getting IO overload while doing snapshots.
-
@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):
Most common issue here is the SAN getting IO overload while doing snapshots.
Actually there is no overload per the logs.
-
This post is deleted! -
This post is deleted! -
Do the switches report any overloading? A huge backup at the L3 routing points could do this, but would be super uncommon. But SAN traffic should never be routed, ever, and this would be a reason for that.
-
This post is deleted! -
@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):
Do the switches report any overloading? A huge backup at the L3 routing points could do this, but would be super uncommon. But SAN traffic should never be routed, ever, and this would be a reason for that.
Switches are not reporting any errors either. We pulled all those logs and found no network errors or hardware failure.
-
Is there a single switch that handles all traffic for SAN(storage traffic) and failover and network traffic for these hosts?
What kind of connection does the switch have to the router?
-
@dashrender said in Hyper-V Failover Cluster FAILURE(S):
Is there a single switch that handles all traffic for SAN(storage traffic) and failover and network traffic for these hosts?
What kind of connection does the switch have to the router?
Due to a huge web of issues I couldn't tell you exactly how everything is connected but I do know the Servers and SAN's are on their own switches and then handed off to the LAN.
-
@scottalanmiller how critical, and if not critical - then recommended, is having SAN traffic on it's own switches, not shared with anything else?
-
@dashrender said in Hyper-V Failover Cluster FAILURE(S):
@scottalanmiller how critical, and if not critical - then recommended, is having SAN traffic on it's own switches, not shared with anything else?
Pretty critical. there is a reason that no one would ever try it any other way. SANs need low latency and you dont' want it waiting on a busy backplane. Also, a switch that is good for SAN is not good for the LAN and vice versa. So it wouldn't be cost effective to mix them anyway. Hence, it never comes up. No upsides, loads of downsides.
