With Clustered OnTap, it actually makes sense to have lots of volumes and lots of IPs, one per datastore, so you can move them around the cluster and also move the interface to follow the volume as well. You burn through IPs, but that's what the 192.168.x.y space is for, right? Just dedicate a class C or two to DataStore IPs and you should be all set.
This isn't as big an issue with 7-mode though it's probably still good to have an IP address per-head so that the load splits nicely. John Adam> Yeah that seems to be the easiest answer, even if it's not Adam> ideal. That'll naturally limit the number of VMs per Adam> datastore. If we can manage to change policies to go with Adam> crash-consistent instead of app-consistent on most of our Adam> service levels, that'll help a lot too. Adam> -Adam Adam> On Tue, Oct 27, 2015 at 11:55 AM, John Stoffel <j...@stoffel.org> wrote: Adam> Yeah, it's a hard balance to strike. Having one tool to do it all Adam> makes training and support simpler and easier. But... if that tool Adam> can't do it all as well as a specific tool, then maybe it's not a good Adam> tradeoff to make. Adam> I don't have a good answer, but in some cases just pure $$$ costs Adam> argues against going with more than one tool. Dunno... Adam> But getting back to the root cause, I think going with smaller Adam> datastores is the best track here. Adam> The more we look into this, the more I think that trying to use Adam> just one tool is going to mean that some part of the environment Adam> isn't going to work well. Different tools have different Adam> strengths. Our management is pushing for this one tool solution Adam> as well, but it's causing some difficulties because of the Adam> limitations. Adam> -Adam Adam> On Tue, Oct 27, 2015 at 11:42 AM, John Stoffel <j...@stoffel.org> wrote: >>>>>>> "Ray" == Ray Van Dolson <rvandol...@esri.com> writes: Ray> On Tue, Oct 27, 2015 at 09:58:12AM -0400, John Stoffel wrote: Ray> <snip> >>>> We're going to have the same type of problem down the line too, and >>>> I've used CommVault (on FC SAN volumes), a little bit of Veeam, and >>>> we're moving to Netbackup with Snapmanager on NFS datastores. Ray> Out of curiosity, what made you move away from Veeam? Adam> Politics, licensing, trying to consolidate down to one tool (if Adam> possible). The usual. _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
