1. NDS Novell Directory Services

Stein Meisingseth 22.1.2004 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO465 Novell Netware for systemansvarlige 1. Resymé: I denne leksjonen skal vi se på den viktigste komponenten i et hvert NetWare-nettverk, NDS. NDS er som lim som binder sammen hele nettverket, og alt som skal gjøres av driftsarbeid gjøres fra/via NDS. I leksjonen ser vi nærmere på hva NDS er, hva NDS gjør med nettverket og hvordan et nettverk driftes med NDS. NDS kommer spesielt til sin rett i store nettverk, og vi skal se litt på hvordan NDS driftes i slike store nett. NDS organiseres i tre-strukturer, og vi skal se litt nærmere på hvordan en slik trestruktur kan designes for å oppnå en effektiv og god organisering av treet.. 1. NDS NOVELL DIRECTORY SERVICES... 1 1.1. INNLEDNING... 2 1.2. INSTALLASJON AV SUPPORT PACK... 2 1.3. NDS NOVELL DIRECTORY SERVICES (HENTET FRA DRIFT AV LOKALNETTVERK )... 2 1.4. HVA ER NDS?... 3 1.4.1. Objektorientering... 4 1.5. OBJEKTTYPER... 5 1.5.1. Rotklassen... 5 1.5.2. Containerobjekter (Container Objects)... 6 1.5.3. Bladobjektet (Leaf Objects)... 7 1.6. DESIGN AV NDS-TRE... 7 1.7. DESIGNPRINSIPPER... 11 1.7.1. Personlig organisasjonsdesign... 11 1.7.2. Funksjonsdesign... 11 1.8. NDS I STORE NETTVERK... 11 1.8.1. Ett eller flere tre... 11 1.8.2. Replikering... 12 1.9. OPPSUMMERING... 12

1.1. Innledning I denne leksjonen skal vi se på den viktigste delen i forbindelse med drift av NetWarenettverk, NDS. NDS står for Novell Directory Services. Utviklingen av NDS er et av de aller smarteste trekkene i Novells lange nettverkshistorie. Det har gitt dem et teknologisk overtak på sine konkurrenter. La oss begynne med å se på hva Directory Services står for. Direkte oversatt til norsk blir det katalogtjenester. Et annet ord som ofte brukes og som er mer forklarende er ressursdatabase. NDS er altså en database som har oversikt over alle nettverkets ressurser. Det finnes overgripende standarder som beskriver hvordan en ressursdatabase er to slike kjente standarder er X.500 (en eldre, tradisjonell standard) og LDAP (som er den mest aktuelle standarden for tiden). NDS bygger på og støtter begge disse standardene. Det finnes pekere til mer informasjon om X.500 og LDAP på fagets web-sider. Det finnes mye stoff på Internett som tar for seg ressursdatabaser et white paper fra Novell er pensum denne uka sammen med leksjonen. Det er også pekere til noen tidsskriftartikler som tar for seg NDS. I leksjonen skal vi begynne med å se på hva NDS er, og litt på hvordan det er organisert. Første del er hentet direkte fra læreboka Drift av lokalnettverk, side 181 186 (Mikalsen/Borgesen). Vi fortsetter deretter med å se på design og planlegging av NDS-trær før vi ser på drift av NDS-trær i større nettverk til slutt. For å få fullt utbytte av denne leksjonen og øvingen må en ha installert et Novell-nettverk med NDS, og rettigheter til å eksperimentere med det. NDS er vanskelig å forstå å lære seg på en ordentlig måte dersom en bare skal jobbe med det i teorien. 1.2. Installasjon av support pack Se vedlegget om installasjon av support pack som du tar ned sammen med denne leksjonen. 1.3. (hentet fra Drift av lokalnettverk ) NDS står svært sentralt i NetWare 6, 5 og 4. Forståelse for NDS er fundamentalt for å kunne drifte Novell siden NDS er en så sentral komponent i disse versjonene. Hensikten med NDS er å gjøre operativsystemet nettverksorientert og ikke tjenerorientert. Tradisjonelt har nettverk vært svært tjenerorientert. Det vil eksempelvis si at dersom en skal installere en skriver, må en knytte den til en tjenermaskin. Dersom skriveren skal flyttes, må en da fjerne driverne og koplingene som er gjort til tjeneren, og installere på nytt på en annen tjenermaskin selv om vi snakker om samme nettverk. På samme måte ble brukere definert i tilknytning til en tjenermaskin, og ikke til nettverket. Figur 1 viser dette med et eksempel. Vi tenker oss et stort nettverk med mange tjenermaskiner. Nettverket er skissert som en sky i figuren med tjenermaskinene som en ressurs i denne skyen. Noen av tjenermaskinene brukes til brukerdatabase, andre brukes til filtjenester mens noen brukes som tjenere for applikasjoner. Siden alle tjenerne står i det side 2 av 13

