Klaszterek használata nagyléptékű MŰSZAKI számításokhoz a felhőben

ez a megoldás útmutatást nyújt a nagyléptékű MŰSZAKI Számítástechnika végrehajtásához a Google Cloud szolgáltatásban. Számos technikai számítástechnikai alkalmazás nagy számú egyedi számítási csomópontot igényel, amelyek egy fürtbe vannak összekapcsolva, és koordinálják a számítási és adathozzáférést a csomópontok között.

a klaszterszámítás alapjául szolgáló koncepciók és technológiák az elmúlt évtizedekben fejlődtek, és mára kiforrottá váltak. A szoftvercsomag Google Cloud-ra való átállítása néhány ráncot felvehet, de számos lehetőséget kínál a költségek csökkentésére és a meglévő szűk keresztmetszetek enyhítésére a mai nagy teljesítményű számítástechnikai környezetekben. Ez az útmutató áttekintést nyújt a technológiákról, a kihívásokról és a számítási klaszterek Google Cloud-on történő futtatásához szükséges megoldások jelenlegi kínálatáról.

a Cluster computing összesíti és koordinálja a gépek gyűjteményét, hogy együtt dolgozzanak egy feladat megoldásához. A klasztereknek általában egyetlen fejcsomópontjuk van (néha főcsomópontnak hívják), néhány számítási csomópontjuk, esetleg néhány más speciális csomópontjuk. A fejcsomó a rendszer agya, ésfelelős:

• számítási csomópontok regisztrálása a rendszerbe.
• a csomópontok figyelése.
• feladatok hozzárendelése bizonyos csomópontokhoz.

a felhasználók sok feladatból álló feladatokat küldenek be, ahol a feladat a munka alapvető egysége. Egyes alkalmazások megkövetelik, hogy a feladatokban lévő összes feladat egyszerre fusson, és a feladatok kommunikáljanak egy párhuzamos algoritmus megvalósítása érdekében;egyes feladatok összetett feladatfüggőségekkel rendelkeznek, így bizonyos feladatokat mások előtt kell futtatni; és egyes feladatok bizonyos csomópont-konfigurációkat igényelhetnek a memória, a CPU vagy más adott hardver szempontjából, amelyeken futni kell. A feladatok olyan végrehajtható fájlok, amelyek beolvassák a bemeneti adatokat a tárolóból, feldolgozzák az adatokat az eredmény előállításához, majd a végső eredményeket visszaírják a tárolóba.

a klaszterszámítási munkaterheléseknek két fő típusa van:

• nagy teljesítményű számítástechnika (HPC) – olyan típusú számítástechnika, amely sokmunkás csomópontot használ, szorosan összekapcsolva és egyidejűleg végrehajtva az atask végrehajtását. Ezeknek a gépeknek általában alacsony hálózati késleltetésre van szükségük a hatékony kommunikációhoz. Példa alkalmazások ebben a térben közé időjárás modellezés, számítási folyadékdinamika (CFD), stressz modellezés mérnöki, éselektronikai tervezés.

• high-throughput computing (HTC) – olyan típusú Számítástechnika, ahol az alkalmazásoktöbb olyan feladattal rendelkeznek, amelyeket egymástól függetlenül dolgoznak fel anélkül, hogy az egyes számítási csomópontoknak kommunikálniuk kellene. Néha ezeka munkaterheléseket kínosan párhuzamos vagy kötegelt munkaterhelésnek nevezik. A tipikus példák közé tartozik a Média megjelenítés, átkódolás, genomika, and particle-physics-event simulation and processing. Ha sok egyedi fájlt kell feldolgoznia, akkor ez valószínűleg egy HTC munkaterhelés.

Cluster computing software stack

a cluster computing software stack a következőkből áll:

• rendszer-menedzsment szoftver, amely rendelkezéseket és épít klaszterek.
• ütemezők, amelyek összehangolják a feladat végrehajtását.
• végfelhasználói alkalmazások.

