I've done a fair amount of work with AWS, including failover, but none with disk encryption.
As I see it the main scenario in which to guard against host (EC2 instance) failure is when using ephemeral storage. That can be attractive sometimes, and in that case forests should be replicated within a cluster of at least three hosts. In some cases each forest might have two replicas, each on a different instance. With EBS there's less of a case for guarding against host failure. It's fairly straightforward to replace a failed instance without losing the volumes, and the MarkLogic CloudFormation templates should make it automatic. Guarding against host and disk failure is mostly about high availability. If disaster recovery is also important, consider database replication to a different cluster in a different AWS data center - or off AWS, to another cloud provider or to private hardware. In the past, AWS outages have sometimes affected infrastructure that is shared between multiple data centers. If data security is a concern, I would prioritize ordinary hygiene: firewall configuration, cluster communications, and communication with users. Encrypting the disk seems like overkill to me, and is likely to work against any HA strategy because you wouldn't want to store the key in AWS too. Of course you might face an obligation to use disk encryption whether it makes sense or not.... -- Mike On 13 Mar 2014, at 08:22 , Marc Young <[email protected]> wrote: > I'm curious what implementations others have made for data redundancy > (failover) for cloud implementations. I understand forest duplication and > failover in the ML engine, but has anyone used this at AWS? We're using > MarkLogic on a single node and the data is stored to a LUKS encrypted mounted > partition. I'm curious if there are any other implementations that are > elegant, such as encrypted GlusterFS, HBase, etc as the filesystem store. I > know this is open ended, I'd just like to know who's done this in production > and what they like about it, or what pointers they'd like to give someone new > to this area. > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
