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: June Mullins (junemullins, earthlink dot net)
Date: 2001.11.03 - 13.07 MST


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 discussed
and clarified.  I'll send it out when I'm done.


   So ... I'm assuming we're meeting Monday night at 4:30.  Pardon my
ignorance, 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
> 
> 
> ------------------------------------------------------------------------
> 
> ARVM Active/Passive Head Configuration
> 
> Introduction
> As 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 1
> As 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 head 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 Flows
> The 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 Traffic
> As 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 2
> As 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 Head
> The 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 3
> The 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 copies 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 Configuration
> In 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 4
> The 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