Najbardziej wydajne superkomputery upadają najtrudniej, naukowiec sugeruje

Ponieważ superkomputery stają się coraz potężniejsze, dzięki rosnącej ilości wbudowanego komponentu będą również bardziej podatne na awarie. Kilku badaczy z niedawnej konferencji SC12 w zeszłym tygodniu w Salt Lake City w stanie Utah zaoferowało możliwe rozwiązania tego rosnącego problemu.

Współczesne systemy obliczeniowe o wysokiej wydajności (HPC) mogą mieć 100 000 węzłów lub więcej - z każdym węzłem zbudowanym z wielu elementy pamięci, procesorów, magistrali i innych obwodów. Statystycznie rzecz biorąc, wszystkie te elementy zawiodą w pewnym momencie i zatrzymają operacje, kiedy to zrobią, powiedział David Fiala, doktorant na Uniwersytecie Stanu Karolina Północna, podczas przemówienia w SC12.

Problem nie jest oczywiście nowy. Kiedy 600-węzłowy ASCI Lawrence Livermore National Laboratory (ang. Accelerated Strategic Computing Initiative) wszedł do Internetu w 2001 roku, miał średni czas między awariami (MTBF) wynoszącym tylko pięć godzin, częściowo dzięki awariom komponentów. Późniejsze wysiłki w zakresie tuningu poprawiły MTBF ASCI White'a do 55 godzin, powiedział Fiala.

Ale wraz ze wzrostem liczby węzłów superkomputera, problem będzie. "Coś trzeba z tym zrobić. Będzie coraz gorzej, gdy przejdziemy do eksaskali", powiedział Fiala, odnosząc się do tego, że superkomputery następnej dekady będą miały dziesięciokrotnie większą moc obliczeniową niż dzisiejsze modele.

Dzisiejsze techniki bo radzenie sobie z awarią systemu może nie być bardzo skalowalne, powiedział Fiala. Przytoczył punkt kontrolny, w którym uruchomiony program jest chwilowo zatrzymany, a jego stan zapisany na dysku. Jeśli program ulegnie awarii, system będzie mógł ponownie uruchomić zadanie od ostatniego punktu kontrolnego.

NCSUDavid Fiala Problem z punktami kontrolnymi, według Fiala, polega na tym, że wraz ze wzrostem liczby węzłów, ilość narzutu systemowego potrzebne do robienia punktów kontrolnych również rośnie - i rośnie w tempie wykładniczym. Na przykład na superkomputerze na 100 000 węzłów, tylko około 35 procent aktywności będzie zaangażowanych w prowadzenie pracy. Resztę przejmą punkty kontrolne i - powinieneś wykonać operacje odzyskiwania systemu - szacuje Fiala.

Ze względu na cały dodatkowy sprzęt potrzebny do systemów exascale, które mogą być zbudowane z miliona lub większej liczby komponentów, niezawodność systemu będzie być poprawionym przez 100 razy, aby utrzymać ten sam MTBF, którym cieszą się dzisiejsze superkomputery, powiedział Fiala.

Stara, dobra rada: kopie zapasowe

Fiala przedstawiła technologię, którą on i inni badacze opracowali, co może pomóc poprawić niezawodność. Technologia rozwiązuje problem cichego niszczenia danych, gdy systemy ujawniają niewykryte błędy podczas zapisywania danych na dysk.

Zasadniczo podejście badaczy polega na jednoczesnym uruchamianiu wielu kopii lub "klonów" programu, a następnie porównywaniu odpowiedzi. Oprogramowanie o nazwie RedMPI jest uruchamiane w połączeniu z Message Passing Interface (MPI), biblioteką do dzielenia działających aplikacji na wiele serwerów, dzięki czemu różne części programu mogą być wykonywane równolegle.

RedMPI przechwytuje i kopiuje każdy MPI wiadomość, którą aplikacja wysyła, i wysyła kopie wiadomości do klonu (lub klonów) programu. Jeśli różne klony obliczyć różne odpowiedzi, to liczby można ponownie obliczać w locie, co pozwoli zaoszczędzić czas i zasoby przed ponownym uruchomieniem całego programu.

"Wdrażanie redundancji nie jest drogie. Może to być dużo liczby rdzeni które są potrzebne, ale pozwala uniknąć przepisywania z ponownym uruchamianiem punktów kontrolnych "- powiedział Fiala. "Alternatywą jest oczywiście ponowne uruchomienie zadań, dopóki nie podejmiesz właściwej odpowiedzi."

Fiala zaleciła uruchomienie dwóch kopii zapasowych każdego programu, w celu uzyskania potrójnej nadmiarowości. Mimo że uruchomienie wielu kopii programu początkowo pochłania więcej zasobów, z czasem może być bardziej wydajne, ponieważ programy nie muszą być ponownie uruchamiane w celu sprawdzenia odpowiedzi. Również punkt kontrolny może nie być potrzebny, gdy uruchomionych jest wiele kopii, co również pozwala zaoszczędzić na zasobach systemowych.

UCSCEthan Miller

"Myślę, że idea wykonywania nadmiarowości jest naprawdę świetnym pomysłem. [Dla] bardzo dużych obliczeń obejmujących setki tysięcy węzłów, z pewnością istnieje szansa, że ​​błędy będą się pojawiać", powiedział Ethan Miller, profesor informatyki na Uniwersytecie Kalifornijskim Santa Cruz, który wziął udział w prezentacji. Ale powiedział, że podejście może nie być odpowiednie, biorąc pod uwagę ilość ruchu sieciowego, jaki może stworzyć taka redundancja. Zaproponował uruchomienie wszystkich aplikacji na tym samym zestawie węzłów, które mogłyby zminimalizować ruch międzywęźlowy.

W innej prezentacji Ana Gainaru, doktorantka z University of Illinois w Urbana-Champaign, zaprezentowała technikę analizy dziennika pliki do przewidywania, kiedy wystąpią awarie systemu.

Praca łączy analizę sygnałów z eksploracją danych. Analiza sygnału służy do scharakteryzowania normalnego zachowania, więc gdy wystąpi awaria, można ją łatwo zauważyć. Eksploracja danych szuka korelacji między oddzielnymi raportowanymi awariami. Inni badacze wykazali, że wielokrotne awarie czasami są ze sobą skorelowane, ponieważ awaria jednej technologii może wpływać na wydajność innych, według Gainaru. Na przykład, gdy karta sieciowa ulegnie awarii, wkrótce przepycha się inne procesy systemowe, które opierają się na komunikacji sieciowej.

Naukowcy odkryli, że 70 procent skorelowanych niepowodzeń zapewnia okno możliwości dłuższe niż 10 sekund. Innymi słowy, po wykryciu pierwszego znaku awarii system może mieć do 10 sekund na zapisanie pracy lub przeniesienie pracy do innego węzła przed wystąpieniem bardziej krytycznej awarii. "Prognozowanie porażek można połączyć z innymi technikami tolerancji błędów" - powiedział Gainaru.

Joab Jackson omawia oprogramowanie dla przedsiębiorstw i ogólne nowości technologiczne dla Serwisu IDG News. Śledź Joaba na Twitterze na @Joab_Jackson. Adres e-mail Joaba to [email protected]