Aetherstore, looks amazing, what about...
-
@dafyre said:
I've seen and heard about Aetherstore for a a while. It is very interesting what they are doing with it. Oddly enough, it seems eerily similar to a program from years ago called Medley 97 (which shared storage, as well as CPU and RAM between machines in a local network).
I'm glad to see things like this making their way back into modern times.
It is a lot more like Gluster.
-
I wonder how this would do (or even if it could be set up) as shared storage or CSVs for a windows failover cluster.
-
@dafyre said:
I wonder how this would do (or even if it could be set up) as shared storage or CSVs for a windows failover cluster.
No, it is not that kind of storage. How would you present it since it can't be shared as a SAN (iSCSI, FC, etc.)
Even if you could, it is not architected for that yet. Eventually this is a real possibility but not today.
-
The number of ways this could break catastrophically actually blows my mind!
You'd need a large dependable desktop fleet for this to make much sense. $0.02.
-
@MattSpeller said:
The number of ways this could break catastrophically actually blows my mind!
You'd need a large dependable desktop fleet for this to make much sense. $0.02.
It's quadruple mirrored network RAID 1. It's pretty reliable with minimal effort. And that's if you use stock drives. Do RAID 1 on the desktops and you move to RAID 1{1} at 4x2 mirroring (8 times total mirroring.)
-
@scottalanmiller said:
It's quadruple mirrored network RAID 1. It's pretty reliable with minimal effort. And that's if you use stock drives. Do RAID 1 on the desktops and you move to RAID 1{1} at 4x2 mirroring (8 times total mirroring.)
Good lord.
Wouldn't this exponentially increase your network traffic as well? Re-Sync'ing all those mirrors all the time? Yuck!
I'm a bit conservative on this one, I'll wait and see how it plays out.
-
@MattSpeller said:
Wouldn't this exponentially increase your network traffic as well? Re-Sync'ing all those mirrors all the time? Yuck!
This is why I'm after the scheduling, so it can only hog the network after hours.
-
@MattSpeller said:
Wouldn't this exponentially increase your network traffic as well? Re-Sync'ing all those mirrors all the time? Yuck!
Why would they resync? What are you picturing happening? It's block level replication. So they stay in sync. On a normal GigE switch network this would create completely unnoticed traffic for normal amounts of storage. Remember "network traffic" is a weird concept as this would only create traffic peer to peer amongst four nodes. So what network impact are you imagining?
-
@Breffni-Potter said:
This is why I'm after the scheduling, so it can only hog the network after hours.
I think that the idea of how much bandwidth is needed for storage is overestimated. GigE is enough for some pretty hefty SAN connections and we are talking about that just for change replication for non-primary storage. Unless you are doing something weird, traffic will be pretty small.
And, of course, replication happens when the storage happens. Run a backup at night and the sync is going to be at night too while the writes are going on.
-
@Breffni-Potter said:
This is why I'm after the scheduling, so it can only hog the network after hours.
I think what you want is just an RSYNC group.
-
@scottalanmiller said:
Why would they resync? What are you picturing happening? It's block level replication. So they stay in sync. On a normal GigE switch network this would create completely unnoticed traffic for normal amounts of storage. Remember "network traffic" is a weird concept as this would only create traffic peer to peer amongst four nodes. So what network impact are you imagining?
Re-sync was a bad term, they'd need to sync up any blocks that changed - absolutely. Ditto network, you're right it'd be peer to peer for most of it.
Maybe I've just not had my coffee, or something, but this whole concept gives me the creeps.
-
@MattSpeller said:
You'd need a large dependable desktop fleet for this to make much sense. $0.02.
Keep in mind that nothing makes you use this on a desktop rather than a server.
-
@MattSpeller said:
Maybe I've just not had my coffee, or something, but this whole concept gives me the creeps.
No different than most modern storage. This is exactly how Gluster or CEPH or Exablox work.
-
Not all of us are in GigE
Remember us 10/100 guys. -
@scottalanmiller said:
Keep in mind that nothing makes you use this on a desktop rather than a server.
I can't imagine it running smooth as butter over wifi without putting in some serious attention to detail.
This whole thing is super dependant upon very well setup fundamentals - working so much in SMB I just don't see it. I think this is more attractive in a larger business as a backup scenario or something like that.
-
@Breffni-Potter said:
Not all of us are in GigE
Remember us 10/100 guys.You should have NOTHING happening on your network. Actually, at those speeds I'd question even having users there
-
@Breffni-Potter said:
Not all of us are in GigE
Remember us 10/100 guys.IM NOT ALONE!
-
@MattSpeller said:
I can't imagine it running smooth as butter over wifi without putting in some serious attention to detail.
Why would you have wifi to desktops, outside of some really extreme cases?
-
@scottalanmiller Ah I wasn't clear - I can't imagine it running well on a fleet of laptops over wifi. Not without some serious I/O speed penalty.
-
@MattSpeller said:
This whole thing is super dependant upon very well setup fundamentals - working so much in SMB I just don't see it. I think this is more attractive in a larger business as a backup scenario or something like that.
Nearly all SMBs have Windows desktops and GigE networking. Wifi to desktops, no desktops, Linux desktops, FastEthernet... while all exist from time to time are all super rare. A normal SMB can implement this easily and reliably. No technology works for everyone. But this one definitely is targetted at a normal, traditional SMB.
