Open Stack

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 <ayoung at redhat.com> 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:ayoung at redhat.com <ayoung at redhat.com>]
> *Sent:* Tuesday, March 17, 2015 10:00 PM
> *To:* openstack-dev at lists.openstack.org
> *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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?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: huangzhipeng at huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipengh at uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150319/64dab938/attachment.html>