TL;DR

  • Poolを更新するとPoolを利用している全てのZoneのSerialが更新される
  • Serialが更新されるとNotifyが飛びZone転送が行なわれて全てのセカンダリーにデータだ同期される
  • NSの変更などを個別に行いたい場合にはPoolの変更などを1 Zoneずつ実施する必要がある
  • ただ、DesignateにPoolを操作するAPIはないので、作るかDB操作を頑張るしかない

ここから先はCode Reading log

Pool操作時のDesignateの動作

DesingateはZone作成時にSOAとNSレコードを作成する

関数の呼び出しの長れ create_zoen → _create_zone → _create_zone_in_storage _create_zone_in_storage の中でNSレコードの作成と、SOAレコードの作成が行われる

SOAレコードはZoneの情報とPoolのNSの情報から作成される。 _create_soa → _build_soa_record

NNAMEはPoolのNSの値から取得される。

SOAのserialは、ZoneがUpdateされたタイミングで呼び出される。

increment_zone_serial → _update_soa

SOAの値を最新の値でbuildする。 MNAMEを更新したい場合には、SOAを触らなくて良い。

NSはPoolをUpdateしたら全体で更新される。

なので、個別のZone毎にUpdateといった処理は出来ない。
Poolを更新した瞬間にそのPoolを利用している全てのZoneがUpdateしてしまうので、結構、危険な操作になる。

PoolをUpdateしたら追加するNSと削除するNSの管理が行われて、Zone毎に順番に適用される。 この時にに、 _update_zone_in_storage が呼ばれるのでSerialがUpdateされ、SOAも更新される。 なので、Poolの更新をするとそのPoolを利用している全てのZoneでZone転送が行なわれる。

designate-manage pool updateのタイミングでpoolのupdateは呼ばれるのでデプロイのタイミングで呼ばれる。

なのでまとめると、Poolを更新すると、全てのZoneのNSやSOAが更新される事になる。

Poolの割り当て

Poolの割り当てはDesignateのPool schedulerによって行なわれる。 何も設定していないと、Default pool schedulerが利用される。

config中にfilterが指定してあれば、そのPool Scheudler Filterを利用出来る。

[service:central]
scheduler_filters = attribute, pool_id_attribute, fallback

attribute filterが一般的で、Zoneのattributesに応じてpoolの選択をしてくれる。 Poolを複数作ってチームだとかテナントをattributesで割り当てるのが一般的かと思う。

そして、調べた限り、1度設定したPoolを操作する、APIは無さそう。