Open Stack

You're looking to provide data redundancy across keystone instances with
varying backend implementations... what's your use case? How would you
orchestrate the synchronization and failover, if any? What's the purpose of
each backend in such a deployment?

-Dolph


On Wed, Aug 29, 2012 at 3:50 AM, pat <pat at xvalheru.org> wrote:

> Hi Joe,
>
> OK, this is clear to me, but I more think about this scenario: each
> keystone
> has its own storage and the keystones are interconnected and replicating
> the
> information on keystone layer - so for example one keystone can be
> connected
> to LDAP another to DB or KVS etc.
>
> Thanks a lot for your answers and patience :-) Your answers are helpful to
> me.
>
>      Pat
>
> On Tue, 28 Aug 2012 08:55:16 -0700, Joseph Heck wrote
> > On Aug 28, 2012, at 12:41 AM, pat <pat at xvalheru.org> wrote:
> > > Thanks for Q1. About Q2, I more think about keystone instances and
> each has
> > > its own storage and the keystones are interconnected and their data are
> > > replicated. The DB, in your suggestion, looks like single point of
> failure
> to me.
> >
> > Hi Pat,
> >
> > Yes - it definitely could be. If you're setting up keystone in an HA
> > configuration, then I'd expect that you actually have a mysql
> > cluster backing the database that could allow a single instance of
> > mysql to fail and maintain services. Keystone, like Nova, Glance,
> >  etc is stashing it's state somewhere - the WSGI processes that run
> > keystone have moved that to MySQL, so MySQL is the place where you
> > need to watch and care for.
> >
> > Many implementations of OpenStack that I've seen have shared the
> > MySQL instance between keystone, nova, and glance, and quite
> > successfully.
> >
> > If you were using LDAP entirely for the backend instead of the SQL
> > backed mechanisms, then you'd need a replicated/failover cluster for
> > LDAP as well.
> >
> > -joe
> >
> > > On Mon, 27 Aug 2012 09:46:41 -0700, Joseph Heck wrote
> > >> Hi Pat,
> > >>
> > >> On Aug 27, 2012, at 8:09 AM, pat <pat at xvalheru.org> wrote:
> > >>> I have two questions regarding OpenStack Keystone:
> > >>>
> > >>> Q1) The Folsom release supports domains. The domain can contain more
> tenants
> > >>> and tenant cannot be shared between domains. Is this right? I think
> so, but
> > >>> want to be sure.
> > >>
> > >> I'm afraid it doesn't. We didn't make sufficient progress with the
> > >> V3 API (which is what incorporates domains) to include that with the
> > >> Folsom release. We expect this to be available with the grizzly
> release.
> > >>
> > >>> Q2) Is it posible to have a “cluster” of the Keystones to avoid
> Keystone
> to be
> > >>> a bottleneck? If so, could you point me to a “tutorial”? Or did I
> missed
> > >>> something important?
> > >>
> > >> If by "cluster" you mean multiple instances to handle requests, then
> > >> absolutely - yes. For this particular response, I'll assume you're
> > >> using a SQL backend for Keystone. Generally you maintain a single
> > >> "database" - wether that's an HA cluster or a single instance, and
> > >> any number of Keystone service instances can point to and use that.
> > >>
> > >
> > >
> > > ----------------------------------------
> > > Freehosting PIPNI - http://www.pipni.cz/
> > >
> > >
> > > _______________________________________________
> > > Mailing list: https://launchpad.net/~openstack
> > > Post to     : openstack at lists.launchpad.net
> > > Unsubscribe : https://launchpad.net/~openstack
> > > More help   : https://help.launchpad.net/ListHelp
> >
> > ----------------------------------------
> > Freehosting PIPNI - http://www.pipni.cz/
>
>
> ----------------------------------------
> Freehosting PIPNI - http://www.pipni.cz/
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120829/40782d8b/attachment.html>