What are the pros and cons to file virtualization appliances? Which do you think is better and why? |
 |
| 12 Jun 2007 | Greg Schulz |
|
|
All types of virtualization need to be transparent to the applications that are using services, transparent to the storage systems themselves and also transparent to management -- the last thing you want to do is increase your management workload. You want the virtualization platform to work for you, not vice versa. The key is to deploy technologies that will be nondisruptive and scalable in its performance and capacity. At the same, it must avoid introducing instability and downtime into the environment.
All vendors will tell you that they are totally nondisruptive and seamless, but at some point something needs to change. For example, you may need to change an automount or a DNS configuration on your servers. The trick is to evaluate the changes that are needed and verify that any changes are acceptable in your environment.
Once file virtualization is implemented, you should also be able to enable or disable it without disruption. Suppose you don't want it running during daytime mission-critical production workloads -- you might prefer to run virtualization at night for back-end operational tasks. Determine the amount of disruption involved in removing the virtualization layer.
While a particular vendor's software will control the file virtualization, it is proprietary (vendor-specific) hardware that can potentially cause the most disruption. You want to reduce the "stickiness" of a virtualization platform, minimizing the vendor lock-in for both software and hardware.
Go to the beginning of the File Virtualization FAQ Guide.
|
|
|
|
