This discussion trivializes some of the fine points, but was an enabler for massive growth in the Usenet market, which went from an average of 7 days retention back in ~2000 to more than two thousand days retention at some providers today.
Further, when you need to rebuild server0's disk, the data is evenly distributed in bank 1 so you aren't pounding them to do the rebuild.įurther, since it is more likely that a single disk would die than an entire server, you also apply different distribution functions to the individual disks, so that you can always reliably know where all the data in your spools ought to be, but if you look at the destination servers and disks in bank 0 and bank 1, they're always on different disks and servers so that if you need to rebuild a disk or server, the load is evenly spread out. So now if server0a fails, the load only increases by maybe 15-20% on the servers in bank 1. So instead what you do is you use a different allocation function so that the data on server0a ends up 1/6th on server1a, 1/6th on server 1b, 1c, 1d, 1e, and 1f. right until server0a fails and the load on server1a DOUBLES. The naive solution is to "mirror" them so that the content on server0a is the same as what's on server0b. So let's say you had a design where you had two sets of spools, server bank 0, letters a-f, and server bank 1, letters a-f, each with 16 drives. As EIDE grew old and SATA became available, the largest cheapest per byte hard drives available were SATA, not SCSI. The goal is to keep a server as cheap as possible.
#Backblaze storage pod for sale how to
So the two choices are to try to figure out how to attach lots of storage to a single massive server or figure out how to do distributed storage.
:Ĭonsider a massive Usenet provider around the year 2000 with terabytes of disks. We called this design a "Redundant Array of Inexpensive Servers". There shouldn't be "another," there should be "all the others."
0 kommentar(er)
