san_migrations
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
san_migrations [2019/03/22 22:04] – sgriggs | san_migrations [2019/03/22 22:23] – [How Does PARSEC Do Migrations?] sgriggs | ||
---|---|---|---|
Line 31: | Line 31: | ||
* **OpenVMS**: | * **OpenVMS**: | ||
- | * **AIX**: We use the Logical Volume Manager (LVM) which comes with the operating system to migrate your logical volumes to new physical volumes by adding old LUNs to new LUNs in the volume group, then creating mirrors of each logical volume on the new SAN LUNs. This usually requires no downtime to migrate. We also have scripts and tools which enhance the process by giving you status, estimated time of completion, and managing multiple mirroring operations simultaneously where possible, speeding up the migration considerably. | + | * **AIX, Linux, HP-UX**: We use the Logical Volume Manager (LVM) which comes with the operating system to migrate your logical volumes to new physical volumes by adding old LUNs to new LUNs in the volume group, then creating mirrors of each logical volume on the new SAN LUNs. This usually requires no downtime to migrate. We also have scripts and tools which enhance the process by giving you status, estimated time of completion, and managing multiple mirroring operations simultaneously where possible, speeding up the migration considerably. |
+ | * **Solaris 2.6 - Solaris 9** We can use either Solstice Disk Suite (called Solstice Volume Manager in Solaris 9) or we can use Veritas Volume Manager to migrate your storage. Be aware that neither SDS/SVM or VxVM are setup on Solaris by default. So, if you are using straight disk devices your migration will be more manual and require | ||
+ | * **Solaris 10 and above** We use the ZFS filesystem to perform the migration in much the same way as we do for LVM. We add the new SAN storage to the ZFS storage pool, mirror onto the new storage, then break the mirror away from the old storage. | ||
+ | * **Tru64 and Digital Unix** We can use both AdvFS and Logical Storage Manager to migrate you from your old to new SAN. Be aware that Alpha systems cannot use anything faster than a 2Gbit HBA. So, you'll need to keep a switch around capable of that lower speed. You may also need to adjust your buffer credits on the new switch to compensate for that old infrastructure. However, the upside is that with both AdvFS and LSM we can do the migration with no downtime. | ||
+ | * **IRIX** We can use either CXFS or the XLV volume manager to migrate your storage on IRIX with no downtime. If you are using XFS or EFS filesystems directly on disk slices, we can still perform your migration but you should expect some outages as the old storage is deprecated. | ||
+ | |||
+ | ==== What Have You Guys Migrated Before? ==== | ||
+ | |||
+ | We have done migrations between all major storage vendors equipment. On the old/legacy side we have seen a lot of EMC Symmetrix, NetApp 7-series, and Hitachi USP-V SANs. As far as newer gear we've landed on, it's typically been EMC VMax, Hitachi F-Series, Pure Storage, Dell Compellent, NetApp Cluster-Mode gear, or HP 3PAR. Not all newer SANs will support some of the special features required by OpenVMS. So, check with your vendor first before dropping any money on new storage. |
san_migrations.txt · Last modified: 2019/03/22 22:26 by sgriggs