From: Brent Welch (welch@panasas.com)
Date: 08/17/01-11:52:37 AM Z
Message-Id: <200108171652.JAA16252@medlicott.panasas.com>
Subject: Re: Replication and migration requirements
From: Brent Welch <welch@panasas.com>
Date: Fri, 17 Aug 2001 09:52:37 -0700
Regarding points 1 and 2 below, one candidate for a server-to-server
protocol is NDMP, which is used to copy file systems from filers to
tape servers, or from filers to filers.
>>>Robert Thurlow said:
> > We should define the objectives for protocol support of
> > replication/migration.
>
> I think we should mainly be focused on defining a protocol
> which permits a server to contact another server to initiate
> and complete a data transfer to create or maintain filesystem
> replicas, or to move a filesystem.
>
> > Do we want to:
> >
> > 1. Define a standard way for a server to replicate/migrate data to anothe
r,
> > possibly heterogenous, server?
>
> I believe this should be our priority here, with "heterogeneous"
> being the key word. Sun has a block-level replication product
> which is good, so does NetApp - but they're only capable of doing
> that with the same brand of machines. Islands of functionality
> like this do not meet customer needs.
>
> > 2. Provide useful mechanisms for servers to send/receive file data and
> > attributes to each other so that server vendors can build effective
> > replication/migration solutions?
>
> I may be misunderstanding this, but I don't think we're interested
> in building a "toolkit" - we want a protocol servers can speak to
> transfer entire filesystems and then propagate updates to replicas.
> The IETF does protocols and not APIs, so this seems necessary.
>
> > 3. Provide ways for clients to control what gets replicated/migrated (who
le
> > file systems, directory trees, individual files), when, and where?
>
> I don't think we are standardizing how an administrator at her
> desk communicates her desire to have servers achieve a migration
> or replication activity, but perhaps we should be doing that.
>
> > 4. Allow clients to recognize the existence of replicas or be informed th
at
> > some data has been migrated elsewhere, and to optimize their data access
> > accordingly (load balance among replicas, for instance)?
>
> Right now, we haven't been talking much about how resource info
> is "published" so that clients can know about it. It is clearly
> important, and customers have BIG complaints that this is not
> standardized, leaving them to manage more islands of functionality.
>
> But replication only adds a couple of requirements to this issue
> ("give me multiple names" and "permit this info to be mutable"),
> so I would think this is not a goal for this work. If we wanted
> to discuss doing NFS resource discovery in a standard way, I'd
> think that would be a useful effort, but not tied to replication
> and migration.
>
> Rob T
>
--
Brent Welch
Software Architect, Panasas Inc
Pioneering Smart and Infinitely Scalable Storage Networks
www.panasas.com
welch@panasas.com
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:01 AM Z CST