Použití klastrů pro rozsáhlé technické výpočty v cloudu

toto řešení poskytuje pokyny pro provádění rozsáhlých technických výpočtů v cloudu Google. Mnoho technických výpočetních aplikací vyžadujevelký počet jednotlivých výpočetních uzlů, spojených dohromady do clusteru a koordinace výpočtu a přístupu k datům napříč uzly.

koncepty a technologie základní cluster computing vyvinula v posledních několika desetiletích, a jsou nyní zralé a proudu. Migrace softwarestack Google Cloud můžete přidat pár vrásek, ale také nabízí řadu ofopportunities snížit náklady a zmírnit stávající překážky v dnes zaměřuje-performance computing prostředí. Tato příručka poskytuje přehled technologií, výzvy, a aktuální úroda řešení pro runningcomputational clusterů na Google Cloud.

Cluster computing agreguje a koordinuje sbírku strojů, které mají společně vyřešit úkol. Klastry mají obvykle jeden uzel hlavy (někdy nazývaný hlavní uzel), určitý počet výpočetních uzlů a možná několik dalších speciálních uzlů. Uzel hlavy je mozkem systému a jeodpovědný za:

  • registrace výpočetních uzlů do systému.
  • monitorování uzlů.
  • přidělování úloh konkrétním uzlům.
cluster se skládá z uzlu hlavy a sady výpočetních uzlů.
Obrázek 1. Cluster se skládá z uzlu hlavy a sady výpočetních uzlů. Uživatelé interagují s uzlem hlavy, který pak koordinuje práci do výpočetních uzlů.

uživatelé zadávají úlohy, které se skládají z mnoha úkolů, kde úkol je základní jednotkou práce. Některé aplikace vyžadují, aby všechny úkoly v práci runconcurrently a nechat úkoly, komunikovat implementovat paralelní algoritmus;některé úlohy mají komplexní sadu závislosti úkolu tak, že konkrétní tasksmust být spuštěn před ostatními; a některé úkoly mohou vyžadovat zvláštní nodeconfigurations pokud jde o paměť, Cpu, nebo jiné konkrétní hardware na to má spustit. Úkoly jsou spustitelné soubory, které číst vstupní data ze skladu, proces, data produkovat výsledek, a pak napsat konečné výsledky zpět do skladu.

Existují dva hlavní typy cluster computing pracovní vytížení:

  • High-performance computing (HPC) — typ výpočetní techniky, která se používá manyworker uzly, pevně spojený, a vykonávajícího současně dosáhnout atask. Tyto stroje obvykle potřebují nízkou latenci sítě pro efektivní komunikaci. Příklady aplikací v tomto prostoru zahrnují modelování počasí, výpočetní dynamiku tekutin (CFD), modelování napětí ve strojírenství a návrh elektroniky.

  • High-throughput computing (HTC) — typ výpočtu, kde appshave více úkolů, které jsou zpracovány nezávisle na sobě, bez nutné pro jednotlivé výpočetní uzly komunikovat. Někdy se tyto pracovní zátěže nazývají trapně paralelní nebo dávkové pracovní zátěže. Mezi typické příklady patří Vykreslování médií, překódování, genomika, a simulace a zpracování událostí z fyziky článků. Pokud potřebujete zpracovat spoustu jednotlivých souborů, je to pravděpodobně pracovní zátěž HTC.

Cluster computing software stack

cluster computing softwarový balík se skládá z:

  • Systém-software pro správu, která ustanovení a vytváří shluky.
  • plánovače, které organizují provádění úloh.
  • aplikace pro koncové uživatele.

následující části pojednávají o softwaru pro správu systému a plánovačích.

software pro správu Systému

můžete spustit software clusteru buď přímo na holém hardware, aswith v prostorách seskupení, nebo ve virtualizovaných prostředích, jako s cloudenvironments. Ruční uspořádání více uzlů v klastru je časově náročné a náchylné k chybám. Můžete použít specializovaný software pro správu klastrů a konfigurovat více uzlů a zdrojů společně, a to opakovaně a deterministicky.

