Nuboj estas kiel magia skatolo - vi demandas, kion vi bezonas, kaj la rimedoj simple aperas de nenie. Virtualaj maŝinoj, datumbazoj, reto - ĉio ĉi apartenas nur al vi. Estas aliaj nubaj luantoj, sed en via Universo vi estas la sola reganto. Vi certas, ke vi ĉiam ricevos la postulatajn rimedojn, vi ne konsideras iun ajn kaj vi sendepende determinas, kia estos la reto. Kiel funkcias ĉi tiu magio, kiu faras la nubon elaste asigni rimedojn kaj tute izoli luantojn unu de la alia?
La AWS-nubo estas mega-superkompleksa sistemo, kiu evoluas evolue ekde 2006. Parto de ĉi tiu evoluo okazis Vasilij Pantyukhin - Amazon Web Services Arkitekto. Kiel arkitekto, li ricevas internan rigardon ne nur al la fina rezulto, sed ankaŭ al la defioj venkitaj de AWS. Ju pli granda estas la kompreno pri kiel funkcias la sistemo, des pli granda estas la fido. Sekve, Vasily dividos la sekretojn de AWS-nubaj servoj. Malsupre estas la dezajno de fizikaj AWS-serviloj, elasta datumbaza skaleblo, kutima Amazon-datumbazo kaj metodoj por pliigi la rendimenton de virtualaj maŝinoj samtempe reduktante ilian prezon. Scio pri la arkitekturaj aliroj de Amazon helpos vin uzi AWS-servojn pli efike kaj eble donos al vi novajn ideojn por konstrui viajn proprajn solvojn.
Pri la preleganto: Vasilij Pantyukhin () komencis kiel Administranto de Unikso ĉe .ru-kompanioj, laboris pri granda Sun Microsystem-aparataro dum 6 jaroj, kaj predikis datuman centran mondon ĉe EMC dum 11 jaroj. Ĝi nature evoluis al privataj nuboj, kaj en 2017 moviĝis al publikaj. Nun li provizas teknikajn konsilojn por helpi vivi kaj disvolvi en la AWS-nubo.
Malgarantio: ĉio ĉi sube estas la persona opinio de Vasily kaj eble ne koincidas kun la pozicio de Amazon Web Services. La raporto, sur kiu baziĝas la artikolo, estas disponebla ĉe nia jutuba kanalo.
Kial mi parolas pri la Amazon-aparato?
Mia unua aŭto havis manan transdonon. Ĝi estis bonega pro la sento, ke mi povis stiri la aŭton kaj havi kompletan kontrolon super ĝi. Ankaŭ mi ŝatis, ke mi almenaŭ proksimume komprenis la principon de ĝia funkciado. Nature, mi imagis, ke la strukturo de la skatolo estas sufiĉe primitiva - io kiel rapidumujo sur biciklo.
Ĉio estis bonega, krom unu afero - blokita en trafikŝtopiĝo. Ŝajnas, ke vi sidas kaj faras nenion, sed vi konstante ŝanĝas, premas la kluĉilon, benzinon, bremson - ĝi vere lacigas vin. La problemo de trafikŝtopiĝo estis parte solvita kiam la familio ricevis aŭtomatan aŭton. Veturinte, mi havis tempon pensi pri io kaj aŭskulti aŭdlibron.
Alia mistero aperis en mia vivo, ĉar mi tute ĉesis kompreni kiel funkcias mia aŭtomobilo. Moderna aŭto estas kompleksa aparato. La aŭto adaptiĝas samtempe al dekoj da malsamaj parametroj: premado de la gaso, bremso, veturstilo, vojkvalito. Mi ne plu komprenas kiel ĝi funkcias.
Kiam mi komencis labori pri la Amazon-nubo, ĝi ankaŭ estis mistero por mi. Nur ĉi tiu mistero estas ordo de grandeco pli granda, ĉar estas unu ŝoforo en la aŭto, kaj en AWS estas milionoj da ili. Ĉiuj uzantoj samtempe stiras, premas la gason kaj bremsas. Estas mirinde, ke ili iras kien ili volas — tio estas por mi miraklo! La sistemo aŭtomate adaptiĝas, skalas kaj elaste alĝustigas al ĉiu uzanto, por ke ŝajnu al li, ke li estas sola en ĉi tiu Universo.
La magio foriĝis iom kiam mi poste venis por labori kiel arkitekto ĉe Amazon. Mi vidis kiajn problemojn ni alfrontas, kiel ni solvas ilin, kaj kiel ni disvolvas servojn. Kun kreskanta kompreno pri kiel la sistemo funkcias, pli da fido je la servo aperas. Do mi volas dividi bildon pri tio, kio estas sub la kapuĉo de la AWS-nubo.
Pri kio ni parolu
Mi elektis multfacetan aliron - mi elektis 4 interesajn servojn, pri kiuj indas paroli.
Optimumigo de servilo. Efemeraj nuboj kun fizika enkorpiĝo: fizikaj datumcentroj kie estas fizikaj serviloj, kiuj zumas, varmigas kaj palpebrumas per lumoj.
Senservilaj funkcioj (Lambda) estas verŝajne la plej skalebla servo en la nubo.
Skalado de datumbazoj. Mi rakontos al vi pri kiel ni konstruas niajn proprajn skaleblajn datumbazojn.
Reto-skalado. La lasta parto en kiu mi malfermos la aparaton de nia reto. Ĉi tio estas mirinda afero - ĉiu nuba uzanto kredas, ke li estas sola en la nubo kaj tute ne vidas aliajn luantojn.
Notu. Ĉi tiu artikolo diskutos pri servila optimumigo kaj datumbaza skalo. Ni konsideros retan skalon en la sekva artikolo. Kie estas la senservilaj funkcioj? Aparta transskribo estis publikigita pri ili "" Ĝi parolas pri pluraj malsamaj skalmetodoj, kaj diskutas detale la Firecracker-solvo - simbiozo de la plej bonaj kvalitoj de virtuala maŝino kaj ujoj.
Serviloj
La nubo estas efemera. Sed ĉi tiu efemereco ankoraŭ havas fizikan enkorpiĝon - servilojn. Komence, ilia arkitekturo estis klasika. Norma x86 pecetaro, retkartoj, Linukso, Xen-hiperviziero sur kiu virtualaj maŝinoj funkciis.
En 2012, ĉi tiu arkitekturo sufiĉe bone traktis siajn taskojn. Xen estas bonega hiperviziero, sed ĝi havas unu gravan malavantaĝon. Li havas sufiĉe alta supre por aparato-emulado. Ĉar novaj, pli rapidaj retkartoj aŭ SSD-diskoj fariĝas disponeblaj, ĉi tiu superkosto fariĝas tro alta. Kiel trakti ĉi tiun problemon? Ni decidis labori sur du frontoj samtempe - optimumigi kaj aparataron kaj hipervizieron. La tasko estas tre serioza.
Optimumigo de aparataro kaj hiperviziero
Fari ĉion samtempe kaj fari ĝin bone ne funkcios. Kio estis "bona" ankaŭ estis neklara komence.
Ni decidis preni evoluan aliron - ni ŝanĝas unu gravan elementon de la arkitekturo kaj ĵetas ĝin en produktadon.
Ni paŝas sur ĉiun rastilon, aŭskultas plendojn kaj sugestojn. Tiam ni ŝanĝas alian komponanton. Do, en malgrandaj pliigoj, ni radikale ŝanĝas la tutan arkitekturon surbaze de sugestoj de uzantoj kaj subteno.
La transformo komenciĝis en 2013 kun la plej kompleksa afero - la reto. EN C3 okazoj, speciala Network Accelerator-karto estis aldonita al la norma retkarto. Ĝi estis ligita laŭvorte per mallonga bukla kablo sur la antaŭa panelo. Ĝi ne estas bela, sed ĝi ne estas videbla en la nubo. Sed rekta interago kun aparataro esence plibonigis tremoton kaj retan trairon.
Poste ni decidis plibonigi aliron por bloki datumstokadon EBS - Elastic Block Storage. Ĝi estas kombinaĵo de reto kaj stokado. La malfacileco estas, ke dum Network Accelerator-kartoj ekzistis sur la merkato, ekzistis neniu elekto por simple aĉeti Storage Accelerator aparataron. Do ni turnis nin al ekentrepreno Annapurnaj Laboratorioj, kiu evoluigis specialajn ASIC-fritojn por ni. Ili permesis al malproksimaj EBS-volumoj esti muntitaj kiel NVMe-aparatoj.
En okazoj C4 ni solvis du problemojn. La unua estas, ke ni efektivigis fundamenton por la estonteco de promesplena, sed nova tiutempe, teknologio NVMe. Due, ni signife malŝarĝis la centran procesoron transdonante la prilaboradon de petoj al EBS al nova karto. Ĝi rezultis bone, do nun Annapurna Labs estas parto de Amazon.
Antaŭ novembro 2017, ni rimarkis, ke estas tempo ŝanĝi la hipervizion mem.
La nova hiperviziero estis evoluigita surbaze de modifitaj KVM-kernmoduloj.
Ĝi ebligis fundamente redukti la superkoston de aparata emulado kaj labori rekte kun novaj ASICoj. Ekzemploj C5 estis la unuaj virtualaj maŝinoj kun nova hiperviziero kuranta sub la kapuĉo. Ni nomis lin Nitro.
Evoluo de okazoj sur la templinio.
Ĉiuj novaj specoj de virtualaj maŝinoj, kiuj aperis ekde novembro 2017, funkcias per ĉi tiu hiperviziero. Nudaj Metalaj okazoj ne havas hiperviziilon, sed ili ankaŭ estas nomitaj Nitro, ĉar ili uzas specialecajn Nitro-kartojn.
Dum la venontaj du jaroj, la nombro da specoj de Nitro-kazoj superis kelkajn dekduojn: A1, C5, M5, T3 kaj aliaj.
Specoj de petskriboj.
Kiel modernaj Nitro-maŝinoj funkcias
Ili havas tri ĉefajn komponentojn: la Nitro-hiperviziero (pridiskutita supre), la sekureca blato kaj la Nitro-kartoj.
Sekureca blato integrita rekte en la bazplaton. Ĝi kontrolas multajn gravajn funkciojn, kiel kontroli la ŝarĝon de la gastiga VIN.
Nitro-kartoj - Estas kvar specoj de ili. Ĉiuj ili estas evoluigitaj de Annapurna Labs kaj baziĝas sur oftaj ASICoj. Iuj el iliaj firmvaro ankaŭ estas oftaj.
Kvar specoj de Nitro-kartoj.
Unu el la kartoj estas desegnita por labori kun retoVPC. Ĉi tio estas videbla en virtualaj maŝinoj kiel retkarto ENA - Elasta Reta Adaptilo. Ĝi ankaŭ enkapsuligas trafikon kiam oni transdonas ĝin per fizika reto (pri tio ni parolos en la dua parto de la artikolo), regas la fajroŝirmilon de Sekurecaj Grupoj, kaj respondecas pri vojigo kaj aliaj retaj aferoj.
Elektitaj kartoj funkcias kun bloka stokado EBS kaj diskoj kiuj estas konstruitaj en la servilon. Ili aperas al la gasto virtuala maŝino kiel NVMe-adaptiloj. Ili ankaŭ respondecas pri datuma ĉifrado kaj disko-monitorado.
La sistemo de Nitro-kartoj, hiperviziero kaj sekureca blato estas integrita en SDN-reton aŭ Programaro Difinita Reto. Respondeca pri administrado de ĉi tiu reto (Kontrolaviadilo) regilo karto.
Kompreneble, ni daŭre disvolvas novajn ASIC-ojn. Ekzemple, fine de 2018 ili publikigis la Inferentia blaton, kiu permesas vin labori pli efike kun maŝinlernado taskoj.
Inferentia Machine Learning Processor-peceto.
Skalebla Datumbazo
Tradicia datumbazo havas tavoligitan strukturon. Por ege simpligi, la sekvaj niveloj estas distingitaj.
- SQL — kliento kaj peto-sendantoj laboras pri ĝi.
- Provizoj transakcioj — ĉio estas klara ĉi tie, ACIDO kaj ĉio tio.
- kaŝmemoro, kiu estas provizita de bufro-naĝejoj.
- Enhavo — provizas laboron kun refari protokolojn. En MySQL ili nomiĝas Bin Logs, en PosgreSQL - Write Ahead Logs (WAL).
- Stokado – rekta registrado al disko.
Tavoligita datumbaza strukturo.
Estas malsamaj manieroj grimpi datumbazojn: sharding, Shared Nothing-arkitekturo, komunaj diskoj.
Tamen, ĉiuj tiuj metodoj konservas la saman monolitan datumbazstrukturon. Ĉi tio signife limigas skaladon. Por solvi ĉi tiun problemon, ni evoluigis nian propran datumbazon − Amazona Aŭroro. Ĝi estas kongrua kun MySQL kaj PostgreSQL.
Amazona Aŭroro
La ĉefa arkitektura ideo estas apartigi la stokadon kaj registradnivelojn de la ĉefa datumbazo.
Rigardante antaŭen, mi diros, ke ni ankaŭ sendependigis la kaŝmemornivelon. La arkitekturo ĉesas esti monolito, kaj ni gajnas pliajn gradojn da libereco en skalado de individuaj blokoj.
La registradaj kaj konservaj niveloj estas apartaj de la datumbazo.
Tradicia DBMS skribas datumojn al stokada sistemo en formo de blokoj. Ĉe Amazon Aurora, ni kreis inteligentan stokadon, kiu povas paroli lingvon refari protokolojn. Ene, la stokado igas ŝtipojn en datumblokojn, kontrolas ilian integrecon kaj aŭtomate rezervas.
Ĉi tiu aliro permesas al vi efektivigi tiajn interesajn aferojn kiel klonado. Ĝi funkcias esence pli rapide kaj pli ekonomie pro tio, ke ĝi ne postulas krei kompletan kopion de ĉiuj datumoj.
La stoka tavolo estas efektivigita kiel distribuita sistemo. Ĝi konsistas el tre granda nombro da fizikaj serviloj. Ĉiu refari protokolo estas procesita kaj konservita samtempe ses nodoj. Ĉi tio certigas protekton de datumoj kaj ekvilibron de ŝarĝo.
Legita skalo povas esti atingita uzante taŭgajn kopiojn. Distribuita stokado forigas la bezonon de sinkronigo inter la ĉefa datumbaza petskribo, per kiu ni skribas datumojn, kaj la ceteraj kopioj. Ĝisdataj datumoj garantias esti disponeblaj por ĉiuj kopioj.
La nura problemo estas konservado de malnovaj datumoj sur legitaj kopioj. Sed ĉi tiu problemo estas solvita translokigo de ĉiuj refari protokoloj al kopioj tra la interna reto. Se la protokolo estas en la kaŝmemoro, ĝi estas markita kiel malĝusta kaj anstataŭita. Se ĝi ne estas en la kaŝmemoro, ĝi estas simple forĵetita.
Ni ordigis la stokadon.
Kiel grimpi DBMS-nivelojn
Ĉi tie, horizontala skalado estas multe pli malfacila. Do ni iru laŭ la batita vojo klasika vertikala skalado.
Ni supozu, ke ni havas aplikaĵon, kiu komunikas kun la DBMS per majstra nodo.
Skalante vertikale, ni asignas novan nodon, kiu havos pli da procesoroj kaj memoro.
Poste, ni ŝanĝas la aplikaĵon de la malnova majstra nodo al la nova. Problemoj ekestas.
- Ĉi tio postulos gravan aplikaĵan malfunkcion.
- La nova majstra nodo havos malvarman kaŝmemoron. La rendimento de la datumbazo estos maksimuma nur post kiam la kaŝmemoro varmiĝos.
Kiel plibonigi la situacion? Agordu prokurilon inter la aplikaĵo kaj la majstra nodo.
Kion ĉi tio donos al ni? Nun ĉiuj aplikoj ne bezonas esti mane redirektitaj al la nova nodo. La ŝaltilo povas esti farita sub prokurilo kaj estas esence pli rapida.
Ŝajnas, ke la problemo estas solvita. Sed ne, ni ankoraŭ suferas pro la bezono varmigi la kaŝmemoron. Krome, nova problemo aperis - nun la prokurilo estas ebla punkto de fiasko.
Fina solvo kun Amazon Aurora senservilo
Kiel ni solvis ĉi tiujn problemojn?
Lasis prokurilon. Ĉi tio ne estas aparta kazo, sed tuta distribuita aro de prokuriloj per kiuj aplikaĵoj konektas al la datumbazo. En kazo de fiasko, iu ajn el la nodoj povas esti anstataŭigitaj preskaŭ tuj.
Aldonita naĝejo de varmaj nodoj de diversaj grandecoj. Tial, se necesas asigni novan nodon de pli granda aŭ pli malgranda grandeco, ĝi estas tuj havebla. Ne necesas atendi, ke ĝi ŝargiĝu.
La tuta skala procezo estas kontrolita per speciala monitora sistemo. Monitorado konstante monitoras la staton de la nuna majstra nodo. Se ĝi detektas, ekzemple, ke la procesoroŝarĝo atingis kritikan valoron, ĝi sciigas la aron de varmaj okazoj pri la bezono asigni novan nodon.
Distribuitaj prokuriloj, varmaj kazoj kaj monitorado.
Nodo kun la bezonata potenco estas disponebla. Bufferoj estas kopiitaj al ĝi, kaj la sistemo komencas atendi sekuran momenton por ŝanĝi.
Kutime la momento por ŝanĝi venas sufiĉe rapide. Tiam komunikado inter la prokurilo kaj la malnova majstra nodo estas suspendita, ĉiuj sesioj estas ŝanĝitaj al la nova nodo.
Laboro kun la datumbazo rekomencas.
La grafikaĵo montras, ke la suspendo ja estas tre mallonga. La blua grafikaĵo montras la ŝarĝon, kaj la ruĝaj ŝtupoj montras la skalmomentojn. Baldaŭtempaj trempoj en la blua grafikaĵo estas ĝuste tiu mallonga prokrasto.
Cetere, Amazon Aurora permesas vin tute ŝpari monon kaj malŝalti la datumbazon kiam ĝi ne estas uzata, ekzemple, semajnfine. Post haltigo de la ŝarĝo, la DB iom post iom reduktas sian potencon kaj malŝaltas iom da tempo. Kiam la ŝarĝo revenos, ĝi denove leviĝos glate.
En la sekva parto de la rakonto pri la Amazon-aparato, ni parolos pri reto-skalado. Abonu kaj restu atenta por ke vi ne maltrafu la artikolon.
En Vasilij Pantyukhin donos raporton "" Kiaj dezajnaj ŝablonoj por distribuitaj sistemoj estas uzataj de Amazon-programistoj, kiaj estas la kialoj de servaj misfunkciadoj, kio estas ĉel-bazita arkitekturo, Konstanta Laboro, Shuffle Sharding - ĝi estos interese. Malpli ol monato ĝis la konferenco - . La 24-an de oktobro fina prezaltiĝo.
fonto: www.habr.com