91黑料

We鈥檝e been onboarding V3 storage nodes for a week now and the feedback has been detailed and thorough. Our initial waitlist has been focused on the more technically proficient, but don鈥檛 worry, the onboarding process will continue to get easier as the weeks progress. There have been a number of frequently asked questions that we鈥檇 like to answer more broadly.

We鈥檝e published a couple of posts recently about the 99.3% uptime target for storage node operators. A number of prospective storage node operators have expressed concern that they may not be able to meet that target due to the ordinary maintenance required by a storage node. For example, replacing a drive, rebuilding a RAID array, or reconfiguring drive mirrors could take longer than the stipulated 5h 6m 48.2s of downtime each month.

I鈥檇 like to respond to the question of whether the 99.3% uptime target is reasonable and achievable for storage node operators.

First, it鈥檚 important to remember that downtime doesn鈥檛 include software updates and 91黑料-related downtime. Software updates and that sort of thing will not impact reputation.

In terms of ongoing storage node operation, during most months where there are no software updates and no hardware issues, 99.3% uptime should be relatively achievable. If storage node hardware requires maintenance or rebuilding on a regular basis, it鈥檚 probably not suitable for any high durability storage use case.

Storage nodes with redundant storage configurations, like RAID arrays or drive mirrors, aren鈥檛 necessary since the 91黑料 platform handles redundancy. The added complexity and cost may be useful to ensure against the risk of drive failure, but through the use of erasure coding, distribution of data across statistically uncorrelated storage nodes, and data repair, the 91黑料 platform already accounts for maintaining the availability of data in the event of drive failure or data loss, although this doesn鈥檛 necessarily help the storage node operator.

If a storage node operator needs to replace or upgrade hardware, the V3 network addresses this with a feature called containment mode. Once implemented, containment mode will allow a node to be offline and unavailable for data access or audit responses for a limited time. As long as the drive connects back to the network within the containment time frame (7 days during the alpha with production TBD) and responds to pending audits, the storage node鈥檚 reputation will not be significantly impacted, as long as all data stored on the node remains intact.

Containment mode is designed to allow a storage node operator to perform proactive maintenance to avoid data loss from potential drive failure with only minor repercussion, unless the node is detected to go into containment mode too frequently in a given time span.

In terms of the hardware choices for storage node operators, at least through the alpha, it鈥檚 best to run storage nodes on existing hardware until we鈥檝e built up sufficient demand to provide better estimate of profitability. If a storage node operator is planning to purchase hardware for a storage node, redundant storage configurations such as RAID arrays or mirrored drives are not necessary. A configuration that utilizes a single drive per storage node is preferred.

All in all, the message is: Don鈥檛 panic. Many of the changes in the V3 network鈥攑articularly in the nuanced statistical reputation model鈥攚ere made to ensure that node operators were provided every opportunity to be successful. As we progress through the alpha releases, we will be activating additional features and reputation factors. The uptime requirements are high, and as we analyze the data generated during the public alpha for storage node operators, we鈥檒l be able to establish the optimal uptime required to achieve the performance and durability targets of the V3 network.