# Distributed architecture for SNOs for high availability of storage nodes

**URL:** <https://forum.storj.io/t/distributed-architecture-for-snos-for-high-availability-of-storage-nodes/6538>\
**Category:** Storage Node feature requests - voting\
**Created:** [May 7, 2020, 7:14am UTC](https://forum.storj.io/t/distributed-architecture-for-snos-for-high-availability-of-storage-nodes/6538 "2020-05-07T07:14:50Z")\
**Posts on this page:** 9\
**Page:** 3

<div class="post-metadata">

**Author:** ![cdhowie](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/cdhowie/32/60_2.png) [@cdhowie](https://forum.storj.io/u/cdhowie)\
**Post date:** [May 8, 2020, 7:07pm UTC](https://forum.storj.io/t/distributed-architecture-for-snos-for-high-availability-of-storage-nodes/6538/44 "2020-05-08T19:07:45Z")

</div>

> [@peem](#):
>
> The larger “surface” of the disk, however, does not give 1.5x the potential income

Of course it does. Otherwise what is the difference between running a 1TB node and a 10TB node? We should all run 1TB nodes if there is no difference.

A 10TB node has approximately 10x the potential income of a 1TB node. Of course not all pieces will generate the same amount of egress traffic, but if we assume both nodes have filled up, the 10TB node is almost certainly going to be generating more egress traffic than the 1TB node unless the 1TB node got really lucky and is storing many “hot” pieces.

---

<div class="post-metadata">

**Author:** ![peem](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/peem/32/6323_2.png) [@peem](https://forum.storj.io/u/peem)\
**Post date:** [May 8, 2020, 7:56pm UTC](https://forum.storj.io/t/distributed-architecture-for-snos-for-high-availability-of-storage-nodes/6538/45 "2020-05-08T19:56:18Z")

</div>

We were talking about RAID5 3x6TB - versus - 3 nodes with 6TB disk …  
Not 10TB - versus - 1TB …

Let’s not argue, I highly value your opinion on various issues, but here I disagree with you 🙂

---

<div class="post-metadata">

**Author:** ![cdhowie](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/cdhowie/32/60_2.png) [@cdhowie](https://forum.storj.io/u/cdhowie)\
**Post date:** [May 8, 2020, 7:58pm UTC](https://forum.storj.io/t/distributed-architecture-for-snos-for-high-availability-of-storage-nodes/6538/46 "2020-05-08T19:58:05Z")

</div>

We’re talking about 12TB vs 18TB. Once the 12TB fills up, the 6TB of redundancy is just wasted. 🙂

---

<div class="post-metadata">

**Author:** ![Toyoo](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/toyoo/32/1126_2.png) [@Toyoo](https://forum.storj.io/u/Toyoo)\
**Post date:** [May 9, 2020, 12:03am UTC](https://forum.storj.io/t/distributed-architecture-for-snos-for-high-availability-of-storage-nodes/6538/47 "2020-05-09T00:03:51Z")

</div>

> [@Pentium100](#):
>
> - The new node will start empty.

If I had enough space and cared about that, I’d probably run X+2 nodes on X hard drives, with the last two nodes of minimal size. If one node fails, I’d have a pre-vetted node on another drive to move and start again. This approach reduces the risk of losing time on vetting again.

---

<div class="post-metadata">

**Author:** ![Toyoo](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/toyoo/32/1126_2.png) [@Toyoo](https://forum.storj.io/u/Toyoo)\
**Post date:** [May 9, 2020, 12:18am UTC](https://forum.storj.io/t/distributed-architecture-for-snos-for-high-availability-of-storage-nodes/6538/48 "2020-05-09T00:18:01Z")

</div>

> [@Cmdrd](#):
>
> I guess the biggest point here is that this is a lot of effort for Storj Labs to implement for an incredibly small subset of SNOs. There are probably only a handful who are running large enough setups to really see any benefit out of this that it just isn’t worth it to develop.

If Tardigrade becomes successful, in my opinion the effect of economy of scale will likely make most of storage space be operated by large SNOs. Then these features will probably show up, whether coded by Storj or independently, as there will be money in this work.

---

<div class="post-metadata">

**Author:** ![Toyoo](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/toyoo/32/1126_2.png) [@Toyoo](https://forum.storj.io/u/Toyoo)\
**Post date:** [May 9, 2020, 12:18am UTC](https://forum.storj.io/t/distributed-architecture-for-snos-for-high-availability-of-storage-nodes/6538/49 "2020-05-09T00:18:54Z")

</div>

> [@Pentium100](#):
>
> At some point during the alpha stage IIRC someone asked how to compile the node from source and the answer was that you cannot - there were some settings required that were not published or something.  
> I may not remember it correctly though.

I was operating a self-compiled node a month ago. It was pretty simple to compile for Linux, though I did not bother packaging it into docker.

---

<div class="post-metadata">

**Author:** ![Cmdrd](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/cmdrd/32/1128_2.png) [@Cmdrd](https://forum.storj.io/u/Cmdrd)\
**Post date:** [May 9, 2020, 1:40am UTC](https://forum.storj.io/t/distributed-architecture-for-snos-for-high-availability-of-storage-nodes/6538/50 "2020-05-09T01:40:52Z")

</div>

> [@Toyoo](#):
>
> If Tardigrade becomes successful, in my opinion the effect of economy of scale will likely make most of storage space be operated by large SNOs.

You are correct, but there are still a lot of other scalable and redundancy measures that should be put in place to accommodate that level of scale. Just Kubernetes along with a fault tolerant storage backend can fill this to a pretty significant extent. Would really only become a valuable addition to the application once an individual storage node is storing more data than one can easily do on a small cluster of systems. Even then, this is still going to be a lot of work to abstract the separate storagenode components to be scalable for a small handful of storage nodes.

I’m not saying that this idea is not a good one, I would be fully supportive of seeing something like this as an SNO who already has nearly redundant everything in my infrastructure stack. It’s just that there are so many other measures that can be taken to accomplish a very similar end result with the exception of a redundant database layer with Storj Labs not having to put in any additional engineering.

---

<div class="post-metadata">

**Author:** ![Pentium100](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/pentium100/32/6082_2.png) [@Pentium100](https://forum.storj.io/u/Pentium100)\
**Post date:** [May 9, 2020, 8:55am UTC](https://forum.storj.io/t/distributed-architecture-for-snos-for-high-availability-of-storage-nodes/6538/51 "2020-05-09T08:55:15Z")

</div>

Good to know, thanks. I saw that a long time ago and then didn’t ask anymore. I guess I should look into it when I have time.

---

<div class="post-metadata">

**Author:** ![SGC](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/sgc/32/1132_2.png) [@SGC](https://forum.storj.io/u/SGC)\
**Post date:** [May 9, 2020, 9:26am UTC](https://forum.storj.io/t/distributed-architecture-for-snos-for-high-availability-of-storage-nodes/6538/52 "2020-05-09T09:26:47Z")

</div>

> [@cdhowie](#):
>
> We’re talking about 12TB vs 18TB. Once the 12TB fills up, the 6TB of redundancy is just wasted. 🙂

yeah raid in the 3x6tb raid5 example the raid mitigates the somewhere between 1% and 90% chance that one drive might fail in a year… but lets call it 1.5to 6%

ofc it does reduce your theoretical max earnings by 1/3… so i really becomes an question if your drive has more than 30% chance to fail… and if 1/3 fails then you also only lost 33% not 100%

if you got 8 drives in a raid6 then you have somewhere between 4% to 16% chance of annual failure and loss of all of your data… while you would with a set of 8 drives only have 0.5 to 2% chance of loosing atleast 1 drives , which would loose you 1/8th so still less than what the 25% cost of the raid redundancy

but its getting closers, the higher we get the ratio of disks to redundant disks, the less cost… but then we end up running raid arrays that are like raidz2 / raid6 on 12 arrays…  
which is just painful… but it’s very economical in its loss of capacity…  
meanwhile having 12 drives you will be up to 6-24% chance of disk failure a yearand you are paying just about the same…  
24 and 2 redundant and you are home… but well… arrays like that can take many months to resilver / rebuild a lost drive… so odds are you will lose drives faster during resilvering because of the added strain, and thus you end up actually going beyond what makes the raid setup safe…

so yeah for most people running seperate nodes seems to be the way to go…  
tho there is something to be said for raid performance when its setup right… one has to keep in mind it gives you access to have vast dataset and manage them with thousands of users… a regular hdd is most often made to supply 1 or a few people with data over limited time spans.

[Previous page](https://forum.storj.io/t/distributed-architecture-for-snos-for-high-availability-of-storage-nodes/6538.md?page=2)
