Testimonials"I can't recommend HostVentures enough for hosting. We've been with them for several years and they're the only hosting company with whom we haven't grown frustrated after a few months. They're responsive, accommodating, and understanding of all our issues. The guys who run it are so dedicated to us it's crazy. HostVentures serves as a consultant to us on anything server or code-related we need help with."
Jakob
Businesses and organizations should be able to achieve near 100% uptime with reasonable costs. In this article we discuss some technical procedures and alternatives for creating a high availability infrastructure, incorporating hardware, software and networking components.
Here is a short list of technical benefits of a typical HA infrastructure:
Some business benefits may include:
Redundancy in all infrastructure components enables near perfect uptime when various components of the system fail or breakdown. This could involve hardware failures, server lock-ups, as well as network downtime from your providers. A thorough infrastructure plan needs to account for failure in all components which would ideally be handled automatically or with a very manual fast response.
Load balancing allows for scalability of your infrastructure, spreading load and requests across multiple servers, data centers and networks.
Failover means that in the event of a hardware or network outage customer requests are automatically redirected to an alternate location or set of servers. This means that when planning your infrastructure you need to account that failure of a node such as a network, server or entire datacenter will still allow for the remaining working components to handle 100% of the existing load. The cost of redundancy decreases with the number of independent nodes. For example, if there are 2 nodes, each needs to handle 100% of the work load in the event of a failure requiring capacity for 200% load. For a 3 node system, a single node failure requires the remaining two nodes to handle 100%. Therefore, each node needs to have capacity to handle 50% of the entire workload, for a total of 150% across the 3 nodes.
Native database replication is a very common technique for creating multiple copies of the same data for failover, redundancy, scalability and performance. All the major database products support various types of replication. For example, Oracle, Sybase, SQL Server, MySQL, PostgreSQL, and DB2 all support replication.
The mechanism works by writing binary logs of all transactions, transferring the atomic transaction information from master to slave servers and having the slave servers apply the same transactions as the master. Note that this technique causes all the database servers to undergo the same identical create/update load. The load generated by SQL select statements can be different on each server and can be load balanced to improve performance under certain circumstances.
One alternative is to have a single master in a single location that is accessed from all sites. This presents numerous issues, such as:
This type of replication is suitable for the purposes of creating redundancy within a single network much more so that globally distributing data.
A good alternative is to essentially have each distributed database be independent, each with independent sets of primary key ranges. For example, your database on the east coast can have customer ids between 1 and 10,000,000 while the west coast database can create them between 10,000,001 and up.
In this way, the two databases can replicate data in a master-master relationship without conflict in the creation of new records.
Most database replication schemes can be configured to use secure, SSL encrypted channels for transferring data between global locations. This is desirable in most circumstances assuming that the data is sensitive and might contain information such as credit card numbers and customer's personal data.
Message queuing is an age old distributed computing technique where disparate systems exchange messages via a third party tool such as IBM WebSphere MQ, or Java's JMS (Java Message Service). Message Queuing provides what is called fire-and-forget functionality for asynchronous processing.
The creation of the message can be treated as part of a global transaction involving database writes. Once the message is successfully created, the process or thread does not need to wait until it is processed and can continue about its work without any delay to the end user.
Messages can be persisted (stored) to either the local file system or a database and are thus able to survive a crash of the processes on the physical machine. As long as these storage mechanisms are not corrupted the messages are guaranteed to eventually get sent and processed.
The messages can contain anything one desires. For example, fixed length headers defining the type of message, SQL commands, XML, or any binary or ASCII data are all typical.
Products such as IBM's WebSphere MQ run on dozens of different platforms, from wireless devices, to mainframes, to PC's and many proprietary hardware systems. Similarly, JMS can run on any system that supports Java.
Since PHP as of version 4.x does not support asynchronous processing and thread creation, we are left with the queuing the work locally and having other processes pick up the work.
Manually log all SQL statements to a file per database. Have a cron job invoke a PHP program every minute that will handle the file asynchronously from normal web processing. The cron job can be written in PHP and may perform one or more of the following tasks:
Synchronization of static content, meaning content other than software or scripts, such as HTML, image and movie files can be handled using a variety of simple techniques. For example:
© Copyright HOSTVENTURES.COM 2006. All Rights Reserved.