a következő szakaszok a rendszerkezelő szoftvereket és ütemezőket tárgyalják.

rendszerkezelő szoftver

fürtözőszoftvert futtathat közvetlenül a csupasz fém hardveren, akár helyszíni klaszterekkel, akár virtualizált környezetben, mint a cloudenvironments esetében. Hangszerelése több csomópont egy klaszter kézzel időigényes és hiba hajlamos. Speciális fürt-kezelő szoftvereket használhattöbb csomópont és erőforrás rendelkezésre bocsátásához és konfigurálásához, együtt, arepeatable és determinisztikus módon.

a Zürichi Egyetem Nyílt forráskódú lasticluster szoftvere felhőalapú megközelítést biztosít a klaszterkezeléshez, amely támogatja a csomópontok kiépítését számítógépes motor használatával, valamint a csomópontok konfigurálását Ansibleplaybookok segítségével. Az ElastiCluster biztosítja a csomópontokat, és telepít egy alapszoftvercsomagot, beleértve az NFS-t a fájlok kiszolgálásához, a NIS felhasználói fiókok kezelését és az ajob ütemezőt a felhasználói alkalmazások végrehajtásához. ElastiCluster támogatja a különböző schedulers, és akkor használja ki a dobozból, vagy testre, hogy megfeleljen a needsof kis-közepes méretű csapatok.

ha más konfigurációkezelő rendszereket használ a HPC-klaszterek, például a Chef, A Puppet vagy a Terraform kezeléséhez, akkor a rendelkezésre álló eszközök és bővítmények használatával kihasználhatja ezeket a beruházásokat a Google Cloud-ra való áttérés során.

a Google Cloud natív szolgáltatásokat nyújt több csomópontú szoftverrendszerek kiépítéséhez és telepítéséhez. Cloud Deployment Manager lehetővé teszi provisiona készlet felhő erőforrások, beleértve a Compute Engine, Compute Engine által felügyelt példánycsoportok, és a felhő tároló. TheHTCondor bemutató bemutatja, hogyan kell használni Cloud Deployment Manager és felügyelt példány csoportok toprovision és konfigurálja a fürt.

Job schedulers

miután a fürt működőképes, a szoftver, amely kezeli a feladat executionand csomópont allokáció hívják job scheduler (néha a workloadmanager vagy várólista-kezelő). Gyakran előfordul, hogy egy klaszterkezelő jönbeépített Feladatütemező. A feladatütemezők számos lehetőséget kínálnak a feladatok és feladatok kezelésére, például:

• a felhasználók és csoportok közötti feladatprioritások támogatása, amely segít a politika alapú feladatütemezés biztosításában.
• a sikertelen feladatok támogatása a feladatok sorba állításával és átütemezésével.
• tevékenységfüggőségek és erőforrás-szükségletek figyelembevétele a feladatelosztáshoz.
• a fürt méretének méretezése a sorban lévő feladatok számától függően.

számos népszerű kereskedelmi és nyílt forráskódú munkaterhelés-kezelő létezik.Ilyen például a Wisconsini Egyetem, a Slurm a SchedMD-től, az Univa Grid Engine és az LSF Symphony az IBM-től. Mindegyiknek megvan a maga erőssége.

a HTCondor a shared-nothing filozófiával épül fel, és a megosztott erőforrásokon keresztül opportunista módon ütemezi a munkákat egyébként tétlen erőforrásokra. Saját adatmozgást biztosít, ezért nem igényel sharedfile rendszereket. Ennek eredményeként a HTCondor több százezer magra skálázódik, és több zónában és régióban is használhatja. HTCondor már használtahibrid munkaterhelések, ahol a munka megosztott vagy megosztott a helyszíni éscloud-alapú rendszerek. Amint azonban a neve is sugallja, összpontosítnagy teljesítményű, nem szorosan összekapcsolt, párhuzamos munkahelyek.

