1996-11-14 Assigned to NCR CORPORATION reassignment NCR CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: RATHUNDE, DALE F., PENARANDA, JORGE D., DZIADOSZ, JOHN A.
2000-02-15 Assigned to VENTURE LANDING & LEASING II, INC. reassignment VENTURE LANDING & LEASING II, INC. SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: STEELEYE TECHNOLOGY, INC.
2000-04-17 Assigned to COMDISCO INC. reassignment COMDISCO INC. SECURITY AGREEMENT Assignors: STEELEYE TECHNOLOGY, INC.
2000-09-05 Assigned to STEELEYE TECHNOLOGY, INC. reassignment STEELEYE TECHNOLOGY, INC. CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: STEELEYE SOFTWARE INC.
2000-09-15 Assigned to STEELEYE SOFTWARE INC. reassignment STEELEYE SOFTWARE INC. CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: SGILTI SOFTWARE, INC.
2004-09-10 Assigned to SILICON VALLEY BANK reassignment SILICON VALLEY BANK SECURITY AGREEMENT Assignors: STEELEYE TECHNOLOGY, INC.
2006-05-08 Assigned to STEELEYE TECHNOLOGY, INC. reassignment STEELEYE TECHNOLOGY, INC. RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: VENTURE LENDING & LEASING II, INC.
A computer system having a scaleable software architecture is disclosed. The scaleable communication or data replication architecture that enables transparent replication of data or state information over a network of geographically dispersed processing units. Transparent data replication over a geographically dispersed computer network is useful in applications such as parallel computing and disaster recovery. The communication architecture also provides a transparent interface to a kernel I/O subsystem, device drivers and system applications. The communication architecture provides a distributed data model presenting a single system image of the I/O subsystem that allows two or more geographically dispersed processing units or clusters thereof, access to common data. In one particular implementation, the communication architecture permits RAID algorithms, such as RAID level 1 and RAID level 5 state information to be applied to the geographically dispersed network for site disaster recovery. The distributed data model software package may be run on uni-processor or multi-processor systems each having the same or different operating environments.
The present invention relates generally to geographically dispersed computer systems, and more particularly to an apparatus for providing a single image of an I/O subsystem in a geographically dispersed computer system.
Known computer systems are typically configured with limited I/O bandwidth and disk capacity. In addition, direct I/O connectivity requirements limit clustering of computer systems to specific platform I/O technologies (e.g. SCSI, Fiber Channel etc.) as well as to the type of platforms themselves. For example, when using a shared SCSI bus, all processing nodes that are connected to the SCSI bus must not only use SCSI, but must also use the same version of SCSI. Likewise, if both processing nodes are interconnected via a Fiber Channel, then both nodes must use Fiber Channel.
The prior art, in an attempt to transcend the physical limitations of accessing common data from clustered computer systems, has attempted to expand disk capacity outside of a single box (e.g. disk drive unit). For instance, it is known to remotely access a peripheral such as a disk associated with a remote computer from a local computer. In particular, a known software product such as Remote File Sharing software (RFS) for UNIX permits a local device or node to gain access to a peripheral on another computer system. However, RFS is specialized software that tends to be unreliable and slow, and more importantly is not transparent to the local or to the remote computer system.
In addition, such prior art solutions have not resolved the problem of interconnecting different platforms or operating systems together. For instance, the present state of art does not permit a present computer system utilizing SCSI interconnect technology to be interconnected with a new computer system utilizing Fiber Channel technology. That is, the present state of art does not permit different platforms to be interconnected together at a disk level because the systems can not communicate with each other.
Further, present interconnect technologies such as SCSI have cabling requirements which impart burdensome physical spacing constraints upon the location and dispersion of clustered processing units. It should be appreciated that the greater the distance separating two given processing units, the greater the fault resilience and disaster recovery ability of the computing system.
What is needed therefore is a method and apparatus for providing a single image of an I/O subsystem in a geographically dispersed computer system by using a network to interconnect multiple computer systems so that applications running on a local processing unit can utilize disks that are associated with other nodes on different platforms. What is also needed is a method of interconnecting different platforms as well as different disk technologies together while still providing a single image of an I/O subsystem. Such a method and apparatus would permit (1) a cost-efficient hardware upgrade solution, (2) a non-disruptive growth path when upgrading computer systems, and (3) expanded computing power without disregarding current computer systems, thus leveraging existing hardware.
What is disclosed hereafter is a kernel-level communication architecture which transparently connects I/O subsystems together by communicating state information and I/O request data across a network to geographically dispersed processing units that cooperate to form a distributed computer system. Thus, the described kernel-level communication architecture operates in different operating systems to scale and expand a local node across multiple nodes.
In accordance with one embodiment of the present invention, there is provided a computer system including a first processing unit having a first storage device, a second processing unit having a second storage device, and a network connecting the first processing unit to the second processing unit. The first processing unit includes a physical device driver for transferring data to and from the first storage device, and a distributed data module for transferring a copy of the data between the first processing unit and the second storage device across the network without the knowledge of the first processing unit.
Pursuant to another embodiment of the present invention, there is provided a computer system including a first processing unit having a first storage device associated therewith, a second processing unit having a second storage device associated therewith, a network connecting the first processing unit to the second processing unit, a first physical device driver for transferring first data between the first processing unit and the first storage device, and a mechanism for transparently transferring the first data between the first processing unit and the second storage device across the network without the knowledge of the first processing unit.
Pursuant to yet another embodiment of the present invention, there is provided a computer system including a local processing unit having a first operating system executing thereon, a storage device for storing data, a physical device driver for facilitating the transfer of the data between the local processing unit and the storage device, and a distributed data module transparently interfaced to the operating system and the physical device driver for replicating the data across a network to a first remote processing unit.
It is therefore an object of the present invention to provide a new and useful method for replicating data in a computer system.
It is another object of the present invention to provide an improved method for replicating data to a number of processing units forming a geographically dispersed computer system.
It is another object of the present invention to provide a new and useful apparatus for replicating data to a number of processing units forming a geographically dispersed computer system.
It is a further object of the present invention to provide an improved apparatus for replicating data to a number of processing units forming a geographically dispersed computer system.
It is therefore an object of the present invention to provide a new and useful method for transferring state information to a number of processing units forming a geographically dispersed computer system.
It is another object of the present invention to provide an improved method for transferring state information to a number of processing units forming a geographically dispersed computer system.
It is another object of the present invention to provide a new and useful apparatus transferring state information to a number of processing units forming a geographically dispersed computer system.
It is a further object of the present invention to provide an improved apparatus for transferring state information to a number of processing units forming a geographically dispersed computer system.
The above and other objects, features, and advantages of the present invention will become apparent from the following description and the attached drawings.
FIG. 8 is a block diagram showing the distributed data model software of the present invention being used for mirroring a boot device across a network such as a local area network or a wide area network.
While the invention is susceptible to various modifications and alternative forms, a specific embodiment thereof has been shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that there is no intent to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.
What is described hereafter is a scaleable communication or data replication architecture that enables transparent replication of data or state information over a network of geographically dispersed processing units. Transparent data replication over a geographically dispersed computer network is useful in applications such as parallel computing and disaster recovery. The communication architecture also provides a transparent interface to a kernel I/O subsystem, device drivers and system applications. The communication architecture provides a distributed data model presenting a single system image of the I/O subsystem that allows two or more geographically dispersed processing units or clusters thereof, access to common data. In one particular implementation, the communication architecture permits RAID algorithms, such as RAID level 1 and RAID level 5 state information to be applied to the geographically dispersed network for site disaster recovery. The distributed data model software package may be run on uni-processor or multi-processor systems each having the same or different operating environments.
Referring now to FIG. 1, there is shown a block diagram of a conventional kernel layer 2 of an operating system executing within a single processing unit 3. The kernel layer 2 includes an I/O subsystem interface 4 which typically communicates with a physical device driver 5 in a conventional manner. As described in greater detail below, the distributed data model software 6 of the present invention, in conjunction with known add-on volume management software 7, resides between the I/O subsystem interface 4 and the physical device driver 5 as middleware 8.
It should be appreciated that the middleware 8 (e.g. the volume management software 7 and the distributed data model software 6) transparently interfaces with the I/O subsystem 4 such that the I/O subsystem 4 does not know that the middleware 8 is present. Likewise, the middleware 8 transparently interfaces with the physical device driver 5 such that the physical device driver 5 does not know that the middleware 8 is present.
In addition, the middleware 8 acts as a switch for data that is to be written to a local peripheral via the physical device driver 5. In particular, the middleware 8 can replicate data to, or read data from a remote peripheral on path 9 without affecting the performance of the I/O subsystem interface 4 or the physical device driver 5. In the embodiment being described, the middleware 8 resides on a host system as described further below. However, it should be appreciated that the middleware 8 may reside on a controller board such as a host adapter, or reside at a RAID subsystem level in order to replicate data in the same manner as set forth below with respect to a host system.
Referring now to FIG. 2, there is shown a block diagram of multi-node computer system 10 which incorporates the features of the present invention therein. The multi-node computer system 10 includes a number of geographically dispersed processing units or nodes 12 such as host computers. Two processing units, a local processing unit 12a and a geographically remote processing unit 12b are shown in FIG. 2 to facilitate the explanation of the computer system 10. However, it should be appreciated that any number of additional local and/or remote processing units may be added to the computer system 10 without departing from the scope of the invention described hereafter.
As shown in FIG. 2, the processing units 12 are interconnected via a network infrastructure 14 such as a Local Area Network (LAN), Metropolitan Area Network (MAN) or a Wide Area Network (WAN). In addition, the network 14 may also be a bus, a hardware backplane, or a number of PC motherboards connected in a rack-mounted configuration with a physical backplane acting as a high-speed network. Further, the network 14 may be ETHERNET running on a LAN, or wireless, as long as the network path(s) can connect at least two processing units together, where each processing unit includes at least a processor (CPU), memory and a disk. Thus, a processing unit as used herein, refers to devices such as notebook computers, personal computers, servers, all the way up to massively parallel processing computers.
In particular, each processing unit 12 may include a network adapter 16, network driver 18, software distributed lock mechanism 20 associated with a parallel software application 22, switch-over software 24, known volume management software 25 (such as Disk Array PLUS or Tape Array PLUS volume management software available from AT&T), distributed data model software 26, physical device driver 28, I/O adapter 30 and a peripheral 32 such as a hard disk, optical disk, hardware RAID sub-system, or disks managed by the volume management software 25 (software RAID). It should be appreciated that the disk 32 may also be other types of peripheral such as a sequential access tape drive.
The network adapters 16 may be known expansion cards or other similar devices which conventionally connect the respective processing units 12 to the network infrastructure 14. The network drivers 18 are known network-specific control software that enable the processing units 12 to communicate over the particular network 14 in a conventional manner. In the embodiment being described, the network adapters 16 and network drivers 18 may support any conventional network protocol such as ETHERNET, ATM (Asynchronous Transfer Mode), or FDDI (Fiber Distributed Data Interface).
The I/O adapters 30 may be known expansion cards or similar devices which conventionally connect the processing units 12 to their respective disks 32 via buses 34 such as a SCSI bus or a Fibre Channel bus. The physical device drivers 28 are a known device-specific control software that enables the processing units 12 to read/write information from/to the respective disks 32 in a conventional manner. In the embodiment being described, the I/O adapters 30 and physical device drivers 28 may support any conventional I/O protocol such as SCSI or Fibre Channel. It should be appreciated that additional processing units (not shown) may be connected to each disk 32 across the bus 34 to form a cluster configuration.
The known switch-over software 24 typically resides on a processing unit 12 that is operating in a standby mode (such as processing unit 12b), and monitors an application program that is executing on a processing unit 12 that is operating in an active mode (such as processing unit 12a). If the active processing unit 12a fails in some respect, the switch-over software 24 on the standby processing unit 12b detects such failure on active processing unit 12a and starts up the standby processing unit 12b to pick-up execution of the application program where the failed processing unit 12a left off.
In the embodiment being described, the switch-over software 24 executing on local processing unit 12a may monitor the operational status of remote processing unit 12b across the network 14 to insure that processing unit 12b remains powered up. Likewise, the switch-over software 24 executing on remote processing unit 12b may monitor the operational status of local processing unit 12a across the network 14 to insure that processing unit 12a remains powered up. The switch-over software 24 monitors the respective processing units 12 by a conventional heartbeat mechanism that is transmitted and received across the network 14. A suitable switch-over software package is the LifeKeeper software package available from AT&T.
The switch-over software 24, when used in conjunction with the distributed data model software 26, provides the capability of (1) detecting when a geographically dispersed processing unit has failed in some respect, and (2) mounting a copy of the software application that was executing on the failed processing unit, onto the resident processing unit to pick up processing of the data where the failed processing unit left off. As described further below, execution of the software application on the resident processing unit is possible because of the fact that the distributed data model software 26 transparently (e.g. without the knowledge of the failed processing unit) and asynchronously replicates data from the failed processing unit to the resident processing unit in the same order written to the failed processing unit, before the failed processing unit fails.
By way of example, if the switch-over software 24 resident on the remote processing unit 12b detects that the local processing unit 12a has failed in some respect, such as the processing unit 12a fails to respond to queries across the network 14, then the switch-over software 24 resident on processing unit 12b will mount the software application that was previously executing on processing unit 12a, onto processing unit 12b. Once the software application is mounted on processing unit 12b, processing of the same data can begin again because the data was previously automatically replicated across the network 14 from the disk 32a of processing unit 12a to the disk 32b of processing unit 12b by the distributed data model software 26 as described further below. The distributed data model software 26 replicates the data from the disk 32a to disk 32b in the same order as the data is written to disk 32a.
Thus, in a switch-over application, one processing unit 12 runs an application while the other processing unit 12 is updated or otherwise has data replicated thereto. In particular, a distributed data configuration consists of two pieces or disks, the local piece being the disk 32 of the processing unit 12a and the remote piece being the disk 32 of the processing unit 12b.
When an application runs on processing unit 12a, the data is duplicated to the disk 32b of the remote processing unit 12b. If a situation occurs where the application running on processing unit 12a fails or is otherwise interrupted, then the processing unit 12b boots up a copy of the application on disk 32b, and the disks 32 comprising the distributed mirror reverse roles. That is, the local piece of the distributed data configuration becomes disk 32b and the remote piece of the distributed data configuration becomes 32a.
The parallel software applications 22 may be any known software package that simultaneously executes on multiple processing units 12. The parallel applications 22 typically utilize known distributed lock mechanisms 20 in a conventional manner to prevent the processing units 12 from simultaneously writing to the same block of data that is replicated on the respective disks 32 to prevent the data from being corrupted. In the embodiment being described, the parallel application 22 may be a cluster database product such as Oracle Parallel Server (OPS) which provides the ability to share a single database image across multiple nodes, or may be a cluster file system that provides the ability to share a single file system image across multiple nodes.
The parallel software application 22, when used in conjunction with the distributed data model software 26, provides a single system data image to the geographically dispersed processing units 12 of the computer system 10. That is, the parallel software applications execute simultaneously on processing units 12. The distributed data model software 26 permits data that is written to the disk 32 of the local processing unit 12a to be automatically replicated the disk 32 of one or more remote processing units 12.
Likewise, the distributed data model software 26 permits data that is written to the disk 32 of the remote processing unit 12b to be automatically replicated to the disk 32 of the local processing unit 12a. Thus, the distributed data model software 26 permits the processing units 12 to have a single system image of I/O subsystem (e.g. a signal system image of the data on the disks 32) even though the processing units 12 are geographically separated.
The distributed data model software 26 utilizes a conventional I/O path 36 (FIG. 2) for facilitating I/O transfers (e.g. I/O reads and writes) to the local disk 32. In addition, the distributed data model software 26 includes a second I/O path 38 for facilitating the transparent (e.g. without the knowledge of the local processing unit 12) replication of data bound for a local disk 32, across the network 14 to a remote disk associated with a remote processing unit as described further below.
Thus, in a parallel application, both processing units 12 run an application at the same time on a shared distributed data configuration. In the shared distributed data configuration, the processing unit 12a has the disk 32a configured as the local piece and the disk 32b configured as the remote piece of the distributed shared data configuration. Simultaneously, the processing unit 12b has disk 32a configured as the remote piece and the disk 32b configured as the local piece of the distributed shared data configuration. In parallel applications, the processing units 12a, 12b utilize synchronous data replication when writing data to the disks 32a, 32b.
Referring now to FIG. 3, there is shown an architecture 39 of the distributed data model software 26 that is resident on processing unit 12a, and an architecture 86 of the distributed data model software 26 that is resident on the processing unit 12b. In particular, the architectures 39, 86 shown in FIG. 3 and described in detail hereafter, facilitate the transparent replication of data along the second I/O path 38 (FIG. 2) from a local processing unit 12a to a sequential access device (e.g. tape drive) or a random access device (e.g. hard disk, optical disk, hardware RAID subsystem, software RAID) associated with one or more remote processing units 12b.
In addition, the architectures 39, 86 shown in FIG. 3 and described in detail hereafter, facilitate sending state information along the second I/O path 38 from the local processing unit 12a to one or more remote processing units 12b. Note that the architecture 39 also facilitates transferring I/O requests (e.g., I/O reads and writes) between the local processing unit 12a and the local disk 32 along the conventional I/O path 36 in a manner well known to one of ordinary skill in the art. Thus, further discussion thereof is not warranted.
Each processing unit 12a, 12b includes an operating system having a known kernel layer 40 (FIG. 3). It should be appreciated that the kernel layer 40 defines the core of the operating system, i.e. that portion of the operating system that manages memory, files and peripheral devices; maintains time and date; launches applications; and allocates system resources. In addition, each operating system includes a known interrupt layer 42 that resides at a level above the kernel layer 40.
The architecture 39 for the local processing unit 12a includes a number of routines that reside in the kernel layer 40 and reside in the interrupt layer 42 of the operating system. In particular, the architecture 39 for the local processing unit 12a includes one or more kernel I/O drivers 44, a distributed storage software module 46, and one or more outstanding request queues 48 all of which reside in the kernel layer 40. The architecture 39 also includes a communication infrastructure 49 comprising a transport module 50, a transmit queue 52, a network device driver 54, a receive queue 58 and a receive daemon process 60 which reside in the kernel layer 40, and a transport interrupt routine 56 which resides in the interrupt layer.
It should be appreciated that the communication infrastructure 49 may be any known communication infrastructure which complies with the known ISO/OSI (International Organization for Standardization Open Systems Interconnection) model. That is, the communication infrastructure 49 of the present invention is modeled after the ISO reference model where the distributed storage module 46 logically comprises the function of the presentation and session layers of the ISO model that reside above the communication infrastructure 49.
Commercially available or proprietary networking protocol software implementations may provide the communication infrastructure 49 such as TCP/IP over ETHERNET, X.25, FDDI, ATM, or preferably, the Reliable Transport Module (RTM) product available from AT&T. In addition, the interconnection of the distributed storage module 46 and a commercially-available communication infrastructure 49 may be described by the TSI (Transport Service Interface). The TSI standard defines a set of primitives or messages such as SEND-- TPDU and RECEIVE-- TPDU that send and receive packets.
Referring again to FIG. 3, the architecture 39 is layered into three tiers. The first tier includes the distributed storage module 46 which encapsulates I/O data or state information as described further below. The second tier includes the transport module 50 which encapsulates the I/O data or state information for transmission across the network 14 in accordance with a protocol defined by the third tier of the architecture 39. The third tier includes the kernel network device driver 54 which provides a low level communication routing protocol such as Internal Protocol (IP) between the geographically dispersed processing units 12 across the network 14.
It should be appreciated that the third tier may implement other protocols, such as a protocol defined by a microkernel as part of a microkernel communication service to other nodes or processing units running the same microkernel. In addition, the third tier may be implemented as a hardware backplane with a chip set that provides the communication services.
The distributed storage module 46 and the communication infrastructure 49 cooperate to form the distributed data model software 26 (FIG. 2). As shown in FIG. 4 and described in detail below, the distributed data model software 26 includes a number of subroutines, namely an entry point routine 26a, an acknowledge routine 26b, an done routine 26c, a send routine 26d, and a time out routine 26e. It should be appreciated that the distributed storage module 46 and communication infrastructure 49 are also resident on the remote processing unit 12b. In addition, it should be appreciated that some of the subroutines mentioned above are executed on a local processing unit and other subroutines are executed on a remote processing unit as described further below.
Data that is to be conveyed or transmitted between the processing units 12 is encapsulated into a data structure such as a Protocol Data Unit (PDU). As shown in FIG. 5, a PDU is defined for each of the three tiers forming the communication architecture 39. More specifically, the PDU defined for the first tier is a Data PDU or DPDU. The PDU defined for the second tier is a Transport PDU or a TPDU. The PDU defined for the third tier is a Network PDU or a NPDU.
It should be appreciated that the PDUs may encapsulate application data as well as state information such as synchronization data. One example of state information that may be sent across the network 14 is RAID level 1 or RAID level 5 state information such as disk Out-Of-Service (OSS), disk In-Service (IS) or disk parity (Out-Of-Date) information. It should also be appreciated that by permitting state information to be transferred between processing units 12, a single system image of an I/O subsystem of the computer system 10 can be achieved. A single system image of an I/O subsystem permits geographically dispersed processing units to access common data.
Referring now to FIG. 6, a DPDU data structure 62 includes a number of fields such as a request type field 64. The request type field 64 identifies whether state information or I/O data is to be transferred to the remote processing unit 12. If state information is to be broadcast to the processing unit 12b, the field 64 may identify a set or a clear state information operation. If I/O data is to be transferred to the remote processing unit 12b, the field 64 identifies either a read I/O or write I/O request.
The DPDU data structure 62 may also include (1) a data address field 66 which links the completion of the request on the remote processing unit 12b to the original request from the kernel, e.g. I/O request, (2) a memory release field 67 which, when set, instructs the transport module 50 to release the memory reserved for the DPDU 62 once the packet is successfully sent to the target processing unit 12b, (3) a target processing unit identification field 68 which identifies which processing unit that the request should be directed to, (4) a source processing unit identification field 69 which identifies which processing unit that the request was sent from, and (5) a data field 70 which contains the data and/or state information to be sent or broadcast to the target processing unit(s) 12 in the computer system 10. The DPDU data structure 62 may also include a control mode field 71 which is active only when the TPDU data field 70 contains state information as indicated by the request type field 64.
The control mode field 71 of the DPDU 62 indicates whether the distributed storage module 46 will or will not wait (user selectable) for the target processing unit(s) 12b to acknowledge a TPDU 72 before resuming operation. That is, if the control mode field 71 so indicates, the distributed storage module 46 will go to sleep and wait for a return acknowledgment from the processing unit 12b before proceeding. If so, the transport module 50 must wake-up the distributed storage module 46 once the acknowledgment is received.
A TPDU data structure 72 includes a path number field 74 which identifies the preferred network path for communicating the packet to the remote processing unit(s) 12b, a sequence number field 76 which guarantees the processing order of the requests by the remote processing unit 12b, and a DPDU field 78 which encapsulates the DPDU data structure 62.
The architecture 39 of the present invention does not define a low-level communication driver encapsulation structure. However, a known encapsulation protocol, such as the Universal Datagram Protocol (UDP), may be used to define a NPDU data structure 80. The NPDU data structure 80 includes a conventional UDP header field 82 and a TPDU field 84 which encapsulates the TPDU data structure 72. It should be appreciated that the NPDU data structure 80 is then communicated across the network in accordance with the characteristics of the particular low-level communication driver being used.
Referring now back to FIG. 3, the known kernel I/O driver(s) 44 pass conventional data blocks to the distributed storage module 46. By conventional, it is meant that the kernel I/O driver(s) 44 pass to the distributed storage module 46, buffer headers that would normally be passed from the operating system to the physical device driver 28 were it not for the presence of the distributed data model software 46. The buffer header typically contains information such as the block number on the remote disk 32 needed for an I/O request. The kernel I/O driver(s) 44 also write to the local disk 32 along the conventional path 36 (FIG. 1) as previously described. The kernel I/O driver(s) 44 may be provided as part of the operating system of the computer system 10, or may provided as part of an add-on volume management software package such as Disk Array PLUS or Tape Array PLUS volume management software available from AT&T.
After the kernel I/O driver(s) 44 pass the buffer header to the distributed storage module 46, the entry point routine 26a (FIG. 4) of the distributed data model software 26 allocates and initializes a buffer (not shown) from a pool of available memory (not shown). The buffer is used for building the DPDU 62. Preferably, the volume management software may allocate the buffer for the DPDU 62, which buffer should be large enough to accommodate the encapsulation requirements of the TPDU 72 and the NPDU 80 (this is the case for sending state change information to the remote processing unit). The initialization of the DPDU 62 by the entry point routine 26a includes the tasks of: (1) indicating if the request is an I/O read or write request, or a set or clear state information request; (2) placing the address of the buffer header that is passed from the kernel I/O driver(s) 44 onto the outstanding request queue 48 for use in completing the particular request as described further below; and (3) identifying the remote processing unit 12b to receive the request.
With regard to the third initialization step above, the distributed storage module 46 may replicate or broadcast to one or more remote geographically dispersed target processing units 12b. The transport module 50 encapsulates the DPDU 62 into a TPDU 78 and facilitates sending the TPDU 78 across the network 14 to the target remote processing unit 12b.
In addition to initializing the DPDU 62, the entry point routine 26a provides system I/O flow-control by monitoring the outstanding requests on the outstanding request queue 48 to see if a predetermined system threshold has been met. More specifically, there is a threshold on the amount of memory that can be allocated for DPDUs 62. If too many DPDUs 62 are outstanding, then it is possible that threshold may be reached. In order to avoid reaching the threshold, the entry point routine 26a governs the rate of allocation of DPDUs 62 by maintaining an ordered work list, keeping track of the number of outstanding requests, and deciding if the requests can be sent to the remote site.
The distributed storage module 46 passes the DPDU 62 to the send routine 26d for encapsulation into the DPDU field 78 of TPDU 72. The send routine 26d also encodes the second tier encapsulation information into the header of the TPDU 72. This includes encoding a sequence number into the sequence number field 76 of the TPDU 72 so that the packet (e.g. TPDU) is delivered to the remote site, in order, on the path specified in the path number field 74 of the TPDU 72. The TPDU 72 is then placed on the transmit queue 52 for use in subsequent retransmissions of the TPDU 72, if necessary. That is, the transmit queue 52 is used by the transport module 50 to guarantee the sequence that packets are send across the network 14.
The transport module 50 also passes the TPDU 72 to the kernel network device driver 54 via system interfaces to transmit the TPDU 72 to the remote processing unit 12b. The kernel network device driver 54 encapsulates the TPDU 72 into the TPDU field 84 of the NPDU 80 which is then conveyed to the remote processing unit 12b using the protocol and methods defined by the known low-level communication driver (e.g. UDP). The low-level communication driver sends the NPDU packet 80 over the network 14 independent of the distributed data model software 26.
The transport module 50 receives TPDU packets 72 from the remote processing unit 12b. The incoming TPDU packets 72 may contain acknowledgment information regarding a previous TPDU packet 72 sent to the remote processing unit 12b, or may contain data to be replicated onto the local disk 32 from the remote processing unit 12b during an active-active mode of operation. The transport interrupt routine 56 is called by a network device interrupt routine or low-level communication driver interrupt routine (not shown) when an incoming packet is received. The transport interrupt routine 56 places the incoming TPDU 72 on the receive queue 58 ordered according to the assigned sequence number stored in the sequence number field 76 of each TPDU 72. The lowest sequence numbered TPDU packet 72 is placed at the front of the receive queue 58, and the highest numbered TPDU packet 72 is placed at the rear of the receive queue 58.
Once the acknowledgment from the processing unit 12b is received by the processing unit 12a, the transport module 50 will release the memory reserved for the DPDU 62 if the job request field 64 indicates that data was sent to the processing unit 12b, as opposed to state information, and if the memory release field 67 is set.
The receive daemon 60 is responsible for servicing the receive queue 58. What is meant herein by the use of the term "daemon" is a program or process that performs a housekeeping or maintenance function without being requested or even known of by the user. Typically a daemon routine sits in the background and is called into play only when needed.
Whenever a new incoming TPDU 72 is added to the receive queue 58, the receive daemon 60 checks to see if the TPDU 72 at the front of the receive queue 58 contains the next unprocessed sequence number. If it does, the TPDU 72 is removed from the receive queue 58 and is passed to the distributed storage module 46. This process iterates until the receive queue 58 is empty, or until the sequence number of the TPDU 72 at the front of the receive queue 58 is not the next expected sequence number. The receive daemon 60 is responsible for validating the TPDU 72, including checking for duplicate sequence numbers.
The distributed storage module 46 handles acknowledgments. The acknowledgment routine 26b (FIG. 5) is called by the receive daemon 60 when requests return from the remote processing unit 12b. The acknowledgment routine 26b removes the relevant buffer header from the outstanding request queue 48. The distributed storage module 46 obtains status information from the TPDU 72 regarding the pending request and sets any error fields, if necessary, in the buffer. The distributed storage module 46 obtains the address of the buffer from the received TPDU 72 and passes the address to the done routine 26c.
The done routine 26c wakes up any sleeping requests on the threshold and adjusts the outstanding I/O counters for purposes of flow control in a manner known to one of ordinary skill in the art. The done routine 26c then passes the buffer address to a conventional kernel I/O routine (not shown) or to a virtual I/O done routine (not shown) associated with volume management software if installed, which places the buffer on the appropriate I/O queue for use by the kernel I/O drivers 44 to signal to the operating system that the outstanding request has completed (either successfully or unsuccessfully).
The time-out routine 26e (FIG. 5) is initialized when the first remote I/O operation is performed on a configured remote device (i.e. replicating data to the disk of the remote processing unit 12b). At pre-determined specified intervals, the time-out routine 26e checks the DPDUs 62 on the outstanding request queue 48. DPDU packets 62 found that exceed the allotted time to complete will have their error fields (not shown) set in the buffer and be removed from the outstanding request queue 48. The failed buffer will then be passed to the done routine 26c. In addition, an appropriate error may be displayed on a console.
The search algorithm for the time-out routine 26e will be to look at a predetermined number of buffers at the front of the outstanding request queue 48, and mark them. These are the buffers that have been on the outstanding request queue 48 the longest. If the buffers are found on the list a second time then a time-out condition occurs and the time-out routine 26e takes the actions described above. It should be appreciated that other search algorithms can be implemented.
Returning again to FIG. 3, the architecture 86 for the remote processing unit 12b includes a number of routines that reside in a kernel layer 88 and in an interrupt layer 90 of the operating system. In particular, the architecture 86 for the remote processing unit 12b includes a communication infrastructure 91 comprising a transport interrupt routine 92 that resides in the interrupt layer 90, and a receive queue 94, a receive daemon 96, a transport module 110 and a kernel network device driver 112 that reside in the kernel layer 88. The architecture 86 also includes a distributed storage module 98, one or more I/O queues 100, one or more I/O daemons 102, and one or more kernel I/O drivers 104 that reside in the kernel layer 90, and a kernel done routine 106 and a DSM callback routine 108 that both reside in the interrupt layer 88. As with the communication infrastructure 49, the communication infrastructure 91 may be any known communication infrastructure which complies with the known ISO/OSI (International Organization for Standardization Open Systems Interconnection) model.
The transport interrupt routine 92 is called by a network device interrupt routine or low-level communication driver interrupt routine (not shown) when an incoming packet is received. The transport interrupt routine 92 places the incoming TPDU 72 on the receive queue 94 ordered according to the assigned sequence number stored in the sequence number field 76 of each TPDU 72. The lowest sequence numbered TPDU packet 72 is placed at the front of the receive queue 94, and the highest numbered TPDU packet 72 is placed at the rear of the receive queue 94.
The receive daemon 96 is responsible for servicing the receive queue 94. Whenever a new TPDU is added to the receive queue 94, the receive daemon 96 checks to see if the TPDU 72 at the front of the receive queue 94 contains the next unprocessed and expected sequence number. If it does, the TPDU 72 is removed from the receive queue 94 and passed to the distributed storage module 98. This process iterates until the receive queue 94 is empty, or until the sequence number of the TPDU 72 at the front of the receive queue 94 is not the next expected sequence number. If the sequence number of the TPDU 72 is not the next expected sequence number, then the receive daemon 96 waits until the next expected TPDU 72 is received. The receive daemon 96 is responsible for validating (e.g. checking for errors) the TPDU, including checking for duplicate sequence numbers.
The distributed storage module 98 receives incoming DPDUs 62 from the receive daemon 96. Alternatively, the distributed storage module 98 may receive incoming data primitives from other commercially available communication infrastructure products. The distributed storage module 98 validates the request in the processing unit 12b. In particular, if an I/O request was received, the distributed storage module 98 checks to see if the target disk or volume is valid and configured in a data access state. In addition, the distributed storage module 98 checks the source processing unit identification field 69 of the received DPDU 62 to verify that the DPDU 62 was received from the expected processing unit 12a.
That is, once a processing unit 12a establishes a distributed configuration with a particular processing unit 12b, the processing unit 12b expects to receive DPDUs only from the processing unit 12a that established the particular configuration. Until the particular configuration is closed, the processing unit 12b will invalidate any DPDUs received from processing units other than the processing unit which initiated that configuration.
Once preliminary validation of the received DPDU 62 has been completed, the entry point routine 26a allocates a system buffer or control structure and initializes the buffer to include the DSM callback routine 108, and include all other information from the DPDU 62 to complete the remote request. The DSM callback routine 108 permits the distributed storage module 98 to be notified by a virtual software management layer (when performing I/O to a virtual disk) or a physical device driver (when performing disk I/O) when the remote request is completed.
The buffer is then inserted onto the I/O queue 100 in sequence. The I/O daemon(s) 102 is awakened if not running, to process the buffer on the I/O queue 100. The I/O daemon(s) 102 passes the buffer to the kernel I/O drivers 104. It should be appreciated that there is one I/O queue 100 and one I/O daemon 102 associated with each processor (not shown) in the processing unit 12b in order to provide a multi-threaded environment (simultaneous execution of the processors) for improving performance and maximizing bandwidth and balancing the workload of each of the processors.
As previously mentioned, the kernel I/O drivers 104 may be add-on volume management software such as Disk Array PLUS or Tape Array PLUS volume management software provided by AT&T. For I/O requests, the kernel I/O drivers 104 translate the I/O request into a conventional physical I/O request for use in reading or writing to the peripheral associated with the remote processing unit 12b. That is, the physical I/O request is then serviced by the physical device driver 28 (FIG. 1) which reads/writes from a particular block on the disk 32 in a conventional manner.
The I/O Daemon(s) 102 is started at boot time by the distributed data model software 26, or during the initialization of the kernel 88 or initialization of start-up scripts (kernel routines or application programs that run as part of the startup sequence). In the embodiment being described, the I/O Daemon(s) 102 may be a number of kernel processes in order to maximize performance. That is, a number of kernel processes can service the requests (data or state information) on the I/O queue 100 faster than a single kernel process. Thus, the I/O daemon(s) 102 waits for requests to be placed on the I/O queue 100. Once awakened, the I/O daemon 102 passes the request to the kernel I/O driver 104 until the I/O queue 100 is empty or until interrupted by a tunable preemption mechanism. Since the distributed data model software 26 runs as part of the kernel layer 40 rather than being scheduled as an application, the software 26 includes a tunable preemption mechanism to preempt itself so as to not monopolize a CPU within the processing unit 12.
At the interrupt level 90, when a physical I/O request completes, the kernel done routine 106, calls the DSM callback routine 108. The DSM callback routine 108 may also be called by a volume management software routine (not shown) using standard kernel callback conventions if the volume management software is resident on the computer system 10. In the later case, the volume management software routine will be called by the kernel done routine 106 when the physical I/O request completes. Thus, the DSM callback routine 108 is invoked when all requests have been completed on the remote processing unit 12b for the particular remote request. The DSM callback routine 108 marks the completed remote request in the corresponding buffer that is on one of the I/O queue(s) 100 and notifies the I/O daemon(s) 102.
The I/O daemon(s) 102 monitors the outstanding requests on the I/O queue(s) 100 and attempts to group acknowledgments of request completions. In addition, the I/O daemon(s) 102 detaches the buffer from a I/O request queue 100 and marks either pass or fail within the returning DPDU 62 from the buffer information. The I/O daemon(s) 102 then passes the DPDU to the transport driver 110 to return to the local processing unit 12a.
The transport driver 110 encapsulates the DPDU into a format (e.g. UDP) that is accepted by the kernel network device driver 112 which is a low-level communications driver. The kernel network device driver 112 is responsible for conveyance of the NPDU 80 to the local processing unit 12a across the network 14.
FIG. 7 is a block diagram showing the distributed data model software 26 of the present invention being used in a backup/restore application across a network. In particular, a server 200 may be used as a backup server for a plurality of processing units or systems 202, 204 and 206 when the distributed data model software 26 of the present invention is present on the server 200 and processing units 202, 204, 206.
The processing units 202-206 may use a distributed virtual disk wherein data is replicated to the backup server 200. The distributed virtual disk includes a primary or local piece comprising disks 202a, 204a and 206a, and a secondary piece comprising disks 200a. During normal hours of operation, the distributed virtual disk operates such that all I/O requests are directed only to the primary or local piece 202a, 204a, 206a of the distributed virtual disk.
At a typical off peak hour of the day, an administrative command to restore the distributed virtual disk may be performed wherein the secondary piece 200a of the distributed virtual disk is synchronized with the primary piece 202a, 204a and 206a. That is, the secondary piece 200a is updated so that the data stored thereon is identical to the data stored on the primary piece 202a, 204a and 206a. Once the restore operation is completed, the distributed virtual disk is again configured with the secondary piece 200a marked as being out-of-service (OSS) so that all requests are again directed to the primary piece 202a, 204a and 206a.
Thus, the application shown in FIG. 7 provides for a copy of the data to be available at a centralized server 200 with the data being as accurate as of the last restore operation. If the data is to be backed up to tape as well, then backup operations to a tape can be done on the backup server 200 with no impact to the users or applications running on the processing units 202-206, even if the tape backup is performed during peak hours of the day. Alternatively, the server 200 may run an application locally, and may need to update identical databases resident on each of the remote processing units 202-206. As such, the server 200 could operate in a branch office and replicate information to the processing units 202-206 in remote branch offices in the same manner as discussed above.
FIG. 8 is a block diagram showing the distributed data model software of the present invention being used for replicating a boot device across a network. In particular, the communication architecture provides the capability to replicate the /root, /usr, /var, and /stand files of a local system 208 to a remote system 210 (along with data files on other disks of the local system 208) when the distributed data model software 26 of the present invention is present on both systems. In particular, the local system 208 includes a known volume management software layer or product 212, and two disks, namely, a boot disk 214 and a secondary boot disk 216. The secondary boot disk 216 stores a copy of the boot disk 214 locally. It is known in the art to use the volume management product 212 to mirror a copy of the boot disk 214 to the secondary boot disk 216.
The local system 208 also includes a distributed data configuration software layer or product 218 inserted below the local volume management layer 212. It should be appreciated that the distributed data configuration product 218 may represent the distributed data model software 26 of the present invention. In this configuration, the distributed data configuration product 218 transparently (without impacting or intruding on operating system software or the volume management software) mirrors the /root, /usr, /var, and /stand files not only to the secondary boot disk 216 but also to a remote disk 220 associated with the remote system 210. Thus, if the local system 208 fails, such as due to a catastrophe, the remote system 210 can be booted-up from the remote disk 220 which is a copy of the boot disk 214 of the local system 208.
When the remote system 210 comes up, it is using the local system's configuration and data, and the remote system 210 boots up the image that was being executed on the local system 208. That is, the remote system 210 boots up as if it were the local system 208. Since the remote system 210 has all of the local system's data disks and program disks, the applications which were running on the local system 208 can be restarted on the remote system 210 without having any knowledge that they are now on a different system. It should be appreciated that the boot disk 214, secondary boot disk 216 and remote disk 210 may be a hard disks, optical disks, hardware RAID sub-systems, or software RAID sub-systems.
In summary, the distributed data model described above brings to clustered computing systems, what LEGO building blocks brought to basic building blocks. That is, before LEGO building blocks were developed, basic building blocks had no interconnect facilities and could be used only to build limited structures. LEGO building blocks, because of their simple interconnect facilities, permit unlimited building of complex structures.
Likewise, the distributed data model of the present invention, with its transparent distribution support, has a similar impact on cluster computer system designs by providing a new and useful means for linking a plurality of processing units together. Thus, applications running on processing units that do not have disks may easily interact with files on processing units that do have disks, as if the disks were local to the processing units without disks. Some processing units may provide special facilities or devices (i.e. tape drives, disk drives) that every processing unit can access as if the facilities or devices were local. This permits a collection of processing units to be unified into a single image of an I/O subsystem. Another benefit of the distributed data model is to facilitate replacing processing units with new or enhanced processing units or peripherals, such as disk drives and tape drives, to provide improved or expanded services.
Since communication between processing units is through standard message interfaces, other processing units are much less impacted by the installation process. This enables incremental or dynamic upgrades to storage as well as to the operating system.
The distributed data model may utilize a data replication capability that permits a system configuration with two disks and two disk controllers, to provide fault tolerant enabling capabilities. Typically, the two disk controllers have to be located on the same processing unit. However, the distributed data model permits replication to take place between two separate processing units connected with a LAN or WAN.
Because the distributed data model uses message-based communications, a disk driver can be on the second processing unit and yet appear as if it were local to the first processing unit. In other words, the processing unit sees the two disk controllers as if they were on the same processing unit when in fact, the disk controllers are on separate processing units. The present invention permits data mirroring to occur over two simple processing units such as personal computers with low-cost controllers instead of more expensive disk controllers utilizing expensive buses. Standard computer equipment can thus be applied to high availability applications such as switch-over applications, or parallel applications such as Oracle Parallel Server.
While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description is to be considered as exemplary and not restrictive in character, it being understood that only the preferred embodiment has been shown and described and that all changes and modifications that come within the spirit of the invention are desired to be protected.
For example, the described invention provides a distributed data model (data over a network) which permits a cluster of nodes or processing units to access common data over a network. The described invention permits clustering of processing units across different hardware platforms and I/O subsystems. The described invention manages multiple I/O daemons on a remote processing unit to maximize I/O throughput performance at a remote site.
The described invention permits remote I/O completion acknowledgments to be piggy-backed to minimize interconnect and system bus bandwidth utilization. The described invention synchronizes remote requests on the remote processing unit in the same order presented to the I/O subsystem on the local processing unit independent of the number of paths interconnecting the nodes or processing units.
The described invention permits continuous data service in the event of a node or processing unit failure by permitting the application to be switched over to a remote processing unit. The described invention permits two or more geographically dispersed processing units access to common or replicated data. The described invention is functionally transparent to the system and to the applications running on the system. The described invention provides synchronous and asynchronous data replication services that can be used simultaneously.
The described invention permits geographically dispersed parallel applications such as Oracle Parallel Server of Cluster File System products to run on the same common data. The described invention enables interconnect technology (e.g. SCSI, Fiber Channel, ETHERNET, FDDI, ATM, T1/T3, wireless RF) to be transparent to the application. The described invention can be implemented at the system level or on an I/O controller (host adapter) at the subsystem level. The described invention permits the transfer of system/application data as well as synchronization data (state information) to create a single system image of the I/O subsystem of a computer system. The described invention is independent of the transport protocol used.
The network 14 has been generically used above to refer to anything from a bus, to a hardware backplane, to a plurality of PC motherboards connected in a rack-mounted configuration with a physical backplane acting as a high-speed network, to ETHERNET running in a LAN, to a WAN, and to wireless, as long as the network path can connect two processing units, each consisting of a CPU, memory and a disk, together. Thus, a processing unit as used above refers to devices such as notebook computers, personal computers, all the way up to massively parallel processing computers.
In addition, hardware vendors have focused on developing chipsets for doing symmetric multiprocessing (SMP). The distributed data model of the present invention may be used to interconnect commodity nodes such as standard four-processor SMP boxes or nodes together to build an array or cluster of SMP boxes. That is, the distributed data model of the present invention may be used to interconnect a number of commodity level processing elements together into one large SMP such that all commodity level processing elements would have the same view of the I/O subsystem.
said transport module includes means for releasing said buffer after said network device driver transfers said second protocol unit across the network.
the second processing unit includes means for processing said plurality of second protocol units according to said predetermined sequence.
a plurality of daemon processes for transferring said copy of said data to a volume management module which transfers said data to and from the second storage device.
4. The computer system of claim 1, wherein said data is RAID state information.
5. The computer system of claim 1, wherein said data is I/O request data.
said first operating system is different from said second operating system.
said second distributed storage module includes means for passing said first data to and from said second physical device driver.
said means for passing said first data to and from said second physical device driver includes a second plurality of daemon processes.
said first distributed storage module further includes means for grouping together a plurality of second data acknowledgment packets together for transfer across said network to said second processing unit.
said first transport module includes means for releasing said buffer after said network device driver transfers said first data across the network.
11. The computer system of claim 7, wherein said first data is stored on a boot disk of said first processing unit.
said first transport module includes means for releasing said buffer after said first network device driver transfers said second protocol unit across said network.
said transport module includes means for releasing said buffer after said network device driver transfers said second protocol unit across said network.
14. The computer system of claim 13, wherein said distributed data module replicates said data across said network to a plurality of remote processing units.
a network device driver for transferring said second protocol unit across the network to the second processing unit.
17. The computer system of claim 15, wherein said data is I/O request data.
means for transparently transferring said second data between said second processing unit and said first storage device across said network without the knowledge of said second processing unit, said means for transparently transferring said second data including a second distributed storage module including means for passing said first data to and from said second physical device driver.
"RAID Unbound: Storage Fault Tolerance in a Distributed Environment," by Brian Ritchie, Alphatronix, Inc., Computer Technology Review, Fall/Winter 1995, pp. 100-105.
EP1796001B1 (en) 2009-05-13 Method for implementing shared disk array management functions.


