We've got server virtualization, desktop virtualization, storage, application and I/O virtualization. So why not database virtualization?
Indeed, why not. At MediaNews Group Interactive, the online division of newspaper holding company MediaNews Group, database operations team leader Ryan Johnson is about to put xkoto Inc.'s Gridscale into production. The goal: to virtualize a pool of IBM DB2 database servers that handles the company's publishing system. With it, Johnson expects to achieve better load balancing, scalability, uptime -- and, ultimately, create a better disaster recovery (DR) strategy .Xkoto Gridscale works by sitting in front of a pool of identical IBM DB2 servers and intercepting SQL statements slated for the database. It then broadcasts these commands to all database instances and keeps track of which database nodes have successfully committed the changes.
In contrast, most database high availability (HA) tools on the market today are based on active and passive clustering techniques in which one server acts as the master and replicates changed data -- the result of the SQL statement -- to a secondary server that takes over in the case of failure. With xkoto's system, however, all servers in the cluster are active and handle requests.
"In and of themselves, [traditional HA/DR products] are good, but most of them still have periods of downtime for the cutover," Johnson said. "We wanted 100% uptime, as well as the ability to take [database] servers in and out of the mix." Over the past year, Johnson has been testing Gridscale.
Further, using storage replication for high availability has serious performance implications, said Dan Kusnetzky, principal analyst at the Osprey, Fla.-based Kusnetzky Group. "Every time a change occurs, you have to replicate the changes, which has a great level of impact on the application," he said. "It also assumes a hearty amount of bandwidth."
Adding new database servers behind Gridscale also increases database performance – hence the number of users that can access the system. Johnson reported that adding a new database server behind Gridscale results in a 50% performance boost.
Xkoto thinks different
The question of how to effectively scale and protect databases is not new, with most answers centering on replication. "Storage replication issues go back 30 years," Kusnetzky said. Xkoto's innovation was to look at the same problem everyone else was seeing, but rather than look at the output side, ask, ' What if we looked at the input side; what's going into the database?' '"
This simple idea, Kusnetzky said, "is diabolically clever." Relative to the actual data in the database, SQL commands are small and easy to replicate. Further, hardware, operating system, and storage no longer need to be identical, and the databases themselves no longer need to work in lockstep.MediaNews' Johnson can attest to this idea. "The hardware can definitely be different – with Linux on one, and Windows on the other. And also, "when you tack on new servers, they don't have to be big servers, so there's no need to overplan," Johnson said.
Carrying the xkoto concept to its logical conclusion, Kusnetzky said that eventually, even the databases themselves won't need to be the same, as long as they all adhere to SQL. "With sufficient intelligence, you could have Microsoft SQL Server on one end, and Oracle on the other," he predicted.
"That might be a stretch," said Johnson, at least from where he's sitting. But the company does have plans to use Gridscale to improve its disaster recovery capabilities by adding a DB2 server at a remote data center location. "We'll put a database server in another cyber center that will receive all the write updates, but won't be turned on [until it needs to be]," he said.
Let us know what you think about the story; email Alex Barrett, News Director.