Active Directory Domain Services (AD DS) je verovatno najkritičniji mrežni servis koji možemo da izgradimo na našoj mreži. Ako infrastruktura aktivnog direktorijuma padne, korisnici na našoj mreži će biti ekstremno ograničeni u onome šta mogu da odrade na mreži. Skoro svi mrežni servisi u Windows Server 2008 mreži zavise od autentifikacije korisnika u aktivnom direktorijumu pre nego što korisnici mogu da počnu da pristupaju resursima na mreži. Iz razloga što je aktivni direktorijum kritičan, moramo da primenimo bar jednak nivo pripreme za sprečavanje katastrofe aktivnog direktorijuma kao što to radimo sa drugim mrežnim resursima. Kada izgradimo Windows Server 2008 aktivni direktorijum, od ključnog je značaja priprema zaštite baze podataka aktivnog direktorijuma i kreiranje plana za oporavak baze podataka u slučaju kritičnih grešaka.

U ovoj lekciji biće reči o nekim osnovnim koracima koje možemo da implementiramo da bismo kreirali redundantnost i zaštitu za aktivni direktorijum. Takođe biće reči i o komponentama baze podataka aktivnog direktorijuma i o optimalnoj konfiguraciji ovih komponenata da bismo osigurali funkcionalnost oporavka od katastrofe.

Planiranje moguće katastrofe

Prvi koraci u oporavku od katastrofe moraju da stupe na snagu mnogo pre udara same katastrofe. Ustvari, ako nismo odradili odgovarajuće planiranje za potencijalnu katastrofu, problemi kao što su problemi sa hardverskom komponentom na domenskom kontroleru mogu da proizvedu pravu katastrofu umesto da proizvedu samo minornu neprijatnost.

Planiranje za katastrofu uključuje razmatranje svih elemenata koji čine normalnu mrežnu infrastrukturu, kao i određeno specifično planiranje aktivnog direktorijuma. Sledeće procedure su od kritičnog značaja:

  • Izgradnja konzistentne Backup i Restore procedure za domenske kontrolere. Prvi korak u svakom planu oporavka je instalacija odgovarajućeg Backup-a hardvera i softvera da bismo Backup-ovali domenske kontrolere. Nakon toga bi trebalo da kreiramo i testiramo Backup i Restore plan. Takođe, trebalo bi da odradimo Backup aktivnog direktorijuma pre svake velike i bitne promene kao što je na primer ažuriranje Sheme ili Bulk importovanje.
  • Potrebno je da testiramo naš Backup plan pre izgradnje aktivnog direktorijuma i povremeno nakon izgradnje. Nakon izgradnje aktivnog direktorijuma, naši korisnici će zahtevati da aktivni direktorijum bude dostupan sve vreme. Takođe bi povremeno trebalo da testiramo restore plan koji smo kreirali. Mnoga od mrežnih okruženja kojima se upravlja na najbolji mogući način imaju konzistentna testiranja Restore procedura, u kojima je svake nedelje testirana neka od komponenata Restore procedure. Ako nam se dogodi katastrofa, bićemo pod velikim pritiskom jer ćemo morati da odradimo Backup aktivnog direktorijuma i vratimo ga u normalnu funkciju što je brže moguće, i u slučaju da smo odrađivali povremena ili redovna testiranja restauracije AD DS-a, neće nam biti prvi put da se suočavamo sa ovim problemom.
  • Testirati promene u aktivnom direktorijumu u laboratorijskom okruženju. Ovo smanjuje rizik i probleme koje mogu da proizvedu ažuriranja aktivnog direktorijuma i u slučaju da određeni problemi budu proizvedeni, oni će se dogoditi u laboratorijskom okruženju, a ne u našoj mreži. Nakon uspešne provere ažuriranja u laboratorijskom okruženju, ažuriranje može da se implementira u produkcijsko okruženje (mrežu).
  • Potrebno je izgraditi domenske kontrolere aktivnog direktorijuma sa hardverskom redundantnošću. Većina servera pri kupovini mogu da se naruče sa ugrađenom hardverskom redundantnošću sa malim dodanim troškovima. Na primer, server sa Dual-power napajanjem, redundantne mrežne kartice i hardverski redundantni Hard Disk sistem bi trebalo da bude standardna oprema za domenske kontroler. Ako nas redundantnost sačuva čak i kada moramo celu noć da odrađujemo restauraciju domenskog kontrolera, to bi bila najbolja investicija koju bismo ikad uradili. U mnogim velikim mrežnim okruženjima, ova hardverska redundantnost prelazi na jedan viši nivo u kom je svaki domenski kontroler konektovan na različito električno kolo i konektovan na različiti Ethernet Switch ili mrežni segment.
  • U svim, ali u svim manjim mrežama, trebalo bi da izgradimo najmanje dva domenska kontrolera. Aktivni direktorijum koristi cirkularno Log-ovanje za svoje Log File-ove i ova defoltna opcija se ne može modifikovati. Cirkularno Log-ovanje znači da sa jednim domenskim kontrolerom možemo da izgubimo podatke aktivnog direktorijuma u slučaju pada domenskog kontrolera i moraćemo da odrađujemo restauraciju iz Backup-a. Čak i u malim kompanijama implementacija višedomenskih kontrolera je od kritičnog značaja. Ako želimo da većina korisnika koristi jedan domenski kontroler u većini slučajeva, možemo da modifikujemo DNS zapise podešavanjem prioriteta za svaki domenski kontroler. Drugi domenski kontroler nakon toga može da odrađuje druge funkcije i može da se iskoristi za Backuo samo u slučaju pada prvog domenskog kontrolera.

 

