Konfigurering DFS Namespaces


Få ditt eksemplar av Windows Server Hacks

Hvis du ønsker å lese Mitch Tulloch øvrige DFS artikler kan du gå til:

  • Implementing DFS Replication
  • gjennomførings DFS-navneområder
  • Konfigurere og bruke DFS Replication

    I min forrige artikkel med tittelen gjennomførings DFS Navnerom på WindowsNetworking.com så vi hvordan du oppretter en navnerom (en virtuell mappe tre) ved hjelp av forbedret DFS ledelse konsollen av Windows Server 2003 R2. Denne artikkelen utdyper den forrige ved å se på hvordan man konfigurerer navnerom i bedriftsmiljøer der det er flere nettsteder. Siden et område, i Active Directory terminologi, refererer i utgangspunktet til en samling av datamaskiner som er koblet sammen som et LAN, betyr en multi-site miljø vanligvis flere LAN, hver plassert på et annet geografisk område. For eksempel kan et selskap som har sitt hovedkvarter i Vancouver (Canada) har en sekundær område eller avdelingskontor ligger noen timer sør i Seattle (USA). Selv om begge steder kan tilhøre samme domene, kan de være separate områder for å bedre håndtere replikering trafikken over en langsom WAN-kobling som forbinder dem. DFS Navnerom inneholder nye funksjoner som gjør DFS arbeide mer effektivt for scenarier som dette enn de eldre DFS komponent i Windows 2000 jobbet i slike scenarier. Vi vil se på flere måter du kan forbedre driften av navne i et bedriftsmiljø som dette.

    Legge Navnerom Servere

    Når distribusjon domenebaserte navnerom, kan du legge til flere navnetjenere å være vert for et navnerom. Dette har flere fordeler:

  • Hvis en navne server hosting navne går ned, vil navne fortsatt være tilgjengelig for brukere som trenger tilgang til delte ressurser på nettverket. Legge til et annet navnerom dermed øker tilgjengeligheten av navnerommet.
  • Hvis du har et navnerom som skal være tilgjengelig for brukere over hele organisasjonen, men Active Directory-nettverket har mer enn ett sted, deretter hvert område bør ha en navne server hosting ditt navnerommet. På den måten når brukere i et område må kontakte en navneserver for henvisninger, kan de gjøre det lokalt i stedet for å sende trafikk forespørsler til andre nettsteder. Dette forbedrer ytelsen og reduserer unødvendig WAN trafikk.

    Legg merke til at å legge til flere navnetjenere støttes bare for domenebaserte navnerom, ikke frittstående navnerom.

    Før viser hvordan du legger til en navneserver til et navnerom, la oss raskt gjennom scenariet fra min forrige artikkel:

  • Vår domenet er R2.local og vår domenekontroller er BOX161.
  • Vi skapte en domenebasert navne heter Accounting.
  • Denne navne ligger på serveren BOX162.
  • The navnerom inneholder mål på servere BOX162 og BOX163.
  • Alle servere er plassert i Standard-First-Site, som er selskapets hovedkontor i Vancouver.
  • Alle servere kjører Windows Server 2003 R2.

    For å gjøre vårt scenario mer enterprise-nivå, vil vi nå legge til følgende:

  • Vi vil opprette en ny side som heter Seattle-området, som er et avdelingskontor lokalisert i Seattle.
  • Seattle-Site er i samme domene R2.local.
  • Domain controller BOX171 ligger i Seattle.

    La oss nå legge BOX171 som en ny navneserver for vårt regnskap navnerom. Åpne DFS ledelse konsollen, velg \\\\ r2.local \\ Regnskap navnerom i konsolltreet, og klikk Navnerom Servere fanen i detaljruten (figur 1):


    Figur 1: Detaljer av fanen Navnerom Servere for den valgte navne
    Merk at regnskapsloven navne bare har ett navneserver i dag (BOX162). Nå la oss legge BOX171 som en ekstra navne server for dette navnerommet. Klikk på Server koblingen Legg kl i søksmålet ruten, eller høyreklikk på navne og velg Legg kl Server. Deretter blar du spesifisere BOX171 som ekstra navneserver for regnskapsloven navnerom (figur 2):


    Figur 2: Legge BOX171 som en ekstra navneserver for regnskap

    Legg merke til at en mappe heter Accounting vil nå automatisk opprettet på BOX171 og deles med de riktige tillatelsene (Les tillatelse for alle). Du kan overstyre denne standard oppførsel hvis du liker ved å klikke på Rediger innstillinger.

    Nå har du to navnetjenere definert for regnskapsloven navnerommet. En av disse serverne er BOX162 i Vancouver, og den andre er BOX171 i Seattle. Spørsmålet er, når en bruker i Seattle forsøker å få tilgang til navne, som navneserver vil den bruke? Dette bringer oss til vårt neste tema-henvisninger.

    Konfigurering henviste

    For å forstå viktigheten av å konfigurere henvisninger i et bedriftsmiljø, må du først forstå hvordan DFS Navnerom fungerer. Går tilbake til vår scenariet ovenfor, la oss si at en bruker som heter Bob Smith ligger i Vancouver (Standard-First-Site) ønsker å få tilgang til ressurser i Kontoer navnerom, som er spredt over (målrettet mot) servere i både Vancouver og Seattle (Seattle site). Her er hva vanligvis skjer:

    1. Bob prøver å få tilgang til rotmappen på navne \\\\ R2.local \\ regnskap ved henvendelse BOX162, en av to navnetjenere for dette navne (den andre navneserveren BOX171 ligger i Seattle).
    2. BOX162 returnerer en henvisning til Bob. Denne henvisningen inneholder en liste over servere som er vert for den aktuelle mappen (regnskap, roten av namespace) Bob prøver å få tilgang. I dette scenariet, er en rot henvisning returnert; hvis Bob prøvde å få tilgang til en mappe høyere opp i navne, ville en mappe henvisning returneres i stedet.
    3. Bob Windows XP stasjonær datamaskin bufrer henvisningen tilbake til det ved BOX162 og fortsetter med å kontakte den første serveren i henvisningen listen, som det viser seg er BOX162 selv.
    4. Derfra Bob begynner å surfe på navnerom, og BOX162 fortsetter å returnere henvisninger til mappe mål for hver mappe bladde.

      Så hva skjer da når en bruker på ett nettsted forsøker å få tilgang til en delt ressurs på et annet nettsted ved hjelp DFS? Som standard er listen over målene som returneres av en henvisning til et bestemt delt ressurs bestilt thusly:

      1. Targets i bruks nettsted er oppført først.
      2. Hvis brukerens området har flere mål, disse er listet opp i tilfeldig rekkefølge.
      3. Targets utenfor brukerens nettstedet er oppført ved siden av, og hvis det er flere mål i andre områder, målene er oppført i henhold til sine tilkoblingskostnader med lavest kostnad først (mål med samme kostnad er oppført i tilfeldig rekkefølge).

        Denne tilnærmingen betyr at som standard, forsøker DFS å koble en klient med et mål i kundens eget nettsted først når det er mulig å hindre klienten fra å måtte bruke WAN-kobling for å få tilgang til ressursen. Videre forsøker DFS også tilfeldig load-balanse slik adgang når det er flere mål som er tilgjengelige i kundens nettsted.

        Det er flere måter denne prosessen kan konfigureres imidlertid. For eksempel, i stedet for å bruke lavest mulig kostnad for å få tilgang mål utenfor kundens nettsted, kan du angi at DFS aldri bruker mål utenfor kundens nettsted i det hele tatt. Dette kan være nyttig, for eksempel, hvis man finner alle de delte ressursene som trengs av at området lokalt på dette området (eller replikeres til at området-Jeg skal dekke DFS Replication i en fremtidig artikkel). For å konfigurere dette, høyreklikker du på navne og velg Egenskaper, og deretter bytte til kategorien henvisninger og velg ekskluderings Targets alternativ som vist i Figur 3:


        Figur 3: Hindre kunder får tilgang til mål utenfor stedet for klienten

        Alternativt kan du la navne konfigurert slik henvisninger utenfor kundens nettsted er gjort ved hjelp av minst kostnad (standardinnstilling) og deretter overstyre denne innstillingen for individuelle mappe mål. For eksempel ved å høyreklikke på Leverandørgjeld mappe målet, velg kategorien Overgang, og velg den første avkrysnings som vist i figur 4 nedenfor:


        Figur 4: Eksklusiv mål utenfor kundens nettsted for en Særlig målmappen

        En annen måte å finjustere henvisninger er å endre prioriteten på mappen mål for en bestemt mappe. Siden en mappe kan ha mer enn én mappe målet (dette er vanligvis brukt i forbindelse med DFS Replication) er det en standard rekkefølge for hvordan disse målene blir returnert i en henvisning. Du kan overstyre denne standard bestilling ved å velge mappen i konsolltreet høyreklikke på en av de målene som er oppført i detaljruten for denne mappen, velge Egenskaper, velge fanen Avansert, og konfigurere de overstyrer innstillingene som ønsket (figur 5) :


        Figur 5: Deaktivere mappen mål for at en mappe

        For eksempel kan du spesifisere at et spesielt mål er oppført først i henvisningen, som vist i figuren ovenfor . Eller du kan angi den som sist hvis målet er din "server of last resort", dvs. en standby-server i tilfelle alt annet går ned.

        Til slutt, hvis WAN-koblinger er upålitelige, kan du finne dine kunder ofte tilgang til ulike mål for den samme mappen. Dette kan være et problem, for som standard, bufrer DFS henvisninger for en periode (300 sekunder eller 5 minutter), så hvis en målserveren plutselig går ned klienten vil fortsette å prøve å koble til målet og gi en feil i stedet for å lage ressursen er tilgjengelig for kunden fra et annet mål. Til slutt (som standard etter 300 sekunder eller 5 minutter) henvisningen utløper i klientens cache og en ny henvisning oppnås til et mål som er online og klienten vil være i stand til å få tilgang til ønsket ressurs, men i mellomtiden bruker kan vokse frustrert siden (a) brukeren må vente for henvisningen til å utløpe, og (b) etter henvisning utløper og en ny er oppnådd, kan henvisningen direkte klienten til å få tilgang til en fjerntliggende mål over WAN-kobling som ikke er en optimal situasjon. For å hindre at dette skjer (særlig ikke-optimale mål), kan du konfigurere klienten failback på navne (eller på bestemte mapper i navnerommet) slik at når den mislykkede målet kommer tilbake online klienten vil mislykkes tilbake til det målet som sin foretrukne mål. Denne innstillingen er også konfigurert på Referral fanen som vist i Figur 4 tidligere.

        Konklusjon

        I denne artikkelen og den forrige vi har sett på hvordan å implementere og konfigurere DFS-navneområder, en ny funksjon i Windows Server 2003 R2 som erstatter en del av den tidligere DFS komponent av Windows 2000 og Windows Server 2003. I fremtidige artikler vil vi undersøke hvordan å gjennomføre den andre halvparten av DFS i R2, nemlig den nye DFS Replication komponent.