samme nettet, vil det være mest fleksibelt og effektivt å legge brukerne inn i selve nettverket. På denne måten logger en bruker seg på nettverket, og ikke på en konkret arbeidsstasjon. Brukere Figur 1 NDS er nettverksorientert I et nettverk med NDS vil det derfor være slik at det logisk sett er ett nettverk selv om det er mange tjenermaskiner der. Det betyr at dersom vi installerer et objekt (for eksempel en skriver) i nettverket, så er det i nettverket uansett om tjenere flyttes, eller til og med fjernes. Slike endringer må oppdateres i NDS-objektets konfigurasjon. NDS gir også gode muligheter til å drive distribuert drift av nettverket. Driftsprogramvaren kan startes fra hvor som helst i nettverket, og systemet kan administreres fra en hvilken som helst arbeidsstasjon. Den eneste betingelsen er selvsagt at den brukeren som skal gjøre dette, må ha tilstrekkelig med rettigheter til å utføre disse driftsoppgavene. 1.4. Hva er NDS? Nå er det sagt en del om hva NDS kan brukes til, men det er ennå ikke definert hva NDS er. NDS er en distribuert, hierarkisk og objektorientert database som holder oversikt over alle ressurser (for eksempel brukerkontoer, filer og skrivere) og tjenester (for eksempel skriverkøer) i nettverket. At det er en database er forholdsvis enkelt å forstå. Den skal holde styr på alle komponenter i nettverket; det vil si ha oversikt over hele nettverket. Alle moderne NOS har en slik database (jf. kapittel 4). Databasen er distribuert. Det vil si at den ikke ligger samlet på ett sted, men er spredt ut over hele nettverket. Dette er hovedsakelig gjort av effektivitetshensyn. Nettverk er ofte store i utstrekning. Det kan være mange deler eller segmenter. Dersom databasen skulle ligge på et bestemt sted, ville det bli generert mye nett-trafikk. Det vil senke ytelsen til nettverket. Når vi i stedet får spredt den utover, kan det ved en fornuftig plassering av delene minske trafikken, og alle deler blir like mye belastet. I tillegg kan det nevnes at NDS av sikkerhetsmessige grunner ikke er lagret åpent, men på skjult område. NDS skal være tilgjengelig for alle uansett hvor i nettverket brukerne befinner seg. Alle brukere har tilgang til NDS og den informasjonen som ligger der. Det betyr at NDS gjerne kan brukes som telefonkatalog over brukerne. NDS er hierarkisk. Det betyr at det er mange nivå av databasen. NDS organiseres i en trestruktur. Figur 2 viser et eksempel på dette. side 3 av 13