Data Storage aktivnog direktorijuma

Baza podataka aktivnog direktorijuma je smeštena u File-u koji se zove Ntds.dit i koji se nalazi u %Systemroot%\NTDS folderu po defoltu. Folder sadrži sledeće File-ove.

  • Edb.chk: Ovaj File je File tačka provere (Chackpoint File) koji ukazuje na transakcije iz Log File-ova koje su napisane u bazi podataka aktivnog direktorijuma.
  • Edb.log: Ovaj File je Transaction Log. Ovaj Log File je Text-length File koji je veličine tačno 10Mb.
  • Edbxxxxx.log: Nakon što aktivni direktorijum radi određeno vreme, verovatno će se kreirati jedan ili više Log File-ova koji će u svom imenu imati xxxxx deo i iznos koji raste i koji je prikazan u heksadecimalnim brojevima.
  • Edbtmb.log: Ovaj Log je privremeni Log koji se koristi kao dopuna tekućem Log  File-u (Edb.log). Novi File pod imenom Edbtemp.log je kreiran da smešta transakcije i edb.log File je reimenovan u sledeći raniji Log File. Nakon toga Edbtemp.log File je preimenovan u Edb.log. Iz razloga što je korišćenje imena ovih File-ova tranzistentno, File je obično nevidljiv.
  • Edbres00001.jrs i edbres00002.jrs: Ovi File-ovi su rezervisani Log File-ovi koji se koriste samo kada Hard disk koji sadrži Log File-ove ostane bez slobodnog prostora. Ako se tekući Log File popuni i server nije u mogućnosti da kreira novi File zbog toga što nema dovoljno slobodnog prostora na Hard disku, server će fleširati (Flush) sve transakcije aktivnog direktorijuma u memoriju u dva rezervisana Log  File-a i nakon toga će ugasiti aktivni direktorijum (Sut down). Svaki od ovih File-ova je veliče 10Mb.
  • Temp.edb: Ovo je privremeni File koji se koristi u toku održavanja baze podataka i za smeštanje informacija koje se odnose na transakcije koje su u progresu.

 

Svaka modifikacija unutar aktivnog direktorijuma naziva se transakcija. Transakcija može da sadrži nekoliko koraka. Na primer, kada pomerimo korisnika iz jedne organizacione jedinice u drugu, objekat mora da bude kreiran u drugoj OU i nakon toga mora da se obriše iz prve OU. Da bi transakcija bila kompletirana, oba koraka moraju uspešno da se odrade. Ako jedan od koraka ne bude uspešno odrađen, transakcija bi trebalo da bude RollBack-ovana sve dok svi koraci ne budu kompletirani. Koristeći Transaction-based model, aktivni direktorijum osigurava da baza podataka bude u konzistentnom stanju sve vreme.

Kad god se dogodi promena u bazi podataka aktivnog direktorijuma (na primer, promena broja telefona korisnika), promena se zapisuje u Transaction Log File. Zbog toga što je Tranaction Log File tekstualni File u kojem se promene zapisuju u sekvencama, pisanje u Transaction Log-ove je mnogo brže od pisanja direktno u bazu podataka. Zbog toga korišćenje Transaction Log-ova poboljšava performansu domenskog kontrolera.

Nakon što je transakcija napisana u Transaction Log, domenski kontroler učitava stranicu baze podataka koja sadrži objekat korisnika u memoriju (ako se već ne nalazi u memoriji). Sve promene u bazi podataka aktivnog direktorijuma se odrađuju u memoriji domenskog kontrolera.

Transaction Log ne poboljšava samo performansu domenskog kontrolera obezbeđivanjem mesta za rapidno upisivanje promena, već takođe nudi neke mogućnosti oporavka u slučajevima greške na serveru. Na primer, ako je promena odrađena u aktivnom direktorijumu, promena je zapisana u Transaction Log-ove i nakon toga u stranicu baze podataka u memoriju servera. Ako se server neočekivano ugasi u toku ovog procesa, promene u memoriji servera neće biti potpuno odrađene u bazi podataka. Kada se domenski kontroler restartuje, on proverava Transaction Log File-ove u potrazi za transakcijama koje nisu odrađene u bazi podataka. Ove promene se primenjuju u bazi podataka prilikom restartovanja servisa domenskog kontrolera. Check Point File se koristi u toku ovog procesa oporavka. Checkpoint File ukazuje na to, koje transakcije u Transaction Log-u su napisane u bazi podataka.

Dodaj komentar Sviđa mi se - (0) Ne sviđa mi se - (0)    

  • Održavanje AD DS domenskih kontrolera 1
  • Održavanje AD DS domenskih kontrolera 2
  • Održavanje AD DS domenskih kontrolera 3
  • Održavanje AD DS domenskih kontrolera 4