Potwierdzić czy Nie Potwierdzić 6.1.4.1

UWAGA: Dzisiaj, odtrzymałem email od inżyniera IBM pracującego nad doświadczonym przeze mnie problemie dotyczącym TL4 dla AIX6.1 na maszynie używającej FlashCopy z SVC oraz SDD 1.7.2.4 – bez problemów udało mu się odtworzyć moje doświadczenie w tym zakresie – “dziwne” rezerwacje dysków FlashCopy niepozwalające na użycie ich do tworzenia backups. Dobra wiadomość to fakt, że IBM serwis pomocniczy dla AIXu zdaje sobie sprawę z istnienia tego problemu i aktywnie zajmuje się jego rozwiązaniem.

Nasz administrator sieci, zauważył pewien rodzaj błędów pojawiających się na portach przełącznika (ethernet switch) obsługujących nasz TSM serwer. Istnienie tych błędów może wytłumaczyć, dlaczego ostatnio mamy do czynienia z tak duża liczbą przerwanych sesji pomiędzy serwerem TSM a jego klientami. Kilka dni później otrzymałem wiadomość od IBM informującą o istnieniu “fixa”, który wyglądał jak coś, co mogło wybawić nas z naszych kłopotów. Ten APAR to IZ44472, który jest również obecny w pakiecie 6100-04. Przed odświeżeniem systemu operacyjnego, polecenie oslevel -s produkowało 6100-03-02-0939. Po zainstalowaniu pakietu 6100-04, to samo polecenie produkowało 6100-04-01-0944 – system operacyjny został przesunięty “do góry” o jeden stopień technologi.

Po tym “odświeżeniu”, skrypty Flash Copy przestały pracować. Kiedy mówię, że ‘skrypty Flash Copy’ przestały pracować nie mam na myśli, że odmówiły pracy polecenie wydawane z maszyny AIX, których odbiorcą jest SVC kontrolujące “dyski” Flash Copy. Skrypty i używane przez nie polecenia systemu operacyjnego, które używają dyski Flash Copy do odtworzenia grup dysków będących źródłem ‘backapu’ przestały działać. Fakt, że te same skrypty pracowały przez kilka ostatnich lat jeszcze bardziej utrudniał zrozumienie tej sytuacji.

Dokładnie, te polecnia: dd, lqueryvg -Atp, redefinevg, chpv oraz chdev pod odmawiały “dotknięcia” którego kolwiek z dysków znajdujących się pod kontrolą FlashCopy

[lang_p]Dziennik błędów, zawierał informację o problemach związanych z ‘elektronika” dysków, kablami i rezerwacją. Wszystko wskazywało na problemy z SVC i DS4XXX (system dysków używanych do Flash Copy). Wszystkie związane z tym środowiskiem urządzenia zostały rmdev’d, całe środowisko Flash Copy na SVC zostało zniszczone po czym ponownie je stworzono – wszystko na nic, sytuacja nie uległa poprawie. W sumie, spędziliśmy kilka godzin przyglądając się wszystkiemu poza TL4.

Po tym jak wykonaliśmy REJECT zbiorów plików będących w stanie APPLIED (nie COMMITED!) zbioru technologi TL4 nasza Flash Copy ponownie zaczęła pracować. Ta operacja, jest przyczyną tego postu.:

nigdy nie COMMIT (instalacja programów), poczekaj kilka dni lub tygodni i dopiero wtedy jak sprawdzisz, że wszystko pracuje tak jak pracowało wydaj polecenie do COMMIT. W przeciwnym wypadku, nie będziesz w stanie wrócić do poprzedniego poziomu systemu operacyjnego.

IBM chce zobaczyć czy będą w stanie odtworzyć moją systuacje, ja czekam na ich werdykt. Mam zamiar zainstalowania TL4 na innej maszynie w celu sprawdzenia czy FlashCopy dozna tej samej porażki.

Uważaj co robisz jeżeli używasz SVC (moja wersja to 4.2.0.2)/FlashCopy, twój AIX to 6100-03-02-0939 razem z devices.sdd.61.rte 1.7.2.4 i chcesz zainstalować TL4 – nie rób COMMIT tych plików, poczekaj!