Rot No LKS Salg PR Adm John Kari Sven Ståle Figur 2 NDS-eksempel Vi ser at vi her har fem nivå: Et rot-nivå, et nasjonsnivå (NO), et organisasjonsnivå (LKS), et under-organisasjonsnivå (Salg, PR og Adm) og et brukernivå, eller et bladobjektnivå. Vi kommer tilbake til de offisielle betegnelsene etter hvert. 1.4.1. Objektorientering NDS er objektorientert. Alle ressurser i NDS kalles objekter. Med ressurser i denne forstand menes stort sett alt det som finnes i nettverket, både av logiske og fysiske enheter. Eksempler på objekter i NDS er brukerkonto, lagringsvolum (Novells måte å dele opp disker på), en tjenermaskin og skriver. Objektet inneholder informasjon om det den representerer (for eksempel brukerkontoen). Når vi her ser på objektorientering, kan vi definere tre nivå: 1. Som øverste nivå har vi selve objektet. Det finnes mange forskjellige objekttyper. Det som kjennetegner objektorientering er at alle objekter, uansett type, behandles forholdsvis likt. Dette gir store fordeler i forhold til drift av objektene. Når en kjenner behandlingen av en type objekt, er dette svært overførbart. 2. Som andre nivå har vi objektenes egenskaper. Alle objekter har en mengde egenskaper, og disse egenskapene er de samme for alle objekter av en spesiell type. Alle brukerobjekter har eksempelvis samme sett av egenskaper. Slike egenskaper er navn, passordregler, innloggingsrestriksjoner etc. Alle brukerobjektene har naturligvis disse egenskapene. Andre objekttyper har andre egenskaper. Det er ikke naturlig at et skriverobjekt har passordregler på samme måte som en bruker. 3. Som tredje og laveste nivå har vi verdiene. Det innholdet som vi gir objektets egenskaper er dets verdier. Vi har tidligere sett på at et brukerobjekt har en egenskap som heter navn. Et konkret objekt har en verdi for denne egenskapen som bare gjelder for akkurat dette objektet. Figur 3 viser et eksempel på et objekt fra administrasjonsprogrammet ConsoleOne (denne finnes fortsatt i Netware 6 ellers bruker vi NWAdmin ved skriverinstallasjon eller webbrowser). Vi ser her et brukerobjekt. Objektet har en mengde egenskaper. Disse er gruppert i forhold til en del hovedemner i høyre side av figuren. Den gruppen som vises er Identification, og eksempler på egenskaper her er Login Name, Given name, Last name etc. Til høyre for egenskapen finner vi verdiene. Vi ser at det står oppgitt Arne Mikalsen som verdi for egenskapen Last Name. I noen av feltene er det mulig å skrive inn side 4 av 13

en verdi og i andre felt er det ikke det (det er for eksempel ikke mulig å skrive noe inn i feltet Login name ). Slike felt er statusfelt. Vi legger videre merke til at det er mange av egenskapene som ikke inneholder noen verdi. Det er ikke obligatorisk å oppgi verdi for alle egenskapene. En NDS-funksjon er også å fungere som en ren database som kan brukes til oppslag for systemadministrator og brukere. En kan for eksempel bruke NDS som en telefonkatalog for ansatte. Figur 3 NDS brukerobjekt 1.5. Objekttyper Det er tre hovedtyper (gjerne kalt klasser i teori om objektorientering) av objekter som kan forekomme. Dette er rotobjekter, containerobjekter og bladobjekter. 1.5.1. Rotklassen Rotklassen er en spesiell objektklasse, siden den kun inneholder ett objekt, rotobjektet. Rotobjektet definerer roten av treet. Som vi så ovenfor settes NDS-treet normalt opp motsatt av et vanlig tre, med roten på toppen. Rotobjektet defineres når NDS-treet installeres, og det må være ett (og ikke flere) rotobjekt i et NDS-tre. Under rotobjektet kan en plassere nasjonsobjekt, organisasjonsobjekt og alias-objekter (vi kommer tilbake til disse objektene etter hvert). side 5 av 13

