Yup, that sounds good, and I didn't realise you had two x4500's. With a pair of them, it's possible to create a pretty robust solution if you're happy mirroring data between them?
Now, I'm not sure what the best solution would be (I'm not hugely experienced in solaris), but I can suggest three options for you to look into: 1. Scripted failover Despite being a manual failover, it might be the best solution, and possibly the most robust). Have one server as your live server, get automatic snapshots working, and have a regular send/receive (every 30 mins?) to the backup server. Give each server a unique IP to boot with, but reserve a third IP to be used as the live IP. Have a startup script on the main server that checks for existence of the live IP, and if it doesn't already exist, sets the IP and starts the sharing services. On the backup server, have a manual script that can be used for DR that sets the backup server's IP and brings the backup pool and shares online. 2. Sun Cluster with Samba I didn't like Samba myself (CIFS has a lot more features, and way better permissions support), but there's no denying it does the job. With a pair of x4500's, it's possible to set them up like this: - Create a pool on each server, share it out over iscsi - Install Sun Cluster on each and create a cluster (you might need to create a new zone to do this on the same servers) - Configure ZFS in the cluster with ha-storage+ - Import your two iscsi luns into your clustered ZFS, and mirror them - Configure a shared hostname, IP address, and Samba You now have a redundant system with all data mirrored live between two servers, and automatic failover between them for all your shares. I've tested this on a simple setup and the failover was fast enough that windows clients weren't even aware it happened. You'd need to test how it goes with large numbers of filesystems though. Sun Cluster really is a piece of cake to setup if you have a bit of time to learn it. However, this configuration does have one *major* limitation: WARNING: iSCSI and ZFS have a nasty bug that means the timeout for any iSCSI problem is 3 minutes. That means your pool will hang for 3 full minutes if either server goes offline. It will recover automatically after that, but 3 minutes is long enough for windows clients to timeout their network connections. There is (hopefully) work being done to address this, and if you felt like it, you could compile a custom iscsi driver with a faster timeout by changing one value in iscsi.h. 3. Sun Cluster with CIFS I don't think there's a CIFS cluster service available yet, but in the meantime you could create the cluster above to manage ZFS, IP and hostname failover, and just have your own script to manually enable CIFS as needed. And finally: All of these options are assuming a single live server, and I don't know how much performance gain you would get from splitting the services between both servers (since I'm suggesting a mirrored configuration so both servers are experiencing load anyway). However, if you have a fast enough interconnect between the servers you could split your services so each server handled half of the load. If nothing else it would reduce the failover time as you would have half the number of filesystems to mount. If you were using option 2 or 3, I'd be tempted to have a go at this by: - Create 2 iscsi luns on each server, using half the disks for each - Create 2 zones on each server - You can now create two separate clusters, each of which can support half of your users. I think you can even automatically load balance with Sun Cluster, so it will automatically keep the services balanced across both servers where possible, but that's not something I've ever looked into myself I'm afraid. Potentially that's quite a nice solution, using just the kit you already have. For us the 3 minute timeout was a deal breaker, but if you're looking at a downtime of an hour now, 3 minutes (plus mount time) with automatic recovery might be worth having :) -- This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
