openstack team mailing list archive

["pat" <pat@xxxxxxxxxxxx>]

Hi Dolph,

Well, I don't have such use case (this just came to my mind), but yes, it's
with data redundancy, etc. I think about synchronization at Keystone level ...
the failover is the problem. As I wrote, I'm curious if this is possible.

Thanks for your answer.

     Pat

On Wed, 29 Aug 2012 04:59:25 -0500, Dolph Mathews wrote
 > 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
 > > > 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@xxxxxxxxxxxxxxxxxxx
 > Unsubscribe : https://launchpad.net/~openstack
 > More help : https://help.launchpad.net/ListHelp
 >


----------------------------------------
Freehosting PIPNI - http://www.pipni.cz/