上QQ阅读APP看书，第一时间看更新

Ask the right questions

Your goal as an architect is to make sure the workload is very clear. The intended use for the storage server defines how many resources need to be allocated. Failing to do so could result in resources being wasted that in turn means money being wasted, or, in a worst case scenario, could lead to a solution that does not perform to spec, which leads to applications failing and users not able to work.

Remember from the Chapter 1, Introduction to Design Methodology: ask the right questions. When sizing a storage solution, you can ask the following questions:

How much space does the current implementation consume (if there's one already in place)?
What are the performance requirements of the application?
How many users interact with the application?
Is high availability required?
How does the application store its data?
Does it create large files and append data to them?
Does it create a large number of small files?

Possible answers to these questions could be the following:

Right now, the application consumes 20 TB, but we expect it to increase 5% each month and stabilize at 80 TB.
The application requires at least 100 MB/s of throughput and a latency no higher than 10 ms.
Currently, about 300 users have access to the application; concurrently, we've seen peaks of 150 users, but we expect the user count to increase significantly.
We can sustain not being able to access the storage for some time, but we do need to be able to recover from a failure reasonably quickly, and could possibly have a copy of the data off-site.
The application primarily saves its information in small files.
It does not append data, and if more space is needed, it merely creates more small files.
Yes, we've seen several thousands of files created no bigger than 4 KB.

From the previous example, you can surmise that the application creates a lot of small files, and it can tolerate being down for some time but requires off-site replication for smooth disaster recovery. Performance requirements seem to be relatively high, so we could opt for a dispersed or distributed volume with geo-replication enabled.