Samba LVS PDC Cluster

PDC cluster

After we verify the Samba configuration and that the service is running, we try to authentify against the LDAP database through Samba. If the challenge successes, the Samba configuration can be duplicated on the other real server. We have only one parameter to change on our new real server, it the netbios name parameter to keep an individual naming for each of our servers. If you rely on DNS resolution or local hostname usage, you don’t even need to change this value.

Since we have configured two similar PDC with the same name and domain, we need to isolate them, to get them blind in the NetBIOS context. For that goal, some iptables rules can jail each of the PDCs. In that way they can coexist on the same network and provide the same service as they ignore each other presence.

Iptables jails

The only machine that should connect to the real servers is the director. The following rules, even if they are too broad, are designed to this goal. Theoretically, we could restrict the rules to hide PDC presence by forbidding only 139 and 445 TCP ports as well as 137 and 138 UDP ports between real servers.

DIRECTOR=192.168.0.254
LOCAL=192.168.0.1

# Default policy
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# Loopback rules: accept everything
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Rules definitions
iptables -N in
iptables -N out
iptables -A INPUT -i eth0 -j in
iptables -A OUTPUT -o eth0 -j out

# Blind config
# We accept all connections from the director
iptables -A in -s $DIRECTOR -j ACCEPT
iptables -A out -d $DIRECTOR -j ACCEPT

# We accept local connection on IP address
iptables -A in -s $LOCAL -j ACCEPT
iptables -A out -d $LOCAL -j ACCEPT

This firewall configuration must be deployed on both real servers to keep a mirror configuration. This kind of policy should be the most adaptive if we consider many Samba real servers, we only open allowed connections instead of forbidding a vertex of Samba server nodes. As an example, we can consider that we first rely on a single LDAP service located on ldap-server. To authorize all dialogs between Samba and LDAP, we need to allow some more flexibility adding those definitions to the previous declaration:

LDAP=192.168.0.10

# Samba/LDAP dialog
iptables -A in -p tcp -s $LDAP --sport 389 -j ACCEPT
iptables -A out -p tcp -d $LDAP --dport 389 -j ACCEPT

Packet routing

As we have now many real servers, we need to consider them on a dedicated sub-network that should be only accessible from the LVS director. With that point of view, we must force the reverse routing process through the director. That means the director is defined as a gateway for the real servers for each Samba servers.

So we have to be careful about route table definition. We must check and set it right with ip or route functions to be conform to the following description:

# route

Destination Gateway Genmask Indic Metric Ref Use Iface
192.168.0.0 * 255.255.255.0 U
default 192.168.0.254 0.0.0.0 UG 0 0 0 eth0

LVS Director

Once the real servers are well configured, jailed and routed, we have now to give the correct parameters to the LVS director. In order to realize this operation, we need a kernel that has IPVS capabilities. The administration tool via command line, ipvsadm is also required. Focus is given on the version of the patch and ipvsadm command that must be coherent the one for the other in order to work. A complete description of kernel patch and corresponding API is describe on LVS web site.

LVS rules are quite similar to iptables ones:

# Virtual interface
VIP=172.16.0.1

# Real servers interfaces
REAL1=192.168.0.1
REAL2=192.168.0.2

# Virtual service declaration
ipvsadm -A -t $VIP:445 -s rr
ipvsadm -A -t $VIP:139 -s rr
ipvsadm -A -u $VIP:137 -s rr
ipvsadm -A -u $VIP:138 -s rr

# Real servers assignation
ipvsadm -a -t $VIP:445 -r $REAL1:445 -m -w 1
ipvsadm -a -t $VIP:445 -r $REAL2:445 -m -w 1
ipvsadm -a -t $VIP:139 -r $REAL1:139 -m -w 1
ipvsadm -a -t $VIP:139 -r $REAL2:139 -m -w 1
ipvsadm -a -u $VIP:137 -r $REAL1:137 -m -w 1
ipvsadm -a -u $VIP:137 -r $REAL2:137 -m -w 1
ipvsadm -a -u $VIP:138 -r $REAL1:138 -m -w 1
ipvsadm -a -u $VIP:138 -r $REAL2:138 -m -w 1

Kernel options and routing

It is compulsory to activate the IP forwarding option in the kernel to have a correct routing scheme. The following options must be set in the file /etc/sysctl.conf for routing purpose and to avoid route redefinition:

net/ipv4/conf/all/ip_forward = 1
net/ipv4/conf/all/accept_redirects = 0
net/ipv4/conf/all/send_redirects = 0

Testing the architecture

Last but not least, we can now test our configuration.

As we need to connect to a computer named samba-server, an association must be set to map the virtual IP, which is the only access point to Samba server. This name resolution has to be defined in a DNS server or an external WINS service. For testing only, you can also put it temporarily in your /etc/hosts.

It is time to connect to the load balancing mechanism. A Samba request to access the share on one of the PDC servers must be done, with smbmount or smbclient:

smbmount //samba-server/test -o username=<user-id>

With an audit tool we can monitor the flow through the director and on each of the real servers we can run smbstatus command to check the open shares are alive connections. When we retry the previous command, then we can point out that the connection is routed to the second real servers.

Google+