1.5.2. Containerobjekter (Container Objects) Definisjonen på et containerobjekt er at objektet kan inneholde andre objekter (containerobjekter eller bladobjekter). Når vi snakker om trestrukturer kunne vi gjerne kalle dem grenobjekter. Containerobjekter gir en logisk gruppeinndeling, og det er mulig å dele inn etter organisasjonsstruktur slik som i eksemplet. En annen fordel med bruk av containerobjekter er muligheten det gir til enkel drift. Dersom en større gruppe skal ha spesielle rettigheter, er det mulig å tildele disse rettighetene til containerobjektene. Da vil alle objekter som er i containerobjektet få disse rettighetene. Eksempelvis vil det i vårt NDS-tre (Figur 2) være mulig å opprette to nye containerobjekter som heter regnskap og ledelse under Administrasjonen (Adm). Figur 4 viser dette. Nå vil det være mulig (og ikke minst enkelt) å gi alle i regnskapsavdelingen tilgang til en skriver (eller noen filer) ved bare å gi rettighetene til containerobjektet. Rot No LKS Salg PR Adm John Kari Sven regnskap ledelse Ståle Kåre Trine Det er tre mulige containerobjekter: Figur 4 NDS 1. Nasjonsobjektet (Country Object C). Dette brukes i svært liten grad, og Novell anbefaler at en ikke implementerer nasjonsobjektet dersom det ikke er spesielle grunner til dette. Årsaken til at Novell har implementert objektet er at NDS bygger på den internasjonale standarden for katalogtjenester, X.500 (jf. kapittel 4). 2. Organisasjonsobjektet (Organization Object O). Dette objektet representerer altså organisasjonsnivået i treet (LKS). Det er bare mulig å ha ett nivå med organisasjonsobjekt i et NDS-tre. Det er imidlertid mulig å ha mange O-objekter ved siden av hverandre (parallelle). Det må være minst ett O-objekt i et tre, og O-objektet må plasseres direkte under rot-objektet (eller nasjonsobjektet dersom en bruker dette). 3. Organisasjonsenhet (Organizational Unit OU). Dette objektet representerer avdelinger i treet, og det er mulig å ha så mange avdelingsnivå en ønsker. Når en skal bygge et stort NDS-tre, gjøres dette med mange nivå av OU-objekter og mange parallelle OU-objekter. Med OU-objekter kan en bygge en NDS-struktur som likner på virksomhetens egen organisasjonsstruktur. En er ikke strengt tatt nødt til å ha OUobjekter i et tre. side 6 av 13

1.5.3. Bladobjektet (Leaf Objects) Definisjonen på et bladobjekt er forholdsvis enkel. Et bladobjekt er et objekt som ikke kan inneholde andre objekter. Derfor har det fått navnet blad. Et bladobjekt finnes alltid under et containerobjekt (enten under O- eller OU-objektet). Det finnes mange forskjellige bladobjekter. Det vil være for omfattende å gjennomgå alle disse her. Eksempler på bladobjekter er: User Group Alias Print Queue Volume NetWare Server Brukerobjektet representerer en bruker som skal ha tilgang til nettverket og de privilegier denne skal ha. Brukerobjektet admin opprettes under installasjon av en NetWare tjenermaskin. Et gruppeobjekt representerer en samling brukere som av en eller annen grunn skal behandles likt (eksempelvis ved rettighetsadministrasjon). Siden gruppeobjektet er et bladobjekt kan ikke objektet inneholde brukerobjekter på samme måte som et containerobjekt. Brukerne som hører til en gruppe er definert inn i gruppas egenskaper som en verdi. Aliasobjektet er et objekt som peker på et annet. En kan for eksempel plassere et objekt for utskriftskø et sted i nettverket, og plassere et aliasobjekt i nærheten av brukerobjektene som skal sende utskrifter til køen. På denne måten blir det enklere å nå objektet. Utskriftskøer brukes til mellomlagring og administrasjon av utskrifter som venter på at det skal bli deres tur til skriveren. Novell NOS deler disken inn i atskilte volum. Volumobjektet er knyttet til en tjenermaskin som inneholder disken som volumet er tilknyttet. Et (eller flere) volumobjekt opprettes når en Novell filtjener installeres. Representerer en Novell tjenermaskin i nettverket. Det kan være flere slike tjenermaskiner i et NDS-tre. Det opprettes et NetWare server-objekt når tjenermaskinen installeres. Det finnes mange flere slike bladobjekter. Det vil være å gå litt for langt, og unødvendig detaljert å sette opp en alle disse her. Det finnes slike oversikter i de fleste skikkelige lærebøker om Novell. 1.6. Design av NDS-tre Når en skal legge opp et NDS-tre, er det mange måter en kan gå frem på. Avhengig av hva en velger vil brukerne merke dette under innlogging, systemansvarlig vil merke det i form av enkel drift av nettverket, og en vil merke det på grunn av at nettverket kjører mer eller mindre effektivt. Vi skal begynne med å se på noen alternativer til design av NDS-treet. I dette eksemplet ser vi på bedriften fra gjennomgangen ovenfor (LKS) med tre avdelinger, Salg, PR og Adm, og side 7 av 13