a Slurm és az Univa Grid Engine egy hagyományosabb HPC klaszter környezetet biztosít,amely támogatja mind a nagy áteresztőképességű, mind a nagy teljesítményű párhuzamos alkalmazásokat. Mindkettő megosztott fájlrendszert feltételez a csomópontok között, ami kiküszöböli az adatok mozgatásának szükségességét. Mindkettő kényelmes és ismerős felhasználói környezetet biztosít az alkalmazások fejlesztéséhez, mivel gyakran ugyanazok az eszközök, amelyeket a helyszínen használnak.Ezek a hagyományos feladatütemezők elegendőek a kis vagy közepes méretű fürtökhöz, de a fürt méretének növekedésével a fájlkiszolgáló terhelése a teljesítmény alsó nyakává válik. A párhuzamos és elosztott fájlrendszerek (lásd a következő részt) nagy léptékben segíthetnek a probléma megoldásában. Alternatív megoldásként, ahol nincs szükség alacsony késleltetésű fileaccess-re, kihasználhatja a felhőalapú tárolást,amely párhuzamos objektum-hozzáférést biztosít az API vagy a keresztülgcsfuse, wherePOSIX kompatibilitás szükséges.

végül a Google Cloud tartalmaz egy egyszerű szolgáltatást az aDocker-alapú feladatok ütemezéséhez a Compute Engine-en a nagy áteresztőképességű munkaterhelésekhez: theCloud Life SciencesPipelines API.Ez a szolgáltatás megköveteli, hogy a feladatot tevékenységekre bontsa, a feladatok közötti függőségeket kezelje, és kezelje a tevékenység életciklusát. A dSub nyílt forráskódú projekt parancssori eszközt biztosít a kötegelt feladatok elindításához éstámogatja a Cloud Life Sciences Pipelines API-t.

Storage

a legtöbb HPC alkalmazás a POSIX API-t támogató fájltárolási megoldást igényel. Kisebb klaszterek esetén a FileStore a Google által kezelt NFS-alapú fájltárolási szolgáltatást nyújtja. Nagyobb klaszterek esetén azonban az alkalmazás I / O teljesítmény szűk keresztmetszetévé válhat.Scale-out és párhuzamos fájlrendszerek, mint plelastifile (a Google által megszerzett), Luster, orQuobyte, segítenek méretezés nagy klaszterek (vagy akár I/O-nehéz kisebb klaszterek).

Alternatív megoldásként, ahol nincs szükség alacsony késleltetésű fileaccess-re, kihasználhatja a felhőalapú tárhelyet,amely párhuzamos objektumhozzáférést biztosít az API vagy a throughgcsfuse használatával, ahol POSIX kompatibilitás szükséges.

fürtszámítási lehetőségek a felhőben

számos oka van a számítási klaszterek felhőben történő futtatásának:

• a megoldás ideje. A termelési minőségű klaszter elindítása a felhőben csak néhány percet vesz igénybe, egy kis 10 csomópontú klasztertől, amely több száz elérhető magot tartalmaz, a nagyszabású klaszterekhez, amelyek százezer vagy többkorúak. Ezzel szemben az új klaszterek helyszíni kiépítése hónapokig is eltarthat, amíg készen állnak a működésre. Még akkor is, ha helyszíni klaszterek állnak rendelkezésre, általában magas kihasználtsággal és hosszú várakozási idővel rendelkeznek-néha órákkal vagy napokkal —a feladatok ütemezése előtt. Ehelyett felépítheti saját fürtjeit a felhőben, felhasználhatja őket a munkaterhelésekhez, és az elemzés befejezése után leállíthatja a fürtöket.

• alacsonyabb teljes tulajdonlási költség. A Google Cloud nem csak a megoldási időt csökkenti, hanem a futtatásonkénti összköltséget is csökkentheti a kihasználható virtuális gépek,a hosszú távú Használati kedvezmények és a dinamikus méretezés révén. Csomópontokat adhat hozzá, amikor a jobsare sorban áll, és eltávolíthatja őket, ha nincs rá szükség.

• együttműködés támogatása. Sok esetben a számítási elemzést különböző emberekkel együttműködve fejlesztik ki több szervezeten keresztül. A Google Cloud projektszintű azonosítást és hozzáférés-kezelő eszközöket biztosít az adatokhoz és az analitikai eszközökhöz való Ellenőrzött hozzáférés lehetővé tételéhez. Az engedélyezett felhasználók hozzáférhetnek ugyanazokhoz az alkalmazásokhoz, adatokhoz és fürtökhöz, így biztosítva, hogy mindenki ugyanazon az oldalon legyen, anélkül, hogy adatokat kellene másolnia, verziókat kellene kezelnie vagy szinkronizálnia kellene a fürtkonfigurációkat.

• feladatokra szabott erőforrások. Mivel egy feladat költsége csak a teljes magórától függ, nem pedig a példányok számától, a felhőben futó klaszterek lehetővé teszik, hogy minden csapat vagy csoport saját dedikált klaszterrel rendelkezzen. Ez a megközelítés enyhítheti a többcsoportos használatra vonatkozó politikák kidolgozásának másik fő fájdalompontját. Ezután testreszabhatja az egyes dedikált felhőfürtöket, hogy beállítsa azokat a célalkalmazáshoz. A helyszíni klaszterek általában egy mindenki számára elérhető erőforrásból állnak, amelyet a különböző csoportok és alkalmazások osztanak meg. Ilyen környezetben a csoportok közötti megosztásra vonatkozó politikák kialakítása és fenntartása általában bonyolult.

• integráció. Mielőtt nagy számítási feladatokat futtatnának, a kutatók jelentős munkát végeznek az adatkészletek előkészítésében. A felhőbe költözés után ezeka kutatók kihasználhatják a felhőben elérhető nagy adateszközöket. A számítási rendszerek kimeneteit is elemezni kell. Az olyan eszközök, mint a BigQuery és a Datalab, jelentős előnyt jelenthetnek a helyszíni rendszerekben elérhető eszközökhöz képest.

építészeti megfontolások

bár az eddig ismertetett előnyök meggyőzőek, vannak olyan technikai kihívások, amelyek gyakran akadályozzák a migrációs projekteket.

• adatok mozgása. A fürt számítógépei által feldolgozott adatkészleteket általában a felhőbe kell állítani a feladatok futtatása előtt.Az adatmozgás kezelése összetett lehet, az adatok mennyiségétől és kezelésétől függően. Az olyan eszközök, mint az avere, segíthetnek egy felhő-gyorsítótárazási réteg biztosításával, amely szükség esetén automatikusan mozgatja az adatokat, de sok alkalmazás esetében az adatkészleteket manuálisan kell szakaszolni.

• Adatokhoz Való Hozzáférés. Számos HPC-alkalmazás megosztott hozzáférést igényel egy készlethezfájlok és könyvtárak. Ez a hozzáférés jelentősen befolyásolhatja az alkalmazás teljesítményét. Kihasználhatja a felhőtárolóban tárolt megosztott adatokat, NFS-kiszolgálókban, például afilestore-ban, vagy párhuzamos fájlrendszereket használhat, amint azt a tárolási szakasz tárgyalja.

• biztonságiak. Az érzékeny adatok esetében gondoskodnia kell arról, hogy a hozzáférés mindig engedélyezett legyen, és az adatok megfelelően titkosítva legyenek a többi és a szállítás során. Míg a Cloud Storage titkosítja az adatokat nyugalmi állapotban és tranzitban, egy további vezérlési és kezelési réteget alkalmazhat akár a felhőalapú kulcskezelő szolgáltatásban, akár önállóan. A kulcsokat le kell tölteni vagy telepíteni kell a számítógéprecsomópontok a feladat futtatása előtt.

