Installing the File and Storage Services
Before you can use the Windows Storage Service you will have to install the File and Storage Services role. This role should be installed by default, but if the role is missing then you can install it by opening the Server Manager and choosing the Add Roles and Features command from the Manage menu. When you do, Windows will launch the Add Roles and Features Wizard.
Click Next to bypass the wizard's Welcome screen and you will be taken to a screen that asks you if you want to perform a Role based or feature based installation or a Remote Desktop Services Installation. Choose the Role-Based or Feature-Based Installation option and click Next.
At this point you will see a list of servers. Make sure that the local server is selected and click Next.
You will now be presented with a list of server roles. Select the File and Storage Services check box and click Next. When you do, Windows will display a list of features that you can install. We don't need to install any extra features, so just click Next. You should now see a confirmation screen indicating that the File and Storage Services role is about to be installed. Take a moment to verify that the correct role is about to be deployed and then click the Install button.
Accessing Windows Storage Spaces
The easiest way to access Windows Storage Spaces is to open the Server Manager and then the File and Storage Services link. You will notice that the portion of the Server Manager that is shown in the screen capture follows a hierarchical layout. The bottommost layer of this hierarchy is Storage Pools.
Storage pools are a new feature in Windows Server 2012 that allow physical storage to be abstracted from logical storage. To put this into simpler terms, a storage pool is really nothing more than just a collection of physical disks that have been grouped together into a pool of resources.
You can see the Storage Pools interface. On this particular server I have created one storage pool and named it My Storage Pool. If you look at the lower right portion of the screen capture, you can see that this storage pool consist of three physical disks.
At first it might not seem that there is anything new going on. After all, Windows Server has long had the ability to group multiple physical disks into a single logical resource. For example, the Disk Management Console can be used to create stripe sets or spanned volumes. Both of these structures treat multiple physical disks as if they were a single logical piece of storage.
Storage pools are different however. A storage pool is nothing more than a collection of physical disks. Creating a storage pool is not the same thing as creating a disk volume.
In order to help you understand why storage pools are so important, I need to take a step back and talk about the way that disks were provisioned using the Disk Management Console (which still exists in Windows Server 2012 by the way).
The Disk Management Console, allows you to create various types of volumes that span multiple physical disks. In order to do so, each disk in the volume set has to be converted to a dynamic disk. After doing so, you can create a disk mirror, a stripe set, a spanned volume, or a stripe set with parity.
Even though Windows does give you a number of different options, there is still one big drawback to using the Disk Management Console. That drawback is the console's lack of flexibility.
To show you what I mean, consider the RAID 5 volume shown in the figure above. Even though this is a relatively large volume, it will eventually run out of space. When that happens there is no easy way to increase the volume's capacity. If I wanted to add an extra hard disk to the stripe set, I would actually have to delete the volume, and break the RAID array just so that I could add an extra disk to the array.
Another inconvenience to using this particular approach to create storage volumes is that the disk space on the physical disks is dedicated solely to the volume. For example, in this particular case the RAID 5 volume is 8383.18 GB in size. Of the 8000 plus gigabytes of space in the volume, less than 3000 GB is actually being used. This isn't a problem if the volume of stored data is expected to steadily increase, but it is an issue if the data that is being stored is relatively static because it means that the disk space is locked away and is not available to use for other purposes.
This is simply not the case with storage pools. Storage pools are flexible in that you can add disks to the storage pool on an as needed basis. Keep in mind however, that adding disks to a storage pool is different from adding disks to a volume. Even so, the underlying storage pool has a direct impact on the size and functionality of the volumes that you create.
Of course I am getting a little bit ahead of myself, because you can't create a volume directly on top of a storage pool. Instead, you create virtual disks on top of the storage pool, and then create volumes on the virtual disks.
The virtual disks that you can create on top of a storage pool are really no different than the virtual disks that are used by Hyper-V.
storage pools are a collection of physical disks. As such, making use of a storage pool means using logical storage rather than directly accessing a physical disk. This is accomplished by creating one or more virtual disks on top of the storage pool.
Creating a virtual disk is a simple process. To do so, open the Server Manager and click on the File and Storage Services link. If this link does not exist then the File and Storage Services have not been installed on the server. When the File and Storage Services console opens, click on the Storage Pools link.
This view displays three main pieces of information. The console's top pane displays any storage pools that have been created. You will notice in the figure that one storage pool exists and that it is selected.
The lower, right pane displays the physical disks that are included in the selected storage pool. The lower left pane lists the virtual disks that have been created within the storage pool. It is this pane that we are interested in for the purposes of this article.
As you can see in the figure, I have created a virtual disk ahead of time. The console displays the name of the virtual disk and also indicates that the virtual disk is protected using parity. We can also see that the virtual disk is thinly provisioned. It has a total capacity of 1.35 TB, but right now only 42 GB of storage space is actually being used.
So with that in mind, let's go ahead and create a virtual disk. To do so, click on the Tasks drop down that appears above the list of virtual disks, and choose the New Virtual Disk option from the drop down menu. When you do, Windows will launch the New Virtual Disk Wizard.
As you can see in the figure above, the wizard asks you to select a storage pool. The reason for this is that the virtual disk is being created within the storage pool as opposed to being created directly on a physical disk.
Click Next and you will be prompted to enter a name and an optional description for the virtual disk that you are creating. You can call the virtual disk anything that you want, but my advice is to use a descriptive name and to enter a meaningful description of the virtual disk's purpose. Servers can accumulate a surprising number of virtual disks over time, and it can become difficult to remember what an individual virtual disk is being used for. Rather than struggling with trying to figure out what a virtual disk does later on, it is better to enter a description up front.
The first choice on the list is to use a simple layout. It might at first seem as if a simple layout which consists of creating the virtual disk directly on to one of the physical disks within the storage pool. However, a simple virtual disk is actually striped across all of the virtual disks that make up the storage pool. This has the effect of maximizing the virtual disk's throughput and capacity, but it does so at the cost of sacrificing the reliability. Simple virtual disks are vulnerable to physical disk failure. If any one of the physical disks in the storage pool were to fail, then any simple virtual disks that you have created will be destroyed because unrecoverable data exist on the failed physical disk.
Your second choice for creating a storage layout is to create a mirrored virtual disk. A mirrored virtual disk is a virtual disk that is replicated in its entirety across multiple physical disks. A mirrored virtual disk is much more reliable than a simple disk, but creating a mirrored virtual disk requires a high degree of physical disk space consumption.
At a bare minimum, a mirrored virtual disk requires the storage pool to have at least two physical disks. The mirrored virtual disk is written to both of the physical disks, and the replica virtual disks are kept in sync at all times. This type of configuration results in a high degree of disk capacity consumption because every write operation occurs twice, on two separate disks.
It is worth noting that mirrored disk can take advantage of more than two physical disks. For example, a storage pool containing three physical disks will result in three copies of a mirrored virtual disk. With enough physical disks, a mirror set can protect against the failure of multiple physical disks. For example, a mirrored the virtual hard disk that uses at least five physical disks can survive the failure of up to two physical disks.
The third type of storage layout that you can use is known as parity. Parity delivers performance near that of a simple disk, but with a degree of reliability. If you want to use a parity layout, then the storage pool must have at least three physical disks. The total capacity of the virtual hard disk that you are creating is less than the physical capacity of the underlying physical hard drives because parity information must be stored alongside the data. This parity information is used to recover from a failure of a physical disk.
As you can see in the figure, Windows gives you the option of creating a virtual disk that is either thin provision or a fixed length. Fixed length virtual hard disks provide better performance, but do so with the cost of disk capacity. When a fixed length virtual hard disk is created, the specified amount of space is immediately allocated to that virtual hard disk and is not available for other virtual hard disks to use. Thinly provisioned virtual hard disks on the other hand, offer slightly degraded performance but only claim as much physical storage space as is needed.
Click Next and you will be prompted to specify the size of the virtual hard disk. You can create a virtual disk that is as large as the amount of free space within the storage pool. This holds true even if there are already thinly provisioned disks that have already laid claim (but not actually used) the storage space.
Create a storage pool and how to create virtual hard disks within the storage pool. In this article, I want to conclude the series by taking a closer look at the virtual hard disks and how they are used.
A Closer Look at Disk Usage
In order to help you to better understand the way that storage spaces work, I want to take a step back and talk some more about the virtual disk that we have created. If you look, you can see the storage pool that I previously created, as shown in Server Manager.
As you look at the figure above, keep in mind that a storage pool is designed to abstract physical storage from the operating system. With that in mind, take a look at the upper portion of the screen capture. It shows the storage pool that I previously created. You can also see that the storage pool has a capacity of 10.9 TB and that it only has 1 GB of free space.
In this particular case those numbers aren't as significant as they might otherwise be. When I created this storage space, my goal was to use it to store a single, fixed length virtual hard disk. That being the case, it made sense for me to allocate all of the space in the storage pool to that virtual hard disk. However, this probably is not the most common type of configuration.
In many cases a storage pool will contain multiple virtual hard disks instead of just one. Often times the virtual hard disks are thinly provisioned, which means that they claim only the storage space that they need, thereby expanding dynamically on an as needed basis until they reach their maximum size.
When you create thinly provisioned virtual hard disks, it is possible to over commit the underlying physical disk resources. In this case for example, the physical hard disks within the pool provide a total of 10.92 TB of storage space. If I were to use thin provisioning there would be nothing stopping me from creating a dozen 10 TB virtual hard disks. Obviously the system does not have enough physical disk space to accommodate that much storage, but it doesn't matter because the virtual hard disks are thinly provisioned. They start out small and grow on an as needed basis. You can add more physical storage to the storage pool when your physical storage begins to reach the point of depletion.
As I explained earlier, the top portion displays the storage pool's total capacity and the amount of free disk space in the storage pool. This information is critically important if you have used thin provisioning to overcommit your storage resources, because you can use it to monitor the rate of physical storage consumption.
The pane on the right shows the physical disks that are included in the storage pool that is selected at the top of the screen. It is actually possible to create multiple storage pools, but a physical disk can only belong to a single storage pool. In other words, this view of the console only displays the disks that have been added to the storage pool. There might be other disks in the server that are not displayed because they are not a part of the storage pool. In the case of this particular server, there is a fifth hard disk that the system is using as a boot drive.
The pane in the lower left portion lists the virtual hard disks that you have created on top of the currently selected storage pool. As I previously explained, my needs required me to create a single fixed length virtual hard disk. Had I used thin provisioning or created a smaller fixed length virtual hard disk, I could have created additional virtual hard disks.
The thing that I wanted to point out about this pane is that the virtual hard disk has a capacity of 8.18 TB even though the virtual hard disk is consuming roughly 10 TB of physical storage space (as reported in the top portion of the interface). This discrepancy is caused by the virtual hard disk's layout. As you can see in the figure, the layout type is set to Parity. Parity provides redundancy that protects the virtual hard disk against the loss of a physical disk, but this protection comes at the cost of reduced storage capacity. In this case the total amount of capacity lost is the equivalent to that of one physical disk, or 2.73 TB.
Now that I have discussed the way that virtual storage resources are displayed through the Server Manager, you might be curious as to what these resources look like to the rest of the operating system.
What is really interesting is the way that the Disk Management Console sees the system's storage. As you may recall, previous versions of Windows Server used the Disk Management Console as a tool for provisioning physical storage. In other words, the Disk Management Console could see all of the physical disks that were installed in the server and could be used to create things like mirror sets and RAID arrays.
The Disk Management Console still exists in Windows Server 2012, and it still has the ability to see and provision physical disks. However, if storage has been provisioned through the Server Manager then the Disk Management Console sees virtual disks as physical disks.
No comments:
Post a Comment