Som nevnt kan DFS-strukturen gjøres feiltolerant. Hver lenke kan dupliseres ved å lage en ny lenke til en lignende nettverksressurs på en annen datamaskin. Som et resultat, hvis én ressurs er utilgjengelig, vil klienter automatisk bli omdirigert til en fungerende datamaskin. Dessuten kan systemet automatisk synkronisere disse ressursene. Hvis dataene endres i mappen med én lenke, vil de bli duplisert i mappen med en annen lenke.

Replikerte ressurser må være plassert i mapper med NTFS 5.0, fordi systemet bruker loggingssystemet til denne filstrukturen for å spore endringer.

Merk Hvis du vil bruke begrensninger på tilgang til dokumenter i DFS-mapper, bør disse innstillingene bare brukes på servermappene (\\<имя_сервера>\ <имя_папки>). Ellers, når du oppretter en DFS-kobling til den nye replikeringsplasseringen, vil mappen arve rettighetene til den overordnede strukturen.

Replikering er ikke aktivert som standard. For å organisere synkroniseringen av data fra flere servere, må du velge de riktige koblingene til ressurser og velge Synkroniser-kommandoen. Når du oppretter replikering, må du spesifisere hvilken ressurs som skal være den primære (master). Når den første replikeringen er fullført, er alle koblinger like: En endring på ett sted vil resultere i en endring i den andre koblingen.

MERK Det finnes flere replikeringsteknologier. Generelt er det nødvendig å ta hensyn til organisasjonens struktur, praksisen med å jobbe med dokumenter, etc. I de fleste tilfeller er det nok å være enig med forslaget fra Replikeringsopprettingsveiviseren.

Ikke alle filer synkroniseres automatisk. Midlertidige filer er ekskludert fra replikering (listen over utvidelser kan sees i innstillingene). Selve filene replikeres først etter at brukeren er ferdig med å jobbe med dem. Med andre ord, hvis en bruker har åpnet en fil og jobber med den i løpet av dagen, vil kopien av filen ved hjelp av den replikerte lenken endres først etter endt arbeid - om kvelden.

Hvis to brukere samtidig jobber med samme fil i forskjellige replikaer, vil systemet løse denne konflikten ved å lagre endringene som ble gjort i filen som ble lagret senere.

Replikering kan brukes til å vedlikeholde kopier av dokumenter på tvers av flere geografisk spredte områder. Dessuten, i de nyeste versjonene av servere, brukes mekanismen for å sende bare endrede blokker, og ikke hele dokumentet, noe som reduserer trafikken mellom noder. Imidlertid er det ofte fornuftig å begrense replikeringstiden til perioder med minimal båndbredde. For å gjøre dette, i tidsplanmenyen, bør du definere de tillatte periodene der datasynkronisering skal utføres.

Replikeringsplanen konfigureres i AD-brukere og datamaskiner-oppgaven. Etter å ha åpnet snapin-modulen, bør du aktivere visning av tilleggsfunksjoner (Vis | Ekstra funksjoner) og finn den nødvendige DFS-roten. Etter å ha åpnet egenskapene på Replikeringssett-fanen, må du klikke på Endre tidsplan-knappen og redigere tidsplanen (fig. 10.2).

Ris. 10.2. Konfigurere DFS-replikeringsplan

ReiserFS

Transaksjoner (journalførte filsystemer)

Vanligvis, for å øke arbeidshastigheten, brukes spesielle mekanismer for caching av lese- og skriveoperasjoner.

Ved å bruke begge typer caching i operativsystemet kan utviklere MYEøke hastigheten på I/O-operasjoner. For eksempel lar caching skriveoperasjoner deg "samle" mange I/O-operasjoner i en enkelt batch med endringer og skrive dem i en eller to disktilganger (til tider med mindre belastning).

Det er imidlertid farlig å lagre uskrevet informasjon til disk i minnet - i tilfelle feil vil informasjon gå tapt og krenkes. logisk struktur filsystem. Å sjekke filsystemet etter en krasj kan ta lang tid. For eksempel tar det 15-20 minutter å sjekke et 8 gigabyte ext2fs-filsystem (testmaskinvare fra 1999).

