I am currently running my samba servers with High availability using Heartbeat (http://www.linux-ha.org/) and drbd (http://www.drbd.org/).
drbd is a network block device (pretty much raid 1 over ethernet).
So I have 2 identical systems with two gigabit nics. They use a dedicated gigabit link to sync the file system through drbd (no rsync needed). Then whenever the master fails, the slave takes over and the switch is almost un-noticeable to the end user (it takes 20 seconds tops).
My servers also run nfs4 for linux shares. They each use 5 SCSI drives configured in RAID5.
I use RHEL4 with stock rpms and use the ldap backend.
I decided to keep smb.conf separate on each server and sync it manually, but definitely moved the lock directory to my drbd device.
So my drbd device gets mounted in /export and then I created
/export/home (for homedirs) /export/etc (all /etc information shared by the servers) /export/var (all /var information shared by the servers).
On smb.conf I added: lock directory = /export/var/cache/samba (both servers will use the same information, but only one can access it at a time. My netlogon share is also in /export/etc/samba/netlogon.
I could have modified /etc/init.d/smb to look for smb.conf in the shared device (/export/etc/samba), but decided to keep smb.conf separate and copy that file over to the slave whenever I made a change.
Diego
Quoting Nathan Vidican <[EMAIL PROTECTED]>:
We're running a similar setup here actually, so a few notes that may be of assistance to you are as follows:
#1 - RAID 0 + RAID 1 is poor for performance, if you want striping and mirroring together you should probably be looking to some sort of parity striping mode like RAID 5. We're using 3Ware Escalade 9000 series controllers to do just that now with WDC 250GB Raid-Edition Serial ATA drives now, and have been for quite some time. Performance is beyond our expectations and reliability has been key.
#2 - Quit copying /etc/passwd, group, etc! Yuck... Try looking into pam_ldap, nss_ldap, and samba/ldap configuration. OpenLDAP (free, open sourced LDAP server), has replication services built right in, and can store your users, passwords, mappings, and much more with full failover capability. We're running FreeBSD/64bit, (on AMD Opteron machines), using a primary/slave LDAP configuration wherein data changes are replicated automagically using 'slurpd' - it was quite easy to setup and all the necessary documentation exists on http://www.openldap.org/ - all of this stuff comes 'standard' out of the box in the FreeBSD ports collection too :)
#3 - Along with your new LDAP-based database of users, passwords, groups, mappings, etc, you might want to take a look at using some nice graphical user management system - just simplify life for yourself if you're not overly familiar with modifying entries in an LDAP tree - try LAM (http://lam.sf.net/) - it's been great and I'm usuing it at several installations now.
#4 - pam_ldap & nss_ldap (mentioned above) - will allow you to use the same account information stored in the ldap database for BOTH unix and Windows worlds - signle sign on is key :)
#5 - Setup samba for primary domain control, and setup the second machine for secondary (BDC) services. We maintain the same shares on both machines, and two dirs for login scripts; should the primary server fail for some reason, the login scripts are over-written by the second set which maps all the same drive letters over to the second server - not entirely transparent mind you, but worst-case scenario if the main server goes out, is that users logoff and back on and continue where they left off from half hour ago (data replicated using rsync as well).
#6 - last advantage to this setup, involves a bit more complexity, but you can device the load/shares out amongst the two servers and replicate data/login scripts in both directions (as we're doing) - so your 'backup' server is actually primary for some shares and vice-versa to the main server, effectively distributing the load.
#7 - split your smb.conf files; keep one for PDC, one for BDC, and one for all the shares that they replicate/share for each other - that way you can rsync shares configuration file without changing the whole smb.conf file (just use an 'include' line to include the shares from the main smb.conf's).
#8 - use CUPS; CUPS will replicate the printers across both servers and allow for fail-over design as well... Still working on how 'transparent' we can make this - so I won't feed you any details or bull about cause' I really havn't tested it well yet.
All-in-all, not a pure 'High Availability' solution; but given a complete catastrophic failure of our main/primary server, we can be back up and running to within a half hour's data in less than a minute if need be - fairly impressive, and definetly noteworthy.
Lot of food for thought, know this stuff can be overwhelming... Might send an email back to the list with further details after you do some reading; ie: what O/S you're using, LDAP/etc questions etc... Trust me, after having done three of these setups now myself it's worth the effort. Good place to start is the Samba Domain Control How-To, (which DOES explain LDAP+samba+nss_ldap integration and provide example configuration files).
-- Nathan Vidican [EMAIL PROTECTED] Windsor Match Plate & Tool Ltd. http://www.wmptl.com/
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richmond Dyes Sent: Thursday, April 28, 2005 8:17 AM To: [email protected] Subject: [Samba] Mirrored samba servers.
I have a customer that is using 250 gig drives for his business data. I have been using rsync to keep mirror copies of his data on a second machine. In the last 3 months I have lost 2 of four drives, the last one being the system drive. I have been doing a manual switchover. Each time rsync runs, I copy my samba conf files, passwd, shadow and group files from etc. Has anyone setup a HA configuration for samba servers on separate machines. If so, where can I get information for this kind of setup?
-- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
-- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
-- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