otevřít sourceElastiCluster software z University of Zurich nabízí cloud-nativní přístup tocluster řízení, s podporou pro provisioning uzly, usingCompute Motoru a konfigurace uzlů pomocí sady Ansibleplaybooks. ElastiCluster ustanovení uzly a nainstaluje základní softwarestack, včetně NFS pro soubor slouží, NIS správa uživatelských účtů, a job scheduler pro spouštění uživatelských aplikací. ElastiCluster podporuje celou řaduschedulers, a můžete jej použít po vybalení z krabice nebo jej přizpůsobit tak, aby vyhovoval potřebám malých až středně velkých týmů.

Pokud ke správě klastrů HPC používáte jiné systémy správy konfigurace, například Chef, Puppet nebo Terraform, můžete tyto investice využít při migraci do cloudu Google pomocí dostupných nástrojů a pluginů.

Google Cloud poskytuje nativní služby pro zajišťování a nasazovánívíce-uzlové softwarové systémy. Cloud Deployment Manager umožňuje poskytnutísoubor cloudových zdrojů, včetně Compute Engine, Compute Enginemanaged instance skupin A Cloud Storage. TheHTCondor výukový program vám ukáže, jak používat Cloud Deployment Manager a spravované skupiny instancí toprovision a konfigurovat cluster.

Práce plánovače

Po clusteru je v provozu, software, který spravuje úkol executionand uzlu rozdělení se nazývá plánovač (někdy se nazývá workloadmanager nebo správce fronty). Správce klastrů často přichází s vestavěným plánovačem úloh. Plánovače úloh poskytují celou řadu funkcí, které pomáhajířízení pracovních míst a úkolů, jako například:

  • podpora priorit práce mezi uživateli a skupinami, což pomáhá providepolicy-based plánování úloh.
  • podpora neúspěšných úkolů zařazením do fronty a přeplánováním úkolů.
  • zohlednění závislostí úkolů a potřeb zdrojů pro přidělování úkolů.
  • škálování velikosti clusteru v závislosti na počtu úloh ve frontě.

existuje celá řada populárních komerčních a open source manažerů pracovní zátěže.Příklady zahrnujíhtcondor z University of Wisconsin, Slurm z SchedMD, Univa Grid Engine a LSF Symphony od IBM. Každý má své silné stránky.

HTCondor je postaven s sdílené-nic filozofie a je usedacross sdílené zdroje oportunisticky plán pracovních míst na jinak idleresources. Poskytuje vlastní pohyb dat, a proto nevyžaduje žádné systémy sdílených souborů. Výsledkem je, že HTCondor měří stovky tisíc jader amůžete jej použít ve více zónách a regionech. HTCondor byl použit prohybridní pracovní zatížení, kde je práce sdílena nebo rozdělena mezi místní a cloudové systémy. Nicméně, jak naznačuje jeho název, je zaměřenvysoce výkonné úlohy, ne těsně spojené, paralelní úlohy.

Slurm a Univa Grid Engine poskytují tradičnější prostředí HPC clusteru, podporující jak vysoce výkonné, tak vysoce výkonné paralelní aplikace. Oba předpokládají sdílený souborový systém napříč uzly, což eliminuje potřebu přesunout data. Oba poskytují pohodlné a známé uživatelské prostředí provývoj aplikací, protože jsou často stejnými nástroji používanými v prostorách.Tyto tradiční Plánovače úloh jsou dostatečné pro malé až středně velké klastry, ale jak se velikost clusteru zvětšuje, zatížení souborového serveru se stáváobottleneck pro výkon. Paralelní a distribuované souborové systémy (viz další část) mohoupomoci s tímto problémem ve vysokém měřítku. Případně, kde je nízké latence fileaccess není nutné, můžete využít Cloud Storage, která providesparallel přístupu k objektu pomocí API nebo throughgcsfuse,wherePOSIX kompatibilita je nutná.