utdyper dette noe. Under hver av disse avdelingene igjen er de ansatte organisert i mindre grupper etter arbeidsoppgaver. Innenfor administrasjonen er det eksempelvis noen som jobber med regnskap, noen med lønn og andre med overordnet ledelse av bedriften. Det er totalt 160 ansatte i firmaet som har Novell-bruker. Alternativ 1: Alle objekter legges flatt under LKS. Dette vil medføre at det legges 160 brukerobjekter ved siden av hverandre, sammen med alle andre objekter, for eksempel skrivere, volumobjekter, etc. Figur 5 illustrerer denne strukturen. Her er brukere, skrivere, volum og en gruppe (Ansatte) lagt på en linje. Rot LKS John KariSven Kåre Trine Ståle Skriver1 Skriver2 Vol_SYS Vol_HOME Ansatte Figur 5 - Flat NDS-struktur En slik flat struktur gjør det enkelt å finne hvor i treet et objekt befinner seg, men dersom det blir mange brukere blir det likevel vanskelig og tungvint å finne frem til objekter. Et annet moment er at tildeling av rettigheter og administrasjon av brukere blir tungvint. Det er dette vi skal se nærmere på i leksjonene utover, og lar det bli med det. Konklusjonen på dette eksemplet blir derfor at denne organiseringen utnytter ikke NDS trestruktur og de mulighetene som ligger i dette. Jo større nettverket er (mange brukere) desto viktigere blir dette. Alternativ 2: Brukerobjektene legges inn under avdelingenes OU-objekter, og alle tekniske objekter legges inn under en egen ressurs-ou. Figur 6 viser et enkelt eksempel som illustrerer dette. Rot LKS Salg PR Adm Ressurs John Kari Sven Ståle Skr1Kø1 SYS Home Skr2 Figur 6 - NDS design, alternativ 2 En konsekvens med dette alternativet er at brukerne må kjenne til sin kontekst når de skal logge seg inn. Konteksten til en bruker er den grena brukeren er plassert på. Dette må oppgis for at brukerne skal kunne logge seg inn på rett bruker. I figuren nedenfor er eksempelvis brukeren Ståles kontekst at han er plassert i kontaineren Adm under LKS. Dette må gjøres under innlogging. Med den klienten som følger med pakken kan dette gjøres på to forskjellige måter. Figur 7 og Figur 8 viser disse to metodene. Med den første metoden oppgir en konteksten direkte i feltet for brukernavn, med brukernavn først og konteksten nedenfra i treet og oppover. Legg merke til at det står en punktum før brukernavnet i figuren. Dette forteller at en oppgir absolutt kontekst altså konteksten side 8 av 13

helt frem til rota (ikke til og med rot). Dersom en ikke setter punktum først regnes konteksten ut fra stående kontekst. 1 Dersom en har en stående kontekst LKS kan en i dette eksemplet oppgi Ståle.adm og dermed logge seg inn på den rette brukeren. Dette kan sammenliknes med DOS stående drev. Dersom en bruker DOS og skal kjøre et program kan en enten skrive programmets navn dersom det ligger i den katalogen du står på, ellers må du oppgi full (eller relativ) sti til programmet. Figur 7 Innlogging I I neste figur har jeg trykket på Advanced, og her et eget felt for å oppgi konteksten. Her kan en enten bla i kontekster brukt tidligere eller så kan en skrive inn en kontekst selv. Dette gjør det enklere for brukere som er ikke er vant med å navigere i kontekster. 1 Stående kontekst er for eksempel den konteksten der en bruker logget seg inn forrige gang, Dersom dette i eksemplet hadde vært Kari, ville stående kontekst ha vært Salg.LKS. side 9 av 13

