From startup to mega-store, MiDAS is ready
\MiDAS is a highly scalable and fault tolerant ecommerce
engine that can support ecommerce solutions and online catalog features to meet needs of any scale, but is still well within the reach of a single server startup.
The MiDAS Commerce Engine application server delivers scalability via:
- The ability to run under heavy load and utilize multiple processors; and
- The ability to EASILY scale across multiple servers providing load balancing and true fault tolerance.
- A compiled code layer that provides all business logic processing for top performance.
- High performance relational database design that delivers rapid results with nominal processing power.
- Proven front end technology that can be quickly replicated across multiple boxes.
 Back
to Top
The MiDAS Commerce Engine delivers fault tolerance via:
- The supported ability to easily scale MiDAS sites across multiple servers; and
- Support for a standard RDBMS system (SQL Server 7.0 and above) with a wide variety of built-in and third party means for server replication, load balancing and fault tolerance.
- Standalone MiDAS servers benefit from the fault tolerance model as well, since they can be restarted without loss of session data. As such, late night software updates or other maintenance procedures that require reloads will NOT cause customers to lose their orders. MiDAS is the only solution in the marketplace that offers this kind of update-on-the-fly resilience.
- MiDAS is based on easy to support standard platforms and technology, enabling quick recoveries from hardware or operating system failures and leveraging a more readily available pool of qualified human resources to help reduce operational costs and specialization.
The MiDAS application server stores all customer information and session details (temporal and permanent) within it's own data store so that user specific, session specific, and order specific data persist across web server reloads or restarts and across server reloads or restarts. This feature exists, and allows servers to recover from OS and Web Server errors very gracefully, even in single box implementations. Additionally, session information (basket, login, customer info, special requests, etc.) are not server specific. This allows a user to move from server to server within a server farm transparently with no loss of persistent or temporal data. These powerful features can be easily harnessed using simple DNS based load balancing or they can be combined with load balancing hardware and low-cost SQL replication or server clustering to allow true 100% fault tolerance for any budget.
Geographic diversity is also enabled in advanced configurations via the application server's built-in ability to retrieve it’s configuration information via a secure (SSL and authentication based) and fault tolerant URL (Public or Private).
Back
to Top
This basic redundancy example utilizes 3 Servers to create a low-cost fault-tolerant environment where any single server can hard fail without interrupting commerce operations. In addition, this system can run stand-alone off of one server when updates or maintenance are being completed.
See Single Server recommendations and,
 1. reduce disk space requirements on server 3 to 10 GB available regardless of configuration, unless your site content (not including product images) would require more disk space than this, and
