Wykorzystanie klastrów do wielkoskalowych obliczeń technicznych w chmurze

To rozwiązanie zapewnia wskazówki dotyczące wykonywania wielkoskalowych obliczeń technicznych w chmurze Google. Wiele technicznych aplikacji obliczeniowych wymaga dużej liczby pojedynczych węzłów obliczeniowych połączonych ze sobą w klaster oraz koordynacji obliczeń i dostępu do danych między węzłami.

koncepcje i technologie leżące u podstaw obliczeń klastrowych rozwinęły się w ciągu ostatnich kilku dekad i są obecnie dojrzałe i popularne. Migracja oprogramowania stack do Google Cloud może dodać kilka zmarszczek, ale oferuje również wiele możliwości zmniejszenia kosztów i złagodzenia istniejących wąskich gardeł w dzisiejszych środowiskach obliczeniowych o wysokiej wydajności. Ten przewodnik zawiera przegląd technologii, wyzwań i aktualnych rozwiązań dla klastrów obliczeniowych w Google Cloud.

przetwarzanie klastrowe agreguje i koordynuje zbiór maszyn do pracy w celu rozwiązania zadania. Klastry zazwyczaj mają pojedynczy węzeł główny (czasami nazywany węzłem głównym), pewną liczbę węzłów obliczeniowych i możliwe, że kilka innych węzłów specjalnych. Węzeł główny jest mózgiem układu i jest odpowiedzialny za:

  • rejestrowanie węzłów obliczeniowych w systemie.
  • monitorowanie węzłów.
  • przydzielanie zadań poszczególnym węzłom.
klaster składa się z węzła głównego i zestawu węzłów obliczeniowych.
Rysunek 1. Klaster składa się z węzła głównego i zestawu węzłów obliczeniowych. Użytkownicy wchodzą w interakcję z węzłem głównym, który następnie koordynuje pracę z węzłami obliczeniowymi.

użytkownicy przesyłają zadania, które składają się z wielu zadań, gdzie zadanie jest podstawową jednostką pracy. Niektóre aplikacje wymagają, aby wszystkie zadania w zadaniu były aktualnie uruchamiane i pozwalały zadań komunikować się, aby zaimplementować algorytm równoległy; niektóre zadania mają złożony zestaw zależności zadań, takich, że poszczególne zadania muszą być uruchamiane przed innymi; a niektóre zadania mogą wymagać szczególnych nodeconfiguracji w zakresie pamięci, procesorów lub innego konkretnego sprzętu, na którym mają być uruchamiane. Zadania to pliki wykonywalne, które odczytują dane wejściowe z magazynu, przetwarzają dane w celu uzyskania wyniku, a następnie zapisują końcowe wyniki z powrotem do magazynu.

istnieją dwa główne typy obciążeń obliczeniowych klastrów:

  • High-performance computing (HPC) – rodzaj obliczeń, który wykorzystuje wiele węzłów, ściśle ze sobą sprzężonych i wykonujących jednocześnie zadania atask. Maszyny te zazwyczaj wymagają niskiego opóźnienia sieci, aby skutecznie komunikować się. Przykładowe aplikacje w tej przestrzeni obejmują modelowanie pogody, obliczeniową dynamikę płynów (CFD), modelowanie naprężeń w inżynierii i projektowanie elektroniki.

  • high-throughput computing (HTC) – rodzaj przetwarzania, w którym aplikacje mają wiele zadań, które są przetwarzane niezależnie od siebie, bez potrzeby komunikowania się poszczególnych węzłów obliczeniowych. Czasami obciążenia te nazywane są obciążeniami równoległymi lub wsadowymi. Typowe przykłady obejmują renderowanie mediów, transkodowanie, genomikę oraz symulację i przetwarzanie zdarzeń w fizyce cząstkowej. Jeśli potrzebujesz przetworzyć wiele pojedynczych plików, prawdopodobnie jest to obciążenie HTC.

stos oprogramowania Cluster computing

