qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Changlong Xie <xiecl.fnst@cn.fujitsu.com>,
	zhanghailiang <zhang.zhanghailiang@huawei.com>,
	Wen Congyang <wency@cn.fujitsu.com>
Cc: Simon Kollberg <dv11skg@cs.umu.se>, Luis Tomas <luis@cs.umu.se>,
	qemu devel <qemu-devel@nongnu.org>,
	qemu block <qemu-block@nongnu.org>, Abel Souza <abel@cs.umu.se>
Subject: [Qemu-devel] COLO: how to flip a secondary to a primary?
Date: Fri, 22 Jan 2016 19:35:35 +0000	[thread overview]
Message-ID: <20160122193534.GF2482@work-vm> (raw)

Hi,
  I've been looking at what's needed to add a new secondary after
a primary failed; from the block side it doesn't look as hard
as I'd expected, perhaps you can tell me if I'm missing something!

The normal primary setup is:

   quorum
      Real disk
      nbd client

The normal secondary setup is:
   replication
      active-disk
      hidden-disk
      Real-disk

With a couple of minor code hacks; I changed the secondary to be:

   quorum
      replication
        active-disk
        hidden-disk
        Real-disk
      dummy-disk

and then after the primary fails, I start a new secondary
on another host and then on the old secondary do:

  nbd_server_stop
  stop
  x_block_change top-quorum -d children.0         # deletes use of real disk, leaves dummy
  drive_del active-disk0
  x_block_change top-quorum -a node-real-disk
  x_block_change top-quorum -d children.1         # Seems to have deleted the dummy?!, the disk is now child 0
  drive_add buddy driver=replication,mode=primary,file.driver=nbd,file.host=ibpair,file.port=8889,file.export=colo-disk0,node-name=nbd-client,if=none,cache=none
  x_block_change top-quorum -a nbd-client
  c
  migrate_set_capability x-colo on
  migrate -d -b tcp:ibpair:8888

and I think that means what was the secondary, has the same disk
structure as a normal primary.
That's not quite happy yet, and I've not figured out why - but the
order/structure of the block devices looks right?

Notes:
   a) The dummy serves two purposes, 1) it works around the segfault
      I reported in the other mail, 2) when I delete the real disk in the
      first x_block_change it means the quorum still has 1 disk so doesn't
      get upset.
   b) I had to remove the restriction in quorum_start_replication
      on which mode it would run in. 
   c) I'm not really sure everything knows it's in secondary mode yet, and
      I'm not convinced whether the replication is doing the right thing.
   d) The migrate -d -b   eventually fails on the destination, not worked out why
      yet.
   e) Adding/deleting children on quorum is hard having to use the children.0/1
      notation when you've added children using node names - it's worrying
      which number is which; is there a way to give them a name?
   f) I've not thought about the colo-proxy that much yet - I guess that
      existing connections need to keep their sequence number offset but
      new connections made by what is now the primary dont need to do anything
      special.

Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

             reply	other threads:[~2016-01-22 19:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-22 19:35 Dr. David Alan Gilbert [this message]
2016-01-25  1:32 ` [Qemu-devel] COLO: how to flip a secondary to a primary? Wen Congyang
2016-01-25  2:11   ` Li Zhijian
2016-01-25 20:20     ` Dr. David Alan Gilbert
2016-01-26  1:16       ` Li Zhijian
2016-01-25 18:59   ` Dr. David Alan Gilbert
2016-01-26  1:06     ` Wen Congyang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160122193534.GF2482@work-vm \
    --to=dgilbert@redhat.com \
    --cc=abel@cs.umu.se \
    --cc=dv11skg@cs.umu.se \
    --cc=luis@cs.umu.se \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=wency@cn.fujitsu.com \
    --cc=xiecl.fnst@cn.fujitsu.com \
    --cc=zhang.zhanghailiang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).