Why are we talking about transcendence?
tran·scend
transitive verb
1
a : to rise above or go beyond the limits of
b : to triumph over the negative or restrictive aspects of : overcome
c : to be prior to, beyond, and above (the universe or material existence)
intransitive verb
: to rise above or extend notably beyond ordinary limits
In addition to the dry, boring dictionary definition, there is a long standing theme in science fiction of humans transcending physical limits. In science fiction, humans may upload themselves to digital storage, clone their bodies, and automatically download their backups into new bodies if they’re killed. They may just as easily download their consciousness into a new, improved body without changing what they know or who they are.
What science fiction does for humans, Sanoid does for servers.
Sanoid helps Windows, Linux, and BSD servers transcend the limits of bare metal and achieve the true persistence of pure data. Sounds like a bunch of woo, right?
pictured above: a bunch of woo.
OK, let’s get lots more nitty gritty: you run your existing servers the way you always have, but you run them on top of Sanoid hardware and software. Every hour, on the hour, Sanoid takes a complete point-in-time snapshot of not just data on your server(s) , but the entire server(s) – including databases, system state, and everything else that’s usually a pain to back up. Have a system update go bad? Have a user click the wrong link, and by the time you get a call, half your server is encrypted with a key that only some bad actor in Romania has?
If any of those things happen, you’re literally seconds away from being up and running again: a single command rolls back your entire virtual machine to a snapshot from the top of the hour… instantly. Did the call come in slower than that? No problem – roll back to two or three hours ago. Or a day ago. Or a month ago. You’d be surprised just how far block-level snapshots let you keep versions of your data – the system defaults keep three full months, and suit nearly all use cases. (One client wanted seven years of daily snapshots on hand. No problem.)
What about physical problems?
Sanoid offers rapid network replication as well. Our most recommended topology is to have three Sanoid hosts functioning as a unit: you have a production host and a hotspare host onsite, and a disaster recovery host offsite. Production runs all of your servers directly; hotspare replicates them in every hour on the hour, and offsite DR replicates them in daily (or more frequently, depending on your bandwidth). And no, you don’t need point to point fiber to make it happen: in the real world, one client firm replicates 2.5TB of data offsite over a 1mbps connection. Typically, in less than an hour.
This might seem too good to be true, but it isn’t. Once a Sanoid host gets its initial replication from a source, later replication only needs to move the changed blocks. But don’t confuse this with old-school differential tape backups! You get fully complete and self-contained snapshots on both sides, with no painful to reassembly or “restore” operations needed. Your backup can literally boot, as-is, directly on the backup target… either in an isolated test network, or (for an onsite hotspare) on the production network, to bring mission-critical sites and services back online without needing to wait for repair operations on the production host.
OK, but performance…
Sanoid uses top-notch server hardware and the world-class ZFS filesystem. ZFS has more features than you can shake a stick at – in fact, I’ve written a few articles about it – but when it comes to performance, you’ll want to know about the ZFS ARC.
Unlike other Linux, Windows, and BSD filesystems, ZFS doesn’t use a simple “first-in, first-out” (FIFO) cache. With a FIFO cache, if you read 10GB of data from your disks, then read that 10GB of data from cache 100 times in a minute, you’ll still lose it all once you read more data in that won’t fit in the cache. ZFS uses its own Adaptive Replacement Cache (ARC), instead – each time a block is reread, or “hit” from cache, it is weighted so that it’s less likely to be displaced. In the real world, this means more I/O from RAM, less I/O from disk, and tremendously increased performance for almost all workloads.
Can I afford it?
Absolutely. As of June 2015, Sanoid’s Small Business Edition – which features all of the capabilities listed above – can be had for less than $3000*, fully configured and ready to go. That includes a three year hardware warranty, and one year (renewable) of support and basic network monitoring. (Network monitoring: if your server throws a disk, or your offsite backup doesn’t get updated, we call you directly and make sure you know about it.) Don’t be fooled by the low cost, though – Sanoid SBE features an Intel Xeon processor with plenty of RAM on the hardware side. It’s actually more powerful than the demo hardware I take to tech conferences… and you can bet that I want people to be wowed by the demos!
If you need to support more than two or three virtual machines – or just plain want more firepower – Sanoid Standard and Sanoid Pro are available with rackmount chassis, external hot-swap bays, and all the other goodies you’d expect.
* final price depends on storage selected and some other optional upgrades
Thanks for reading!
If you’d like to learn more about Sanoid and the technologies that make it work – or place an order – you can email the company at info (at) openoid.net, you can tweet me @jrssnet, or you can check out the code (I remembered to mention that this is all open source software and commodity hardware, right?) on Github.