stos oprogramowania cluster computing składa się z:

  • oprogramowanie do zarządzania systemem, które tworzy i tworzy klastry.
  • harmonogramy, które koordynują wykonywanie zadań.

w poniższych sekcjach omówiono oprogramowanie do zarządzania systemem i harmonogramy.

oprogramowanie do zarządzania systemem

oprogramowanie do tworzenia klastrów można uruchamiać bezpośrednio na sprzęcie bare-metal, w klastrach lokalnych lub w środowiskach zwirtualizowanych, jak w przypadku środowisk cloudenvironments. Ręczne orkiestrowanie wielu węzłów w klastrze jest czasochłonne i podatne na błędy. Możesz używać specjalistycznego oprogramowania do zarządzania klastrami, aby aprowizować i konfigurować wiele węzłów i zasobów, razem, w łatwy i deterministyczny sposób.

oprogramowanie open sourceElastiCluster z Uniwersytetu w Zurychu zapewnia natywne w chmurze podejście do zarządzania clusterem, z obsługą węzłów aprowizacyjnych, poprzez wykorzystanie silnika obliczeniowego i konfigurację węzłów za pomocą zestawu Ansibleplaybooks. ElastiCluster zapewnia węzły i instaluje podstawowy pakiet oprogramowania, w tym NFS do serwowania plików, zarządzanie kontami użytkowników NIS i harmonogram zadań do wykonywania aplikacji użytkowników. ElastiCluster obsługuje wiele różnych szedulerów i można go używać po wyjęciu z pudełka lub dostosować do potrzeb małych i średnich zespołów.

jeśli do zarządzania klastrami HPC używasz innych systemów zarządzania konfiguracją, takich jak Chef, Puppet lub Terraform, możesz wykorzystać te inwestycje podczas migracji do Google Cloud za pomocą dostępnych narzędzi i wtyczek.

Google Cloud zapewnia natywne usługi do udostępniania i wdrażania systemów oprogramowania wielowęzłowego. Cloud Deployment Manager umożliwia udostępnianie zestawu zasobów w chmurze, w tym silnika obliczeniowego, grup instancji zarządzanych przez silnik obliczeniowy i magazynu w chmurze. Tutorialhtcondor pokazuje, jak używać Cloud Deployment Manager i zarządzanych grup wystąpień do tworzenia i konfigurowania klastra.

harmonogramy zadań

po uruchomieniu klastra oprogramowanie, które zarządza wykonywaniem zadań i alokacją węzłów, nazywa się harmonogramem zadań (czasami nazywanym menedżerem zadań lub menedżerem kolejek). Często Menedżer klastra jest wyposażony w wbudowany harmonogram zadań. Harmonogramy zadań zapewniają różne funkcje ułatwiające zarządzanie zadaniami i zadaniami, takie jak:

  • wsparcie dla priorytetów zadań między użytkownikami i grupami, które pomaga w planowaniu zadań w oparciu o politykę.
  • Obsługa nieudanych zadań poprzez kolejkowanie i zmianę harmonogramu zadań.
  • rozważenie zależności zadań i potrzeb zasobów do alokacji zadań.
  • skalowanie rozmiaru klastra w zależności od liczby zadań w kolejce.

istnieje wiele popularnych komercyjnych i otwartych menedżerów obciążeń.Przykładami są: htcondor z University of Wisconsin,Slurm z SchedMD,Univa Grid Engine i LSF Symphony z IBM. Każdy ma swoje mocne strony.

HTCondor jest zbudowany w oparciu o filozofię shared-nothing I jest używany przez wspólne zasoby do oportunistycznego planowania zadań na innych, luźnych zasobach. Zapewnia własny ruch danych i dlatego nie wymaga systemów sharedfile. W rezultacie HTCondor skaluje się do setek tysięcy rdzeni i można go używać w wielu strefach i regionach. HTCondor jest używany do obciążeń hybrydowych, w których praca jest współdzielona lub dzielona między systemy lokalne i chmurowe. Jednak, jak sama nazwa wskazuje, koncentruje się on na miejscach pracy o dużej przepustowości, a nie ściśle powiązanych, równoległych miejscach pracy.