Figur 8 Innlogging II Et klassisk eksempel der dette er vanskelig er videregående skoler som har mange maskiner som brukes av samtlige klasser på skolen (og lærere for den saks skyld). Dersom en 1. klassing har vært innlogget på en maskin må neste bruker (dersom han ikke er i samme klasse) oppgi en ny kontekst, enten ved rullegardinmenyen eller ved å skrive dette for å komme inn. For bedrifter der ansatte stort sett alltid benytter samme maskin vil dette ikke være noe stort problem, men dersom de i stor grad logger seg inn på hverandres maskiner eller har felles maskiner må en avveie hvor stort NDS-treet skal være ut fra dette. Alternativ 3: En deler treet enda mer opp, og innfører nye OU-objekter under hver avdeling ut fra hvilke arbeidsoppgaver de har. Dette gir et svært detaljert NDS-tre, og tilsvarende avansert innlogging som blir tungvinn dersom brukerne skifter maskin ofte. Dersom det er stor forskjell på hvordan brukerne administreres vil det gi fordeler ved at det er enkelt å behandle mindre grupper av brukere felles. I eksemplene ovenfor ser vi at det er spesielt to forhold som trekkes frem i forbindelse med oppdeling av NDS-treet i mange grener (OU-objekter) 1. Enkelthet ved innlogging ved at brukerne må skrive inn sin egen kontekst for å komme inn på nettverket. Dette blir vanskeligere med stor oppdeling. 2. Enklere administrasjon av nettverket ved at en kan tildele rettigheter til en del av nettverket (et OU-objekt) slik at alle brukere nedenfor dette får de privilegiene som tildeles. side 10 av 13

Disse to forholdene er ofte motstridende, slik at en må finne ut hvor balansen går i sitt nettverk. Vi kommer nærmere tilbake til dette i leksjon 7 der vi skal se på organisering av mange brukere i store nettverk. 1.7. Designprinsipper 1.7.1. Personlig organisasjonsdesign Når vi skal se på hvordan en kan designe NDS-nettverk har vi til nå bare sett på fordeler og ulemper med oppdeling av NDS-treet i mange grener. Vi har ikke sett noe på forskjellige strategier for hvordan disse OU-objektene skal lages. I eksemplet ovenfor legger vi merke til at det brukes en organisatorisk tilnærming på designet. Vi har en bedrift (LKS) som har tre avdelinger. Disse tre avdelingene gjenspeiles i NDS-treet, og brukernes plasseres inn under sin avdeling (alternativ 2 og 3). Dette er den mest vanlige måten å designe et tre på, og anbefales ofte i Novell-litteratur. Det er enkelt for brukerne å finne igjen sin bruker fordi strukturen er logisk. Denne designmetoden kaller vi personlig organisasjonsdesign. Vi kaller designet for personlig fordi brukerne er knyttet opp mot brukernes navn. 1.7.2. Funksjonsdesign Et annet alternativ er å designe nettverket etter hvilke funksjoner brukerne har, og ikke knytte det opp mot konkrete navn. En IT-ansvarligs bruker heter IT_ansvarlig, og vedkommende logger seg på som det. En sekretær logger seg på som sekretær. Dersom det er flere sekretærer kan de enten bruke den samme brukeren eller så kan en lage flere sekretærbrukere, for eksempel sekretær 1, sekretær 2 og så videre. Hvordan en skal designe NDS-treet med en slik tilnærming vil kunne variere en kan benytte de samme prinsippene som ovenfor. Da blir det en upersonlig organisasjonsdesign. Alternativt kan en velge å kategorisere brukerne etter funksjoner, alle i topp-ledelsen organiseres under OU-objektet toppledelse. Dersom det er flere sekretærer kan en legge brukerne under et felles sekretær OU-objekt. Slik kan en fortsette, og vi har da laget NDStreet etter et funksjonsdesign. 1.8. NDS i store nettverk 1.8.1. Ett eller flere tre I det testnettverket mange kjører som øvingsplattform i dette faget snakker vi om et svært lite nettverk (en eller to arbeidsstasjoner). I mange bedrifter er Novell-nettverkene svært store. De som har installert en Novell-tjener versjon 6, 5 eller 4 husker fra installasjonen av NDS-treet at det kom opp et spørsmål om den aktuelle tjeneren skal legges inn i et eksisterende NDS-tre eller om det skulle opprettes et nytt tre. Det vi skal frem til er at det mulig å lage et NDS-tre med mange tjenere. En kan oppnå dette på to forskjellige måter: 1. Ved installasjon av tjenermaskin får en spørsmål om en skal legge tjenermaskinen inn i et eksisterende NDS-tre. Hvis en velger dette får en spørsmål om hvilket tre det skal legges inn i. 2. Dersom en installerer maskinen med et eget tre kan en smelte sammen flere trær dersom det er plassert i samme nettverk. Dette gjøres med Dsmerge (tast Load side 11 av 13

1.8.2. Replikering dsmerge fra kommandolinje på tjenerkonsollet). Da vil to trær smelte sammen, og deres O-objekter vil være plassert ved siden av hverandre. Det er derfor et krav at ikke noen av deres O-objekter har samme navn. I store nettverk med ett NDS-tre kan det være dumt å bare ha én versjon av NDS-treet. Dersom en sentral maskin går ned vil hele nettverket da gå i stå. En bør legge kopier forskjellige steder. Dette får en til med replikering av NDS. Replikering gir ikke bare høyere sikkerhet, men også bedre tilgjengelighet, og dermed spart nettverkstrafikk. Dersom nettverket er spredt over store avstander (for eksempel to byer med oppringt ISDN-samband mellom) er det dumt dersom en må opp med telelinja hver gang en bruker skal jobbe mot lokale ressurser. Da er det bedre å ha en lokal kopi av NDS. Replikering av NDS kan settes opp fra ConsoleOne (tidligere fra programmet NDS Manager som en kunne finne under public-katalogen på tjeneren. Programmet kunne da kjøres fra en arbeidsstasjon). NDS deles inn i flere partisjoner, og en partisjon inneholder et containerobjekt og alle objekter som ligger under dette. Det er mulig med barne-partisjoner som er en del av en partisjon. I følge samme logikk er foreldre-partisjonen et nivå høyere enn en barne-partisjon. Et replika er en kopi av en partisjon. En kan sette opp at et en partisjon av NDS skal replikeres til andre filtjenere. Figur 9 viser et skjermbilde fra NDS Manager hvor oppsett av replikering administeres. Ikke bruk denne hvis du ikke er helt sikker på hva du gjør. Veien tilbake er svært vanskelig og ikke å anbefale. Figur 9 Oppsett av replikering i ConsoleOne Vi skal ikke gå i detalj på replikering i denne omgang. Det vil bli tema under seminaret, og vi skal komme tilbake til dette i leksjon 7. 1.9. Oppsummering I denne leksjonen har vi sett på selve kjernen av Novell NetWare, NDS. For å kunne drifte et NetWare-nettverk må en ha god kjennskap til NDS. Hele Novell-nettverket driftes gjennom NDS. Sentralt i forbindelse med NDS-drift er programmet Nwadmin der det hele administreres fra. Første del av leksjonen har vært en presentasjon av NDS og hva det er (hentet fra lærebok i Drift av lokalnettverk ). Vi har sett på hvilken type NDS-objekter som finnes og deres funksjon. Vi har videre sett på design av NDS-trær. Det er viktig å legge opp til et fornuftig design slik at en får et mest mulig effektivt nettverk både i forhold til drifting og for brukere. Til slutt i leksjonen har vi sett kort på NDS i store nettverk det er mulig å ha ett eller flere NDS-tre, og vi har sett litt på at det er mulig med replikering av trærne slik at kritisk side 12 av 13

informasjon ligger lagret flere steder. En får på denne måten et mindre sårbart nettverk, noe som selvsagt har stor betydning. side 13 av 13