[Openstack] [designate]Strange behavior of Designate.

Endre Karlson endre.karlson at gmail.com
Fri Mar 13 11:58:23 UTC 2015


Hi!

Answer to question 1:
I think what is happening here is that you have a mirrored mysql so when
you go hit side a / b and turn off side a mysql the request can be routed
to the side a central which has no mysql access? Check logs on the
designate process to see if requests is hitting it.

Your 2nd question I think you should use haproxy on each node to do
healthchecks here to determine what node is up and simply have designate
connect to localhost via haproxy. We do this for our deployment already but
in a 3 node percona cluster, but it should work the same.

Also note that for Percona it's advised to use a 3 node cluster to avoid
splitbrains.

Btw, you can contact us @ # openstack-dns on the freenode network
Regards
Endre

2015-03-13 12:24 GMT+01:00 Nobumasa Yukutomi <yukutomi at m.ieice.org>:

> Hi all,
>
> I'm Nobumasa Yukutomi.  I'm working on Designate since last year.
>
> We are using Designate for '20141003' Git Hub repository of Icehouse.
>
> We have built Designate with mysql(Percona) cluster shown below.
>
>
>     designate.conf                  designate.conf
>       IP:xxx.xx.x.x                   IP:yyy.yy.y.y
>           A-side                          B-side
>   -----------------               -----------------
>   | designate-api |               | designate-api |
>   -----------------               -----------------
>           |                               |
>   -----------------    cluster    -----------------
>   |   rabbitMQ    |---------------|   rabbitMQ    |
>   -----------------               -----------------
>           |                               |
>   --------------------            --------------------
>   | designate-central |           | designate-central |
>   --------------------            --------------------
>           |                               |
>           |IP:xxx.xx.x.x                  |IP:yyy.yy.y.y
>   ------------------   cluster    ------------------
>   | mysql(Percona) |--------------| mysql(Percona) |
>   ------------------              ------------------
>           |                               |
>           |                               |
>   -----------------               -----------------
>   |   PowerDNS    |               |    PowerDNS    |
>   -----------------               -----------------
>
> Let's assume some situation that mysql cluster encounters some problem. So
> let's stop B-side mysql.
>
> The A-side mysql(active) itself continues running. But designate-api
> services of both sides stop working, even if the process of designate-api
> continues running on both sides.  User gets returned Error500(internal
> server error) from designate-api.
>
> Here are more details.
>
> 1. Listing domains
> For example, if a user access designate-api of A-side, designate-central
> accesses to both sides of mysql and the user experiences to succeed and
> fail to list domains every other time.
>
> 2. Listing records
> Also, listing records fails 100% in both sides when a user accesses to
> designate-api of either A-side or B-side.
>
> And here are my questions.
>
> Question 1
> In designate.conf of A-side, the destination of mysql is
> A-side IP: xxx.xx.xx
>
> In designate.conf of B-side, the destination to mysql is
> B-side IP: yyy.yy.yy
>
> But, for some reason, designate-central accesses to both IP addresses.
>
> I would like to know why this is happening.
>
> Question 2
> I would like to know how to change configuration to make designate-central
> to access "only" to active-mysql, not to inactive-mysql.
>
> Thank you in advance.
>
> Best regards,
>
> ---
> Nobumasa Yukutomi yukutomi at m.ieice.org
>
>
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20150313/34fcc4bd/attachment.html>


More information about the Openstack mailing list