Po jednej stronie… Rasowy Strongmen o numizmatycznych rysach. Same kości i mięśnie zamknięte w korpusie o wadze sześćdziesięciu trzech kilo. Trzy procent tłuszczów organizmie, reszta, same sterydy. Po drugiej stornie… Rasowy NetApp o niezdrowo niebieskiej facjacie. Szczerzący kieszenie dysków, niczym kły w uśmiechu. 200 kilo rozłożone w kartonach, gotowe do włożenia w szafę…

7262958132_24fc8e798d

Po montażu, który, zapewniam Was był dynamiczny jak gra w golfa i porywający jak przemówienia Castro. Nieubłaganie nadszedł moment uruchomienia. Konfiguracja FC, Rajdzik i jakieś Luny. Wydawałoby się, że sprawa banalna i nic nie może nas w niej zaskoczyć… a NetApp na to niemożliwe:

fcp start: Cluster interconnect has never been up. If clustering has just been licensed a reboot is required to enable the cluster interconnect, or the cluster cables could be unplugged. Please correct before starting fcp.

Błąd ten, opisany w kilku dyskusjach na forum NetApp’a, oraz publikacjach KB wydaje się wynikać z nieodpowiedniego wpisania licencji, niezrestartowania filera, albo o zgrozo problemów z klastrem. Być może, faktycznie powyższe elementy mogą go powodować, dla mnie jednak NetApp zafundował coś zupełnie innego.

Problem polegał na tym, że na początku wpisałem licencje FC, a dopiero potem licencje klastra. Zaowocowało to tym, że interfejsy macierzy ustawiły się w tryb inicjatora, a nie oczekiwanego targetu. Po wpisaniu licencji klastra próba uruchomienia podsystemu FC poprzez urokliwe GUI OnCommanda kończyła się wyżej wymienionym błędem. Dodatkowo zastanawiający był fakt iż sam podsystem FC według konsoli macierzy się uruchamiał a komenda:

fcp status

Zwracała informację, iż działa, ma się dobrze, ale nie posiada żadnych aktywnych targetów:

fcp: No FCP Target Adapters are present in this system.

Wszystko więc,rzekomo działało. Jednakże GUI dalej przy próbie uruchomienia FC uparcie rzygało wspomnianym błędem. Po restartach filerów, wyłączeniu klastra i innych szamańskich zabiegach stwierdziłem, że problem musi leżeć w czymś innym. Wtedy właśnie przyszło mi do głowy, że może nie będę zachowywać się jak bezmyślna małpa, która podczas przerwy w iskaniu rzuciła się panicznie na google, a zacznę trochę myśleć. To był ten moment, kiedy wpadłem na pomysł, że wszelkie problemy mogą być spowodowane nieświadomością klastra i FC swoim istnieniu. Postanowiłem wyłączyć FC i uruchomić je ponownie. Na początku wywołałem komendę fcadmin:

filer>fcadminconfig
Local
Adapter Type State Status
———————————–
1a initiator configured online
1b initiator configured online

Dała mi ona do zrozumienia że dwa intefejsyFC obecne na kontrolerze są online – czyli działają, ale co mnie zaintrygowało, działają w trybie inicjatora. Postanowiłem zmienić tryb interfejsu z initiator na target, co według KB 2013410 z oficjalnej strony NetApp’a robi się za pomocą polecenia:

fcadmin config -t target 1a

Po jego wywołaniu otrzymałem informację, że dostęp jest zabroniony. Zalogowany byłem jako root, wiec wydało mi się to nieco zabawne i coraz bardziej interesujące. Wytoczyłem cięższe działa i postanowiłem zupełnie wyłączyć wspomniane karty HBA:

storage disable adapter 1a
storage disable adapter 1b

Udało się. Karty przeszły w tryb offline i przy użyciu komend:

fcadmin config -t target 1a
fcadmin config -t target 1b

Przełączyłem ich tryb w upragniony target. Następnie, aby operacje można było uznać za faktycznie udaną należało zrestartować filer, moją ulubioną po halt, komendą:

reboot

Proces startowania był równie szybki jak dziewczyny na wiejskiej dyskotece. Po kilku minutach macierz oczekiwała na mnie. W morkach konsoli wywołałem sakramentalną komędę…

fcp start

… badum, tsss!

Pomocne linki:

About the author

Bloger i niezależny konsultant z wieloletnim doświadczeniem w branży IT. Specjalizujący się w wirtualizacji i cloud computingu. Posiada tytuły MCP, MCTS, VCP oraz VMware vExpert.
2 Responses

Leave a Reply