question about syscalls on FA ports

Syscalls, as you may well know is the communication protocol used by EMC software to inquire and manage the array. They are sent as SCSI commands and use FA resources to process the request. You have done very well to dedicate FA ports for managment in your design as you have offloaded this overhead from the infrastructure your customers servers use. This means you have minimised the risk of any syscall related performance issue.

The number of syscalls is related directly to the amount of management being performed. They will be generated from SYMCLI, SMC, ECC, SPA etc.

Having one pair of dedicated FA's should be plenty for Symmetrix management. The only impact in the peaks of syscall activity you will see is an elongated turn-around time in your CLI commands.

I didn't realize that GKs could produce a seriously load on an FA. Really ? I never heard this anywhere, but indeed: as long as you can dedicate FAs for this, it's cool !

I always mapped and masked GKs to the same FAs as the normal symdevs. Good to know.

RRR Just look at the numbers... He measured 1000 iops on GKs ports. I simply don't even want to know where do they come from. I see 1000 iops. Full stop.

This means that spreading the GKs on all ports (how many ports? don't know) would spread 1000 iops on other ports. Huge load? No, I don't think it's a huge load but may help at keeping predictable performances (since GK workload won't ever interact with the "real" data that the host is exchanging with the storage).

You may argue that placing GKs on a dedicated FA won't help when the bottleneck is on the HBA side (since both "real" volumes and GKs are accessed using a shared HBA on the server, with "shared" meaning that the same HBA can see two different FAs). But when the bottleneck is on the HBA you simply drop a couple more HBA in the host and live happy ;-)

it depends

it depends

it depends.... sure, if you have a few FAs just sitting there

But even for performance reasons... how many I/Os can you send to a GK ? Doing what ?

split BCV

symrdf est

symdev show

I'm not convinced keeping GKs appart from real LUNs will be a fantastic boost for performance.

Rob as usual when it comes to performances, the answer is "it depends" ;-)

Syscalls are simply SCSI commands targetted at specific devices (the GKs) that run through your FC link. They don't put direct pressure on the backend (since it's simply a way to exchange data between SolEnabler on the host and Engenuity in the storage) but indeed requires action of the FA port. They are simply SCSI commands, just like a plain READ or WRITE. The only difference is that they have a different OPCODE. But it's always a SCSI command running on the wire ;-)

1000 iops does't look like an impressive load to me ;-) Supposing that syscalls use small frames and won't ever require access to the drives, I guess you can even see higher numbers...

If you have a couple of unused FA ports, worth using them for the GKs. And you can always work around OS glitches using symmask to enable/disable FA port flags ;-)

> Just look at the numbers... He measured 1000 iops on GKs ports. I simply don't even want to know where do they come from. I see 1000 iops. Full stop.

You're right. The numbers are right there indeed.

Two dedicated HBAs for GKs is indeed a great idea. I guess QLogic / Emulex will approve this

> Two dedicated HBAs for GKs is indeed a great idea. I guess QLogic / Emulex will approve this

A tad extreme but worth trying ... I suspect you are s supported and it works fine! ;-)

All,

Thanks for your responses.  It was all very valuable input.