New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
@gisadik: Your TOS does sound rather militaristic. By the way, regarding:
$75 to change the email address of the account? Is this standard practice? (Name or owner, I get, though in the case of a legal name change of a customer, $75 seems harsh.)
Don't ever change. The patented Incero brand of no-nonsense complaint and abuse handling is a delight.
Here's a little exercise if you're interested. Do a side-by-side reading of your TOS + AUP ( https://speedykvm.com/tos.html ) and RamNode's TOS ( https://clientarea.ramnode.com/tos.php ) + AUP ( https://clientarea.ramnode.com/aup.php ). The tone is definitely different (sometimes the content as well).
Stable,
no VEHICLE ROLL OVER.
It's bad enough to need ASICs or at the very least FPGAs. Keep in mind that math is an ideal realm but disks are not. You, want, for instance reasonable stripe sizes which quickly make your GF calculations very burdensome on the cpu (hence you want it done in ASICs).
As for R5 and R6: It's funny to see how well marketing works. Even most seasoned admins believe that R6 is much more safe than R5. Well, I have bad news: It is not.
The problem beneath that is that we actually have different variables. One is the beauty of having 2 syndromes (typ. plain xor and xor over GF) which promises to afford losing even 2 drives. The other one, however, is that the basic risc calculation still holds, namely "more disks -> higher risk of n disks failing".
If you look at the equations you'll find that the failure calculation for R5 and R6 have a major part in common with the only difference being that R6 has a higher power factor (for the same amount of net disks/payload disks). So, for instance for 4 payload disks R5 add 1 disks (power factor 5) while R6 adds 2 (power factor 6).
And, in fact, looking only at the R5 part of the equation, we find that failure rate for R5 is lower for the a.m. reason (1 - r to the nth power is lower with increasing n). But there is the other part of the equation, the R6 only part, which may (or not, depending on the values) make up for the loss. That part basically comes down to a term we already know from the R5 equation part - but times some factor that is depending on the number of disks!
That is the funny part (n/2 * r² ...), that is where the music plays and where R6 gains over R5 - or not, depending on the number of disks.
Now, keep in mind that our context here is storage VPS, i.e. lots and lots of reasonable safe storage at reasonable costs.
All in all, it will usually be considerably less expensive both in $ and in computing power to have 2 R5 rather than 1 R6 - and - offer very similar (low) failure rates. As a positive side effect you gain better throughput in a very heterogenous context like VPS nodes. Note: R5 and R6 failure rates are typically very similar and within 1%.
There is btw. yet another factor that is often overlooked: hot spares. If you have a hot spare (and a decent controller) you get with R5 all but de facto R6 quality with very simple means and at lower cost.
That summed up my entire sysadmin career.
That looks to be outweighed by the higher redundancy.
N discs, each has a probability of failure p on a given day. So probability of 2 failures = p2 = N(N-1)p**2. With Raid-5, 2 failures means you lose all your data.
Probability of 3 failures out of N+1 discs = p3 = (N+1)N(N-1)*p**3. That's what has to happen to raid-6 array to be lost.
So with p=0.001, N=5, p2 = 2e-5, and p3=1.2e-7.
With N=10, p2=9e-5, p3=9.9e-7.
Raid-6 with 2 ECC drives looks way better. And of course you can do raid-6 with 3 or more ECC drives.
$191.80 / 36 ~= $5.33 ~= 4.73E/month for 2TB.
Which makes it ~2.37 Euro per month per TB (with KVM, 5GB RAM and 2x CPU, 10GB Xfer, 4Gbps, RAID 60).
Add that we all know that @SpeedyKVM is a very decent host.
So, 5E/TB sounds like double price, not dirt cheap.
/cc @AnthonySmith
You know as well as I do that those responding to the survey aren't prepared to pay up three years in advance to get the pricing they're asking for.
Fair point
Nice calculations
so on that basis with licenses and fee's, he only needs to fill around 28 nodes to make minimum wage for 1 person. not a business model I would like to pursue personally 
I'll take "How to become VortexNode" for 100, Alex.
Francisco
I totally get your point and I'm not saying you're wrong in any way in your business strategy.
My point is that sometimes there exist edge cases that combine amazing value without significant "summerhost" danger. The whole fun in LET is getting them
For example in this case, if I remember correctly, they had these very few nodes paid-out from a project that had ended and wanted to fill them asap, hence they did a special.
Well he says he's using disks that were upgraded from other users' dedis, so they're already at least partly paid down; on the other hand, smaller disks = more of them, so more nodes.
New raw disk space these days is (round off to) $36/TB or $1/month when spread over 3 years. If you can sell it for $3/month while getting the person to pay the full 3 years up front, you're getting $2/month on a hopefully low activity, midrange VPS not counting the disk. This seems kind of doable, (added:) especially with the capital outlay already mostly covered by the 3 year payment.
Storage plans (non-vps) at Hetzner and Online are around 5 euro/month/TB as regular products and I like to think they're making money at those prices.
Fair enough, the worry now is that some 15 year old (physically or mentally) reads this post and thinks wow I can make an extra $300 p/month pocket money, they do it for 6 - 9 months and are super happy because they now have the best scooter on the block.
Meanwhile that price point becomes the norm and people start expecting actual stable business to compete with it, sadly we just can't compete with pocket money hosts.
You are right though, there are edge cases like this which I am sure are completely stable and reliable, just perhaps not repeatable long term.
I'm almost 37 now, i can't help getting more grumpy and cynical with age, its genetic.
Not really. R5 or 6 addresses the question what happens if any disk fails. However, there is another question first, namely whether (and with what probability) a disk fails.
That question is completely independent of R5 or R6. Btw. those calculations are typically (and reasonably) done per year or over the life cycle (typ. 30 - 36 months) and not for days.
The other issue is that while the failure rate tends towards 0 with more elaborate - and more expensive in every regard - raid it doesn't become 0, so there is always a risk remaining (which is why we need backup, no matter what raid we use).
We can have many funny discussion but at the end of the day R6 is not considerably more safe/resilient than R5 in the usual scenarios (4-12 disks in a group) and with typical disk failure rates. In fact, using good disks increases overall resilience by far more than R6 vs R5.
And again, while raid can help to mitigate the problem, the failure rate of the disks exists independently and increases with more disks (and, of course, over time).
The error you and many make is to assume that the risk of 3 disks failing at roughly the same time is much smaller than 2 disks failing at roughly the same time. That seems to be true (and theoretically is) but (practically) is not because the disks failure risk is distributed over the (reasonably) expected life time - unless there is an extra factor, such as a major power spike, which, however, then tends to fry all disks.
In the end it comes down to the fact that neither R5 nor R6 offer 100% resilience and how much one is willing to spend to minimize the risk from, say 4.5% to 3.8%; well noted at rapidly increasing cost.
On the other hand one can with modest effort buy reliable disks for little or no extra cost in the first place, which can make a difference that by far outweighs the difference between R5 and R6. Plus, there are other levers to use; good smart monitoring and replacing worn out disks is but one example.
Whatever, I merely did the math and kept concrete experience in mind. While I like to spoil marketing lies I'm not interested in evangelizing, so if you prefer R6 I certainly won't try to draw you away.
Have you got any actual observable numbers to back this up?
For R6 vs R5 we have the math. Running Prolog over the tight domain gives clear answers.
As for the disk reliability there are some studies out there. One better known one is from blaze something (sorry, forgot the name). They clearly show that within a given class, say, 2TB - 3TB disks, there are very considerable differences (> 100%).
One caveat, though: Usually they are based on over-1-year numbers which can be misleading as the failure rate obviously grows over time, i.e. a new drive has a lower failure risk than the same model after 2 years continuous usage.
I've been using zxhost for a couple of years and it has served me well with good communication from Ashley if things do go wrong. It's not the cheapest but prefer to pay bit more for peace of mind.
We either share the same genetics or this is quite a normal development for everyone with a brain watching this world for more than 30 years.
Probably a bit of both.
You're talking about Backblaze disk reports, which are eagerly read by storage nerds. They found that certain models of HDD made during the Thai flooding area absolutely sucked, and there are significant but smaller failure rate differences among other makes and models.
They don't use raid 5. Sure there's higher and lower probabilities of a drive failing, but it's always less likely that two drives will fail simultaneously, than just one drive failing.
Has anyone here ever heard of a raid-6 storage array being lost due to multiple drive failures, especially failure of more than 2 drives? I've heard of some lost from controller failures, but that's different. Raid-5 arrays have been lost from double failures often enough that raid-6 had to be invented.
Online.net's enterprise C14 product spreads data across something like 50 drives with 20 of them redundant.
there is more and more recent data available. The situation was evidently not limited to the time of the flooding.
It's irrelevant whether they use Raid as the drive failure rate is independent of Raid.
You just love R6? Great, no problem with me. Use R6 to your liking.
My interest, however, isn't in favouring or disliking any Raid type but rather to make a well informed decision based on data and math and to find the best solution for any given situation. Sometimes that will be R6 but more often it will not.
The math is clear. The data strongly suggest that choosing a good disk model does by far outweigh R6 vs R5.
So, let's look at the math and data:
What we learn is:
the more disks in a raid array, the higher the failure rate. Raid can deal with failing disks but it can't change the physics of disk drives.
the other major factor, just as I said, is disk quality.
R5 vs R6 doesn't make all that much difference. Typically R6 gives you less than 1% better array failure rate.
Ergo: The best (most resilient, least failure prone) way to do things is to
R6 is better than R5 in terms of administration. While the failure rates over lifetime are very similar, R6 offers more breathing room ~ less pressure in exchanging a failed disk and rebuilding the array. On the other hand R5 can be rebuilt considerably quicker and is generally much cheaper. Hence, iff you have tech hands available round the clock and are in the low market end, you might prefer R5 and achieve very comparable resilience.
As a customer, particularly with sensitive data, you'll want a hoster with known to be good and quick support and R6 just in case. And you'll want a hot standby drive.
P.S. The setlX code is available upon request. It uses well established formulas.
What's setIX? And what's "r" in that chart? I'll look at the rest of the post later.
A modern and extended version of setl. Strong set theoretical support, good math support, etc.
It's not that the computation couldn't be made in Python or whatever, too, but setlx (like prolog variants) are widely used and come in handy for "scientific spread-sheeting", domain exploration, formal modelling, etc.
Fine, what is r and what are those numbers of disks? Does the first row mean 3 data disks, plus 1 or 2 (depending on raid level) parity disks? The calculation looks mysterious.
r is commonly used for the failure rate for a given time (commonly 1 year) and is supposed to be the same for each of the disks in an array.
The number of disks is the total (incl. payload and syndrome(s)). So n=6 means a total of 6 drives of which 5 are payload w/R5, 4 are payload w/R6. That's also the standard way to calculate it.
Mysterious? Nope. The calculation is the standard formulas for R5 and for R6.
R5: '1 − (1 − r)n − nr (1 − r)n−1'
R6: same as R5 with added '- (n/2) * r**2 * (1 - r) ** n-2'
So in the first row of the table, r=0.01 is probability of any drive failing in relevant period (1 year), raid-5 is 2 data disks and 1 parity disk, while raid-6 is 1 data disk essentially replicated 3 times. And you're saying raid-6 has only half the failure likelihood of raid-5 I think your math is off. The raid-5 is killed by any 2-drive failure while killing raid-6 requires a 3-drive failure. So I think your math is off. r-cubed is much less than r-squared and that swamps effects of the small constants out front.
Also you can't treat all failures in 1 year as simultaneous. Drive 1 fails and is rebuilt/replaced, then later drive 2 fails/is rebuilt/replaced, is much different than drive fails, then during the rebuild drive 2 fails. So r is effectively even smaller.
More of an issue is (as you said elsewhere) failures tend to be correlated (drive age etc.) and also a raid rebuild on an active server stresses drives a lot, increasing failure likelihood.
I don't think the many large and careful users of raid-6 arrays are being stupid and only need to be shown their error by you, anonymous internet person. It still looks to me like you're the one in error.
Willie, I'm sorry, but you are wrong.
RAID-5 = a number of drives, where 1 the capacity of 1 drive is used for storing parity data (round robin on all of the drives).
RAID-6 = a bit like RAID-5, accept using the capacity of 2 drives. And storing parity double.
Check: https://nl.wikipedia.org/wiki/Redundant_array_of_independent_disks#RAID-5
I'm specifically describing the 1st row of bsdguy's table, i.e. a 3-drive array.