• csomópontok közötti késleltetés. Szorosan összekapcsolt HPC-alkalmazások esetén a performanceérzékeny lehet A fürt csomópontjai közötti csomópontok közötti késleltetésre.Mivel a Google Cloud legfeljebb 64 mag méretű csomópontokat biztosít, 64 irányú párhuzamos feladatokat futtathat a csomópontok áthaladása nélkül. A legtöbb esetben az 1000 mag körüli vagy annál kisebb munkák meglehetősen jól teljesítenek a nem szakosodott hálózati hardvereken.

• szoftver licenc menedzsment. Számos kereskedelmi alkalmazás alicense szervert igényel, amelyet néha kulcskiszolgálónak is neveznek. Egyes alkalmazások beépített vagy ajánlott licenckiszolgálóval érkeznek, mások pedig kompatibilisek lehetnek a meglévő licenckiszolgáló-ajánlatokkal. Néhány Feladatütemező segíthet a licenckezelésben, és leállíthatja a feladatok futtatását, amíg a licenc rendelkezésre nem áll.

ajánlott architektúrák és bevált gyakorlatok

a műszaki Számítástechnika számos eszközt és megközelítést kínál a különböző körülményekhez. A sok lehetőség, lehet, hogy nehéz az induláshoz.Függetlenül attól, hogy a klaszterkezelő szoftvert és az ütemezőt választotta-e, számos bevált gyakorlatot követhet, amikor a Google Cloud-on fut.

• tőkeáttétel megelőzhető virtuális gépek, amikor csak lehetséges. A megelőzhető virtuális gépek pont olyanok, mint a rendszeres virtuális gépek a Compute Engine-en, de akár 80% – kal olcsóbbak, mint a rendszeres virtuális gépek, azzal a figyelmeztetéssel, hogy kevés értesítés mellett visszanyerhetők.Nagy áteresztőképességű munkaterhelések esetén a feladatütemezők észlelik a csomópont elvesztését, és csomóponthibaként kezelik, és átütemezik az adott csomóponton futó feladatokat egy másik erőforráson. Míg az elveszett csomópontokon végzett bármilyen munka elveszhet, a csomópontvesztés valószínűsége elég alacsony ahhoz, hogy az alacsonyabb ár megéri az esélyt. A várható veszteség mértéke 5-15%. A preemptiblevm-ek visszanyerése előtt legfeljebb 24 órás használatra korlátozódnak.
• használja ki a felhőalapú tárolás költségeit és sávszélességét a saját párhuzamos fájlrendszer futtatása helyett. A felhőalapú tárolás erős konzisztenciát és skálázható párhuzamos teljesítményt biztosít alacsony összköltséggel.Míg az első bájtos késleltetés magas, nagyjából 100 ms, azok az alkalmazások, amelyek párhuzamos fájlkiszolgáló futtatása helyett felhőalapú tárolást tudnak használni, költséghatékonyabbak. A rendelkezésre álló sávszélesség a felhőtároló és a számítási csomópontok között elegendő a manyapps számára, egyes ügyfelek 23 GB/s feletti összesített sávszélességről számoltak be.
• építsen egy alkalmazást vagy egycsoportos fürtöt. A hagyományos klaszterek több felhasználó, csoport és alkalmazás között oszlanak meg, ami a feladatok hosszú várakozási idejét és az alkalmazások nem hatékony erőforrás-felhasználását eredményezheti. OnGoogle Cloud, fontolja meg több klaszter létrehozását minden csoporthoz vagy projekthez, valamint olyan klaszterek használatát, amelyek optimalizáltak az adott alkalmazásokhoz, amelyek futnak rajtuk. Akár egy fürtöt futtat két órán keresztül, akár két fürtöt egy-egy órára, a teljes költség megegyezik, de ez utóbbi minta csökkentheti a várakozási időket, és javíthatja az alkalmazás teljesítményét.

bár minden megvalósítás egyedi, a következő szakaszok általános ajánlásokat tartalmaznak három gyakori esetre.

