{"id":89872,"date":"2020-07-27T01:42:19","date_gmt":"2020-07-26T23:42:19","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/raspredelyonnye-subd-dlya-enterprajza"},"modified":"2020-07-27T01:42:19","modified_gmt":"2020-07-26T23:42:19","slug":"raspredelyonnye-subd-dlya-enterprajza","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/raspredelyonnye-subd-dlya-enterprajza","title":{"rendered":"Distribuerte databasesystemer for enterprise","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

CAP-teoremet er en hj\u00f8rnesten i teorien om distribuerte systemer. Selvsagt, debatten rundt den tar aldri slutt: verken definisjonene er kanoniske, eller finnes det et strengt bevis... Likevel, st\u00e5ende fast p\u00e5 posisjoner basert p\u00e5 sunn fornuft™, forst\u00e5r vi intuitivt at teoremet er sant.<\/p>\n

\"Distribuerte
\n
\nDet eneste som ikke er \u00e5penbart, er betydningen av bokstaven \u00abP\u00bb. N\u00e5r en klynge splittes, bestemmer den \u2013 om den skal ikke svare f\u00f8r det er oppn\u00e5dd kvorum, eller om den skal gi de dataene den har. Avhengig av resultatene av dette valget klassifiseres systemet enten som CP eller AP. Cassandra, for eksempel, kan oppf\u00f8re seg b\u00e5de slik og slik, avhengig ikke engang av klyngeinnstillingene, men av spesifikasjonene til hver enkelt foresp\u00f8rsel. Men hvis systemet ikke er \u00abP\u00bb, og det har delt seg, hva skjer da?<\/p>\n

Svaret p\u00e5 dette sp\u00f8rsm\u00e5let er noe uventet: en CA-klynge kan ikke splitte.
\nHva slags klynge er dette som ikke kan splitte?
\n<\/a><\/noindex>
\nEt uunng\u00e5elig kjennetegn ved en slik klynge er et felles datalagringssystem. I det overveldende flertallet av tilfellene betyr dette tilkobling via SAN, noe som begrenser bruken av CA-l\u00f8sninger til store selskaper som kan opprettholde SAN-infrastruktur. For at flere servere<\/a> kan jobbe med de samme dataene, er en klyngefilessystem n\u00f8dvendig. Slike filessystemer finnes i portef\u00f8ljene til HPE (CFS), Veritas (VxCFS) og IBM (GPFS). <\/p>\n

Oracle RAC<\/h4>\n

\nAlternativet Real Application Cluster dukket f\u00f8rst opp i 2001 med utgivelsen av Oracle 9i. I en slik klynge jobber flere instanser serveren<\/a> med samme database.
\nOracle kan jobbe b\u00e5de med klyngefilessystem og med sin egen l\u00f8sning \u2013 ASM, Automatic Storage Management.<\/p>\n

Hver instans f\u00f8rer sin egen logg. En transaksjon blir utf\u00f8rt og registrert av \u00e9n instans. Ved feil p\u00e5 en instans leser en av de overlevende nodene i klyngen (instansene) loggen dens og gjenoppretter de tapte dataene \u2013 dette sikrer tilgjengelighet.<\/p>\n

Alle instanser st\u00f8tter sin egen cache, og de samme sidene (blokkene) kan befinne seg samtidig i cachen til flere instanser. Dessuten, hvis en instans trenger en side, og den finnes i cachen til en annen instans, kan den hente den fra \u00abnaboen\u00bb ved hjelp av mekanismen cache fusion, i stedet for \u00e5 lese fra disken.<\/p>\n

\"Distribuerte
\n
\nMen hva skjer hvis en av instansene trenger \u00e5 endre dataene?<\/p>\n

S\u00e6regenheten til Oracle er at det ikke finnes noen dedikert l\u00e5setjeneste: hvis serveren \u00f8nsker \u00e5 l\u00e5se en rad, blir informasjon om l\u00e5sen plassert direkte p\u00e5 den siden av minnet hvor den l\u00e5ste raden ligger. Takket v\u00e6re denne tiln\u00e6rmingen er Oracle en mester i ytelse blant monolittiske databaser: l\u00e5setjenesten blir aldri en flaskehals. Men i en klyngekonfigurasjon kan en slik arkitektur f\u00f8re til intensiv nettverksutveksling og gjensidige l\u00e5ser.<\/p>\n

S\u00e5 snart en rad blir l\u00e5st, varsler instansen alle de andre instansene om at siden som inneholder denne raden, er blitt tatt i monopolmodus. Hvis en annen instans trenger \u00e5 endre raden p\u00e5 den samme siden, m\u00e5 den vente til endringene p\u00e5 siden er blitt bekreftet, det vil si at informasjonen om endringen ikke er blitt skrevet til loggen p\u00e5 disken (transaksjonen kan imidlertid fortsette). Det kan ogs\u00e5 skje at siden ble endret sekvensielt av flere instanser, og n\u00e5r siden skrives til disken, m\u00e5 man finne ut hvem som har den gjeldende versjonen av siden.<\/p>\n

Uforutsigbare oppdateringer av de samme sidene gjennom forskjellige RAC-noder f\u00f8rer til en dramatisk reduksjon i databasens ytelse \u2013 til og med s\u00e5 mye at ytelsen til klyngen kan v\u00e6re lavere enn ytelsen til en enkelt instans.<\/p>\n

Riktig bruk av Oracle RAC er fysisk deling av data (for eksempel ved hjelp av mekanismen for partisjonerte tabeller) og tilgang til hvert sett med partisjoner gjennom en dedikert node. Hovedform\u00e5let med RAC har blitt ikke horisontal skalerbarhet, men \u00e5 sikre feilfri drift.<\/p>\n

Hvis en node slutter \u00e5 svare p\u00e5 heartbeat, starter den noden som oppdager dette f\u00f8rst, en stemmeprosess p\u00e5 disken. Hvis den tapte noden heller ikke registrerer seg her, tar en av nodene over ansvaret for datagjenopprettelse:<\/p>\n