There is an interesting aspect to our SANsymphony product: Migration.
Migration is something that every storage administrator has to face at some point and a few reasons for this inevitability come to mind:
- Storage hardware is approaching end-of-life
- Expanding storage resources due to growth
- Moving datacenter locations
In this highly virtualized world we now live in, most compute hypervisors (i.e. VMware, Microsoft Hyper-V, etc.) allow for the online migration of virtual machines from one storage device to another. However, what happens when you have systems or applications which are not virtualized either due to them simply not being virtualized yet or because they cannot be virtualized? This often ends up becoming a very manual and tedious process.
In this article, we will direct our attention to this type of migration. But before we review the steps involved in performing the migration, let’s cover some background details on what makes all this possible.
BACKGROUND
As you may already be aware, SANsymphony at its most foundational level is a storage hypervisor. A hypervisor is an abstraction or translation layer which provides decoupling between the two layers in consideration. For example, VMware provides abstraction of the compute layer from the underlying hardware to allow applications to execute regardless of the hardware chassis in use. Similarly, SANsymphony provides abstraction of the data layer from the underlying storage hardware to allow data to freely exist across any common storage device.
However, abstraction isn’t enough. The system must be compatible with the underlying storage platform. Just as VMware requires an industry standard x86-64 based compute platform, SANsymphony requires a T10 standards based storage device. All storage vendors which adhere to this standard are in principle, compatible. The combined characteristics of compatibility and abstractability opens a door to some interesting possibilities, one of which happens to be the topic of this article.
Consider for a moment we have a T10 compliant storage device underneath a T10 compliant software intelligence (i.e. SANsymphony). First this means they communicate using the same language. Second, the upper-layer software intelligence would have access to the lower-layer raw data structures on the storage device (i.e. disk sectors) which contain the data (regardless of what the data is). If both of these statements are true, then in order to relocate the data from one T10 storage device to another, all one needs is a transport mechanism to facilitate the move. As it turns out, the SANsymphony framework provides this transport mechanism.
Stay tuned for Migration with DataCore SANsymphony – Part 2 and we’ll take a deeper look into the different types of Migration that can befit your infrastructures!