Slurm i Univa Grid Engine zapewniają bardziej tradycyjne środowisko klastra HPC,obsługujące zarówno wysokowydajne, jak i wysokowydajne aplikacje równoległe. Zakładają wspólny system plików między węzłami, co eliminuje potrzebę przenoszenia danych. Oba zapewniają wygodne i znajome środowisko użytkownikówrozwijanie aplikacji, ponieważ często są to te same narzędzia używane lokalnie.Te tradycyjne harmonogramy zadań są wystarczające dla małych i średnich klastrów,ale wraz ze wzrostem rozmiaru klastra obciążenie serwera plików staje się przeszkodą dla wydajności. Równoległe i rozproszone systemy plików (patrz następna sekcja) mogą pomóc w rozwiązaniu tego problemu w przypadku dużej skali. Alternatywnie, gdy dostęp do plików o niskim opóźnieniu nie jest wymagany, można wykorzystać pamięć w chmurze, która zapewnia równy dostęp do obiektu za pomocą API lub przez gcsfuse,gdzie wymagana jest kompatybilność z POSIX.

wreszcie, Google Cloud zawiera prostą usługę do planowania zadań opartych na aDocker na silniku obliczeniowym dla obciążeń o dużej przepustowości: API Cloud Life SciencesPipelines.Ta usługa wymaga rozłożenia zadania na zadania, zarządzania zależnościami między zadaniami i zarządzania cyklem życia zadania. Projekt open source DSUB zapewnia narzędzie wiersza poleceń do uruchamiania zadań wsadowych i wspiera API Cloud Life Sciences Pipelines.

Pamięć Masowa

większość aplikacji HPC wymaga rozwiązania pamięci masowej afile obsługującego interfejs API POSIX. W przypadku mniejszych klastrów FileStore zapewnia zarządzaną przez Google usługę przechowywania plików NFS. Jednak w przypadku większych klastrów Wejście/Wyjście aplikacji może stać się wąskim gardłem wydajności.Skalowanie i równoległe systemy plików, takie jakelastifile (przejęte przez Google), Lustre,orQuobyte, pomagają skalować do dużych klastrów (lub nawet dużych mniejszych klastrów We/Wy).

alternatywnie, gdy dostęp do plików o niskim opóźnieniu nie jest wymagany, można wykorzystać pamięć w chmurze, która zapewnia równy dostęp do obiektu za pomocą API lub poprzez gcsfuse,gdzie wymagana jest zgodność z POSIX.

możliwości przetwarzania klastrów w chmurze

istnieje wiele powodów, dla których należy uruchamiać klastry obliczeniowe w chmurze:

  • czas na rozwiązanie. Uruchomienie klastra jakości produkcyjnej w chmurze zajmuje tylko kilka minut, od małego 10-węzłowego klastra z setkami dostępnych rdzeni, do dużych klastrów ze stu tysiącami lub więcej rdzeni. Natomiast budowa nowych klastrów na miejscu może potrwać miesiące, zanim zacznie działać. Nawet jeśli klastry lokalne są dostępne, zwykle mają wysokie wykorzystanie i długi czas oczekiwania w kolejce – czasami godziny lub dni-przed zaplanowanym uruchomieniem zadań. Zamiast tego możesz tworzyć własne klastry w chmurze, używać ich do swoich obciążeń i definiować klastry po zakończeniu analizy.

  • niższy całkowity koszt posiadania. Google Cloud nie tylko skraca czas rozwiązania, ale może również obniżyć całkowity koszt uruchomienia dzięki wykorzystaniu przestarzałych maszyn wirtualnych, długoterminowym rabatom na użytkowanie i dynamicznemu skalowaniu. Możesz dodawać węzły, gdy zadania są w kolejce i usuwać je, gdy nie są potrzebne.

  • wsparcie współpracy. W wielu sytuacjach analiza obliczeniowa jestrozwijana we współpracy z różnymi ludźmi w wielu organizacjach. Google Cloud zapewnia narzędzia do zarządzania projektami i dostępem, aby umożliwić kontrolowany dostęp do danych i narzędzi analitycznych. Autoryzowani użytkownicy mogą korzystać z tych samych aplikacji, danych i klastrów, aby zapewnić, że wszyscy znajdują się na tej samej stronie bez konieczności kopiowania danych, zarządzania wersjami lub konfiguracji synccluster.

  • zasoby dostosowane do zadań. Ponieważ koszt zadania zależy tylko od całkowitej liczby podstawowych godzin pracy, a nie od liczby wystąpień, uruchomienie klastrów w chmurze umożliwia każdemu zespołowi lub grupie posiadanie własnego dedykowanego klastra. Takie podejście może złagodzić kolejny poważny problem związany z opracowywaniem polityk dotyczących korzystania z wielu grup. Następnie możesz dostosować każdy dedykowany klaster chmury, aby dostosować go do docelowej aplikacji. Lokalne klastry zwykle składają się z jednego uniwersalnego zasobu współdzielonego między różnymi grupami i aplikacjami. W takim środowisku tworzenie i utrzymywanie polityki dzielenia się między grupami jest zwykle skomplikowane.

  • Integracja. Zanim będą mogli uruchomić duże zadania obliczeniowe, naukowcy dosignificant pracy w celu przygotowania zbiorów danych. Po przejściu do chmury, theseresearchers mogą wykorzystać narzędzia big data dostępne w chmurze. Należy również przeanalizować wydajność systemów obliczeniowych. Narzędzia takie jak asBigQuery i Datalab mogą zapewnić znaczące korzyści ponad te dostępne w systemach lokalnych.

typowe lokalne klastry są udostępniane użytkownikom i grupom i obsługują wiele różnych potrzeb aplikacji.
Rysunek 2.Typowe lokalne klastry są udostępniane użytkownikom i grupom i obsługują wiele różnych potrzeb aplikacji. Natomiast po przejściu do Google Cloud użytkownicy mogą dostosować właściwości klastra do potrzeb aplikacji, aby obniżyć koszty i zwiększyć wydajność.

względy architektoniczne

chociaż opisane dotychczas zalety są przekonujące, istnieją jednak pewne wyzwania techniczne, które często utrudniają projekty migracyjne.

  • ruch danych. Zbiory danych przetwarzane przez moduły obliczeniowe klastra zazwyczaj muszą być przechowywane w chmurze przed uruchomieniem zadań.Zarządzanie przepływem danych może być złożone, w zależności od ilości danych i sposobu zarządzania nimi. Narzędzia takie jakavere mogą pomóc, zapewniając warstwę buforowania w chmurze, która automatycznie przenosi dane w razie potrzeby, ale w wielu aplikacjach zbiory danych muszą być ustawiane ręcznie.

  • Dostęp Do Danych. Wiele aplikacji HPC wymaga współdzielonego dostępu do ustawionych katalogów i plików. Sposób zapewnienia tego dostępu może znacząco wpłynąć na wydajność aplikacji. Możesz wykorzystać współdzielone dane przechowywane w pamięci masowej w chmurze, na serwerach NFS, takich jak filestore, lub przy użyciu równoległych systemów plików, jak omówiono w sekcji magazynowanie.

  • Ochrona. W przypadku danych wrażliwych należy zadbać o to, aby dostęp był zawsze autoryzowany, a dane były odpowiednio szyfrowane podczas ponownego przesyłania. Podczas gdy Przechowywanie w chmurze szyfruje dane w spoczynku i podczas przesyłania, możesz zastosować dodatkową warstwę kontroli i zarządzania kluczami w usłudze zarządzania kluczami w chmurze lub samodzielnie. Klucze muszą być pobrane lub zainstalowane na komputerach przed uruchomieniem zadania.

  • opóźnienie między węzłami. W przypadku ściśle powiązanych aplikacji HPC performancemight jest wrażliwy na opóźnienia między węzłami między węzłami w klastrze.Ponieważ Google Cloud zapewnia węzły o rozmiarach do 64 rdzeni, możesz wykonywać 64-kierunkowe zadania równoległe bez przechodzenia przez węzły. W większości przypadków zadania rzędu 1000 rdzeni lub mniejsze działają dość dobrze na niespecjalizowanym sprzęcie sieciowym.

  • zarządzanie licencjami oprogramowania. Wiele komercyjnych aplikacji wymaga serwera alicense, czasami znanego jako serwer kluczy. Niektóre aplikacje mają wbudowany lub zalecany serwer licencyjny, a inne mogą być kompatybilne z istniejącymi ofertami serwerów licencyjnych. Niektóre harmonogramy zadań mogą pomóc w zarządzaniu licencjami i uniemożliwić uruchamianie zadań do czasu udostępnienia licencji.

zalecane architektury i najlepsze praktyki

obliczenia techniczne zapewniają wiele narzędzi i podejść do różnych okoliczności. Przy tak wielu opcjach rozpoczęcie pracy może być trudne.Niezależnie od wyboru oprogramowania do zarządzania klastrami i harmonogramu, istnieje wiele najlepszych praktyk, które można zastosować podczas pracy w Google Cloud.

  • Wykorzystaj w miarę możliwości prewencyjne maszyny wirtualne. Preempowalne maszyny wirtualne są podobne do zwykłych maszyn wirtualnych na silniku obliczeniowym, ale wyceniane do 80% mniej niż zwykłe maszyny wirtualne, z zastrzeżeniem, że można je odzyskać z niewielkim wyprzedzeniem.W przypadku obciążeń o dużej przepustowości harmonogramy zadań wykrywają utratę węzła i traktują ją jako awarię węzła i zmieniają harmonogram wszystkich zadań uruchomionych na tym węźle na innym zasobie. Podczas gdy każda praca wykonana na tych utraconych węzłach może zostać utracona, prawdopodobieństwo utraty węzła jest na tyle niskie, że niższa cena jest warta szansy. Oczekiwany wskaźnik strat wynosi od 5% do 15%. Preemptiblevmy są ograniczone do maksymalnie 24 godzin użytkowania przed ponownym odzyskaniem.
  • wykorzystaj koszt i przepustowość pamięci masowej w chmurze zamiast korzystać z własnego równoległego systemu plików. Pamięć masowa w chmurze zapewnia dużą spójność i skalowalną równoległą wydajność przy niskich kosztach ogólnych.Podczas gdy opóźnienie pierwszego bajtu wynosi około 100 ms, aplikacje, które mogą zmniejszać pamięć masową w chmurze zamiast uruchamiać równoległy serwer plików na silniku komputerowym, są bardziej opłacalne. Dostępna przepustowość między pamięcią masową w chmurze i węzłami obliczeniowymi jest wystarczająca dla wielu aplikacji, niektórzy klienci zgłaszali trwałą łączną przepustowość wynoszącą ponad 23 GB / s.
  • Zbuduj jedną aplikację lub klaster z jedną grupą. Tradycyjne klastry są tworzone przez wielu użytkowników, grupy i aplikacje, co może skutkować wydłużeniem czasu kolejkowania zadań i nieefektywnym wykorzystaniem zasobów przez aplikacje. Ongoogle Cloud, rozważyć utworzenie wielu klastrów dla każdej grupy lubproject, i za pomocą klastrów, które są zoptymalizowane dla poszczególnych aplikacji, które je uruchomić. Niezależnie od tego, czy uruchamiasz jeden klaster przez dwie godziny, czy dwa klastry dla JEDNEJ godziny, całkowity koszt jest taki sam, ale ten drugi wzór może skrócić czas oczekiwania i poprawić wydajność aplikacji.

chociaż każda implementacja jest wyjątkowa, poniższe sekcje zawierają ogólne zalecenia dotyczące trzech typowych przypadków.

niezależny badacz chce przetwarzać swoje dane

poszczególni badacze zazwyczaj starają się uruchomić swoją aplikację w swoich danych i dotrzeć do zakończenia tak szybko, jak to możliwe. Mogą być ekspertami w swoich projektach, ale nie chcą być ekspertami w zarządzaniu klastrami.

Jeśli korzystasz z wysokowydajnych obciążeń, możesz rozważyć użycie API Cloud Life SciencesPipelines.Interfejs API Pipelines wymaga umieszczenia aplikacji w kontenerze dokowanym i umieszczenia plików wejściowych w zasobniku pamięci masowej w chmurze. Następnie możesz użyć narzędzia wiersza poleceń gcloud, aby uruchomić aplikację ponownie z plikami w zasobniku pamięci w chmurze. Wyniki można umieścić w innym zasobniku pamięci masowej w chmurze.

oto przykład polecenia do wykonania zadania, które wykorzystuje amtools do generowania pliku indeksu BAM z wejściowego pliku BAM:

gcloud alpha genomics pipelines run --pipeline_id \--logging gs:///logs \--inputs inputFile=gs://genomics-public-data/gatk-examples/example1/NA12878_chr22.bam \--outputs outputFile=gs:////output/NA12878_chr22.bam.bai

gdzie

  • reprezentuje identyfikator aplikacji w Pipelines API.
  • reprezentuje nazwę Twojego zasobnika pamięci masowej w chmurze.
  • reprezentuje nazwę Twojego katalogu.

nie ma klastra do aprowizacji ani zarządzania nim. Zadania po prostu działają do wyczerpania w maszynie wirtualnej, która jest aprowizowana i zarządzana przez API potoków. Jest to wydajne, ponieważ oblicza rachunki za silnik na sekundę użytkowania.

mały lub średni klaster dla pojedynczego projektu lub zespołu

w projekcie lub zespole członkowie mogą mieć dostęp do klastra prowadzonego przez centralny zespół dla użytkowników w całej firmie lub mogą mieć dostęp do dużych zasobów w zewnętrznym centrum HPC. W obu sytuacjach Rejestratory są profesjonalnie zarządzane i dostępne za pomocą standardowych narzędzi. Na przykład użytkownicy mogą używać ssh do łączenia się z węzłem głównym i używać skryptów Grid Enginesubmit do przesyłania zadań do wykonania.

jednym z podejść takiego zespołu jest użycie ElastiCluster do zdefiniowania środowiska klastrowego, które jest podobne do ich systemów lokalnych. Mogą dostosować program, wybierając typ maszyny silnika obliczeniowego, który najlepiej pasuje do ich aplikacji, i dostosować skrypty startowe, aby zainstalować zależności oprogramowania dla ich aplikacji. Dane wejściowe mogą być nadal przechowywane w pamięci masowej Cloud i można zainstalowaćgcsfuse na węzłach obliczeniowych, aby zamontować dane wejściowe.

te szczegóły są zapisywane w pliku konfiguracyjnym ElastiCluster, a gdy wymagana jest komputeryzacja, klaster jest wywoływany za pomocą narzędzia wiersza poleceń, na przykład:

% elasticluster start astrocluster1

klaster, nazwany w pliku konfiguracyjnym jako astrocluster1, jest aprowizowany i skonfigurowany zgodnie z podanym parametrem. Definicje zawarte w pliku konfiguracyjnym są elastyczne i obsługują różne typy węzłów dla węzłów head i compute,dyski Compute Enginpersistent dla przestrzeni magazynowej, prewencyjne maszyny wirtualne dla obniżenia kosztów dla obciążeń o dużej wydajności oraz układy GPU dla przyspieszonej pracy. Przykład podstawowej konfiguracji dla klastra opartego na Slurm z 10 węzłami obliczeniowymi i 1 węzłem głowy wykorzystującym 32-rdzeniowe maszyny wirtualne oparte na CentOS wyglądałby następująco:

 cloud=google login=google setup=ansible-slurm security_group=default image_id=centos-7-v20170327 flavor=n1-standard-32 frontend_nodes=1 compute_nodes=10 ssh_to=frontend boot_disk_size=50 

wreszcie, gdy w systemie nie są uruchomione żadne zadania, możesz zatrzymać klaster:

% elasticluster stop astrocluster1

