# 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:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\
**Post date:** [May 7, 2020, 8:32am UTC](https://forum.storj.io/t/distributed-architecture-for-snos-for-high-availability-of-storage-nodes/6538/3 "2020-05-07T08:32:51Z")

</div>

The replication should be on other level - storage, not the application.  
We should not invent the wheel - you can use a Gluster or Cepf for that, which are robust these days and have a long history of development, it will be more reliable than introduce a replication on SN level, because we do not have an implementation of replication anymore.  
Your node can only spread pieces across the network during the Graceful Exit. I don’t think you want that in case of compute failure.

For the compute failure protection you can use a Kubernetes or Docker Swarm. Those solutions are proven in the production too.

I don’t think that we should re-invent those technologies in the SN, it will be more complicated and less reliable than a separate specialized solutions.

---

_[View the full topic](https://forum.storj.io/t/distributed-architecture-for-snos-for-high-availability-of-storage-nodes/6538)._