New User Special Price Expires in

Let's log you in.

Sign in with Facebook


Don't have a StudySoup account? Create one here!


Create a StudySoup account

Be part of our community, it's free to join!

Sign up with Facebook


Create your account
By creating an account you agree to StudySoup's terms and conditions and privacy policy

Already have a StudySoup account? Login here

Special Topics PHP with MySQL

by: Melyssa Aufderhar

Special Topics PHP with MySQL CSC 191

Marketplace > Wake Forest University > ComputerScienence > CSC 191 > Special Topics PHP with MySQL
Melyssa Aufderhar
GPA 3.56


Almost Ready


These notes were just uploaded, and will be ready to view shortly.

Purchase these notes here, or revisit this page.

Either way, we'll remind you when they're ready :)

Preview These Notes for FREE

Get a free preview of these Notes, just enter your email below.

Unlock Preview
Unlock Preview

Preview these materials now for free

Why put in your email? Get access to more of this material and other relevant free materials for your school

View Preview

About this Document

Class Notes
25 ?




Popular in Course

Popular in ComputerScienence

This 14 page Class Notes was uploaded by Melyssa Aufderhar on Wednesday October 28, 2015. The Class Notes belongs to CSC 191 at Wake Forest University taught by Staff in Fall. Since its upload, it has received 7 views. For similar materials see /class/230725/csc-191-wake-forest-university in ComputerScienence at Wake Forest University.


Reviews for Special Topics PHP with MySQL


Report this Material


What is Karma?


Karma is the currency of StudySoup.

You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!

