6. Complicated model of Logical interfaces spreading around away from
vServer
bothered me at first, too, but the CLI is rich, and the API is getting
On 11/06/2013 03:37 PM, Iluhes wrote:
I can think of many things that would clearly annoy me:
1. Not having flat files to manage and quickly modify, quotas: exports,
rc, Running config commands potentially much more dangerous then
there. Also take a look at Work Flow Automator as a way to do
repetitive tasks.you can ssh commands, passwordless (once you set up the proper keys)
2. RSH? Can I run RSH commands?
there is, as of cDOT 8.2.1.
3. No separate exports for qtrees
"event log ..." commands
4. Not clear how to access log file of the cluster....mounting root
share not possible, right? only for vServer..
We use AD. I suspect its on the roadmap, though, as I see a
5. No local user authentication mode for cifs vServer
cifs option called "Is Local Auth Enabled" that sounds intriguing.not been an issue for us.
6. Complicated model of Logical interfaces spreading around away from
vServer
how is this an issue?
7. ".admin" in NFS mount path ....Common...
8. Anti-virus?
soon.
FWIW, we've been a cDOT (formerly known as "GX") user since 2006.
Initially GX was put in-place for scaleout HPC file service,
and its stayed around in that role ever since. Now that the
data protection features (snap mirror, snap vault) are available,
we're migrating to as much cDOT as possible.
Why?
Vol move, aggregate relocate, LIF migrate and the fundamental ability
to do all system currency tasks, resource balancing, add and remove
hardware and OnTap upgrades without service disruption.
With our 7-Mode fleet, when a controller is saturated, a downtime
is needed to move a volume to another controller or aggregate.
Its a short-downtime usually, but still requires stopping file
service access to that data set.
With cDOT, I can do every one of the common operational and
systems currency tasks we do, without disrupting clients.
Totally worth it.
As for migration, our model is to migrate as Systems ReCap and
projects start, over the next year or two. There will be service
interruptions as data sets move from 7-mode to cDOT, but once in,
there should be no disruptions for access to that data set for the
rest of its lifetime.
-skottie
On Wednesday, November 6, 2013 4:01 PM, John Clear <jac@panix.com> wrote:
On Wed, Nov 06, 2013 at 12:25:17PM -0800, Iluhes wrote:
> Netapp is pushing hard to start using Cluster Data ONTAP. From
> what I see, from admin/operator level is not as elegant and friendly
> as "Classic". I just cannot see going to it, it goes against almost
> everything I like about administrating netapp. Do people feel the
> same way out there is the field? Netapp is telling us that 7-mode
> will go away. Is that for real? Do you "like" Cluster OS?
Prior to 8.2, we were only implementing CDOT where we needed the extra
performance of all the nodes appearing as a single system, or the
ability to migrate volumes between nodes.
With the release of 8.2, all the features of 7-mode that we use
are supported in CDOT. The main one for us was Snapvault, but QOS
is also a plus. We are not installing any more 7-mode filers.
CDOT is still a bit rough around the edges, but administering it in
some ways is easier than 7-mode. When I have to work on our 7-mode
systems now, I find myself missing tab completion, wildcards and global
commands.
YMMV,
John
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters