There's no Sun Cluster agent for the CIFS Service and we don't
have that on our roadmap at this time.

In response to an earlier comment, the CIFS service can act as
a DFS target but it can't provide DFS referrals yet.  We're
working on DFS referrals and hope to make that available later
this calendar year.

Alan

On 02/06/09 00:35, Ross wrote:
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 :)

_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss

Reply via email to