text:
Thesprotia subhyalina, common name grass mantis, is a species of mantis found in Brazil. It was originally identified as Oligonyx subhyalina.

References

subhyalina
Insects of Brazil
Insects described in 1870

redpajama_set_name: RedPajamaWikipedia


text:
Thammasat Journal of History is a biannual academic journal published by department of History, Philosophy and English Literature. The journal aims to provide a forum for academics to present their works on humanities and social sciences in issues pertaining to historical studies. Our objective is to encourage academic exchanges as well as development.
We welcome original manuscripts written in Thai or English in the forms of research studies, academic papers, reviews, and translated publications. The journal uses double-blind peer review. All submissions to the journal are initially reviewed by the editorial board.
Thammasat Journal of History provides immediate open access to its content on the principle that making research freely available to the public supports a greater global exchange of knowledge. However, the opinions expressed in the journal are those of the authors.
Department of History, Philosophy and English Literature, Faculty of Liberal Arts, Thammasat University

redpajama_set_name: RedPajamaCommonCrawl


text:
The Railhead
NEWS LETTER OR THE PIKES PEAK "N"GINEERS MODEL RAILROAD CLUB
July 2009 RAILROADING SINCE OCTOBER 13, 1989
Calendar of Events 2009
July 6: Board meeting at Village Inn on Academy Blvd just N of Austin Bluffs Pkwy dinner at 6:30 pm meeting at 7:30 pm
July 3, 10, 24 & 31: Friday Work sessions 7 pm to 9 pm
July 7, 14, 21 & 28: Tuesday Work sessions 7 pm to 9 pm
July 11, 18 & 25: Saturday Run sessions 9 am to 11 am
July 11: Club Trip to the Colorado Railroad Museum – Meet at the Monument Park & Ride @ 8 am and we'll carpool up from there.
July 17: Business Meeting 7 pm at club room
Aug 3: Board meeting at Village Inn on Academy Blvd just N of Austin Bluffs Pkwy dinner at 6:30 pm meeting at 7:30 pm
Aug 11, 18 & 25:Tuesday Work sessions 7 pm to 9 pm
Aug 3, 10, 24 & 31:Friday Work sessions 7 pm to 9 pm
Aug 17: Business Meeting 7 pm at club room
Aug 1: Denver & New orleans field trip
Aug 8: Club rides the Royal Gorge Route RR. @ 3:30 pm. We will meet at the Nevada Park & Ride @ and carpool from there. See below for trip details.
Aug 1, 15, 22 & 29: Saturday Run sessions 9 am to 11 am
Aub 29 0r 30: Combined Picnic at Palmer Lake
Other Events for 2009
Sept 12 & 13: TECO-4
Sept 26: Ride the Cripple Creek Railroad
Oct 10: Club Anniversary Party at the Dueker's
Oct: Club trip to the Pueblo Railroad & Air Museums
Nov 6, 7 & 8: GTE Show in Denver.
Nov 28: Club Show at the DAV at Palmer Park Blvd and Peterson Rd
Colorado railroad Museum Trip July 11
For those of you wishing to go on this trip meet at the Monument Park & Ride at 8 am on Saturday July 11. The group will carpool from there to Golden. The cost is $12 per person.
Denver & new Orleans Field Trip August 1
For those who wish to go on this field trip we will meet at 10 am at the old Cub Foods parking lot at Constitution and Palmer Park and carpool from there. Bring a lunch and something to drink as this should take about 4 hours. Mike Peck will do El Paso County and Lester Coburn will do Elbert County.
Royal Gorge Route Trip
The club has scheduled this trip for August 8 at 3:30 pm. We will meet at the Nevada Park & Ride. We will set the time at the July business meeting. The club opted to ride in one of the vista dome cars so we could have a better view of the gorge. The club has reserved 20 seats and 16 are spoken for. We do have the option of adding more seats so don't worry we'll have seats for those who wish to join us. Cost is $49.25 for adults and $18.30 for children 3-12. Unfortunately the money has to be in to the club by July 8 so we can pay thirty days in advance.
MTL Repairs
We still have a lot of work to do on the MTL. We will be trying to setup up a couple more work sessions so we can have the repairs completed by TECO in September. As we have not worked on the MTL lately I do not have any current pictures of what we are doing so you will have to waite till after the next work session.
We didn't hear this BNSF business train coming so
This is the only shot we could take Major train wreck at Georgetown before the show
These two photos of buildings in Georgetown showing how they are trying to preserve the architecture and history of the town.