w przypadku większych obciążeń można:

  • Spójrz, aby dostosować typy maszyn klastrowych, aby jeszcze bardziej obniżyć koszty.
  • Dodaj zewnętrzny równoległy filtr, aby zwiększyć wydajność w skali.
  • Dodaj możliwości automatycznego skalowania, aby dodawać i usuwać dodatkowe węzły w oparciu o głębię zapytania.

centrum HPC dodawanie pojemności seryjnej do istniejących klastrów

Centralne centra HPC mają ogromną pojemność obliczeniową, ale ponieważ są używane przez wiele grup w firmie lub organizacji, centra HPC mają zwykle konsekwentnie wysokie wykorzystanie i długi czas oczekiwania w kolejce. Są one typowo kupowane z myślą o konkretnej zdolności produkcyjnej, a gdy nieprzewidziane obciążenia robocze zostaną wprowadzone do mieszanki, mogą znacznie spowolnić postęp.

w takich sytuacjach możesz włamać się do środowiska Google Cloud, tymczasowo dołączając węzły obliczeniowe do klastra. Klaster staje się hybrydą, z węzłem głównym i niektórymi węzłami obliczeniowymi działającymi lokalnie, a innymi węzłami obliczeniowymi działającymi w Google Cloud. Po opróżnieniu kolejek zadań dodatkowe węzły mogą zostać zwolnione.

pęknięcie w chmurze jest wygodne z kilku powodów:

  • utrzymuje spójne środowisko użytkownika do przesyłania zadań i zarządzania nimi. Użytkownicy nie wiedzą ani nie dbają o to, czy dodatkowe węzły zostaną dodane.
  • pozwala menedżerom IT na definiowanie zasad, kiedy pęknąć, w celu kontrolowania kosztów.

największym wyzwaniem jest zapewnienie spójnej przestrzeni nazw danych i plików Dla zadań użytkowników w węzłach lokalnych i Google Cloud. Węzły cloudgoogle mogą nie mieć dostępu do tych samych systemów plików wewnętrznych, co węzły lokalne. W tej sytuacji zadania, które odnoszą się do tych plików, nie zostaną uruchomione.

jeśli węzły Google Cloud są skonfigurowane z wewnętrznymi przepustowościami dostępu do plików, zadania będą uruchamiane, ale mogą nie działać w ten sam sposób i mogą tworzyć dodatkową przepustowość sieci i opłaty za wyjście. Ponadto zadania równoległe, które są podzielone na węzły lokalne i chmurowe, mogą również nie działać dobrze z dodanym opóźnieniem między różnymi częściami aplikacji.

w przypadku zadań o wysokiej przepustowości, Korzystanie z HTCondor do włamania do zasobów w chmurze sidestepsmany tych wyzwań. HTCondor obsługuje dynamiczne udostępnianie przy użyciu glideinwms.Ponieważ zadania są przesyłane do kolejki zadań a, mogą one wyzwalać tworzenie węzłów i dodawanie ich do klastra. Kiedy są one dodawane, harmonogram condor przekazuje pliki wejściowe do wyznaczonego węzła i używa tych dodatkowych nodów do wykonywania zadań i opróżniania kolejki.

dowiedz się więcej o przypadkach użycia cluster computing w Google Cloud:

  • Google Cloud, HEPCloud i sondowanie natury natury
  • 220 000 rdzeni i liczenie: profesor matematyki z MIT pobił rekord największej pracy silnika obliczeniowego

Czytaj więcej o:

  • serwery plików na silniku obliczeniowym
  • dokumentacja Cloud Deployment Manager

rozpocznij pracę z klastrem:

  • przetwarzanie wsadowe z Autoskalerem silnika obliczeniowego
  • Tworzenie klastra HTCondor przy użyciu szablonów Cloud Deployment Manager

przykładowe projekty na GitHub:

  • dsub przykład: proste zadania wsadowe za pomocą Dockera
  • przykład ElastiCluster
  • przykłady API rurociągów

  • wypróbuj inne funkcje Google Cloud dla siebie. Spójrz na nasze tutoriale.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.