similar to: ctdb failover interrupts Windows file copy

Hi everyone, I'm setting up a clustered Samba+CTDB in front of CephFS and am running into an issue during failover. For the most part everything seems to work: the IP moves quickly, smbd is started on the right node, etc, but if there is an IO load from a client during failover (e.g., copying a big directory full of files in File Explorer), it pauses for a couple of seconds and then pops up

On Sat, Aug 8, 2020 at 2:52 AM Martin Schwenke <martin at meltin.net> wrote: > Hi Bob, > > On Thu, 6 Aug 2020 06:55:31 -0400, Robert Buck <robert.buck at som.com> > wrote: > > > And so we've been rereading the doc on the public addresses file. So it > may > > be we have gravely misunderstood the *public_addresses* file, we never > read > >

On Thu, 16 Feb 2023 17:30:37 +0000, Ulrich Sibiller <ulrich.sibiller at atos.net> wrote: > Martin Schwenke schrieb am 15.02.2023 23:23: > > OK, this part looks kind-of good. It would be interesting to know how > > long the entire failover process is taking. > > What exactly would you define as the begin and end of the failover? From "Takeover run

Very helpful. Thank you, Martin. I'd like to share the information below with you and solicit your fine feedback :-) I provide additional detail in case there is something else you feel strongly we should consider. We made some changes last night, let me share those with you. The error that is repeating itself and causing these failures is: Takeover run starting RELEASE_IP 10.200.1.230