text:
Weisshaupt oder Weißhaupt ist der Familienname folgender Personen:

 Brigitte Weisshaupt (* 1939), deutsche Philosophin
 Fritz Weißhaupt (1910–1984), deutscher Politiker (DDR)
 Horst Weißhaupt (* 1949), deutscher Fußballspieler
 Jean Heinrich Weißhaupt (1832–1894), deutscher Fabrikant und Abgeordneter des Provinziallandtages der Provinz Hessen-Nassau
 Jörg Weißhaupt (* 1949), deutscher Fußballspieler
 Josef Weißhaupt (1863–1944), deutscher Landwirt und Politiker (Zentrum)
 Marc Weisshaupt (* 1970), deutscher Radrennfahrer
 Marco Weißhaupt (* 1972), deutscher Fußballspieler
 Noah Weißhaupt (* 2001), deutscher Fußballspieler
 Norbert Weißhaupt (* 1931), deutscher Fußballspieler
 Pamela Weisshaupt (* 1979), Schweizer Ruderin
 Viktor Weißhaupt (1848–1905), deutscher Maler

Siehe auch:
 Weishaupt


text:
Q: How to escape '@' in curl command password field My username is user1 and password is mypass8@
I wish to pass this username and password to curl command.
How do i escape the @ in the password when passing it to curl command ?
curl -k -X POST https://user1:mypass8@@myshop.com/job/build