Derfor bruker de spesielle operasjonslogger - de registrerer informasjon umiddelbart. Hvis det oppstår en feil, utføres en sjekk basert på denne loggen, mens det sikres høy hastighet kontroller og gjenoppretting - i gjennomsnitt ikke mer enn 30 sekunder (for eksempel en 12 GB partisjon, utstyr 2003-2006).

ReiserFS-filsystemet var historisk sett det første for Linux - det støttes av kjernen siden de første versjonene av 2.4.x-grenen og var det eneste utviklet fra bunnen av spesifikt for dette operativsystemet av Hans Reiser. Som i de fleste av disse systemene, logges kun operasjoner på filmetadata her. I tillegg har ReiserFS en unik mulighet optimalisering diskplass okkupert av små filer - de er helt lagret i sine inoder, uten å tildele blokker i dataområdet, og sammen med plassbesparelse bidrar dette også til økt ytelse, siden data og metadata er lagret i umiddelbar nærhet og kan leses av en enkelt I/O-operasjon. En annen funksjon ved ReiserFS er at filhaler på mindre enn én blokk kan pakkes (flismodus). Dette gir omtrent 5 % besparelser i diskplass.

I motsetning til ReiserFS, er ext3fs ikke noe mer enn et journaling-tillegg over de klassiske ext2fs utviklet av selskapet Rød hatt og støttet Linux-kjernen fra 2.4.16. Som en konsekvens av denne opprinnelsen opprettholder den full kompatibilitet med stamfaderen, inkludert på nivået for vedlikeholdsverktøy. En annen fordel er nesten maksimal pålitelighet: ext3fs er et system der det er mulig å logge operasjoner ikke bare med metadata, men også med data.

Ext3fs gir tre driftsmoduser: full journalføring ( fullstendige data journalføring), tilbakeskrivningsjournalføring og standardbestilt. I det første tilfellet blir alle nye data først skrevet til loggfilen og først deretter skrevet til disken. I tilfelle en krasj kan du lese loggen på nytt, og bringe dataene og metadataene til en konsistent tilstand. Denne mekanismen garanterer praktisk talt mot tap av data, men den er den tregeste. I tilbakeskrivingsmodus skrives kun metadataendringer til loggfilen, og den gir ingen garanti for dataintegritet, men den gir den høyeste (innen ext3fs) ytelse. Sekvensiell modus logger også fysisk bare filens metadata, men de tilknyttede datablokkene er logisk gruppert i en enkelt enhet kalt en transaksjon. Og disse blokkene lagres før nye metadata skrives til disk, noe som, selv om det ikke garanterer fullstendig sikkerhet, er veldig gunstig for det.

XFS-filsystemet, i motsetning til de "unge" ReiserFS og ext3fs, har utviklet seg i over ti år - det dukket først opp for Irix 5.3 i 1994. XFS - 64-bit filsystem... Funksjonene til XFS er:

• tildelingsgruppemekanisme- dele en enkelt diskpartisjon i flere like områder med sine egne lister over inoder og ledige blokker for parallellisering av diskoperasjoner;
• logisk logging bare metadataendringer, men med hyppig skylling til disk for å minimere mulige tap i tilfelle feil;
• forsinket tildelingsmekanisme- tildeling av diskplass ved skriving av filer ikke under journalføring, men når de faktisk skylles til disk, som sammen med en økning i ytelse forhindrer fragmentering av diskpartisjonen;
• Access Control List (ACL) og utvidede attributter.

XFS er et veldig balansert filsystem - det er nesten like pålitelig som ext3fs og er like raskt som ReiserFS på de fleste filoperasjoner... Og når man manipulerer med veldig store filer XFS er uovertruffen. Ingen kompatibilitetsproblemer ble notert for det heller.

NTFS er et utvinnbart filsystem. Det garanterer konsistensen av volumdataene ved å bruke standard prosedyre registrering av transaksjoner. Hver I/O-operasjon som endrer en fil på et NTFS-volum, behandles som en transaksjon av filsystemet.

Når en fil endres, registrerer en spesiell filsystemkomponent - loggfiltjenesten - all informasjonen som er nødvendig for å gjenta eller tilbakestille en transaksjon i spesiell fil kalt $ LogFile. Hvis transaksjonen ikke fullføres som normalt, prøver NTFS å avslutte transaksjonen (redo) eller ruller den tilbake. Denne metoden gir den korteste gjenopprettingstiden, men bare systemdata (metadata) gjenopprettes, og brukerdata kan gå tapt.

Distribuerte systemer tilbyr ofte filreplikering (replikering) som en av tjenestene som tilbys til kunder. Replikering er asynkron overføring av dataendringer fra et kildefilsystem til filsystemer som tilhører forskjellige noder i et distribuert filsystem. Det er flere grunner til å tilby denne tjenesten, de viktigste er:

1. Økt pålitelighet på grunn av tilgjengeligheten av uavhengige kopier av hver fil på forskjellige filservere.
2. Lastbalansering på tvers av flere servere.
3. Ved behandling av store datamengder kan det være nyttig å replikere alt til en egen server og analysere det der.

Normalt, hovedproblem relatert til replikering er åpenhet. I hvilken grad bør brukere være klar over at noen filer blir replikert? Bør de spille en rolle i replikeringsprosessen, eller bør replikering være helautomatisk? I noen systemer er brukere fullt ut involvert i denne prosessen, i andre gjør systemet alt uten deres viten. I det siste tilfellet sies systemet å være replikeringsgjennomsiktig.

Det er tre replikeringsalternativer vist i figuren:

a) Nøyaktig filreplikering. Når en prosess oppretter en fil, gjør den det på én spesifikk server, deretter opprettes ytterligere kopier på andre servere etter behov. Hvis katalogserveren tillater flere kopier av filen, da nettverksadresser alle kopier kan assosieres med et filnavn som vist i figuren under, og når navnet er funnet betyr det at alle kopier er funnet. Selv om denne ordningen fungerer, har den mange ulemper, og av disse grunnene bør den ikke brukes i distribuerte systemer.

b) Lazy filreplikering. Her opprettes kun én kopi av hver fil på en server. Senere vil selve serveren automatisk replikere til andre servere uten deltakelse fra en programmerer. Dette systemet bør være raskt nok til å oppdatere alle disse kopiene om nødvendig.

c) Filreplikering ved hjelp av en gruppe. I denne metoden, alt systemanrop WRITE sendes samtidig til alle servere, så kopier lages samtidig som originalen lages.

Det er to grunnleggende forskjeller i bruk av gruppelenker og lat replikering. For det første adresserer lat replikering en enkelt server, ikke en gruppe. For det andre skjer lat replikering i bakgrunn når serveren har litt ledig tid, og med gruppereplikering, opprettes alle kopier samtidig.

Det er et problem med å spore endringer og replikere dem til andre servere. Det er flere kjente algoritmer for å løse dette problemet:

Den første algoritmen, kalt replikering av første kopi, krever at én server utpekes som primærserver. Resten av serverne er sekundære. Når den replikerte filen er endret, sendes endringen til primær server som utfører endringene lokalt og deretter sender endringene til de sekundære serverne.

For å forhindre at primærserveren kan varsle alle sekundære servere om endringer på grunn av en feil, må endringene opprettholdes til vedvarende lagring før primærkopien endres. I dette tilfellet, etter omstart av serveren, er det mulig å sjekke om noen oppdateringer ble utført på tidspunktet for krasj. Ulempen med denne algoritmen er typisk for sentraliserte systemer- redusert pålitelighet.

For å unngå det brukes en metode foreslått av Gifford og kjent som "stemme". Anta at det er n kopier, så bør endringer gjøres i eventuelle W-kopier. Samtidig må serverne som kopiene er lagret på spore serienummer deres versjoner. Når en server utfører en leseoperasjon, sender den en forespørsel til alle R-servere. Hvis R + W> n, inneholder minst én server den nyeste versjonen, som kan identifiseres med maksimalt antall. Denne metoden krever at hver fil har et spesielt nummer kalt "versjon".

En interessant modifikasjon av denne algoritmen er "cast voting"-algoritmen. Lesing er mye mer vanlig enn skriving i de fleste applikasjoner, så R holdes vanligvis liten og W nær N. Men hvis flere servere mislykkes, er det ikke quorum for skriving. Ghost Voting løser dette problemet ved å lage en dummy diskløs server for hver server som svikter eller går offline. Den fiktive serveren deltar ikke i lesequorumet (for det første har den ingen filer), men den kan bli med i skrivequorumet, og den skriver rett og slett til ingensteds filen som er overført til den. Opptaket er bare vellykket når minst én server er ekte.

Når den mislykkede serveren startes på nytt, må den oppnå et lesequorum for gjenkjenning. siste versjon som han kopierer til seg selv før han starter normale operasjoner. Ellers er denne algoritmen lik den viktigste.

Et sett med alternative delinger knyttet til et enkelt logisk DFS-navn kalles et replikasett. Avhengig av forholdene som det distribuerte filsystemet fungerer under, blir replikaene i settet synkronisert ulike metoder... Det distribuerte filsystemet prøver ikke selv å analysere om dataene som ligger på forskjellige replikaer er forskjellige. Identiteten deres må oppnås gjennom tredjeparts midler... Hvis alternative aksjer opprettes i filstruktur med en offline DFS-rot er automatisk replikering ikke mulig. I dette tilfellet må datasynkronisering mellom medlemmer av replikasettet gjøres manuelt. Hvis de alternative delingene er i DFS-domenets rotnavneområde og er plassert på Windows-servere 2000 eller Windows Server 2003, så for dem kan du konfigurere automatisk synkronisering(replikering av) informasjon.

Slik konfigurerer du replikering mellom alternative ressurser (replikater) knyttet til en domenerot eller DFS-koblinger:

Ris. 8.33. Vinduet Konfigurasjonskonfigurasjon for alternative aksjer

2. Ved å klikke på Tilpass-knappen kan du gå til oppsettvinduet for replikeringstopologi, der du kan administrere tilkoblinger mellom servere og deres prioriteringer.
3. Tidsplan-knappen lar deg åpne et vindu der replikeringstiden er angitt. Som standard er replikering tillatt 24/7.
4. Filfilterfeltet viser (gruppe) filnavnene som er ekskludert fra replikeringsprosessen. Ved å klikke på Rediger-knappen kan du endre denne listen.
5. Undermappefilterfeltet viser mapper som ikke er involvert i replikering. Hvis du trenger å deaktivere replikering for enkelte mapper, klikker du på Rediger-knappen og skriver inn de nødvendige navnene.
Etter å ha fullført replikeringskonfigurasjonen, er dataene på felles ressurser inkludert i replikasettet vil periodisk synkroniseres. Som standard er synkroniseringsperioden 15 minutter. Når du har konfigurert replikering, kan du teste den Nåværende tilstand ved å bruke Kontroller status-kommandoen fra kontekstmenyen... Resultatet av kontrollen kan fikse en av tre tilstander:

• Replikeringsprosessen fullførte normalt - grønne hakemerker vises på DFS-koblingsikonet og på replikaikonene (se figur 8.31).
• kopien er utilgjengelig - et kryss vises i en rød sirkel nær kopinavnet (status - Frakoblet) (fig. 8.34);
• noen alternative kopier av koblingen som sjekkes er ikke tilgjengelige - en egenskap vises på DFS-lenkeikonet Utropstegn i en gul trekant.

Jeg bestemte meg for å oppsummere opplevelsen av å bruke denne teknologien litt (i flere deler).

Til hva?

DFS (distribuert Filsystem) - distribuert filsystem, Microsoft-komponent Windows Server brukes til å forenkle tilgang og administrasjon av filer som er fysisk distribuert over et nettverk. Når du bruker den, blir filer distribuert på tvers av servere presentert for brukere som på ett sted. Dette er en tjeneste som lar deg løse flere problemer:

• Gjør det enklere å få tilgang til filer og mapper som er på forskjellige steder ved å forskjellige servere, på forskjellige kontorer. Dette er mest hovedfunksjon DFS. Ved hjelp av den såkalte. Av "roten" tenker ikke brukere på hvor denne eller den dataen er, men skriver bare inn samme navn, for eksempel \\ hq.com \ doc.
• Til tross for en enkelt "root", kan forskjellige eller samme data grupperes ved å bruke flere adresseområder. For eksempel kan banene \\ hq.com \ docs eller \\ hq.com \ branchdocs inneholde både forskjellige og dupliserte data.
• Øk feiltoleransen ved å replikere roten til flere servere, bruke AD som rotlagringssted, og replikere selve dataene mellom forskjellige servere.
• Reduser belastningen på en bestemt filserver ved å distribuere data og tilgang til ofte brukte ressurser på tvers av flere servere.
• Tilrettelegge for sikkerhetskopiering og gjenfinning av data. For eksempel kan en administrator opprette et navneområde \\ hq.com \ backups, som vil inneholde alle nettverkskataloger for sikkerhetskopiering. Og banen i DFS kan spesifiseres til både sikkerhetskopieringsprogrammer og datainnhenting. Når du søker i DFS, trenger du ikke søke etter en fil på hver server separat.

Hvordan?

For å utføre disse oppgavene bruker DFS:

• DFS-N(Navneområde) - DFS-navneområdetjeneste
• DFS-R(replikering) - DFS-replikeringstjeneste.

DFS-N- støttetjeneste virtuell katalogtre som lenker til ekte nettverkskataloger (målkataloger eller mål). Dette er den mest "nyttige" DFS-tjenesten og gir muligheten til å bruke en enkelt rot for å få tilgang til data. DFS-N returnerer til klienten en UNC-kobling til den virkelige nettverksdelingen (\\ servernavn \ nettverkskatalog), brukeren ser rett og slett ikke dette og tenker ikke på hvor filene er. Den returnerte UNC-lenken avhenger av brukerens plassering, og hvis han plutselig flytter til grenen, vil DFS automatisk gi en lenke til den "lokale" serveren.

DFS-navneområdet kan implementeres på to måter:

• Distribuert filsystem med en isolert rot (frittstående);
• Domenebasert filsystem;

Når det gjelder frittstående (jeg legger merke til at dette alternativet også kan være i AD-domenet), utføres tilgang til navneområdet gjennom banen \\ Server_name \ DFS_root, dataene lagres i registeret og støttes bare en navneområde (root), AD er ikke nødvendig.

DFS-R Er en tjeneste som gir datareplikering mellom servere. De. hvis replikering er satt til noen nettverksmappe mellom ServerA og ServerB, så vil tjenesten være med angi intervall replikere data mellom mapper. Til syvende og sist vil alle filer som er endret eller opprettet på ServerA, replikeres til riktig mappe på ServerB (og omvendt). Denne tjenesten forårsaker mest et stort nummer av misforståelser blant nybegynnere. DFS-R kan bare være nyttig i noen få scenarier som:

• Samarbeid med data ved avdeling og hovedkontor.
• Oppretting av kopi av filialens dokumenter på hovedkontoret.

DFS-R-tjenesten er ikke en erstatning backup eller en klynge!!! Derfor, ikke bruk den som sådan, og du vil ikke ha noen problemer med DFS-R. Ikke plasser databaser i replikerte mapper! Du kan imidlertid kombinere mapper fra databasen i én rot.

DFS-R ble opprettet i en tid med treg Internett-tilkoblinger da det var viktig å ikke laste ned kanalen for å ha dokumentasjon og filer fra hovedkontoret i filialene. I tilfelle det samme dokumentet ble åpnet av flere brukere fra forskjellige replikerte lokasjoner, vil -DFS ganske enkelt lagre filen med den nyeste datoen. Alle endringer gjort av den andre brukeren vil bli overskrevet! For rettferdighets skyld bør det legges til at DFS har en mekanisme for å løse konflikter - filen som har tapt i konflikten legges i tjenestemappen, hvorfra den kan gjenopprettes av administrator.

Du kan replikere separate mapper eller hele roten (og til og med hele disker hvis du gjør dem delt). Det er best å ikke replikere roten, da du vil miste funksjonalitet og fleksibilitet. DFS-R er bra for data som ikke endres (PDF-filer, programmer). Eller for feiltoleranse, med én replikeringspartner som opererer i skrivebeskyttet modus. De. hvis hovedfilserveren er nede, vil brukerne kunne åpne dokumenter og jobbe med dem. De vil ikke kunne lagre dokumenter på denne serveren, men arbeidet på kontoret stopper heller ikke.

