Subscribe

Set up Multistore on existing solution

Hi,

Just wonder if i could pick the communities brains and gather some thoughts on how to proceed with some work i need to do.

We have a couple of v3240's and they have been previously configured. On the primary unit  there is a series of volumes split between the 2 controllers shared by CIFS and each volume is Snap Mirrored to the secondary unit. So its a pretty simple set up but it has come to light that we need to re-configure these and use vFilers as a company standard has been set that says so. This is where i am a bit stuck as i've never touched Multistore & vFilers before and i don't have a simulator available to try this on as it wont run on my home pc

I just wonder what people with more experience than me might do here? Can you enable Multistore, create a vFiler unit and then attach previously configured volumes to it? From various posts and forums i've read i guess you can but everything i read talks about adding a new volume to a vFiler unit, not an existing volumes. Or is enabling Multistore as an after thought a bad thing to do and it would be advisable to basically start from scratch again?

Any thoughts, tips, ideas would be gratefully received.

Thanks

Re: Set up Multistore on existing solution

Vfilers are the easiest thing and people should be using them.

You should look at creating a vfiler and then setup a dr-vfiler for DR.

You will need downtime and swing everything to a vfiler and either use CNAME or move the DNS records to them

Re: Set up Multistore on existing solution

One of the Insight labs I taught a few years back covers how to migrate to a vFiler... you can assign existing volumes to vFilers without a data migration, however there are reconfiguration requirements, for example, joining the domain with the same netbios name, creating the cifs shares, nfs exports, igroups and lun maps (if iscsi is used, if fcp you have to keep that in vfiler0).   See below.. an outline of what needs to be done but not command line examples.  We normally would have about a 4-8 hour PS engagement to do this for our customers depending on the complexity of what is being re-created in the vFiler.

1 APPENDIX E - How to move existing vfiler0 to a vFiler

It is possible to migrate an existing physical controller to a vFiler unit. There are many considerations to plan for moving a physical controller into a vFiler. There will be downtime to migrate to a vFiler, but if you plan (and pre-write commands or scripts) for all the considerations below, the downtime can be short. In many cases you may take vfiler0 and create more than one vFiler, and that can be extrapolated from the list below. 

There are a lot of small things to migrate from vfiler0 into the vFiler and these considerations also apply when migrating from one physical controller to another physical controller. Below is a checklist of topics without ONTAP commands (anyone doing this work should know the commands or where to find them).   A pre-written plan to execute on-site is the key to success when migrating to a vFiler from a physical controller.

  • A vFiler needs its own small root volume
    • Create a root volume  for the vFiler
  • iSCSI Nodename and LUN Mappings
    • Rename the vfiler0 iscsi nodename and reassign the iscsi nodename on the vFiler to match former vfiler0 for no client change (you can leave it different but need to make changes on the clients if you do).
    • Create iGroups in the vFiler
    • Map LUNs to iGroups
  • Hostname
    • Need a new hostname (either for vfiler0 or vFiler depending on which keeps the original hostname). For no host change, often vfiler0 is renamed and the vFiler assumes the name of vfiler0.
  • IPSpaces
    • Do you need to create a separate network from the default-ipspace?
  • IP and Interface, DNS, NIS, LDAP
    • You need a new IP (often put a new management IP on vfiler0 and move existing interfaces on vfiler0 to the vFiler).
  • Domain Membership, FilerSID, Recreate shares and exports
    • We need to rejoin the domain from vFiler using the same netbios name we had in vfiler0, then rejoin with vfiler0 with a new netbios name. Typically vfiler0 rejoins the domain with a new name to free the computer account first.
  • SnapMirror Relationships
    • Need to manually setup additional volumes and then create the dr vfiler manually ,then resync it. Use vfiler0 for the relationship, so this typically involves a new IP address since the new vFiler typically assumes the physical filer address and you have a new hostname and IP for vfiler0 which will be the source of the mirror for vfiler dr. You could use the vfiler IP for snapmirror, but not if using vfiler dr.
    • If Operations Manager use vfiler0 for relationships and update snapmirror.access.
  • NDMP Backups
    • If any backups are set to run against vfiler0 and it’s ip changes, change the backup software to authenticate to vfiler0’s new IP/name. NDMP works for copying but does not work for backup to tape from a vFiler. NDMP backups for the data will need to re-authenticate to vfiler0.
  • SnapVault Relationships
    • Operations Manager uses vfiler0 (hosting filer) for SnapVault relationships.  Modify / restart vaults from vFiler0 between source and target instead of direct vfiler to vfiler.
    • Set snapvault.access and ndmpd.preferred_interfaces on vfiler0.

  • VSCAN
    • If any vscanners are set to run against vfiler0 and its ip changes, change the vscan software to authenticate to vfiler0’s new IP/name. Unless you want to vscan from the vFiler (most often vscan is centralized for all vFilers at vfiler0).
  • Netbios Aliasing
    • If any netbios aliases are used by vfiler0, they need to be moved to the vFiler.  NOTE: this might be an issue if you leave resources on vfiler0 that also need the alias. The same alias can’t be in more than one filer (virtual or physical). If all resources move to the vFiler, we can move it from vfiler0, but if not, users may be impacted.
  • AutoHome directories
    • If any autohome directories are setup for any volumes moving from vfiler0 to the vFiler, they must be removed from vfiler0 and setup again in the vFiler.
  • Local User Accounts  
    • Create local user accounts in vfiler0 in the vFiler.  There is a method to export and import registry entries for users.
  • Local Groups
    • Check for local groups from the windows mmc and/or /etc/lclgroups.cfg.  Make entries in the new vfiler for any groups needed in the vfiler.
  • Domain User Accounts 
    • Always check to see if domain user accounts are used in vfiler0 so they can be added to the vFiler.
  • SNMP
    • Match SNMP settings if any snmp monitors are used (OpsManager, etc.)
  • Quotas
    • If any quotas are set on volumes moving from vfiler0 to the vFiler, the /etc/quotas entries need to be removed from /etc/quotas on vfiler0 and created in /etc/quotas on the vFiler, then “quota on volname” in the vFiler for the volume.
  • User Mappings
    • Copy usermap.cfg entries needed in vfiler1 from vfiler0 (modify / copy  / delete as needed for each vfiler)
  • CIFS, NFS, iSCSI Options
    • List all options from vfiler0 and match on the vFiler
  • Fpolicy settings
    • Need to run fpolicy setup in the vFiler
  • Widelinks        
    • /etc/symlink.translations (move from the physical controller to the vFiler).
  • SSH, RSH setup
    • Both of these need to be enabled and configured in the vFiler.
  • Volume Names
    • Volume names must be the same on the source and destination for migrate, dr and data motion.

Re: Set up Multistore on existing solution

Thanks for that Scott. That gives me a good idea on what i need to do. If i could get the NetApp simulator to work on my laptop i might be able to have a practice at this work before trying it on a live system.