I get the error message:

MESSAGE:Invalid password/token for user: user1

I also tried the following but all fail stating the password is not right as the 2 charecter and not considered in the password by the curl command.
curl -k -X POST https://'user1:mypass8@'@myshop.com/job/build
curl -k -X POST https://"user1:mypass8@"@myshop.com/job/build
curl -k -X POST https://user1:"mypass8@"@myshop.com/job/build
curl -k -X POST https://user1:'mypass8@'@myshop.com/job/build

Update: the login I m trying is for Jenkins admin console.
Can you please suggest ?

A: URLs use percent-encoding aka URL encoding.
@ sign is %40 in this encoding.
% curl -k -X POST https://user1:mypass8%40@myshop.com/job/build

Or alternatively with -u / --user parameter:
% curl -u user1:mypass8@ -k -X POST https://myshop.com/job/build

RFC 3986 section 3.2.1 states:

The userinfo subcomponent may consist of a user name and, optionally,
scheme-specific information about how to gain authorization to access
the resource.  The user information, if present, is followed by a
commercial at-sign ("@") that delimits it from the host.

  userinfo    = *( unreserved / pct-encoded / sub-delims / ":" )

Use of the format "user:password" in the userinfo field is
deprecated.  Applications should not render as clear text any data
after the first colon (":") character found within a userinfo
subcomponent unless the data after the colon is the empty string
(indicating no password).  Applications may choose to ignore or
reject such data when it is received as part of a reference and
should reject the storage of such data in unencrypted form.  The
passing of authentication information in clear text has proven to be
a security risk in almost every case where it has been used.

