Burned by Eschewing Best Practices
-
@Carnival-Boy said in Burned by Eschewing Best Practices:
But if you buy both services from the same provider, their automatically tied together, and you can never separate them? That doesn't make sense?
That's the only model available in most countries I've dealt with. There are some countries where this is the only model legal in the country! In the US and Canada, it's the only model available from ISPs, but not by law, just because the law doesn't force them not to do it.
-
@scottalanmiller said in Burned by Eschewing Best Practices:
@Carnival-Boy said in Burned by Eschewing Best Practices:
But if you buy both services from the same provider, their automatically tied together, and you can never separate them? That doesn't make sense?
That's the only model available in most countries I've dealt with. There are some countries where this is the only model legal in the country! In the US and Canada, it's the only model available from ISPs, but not by law, just because the law doesn't force them not to do it.
This is why we are suggesting that you MAKE SURE that you have actually truly divorced services, don't just assume you do.
-
OK. I think I follow you all. It may well be the case with BT and other UK ISPs, I really don't know.
-
@Carnival-Boy said in Burned by Eschewing Best Practices:
So you're saying the rule is that your internet pipe/leased line should be a separate contract to your SIP trunk.
Not quite. It might manifest itself that way, but that certainly isn't guaranteed or even likely with that scenario. That exact wording in many (most?) locations would still be fully coupled.
It's that the two should be fully decoupled. Absolutely nothing that happens with one, including legal dispute, billing dispute, physical changes, service changes, account mistakes, etc. should have the ability to influence the other. If one "company" can truly act as two independent companies with the two services being truly decoupled, you can make a strong case that your trunk and your ISP are not from the same vendor, even though they share a parent.
This would be akin to buying a couch from Nebraska Furniture Mart and shipping it on BNSF. Yes, the same company owns both of those companies, but those two companies don't comingle data or accounts.
-
@scottalanmiller said in Burned by Eschewing Best Practices:
This would be akin to buying a couch from Nebraska Furniture Mart and shipping it on BNSF. Yes, the same company owns both of those companies, but those two companies don't comingle data or accounts.
nice
-
I buy my couches from Ikea. And call them settees.
-
I'm putting this here in case of future burn:
https://www.itnews.com.au/news/sa-health-takes-disaster-recovery-gamble-to-save-money-465730South Australia's Health department has decided not to implement a secondary site for disaster recovery with its new state-wide pathology system in an effort to save costs from a project that is running late and over budget.
State wide... Expected cost of $40 million... Dropping plan for DR site...
-
So this is a system that does centralized pathology computing for the entire state?
-
@scottalanmiller said in Burned by Eschewing Best Practices:
So this is a system that does centralized pathology computing for the entire state?
I believe so.
-
@nadnerB said in Burned by Eschewing Best Practices:
@scottalanmiller said in Burned by Eschewing Best Practices:
So this is a system that does centralized pathology computing for the entire state?
I believe so.
Okay, that does seem pretty foolish then. Assuming that just having the computer system online is valuable should the site fail.
-
Potential IPOD in the works for a mere 43TB.
-
@DustinB3403 said in Burned by Eschewing Best Practices:
Potential IPOD in the works for a mere 43TB.
Mere?
Someone's perspective seems odd.
-
@Dashrender said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
Potential IPOD in the works for a mere 43TB.
Mere?
Someone's perspective seems odd.
Really it is a mere 43TB. Not until you're in the 100's of TB range should SAN's even be considered. Which this is where you start to reach the limit of single servers.
-
@DustinB3403 said in Burned by Eschewing Best Practices:
@Dashrender said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
Potential IPOD in the works for a mere 43TB.
Mere?
Someone's perspective seems odd.
Really it is a mere 43TB. Not until you're in the 100's of TB range should SAN's even be considered. Which this is where you start to reach the limit of single servers.
The size of data isn't really a limiting factor. It's the number of hosts that need to share the storage.
-
@stacksofplates said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
@Dashrender said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
Potential IPOD in the works for a mere 43TB.
Mere?
Someone's perspective seems odd.
Really it is a mere 43TB. Not until you're in the 100's of TB range should SAN's even be considered. Which this is where you start to reach the limit of single servers.
The size of data isn't really a limiting factor. It's the number of hosts that need to share the storage.
Sure, but I can fit that much storage into a single server and be within the tolerances set by the OP.
So while he is downsizing to 2 servers, 1 is all that he might actually require. Assuming SA is good enough.
-
@stacksofplates said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
@Dashrender said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
Potential IPOD in the works for a mere 43TB.
Mere?
Someone's perspective seems odd.
Really it is a mere 43TB. Not until you're in the 100's of TB range should SAN's even be considered. Which this is where you start to reach the limit of single servers.
The size of data isn't really a limiting factor. It's the number of hosts that need to share the storage.
There is no reasoning as to why the OP thinks he needs a SAN other than it's what he had before and is familiar with. So that reason right there is a "red herring" and immediately means he should welcome outside review before purchasing anything.
Assuming he had 100 TB of storage across 3 servers he could go with scale or starwind's vsan and still be way better off than with the SAN.
-
@DustinB3403 said in Burned by Eschewing Best Practices:
@stacksofplates said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
@Dashrender said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
Potential IPOD in the works for a mere 43TB.
Mere?
Someone's perspective seems odd.
Really it is a mere 43TB. Not until you're in the 100's of TB range should SAN's even be considered. Which this is where you start to reach the limit of single servers.
The size of data isn't really a limiting factor. It's the number of hosts that need to share the storage.
Sure, but I can fit that much storage into a single server and be within the tolerances set by the OP.
So while he is downsizing to 2 servers, 1 is all that he might actually require. Assuming SA is good enough.
The point was the statement you made was definitive statement without any relation to the OP. If you said "in this case" fine. But it was just a blanket statement.
-
@stacksofplates said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
@stacksofplates said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
@Dashrender said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
Potential IPOD in the works for a mere 43TB.
Mere?
Someone's perspective seems odd.
Really it is a mere 43TB. Not until you're in the 100's of TB range should SAN's even be considered. Which this is where you start to reach the limit of single servers.
The size of data isn't really a limiting factor. It's the number of hosts that need to share the storage.
Sure, but I can fit that much storage into a single server and be within the tolerances set by the OP.
So while he is downsizing to 2 servers, 1 is all that he might actually require. Assuming SA is good enough.
The point was the statement you made was definitive statement without any relation to the OP. If you said "in this case" fine. But it was just a blanket statement.
Semantic police are in force today. . . .
-
@DustinB3403 FFS, the size of the data has nothing to do with the need for a SAN.
If you need more data than you can fit in a 4U box, then you buy a DAS to connect to your box to get more storage. Or you look at multiple boxes with local storage and then a vSAN or something to get the storage amount you need.
You use a SAN when you need lots of hosts on the same set of data.
-
@DustinB3403 said in Burned by Eschewing Best Practices:
@stacksofplates said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
@stacksofplates said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
@Dashrender said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
Potential IPOD in the works for a mere 43TB.
Mere?
Someone's perspective seems odd.
Really it is a mere 43TB. Not until you're in the 100's of TB range should SAN's even be considered. Which this is where you start to reach the limit of single servers.
The size of data isn't really a limiting factor. It's the number of hosts that need to share the storage.
Sure, but I can fit that much storage into a single server and be within the tolerances set by the OP.
So while he is downsizing to 2 servers, 1 is all that he might actually require. Assuming SA is good enough.
The point was the statement you made was definitive statement without any relation to the OP. If you said "in this case" fine. But it was just a blanket statement.
Semantic police are in force today. . . .
No, you are wrong and are being called out on it.