2. add requirement for secondary NIC in server 1 and 2.
- Multiple Upstream ISP's, T1 or better
- BGP Capable Router (Cisco 3640 or better suggested)
-Port configurable switch (Cisco 2950 or 3550 suggested)
- Backup Generator or Data Center collocation
Server 1 roles:
- MiDAS Application Server
- DB Server
- MiDAS Configuration Store
Server 2 roles:
- MiDAS Application Server
- Backup DB Server
- Backup MiDAS Configuration Server
- DNS Server
Server 3 roles:
- MiDAS Application Server
- DNS Server
- Monitoring Service
Basic Load Balancing method:
DNS - Round Robin
Redundant Servers:
- automated replication of site design and non-MiDAS related content
- Dual SQL Servers (offline backup) configured to share transaction file, automated hourly backup of master.
- Dual-located MiDAS central configuration file (fault-tolerant URL based master configuration)
Functionality Explained:
When a customer makes a request to this server farm, DNS passes a list of 3 records (1 for each server), in each request a different server will be listed in the first position in the returned list of IP addresses, this is a standard feature of "round-robin" DNS. Round robin DNS is a feature of most DNS servers in production. To create round robin entries, the administrator simply enters multiple A records with different IP addresses for the same host name. The client machine (visitor) will try first to connect to that first host and if it times out, it will try the second and so on. Because MiDAS session data (order contents, logged in account information, etc.) is stored in the MiDAS database it is not machine specific. Therefore, if a visitor adds an item to his or her order while connected to one server and the next web request is sent to a different server the same data will still be present. As a result, the status of a single server will not affect the overall user experience. If a single server fails, the user can be redirected to another server without loss of information, status, order contents, etc.
Scripted server monitoring enables down servers to be removed from the DNS "round robin" list. Off-the-shelf packages such as Ipswitch Inc's "What's Up Gold" (less than one thousand dollars) can detect a failed device or service and initiate a script call (to remove the entry). It is also possible to create MiDAS specific entries within this specific, or other, monitoring packages. Such packages can also detect recovery and initiate scripts to return the DNS entry to distribution.
Without special hardware or software, SQL Server fault tolerance can still be implemented in conjunction with a third party monitoring tool as follows...
* Each instance of a properly configured SQL server can support 4-5 MiDAS application servers.
Basic (Low Cost) Redundant Database Setup Details:
Setup Requirements:
(2) Servers (Server 1 and 2 in this example)
(2) Licenses of SQL Server Enterprise Edition (V 7.0 or greater)
(1) Cisco or other manageable switch
Server 1:
- The "SQL Service" is configured to run automatically.
- The data files (*.mdf) are located on the local or a remote file system.
- The transaction logs are located on a remote file system, accessible to both SQL servers.
- A SQL maintenance plan is generated to backup the databases hourly (to a remote disk location accessible to both servers)
- A script is generated, which if called can stop the SQL service and can be called remotely.
- A script is generated, which if called can start the SQL service and can be called remotely.
- The second NIC is configured with the "shared" IP address.
- A WSH script is generated to disable the secondary NIC if the SQL Service fails.
Server 2: (Backup SQL Server)
- The "SQL Service" is configured to run automatically.
- The data files (*.mdf) are located on the local or a remote file system.
- The transaction logs are pointed at a local file system.
- A SQL maintenance plan is generated to restore the databases hourly (from a remote disk location accessible to both servers)
- A script is generated, which if called can stop the SQL service and can be called remotely.
- A script is generated, which if called can start the SQL service and can be called remotely.
- A SQL maintenance plan is generated to restore the databases hourly (from a remote disk location accessible to both servers)
- The second NIC is configured with the "shared" IP address, but left disabled.
- A WSH script is generated to enable the secondary NIC if the SQL Service fails on the primary server.
Server 3:
- What's Up Gold (Ipswitch, Inc. (www.ipswitch.com) is configured to monitor the SQL service. If it fails (and restarting the service fails) the scripts are called to:
1. Disable the secondary NIC on the primary SQL server.
2. Enable the secondary NIC on the secondary server.
3. Run the SQL Script to:
- Dismount the secondary server's copy of the MiDAS database.
- Change the transaction log location to the network location where the primary server last wrote data to the transaction logs.
- Remount the copy of the MiDAS database.
4. Send the command to the switch to reload the ARP cache.
5. Alert the administrator
Basic Fault Tolerance Summary:
This basic or "configured" means of fault tolerance and load balancing provides low cost and remarkably strong uptime protections but does not produce a truly balanced load. When users arrive at a site, they typically cache the DNS record they receive the first time. Thus, subsequent page requests from that user will be passed to the same server. As a result, it is possible that many active users - requesting many pages, executing many searches and ordering a lot of items - may be randomly directed to a single server while another server handles an equal number of visitors who simply view one page and realize they are at the wrong site. In that example, the fault tolerance is still present, but one server is carrying the larger portion of the load. This is not typically a problem as random probability suggests that the round-robin approach will share the load between servers in most instances. For instances where more precise load balancing is needed there other approaches that can be taken such as server clustering and the use of hardware load director's such as Cisco's "Load Director". More information about managed load models are available by contacting Swift Software or one if it's systems integrators. MiDAS can interoperate with both of these models and a variety of load balancing and fault tolerant solutions.
Back
to Top
As seen in the diagram above, MiDAS leverages Microsoft
Clustering Technology and Cisco's Load Balancing and Network Technologies,
in conjunction with good network design and a robust BGP4 protocol
implementation to provide a 100% fault tolerant commerce environment
for your mission critical applications. In this example, you could
lose a switch, a router, a server or two, an ISP could go down...
and through it all, you continue to take orders.
For more specific HA examples or consulting, or a quote on implementation of a MiDAS based solution, contact a MiDAS channel partner.
Back
to Top
|