Applications that render a URI for the sake of user feedback, such as
in graphical hypertext browsing, should render userinfo in a way that
is distinguished from the rest of a URI, when feasible.  Such
rendering will assist the user in cases where the userinfo has been
misleadingly crafted to look like a trusted domain name
(Section 7.6).

Tested with this tiny Go application:
package main

import (
    "log"
    "net/http"
)

func auth(fn http.HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        user, pass, _ := r.BasicAuth()
        if !check(user, pass) {
            http.Error(w, `Unauthorized.`, 401)
            return
        }
        fn(w, r)
    }
}

func check(user string, pass string) bool {
    if user == `user` && pass == `pass@` {
        return true
    }

    return false
}

func index(writer http.ResponseWriter, request *http.Request) {
    writer.Write([]byte(`hello, world!`))
}

func main() {
    http.HandleFunc("/", auth(index))
    if err := http.ListenAndServe(":8080", nil); err != nil {
        log.Fatal(err)
    }
}

Run server:
% go run .

Test:
% curl -k -X POST http://user:pass%40@127.0.0.1:8080/
hello, world!

% curl -k -X POST http://user:pass@127.0.0.1:8080/
Unauthorized.

% curl --version
curl 7.72.0 (x86_64-pc-linux-gnu) libcurl/7.72.0 OpenSSL/1.1.1g zlib/1.2.11 zstd/1.4.5 libidn2/2.3.0 libpsl/0.21.1 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.41.0
Release-Date: 2020-08-19
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd

