Requires Free Membership to View
When you register for SearchVirtualStorage.com, you’ll also receive targeted emails from my team of award-winning editorial writers. Every flavor of virtualization project – server, storage, desktop, file – offers challenges and rewards to the storage manager, and it’s our goal to ensure you’re up-to-date on the latest tips, trends and technologies that can help you overcome these roadblocks.
Rich Castagna, Editorial DirectorThere is no hard and fast rule for the right number of volumes. Like most things, you need to balance a number of factors:
- Having more volumes gives you more granularity and more flexibility at the cost of having more things to manage and a bit more overhead.
- Having fewer volumes gives you fewer things to worry about, but causes a larger community to be affected any time something goes wrong or changes.
Here are some of the things you might look at to make this decision:
- The contents of each volume are pretty much bound together from a backup/archive perspective. This means as the volumes grow larger these operations take longer to complete.
- Applications differ widely in the size of objects they create. Each volume gets one and only one block size. Changing block sizes and putting the right apps on the right volumes can significantly improve performance.
- While modern file structures are fast, all retrieval algorithms slow down in proportion to the number of objects that are indexed. Huge volumes with hundreds of millions of files are probably not a best choice under any circumstances.
Relative to your question about servers and applications, it is uncommon to see a server or an application that needs a connection to more than a handful (5-6) volumes. Without knowing the specifics of your situation, this is the best advice I can give you. I hope it helps.
Editor's note: Do you agree with this expert's response? If you have more to share, post it in our .dZROapaKemm^1@.ee83ce3!viewtype=threadDate>Storage Management discussion forum.
This was first published in February 2002
Join the conversationComment
Share
Comments
Results
Contribute to the conversation