On 2016-11-24 10:41, Toni Tschampke wrote:
We recently did an upgrade for our cluster nodes from Wheezy to Jessie.
IIRC it's the MIT CS joke that they have clusters whose uptime goes way
back past the manufacturing date of any/every piece of hardware they're
running on. They aren't linux-ha
We recently did an upgrade for our cluster nodes from Wheezy to Jessie.
To reduce possible problems with drbd we first updated the kernel to the
backport version, which is the same as the stable kernel in Jessie.
After that drbd versions matched while one node was on whezzy and one
node already
On Tue, Nov 22, 2016 at 05:22:21PM +, Jason A Ramsey wrote:
> I’ve done the opposite:
>
> lvm on top of drbd -> iscsi lun
>
> but I’m not trying to resize anything. I just want to patch the OS
> of the nodes and reboot them in sequence without breaking things (and,
> preferably, without
I’ve done the opposite:
lvm on top of drbd -> iscsi lun
but I’m not trying to resize anything. I just want to patch the OS of the nodes
and reboot them in sequence without breaking things (and, preferably, without
taking the cluster offline).
--
[ jR ]
there is no path to greatness;
I been using this mode: iscsi_disks -> lvm volume ->
drbd_on_top_of_lvm -> filesystem
resize: add_one_iscsi_device_to_every_cluster_node_first ->
now_add_device_the_volume_group_on_every_cluster_node ->
now_resize_the_volume_on_every_cluster_node : now you have every
cluster with the same logical
On 2016-11-22 10:35, Jason A Ramsey wrote:
Can anyone recommend a bulletproof process for OS patching a pacemaker
cluster that manages a drbd mirror (with LVM on top of the drbd and luns
defined for an iscsi target cluster if that matters)? Any time I’ve
tried to mess with the cluster, it seems
Can anyone recommend a bulletproof process for OS patching a pacemaker cluster
that manages a drbd mirror (with LVM on top of the drbd and luns defined for an
iscsi target cluster if that matters)? Any time I’ve tried to mess with the
cluster, it seems like I manage to corrupt my drbd
