mopdf.com

Software Requirements Specification for Linux File RAIDPage 3even a capstone design project to build an entire system service (e.g. STaaS) or platform hostedapplication suitable for deployment.1.5 References1. https://www.dau.mil/glossary/Pages/Default.aspx2. International Organization for Standardization/International ElectrotechnicalCommission/Institute of Electrical and Electronics Engineers (ISO/IEC/IEEE) Standard24765:2010: Systems and Software Engineering – Vocabulary3. https://www.computer.org/web/swebok/v3, Bourque, Pierre, and Richard E. Fairley. Guideto the software engineering body of knowledge (SWEBOK (R)): Version 3.0. IEEEComputer Society Press, 2014.4. http://agilemanifesto.org/5. https://www.omg.org/spec/UML/2.5.1/, UML 2.5.x specification6. Kendall, Penny A. Introduction to systems analysis and design: a structured approach.Business & Educational Technologies, 1995.7. Rumbaugh, James, Ivar Jacobson, and Grady Booch. Unified modeling language referencemanual, the. Pearson Higher Education, 2004.8. https://raid.wiki.kernel.org/index.php/RAID setup, Linux software RAID using MDADM.9. Welch, Brent, et al. "Scalable Performance of the Panasas Parallel File System." FAST. Vol.8. 2008.10.Libes, Don. Exploring Expect: a Tcl-based toolkit for automating interactive programs. "O'Reilly Media, Inc.", 1995.2. Overall Description2.1 Product PerspectiveThe purpose of the Linux File RAID software libraries and example application is to provide aworking example of data storage with data protection and to serve as a starting point for a studentwishing to build a more complete application or storage service and to practice QA and analysisand design methods to improve this example. As such, the design includes a basic library of RAIDoperations and the example File RAID application simply provides ability to store files in chunksthat can be mapped to distinct and separate storage subsystems to prevent loss of data when astorage subsystem fails or is lost (a chunk erasure). While RAID is most often implemented at ablock and HDD (Hard Disk Drive) or SSD (Solid-State Disk) device level, it can also beimplemented at a file level where large files are automatically broken down into smaller chunks(sub-files) that are distributed across multiple file systems to provide data protection equivalent toblock level RAID, but with more portability and simplified testing compared to block level RAID.For students, it is not practical to expect them to have access to SAS/SATA (Serial Attached SCSIor Serial Attached ATA) disk array with root access on a Linux system, so the Linux File RAIDallows them to learn about RAID and at the same time learn about software system (service) and