a konečně, Google Cloud obsahuje jednoduchou službu pro plánování aDocker-based úkol na Compute Engine pro vysoce výkonné pracovní zátěže: theCloud Life SciencesPipelines API.Tato služba vyžaduje, abyste se rozkládají na práci do úkolů,správu závislostí napříč úkoly, a spravovat úlohy životního cyklu. Thedsub open source projekt poskytuje nástroj příkazového řádku pro spuštění dávkové úlohy andpodporuje Cloud Life Sciences Pipelines API.

úložiště

většina aplikací HPC vyžaduje řešení pro ukládání souborů, které podporuje rozhraní POSIX API. Pro menší klastry poskytuje FileStore službu ukládání souborů založenou na NFS spravované společností Google. Pro větší klastry se však I / o aplikace může stát překážkou výkonu.Scale-out a paralelní souborové systémy, jako jeelastifile (získané společností Google), Lustre, orQuobyte, pomáhají škálovat na velké klastry(nebo dokonce I / o-těžké menší klastry).

Případně, kde je nízké latence fileaccess není nutné, můžete využít Cloud Storage, která providesparallel přístupu k objektu pomocí API nebo throughgcsfuse,kde POSIX kompatibilita je nutná.

Příležitosti pro cluster computing v oblaku

Existuje mnoho důvodů, proč běžet výpočetní clustery v cloudu:

  • Čas na řešení. Zahájení výroby-kvalitní clusteru v cloudtakes jen pár minut, od malých 10-uzlu clusteru souprav se stovkami jader, rozsáhlé clustery se stovkami tisíc nebo morecores. Naproti tomu budování nových klastrů v areálu může trvat měsíce, než bude možné je zprovoznit. I když jsou k dispozici místní klastry, obvykle mají vysoké využití a dlouhé čekací doby ve frontě —někdy hodiny nebo dny — před plánovaným spuštěním úloh. Místo toho můžete vytvořit vlastní klastry v cloudu, použít je pro vaše pracovní zatížení a po dokončení analýzy klastry ukončit.

  • nižší celkové náklady na vlastnictví. Google Cloud nejen snižuje čas na řešení, ale může také snížit celkové náklady na běh leveragingpreemptible Vm,dlouhodobé užívání slev a dynamické škálování. Můžete přidat uzly, když jobsare ve frontě a odstranit je, když není potřeba.

  • podpora spolupráce. V mnoha situacích je výpočetní analýzavyvinuté ve spolupráci s různými lidmi napříč více organizacemi. Google Cloud poskytuje nástroje pro správu projektů na úrovni projektůidentity a přístupu, které umožňují řízený přístup k datům a analytickým nástrojům. Oprávnění uživatelé canaccess stejné aplikace, data, a klastry, aby zajistily, že všichni ison stejné stránce, aniž by museli kopírovat data, Spravovat verze, nebo konfigurace synccluster.

  • zdroje přizpůsobené úkolům. Protože náklady na práci závisí pouze na celkových základních hodinách, spíše než na počtu instancí, spuštění klastrů v cloudu umožňuje každému týmu nebo skupině mít svůj vlastní vyhrazený klastr. Tento přístup může zmírnit další hlavní bod bolesti při vývoji politik týkajících se používání více skupin. Poté můžete přizpůsobit každý vyhrazený cloud cluster a naladit jej pro cílovou aplikaci. Místní klastry mají tendenci sestávat z univerzálního zdroje sdíleného v různých skupinách a aplikacích. V takovém prostředí, zásady pro sdílení napříč skupinami mají tendenci být složité nastavit a udržovat.

  • integrace. Předtím, než mohou spustit velké výpočetní úlohy, výzkumníci dělat významnou práci na přípravě datových sad. Po přesunu do cloudu mohou tito výzkumní pracovníci využít velké datové nástroje dostupné v cloudu. Výstupy výpočetních systémů musí být také analyzovány. Nástroje jako BigQuery a Datalab mohou poskytnout významné výhody oproti těm, které jsou k dispozici v místních systémech.

