[Info-vax] ES47 2G FC and rx2800 i4 8G FC in same VMS Cluster with Shadowsets on shared storage controller? Is this possible?

[Forster, Michael]

Note that EVA's required "in order delivery", hence store and forward.

Michael Forster
Enterprise Storage and IDX Architect | Information Services
Medical College of Wisconsin
O: (414) 955-4967 |  mforster at mcw.edu


________________________________________
From: Info-vax <info-vax-bounces at rbnsn.com> on behalf of Jan-Erik Söderholm via Info-vax <info-vax at rbnsn.com>
Sent: Sunday, March 15, 2020 7:17:26 AM
To: info-vax at rbnsn.com
Cc: Jan-Erik Söderholm
Subject: Re: [Info-vax] ES47 2G FC and rx2800 i4 8G FC in same VMS Cluster with Shadowsets on shared storage controller? Is this possible?

ATTENTION: This email originated from a sender outside of MCW. Use caution when clicking on links or opening attachments.
________________________________

Den 2020-03-15 kl. 00:02, skrev Grant Taylor:
> On 3/14/20 4:26 PM, Colin Butcher wrote:
>> Brocade FC switches implement 3 speeds: 1/2/4, 2/4/8, 4/8/16, and so on.
>
> Good to know.
>
>> You might be able to have cascaded switches in the same fabric to handle
>> a wider range of speeds, but you'll add latency due to the extra switch hops
>
> Will the extra latency in and of itself be a problem?
>
>> and you could run into firmware interoperability issues.
>
> I would expect that these issues could be overcome.
>
>> The 16GigFC storage should run at 4GigFC (16/8/4), as should the 16GigFC
>> HBAs in the rx2800s, so that might work for you as part of a migration
>> design with your 4GigFC switches, changing over to faster switches later
>> once the Alphas are gone.
>
> Other than the added latency of cascading switches, what would be the
> downside of doing so?
>
> It seems to me like configuring all the new equipment on the 16 Gbps FC
> switch would be a one time operation.  Once the cluster is migrated from
> the Alphas to the Itaniums, the old Alphas, 4 Gbps FC equipment could be
> removed, leaving the new systems intact and not needing any further changes.
>
> What is the down side of doing this other than the extra latency?
> (Presuming that any firmware issues are null or overcome.)
>

Our 2 GB AlphaServer DS20e (as far as I know, the max FC speed) runs in an
environment where the Power9 and other "modern" servers uses 32 GB against
the same IBM V7000 Storwize SAN systems. So we share SAN with other i/OS,
AIX, Windows and Linux systems.

I know that they (the FC/SAN management group) have saved a few FC switches
that supports 2 GB but I have little knowledge about how it is setup in
the rest of the FC network.

If it could be valuable, I can check with the FC/SAN group about it
and maybe get a setup description. That is, how are our 2 GB DS20s
interfaced against the othervise 32 GB SAN system.

But, it does work very well. No FC issues since we switche to this setup
6-7 years ago. The SAN systems has moved from IBM D8000 to V7000 and there
have been several on-line FC switch FW updates and also switch replacements
with no interuptions on our (OpenVMS) side. Just the usual "Last switched
to" and "Last switched from" counters on the "I/O Paths" (4 of them/disk).

And as far as I understand, all our OpenVMS storage is on SSD after the
last IBM SAN hardware change.


>> Fibrechannel is cut-through switching, not store and forward switching.
>
> How does Fibre Channel switching handle something coming in at 2 Gbps going
> out at 4 Gbps?  Is there any sort of buffering?  Does it go out the 4 Gbps
> interface at 2 Gbps?  Or does the FC switch do something to receive the
> entire frame (?term?) at 2 Gbps and then send it at 4 Gbps?
>

I guess that traffic going DS20 -> SAN is no issue, it is just that the
higher speed parts will not be saturated. We (the VMS) side can saturate
our 2 GB line but the 32 GB line going in to the SAN will of course not
saturate at 32 GB. It will still be a 32 GB line, but most of the time
being idle/silent.

For traffic the other way (32 GB SAN -> 2 GB DS20) I guess that there must
be some handshaking backwards so that the SAN will wait for the next switch
to send to the slower line before pushing out the next 32 GB FC package.

And it is fast, we easily saturate the CPU before the storage I/O.
A little depending on what we do (a SEARCH vs. an Rdb query), but still
fast, when measured against the heydays of an 666 Mhz DS20...


>
>

_______________________________________________
Info-vax mailing list
Info-vax at rbnsn.com
https://urldefense.com/v3/__http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com__;!!H8mHWRdzp34!tZ_Kn-MQALi9qiGUfmsLfZCAmgHKDbdgGez_rF4DIlviyQtCe5-KxeLlobLiK3Q$