Hi there, I am looking into using CTDB between a PDC and a BDC. I assume this is possible! However I have a few questions: 1: Do I have to use tdb2 as an Idmap backend? Can I not stay with ldap? (from the CTDB docs: A clustered Samba install must set some specific configuration parameters clustering = yes idmap backend = tdb2 private dir = /a/directory/on/your/cluster/filesystem It is

Hi to all, I'm having a CTDB-Cluster with two nodes (both Ubuntu wit Sernet-packages 4.17.4). Now I want to replace one of the nodes. The first step was to bring a new node to the CTDB-Cluster. This time a Debian 11 but with the same sernet-packages (4.17.4). Adding the new node to /etc/ctdb/nodes at the end of the list. And the virtual IP to /etc/ctdb/public_addresses, also at the end

Hello, we are using ctdb 4.15.5 on RHEL8 (Kernel 4.18.0-372.32.1.el8_6.x86_64) to provide NFS v3 (via tcp) to RHEL7/8 clients. Whenever an ip takeover happens most clients report something like this: [Mon Feb 13 12:21:22 2023] nfs: server x.x.253.252 not responding, still trying [Mon Feb 13 12:21:28 2023] nfs: server x.x.253.252 not responding, still trying [Mon Feb 13 12:22:31 2023] nfs: server

Hello, at this time i want to install a CTDB Cluster with SAMBA 4.7.7 from SOURCE! I compiled samba as follow: |./configure| |--with-cluster-support ||--with-shared-modules=idmap_rid,idmap_tdb2,idmap_ad| The whole SAMBA enviroment is located in /usr/local/samba/. CTDB is located in /usr/local/samba/etc/ctdb. I guess right that the correct path of ctdbd.conf (node file, public address file

Could I impose upon someone to provide some guidance? Some hint? Thank you Is a shared file system actually required? If etcd is used to manage the global recovery lock, is there any need at that point for a shared file system? In other words, are there samba or CTDB files (state) that must be on a shared file system, or can each clustered host simply have these files locally? What must be

Hi Max, On Fri, 4 Oct 2019 14:01:22 +0000, Max DiOrio <Max.DiOrio at ieeeglobalspec.com> wrote: > Looks like this is the actual error: > > 2019/10/04 09:51:29.174870 ctdbd[17244]: Recovery has started > 2019/10/04 09:51:29.174982 ctdbd[17244]: ../ctdb/server/ctdb_server.c:188 ctdb request 2147483554 of type 8 length 48 from node 1 to 0 > 2019/10/04 09:51:29.175021

Martin Schwenke schrieb am 15.02.2023 23:23: > Hi Uli, > > [Sorry for slow response, life is busy...] Thanks for answering anyway! > On Mon, 13 Feb 2023 15:06:26 +0000, Ulrich Sibiller via samba > OK, this part looks kind-of good. It would be interesting to know how > long the entire failover process is taking. What exactly would you define as the begin and end of the

Hi everybody, I just updated my ctdb node from Samba version 4.9.4-SerNet-Debian-11.stretch to Samba version 4.9.8-SerNet-Debian-13.stretch. After restarting the sernet-samba-ctdbd service the node doesn't come back and remains in state "UNHEALTHY". I can find that in the syslog: May 16 11:25:40 ctdb-lbn1 ctdb-eventd[13184]: 50.samba: samba not listening on TCP port 445 May 16

Hi Uli, [Sorry for slow response, life is busy...] On Mon, 13 Feb 2023 15:06:26 +0000, Ulrich Sibiller via samba <samba at lists.samba.org> wrote: > we are using ctdb 4.15.5 on RHEL8 (Kernel > 4.18.0-372.32.1.el8_6.x86_64) to provide NFS v3 (via tcp) to RHEL7/8 > clients. Whenever an ip takeover happens most clients report > something like this: > [Mon Feb 13 12:21:22

I am attempting to enable IPv6 on our CTDB setup. I have placed the IPv6 address in the public_addresses file with the correct prefix. The addresses never come up and I recieve these messages in the log 2012/06/28 10:54:43.313227 [ 1820]: Async operation failed with ret=0 res=1 opcode=0 2012/06/28 10:54:43.313918 [ 1820]: Async operation failed with ret=0 res=1 opcode=0 2012/06/28

drbd ctdb ocfs2 Hi Everything seems OK apart from the IP takeover. public_addresses 192.168.1.80/24 enp0s3 192.168.1.81/24 enp0s3 ctdb status Number of nodes:2 pnn:0 192.168.1.10 PARTIALLYONLINE pnn:1 192.168.1.11 PARTIALLYONLINE (THIS NODE) Generation:2090727463 Size:2 hash:0 lmaster:0 hash:1 lmaster:1 Recovery mode:NORMAL (0) Recovery master:1 but we are getting: 2014/07/11

Hi All, My site has two separate clustered Samba instances (managed by two independent CTDB instances) running over GPFS. In the last couple of weeks, we have seen a recurring issue that causes the `smbd` process in *one* of these instances to become unresponsive (as seen by CTDB), which results in flapping of CTDB and multiple IP takeover runs. The symptoms that we observe are: 1) Samba

hm, I stand correct on the problem solved statement below. Ip addresses are simply not cooperating on the 2nd node. root at vault1:~# ctdb ip Public IPs on node 0 192.168.120.90 0 192.168.120.91 0 192.168.120.92 0 192.168.120.93 0 root at vault2:/service/ctdb/log/main# ctdb ip Public IPs on node 1 192.168.120.90 0 192.168.120.91 0 192.168.120.92 0 192.168.120.93 0 root at

My ctdb version is 4.17.7 Hello, everyone. My ctdb cluster configuration is correct and the cluster is healthy before operation. My cluster has three nodes, namely host-192-168-34-164, host-192-168-34-165, and host-192-168-34-166. And the node host-192-168-34-164 is the leader before operation. I conducted network oscillation testing on node host-192-168-34-164?I down the interface of private

Hi all We did some failover/failback tests on 2 nodes��A and B�� with architecture 'glusterfs + ctdb(public address) + nfs-ganesha'�� 1st: During write, unplug the network cable of serving node A ->NFS Client took a few seconds to recover to conitinue writing. After some minutes, plug the network cable of serving node A ->NFS Client also took a few seconds to recover

I'm currently hacking on CTDB's IP takeover/failover code. For Samba 4.6, I would like to rationalise the IP takeover-related tunable parameters. I would like to know if there are any users who set the values of these tunables to non-default values. The tunables in question are: DisableIPFailover Default: 0 When set to non-zero, ctdb will not perform failover or