független kutató, aki az adataikat kívánja feldolgozni

az egyes kutatók általában arra törekszenek, hogy az alkalmazásukat az adataikon keresztül futtassák, és a lehető leggyorsabban teljesítsék. Lehet, hogy szakértők a sajátjukban, de nem akarnak szakértők lenni a klaszter adminisztrációban vagy a menedzsmentben.

ha nagy áteresztőképességű munkaterheléseket futtat, akkor fontolja meg a cloud Life SciencesPipelines API használatát.A Pipelines API megköveteli, hogy az alkalmazást egy Docker konténerbe helyezzeés helyezze a bemeneti fájlokat egy Felhőtárolóba. Ezt követően isdone, a gcloud parancssori eszközzel elindíthatja az alkalmazásta felhőtároló vödör összes fájlja ellen. Az eredményeket egy másik felhő tároló vödörbe helyezheti.

Íme egy példa egy parancsra egy olyan feladat végrehajtására, amely a samtools segítségével Bam indexfájlt hoz létre egy bemeneti Bam fájlból:

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

ahol

• az alkalmazás azonosítóját képviseli a Pipelines API-ban.A
• a felhőalapú tároló vödör nevét jelenti.A
• a könyvtár nevét jelenti.

nincs klaszter, amelyet biztosítani vagy kezelni kell. A feladatok egyszerűen a befejezésig futnak egy olyan virtuális gépben, amelyet a Pipelines API biztosít és kezel. Ez iscost hatékony, mert kiszámítja Motor számlák másodpercenként használat.

kis – és közepes méretű klaszter egyetlen projekthez vagy csapathoz

egy projektben vagy csapatban a tagok hozzáférhetnek az acentral team által működtetett fürthöz a felhasználók számára az egész vállalaton belül, vagy hozzáférhetnek nagyméretű erőforrásokhoz egy telephelyen kívüli HPC-központban. Mindkét esetben a clustereket professzionálisan kezelik és szabványos eszközökkel érik el. Például a felhasználók assh használatával csatlakozhatnak egy head csomóponthoz, és a Grid Engine submit parancsfájlokkal küldhetnek el feladatokat végrehajtásra.

egy ilyen csapat egyik megközelítése az ElastiCluster használata a helyszíni rendszereikhez hasonló klaszterkörnyezet meghatározásához. Testreszabhatják a Cluster-t azáltal, hogy kiválasztják az alkalmazásuk számára legmegfelelőbb számítási motor géptípust, valamint testreszabhatják az indítási parancsfájlokat az alkalmazásuk szoftverfüggőségeinek telepítéséhez. A bemeneti adatok továbbra is beállíthatók a felhőalapú tároláshoz, és telepítheti agcsfuse értéket a számítási csomópontokra a bemeneti adatok csatlakoztatásához.

ezek a részletek az ElastiCluster konfigurációs fájlban kerülnek rögzítésre, és amikor számításra van szükség, egy fürt jelenik meg a parancssori eszköz segítségével, például:

% elasticluster start astrocluster1

a konfigurációs fájlban astrocluster1 nevű fürt a megadott módon van kiépítve és konfigurálva. A konfigurációs fájl definíciói rugalmasak,és különböző csomóponttípusokat támogatnak a head és a compute csomópontokhoz, a compute Enginepersistent lemezeket a scratch space-hez, az előrevetíthető virtuális gépeket a nagyteljesítményű munkaterhelések költségeinek csökkentése érdekében, valamint a GPU-kat a gyorsított működéshez. Egy példa a Basicconfiguration egy Slurm-alapú klaszter 10 számítási csomópontok és 1 head nodeusing 32 magos virtuális gépek alapján CentOS a következőképpen néz ki:

 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 

végül, ha nem fut több feladat a rendszerben, leállíthatja a fürtöt:

% elasticluster stop astrocluster1

nagyobb munkaterhelés esetén:

