



Choosing Interconnects for Grid Databases? 31
cybrthng asks: "With all of the choices from Gig-E, 10 Gig-E, SCI/Infiniband and other connections for grid database applications, which one is actually worth the money and which ones are overkill or under performing? In a Real Application Cluster (RAC), latency can be an issue with cached memory and latches going over the interconnect. I don't want to recommend an architecture that doesn't achieve desired results, but on the flipside, I don't necessarily want overkill. Sun had recommended SCI, Oracle has said Gig-E and other vendors have said 10 Gig-E. Seems sales commissions drive many of what people recommend, so I'm interested in any real world experience you may have. Obviously, Gig-E is more affordable from a hardware perspective but does this come at a cost of application availability and performance to the end users? What has been your success or failures of grid interconnects?"
Re:If you have the money..... (Score:2, Offtopic)
So, being an optimist, I choose to see the glass as 0.1% full. This means if we get a thousand responses,it's worth a shot.
Re:If you have the money..... (Score:1, Offtopic)
Re:If you have the money..... (Score:2)
And yes
mod parent up (Score:2)
CC could have worded it more nicely, but his underlying message is spot-on. If you don't have the necessary expertise in-house, hiring a professional is faster and less expensive than growing the expertise yourself, and you'll probably end up with a better-running system.
-- TTK
Re:mod parent up (Score:2)
Since you're one of the second type of responder, do you care to say what you think an acceptable topic for Ask Slashdot would be? Obviously, asking about highly technical enterprise topics is verbotten, since
Re:mod parent up (Score:2)
Since you're one of the second type of responder
Oh, am I now? Funny, before I made the post to which you replied, I made this other post first [slashdot.org], because I thought I didn't emphasize this alternative enough there.
You're off-base, though, in claiming that hiring a professional network engineer would cost more money than developing the necessary expertise in-house. The time and resources it takes to learn how to do it yourself will cost your business more in the long run. If it's a labor of love, tho
Re:mod parent up (Score:2)
Here's my take:
The OP never said anything useful about price and performance constraints,
scaling requirements, software constraints, etc.
1) connect them all to a fast switch using commodity hardware, OTS software.
- cheap, cheap, cheap, works now
- probably good enough
need faster?
2) connect them all to each other using commodity hardware, OTS software.
- cheap, will work once the wires are all connected
Re:mod parent up (Score:2)
Your options assume that your developing the grid as a proprietary system, which we are not.
We are looking at using Sun 490's, Solaris 10, Sun Cluster 3.1 and Oracle 10g RDBMS. All of which everything from GigE to SCI/Infiniband is supported on and all of which shareholders would highly approve of a
Gigabit Ethernet (Score:1, Informative)
Gig-E (Score:5, Informative)
Re:Gig-E (Score:2)
So they don't necessarily practice what they preach - however i guess they assume the scale of there customers is smaller. (which kind of defeats the purpose of scoping a GRID environment). RAC gig-e - "GRID" conceptually ????
GigE (Score:5, Informative)
Make sure you tune your cluster subnet, adjusting window sizes, utilize jumbo frames, etc. Just the jump from 1500 MTU to jumbo frames made a HUUUUGE difference in performance, so spending a couple of days just tuning the network will make all the difference in the world.
Re:GigE (Score:2)
Our new platform will be the enterprise ERP suite and CRM with hundreds of concurrent users and live transactions running in everything from order entry, product configurator to processing invoices, taking support requests and all.
Re:GigE (Score:1)
There are many people posting here who are completely confusing what the word "cluster" means for this particular question.
This article is about APPLICATION CLUSTERING (in this case a very specific relational database) and you are answering the question with information that is generalized to a COMPUTE FARM or a Linux cluster built and optimized for high performance computing.
Broadly speaking the word "cluster" means different t
This is really application-specific (Score:5, Informative)
In my own experience, fully switched Gig-E was sufficient for operating a high performance distributed database. The bottlenecks were at the level of tuning the filesystem and hard drive parameters, and memory pool sizes. But that was also a few years ago, when the machines were a lot less powerful than they are now (though hard drives have not improved their performance by all that much).
Today, high-end machines have no trouble maxing out a single Gig-E interface, but unless you go with PCI-Express or similarly appropriate IO bus, they might not be able to take advantage of more. That caveat aside, if Gig-E proved insufficient for my application today, I would add one or two more Gig-E interfaces to each node. There is software (for Linux at least; not sure about other OS's) which allows for efficient load-balancing between multiple network interfaces. 10Gig-E is not really appropriate, imo, for node interconnect, because it needs to transmit very large packets to perform well. A good message-passing interface will cram multiple messages into each packet to maximize performance (for some definition of performance -- throughput vs latency), but as packet size increases you'll run into latency and scheduling issues. 10Gig-E is more appropriate for connecting Gig-E switches within a cluster.
The clincher, though, is that this all depends on the details of your application. One user has already suggested you hire a professional network engineer to analyze your problem and come up with an appropriate solution. Without knowing more, it's quite possible that single Gig-E is best for you, or 10Gig-E, or Infiniband.
If you're going to be frugal, or if you want to develop expertise in-house, then an alternative is to build a small network (say, eight machines) with single channel Gig-E, set up your software, and stress-test the hell out of it while looking for bottlenecks. After some parameter-tweaking it should be pretty obvious to you where your bottlenecks lie, and you can decide where to go from there. After experimentally settling on an interconnect, and having gotten some insights into the problem, you can build your "real" network of a hundred or however many machines. As you scale up, new problems will reveal themselves, so incorporating nodes a hundred at a time with stress-testing in between is probably a good idea.
-- TTK
Re:This is really application-specific (Score:2)
It comes down to a latency issue and figuring out how that latency impacts real world use and the answer comes down to how much money you want to throw at that problem.
My question is that latency that much for the interconnects that cutting it by high speed interconnects isn't lost in all of the other overheads in the system (such as local
Re:This is really application-specific (Score:2)
Re:This is really application-specific (Score:2)
Re:This is really application-specific (Score:1)
I'm assuming you're using MPI for message passing. Why can't you go with MPI directly over GigE without going over IP? There are MPI libraries that communicate directly with SCI, MyriNet, Infiniband, etc, why not GigE? I did a quick google for such a library, but didn't find any, so maybe it's part of standard MPI implementations already.
If you're not using MPI, there must be a
Re:This is really application-specific (Score:2)
On a linux system, that would be an interesting benchmark for proof of concept, but not something a vendor would support us for.
This is for a large corporation so supported platforms is critical.. i don't believe redhat or suse have certified MPI over GigE in any form
Multiple Networks (Score:5, Informative)
One was a high latency high bandwidth switched network (I reccomend GigE since it has good price/performance) and one was a low latency low bandwidth network just for passing messages between CPUs. The application should be able to pass off thoroughput intensive stuff (file transfers and the like) to the high latency network, and keep the low latency network clear for inter-cpu communication.
The low latency network depends on your precise application. I've seen everything from a hypercube topolgy w/ GigE (for example with 16 machines in the grid, you need 4 gigE connections for the hypercube per computer. It always seemed to me that the routing in software would be really high latency, but people smarter than me tell me it's low latency so it's worth looking into). Personally, I just use a 100mbit line with a hub (i tried with switch, but it actually introduced more latency at less than 10% saturation since few collisions were taking place anyways) for the low latency connect. The 100mbit line is never close to saturated for my application, but it really depends on what you need.
The big thing is make sure your software is smart enough to understand what the two networks are for, and not try to pass a 5 gig file over your low latency network. Oh, and I definetly agree. If you are dealing with more than $10K-20k it's definetly worth it to find a consultant in that field to at least help with the design, if not the implementation.
Re:Multiple Networks (Score:1)
This article is about APPLICATION CLUSTERING (in this case a very specific relational database) and you are answering the question with information that is generalized to a COMPUTE FARM or a Linux cluster built and optimized for high performance computing.
The two areas are completly distinct and have different "best practices" when it comes to network topology, configuration and interc
SCSI Question (Score:2)
Myren
Re:SCSI Question (Score:1)
Yes you can... (Score:2)
Most the time they are used in Hot/Cold clusters. It's easiest to manage. Hot/Hot is possible, but you need to make sure your applications know how to handle it properly.
It works by each of your servers having a SCSI/RAID controller card. They connect to a shared backplane in some sorta storage array (like a PowerVault). Make sure your backplane isn't set to 'split' mode, in which case each serv
Re:Yes you can... (Score:2)
Will it be possible to find this sort of support in "consumer" RAID gear? I'm looking at the Intel SRCU42X and LSI MegaRAID 320-2e (both $700) and dont know how it would work. The main thing I dont understand is what form the utilities for these kinds of cards will be in... how arrays are setup, how hotswap is performed, &all... I doubt the firmware interfaces are open enough to
imo/e (Score:1)
and don't skimp on switches. Get something from the Extreme Networks Summit range if possible
We use Gigabyte Ethernet (Score:2)
--
Barebones computer reviews [baremetalbits.com]