A: I have had success with URL-encoding the @s.  The problem is that when you say http://myuser:myp@ssword@host.example.com/file, it sees the username as myuser, the password as myp, and the host as ssword@host.example.com which is obviously wrong.
So if you do something like:
user="myuser"
pass="$( printf 'myp@ssword' | sed 's/@/%40/g' )"
curl "https://${user}:${pass}@host.example.com/file"

you should have better luck.

A: Since I don't know what the website looks like (assuming myshop.com is just an example) I am not sure if this could help.
Have you tried "-F" instead of "-X POST"? In case you are filling out a form that should work. That way you could put your password inside a file and call that files content with "<" like so:
curl -F password=</home/user/pw-file -F user=user1 myshop.com/job/build

A: Not working:
curl -u user1:mypass8@ -k -X POST https://myshop.com/job/build

Working:
curl -u 'user1:mypass8@' -k -X POST https://myshop.com/job/build

The single quote '' is required if you have @ in your password

redpajama_set_name: RedPajamaStackExchange


text:
Weather woes dent industry's recovery: IATA
By IATA
Feb. 2, 2011, Geneva, SUI - The International Air Transport Association (IATA) reported full-year 2010 demand statistics for international scheduled air traffic that showed an 8.2 per cent increase in the passenger business and a 20.6 per cent increase in freight.
Demand growth outstripped capacity increases of 4.4 per cent for passenger and 8.9 per cent for cargo. Average passenger load factor for the year was 78.4 per cent which is a 2.7 percentage point improvement on 2009. The freight load factor saw a 5.2 percentage point improvement to 53.8 per cent.
Compared to the pre-recession levels of early 2008, December air travel volumes were 4 per cent higher. Air freight was 1 per cent higher than pre-recession levels; however volumes have fallen 5 per cent since the peak of the post-recession inventory re-stocking boom in early 2010.
"The world is moving again. After the biggest demand decline in the history of aviation in 2009, people started to travel and do business again in 2010. Airlines ended the year slightly ahead of early 2008 volumes, but with a pathetic 2.7 per cent profit margin. The challenge is to turn the demand for mobility into sustainable profits," said Giovanni Bisignani, IATA's Director General and CEO.
Severe weather Europe and North America in December put a dent in the industry's recovery. It is estimated that this shaved 1 per cent off of total traffic demand for the month. As a result passenger demand dipped to 4.9 per cent growth on December 2009 levels, significantly lower than the 8.2 per cent growth recorded in November. Hardest hit was Europe which saw December growth slow to 3.3 per cent.
International Passenger Demand
Asia-Pacific carriers recorded a 9 per cent year-on-year increase in passenger demand in 2010. While December 2010 passenger demand growth slowed to 2.9 per cent, it is 11 per cent higher when compared to December 2008, just ahead of the industry's 9-10 per cent improvement over the same period. The economies of China and India continue to lead the region's recovery.
European carriers saw year-on-year passenger demand increase 5.1 per cent. This is double the capacity increase of 2.6 per cent, which shored-up the passenger load factor at 79.4 per cent. But the continent's economic uncertainty and continuing debt crisis limited yield improvements. Moreover, Europe was the hardest hit by December's severe weather which slowed demand growth to 3.3 per cent, less than half the 7.8 per cent growth recorded in November.
North American carriers recorded year-on-year increases in passenger demand of 7.4 per cent in 2010. A key feature in 2010 was the capacity discipline, where full-year capacity was up by just 3.9 per cent (leading to a sharp recovery in profits). The passenger load factor at 82.2 per cent for the full year (up from 79.6 per cent in 2009) may prove difficult to maintain if capacity additions accelerate over the period ahead. Passenger demand in December increased 6.7 per cent.
Middle Eastern carriers reported the strongest full year growth at 17.8 per cent on the back of a 13.2 per cent capacity increase fueled largely by aircraft deliveries to Gulf-based airlines. Load factors for the region showed a 3 percentage point increase to 76.0 per cent. December demand was 14.1 per cent above previous year levels and 35 per cent higher than in December 2008, illustrating the structural shift that is taking place in the industry as a result of the region's expansion.
Latin American carriers saw the whole year demand grow 8.2 per cent despite a 1.1 per cent decrease in December, a reflection of the demise of Mexicana. But the reality is that for 2010 overall, the total is almost 8 per cent more than 2008.
African carriers experienced a sharp rebound of nearly 12.9 per cent in 2010, although load factors remained well below the industry average, at 69.1 per cent. Their year ended with December demand at 11.7 per cent above previous year levels.
International Freight Demand
Freight demand growth varied wildly over the year from a high of 35.2 per cent in May to a low of 5.8 per cent in November. Overall the industry is trending towards normal growth pattern in line with the historical growth rate of 5-6 per cent.
The regional variation in growth remains particularly marked. Latin American carriers recorded the highest full-year growth rate of 29.1 per cent, followed by Middle East carriers (accounting for 11 per cent of the market) at 26.7 per cent, Asia Pacific airlines (with a 45 per cent market share) grew by 24.0 per cent, Africa at 23.8 per cent and North America by 21.8 per cent. Against these industry gains, Europe's 10.8 per cent growth stands out as exceptionally weak.
"The story this month is the sharp rise in oil prices. We predicted that 2011 would see a consecutive second year of profitability but with industry profits falling by 40 per cent to $9.1 billion. This was based on an oil price of $84 per barrel (Brent). Fuel accounts for 27 per cent of operating costs and a sustained rise in the oil price could spoil the party. With uncertainties in the Middle East, oil prices are now hovering near the $100 per barrel mark. For every dollar increase in the average price of a barrel of oil over the year, airlines face the difficult task of recovering an additional $1.6 billion in costs," said Bisignani.
IATA reports September traffic figures
IATA reports strong traffic growth
Passenger demand slowed 3.4 per cent in July: IATA
TrueNorth growth reflects BizAv recovery
Sikorsky completes investment in Eclipse Aerospace


