On 04/29/2014 11:59 AM, Timofey Koolin wrote:
From time to time old monitor can’t connect to new monitors.
For example upgrade from 0.66 to 0.67
http://ceph.com/docs/master/release-notes/#upgrading-from-v0-66
• There is monitor internal protocol change, which means that v0.67
ceph-mon daemons cannot talk to v0.66 or older daemons. We recommend upgrading
all monitors at once (or in relatively quick succession) to minimize the
possibility of downtime.
I has test cluster on the 0.66 version and monitor upgrade was failed.
I the situation update one by one don’t help me when I upgrade middle monitor
instance.
When you go from the major release to another one there is no problem.
Dumpling -> Emperor -> Firefly, etc.
That should all work without downtime.
On 04/28/2014 05:59 PM, Timofey Koolin wrote:
Is a setting for change the behavior to return read error instead of block read?
I think it is more reasonable behavior because it is similar to bad block on
HDD: it can’t be read.
Or may be a timeout some seconds, then return read error for the block and
other absented blocks in same image/PG.
Yes, you could do so in theory, but I wouldn't do that. Usually the VM itself
will start throwing errors when the drive doesn't respond.
Or is any method safe upgrade cluster without downtime.
Yes, you can upgrade a Ceph cluster without downtime. Just do a rolling upgrade.
Now if I will upgrade monitors and upgrade will fail on second (of three)
monitor - cluster will down. Becouse it will have
1 new monitor
1 down monitor
1 old monitor
You expect the upgrade to fail? Simply upgrade the monitors one by one within
~30 minutes and you should be fine.
Afterwards you do the same for all the OSDs. Restart the daemons one by one and
without downtime you can upgrade the cluster.
Old and mew monitor haven’t quorum.
Same for 5 monitors:
2 new monitors
1 down monitor
2 old monitors.
On 04/28/2014 02:35 PM, Timofey Koolin wrote:
What will happened if RBD lose all copied of data-block and I read the block?
The read to the object will block until a replica comes online to serve it.
Remember this with Ceph: "Consistency goes over availability"
Context:
I want use RDB as main storage with replication factor 1 and drbd for
replication on non rbd storage by client side.
For example:
Computer1:
1. connect rbd as /dev/rbd15
2. use rbd as disk for drbd
Computer2:
Use HDD for drbd-replication.
I want protect from break of ceph system (for example while upgrade ceph) and
long-distance replication.
Ceph wants to be consistent at all times. So copying over long distances with
high latency will be very slow.
_______________________________________________
ceph-users mailing list
[email protected]
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
--
Wido den Hollander
42on B.V.
Ceph trainer and consultant
Phone: +31 (0)20 700 9902
Skype: contact42on
_______________________________________________
ceph-users mailing list
[email protected]
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
_______________________________________________
ceph-users mailing list
[email protected]
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
--
Wido den Hollander
42on B.V.
Ceph trainer and consultant
Phone: +31 (0)20 700 9902
Skype: contact42on
_______________________________________________
ceph-users mailing list
[email protected]
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
_______________________________________________
ceph-users mailing list
[email protected]
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
--
Wido den Hollander
42on B.V.
Ceph trainer and consultant
Phone: +31 (0)20 700 9902
Skype: contact42on
_______________________________________________
ceph-users mailing list
[email protected]
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
