BP is at https://blueprints.launchpad.net/keystone/+spec/keystone-ha-multisite , spec will come later :)
On Thu, Mar 19, 2015 at 11:21 AM, Adam Young <[email protected]> wrote: > On 03/18/2015 08:59 PM, joehuang wrote: > > [Joe]: For reliability purpose, I suggest that the keystone client > should provide a fail-safe design: primary KeyStone server, the second > KeyStone server (or even the third KeySont server) . If the primary > KeyStone server is out of service, then the KeyStone client will try the > second KeyStone server. Different KeyStone client may be configured with > different primary KeyStone server and the second KeyStone server. > > > [Adam]: Makes sense, but that can be handled outside of Keystone using HA > and Heartbear and awhole slew of technologies. Each Keystone server can > validate each other's tokens. > > For cross-site KeyStone HA, the backend of HA can leverage MySQL Galera > cluster for multisite database synchronous replication to provide high > availability, but for the KeyStone front-end the API server, it’s web > service and accessed through the endpoint address ( name, or domain name, > or ip address ) , like http://.... or ip address. > > > > AFAIK, the HA for web service will usually be done through DNS based > geo-load balancer in multi-site scenario. The shortcoming for this HA is > that the fault recovery ( forward request to the health web service) will > take longer time, it's up to the configuration in the DNS system. The other > way is to put a load balancer like LVS ahead of KeyStone web services in > multi-site. Then either the LVS is put in one site(so that KeyStone client > only configured with one IP address based endpoint item, but LVS cross-site > HA is lack), or in multisite site, and register the multi-LVS’s IP to the > DNS or Name server(so that KeyStone client only configured with one Domain > name or name based endpoint item, same issue just mentioned). > > > > Therefore, I still think that keystone client with a fail-safe design( > primary KeyStone server, the second KeyStone server ) will be a “very high > gain but low invest” multisite high availability solution. Just like MySQL > itself, we know there is some outbound high availability solution (for > example, PaceMaker+ColoSync+DRDB), but also there is Galera like inbound > cluster ware. > > > Write it up as a full spec, and we will discuss at the summit. > > > > Best Regards > > Chaoyi Huang ( Joe Huang ) > > > > > > *From:* Adam Young [mailto:[email protected] <[email protected]>] > *Sent:* Tuesday, March 17, 2015 10:00 PM > *To:* [email protected] > *Subject:* Re: [openstack-dev] [opnfv-tech-discuss] [Keystone][Multisite] > Huge token size > > > > On 03/17/2015 02:51 AM, joehuang wrote: > > It’s not reality to deploy KeyStone service ( including backend store ) in > each site if the number, for example, is more than 10. The reason is that > the stored data including data related to revocation need to be replicated > to all sites in synchronization manner. Otherwise, the API server might > attempt to use the token before it's able to be validated in the target > site. > > > Replicating revocati9on data across 10 sites will be tricky, but far > better than replicating all of the token data. Revocations should be > relatively rare. > > > > When Fernet token is used in multisite scenario, each API request will ask > for token validation from KeyStone. The cloud will be out of service if > KeyStone stop working, therefore KeyStone service need to run in several > sites. > > > There will be multiple Keystone servers, so each should talk to their > local instance. > > > > For reliability purpose, I suggest that the keystone client should provide > a fail-safe design: primary KeyStone server, the second KeyStone server (or > even the third KeySont server) . If the primary KeyStone server is out of > service, then the KeyStone client will try the second KeyStone server. > Different KeyStone client may be configured with different primary KeyStone > server and the second KeyStone server. > > > Makes sense, but that can be handled outside of Keystone using HA and > Heartbear and awhole slew of technologies. Each Keystone server can > validate each other's tokens. > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > [email protected]?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Prooduct Line Huawei Technologies Co,. Ltd Email: [email protected] Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: [email protected] Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
