HP Auto Port Aggregation -- anyone doing server-to-server?

[Brian M Rawlings]

I've been reading up on APA, and server-to-server connections using crossover cables (no switches) appears to be fully supported.

Is anybody out there doing this, who can confirm that it works as advertised?

I'm particularly looking for any gotchas in setting up the APA connections, any words of wisdom from folks who have done it, and any problems they'd like to share (so I can avoid them).

Thanx in advance. --bmr

[rick jones]

One very important thing to keep in mind if you go server-to-server is that you need to select the TCP/UDP port based packet scheduling, and not the MAC or IP-based - with server to server, there is only ever one MAC or IP, which means that the load balancing wouldn't work terribly well :)


Also, don't forget that the perf boost with APA is for _aggregates_, not for an individual connection. A single FTP will not go any faster (to a first approximation) than it would over a single link, but several FTP's in parallel will.

[Brian M Rawlings]

Thanks, Rick. I've read through the "make your network go like a scalded dog" white paper on the www.docs.hp.com website, and I had the TCP/UDP port-based scheme in mind for this.

I hadn't thought it through enough to realize that one connection (same port, IP, MAC, CPU, everything) can't span to multiple links, thanks for the info.

The intention is to have an extremely fast connection from app server to DB server, since they are currently on the same box, and are basically using backplane speeds & IPCs for communication. I imagine that there will be many different communication threads in use at all times, and that we will see the aggregated links kick in with decent load balancing.

I also doubt that we'll really need all this bandwidth, but it would be very bad to expand to two faster boxes, split the app and DB onto their respective (and specifically tuned) servers, and still have mediocre performance due to messaging bottlenecks.

Anybody else? I'm hoping to hear from people who are doing this out there, surely there is somebody running in this fashion? I have a big pile of points, no pushing, there's enough for all... 8^)

--bmr

[Krishna Prasad]

We don't use APA for server to server, however we do use APA. We also have APP Servers talking to a DB Server. We bind two ports together both giving us 200 MB Full Dublex. We have the ability to expand this to X the number or ports available. Which should give you a fast connection. It may not be server to server, but .....definity not a bad solution.


Also, what kind of App/Database application are you using?

[John Bolene]

We use a single 1 Gig link between an app and DB server. We have not seen the need to go to multiple links.

We are running Oracle for the DB and java for the app. Java is such a memory pig.

What are you running that you need multiple Gig links?

[Mark Greene_1]

We are in process of upgrading one of our remaining Data General servers to an HP, and this software was included on the quote for the new system. As I'd not heard of it before, I asked them what it was for. I was told it was for use with the VA7100 disk system, but given that we are also purchasing an EMC Clariion SAN, we wouldn't neeed it.

I am now questioning that statement. The server being upgraded runs an Oracle db, and communicates with two other servers via another server that acts as the interface link between the three. So, does anyone have a URL for info from HP on this package?

thanks,
mark

[John Bolene]

APA is not used for disk access, it is for lan access.

It is a way to connect multiple lan lines from point to point and get greater thruput.

check these

http://docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/J4240-90017/J4240-90017_top.html&con=/hpux/onlinedocs/J4240-90017/00/00/1-con.html&toc=/hpux/onlinedocs/J4240-90017/00/00/1-toc.html&searchterms=port%7cauto&queryid=20030120-123541


http://docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/J4240-90016/J4240-90016_top.html&con=/hpux/onlinedocs/J4240-90016/00/00/4-con.html&toc=/hpux/onlinedocs/J4240-90016/00/00/4-toc.html&searchterms=port%7cauto&queryid=20030120-123541

[Tim D Fulford]

Hi... This does not answer question at all..... but dont stop reading as I think the below is useful....

If I'm right... you currently have an App & DB on the same computer & you now want to get a more "scaled" performance out of it. Thus you are splitting it into two.

We do not use APA, BUT APA or multiple 100BaseT LAN cards have some significant advantages ove faster network cards under certain circumstances.

We did an App/DB split and saw very good results. However, specifically on the nework communication.
o IF you are using small packets / data transfers between app & DB (likely if you are OLTP) you will not get the full bandwidth of the card. You will PROBABLY be throughput limited (i.e. limited to say 40,000 pkt/s) per network card. Going to gigabit is unlikely to help as it too will have a similar limit (40,000). THUS your choice for APA or multiple cards makes sense.

Why am I saying the above, well it can be far cheaper to go gigabit than use APA. As I've just mentioned above APA or multiple LAN cards will scale if you use small data packets (by small <100 Bytes)...

Regards

Tim

[Brian M Rawlings]

All: the configuration is one RP5405 2-way Oracle DB server, with one 4-way RP5405 SAS server (very compute intensive, pulling data from the Oracle DB server).

As I said, the concern over the need for speed is that, currently, SAS-to-Oracle communication is at backpanel speeds. Even in a K-class, this is pretty fast IPC traffic.

As we seperate the functions between two servers, we wanted to be sure (sure as can reasonably be) that the APP-to-Server comms does not become the hobble for our new pair of thoroughbreds.

Ron: thanks for the confirmation. If you can do it via trunked 100bT, we should be good to go with Gig-E, trunked or not.

John: my sympathies on the Java side. We have the opposite problem -- SAS is low memory usage, but very CPU-intensive. As to the "need" for trunked Gig-E, it's probably overkill... but, absent good info from the app vendor or HP or somebody who's doing this, we erred on the side of absurd speed. I think we'll be fine.

Mark: thanks for your question, John pointed you at the right place. The www.docs.hp.com website has a wealth of info about this app, which I believe you will find as useful as I expect to.

Tim: thanks for your answer, good info. I believe (not positive) that SAS pulls info in lots of small chunks, so we may indeed see lower than expected speed on each link. APA is actually not too pricy, and it is one cost per box, no tiering, as many or as few links as you need on the box. That makes it easy to justify. Doing it with Gig-E gives us the benefits of both types of speed enhancers, and I can't imagine we'll have a speed issue between DB & Apps.

Thanks to all for your responses. Still looking for anyone with experience doing APA back-to-back (server-to-server). Is this really that rare? We'd prefer to spare the switch ports & traffic by just using crossover cables. Maybe nobody really does it this way.

If I remember, I'll update this thread once we get it working, with any issues or with a "works great" & some numbers.

Best Regards, --bmr

[rick jones]

Indeed the "old" GbE NICs would have a PPS limit of about 40K - that is, Ican max-out an old GbE card (A4926A and friends) with about 35 to 40K netperf TCP_RR transactions per second (single-byte) which is 40K in each direction. That does not saturate the interrupt CPU.

Last I measured a 100BT NIC, the limit there was about 50K netperf TCP_RR trans/sec. I think that was on a single-CPU, 440 MHz box and may have represented a CPU saturation, but the dimm memory is fading...

The GbE NIC of choice these days would be the A6XXX's - these are the next generation GbE NIC. It has a much higher packet per second limit on the card, and lower latency for a single stream of transactions.