typické místní klastry jsou sdíleny mezi uživateli a skupinami a podporují mnoho různých potřeb aplikací.
Obrázek 2.Typické místní klastry jsou sdíleny mezi uživateli a skupinami a podporují mnoho různých potřeb aplikací. Naproti tomu při přechodu na Google Cloud mohou uživatelé přizpůsobit vlastnosti clusteru tak, aby odpovídaly potřebám aplikace, aby se snížily náklady a zvýšil výkon.

Architektonické úvahy

Zatímco výhody popsané tak daleko, jsou přesvědčivé, jsou neverthelesssome technické problémy, které často brání migraci projektů.

  • pohyb dat. Datové sady, které jsou zpracovávány výpočetními uzly klastru, musí být obvykle před spuštěním úloh uspořádány do cloudu.Správa pohybu dat může být složitá v závislosti na objemudata a způsob jejich správy. Nástroje, jako jeavere může pomoci tím, že poskytuje cloud-caching vrstvu, která automaticky přesune datawhen potřeba, ale pro mnoho aplikací datové sady musí být uspořádány ručně.

  • Přístup K Datům. Mnoho aplikací HPC vyžaduje sdílený přístup k souborům a adresářům. Způsob, jakým je tento přístup poskytován, může výrazně ovlivnitvýkon aplikace. Můžete využít sdílená data uložená v cloudovém úložišti, na serverech NFS, jako jefilestore, nebo pomocí paralelních souborových systémů, jak je popsáno v části ukládání.

  • Ochranka. U citlivých dat musíte dbát na to, aby byl přístup vždy autorizován a data byla náležitě šifrována v klidu a při přepravě. Zatímco Cloud Storage šifruje data v klidu a v tranzitu, můžete použít další vrstvu kontrolovat a spravovat klíče buď inCloud Key Management Service,nebo na vlastní pěst. Klíče musí být načteny nebo nainstalovány do počítačů před spuštěním úlohy.

  • inter-Node latence. Pro pevně spojené aplikace HPC, performancemight být citlivý na latenci mezi uzly mezi uzly v clusteru.Protože Google Cloud poskytuje uzly s velikostí až 64 jader, můžetespusťte 64-way paralelní úlohy bez procházení uzlů. Ve většině případů fungují úlohy přibližně 1000 jader nebo menších poměrně dobře na nespecializovaném síťovém hardwaru.

  • Správa softwarových licencí. Mnoho komerčních aplikací vyžaduje alicense server, někdy známý jako klíčový server. Některé aplikace přicházejí s vestavěným nebo doporučeným licenčním serverem a jiné mohou být kompatibilní s existujícími nabídkami licenčních serverů. Některé Plánovače úloh mohou pomocispořádání licencí a zastavení spouštění úloh, dokud není k dispozici licence.

Doporučené architektur a osvědčené postupy

Technické výpočty poskytuje mnoho nástrojů a přístupů pro differentcircumstances. S tolika možnostmi může být obtížné začít.Bez ohledu na výběr softwaru pro správu klastrů a plánovače existujípočet osvědčených postupů, které můžete dodržovat při spuštění v cloudu Google.

  • využijte kdykoli je to možné. Preemptible VM jsou stejně podobnépravidelné VM na Compute Engine, ale cena až o 80% nižší nežpravidelné VM, s upozorněním, že mohou být regenerovány s malým upozorněním.Pro high-propustnost, vytížení, práci plánovače detekovat ztrátu z uzlu a brát to jako selhání uzlu a naplánovat všechny úkoly, běžící na této uzlu na jiný zdroj. Zatímco jakákoli práce na těchto ztracených uzlechmůže být ztracena, pravděpodobnost ztráty uzlu je dostatečně nízká, že nižší cena stojí za šanci. Očekávaná míra ztráty je 5% až 15%. Preemptiblevm jsou omezeny na maximálně 24 hodin používání před opětovným použitím.
  • využijte náklady a šířku pásma cloudového úložiště namísto spuštění vlastního paralelního systému souborů. Cloudové úložiště poskytujesilná konzistence a škálovatelný paralelní výkon s nízkými celkovými náklady.Zatímco latence prvního bajtu je vysoká zhruba na 100 ms, aplikace, které mohou využívat cloudové úložiště místo spuštění paralelního souborového serveru na počítači, jsou nákladově efektivnější. Dostupné bandwidthbetween Cloud Storage a compute uzlů je dostatečná pro manyapps, někteří zákazníci mají hlášeno trvalé celkovou šířku pásma ofover 23 GB/s.
  • Vytvořit single-app nebo single-group clusteru. Tradiční klastry jsou rozděleny mezi více uživatelů, skupin a aplikací, což může mít za následek dlouhé fronty pro úlohy a neefektivní využívání zdrojů aplikacemi. OnGoogle Cloud, zvažte vytvoření více klastrů pro každou skupinu nebo projekt a použití klastrů, které jsou optimalizovány pro konkrétní aplikace, které na ně běží. Ať už provozujete jeden cluster po dobu dvou hodin, nebo dva clustery po dobu jedné hodiny, celkové náklady jsou stejné, ale tento vzorec může snížit čekací doby a zlepšit výkon aplikace.

