Last year, some of you have followed on the Facebook page XenServer with great interest the physical migration of my CloudPlatform cloud demo. Some even commented on how cool storage at me which I used.
Unfortunately, as anyone who has had to deal with the hardware in the data center knows all too well, the servers that are running might not start up if it is powered down and this is no less true for storage controllers.
in fact, one of the controllers in my storage array has failed, and it proved a little more difficult to do than replace I anticipated, so off I went to find a suitable replacement. Before going too far in my decision process, it is probably a good idea to consider what the most common storage both options are in the clouds, and why you might want to choose one over the other.
Local Storage
local storage is far the easiest choice, after all most servers come with at least one drive, and you usually have the option to add several other . Typically, local storage is used to control storage costs, and shared with decent storage from tens of thousands of dollars, there is the potential for cost savings.
Well, until you understand that IO is. All drives have spinning spindles, and the amount of random IO, you can get from a spinning disk is a function of its speed and the number of pins it has. If you are the only user of the disc, the number of pins does not matter too much, but when you have multiple users (aka VM), things can slow down quickly.
course SSD is still an option, but with enterprise SSD costs 5-10 times what the same capacity SAS 15k player, SSD for local storage is not really a leader in costs. More importantly, local storage also historically come with an implied limitation; Virtual machines can not easily migrate between hosts. Fortunately, the latest versions of both vSphere and XenServer effectively address this problem.
Shared Storage
In server virtualization, shared storage is generally used to allow more efficient use of the host. If you need to start a new VM, there is no real way to predict which host in a cluster may have spare capacity, but with a shared storage on the host selection process can be disconnected from the problem of storage management.
This is really good because the anchoring of storage to shared storage solution provides more advanced features such as automatic restart of virtual machines if hardware fails. Whether you use the file (NFS) and block (iSCSI) based storage, IO available to you is the number of drives, their speed and efficiency of the storage array is to manipulate these IO requests.
The problem with the traditional shared storage is that controllers do not include the type of OI they are asked to deliver. For them, a database application and a virtual machine from are pretty much the same, and that leads to a serious problem in the cloud.
How I came to SolidFire
When you look at the state of the world in the storage array, the basic trend is now increasingly large IOP. This is wonderful for guys of storage, but organizations are actually too buy IOP based on forecasts for the IO advanced needs. 
In the world of IaaS, this is made worse because of a lack of control over the IO requires each tenant cloud.
While the careful storage design is not done, use IO an account could lead to a second account get hungry IO. SSDs offer a ton of IO, but it still does not solve the central problem of the IO control
Enter the guys SolidFire
Yes the SolidFire storage solution based SSD ..; which is cool. Yes, it offers a ton of ability IOP, but it goes to another level. With SolidFire, you actually specify the OIP you need on a per LUN / volume, and associate it to an account. This allows some very granular controls, but above all allows you to clear an SLA on the side of storage, and ensure that if someone tries to abuse the table as the impact on other tenants is easy to manage.
As cool as it is, it's still not the whole story. I'm pretty well known for being a XenServer guys, and I'll freely admit that one of the biggest challenges I've had in years was thick on provisioning storage based on blocks.
There are quite a long history, but suffice it to say that if you want thin provisioning in XenServer your choices are local storage and NFS, or choose based storage StorageLink. 
Now I have nothing against NFS, and honestly do use it for some of my storage in the cloud demo, but I definitely prefer iSCSI regarding storage management . Here's where the solution SolidFire really caught my attention
Under the covers, they perform native thin provisioning, data deduplication and compression on each block. LUN through. In real life, this means that, despite the fact that I asked for a 20GB disk cluster, I am likely to use much less than that, and while XenServer think it full 20Gb, the cluster knows best. Since I'm running under a cloud, there is a ton of similarities between my models and deduplication is a wonderful addition.
This is the end point, and probably the key. Since I was replacing storage, I could have taken the easy and just got the current version of my existing channel table. Nice, simple, and drop it in full. Instead, I choose to look at exactly how my cloud has been used, and see if there was a better solution on the market. My key pain points controlled the IO use based on unknown workloads for the coming years, and to be able to ensure that I did not miss storage capacity in the near future. SolidFire delivered on them, and that's why my cloud is now running happily on SSD.
SolidFire is a Citrix Ready partner in cloud solutions, and you want to know more about the solution, Citrix Ready people organize a joint webinar with SolidFire March 13 e 2013 that everyone is invited to. Just register here: http://www.citrix.com/cms/ready/solidfire/
0 Komentar