I neste del skal vi se nærmere på DFS-terminologien.

Distribuert filsystem (DFS) replikeringsteknologi (aka DFS-R, aka DFSR) har eksistert i mange år. Likevel er det mange misoppfatninger om henne i hodet vårt. Så snart det kommer til DFS, sier noen umiddelbart noe sånt, og en tvist begynner: det fungerer ikke, det støttes ikke, det er buggy.

Og som alltid er sannheten i enkelhet: jo mer komplisert scenariet vi lager, jo større er sjansen for å få problemer.

I hovedsak stammer forvirringen fra det faktum at det er to hovedteknologier bak DFS-R: den første er virtuelt navneområde og den andre er replikering.

Virtuelt navneområde

1. Det er veldig praktisk. Flere filballer kan kombineres til et enkelt navnstre. Hvis du trenger å bytte ut serveren eller flytte ballen til et annet sted, endres ingenting for brukerne, og administratoren er praktisk talt fri for bundne hender. I tillegg forenkles organisasjonsprosesser: én enkelt ressurs, én eier, én enkelt ledelsespolicy.

2. Det er pålitelig. DFS rot kan lokaliseres på flere domenekontrollere. Faktisk, på dette tidspunktet, kan DFS betraktes som absolutt udødelig: hvis alle hoveddomenekontrollerne mislykkes, vil ikke bare DFS, men ingenting i det hele tatt fungere.

Replikering

Replikering fungerer ikke bare sammen med DFS, men også uavhengig: ingenting hindrer replikering av informasjon fra en server til en annen eller til flere.

Vanligvis brukes dette scenariet til å samle informasjon fra avdelingskontorer til sentralkontoret: filer pumpes over smale kanaler ved hjelp av BITS, som bruker båndbredde veldig humant.

Det er mange replikeringsscenarier, men å forstå BITS er nøkkelen når du bruker DFS-R-replikering.

Legger til replikering til DFS

1. Mens den virtuelle mappen bare har ett mål (Target), dvs. det er bare én kopi - absolutt alle teknologier støtter arbeid i DFS. Dette inkluderer roaming-profiler, hjemmemapper, frakoblede filer og omdirigeringsmapper.

2. Hvis virtuell mappe har ikke en kopi, men to eller flere, så er det her begrensningene begynner, og hvis de ikke blir observert, dukker det opp feil, feil og alle slags "mirakler". Alle de ovennevnte teknologiene støttes ikke i dette scenariet.

En vanlig feil ved bruk av DFS-R er å lage flere kopier og tillate redigering av filer. I dette tilfellet er det flere kopier av samme fil, og kopiene kan redigeres samtidig. Dette er ikke alltid en feil, men oftere enn ikke er det fortsatt en feil. Det er ingen feil å tillate uavhengig redigering av deler av en fil - dette er sjeldent og bør tenkes godt gjennom før bruk. For eksempel den vanlige tekstfil den vil overleve. Men ethvert Office-dokument er et zip-arkiv, og det er umulig å replikere endringer i innholdet: den siste som lagrer endringene vil vinne. Enda verre, delvis replikering av en fil kan kompromittere dataintegriteten totalt. Situasjonen er lik med roaming-profiler: de støtter ikke delvis replikering av DFS-R-endringer.

Så hva er ikke DFS-R kompatibel med Office-dokumenter? Nei, du må bare velge riktig scenario. Her er et eksempel.

Vi lager en sentral hub-server og samler inn informasjon om den fra andre kildefilservere. Vi inkluderer flere replikaer i det virtuelle navneområdet: en på huben, den andre på kildefilserveren, men alle ballene er skrivebeskyttet.

Hvordan redigerer du informasjonen? Det er veldig enkelt: du må lage en ny ball på hver kildeserver til de samme mappene med filer, men allerede med tillatelse til å redigere. Slike baller kan brukes direkte eller inkluderes i en egen gren virtuelt rom navn, men bare som en pekepinn.

Det er andre nyanser når du arbeider med DFS-R, de fleste av dem er godt beskrevet i dokumentasjonen.