cryptofreak.org cryptofreak home projects
contact about
Contact:


projects
News Agenda
Antera Antera
News Commentator
News fcreate
Linux Porting Linux Porting
mod-chal mod-chal
Quake III Quake III
News Zope
Contact: webmaster

From: Brian Kreider (brian, thekreiders dot com)
Date: 2001.11.03 - 15.30 MST


X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)

Monday at 4:00 is fine.  Remember that we average about 3 hours for our
regular discussions.  From what I understand we have a lot of details to
discuss and 3 hours doesn't sound like much time.

Brian
  -----Original Message-----
  From: owner-antera, cryptofreak dot org [mailto:owner-antera, cryptofreak dot org]On
Behalf Of Perry and Lorae Merritt
  Sent: Saturday, November 03, 2001 3:16 PM
  To: antera, cryptofreak dot org
  Subject: Re: ARVM discussion


  Hank sings at 7:00
    ----- Original Message -----
    From: June Mullins
    To: antera, cryptofreak dot org
    Sent: Saturday, November 03, 2001 1:07 PM
    Subject: Re: ARVM discussion


    Perry,
         I think it looks good.  I would just fix this sentence:

In a typical storage configuration, all data (whether for user applications
or for backups) is moved through what is normally called a controller.
instead of:In a typical storage configuration data, whether it is backup or
user requested is all moved through what is normally called a controller.
I'm working on getting together a bulleted list of issues,rather than
updating my doc yet.  I think they need to be discussedand clarified.  I'll
send it out when I'm done.   So ... I'm assuming we're meeting Monday night
at 4:30.  Pardon myignorance, but when does MNF start?              June


    Perry and Lorae Merritt wrote:

      Ok first of all, being the first to endure the pain of pacifying you
Unix bigots, this text/jpeg thing is a pain in the butt. I know this is
probably just a deficiency on my part, but I couldn't work with my text
being in one file (and program) and my drawings being in another. I want it
all together. It is more natural to me. But if you guys want to see this
stuff separated I'll continue to do it. I attached a word doc that is nicely
formatted and easy to read and a text file with all of the jpegs for those
of you that want to continually flip back and forth and like plain ugly
unformatted text.

      Now that I've finished complaining ;-), let me tell you what this is
about.

      As you may or may not know, our benefactor has not been getting the