zatímco každá implementace je jedinečná, následující oddíly poskytují některá obecná doporučení pro tři běžné případy.

nezávislý výzkumník, který chce zpracovat svá data

jednotliví vědci se obvykle snaží spustit svou aplikaci přes svá data a dostat se k dokončení co nejrychleji. Mohou to být experti ve svém oboru, ale nechtějí být experty na administrativu klastrů nebo řízení.

pokud používáte pracovní zatížení s vysokou propustností, můžete zvážit použitícloud Life SciencesPipelines API.Pipelines API vyžaduje, abyste dal svou aplikaci do Docker containerand umístit své vstupní soubory do úložiště cloud kbelíku. Po tomto isdone můžete pomocí nástroje příkazového řádku gcloud spustit aplikaci protikaždý ze souborů v kbelíku cloudového úložiště. Ty můžete umístit do jiného cloudového úložiště.

Tady je příklad příkazu k provedení úkolu, který usesSAMtools generovat BAM index soubor z vstupní soubor s příponou 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

Kde

  • představuje aplikace ID v Potrubí API.
  • představuje název kbelíku cloudového úložiště.
  • představuje název vašeho adresáře.

neexistuje žádný cluster pro poskytování nebo správu. Úkoly jednoduše spustit, dokud nedokončení v VM, který je poskytován a spravován Pipelines API. To iscost efektivní, protože Compute Engine účty za sekundu použití.

Malé – střední clusteru pro jeden projekt nebo tým

V projektu nebo týmu, členové mohou mít přístup do clusteru spustit acentral týmu pro uživatele po celou dobu jejich společnosti, nebo mohou mít přístup tolarge rozsahu zdroje na off-site HPC center. V obou situacích jsou clustery profesionálně spravovány a přístupné pomocí standardních nástrojů. Například uživatelé mohou použít ssh pro připojení k hlavovému uzlu a pomocí skriptů Grid Enginesubmit odeslat úlohy k provedení.

jedním z přístupů pro takový tým je použití Elasticlusteru k definování klastrového prostředí, které je podobné jejich místním systémům. Mohou přizpůsobit thecluster výběrem typu počítače Compute Engine, který je nejvhodnější pro jejich aplikaci, a přizpůsobit spouštěcí skripty pro instalaci softwaredependencies pro jejich aplikaci. Vstupní data mohou být stále představenahlasové úložiště a můžete nainstalovatgcsfuse na výpočetních uzlech pro připojení vstupních dat.

Tyto údaje jsou zaznamenány v ElastiCluster konfigurační soubor, a whencomputation je potřeba, shluk je vychován pomocí nástroje příkazového řádku, například:

% elasticluster start astrocluster1

