Physical Architecture¶

The scheduling software comprises of a number of different types of services:

• Those concerned with input/output of data and system monitoring
• Internal services to provide data for scheduling and use schedules
• Services used for actual scheduling and optimization.

This section explains the scheduling design architecture that has been adopted. It details how the architecture enables the scheduling solution to be configured to cope with enterprise system issues and addresses specifically the areas of:

• Scalability
• Availability
• Manageability

N-Tier Design Overview¶

A 5 tier architecture has been adopted for the deployment of the scheduling system. The five tiers are separated - both logically and physically into:

• The client tier, responsible for interacting with the user via a Graphical User Interface (GUI) and submitting requests via the network to the mid tier. The client tier consists primarily of the Scheduling Workbench, but may also include other 3rd party applications either operating via thick clients or web service components.
• The mid tier, responsible for gathering requests from clients and executing transactions against the data tier. Also responsible for sending data back to the client tier. This is supported by the Schedule Input Manager and Schedule Broadcast Manager components respectively.

• The data tier, responsible for physical storage and manipulation of the information represented by application queries and the responses to those queries. The data tier is a relational database engine, such as the Oracle RDBMS or Microsoft SQL Server. Within this tier 2 further sub-tiers are defined:

  • Data Access Layer (DAL) which enable database independent transactions to take place.
  • Business Object Layer (BOL) which defines a number of methods to be used by applications wishing to interface with the data tier.

• The scheduling tier is responsible for extracting data from the data tier and managing simultaneous problem space solutions to produces a scheduling plan. In addition this tier provides travel time data for use by the scheduler components.

• The optimisation tier is responsible for solving particular problems or a sub-set of the larger problem space.

The benefits of 5 tier architecture include:

• Centralization of business logic for ease of maintenance.
• Separation of user interface logic from data access logic.
• The ability to spread work over several servers (load balancing).
• When the client tier is a browser, an independence from the platform used to execute user interface logic, allowing a broader reach for the application.
• Separation of CPU intensive processes from data storage and retrieval operations.

Scalability¶

Scalability is a desirable property of a system which indicates its ability to either handle growing amounts of work in a graceful manner, or to be readily enlarged through the addition of hardware and/or instances of the software components. For example, it can refer to the capability of a system to increase total throughput under an increased load when resources (typically hardware) are added.

Scalability, as a property of systems, is generally difficult to define and in any particular case it is necessary to define the specific requirements for scalability on those dimensions which are deemed important. A system whose performance improves after adding hardware, proportionally to the capacity added, is said to be a scalable system. The primary dimensions regarding scalability for the scheduling solution are:

• Speed of data transfer
• CPU processor capacity (speed and quantity)
• Hardware memory

Secondary dimensions with particular reference to certain tiers would be:

• Database technology used in the Data tier
• Network connectivity and speed in and between the Scheduling/Optimisation tiers

A highly scalable solution is achieved through the use of the following approaches:

Asynchronous Processing¶

An asynchronous processing approach has been adopted for all the inter-tier communication flows. Because the time to place objects on the queue is imperceptible vs. the time it takes to process the transaction in the database, the perceived speed of the system is dramatically increased. The other advantage of this queued configuration is that it is possible to scale the back end in one of two ways. You can employ the same scale-up strategy from a synchronous design and simply add more power to a single back end. But the asynchronous approach design enables a scale-out strategy to be employed. Instead of having a single back end that processes the queue, you can have multiple back ends picking off queue data and processing it.

Asynchronous Communication¶

This approach is adopted for the communication between the Client/Mid/Data tier and between the Scheduling/Optimisation tier. The Input Manager and Broadcast Manager both operate as asynchronous multithreaded components processing data in and out of the scheduling system respectively.

Autonomous Tiers¶

Each tier within the scheduling system can be viewed as a self-contained group of software components. Each tier can be separated out on to its own hardware platform, and within each tier the software components may also be split on to separate server platforms. With the exception of the Data tier, each component may have numerous instances. How this is accomplished with the Data tier depends on the database technology employed and related more to redundancy and system availability.

Database Scalability¶

SQL Server and Oracle are the supported database technologies for the Data tier. These technologies support VLDB and OLTP systems and are scalable in their own right. Server clusters can be defined for the database, and disk access distributed across several storage devices.

The database has been designed in such a way that it can be tuned for bulk inserts and query of data using parallel query options within these technologies. In addition scheduling problems can be logically partitioned within the database and these logical partitions mapped to specific physical storage devices thus enabling disk load balancing to be achieved if required.

Scheduling Scalability¶

A Dynamic Scheduling Engine uses various techniques to split a scheduling problem into a number of near equally sized problem spaces and allocates a processor to the resolution of each problem. The maximum processing power available on the server is utilized to resolve the scheduling problems using parallel programming techniques.

Availability¶

Large scale systems often need to be highly available. Availability is the ability of a system to be operational a large percentage of the time - the extreme being 24/7 operations. The largest challenge to availability is surviving system instabilities, whether from hardware or software failures.

In the mid-tier, building highly available systems starts with using high-quality hardware with features such as RAID drive arrays and redundant power supplies, network cards in a data centre with adequate protection from power outages. However, even with such hardware, systems can still fail. If the system has been designed to be load balanced, and more than one machine is handling the load, it can survive the failure of any individual machine.

Client/Data Tier Availability¶

Here load balancing products are available to distribute the data input from the web applications across several servers. So in the event of a particular server failing the remaining servers can take the additional load while standby servers are started.

Standby servers can be configured for both the Input Manager and Broadcast Manager software components.

Mid/Scheduling Tier Availability¶

Availability in the data tier is achieved through clustering technology. Clustering is the use of more than one server to provide access to the same data store. Often this means that two servers are connected to the same physical drive array, with one of the servers on "standby." If something should happen to the active server, the second server comes online and begins serving the mid-tier requests in place of the first server. These two servers are collectively referred to as a cluster, although the term could apply to groups containing more than two servers if higher degrees of availability were required.

Clustering can be combined with partitioning to provide a data tier that is both highly available and highly scalable. Each individual partition must be separately clustered.

The design of the scheduling software components support this type of physical resilience.

There is also an option for input to the mid-tier Input Manager service to be copied to another service on a server on the same network.

Data replication and failover DR options can easily be configured allowing for deployment in multinational environments using VMware. In this case for the UK and NL.

In addition, the system supports automatic detection of services becoming non-responsive, and the ability to automatically restart services when this occurs. This is achieved via the administration service monitoring and the service management service.

Manageability¶

The key to high availability is redundancy: if there is more than one of everything, you are then not susceptible to any single points of failure. However, although redundancy means that the system as a whole will be up when you need it to be up, individual components are still bound to fail. It is important to know when this happens so that corrective action can be taken.

The system includes a Scheduling Administration Service which is responsible for the housekeeping operations on the Database and for monitoring the scheduling services. This monitoring includes each service and service memory, CPU usage as well as any application warnings or errors. Service failure can be notified via email and service status can be monitored in real time by administration functions of the Scheduling Workbench.

Manageability is twofold. It includes both the ability to detect faults (or the absence of faults) and the ability to automatically react to them. These abilities come from instrumentation and enterprise monitoring respectively.

Instrumentation is the feature of system components that lets us determine their health at any given point in time. The simplest form of software instrumentation is code that simply logs a message when a fault is detected.

In order to provide the ability for third parties to detect errors in an enterprise installation all scheduling software components write status and processing messages to their respective operating system event logs. These indicate error/warning conditions or just information. Secondly components register their activation via entries on the database which can be periodically monitored. These entries take the form of application name, server, instance number and current status.