Date Created: 10/28/15
Chapter 2 Cluster Introduction This chapter of notes will outline the problems solved by clusters the general design of those clusters based on the needs and various software components used in clusters This very general outline will be expanded greatly in future lectures but a brief general overview is necessary to understand the detail to be explored later 21 Why do we need clusters Linux Beowulf Clusters provide exible con gurable and very a ordable computational power To gain an insight into how you build a cluster you need to get an understanding of the possible uses of a cluster 211 NuclearParticle Physics Particle physics and High Energy Nuclear Physics experiments have grown in complexity over the 60 years of their existences lnitial experiments were simply photographs of collisions in extremely dark conditions Researcher would analyze hundreds of photographs and try to make sense of the images they recorded These experiments usually included only a few scientists each 10 at the most Yesterday 1995 collaborations has N 40 members Today current collaborations have N 400 members Tomorrow new collaborations for experiments in 2007 will have N 1000 members The amount of data they collect has grown in equal proportions Yes terday7s experiments recorded data at a rate of 1MBs and about 100MBday Today7s experiments record at rates of 100MBs and on average about 1 TBday Tomorrow7s ex periments are aiming for 100GBs and 1 PBday Given the computational power of today7s systems it would take a single machine 10 years to process all the data Factor in the reality that two or three passes over the data are sometimes required and you begin to see how quickly a PhD student would go postal Fortunately since each unit of data called an event is independent of other events you can simply chop up the data and process them in any order across as many machines as you like What takes 1 machine 10 years now takes 40 machines 3 months The PhD students existence now becomes a little more bearable In this scenario7 one common disk server that holds all the data can be read by the 40 machines and the entire data set can be analyzed Work out calculation for determining how many systems one would need to get a calcula tion done in a speci c period of time Use some standard numbers from PHENIX to describe how to get from requirements to size of the cluster 212 BioPhysics Chemistry Molecular Modeling 213 Human Genomics Human genomics presents one of the single7 most daunting challenges to computing that has ever existed in the history of computing While most computational issues have bene tted and thrived on Moore7s Lawl7 progress in genomics is threatened by it The amount of genomic data to be processed has been doubling every 6 months Addi tionally7 the complexity of genomic analysis has driven the computational requirements to double every 3 months In addition7 most of the data is distributed among over 300 databases Some of those databases are free7 some are proprietary7 and some are con dential 214 Workstation Management The most overlooked7 but greatest bene t of cluster computing comes from the ease of management Clusters have scaled up to thousands of machines Without some simpli ed scheme7 individually managing these machines would be prohibitively expensive especially in terms of manpower requirements With proper design as was done at several genomics start up companies7 administrators simply added machines to the network Their presence on the network was detected by various servers which forced the new systems to be initialized7 con gured7 and brought online for use within 20 minutes 22 High Performance Computer Types There are several types of high performance computing hardware available for meeting the computational needs of researchers and developers Each type is described adequately in the course textbook on pages 16 19 The relevant types for this course are localized on the last two pages of that section 1Moore s Law Transistor density and loosely computational power doubles every 18 months 23 First Homework Assignment Discuss rst homework assignment here 24 Basic Cluster Hardware This section will layout the general types of hardware and the functionality of each type within a cluster environment Each machine will be discussed in detail without exposing too many operating system speci cs as those will be explored later in the course 241 Computational Farm Compute Node As you have seen or will see in your homework assignment clusters tend to grow very large in a very short time period will seemingly very small projects The trick of course is building the systems to be scalable the system can grow in simple measured steps in the cheapest possible fashion without wasting precious funding resources with the best possible performance sometimes the most logical simplest designs can really kill your performance Networking 101 In order to layout the simplest most redundant and largest component of your cluster some networking basic are necessary First two types of networking gear exist hubs and switches All network traf c to every machine on the hub is seen by every machine on the hub If one system needs 1TB of data that TB of data is sent to all systems As a result each machine may have the capability of 100Mbits but in most cases the user will never see that rate Even worse as traf c increases greatly on the hub packet collisions occur and add even more latency to the networking layer thereby decreasing its performance Switches take a different approach Each port has a dedicated connection Only traf c for the ports server is sent out the port This arrangement greatly increases security for the server as well in that insecure traf c is limited to only the intended destination and not the whole world There7s only one problem of interest to us as switches get larger it becomes more expensive to support the sum total bandwidth of all the ports also known as the backplane bandwidth Most manufacturers have reduced the cost of their switch by oversubscribing the backplane bandwidthz These backplane issues aside from the technical bandwidth issue factors directly into the cost of the switch and the limits of usefulness for a cluster The high end switches can reach 256 ports at 10100 although new GigE ports are now becoming available Unfortu nately these switches with suf cient backplane capacity run around 200000 As a reference 256 nodes can be bought for about 600000 Networking now becomes approximately 25 of your cluster compute node price However you can segment your network into 8 subunits or racks A 48 port 10100 switch is about 3000 If each rack unit had 32 nodes and 48 port switches we have brought 2For example for a 16 port 10100 switch the backplane for COTS switches a few years back is usually around 500 Mbps our price down from 200000 to 24000 4000 for the switch to connect the 10100 switches together But there7s a price of course We now have added networking delays between cluster nodes The paths between compute nodes are no longer uniform ls this good or is this bad Depends on the research to be done on the cluster Scalar HENP jobs wouldn7t care Parallel analysis jobs wouldn7t care if they used less than 64 pro cessors provided you could keep those small jobs running on network switch Unfortu nately job scheduling ine iciencies would start increasing since other smaller jobs would begin making resources on a single switch less available Myrinet 1 0 1 The point becomes irrelevant when one builds clusters with Myrinet If you plan on having a single 256 node cluster Myrinet makes a 256 port switch that is just as expensive per port as a 16 port switch There are no games to play with smaller switches to get cheaper prices Draw diagram of dual homed cluster on board One home is ethemet and one is Myrinet Even if your cluster will grow beyond 256 ports Myrinet7s performance scales in a way that all destinations can be equivalent distances3 You can if you wish make a similarly segmented Myrinet setup as you7ve done with the Ethernet but you then defeat the purpose and bene ts of Myrinet Hardware Components Of course we actually have to construct a compute node and install it into the rack With IBM hardware the second CPU memory Myrinet card and system disk must be installed locally The mounting bracket rails must be put into the rack Power and networking cables must be labelled clearly routed neatly and secured inside the rack These simple little tasks which do take up most of the installation time save many headaches and delays in the long run when it comes time to service the cluster In addition by routing and securing the cables away from the systems air ow is least restricted allowing for e icient colling of the cluster Firmware Updates The latest service processor ash BIOS and diagnostic rmwares should be loaded onto the systems immediately after the hardware is installed 242 Cluster Services Maintenance Node The cluster requires key services in order to function as one system The head nodes access these services as clients while the maintenance nodes act as the servers For complete 3A8 with everything there s a price the cost per port for these advanced setups grows with the overall size of the uniform Myrinet setup One comforting thought though is that it s still cheaper and larger scale than standard ethernet redundancy these services should be con gured in a high availability setup However some of the services do not behave well in failover environments The following maintenance node services are necessary 1 Critical Cluster Services 0 Batch Queueing System OpenPBS A service that receives job submissions from users and executes them on the cluster This software without supplemental software runs jobs on a rst come rst serve basis ie FIFO 0 Job Scheduler Maui A priority based scheduling service that determines the order of execution for jobs based on a wide range of criteria average cpu usage average resource usage job queue wait time longer a job is in the queue the higher priority a job is given Each of these criteria can be assigned on a user andor group level 2 Critical System Services 0 Pre eXecution Environment PXE A service that accepts remote boot image requests and determines how the remote system starts 0 Dynamic Host Con guration Protocol DHCP A service that accepts remote requests and returns lP con guration information o Hyper Text Transport Protocol HTTP A service that serves hypertext to clients In the cluster environment HTTP provides a scalable and robust sys tem image distribution service 0 Lightweight Directory Access Protocol LDAP A service that stores password and login information for the entire cluster 0 Network Time Protocol NTP A service that synchronizes the date and time on every system in the cluster 0 Remote Shell RSH and Remote Login RLOGIN Services that allow remote access without password if con gured correctly These services are critical parallel programming environments of a distributed computing cluster 3 Critical Support Services 0 System Usage Monitoring Ganglia This tool provides dual functionality The rst is public relations in nature You can show pretty graphs of system loads for the entire cluster The second is monitoring On a single web page you can see how loaded the cluster is You can single out a particular node and view every aspect of its performance from memory used to network tra ic to swap space It also provides an early warning of cluster software issues For example if the cluster is empty a rare occurrence you know there might be issues and checking the job queues can provide an insight to any potential problem See gure 21 0 System Health Monitoring Nagios This tool picks up where any extreme use of Ganglia leaves o Nagios actively checks for system hardware network and 12 OvtmiwufDEAC 0m nm 651 n39s am last Iwnr ma Therearezi nodes 98 CPUs up and running an There are no nods down D 8 312 mm mm a I mm IN MI I syxnmzru I m m m 1 an s z 1 V 5 5 77s 39 l um mm m 1m haw DEAt osms wan last hwr Inc E San 39 n D l l 7 a 17 w is an 5 29 w 1 3 00 5 I HemIvy Used Mewquot Shrew I remmy can 1 me m limes Imn 5N3 Imvmma Hangs IMzmrv Baf n Inmnn m SnapshnxnfDEACOmilergmd DEAC am 15043 amnm 39 mam 39 dmc l la WW 7 w 7 2u a 0 1 u a 5 1740 mm is 7 w ism iszv mm i500 i520 I um mm mm mm 9 am I 1mm m2 man now 0 cu I Imam 15 mm man 2 am amm magmas dawns 2 D 2 a a u 1 a 5 1740 mm iszo 7 w won iszv mm i500 i520 limimu 1mmquot mm 2 am limLm 1m mm mm 2 um I Imam 15 mm man 2 am mum neamna dmana we 4 v 39 39 mu m 39 r a u a law aw 1 WW 0 a 170 mm mm ww we iszv mm i500 i520 I 1mm mm mm mm 9 am I Inqu 1 man Know a m I mamquot 1m 1w man 3 um Figure 21 Screen capture of Ganglia some system service failures Upon any repeated failure number of failures before alarming is con gurable the system can email or page the administrator and alert of a potential problem Nagios provides a wide wange of utilities and services to track problem histories system deployment etc See gures 22 23 Remote Management Capability IBM s RSAISMP While most issues with a cluster can be addressed by logging in as root some require physical access to the keyboard and monitor for the system If your hardware is on your desk it s not an issue However if the hardware is 10 miles away you ve got a problem with ordinary equipment The Remote Supervisor Adapter and Integrated System Management Processor provide remote power cycling to all nodes in the lSMP network and remote console access to the system directly attached to the RSA card In addition to the RSA card and lSMP network the X335 systems support redi rection of the console output over the serial port This provides a more pervasive remote console access An additional piece of hardware is necessary to recieve all the serial ports and present them to the network sometimes called a serial port concentrator System Journal Software LAMP Finally you need to be able to keep track of the billion little changes that you been making to the cluster Among the 13 Sims JlJSAmIu m sm mm Hun h1sz mm m man w mm M Miriam Embled Figure 22 Screen capture of Ganglia many di erent reasons7 the rst is accountability in status reports Second7 when something breaks that you didn t expect to break7 your notes are the best7 rst step in guring out what you screwed up Third7 when you gure out the best way to do something7 you want to remember how you did it We use a custom programmed Linux Apache MySQL PHP based journal 4 Optional Services o Domain name services Most hardware within the cluster exists on a private network and for security reasons should not be publicized on the Internet o Sendmail email services Once the cluster and its administration sta grows7 it becomes more convenient to concentrate mail from the cluster into one mail server where post delivery processing can analyze the results and generate summary emails 243 Interactive System7 Head Node First and foremost7 the cluster needs to support users and users need to log into the cluster to use it Thus7 it s rather straightforward that you need a head node This system needs to support everyday user activities such as 1 Provide standard Linux utilities to perform daily work a Editors b Compilers mm mwm M2mmmd t 1 oxv ksngu wow w as a 514 m lac 50 m Ilium m wwwwwm swwnmusm mfk39o39msg FW ml Pmo ox V wmac mm In Wu mm mmmm m MW w um xb Hm PlNO ox WARMIKJ mkdu mun mm Hm l l l msuvg NEW336W683433W2 156W liak39olm h mum l l l mm i an WEGE ZGWSYZINZZLDMZM 1 Efmfx hm lm nam l l m memsxmnmw m m 39 ssH3quot Fmquotl l l l 39Qauamm wu3ozso9mwnzamss m Elgomfx Pquot quotquot 39mA39 l m mzswwihmm m lmhmH umnm l 11xng amusing wuzomumuadzhszmses m E i x39l m wvmquot 1 l m mmcu magnum a M I gait wumwx mmmssw mm 5m 5dm 7 1 Fqugac y um DLEKWAI umk mmmm 1 919 imammm mmhx 3quot lmnndp ncdju ame l m m mauswvwmmzuzmwm lmlhhl nm39z w4m l 1324 msaszemsysezammsss m LDAPuk sczandsxirpnnnm mm mmanmmsimnmmm n my l l l l l l l l l l l l mm mmmwm Figure 23 Screen capture of Ganglia c lmage utilities visualization d X windows utilities etc 2 The amount of Linux functionality provided depends on the level of services you wish to support Some services that could be unnecessary 0 Receiving email from the Internet Although the cluster should support forward ing email from the cluster to a default more permanent email address 0 Receiving net news from the Internet 0 Serving personal web pages from the cluster 0 Multimedia applications video MP3s etc 3 Provide clientside access to the utilities necessary to properly distributed the compu tational load across the cluster Additionally since the head node provides the sole access to the cluster extra care must be given to ensure the user has consistent reliable and highly available HA access to the head node This requirement means the head nodes must be constructed with extra care and heavy duty hardware 1 The head node must endure many hardware failures Most of the failures in computers involve moving parts ie fans hard drive platters 0 Hard Drive Failure RAlDl system disk 15 2 3 0 Power Supply Failure Dual Redundant Power Supplies 0 System Cooling Fans CPU air ow The head node must endure general connectivity failures arising from network connec tion losses from the interface card network switch or OS network driver failure The head node must endure poor responsiveness when an errant process or bad user brings the system grinding to a halt Sadly even with all these protections having only a single head node for your cluster is itself a single point of failure Therefore your cluster should have at least two redundant head nodes And as the number of users for the cluster increases the head nodes will increasingly fall into the third category of failure poor performance Fortunately several solutions are available from the enterprise computing realm Multiple machines and assign users to different machines In this model users are only allowed to log into assigned nodes It helps the load balancing by spreading users across several machines Unfortunately if a head node goes down those users don7t have access to the cluster The users have to consciously log into a second machine DNS round robin aliasing This method provides a more transparent means of sending users to different machines The same host name will bounce to different machines in a loop ie 1st access to node A 2nd access to node B 3rd to C etc If a machine dies some administrative action is required to take the machine out of the DNS pool Also DNS provides caching to speed name resolution and prevent excessing load on the DNS server This caching also causes problems if the cached information points to the machine is down Linux Virtual Server aliasing From the user perspective LVS looks similarly to DNS RRA The user always connects to the same DNS name Unlike DNS RRA where the DNS name resolves to different machines LVS always refers to the same machine This head LVS system passes those network connections transparently to the least loaded system in the LVS server pool The system by itself simply uses scheduling algorithms to balance the load on a con nection by connection basis As a result like the DNS situation its possible that the LVS will try to send connections to dead machines but the next connection will be pushed to the next presumably live system In addition a change to the LVS con guration will immediately remove a dead server from the pool A change in DNS con guration still has to propagate to clients because of the caching features of DNS High Availability failover Typically coupled with LVS HA provides automatic detec tion of failed services and removes those failed services from production When the failed service recovers HA returns the service to production To provide this type of capability several things must act in a coordinated fashion 16 1 A monitor must watch each head node system 2 When machine is sickdying make sure its dead STOMlTH 3 The lPMAC of dead machine must be re assigned 4 Reverse process when monitor sees original system online When coupled with LVS HA becomes much simpler in function Taking over a dead systems network identi cation is not necessary since the LVS is merely a front end to multiple systems on the back end Typically all that is required is merely disabling the LVS entry for the dead machine When the monitor software detects a working revived system the LVS entry is re enabled 244 Disk Node The fourth and nal component of the cluster is the data servers which we call disk nodes There are three things that have to be considered when addressing the disk nodes 1 Capacity 2 Redundancy and Reliability 3 Scalability We7ll discuss each one in detail below The rst scenario we7ll discuss uses inexpensive COTS parts Capacity Most clusters really need multi TB level storage capacity As we7ve discussed previously this level of storage is not available in a single drive format nor for performance rea sons would we want it to be lmmediately we need to look towards purchasing many drives The types of drives lDESCSl and the size for lDE 120G200G300G for SCSl 18G36G72G143G depend of course on what you are looking for Scalability While scaling the compute nodes and the head nodes for a cluster is straightforward with the technology available today we start to run into serious issues when we turn our focus towards the data lO for the cluster With lDE RAID servers as will be discussed below scalability is easy by simply purchasing more systems Redundancy and Reliability Each disk node needs to provide a xed reliable and stable storage space in order for it to be useful in any situation On a single server we have plenty of Redundancy and Reliability in the RAlD5 con gurations we use However looking at the data space as a whole all X servers providing a single data space is not very redundant or reliable 17 Disk Space Usage There are two categories of space required for clusters users personal space and users data space This split categorization should not devalue the importance of either type of data That being said one should keep it quite clear that in principle the data can be simply regenerated with more cluster time while the personal space contains crucial software and information that cant Major points of interest in data space are c Su icient disk space provided for each user home to store software sources and various crucial information This area needs to be a safe haven for users in case of system failure and therefore requires regular backups ie at least nightly Examples of home directory contents include job con guration les and scripts data summaries and condensed results journal publications etc Home space should be extremely reliable trusted but not necessarily the fastest space on the block Raw data storage for results generated on the cluster should be extremely spacious Simulation software can generate terabytes of information very quickly from extremely small input les However since this class of space is the most heavily used it needs to have extremely large amounts of bandwidth and have the capability of scaling that bandwidth to meet future needs Physical data space layout both home and raw data needs to be transparent to the user If they are to be trusted to make the cluster work e iciently it won7t refer to second law of thermodynamics Filesysterns The choice of lesystem technology used can greatly a ect the disk servers performance and suitability for cluster purposes For example to meet the scalability needs we can crudely take our favorite lDE RAID array disk servers and buy several of them While the bandwidth to a single machine wouldn7t scale the user can spread their data over multiple machines by hand and access more data bandwidth In the process we would also get the capacity needed to support the users Unfortunately this method puts a greater burden on users to spread out their data manually Users are also trusted to do this on their own and do so in a way that balances the load across all servers Clearly that violates the second law of thermodynamics again In addition by resorting to this simple hardware scaling we are not addressing the fault tolerance issues involved These servers export the data space via Network File Sys tem NFS The write performance for Linux NFS is about BOMBs Unfortunately the server side support for NFS is not the greatest thing in the world It has made signi cant strides in the past 6 months but it is still not commerical grade Client side support is rock solid however To address the four big issues capacity redundancy reliability and scalability you need to look toward parallel lesystems like the Open Source Software 088 Parallel Vir tual FileSystem PVFS and lBM7s General Parallel FileSystem GPFS The bene ts and drawbacks from each lesystem are Both spread the data transparently across the cluster and access to the les are provided through a single global mount point pvfs and gpfs Both stripe the data across the nodes Both provide aggregate bandwidth increases due to multiple systems serving data blocks to the client In PVFS v1 the metadata for the lesystem is stored on a single machine Failure of that machine takes the lesystem offline A single metadata system also results in a bottleneck for the lesystem ln GPFS metadata and le locking information is stored redundantly across the FS servers In GPFS single drive or data server failure does not bring entire lesystem down GPFS provides a great deal more exibility in con guration to allow for more redundant and fault tolerant scenarios as opposed to a single layout scheme in PVFSvl 25 Second Homework Assignment Discuss second homework assignment here 26 Other Cluster Implementations The cluster layout and components described over the previous weeks has really focused on a scalable slightly home grown using already widely available seeds ie 088 software design for distributed cluster computing In that design there is no serious attempt at hiding the fact that all of our processing power is not on a single box Yet despite the lack of a veil of ignorance purposeful attempts are made to shield the user from the implementation of the cluster hardware Other approaches to clusters try to hide from the user the distributed nature of the hardware Two of these approaches are described in detail below 261 Scyld Beowulf Clusters The hardware approach is very similar to the type of cluster we have been discussing the entire semester However each node participates in an integral way in the entire clus ter functionality In other words every node is a compute node Every node is a disk node via PVFS The only exception is that the rst node de ned in a Beowulf cluster not only acts as a compute node and disk node7 but also carries out head node and maintenance node functions The cluster batch queue system and job scheduler are run on the rst node lt monitors the rest of the cluster to determine if a machine is offline It runs jobs and it serves disk space The bene ts of this type of setup are very subtle but worthy of consideration The cluster is presented as a single7 large system to the user and to programs As such7 the user doesn7t necessarily care how many physically distinct nodes and processors there are The program simply runs Being transparent to the user7 user interface is simpli ed Requesting multiple proces sors is as simple as an environment variable Users can change simple fork commands into bprocfork and instantly distribute processes across entire cluster As a single system7 licensing issues become very straight forward It is one system Most software licenses will only charge for the single system pricing Notable exceptions include some compilers that make the distinction between single system images and single system hardware Expansion of the cluster is transparent to the user Additional processors magically appear on the system Of course7 there are drawbacks to this setup Despite the transparency7 the overhead of message passing and job migration are still present The overhead is on the same level of the distributed computing environment we7ve discussed the entire semester System does not scale very well System does not handle faults very well Recall that PVFS is very fragile in the fault tolerance area if one drive goes down7 the entire lesystem is offline Transparent parallelism through the forking example comes at a portability price MPl programs can be used on cluster to mitigate the ability to port software Not very decent platform for large numbers of users derives from lack of scalability and single login point or large variance in computational problems Single system image is really not quite accurate Entire cluster activity is seen on login node7 but jobsprocesses are targeted for available node resources in similar method to distributed computing clusters 262 OpenMOSIX Kernel level patches to LINUX that enable multiple machines look like a single system image The patches tightly integrate the cluster nodes memory CPU cycles and drive space into a more uniform appearing single system Logins to any of the nodes on the cluster are possible All of the memory and all of processors are available to any job Unlike the targeted job distribution in Scyld Beowulf clusters or the queue system and job scheduler of distributed computing environments OpenMOSlX is a rst come rst serve balance all tasks setup If a user wants to run a job they simply run it There are no queueing and special scripts to write No special environment variables It truly behaves like a single large system So whats the problem with it Well rst o It has a checkered past It was MOSlX and freely available Then after a licensing dispute and change MOSlX became proprietary and OpenMOSlX was created OpenMOSlX is under active development Yea so what So are a lot of open source software packages Wait there7s more 0 The method of task distribution is automated at the kernel level When various trig gers77 are red the process is checkpointed and migrated to another system An exam ple of this happening is everyone logging into the rst node They each start an hour long program to calculate pi As each job reachs a certain CPU usage level andor memory usage level the kernel migrates everything to another system llRC programs must be statically linked Shared library binaries were still problem atic Special distributed le system that can7t be used in any other environment This could be a good thing since its most likely optimized for OpenMOSlX usage but bad in that you have to install OpenMOSlX to use it Very little testing by the real world Despite its look as a single system image its really not designed or targeted for a parallel programming environment Its main goal is simply load balancing a single interactive environment across a number of similar systems