The state of Alaska's record Chinook (King) Salmon weighed over 97 pounds, caught by Lester Anderson in 1985. It took ol' Lester more than 2 hours to bring in that "Fat" Chinook salmon.
Alaska is the largest state in the union and one fifth the size of the Lower 48. There is nearly a square mile per person! The fish and seafood industry is Alaska's largest private industry employer. Alaska is a fisherman's paradise and Alaskan waters are home to a large variety of sea life including King Crab, shrimp, Halibut, Herring, Orca Whales, sea lions and five Salmon species including Humpies, Chum, Coho and the prized FAT Pacific King Salmon. Skagway is also home to the famous Ivory King, which unlike regular King Salmon, is pure white meat.
The largest known Salmon caught in Alaskan waters tipped the scales at 97.5 pounds and took more than two hours to catch. Fishing is a passion that stirs your soul and residents of Alaska plan their schedules around the tides and salmon runs to be sure to get the most Salmon for their freezers or smokers.
Fortunately for visitors of Skagway, one doesn't have to be so meticulously organized in order to catch Salmon. King Salmon fishing in Skagway is the ultimate fishing experience of a lifetime. Unlike most cruise ports around the world, Skagway waters offer the angler an unparalleled opportunity to fish these legendary waters without commercial fishing vessels crowding and competing for your prized Pacific King!
Your extreme fishing adventure begins in Skagway's Small Boat Harbor, slip A-5, with FAT Salmon Charters. If you are arriving on a cruise ship, FAT Salmon Charters is an easy walk, docked next to the cruise ship docking. Owned and operated by USCG Master Captain Joe, winner of last year's fishing derby for Skagway locals and a resident for 14 years, Fat Salmon Charters is a well maintained, fully rigged, twin engine fishing vessel with a comfortably equipped cabin. Captain Joe's experience and knowledge, in combination with a fish finder and down riggers to get your line where the Salmon run, all work together to deliver an exciting and successful fishing experience. Fishing licenses are available on board.
Captain Joe takes great pride in making each charter excursion the ultimate fisherman's dream. Just minutes to the Lynn Canal, you'll spend your fishing experience actually fishing instead of cruising! The vast fjord of deep green sparkling glacier water and the breathtaking scenery engulfs you and is just a predecessor to the battle and excitement that lies ahead! Whether you are a seasoned angler or a beginner, Captain Joe will provide you with the gear and tackle you need to get that FAT Salmon on your line and in the boat. As you gaze at the towering peaks above, you'll feel a tug on the line – and your battle with a 60# Salmon has begun!
Half day, full day and exclusive charters are available and our charters are scheduled to coincide with the cruise schedules. There is no fishing experience anywhere that will compare with battling a Pacific King Salmon! At the end of your trip, when you're trying to figure out what to do with your catch, Captain Joe will clean your fish and prepare them for processing. Fat Salmon charters offers a variety of options for processing your catch and will arrange to have your fish delivered to your door upon your arrival home. Favorite Fat Salmon original recipes for preparing your prize catch, including a dishwasher recipe, are proudly shared. There is nothing tastier than a freshly caught Alaskan King Salmon and there is nothing more exhilarating than the battle that brought it to your table.
Don't miss this unique experience, book a charter fishing trip with Fat Salmon Charters today!


We just posted this recipe in June, but our family loves it so much we've had it several times. Even for dinner! It is easy to substitute whatever fresh items you have on hand. We use goat cheese instead of ricotta, which adds a few calories (but, it's worth it!). My daughter and her friend, Ave, treated us by preparing it for us last night. They opted to leave off the eggs but added peppers and mushrooms. It was a nice, light meal to finish out a long, hot day!
Posted in Recipes.	This entry was tagged diet, fresh, health, healthy, heart health, nutrition, produce, recipe, recipes, vegetables. Bookmark the permalink.