cluster, pojmenovaný v konfiguračním souboru jako astrocluster1, je provisionedand nakonfigurován, jak je uvedeno. Definice v konfiguračním souboru areflexible a podporovat různé typy uzlů pro vedoucí a výpočetní uzly,Výpočet Enginepersistent disky pro scratch prostoru, preemptible VMs snížit náklady na highthroughput pracovní vytížení, a Gpu pro urychlení operace. Příklad basicconfiguration pro Čermáka na bázi clusteru s 10 výpočetní uzly a 1 hlava nodeusing 32-core virtuální stroje založené na CentOS bude vypadat takto:

 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 

Konečně, když ne více pracovních míst jsou spuštěny v systému, můžete zastavit clusteru:

% elasticluster stop astrocluster1

Pro větší pracovní vytížení, můžete:

  • podívejte se na přizpůsobení typů clusterových strojů, abyste dále snížili náklady.
  • přidejte externí paralelní filer pro zvýšení výkonu v měřítku.
  • přidat automatické škálování schopnosti přidat a odebrat další uzly na základě hloubky thequeue.

HPC centrum přidání praskla kapacita stávajících klastrů

Centrální HPC centra mají obrovskou kapacitu pro výpočetní, ale proto, že areused mnoho skupin, celé společnosti nebo organizace, HPC center mají tendenci haveconsistently vysoké využití, a dlouhé fronty čekací doby. Jsou typicallypurchased s konkrétní výrobní kapacity v mysli, a když unforeseenworkloads jsou předloženy do mixu, mohou pomalu postupovat dolů výrazně.

v těchto situacích můžete vtrhnout do prostředí Google Cloud dočasným přidáním výpočetních uzlů do clusteru. Cluster se stává hybridem, s uzlem hlavy a některými výpočetními uzly běžícími v areálu a dalšími výpočetními uzly běžícími v cloudu Google. Když byly fronty úloh vyčerpány, mohou být uvolněny další uzly.

prasknutí do cloudu je výhodné z několika důvodů:

  • udržuje konzistentní uživatelské prostředí pro podání úlohy a správu. Uživatelé nevědí ani se nestarají o přidání dalších uzlů.
  • umožňuje IT manažerům definovat zásady pro to, kdy prasknout, za účelem kontroly nákladů.

největší výzvou je, že poskytuje konzistentní data a soubor názvů foruser pracovních míst přes on-areálu a Google Cloud uzlů. Cloudové uzly Google nemusí mít přístup ke stejným interním souborovým systémům jako místní uzly. V této situaci jsou úlohy, které odkazujítyto soubory se nezdaří.

Pokud Google Cloud uzly jsou nakonfigurovány s vnitřní souboru-accesspermissions, pak práce bude probíhat, ale nemusí provádět stejným způsobem andmight vytvořit další síťové šířky pásma a výstup poplatky. Kromě toho, paralelní úlohy, které jsou rozděleny na místní a cloudové uzly, také nemusí dobře fungovat s přidanou latencí mezi různými částmi aplikace.

pro vysoce výkonné úlohy, pomocí HTCondor vtrhnout do cloud zdrojů sidestepsmany těchto výzev. HTCondor podporuje dynamické poskytování pomocíglideinwms.Když jsou úlohy odesílány do fronty úloh a, mohou spouštět uzly beingprovisioned a přidány do clusteru. Když jsou přidány, condor schedulerpřenáší vstupní soubory do určeného uzlu a používá tyto další uzlyprovádět úkoly a vypustit frontu.

Přečtěte si více o cluster computingu případy užití na Google Cloud:

  • Google Cloud, HEPCloud, a zkoumání přírody přírody
  • 220,000 jader a počítání: MIT profesor matematiky přestávky záznam pro largestever Compute Engine práci

Přečtěte si více o:

  • File servery, na Compute Engine
  • Cloud Deployment Manager dokumentace

začínáme s clusteru:

  • Dávkové zpracování s Compute Engine Autoscaler
  • Vytvoření HTCondor clusteru pomocí Cloud Deployment Manager šablony

Příklad projektů na GitHub:

  • dsub příklad: Jednoduché dávkové úlohy s Docker
  • ElastiCluster příklad
  • Potrubí API příklady

  • Vyzkoušet jiné služby Google Cloud funkce pro sebe. Podívejte se na ourtutorials.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.