Buy Material

Are you sure you want to buy this material for

25 Karma

Buy Material

BOOM! Enjoy Your Free Notes!

We've added these Notes to your profile, click here to view them now.


You're already Subscribed!

Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'

Why people love StudySoup

Jim McGreen Ohio University

"Knowing I can count on the Elite Notetaker in my class allows me to focus on what the professor is saying instead of just scribbling notes the whole time and falling behind."

Janice Dongeun University of Washington

"I used the money I made selling my notes & study guides to pay for spring break in Olympia, Washington...which was Sweet!"

Bentley McCaw University of Florida

"I was shooting for a perfect 4.0 GPA this semester. Having StudySoup as a study aid was critical to helping me achieve my goal...and I nailed it!"

Parker Thompson 500 Startups

"It's a great way for students to improve their educational experience and it seemed like a product that everybody wants, so all the people participating are winning."

Become an Elite Notetaker and start selling your notes online!

Refund Policy


All subscriptions to StudySoup are paid in full at the time of subscribing. To change your credit card information or to cancel your subscription, go to "Edit Settings". All credit card information will be available there. If you should decide to cancel your subscription, it will continue to be valid until the next payment period, as all payments for the current period were made in advance. For special circumstances, please email


StudySoup has more than 1 million course-specific study resources to help students study smarter. If you’re having trouble finding what you’re looking for, our customer support team can help you find what you need! Feel free to contact them here:

Recurring Subscriptions: If you have canceled your recurring subscription on the day of renewal and have not downloaded any documents, you may request a refund by submitting an email to

Satisfaction Guarantee: If you’re not satisfied with your subscription, you can contact us for further help. Contact must be made within 3 business days of your subscription purchase and your refund request will be subject for review.

Please Note: Refunds can never be provided more than 30 days after the initial purchase date regardless of your activity on the site.