text:
© 2018 by Where She Goes...
Contact / Home
IT'S TOO DARN HOT
It's the first week of October.
And it's averaging 38 degrees.
It's also my first week on placement with my work counterparts: Lizzie, Dan and Kim. The four of us are working with a cluster of barangays in Cabiao (San Carlos, Santa Isabel, Bagong Sikat and Polilio) to create community specific DRRM plans. Our first step is to conduct a baseline survey, in order to find out what the locals know (and don't know) about flooding in their area. We have to target 100 households in each of our 4 barangays but we only have 3 days to do so. Pressure much.
Three of our barangays are quite far out from Cabiao's town centre (10-20km away) but are, in my biased opinion, the most beautiful. These areas are very rural- mostly populated by farmers and fishermen- and provide spectacular views of Mount Arayat. They are also some of the most susceptible to flooding, making our work even more crucial to these communities.
Unlike my host-home, which is based in a compound, the houses in these barangays are spread far apart. Walking door-to-door in this heat felt like a marathon effort and no amount of napping, sugary drinks or rice
was able to counter its effect. Like a clan of zombies we stumbled through the day and FINALLY hit our first target by sunset.
I'm starting to understand why Filipinos would rather catch a tricycle than walk 10 minutes to the shop because EVERYTHING feels like too much effort in this climate! (even blogging- hence the short and sweet post!)
Austin is Awesome!
There's no time to rush...
A Londoner in Charlotte
Life is all about how you handle Plan B...
On the Self-Stigma of Mental Illness
Unbelizeable!!!
Consciously decluttering your life
My Wedding Vows...
A Change of Scene...
Juicing (and juggling normal life!)
In Defence of Daydreams
Make Madrid My Home...
Playful Paris
Why I Quit Vipassana...


text:
Armitstead, Cavendish and Swift make it a Great British weekend
Cycling Weekly May 17, 2010 1:14 am
British cycling news round up logo
It has been an incredible weekend for Britain's cyclists.
A week after Bradley Wiggins won the opening stage of the Giro d'Italia and pulled on the pink jersey, Ben Swift, Lizzie Armitstead and then Mark Cavendish all followed suit in their respective races.
From Picardie to the Languedoc at the other end of France and then over in California, British riders were on top. Swift, Armitstead and Cavendish all had the pleasure of pulling on a leader's jersey too.
Can anyone remember a weekend when British cyclists enjoyed so much success on the road in a single weekend?
BRITS ON TOP
Saturday, Cires-les-Mello, northern France
Tour of Picardie stage two
Ben Swift won the sprint to take his first victory since joining Team Sky from Katusha. He also took the yellow leader's jersey.
Stage win for Swift>>
LIZZIE ARMITSTEAD
Saturday, Rieux-Minervois, southern France
Tour de l'Aude stage one
Using her track craft and turn of speed, Armitstead outsprinted the rest of a 10-rider break that got away 20 kilometres into the 117 kilometre stage. However, Armitstead lost the lead on Sunday when she punctured early in the team time trial, which her Cervélo squad went on to win.
Armitstead wins at the Tour de l'Aude>>
Sunday, Sissonne, northern France
Tour of Picardie overall
Team Sky controlled things on the final day and Swift sprinted to ninth place to clinch a seven-second victory over Spain's Koldo Fernandez. It was the first general classification win for Team Sky.
Overall win for Swift>>
Sunday, Sacramento, northern California
Tour of California stage one
Cavendish won the sprint in California after a text-book lead-out from his HTC-Columbia team. It was his third win of the season and the 54th of his career. The victory also gave him the leader's jersey.
Cavendish wins California opener>>
Fran Millar, Team Ineos CEO. Picture by Mike Prior
Team Ineos CEO pledges to win back the fans
Geraint Thomas praised rival Thibaut Pinot for his performance on La Planche des Belles Filles (Photo: Yuzuru SUNADA)
Geraint Thomas praises Thibaut Pinot for La Planche des Belles Filles performance at Tour de France 2019
Elia Viviani (left) missed out due to a puncture on stage seven (Photo by Justin Setterfield/Getty Images)
Puncture in final straight leaves Elia Viviani disappointed in Tour de France sprint


text:
Share this Story: Gallant 'far from done' after firing by Golden Knights
Gallant 'far from done' after firing by Golden Knights
Former Vegas Golden Knights head coach Gerard Gallant said he was both disappointed and surprised at his firing on Wednesday, two seasons after taking the team to the Stanley Cup Finals.
"I was quite surprised actually when it happened," Gallant told his hometown newspaper, the Journal Pioneer in Summerside, Prince Edward Island, Canada. "You don't see something coming like that when you have 2 1/2 years in."
Gallant 'far from done' after firing by Golden Knights Back to video
Gallant led the Golden Knights to a 51-24-7 record in their debut season of 2017-18. They lost to the Washington Capitals in a five-game Stanley Cup Final.
"I'm far from done," the 56-year-old Gallant said after posting a 118-75-20 record with the Golden Knights. "I enjoy coaching. … If an opportunity comes up, I will definitely look at it."
The Golden Knights just one point outside of a playoff spot at the time he was fired, plus he had been named the head coach of the Pacific Division team at this month's All-Star Game festivities.
He has been replaced in the All-Star Game by the Arizona Coyotes' Rick Tocchet.
"I talked to the NHL about it and they sort of left it up to me, but I didn't really feel comfortable (going)," Gallant told the Journal Pioneer. "I just said I'd sooner pass."


text:
Hannover Bismarckstraße – stacja kolejowa w Hanowerze, w kraju związkowym Dolna Saksonia, w Niemczech. Znajdują się tu 2 perony.

Stacje i przystanki kolejowe w Hanowerze


text:
This spring Vibe Pop/Rock Choir put on, not one, but two, brilliantly uplifting concerts raising over £1,500 for local charity Wellspring Counselling. Despite the freezing temperatures on Saturday 17th March, Vibe warmed the hearts of two packed audiences at their matinee and evening concerts held at the Methodist Church on Portishead High Street.
Vibe Pop/Rock Choir is co-lead by Wendy Sergeant and Catherine Smith. The choir, which sings a cappella arrangements of pop and rock songs, has been running for over a year with about 90 members of all different ages. "We're very proud of the wonderful community this choir has become. We're so lucky to work with such a brilliant bunch of people. We're also very proud of the charity element of Vibe. Each of our concerts has raised a significant amount of money for local charities, our spring concerts raising the most so far" (Catherine Smith).
"It's important to us that we support local charities. Many friends have told us what an amazing service Wellspring Counselling provide making counselling accessible and affordable to adults and young people." (Catherine Smith).
"I am so grateful for Vibe's heartfelt support for Wellspring, both in raising the profile of our charity in Portishead, and in raising such an amazing amount. The funds raised will go a long way to helping both our adult and young people clients in Portishead get the help they need." (Sarah Rees, Director of Wellspring Counselling).
"The health and wellbeing benefits of singing in a choir have been well documented and the ethos of Wellspring Counselling resonates well with that of Vibe. Many of our members have told us how uplifting they find our rehearsals" (Catherine Smith). As some of our choir members explain:
"I feel like I can leave all my worries behind when I am at choir."
"I really feel invigorated after being at choir every week, great fun and great for my wellbeing as I forget about normal life!"
"I'm amazed how much better I feel after a mentally stressful day at work – singing is very "mindful" and so therapeutic!"
"It doesn't matter how low I'm feeling, singing with Vibe always picks me up".
Anyone wanting to find out more about singing with vibe can e:mail vibepopchoir@gmail.com or check out our Vibe Pop/Rock Choir Facebook page. For more information about Wellspring Counselling please visit www.wellspringsomerset.btck.co.uk
Categorized in : Clevedon & Yatton News Latest News Nailsea News Pinned Post Portishead News
What a year for Yatton Youth Club!
Weston Endoscopy Unit Reopens after £1.5 facelift


MyTronome is a pattern-based metronome that has a precise sound engine, with tempos ranging from quarter notes at 15 bpm to sixteenth notes at 300 bpm (really, 1200 bpm!). It features a unique Measure page that allows you to customize a pattern with any number of beats. Each beat has its own volume control and can toggle between two different selectable sounds. You can create patterns in odd time signatures, clave patterns, patterns with accents, and patterns that just sound more musical because of the ability to change the dynamics of each beat.
Another unique feature offered in MyTronome is the On / Off function. MyTronome will play the number of measures you specify ON, then will silently keep time for the number of measures you specify OFF. The idea is that playing with a metronome is a great way to learn to play along with a steady beat, but it may not help you develop a steady internal beat yourself. You can practice, for example, with 3 measures on and 1 measure off - the metronome will help you keep time for 3 measures, but you will have to keep time yourself for the 4th measure. If that's not challenging enough, try practicing whole phrases - 4 measures on, 4 measures off - or maybe a 12 bar blues on, then a 12 bar blues off. If you're not interested in this feature, simply set the number of measures off to 0, and MyTronome will behave like a normal pattern-based metronome.
MyTronome features an array of great sounds, with short click or snap sounds, longer shaker and tambourine sounds, and drum sounds.
MyTronome also features the ability to save presets with a variety of selectable parameters. You can save the tempo, the on / off count, the measure pattern, the sounds used, or any combination of these parameters. So, you can have a "120 bpm, 4 on 4 off" preset, or a "7/8 shakers" preset, or a "247 bpm, 3 on 1 off, 4/4, Cowbells" preset.
updates and more great, useful music apps in the future.