[Openstack] [designate]Strange behavior of Designate.

Nobumasa Yukutomi yukutomi at m.ieice.org
Fri Mar 13 12:33:28 UTC 2015


Hi Endre,

Thank you very much for quick response.

I will check the mysql status.(if it's mirrored or not.)

Also, I will consider to use haproxy.

Best regards,
Nobumasa


2015年 3月 13日(金)8:58 pm に Endre Karlson さんは書きました:
> 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
>>
>>
>


---
Nobumasa Yukutomi yukutomi at m.ieice.org
Cloud   ID:         = 92 21 37 42-0e f1-43 10 - 96 dd-c0 bf 33 9f ca 05
PGP6Key fingerprint = DE61 9B71 43E7 E999 BDE2 11DE 7187 B902 239E 74F7
Op  SSL fingerprint = 9F 66 5A ED B3 1F BE 1C   02 99 F0 E3 E4 CE 84 74
Op  SSL thumb-mark  = 62F1 1323 B193 B686 5E47 E5FE DF11 B9DA 2152 8A99
SSLprxy fingerprint = A0 04 CA 35 E6 84 14 7D   99 42 74 1A D5 E4 7A 26
SSLprxy thumb-mark  = 1315 9674 E866 55BA 9EC8 07AF A59A 8E75 C915 6CB0






More information about the Openstack mailing list