Miles Nordin wrote:
"lz" == Len Zaifman <leona...@sickkids.ca> writes:

    lz> So I now have 2 disk paths and two network paths as opposed to
    lz> only one in the 7310 cluster.

<confused>

You're configuring all your failover on the client, so the HA stuff is
stateless wrt the server?  sounds like the smart way since you control
both ends.  The entirely-server-side HA makes more sense when you
cannot control the clients because they are entee usars.

    lz> Under these circumstances what advantage would a 7310 cluster
    lz> over 2 X4540s backing each other up and splitting the load?

remember fishworks does not include any source code nor run the
standard opensolaris builds, both of which could be a big problem if
you are working with IB, RDMA, and eventually Lustre.  You may get
access to certain fancy/flakey stuff around those protocols a year
sooner by sticking to the trunk builds.  Furthermore by not letting
them take the source away you get the ability to backport your own
fixes, if you get really aggressive.

Having a cluster where one can give up the redundancy for a moment and
turn one of the boxes into ``development'' is exactly what I'd want if
I were betting my future on bleeding edge stuff like HOL-blocking
fabrics, RDMA, and zpool-backed Lustre.
It also lets you copy your whole dataset with rsync so you don't get
painted into a corner, ex trying to downgrade a zpool version.

I'd still get the 7310 hardware.

Worst case scenario is that you can blow away the AmberRoad software load, and install OpenSolaris/Solaris. The hardware is a standard X4140 and J4200.

Note, that if you do that, well, you can't re-load A-R without a support contract.


--
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to