message about the ADML. Not that we didn't try, but apparently when he first
heard about SuperNova he wanted that and hasn't "heard" anything else since
then. When we split the ARVM and ADML into two products, he heard it and
said he wanted the ARVM stuff. So here we are. We need to develop the ARVM
stuff first. (By the way, all future communication needs to use term OP
instead of Supernova. That was the last time I'll use it.)

      I decided to take the lead and start developing a document to describe
what the system might look like and how data and work flows through it.
That's what I'm sending you now. This document doesn't get into the level of
detail that June has in her ARVM doc. By the way, she's working on further
developing that document this weekend also. She should be sending it out for
review sometime soon.

      I wanted to get started before we (probably you) meet next week. Dan
and I need a solid story before we leave on the 15th so I don't want to
waste any time. I don't think we can afford to. We have to get this nailed
before we leave or we stand the chance of coming home empty handed. I don't
want that to happen.

      Please look over what I wrote and comment on it. We can get a lot done
using email if you'll take the time to do it. As always, I view this a
starting point for our discussions. I fully expect this stuff will change as
we discuss it.

      There is a problem with the solution as it stands now. I don't know
how we can have a passive head take over unless we keep buffer cache in
sync. There is no provision for that at the ARVM layer and I don't know how
to solve it down here. If you have any ideas I'd love to hear them.
      It seems to me that we'd have to develop a thin ADML to mirror writes
across to the passive system. We could then have the passive ARVM discard
the buffer cache writes to it so that we don't double the disk traffic. But
I don't know. Can we use DRBD??

      P
--------------------------------------------------------------------------AR
VM Active/Passive Head ConfigurationIntroductionAs part of the Versatile
Storage Architecture (VSA), the Antera RAID Volume Manager (ARVM) can be
used to implement a single head storage configuration or, as discussed in
this document, a dual, active/passive head configuration.1 This paper
discusses the basic components involved and how work and data flow through
the system to provide a unique fault-tolerant storage solution that
integrates a system level backup into the original design.Figure 1As Figure
1 shows, the basic architecture is made up of two systems each containing
the Antera ARVM and Portal software components. In this architecture the
active head on the left is in control of all volume-level activity including
volume creation, modification and basic read/write activity. The passive
head is simply a receiver that receives volume control information from the
active head. As the passive h!
ead receives information from the active head, it updates its internal data
structures to mirror those of the active head. In the event the active head
is no longer viable, the passive head is able to continue providing access
to the volume.Work And Data FlowsThe following sections provide more detail
describing the interaction of the components in various activities. Those
activities include normal IO traffic, backup from the passive head, and
backup in a failed head configuration.Normal IO TrafficAs Figure 2 shows, IO
traffic is instigated from several locations, outside the system (such as
when the head is use as a NAS device) and inside the system from
applications resident in the head. This traffic flows through the normal
driver stack through the ARVM to the storage devices attached to the
head.Figure 2As changes are made to the volume, they are sent from the
active head to the passive head through the Antera Portal. Changes are
received!
 in the passive head and are applied to the ARVM data structures. By
continually updating the passive head of volume changes, the passive head is
always in a state that allows it to take over control in the event the
active head ceases operation.2 This approach minimizes the traffic between
the heads and as such minimizes the performance impact of maintaining a
passive standby head.Backup From The Passive HeadThe passive head
arrangement can be used to greatly improve backup times and reduce the
impact to the active head. In a typical storage configuration data, whether
it is backup or user requested is all moved through what is normally called
a controller. In the Antera solution, the active head is able to continue
providing user access to the data without sacrificing bandwidth to satisfy a
concurrent backup.Figure 3 adds the work and data flows of a backup to the
normal IO traffic shown in Figure 2. The new backup activity is shown using
the blue lines. Figure 3The activity can be seen as moving from left to
right in the diagram. In order to minimize backup activity to the system,
snapshot copies have been created. Snapshots allow a secondary image of the
volume to be instantaneously created and then used. This reduces the time
file activity has to be quiesced to perform the backup. Without a snapshot,
a backup would either require the system be inactive for the duration of the
backup or that active files would not be backed up. As such, the first
activity that takes place within the active ARVM is a volume-level snapshot.
Once the snapshot is created, the information describing the snapped volume
it sent to the passive ARVM. The blue disks in the diagram indicate the
snapped volume. The ARVM implementation of snapshot is a copy-on-write
implementation. That is as data is updated in the original volume, the old
data is copied to a new location within the snapped volume, preserving the
original image. As these copi!
es take place the active ARVM must notify the passive ARVM of the changes so
that it maintains a consistent view of the snapped volume.With the snapped
image, the passive ARVM is able to "create" a new volume that it mounts in
the VFS. Once the new volume is mounted, the backup is able to view the
files contained therein and perform the backup complete out of band from the
normal IO traffic. Backup In A Failed Head ConfigurationIn the event the
system is degraded and a single head survives, Figure 4 shows how a backup
and normal IO traffic is handled in the system.Figure 4The primary
difference between Figure 4 and Figure 3 is that all of the backup traffic
is contained in the active head along with the normal IO traffic. Many of
the same events still take place. The snapshot is still performed and the
resulting volume is mounted to the VFS. Once the snapped volume is mounted
the backup application is able to backup files in the snapped volume!
 without requiring long periods of inactivity or partial backups.1 Full
active/active configurations require the implementation and use of the
Antera Data Management Layer (ADML).2 Data written to the volume such as
user files are not sent to the passive head. That data is recorded on the
storage media and as such is available to the passive head in the event it
becomes the surviving head.






            ARV active passive head configuration.doc Content-Type:
application/msword
                  Content-Encoding: base64




--------------------------------------------------------------------------

            ARVM active passive head configuration.txt Content-Type:
text/plain
                  Content-Encoding: quoted-printable




--------------------------------------------------------------------------

            Basic ARVM active-passive (fig 1).jpg Content-Type: image/jpeg
                  Content-Encoding: base64




--------------------------------------------------------------------------

            active-passive ARVM data flow (fig 2).jpg Content-Type:
image/jpeg
                  Content-Encoding: base64




--------------------------------------------------------------------------

            Active-passive backup (fig 3).jpg Content-Type: image/jpeg
                  Content-Encoding: base64




--------------------------------------------------------------------------

            active-passive backup with passive not involved (fig 4).jpg
Content-Type: image/jpeg
                  Content-Encoding: base64








--
This is the antera mailing list.  To unsubscribe, email
majordomo, cryptofreak dot org with message body `unsubscribe antera'.
Or, for more information, visit http://www.cryptofreak.org/.



This archive was generated by hypermail 2b30 : 2001.11.04 - 04.02 MST