• nézze meg a fürtgép típusok testreszabását a költségek további csökkentése érdekében.
• adjon hozzá egy külső párhuzamos filert a méretarányos teljesítmény növeléséhez.
• automatikus méretezési képességek hozzáadása további csomópontok hozzáadásához és eltávolításához a sorrend mélysége alapján.

HPC center burst kapacitás hozzáadása a meglévő klaszterekhez

a központi HPC központok óriási számítási kapacitással rendelkeznek, de mivel a vállalat vagy szervezet számos csoportja használja őket, a HPC központok általában tartósan magas kihasználtsággal és hosszú várakozási idővel rendelkeznek. Jellemzően egy adott termelési kapacitást szem előtt tartva vásárolják meg őket, és ha előre nem látható munkaterhelés kerül a keverékbe, jelentősen lelassíthatják az előrehaladást.

ezekben a helyzetekben a számítási csomópontok ideiglenes hozzáadásával a fürthöz betörhet a Google Cloud környezetbe. A fürt hibriddé válik,a head csomópont és néhány számítási csomópont a helyszínen fut, más számítógépes csomópontok pedig a Google Cloud-on futnak. Amikor a feladatsorokat leeresztették, aTovábbi csomópontok felszabadíthatók.

a felhőbe való feltörés néhány okból kényelmes:

• konzisztens felhasználói környezetet tart fenn a job submission andmanagement számára. A felhasználók nem tudják, vagy nem érdekli, ha további csomópontok kerülnek hozzáadásra.
• ez lehetővé teszi az informatikai vezetők számára, hogy meghatározzák a kitörés idejét a költségek ellenőrzése érdekében.

a legnagyobb kihívás a konzisztens adat-és fájlnévtér biztosítása a felhasználói feladatok számára a helyszíni és a Google Cloud csomópontokon keresztül. Előfordulhat, hogy a Google Cloud csomópontjai nem férnek hozzá ugyanazokhoz a belső fájlrendszerekhez, mint a helyszíni csomópontok. Ebben a helyzetben a hivatkozó feladatokezek a fájlok nem fognak futni.

ha a Google Cloud csomópontok belső fájlelérési engedélyekkel vannak konfigurálva, akkor a feladatok futni fognak, de előfordulhat, hogy nem ugyanúgy működnek, és további hálózati sávszélességet és kilépési díjakat hozhatnak létre. Ezenkívül előfordulhat, hogy a helyszíni és felhőcsomópontokra osztott párhuzamos feladatok nem teljesítenek jól az alkalmazás különböző részei közötti hozzáadott késleltetéssel.

nagy áteresztőképességű feladatokhoz a HTCondor használatával a felhőalapú erőforrásokba való betörés sok ilyen kihívást kikerül. A HTCondor támogatja a dinamikus kiépítést a glideinwms használatával.Mivel a jobok be vannak küldve az a job várólistába, kiválthatják a fürtbe kerülő és hozzáadott csomópontokat. Amikor hozzáadják őket, a condor schedulerátirányítja a bemeneti fájlokat a kijelölt csomópontra, és ezeket a további csomópontokat használja a feladatok végrehajtásához és a várólista leeresztéséhez.

További információ a cluster computing Használati eseteiről a Google Cloud szolgáltatásban:

• Google Cloud, HEPCloud, és a természet természetének vizsgálata
• 220 000 mag és számlálás: MIT math professor breaks record for largestever Compute Engine job

További információ:

• fájlkiszolgálók a számítási motoron
• Cloud Deployment Manager dokumentáció

kezdje el a fürt használatát:

• kötegelt feldolgozás a Compute Engine Autoscaler segítségével
• HTCondor fürt létrehozása Cloud Deployment Manager sablonok használatával

példa projektekre a Githubon:

• dsub példa: egyszerű kötegelt feladatok Dockerrel
• ElastiCluster példa

• csővezetékek API példák

• próbálja ki magának a Google Cloud egyéb funkcióit. Vess egy pillantást az oktatóanyagainkra.