Adaptery FC IBM Power: czy SFP to osobny FRU i czy IBM wymieni optykę, której od nich nie kupiliśmy
Mamy kilka maszyn IBM Power obok małego SAN-u i próbuję spisać sensowną politykę zapasów przed kolejnym odnowieniem kontraktu serwisowego. Czego nie mogę dokładnie ustalić, to sam transceiver: w niektórych adapterach wygląda na osobną część field-replaceable, w innych zgłoszenie serwisowe kończy się wymianą całego adaptera, a optyka wychodzi razem z nim za drzwi.
- IBM Power Systems, adaptery Fibre Channel 32Gb i 64Gb
- adaptery Ethernet i RoCE w tym samym chassis, gniazda SFP28 i QSFP28
- optyka w większości dostarczona przez IBM, plus garść modułów SFP28 innych producentów po stronie Ethernet
Co udało mi się dotąd wygrzebać z dokumentacji adapterów:
64Gb FC: EN2N/EN2P (CCIN 2F05), EN1N/EN1P (CCIN 2CFD) - transceiver FRU 78P7722
32Gb FC: EN2L/EN2M (CCIN 2F06), EN1L/EN1M (CCIN 2CFC) - transceiver FRU 02CL041
Co już próbowałem:
- otworzyłem zgłoszenie serwisowe na porcie, który ucichł, a efektem była wymiana FRU adaptera, a nie optyki
- zapytałem, czy możemy po prostu zamówić FRU transceivera i trzymać zapas na półce, i nie dostałem jasnej odpowiedzi
- przejrzałem featury adapterów Ethernet, żeby sprawdzić, czy tam obowiązuje ta sama logika
Dwa więc pytania. Przy których featurach transceiver jest naprawdę osobnym FRU, i jakie jest faktyczne stanowisko serwisu, kiedy moduł w gnieździe nie został kupiony od IBM?
Comments 3
Twoje odczytanie strony FC jest poprawne, i te dwa FRU to cała historia: 78P7722 dla featurów 64Gb i 02CL041 dla 32Gb. Lista jest publikowana per kod feature, a nie per rodzina adaptera, więc sprawdzaj swój, zamiast zakładać, że sąsiedni slot zachowuje się tak samo.
W Ethernet i RoCE featury z osobno wymienialną optyką obejmują EC85/EC86, EC75/EC76, EC66/EC67, EC2R/EC2S, EC2T/EC2U, EC3L/EC3M, EC3A/EC3B, EN24/EN26 i EC71/EC72. Przypadek odwrotny to adaptery miedziane: te nigdy nie staną się portami optycznymi tylko dlatego, że znalazłeś pasujący moduł, po prostu nie grają w tę grę.
Część serwisowa jest brutalnie prosta i to ona decyduje o twojej polityce zapasów. Jedyna optyka, przy której IBM w ogóle rusza ręką, to ta kupiona od IBM, wciąż na gwarancji albo objęta kontraktem serwisowym na sprzęt. Wszystko inne wypada poza umowę serwisową, nawet jeśli gniazdo jest mechanicznie otwarte, a port łączy się bez żadnego problemu. Ta sama dokumentacja mówi też, żeby nie wymieniać modułu przed przejściem normalnego troubleshootingu, co bardzo prawdopodobnie tłumaczy, czemu twoje zgłoszenie skończyło się wymianą adaptera.
To zgadza się z tym, co mamy w szafach. Nasze porty 32Gb to para EN1L/EN1M, więc 02CL041 to numer, który trzeba trzymać na półce, i przestaję udawać, że SFP28 innych producentów w adapterach Ethernet są czymkolwiek objęte. Te zostają po stronie labowej środowiska.
Co do kolejności troubleshootingu, przyjąłem do wiadomości. Teraz zapisujemy błędy portu i odczyty modułu, zanim ktokolwiek dostanie zgodę na wyciągnięcie optyki, więc zgłoszenia nie da się zamknąć wymianą adaptera tylko dlatego, że ktoś najpierw ruszył moduł.
Warto rozdzielić dwie rzeczy, które w pracy z SAN ciągle się mieszają: interoperacyjność protokołu i sprawdzanie kodowania per port. Mieliśmy IBM SAN24B-5 przed HPE MSA 2040 ES LFF, którego porty miały HPE 8 Gb shortwave FC SFP+ (C8R23A), i mieszanka marek nikomu nie przeszkadzała, bo każdy moduł musi zostać zaakceptowany tylko przez gniazdo, w którym siedzi. Zostaw optykę producenta macierzy w macierzy, optykę producenta switcha w switchu, i omijasz jednocześnie kontrolę vendora i kłótnię o support.
Druga pułapka to migracja. Stary długofalowy SFP+ 8G, część 57-1000027-02, z SAN48B-5 nie przechodzi na SAN64B-7 (8960-P64, pod spodem G720) - nie są na liście kwalifikowanej dla pudełka Gen7. Sprawdź każdy numer części względem matrycy wsparcia transceiverów Brocade, zanim zbudżetujesz przenosiny, i najpierw puść sfpshow na starym switchu, żeby dokładnie wiedzieć, co masz w rękach.