|
|
 |
 |
 |
 |
 |
 |
|
|
|
From: Perry and Lorae Merritt (plmerritt, hypermall dot net) Date: 2001.11.03 - 16.10 MST
X-Mailer: Microsoft Outlook Express 5.50.4522.1200 There are no stupid questions. Oh, I take that back I just read what you wrote. ;-) Again, my comments are indicated with --------> ----- Original Message ----- From: "Brian Kreider" <brian, thekreiders dot com> To: <antera, cryptofreak dot org> Sent: Saturday, November 03, 2001 3:30 PM Subject: RE: Opie components I am sorry if some the questions are stupid. >-----Original Message----- >From: owner-antera, cryptofreak dot org >[mailto:owner-antera, cryptofreak dot org]On Behalf Of June Mullins >Sent: Saturday, November 03, 2001 2:06 PM >To: antera, cryptofreak dot org >Subject: Opie components > > >Here's a list of components for Opie. I've added some highlights (or >lowlights) >and some issues. Some of this might look strikingly familiar to you. > >I have not written a formal ARVM architecture doc yet. The gist of my >thoughts >about how ARVM and snapshot are implemented are outlined in the bullets. > >I'm also attaching this as a Word doc for people who prefer it. > >June > >1 Opie Components >1.1 RAID5 >· Implements RAID5 in software. >· Minimum RAID set size = 2 ISU's What is an ISU? ---------> ISU's and IMU's were defined in the early architecture docs. AN ISU in an intligent storage unit, an IMU is an intelligent management unit. ISUs are the "disks" and IMUs are the heads. >· When new ISU's added, the entire RAID group is morphed >· Need to work out data integrity issues around morphing >· How to handle different geometries (i.e., adding a bigger disk to a >RAID group) >· Always add to existing RAID group or form new one with different >geometry? >· RAID5 group = logical volume (or part of volume if multiple extents) >· Support multiple logical volumes? >· Implemented by fixed mapping tables >· Any need for multiple extents / volume? >· Any need for multiple logical volumes per physical volume? >· Do we still want to use MD (RAID0) at the ISU level? >1.2 NBD >· Allows a networked device to be accessed as a block device. >· Need to tackle NBD performance issues >· Consider iSCSI? >1.3 Snapshot Copy >· Snapshots are for backup purposes only >· Can we hide snapshots from the user, since we use them only for backup? >· Implement via hashed mapping table - mark mapping table of source and >snap as snapshot. When receive write request to source, first copy >segment for snapshot, then add to hash. Then satisfy write request to >source. >· Since we are in charge of backup, we delete snapshot as soon as backup >is done >· What are the interactions between morphing and snapshot? Can we use snapshot to morph? ---------> Uuuuuuggggg. You sound like an inverse Sandy. He wants to use morph to snap. ---------> Seriously, I don't think you can, because they are two very different things. Snap creates another set of tables in the volume manager to map changed data. Morph causes an different table to be built. Snap is used to provide a read-only view of a volume mirror, morph is used to expand the volume. ---------> With that said, why is your question causing me to pause for long periods? Are you on to something? >· Space must be reserved for copy-on-write data >· Would it be reasonable to force write-through for copy-on-write data? >1.4 Backups >· Initiated one-time by user or as scheduled jobs? >· No HSM yet >· What is the backup medium? If disk, should be RAID5 protected also. >1.5 File System >· Needs to support large file systems >· Should be journaled >· Is ACL support necessary? Posix or Windows ACL's? >1.6 Active / Passive Heads >· Need to send config changes from active to passive head >· Need to send Snapshot changes from active to passive head >· Mapping hash table >· Copy-on-write data (or force write-through - see above) >1.7 Configuration Management >1.7.1 Persistent store >· Do we need to keep multiple permanent copies of the configuration? >· Should ISU's store their own configurations (or everybody's >configuration)? >· Do we allow for spare (or unassigned) ISU's? >· Some configuration data we need: >· ISU MAC address, name(?), and IP address >· ISU function (active, unassigned) >· If active, which RAID5 group(s) is ISU part of? >· Each ISU should also know at least the head's IP address or something >to identify its head. >1.7.2 Existing device discovery >· There needs to be a mechanism for devices that are already configured >to announce themselves. >· Needed both at boot up time and when a previously broken ISU is now >functional. >1.7.3 New device discovery and configuration >· New, not yet configured devices need to be able to announce >themselves. The head has to be able to recognize that a new device has >been added to the system. >· How do we do this? We can make the head a DHCP server and use DHCP - >but we were not able to figure out how to get from DHCP discovering a >new device to getting that fact over to our code. Can we use some of the same concepts that openview did to find SNMP enabled devices on the network? We could keep a log of the devices we have on the subnet and when a new one arrives we could send a message to see if the new component is one of ours. ---------> Seeing your comment and Junes a few lines later and mine make me beleive this isn't going to be a hard problem to solve. >· How about writing our own equivalent of a simplified DHCP - simply >have the ISU's broadcast to a well-know port behind which is our code? >Our code would dole out from a (user-specified?) list of reserved IP >addresses. Since the assumption is that the ISU's are isolated behind a >switch, this should work. >· We might also make the user configure the ISU IP addresses via >something like the serial port. >1.7.4 Configuration of heads >· How do heads get their IP addresses? >· Need to configure which is active and which is passive >1.8 System Initialization >· Each ISU can boot independently, but the file system cannot be started >until sufficient ISU's are operational. >1.8.1 ISU initialization >· Each ISU starts its own RAID0 configuration (if used). >· Then starts its nbd servers (if used). >· Then report status to the head. >1.8.2 Active Head Initialization >· Once sufficient ISU's operational, the active head starts its nbd >clients. >· Then activates its RAID5 volumes >· Then activates share export. >1.8.3 Passive Head Initialization >· ????? >1.9 Status Monitor >· Responsible for detecting changes in ISU status, or ISU status >transitions. >· Responsible for detecting failures in active or passive head?? >· Individual ISU's monitor their own status (Node booting, normal, hard >disk failure, MD broken, NBD server or client down) >· Network connectivity is monitored (or do we just rely on the nbd layer >for this?) >· Nodes report their status to big kahuna status monitor (maybe recovery >component). >1.10 Recovery >· Responsible for initiating actions to recover from "degraded" mode. >· If hot spare available, it must activate hot spares automatically >after a user-defined timeout period. >· Responsible for initiating failover to passive node if active node fails >· CIFS issues - in-flight transactions lost? >· Buffer cache issues >1.11 Dual Head Synchronization >· Responsible for sending configuration updates (and buffer cache >updates?) from active to passive head >1.12 Shares Management >· What types of shares must we support? CIFS? NFS (2 or 3)? Apple? >· Support CIFS via security=domain? >1.13 GUI >· What needs to be supported in the GUI? >· Head configuration (active or passive) >· Add ISU (and make it active or unassigned) >· Administer backups >· Administer shares >· Display status >· Display storage usage >· Display logs >· ????? . Change IP address Finally for June, Front Panel ---------> Haven't seen a requirement for that one yet. Hope I don't. Brian -- 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 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 |
