On Fri, 1 Jun 2012, Tommi Virtanen wrote:
The problem with storing things in RAM is, what if your rack/row/data center loses power, all at once. It's really hard to guard against those kinds of massive failures. If you don't have a persistent journal, you might as well not have a journal at all.
The storage nodes can be put in different data centers with different kinds of uninterruptable power, from emergency power (diesel backed up batteries) to a small UPS (batteries) for individual nodes. This would hopefully give Ceph enough time to write down the journal to disk.
I am not sure that using for example battery backed up hardware raid cards would give better performance and reliability for the same money. Especially if existing infrastructure may be used for uninterruptable power. That would be interesting to figure out.
The memory-only systems you see out there are typically only used to the kinds of applications where rolling back to last (on-disk) snapshot is acceptable -- stuff like shopping carts. Ceph is built on significantly stronger promises, so it's not the ideal match for an architecture like that.
I will begin with rsyncing disk backups there and maybe use it for temporary but fast storage. Rolling back to a consistent state some (shorter) time ago would be fine. If Ceph itself is stable it could later be used for data that cannot so easily be recreated.
It would be great to be able for individual users and existing applications to use the data directly from Ceph and old snapshots there instead of having to read back the data from Ceph into a normal file server by a system administrator.
It's also unclear to me on what would happen to Ceph if all the replicas lost their journals at the same time. That might cause bigger problems, since there's no up to date replica to pull the lost data from.
It would be very interesting to know what would happen. --jerker -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