Software Requirements Specification for Linux File RAIDPage 4application analysis, design, implementation and test. Students wishing to compare block RAID tofile RAID may want to consult Linux MDADM (Multi-Disk Administration) and examples of use withRAM (Random Access Memory) disks for tutorials on configuration, use and operation of softwareRAID without dedicated HDD arrays. The Linux File RAID is mostly for learning and practice withRAID, but could be used in an actual deployment as long as each file chunk is mapped to a uniquefile system.RAID has levels including striping (level 0), mirroring (level 1) and XOR parity (level 5) as well asdouble XOR parity (level 6). These levels can be combined so that unique block devices arestriped and mirrored (level 10 or sometimes called 0 1) or striping of XOR parity sets (level 50).Furthermore, the number of independent disks (or file systems) is variable, but normally rangesfrom the minimum of a mirror pair (two disks or file systems) up to any number of three or more forXOR parity schemes. The fundamentals of RAID systems are covered in CS 317, file anddatabase systems, and many excellent references and examples such as Linux block levelsoftware RAID (MDADM). The same principles used to map blocks (typically 512 bytes of data ata time up to 4 kilobytes) onto a set of independent HDD or SSD storage devices can also be usedto break a large file up into file chunks (sub-files) that can be mapped onto multiple independentfile systems. The block level is the most common RAID system type where a file system is thenbuilt on top of this new RAID volume (virtual block storage device). However, file level is used inreal products (e.g. Panasas - https://www.panasas.com/ ) and serves as a convenient alternativeto dealing with low-level block devices. All of the same data protection can be achieved as long asfile chunks are mapped to independent file systems rather than independent storage devices. Thisapproach is actually taken for scale-out file systems (federated file systems) and is an alternativeto SAN (Storage Area Networking) and can work with NAS (Network Attached Storage) or be usedas a NAS alternative. It is potentially a great way to provide STaaS (Storage as a Service) wherethe main goal is to provide a “bit bucket” to share files, back them up, or provide a web baseddistribution for files. Figure 1 shows a basic RAID 10, where mirror pair block level storagedevices (HDD or SSD) are striped.Figure 1. RAID-10 striping and mirroring of data blocks on 6 storage devices

Software Requirements Specification for Linux File RAIDPage 5The idea behind RAID-10 is to provide speed-up for reads and writes by using multiple disk drivesin parallel to read portions of a larger set of blocks composing a file or other storage object and atthe same time, mirror blocks onto multiple independent disk drives in case one fails. If one doesfail, a data erasure, the lost data can simply be read from any device that mirrors the same data.When the failed disk drive is replaced by a disk array technician, the system can restore themirroring automatically. So, RAID has two main system level design goals – speedup by writinglarge data sets to many disks in parallel by chunking the original data into blocks as well asproviding protection against data loss due to temporary device malfunction or failure. The key toRAID is that the blocks (or more generally chunks) of data must be allocated (mapped) toindependent devices or file systems to provide actual speed-up and data loss protection whendevices (or file sub-systems) fail. In order to simply learn about RAID and practice with theoperations, actual independent devices are not required, but not speed-up and no failure faulttolerance will actually be realized – for example if file RAID is used with just one file system ratherthan multiple independent. However, not only can one learn about RAID, the basic features andfunctions can still be tested, and when a system with “n” file systems or “n” devices is available,then the speed-up and failure fault tolerance can likewise be tested (performance constraints anderror recovery requirements). Figure 2 shows a basic RAID 50, where XOR parity block levelstorage devices are striped.Figure 2. Striping of data blocks over two 4 1 distributed parity RAID-5 sets

Software Requirements Specification for Linux File RAIDPage 6For RAID-50, RAID-5 sets are striped and each RAID-5 set of devices can in fact be any numberof devices as long as each set is one parity plus at least one or more data devices – typically n 1(5 shown here). While it’s possible to make one of the devices a dedicated parity device, mostoften the parity is distributed, and parity for any particular write set (n blocks or chunks) mustsimply be placed on an independent device ( 1 device) so that any missing block can berecovered by re-computing the parity of the remaining blocks.Due to ability to emulate and test a wide range of RAID configurations with file RAID, the designdoes not provide any block level RAID capability, only file chunk RAID. This supports learningobjectives better by allowing students to run code on any Linux system (and easily port thesolution to a wide range of POSIX compliant systems such as Mac OS-X, Free BSD, etc.)To simplify and allow for experimentation with RAID anywhere, the Linux File RAID simply modelseach independent storage chunk in a RAID mapping as a sub-file that composes a larger file asshown in Figure 3.Figure 3. Linux File RAID Dataflow

Software Requirements Specification for Linux File RAIDPage 72.2 Product FunctionsThis section summarizes the major functions the Linux File RAID system or application mustperform. Details are provided in Section 3, so only a high level summary list is provided here. Thefunctions are organized into high level capability requirements, test requirements (for test drivendesign goals) and system constraints (performance, scaling, sizing). A class diagram is providedthat goes beyond what is currently prototyped to provide ideas for extending the design to includeadditional user authentication, access control, and session features as well as file, directory andfile date, time, and version information.The product must perform:1. Storage of entire file as chunks on file systems A, B, C, D and a dedicated XOR file system2. Read of chunks contained in a file from A, B, C, D and XOR files to reconstruct theoriginally written file3. Recovery of any lost chunk from the original file in order to restore the file4. Detection of corruption of any chunk and recovery of data if one chunk is corrupted5. Ability to map chunks to any file system (same for testing) or independent (for safe use)6. Management of original file names and association with storage chunks for reconstructionand basic file manipulation operations (copy, delete, rename)7. Error reporting if two or more chunks are lost or corrupted (recovery is not possible)Test requirements:1. Show that any chunk, A, B, C, D or XOR can be deleted or corrupted and recovered2. Show that any file size up to constraint size can be written and stored3. Show that read and recovery results in an identical file to that written by full data compareor a data digest4. Test basic number of RAID writes per second possible5. Test basic number of RAID reads per second possible6. Test immediate read-after-write RAID operations possible with our without data compareSystem constraints:1. Storage of files up to 1 gigabyte in size (e.g. typical documents, image files, code, text,binary files)2. RAID operations of 100 K read/write operations per second or better in the library such thata 1 gigabyte file could be written at a rate of 50 kilobytes/second or better, completing filetransfer of a megabyte in 20 seconds or less

Software Requirements Specification for Linux File RAIDPage 83. The current prototype can only handle files, not directories of multiple files, but this couldbe an extension pursued for a project or feature addition exercise which would requiremanagement of namespace metadata.4. The current prototype does not implement any file access control or authentication, but thiscould be pursued as a feature addition exercise or project.Figure 4 shows a basic class diagram for file RAID. This model can be found as a workingexample as a UML model for Modelio http://mercury.pr.erau.edu/ siewerts/se310/design/Modelio/3.4-SD/Figure 4. More fully featured class diagram for Linux File RAID STaaS or ApplicationNote that Figure 4 shows class attributes and associations that go beyond what the currentprototype has implemented such as:1.2.3.4.5.File attributes including time and date, revision, and typeFile system name space including directory and file pathAccess controlIndexing for searchSession management with user authenticationA significant, but useful feature that could be added is journaling, whereby all versions of the samefile (same name and path) could be preserved at a chunk level (which therefore works for any filetype including binary as well as text) where only modified chunks are re-written on update. This isa complex feature, but many file systems and RAID systems do provide this journaling feature bycomparing chunks and writing all changed chunks with time and date metadata. One major

Software Requirements Specification for Linux File RAIDPage 9challenge of journaling are the potential read-modify-write operations (and associated workload)for this feature.2.3 Use CasesTwo main use cases are anticipated for this software including STaaS where the software providesback-end storage for a front-end web interface, much like Dropbox or AWS S3, but with specificoptions for data protection and possibly journaling features. The second use case is a basicapplication that provides software RAID on a Linux system with a browser application assumingthe Linux system has multiple file systems mounted on multiple storage devices to provide dataprotection. Figure 5 shows uses cases for both STaaS and browsing locally for RAID-10 andRAID-50.Figure 5. Use cases for Linux File RAIDFor STaaS, it is assumed that users will mostly want a basic archiving capability for files to beused for backup, file sharing, and file distribution. Common uses would be storing, sharing anddistributing digital photos, design files, or other file types other than code. Code is most often beststored in a CMVC system, so while source code files could be stored, the system provides nospecific advantage and is intended to mostly provide a bit bucket for files.For a local Linux File RAID browser and data protection application, the user will want the filesystem to be as easy to use as current command line directory manipulation tools and graphicalfile explorers commonly available on Ubuntu. Basic access control (user, group and otherpermissions) and user authentication should be supported.The key advantage of the Linux File RAID STaaS and browser are the built in speedup and dataprotection features, which may be sufficient to make the service and applications built fordeployment using this software design advantageous compared to block level software RAID(easier to use on a directory basis rather than volume of disks in array). However, additional

Software Requirements Specification for Linux File RAIDPage 10features such as journaling, directory level authentication, web access to Linux File RAID andother feature extensions possible could increase value and advantages for users. These usecases could be broken into smaller more specific use cases and expanded based upon theintended application of STaaS or a local browser.2.4 Use Case and Requirements TracingAs studied in SE 310, use cases and requirements can be correlated to validate that all requirementssupport a use case and all use cases are supported by requirements. Furthermore, use cases can beprioritized (or requirements as is often done by the commercial industry if all requirements are notmission critical). For example:This should be completed as a validation of requirements – are the right requirements and use casesdriving what is built so that we build the right thing. Whether the design has been built right(verification) can be determined by steps such as code generation from CASE (Computer AidedSoftware Engineering) tool code generation (e.g. Modelio class C generation, MySQLWorkbench schema SQL generation, etc.) as well as prototyping, design walk-throughs, and codewalk-throughs along with SQA test plans, scripts, and drivers outlined in section 5 for test-drivendesign with prototyping.2.5 Operating EnvironmentThe operating environment for Linux File RAID is a standard Linux platform such as Ubuntu,CentOS, or RHEL Linux running on a scalable server or workstation that is configured to havemultiple storage devices and file systems. This could be as simple as two disk drives, each with astandard file system (e.g. ext4) for a RAID-1 configuration, but scaling up to an even number ofstorage devices and file systems for RAID-10, and scaling up to a number of equally sized RAID-5sets that can be striped for RAID-50. For data protection each file system must be on anindependent device, but for basic testing, the software can be run on one partitioned storagedevice with multiple file systems or even on one file system with multiple directories (both of whichprovide no protection, but allow for testing). No specialized hardware is required otherwise, whichis a distinct advantage of file RAID compared to block RAID.

Software Requirements Specification for Linux File RAIDPage 112.6 Design and Implementation ConstraintsDevelopers may test on an unsafe system with one file system or fewer file systems than requiredfor the RAID level, but all deployed systems should have a sufficient number of independent filesystems for data protection so that a user is not mislead into thinking their data is protected whenit’s not – the unsafe configur

RAID without dedicated HDD arrays. The Linux File RAID is mostly for learning and practice with RAID, but could be used in an actual deployment as long as each file chunk is mapped to a unique file system. RAID has levels including striping (level 0), mirroring (level 1) and XOR