One of the problems with using lots of datastores is the IP issue with cDOT, which as you point out isn't a problem with RFC 1918 address spaces...
...unless your network team long ago got really tired of mergers and acquisitions causing all sorts of problems with overlapping address spaces, and decided to just use public IP spaces, including already allocated spaces, because nobody ever connects to DOD addresses anyway, right? But, ah, I think that's a story for another time... -Adam On Tue, Oct 27, 2015 at 3:52 PM, John Stoffel <j...@stoffel.org> wrote: > > 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/
