I understand about HIPAA. I disagree with the technical need on technical grounds, but I understand and we needn't argue the point.
Where the application can run on S3 forests, I see no reason for forest-level replication at all. Forest replication is a host failure strategy for HA, and using a CloudFormation template with ASG configuration will take care of any instance failures. If CloudFormation itself fails, that counts as a disaster and your DR plan kicks in. An S3 failure would also count as a disaster. Either way your DR plan is probably database replication, or maybe journaled backup. Think seriously about any AWS dependencies, because the nature of the disaster may be that AWS itself has failed in a catastrophic way. -- Mike On 14 Mar 2014, at 15:43 , Marc Young <[email protected]> wrote: > I'm not sure about ephemeral, S3 was attractive, although I've read that the > overhead/performance degredations are not worth it. As for encryption, it's a > must, our BAA requires HIPAA compliance, so data must be encrypted during > transmission and at rest. > > > On Fri, Mar 14, 2014 at 5:29 PM, Michael Blakeley <[email protected]> wrote: > 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 > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
