As the services I described were the first things that came into my mind with regards to high availability in Barbican I assumed that there was probably a better strategy.
If the strategy is as you've described then that's great - even I can understand that! -Rob > > Our plan for deployment is exactly as Clark described: > > > * Several API nodes behind a load balancer > * PostgreSQL master/slave replication > * HSMs in HA paired mode > * Several Worker nodes > > I’m also curios as to why this would be considered “clunky”? > > -Doug > > On 3/19/14, 1:21 PM, "Clint Byrum" <cl...@fewbar.com> wrote: > > >Excerpts from Clark, Robert Graham's message of 2014-03-19 07:41:35 - > 0700: > >> Has there been much discussion on how to ensure that keys are > >> recoverable in the event that Barbican has some sort of horrific > >> failure? > >> > >> I suppose a HA frontend, Redundant Keystore Databases and HA paired > >> HSMs would be the most obvious non-code-writing path but this feels > >> pretty clunky, I was wondering if it had been discussed yet? Possibly > >> it should be something for a design session? > >> > > > >Sorry, what is clunky about backing up your data? > > > >_______________________________________________ > >Mailing list: > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > >Post to : openstack@lists.openstack.org > >Unsubscribe : > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack