Wraz z NBO 2.0 Novell wprowadził nowy, znacznie korzystniejszy system licencjonowania niż w przypadku wersji 1.0. Podstawowa licencja opiewa na jeden serwer w centrali i jeden serwer w oddziale terenowym. Jeżeli liczebność oddziału nie przekracza 250 użytkowników (w Polsce to raczej wątpliwe), łączna cena licencji wynosi tylko 2810 euro. Licencja obowiązuje bez względu na wybrany przez klienta system operacyjny.

Replikacja w standardzie

Nie wszyscy wiedzą, że do synchronizacji plików między oddziałami a centralą można wykorzystać standardowe usługi systemów Windows, przy czym Windows Server 2003 nadaje się do tego celu znacznie lepiej niż Windows 2000 Server. Distributed File System (DFS) to usługa umożliwiająca oddzielenie nazw udziałów sieciowych od powiązań z konkretnym serwerem fizycznym. Użytkownik chcący uzyskać dostęp do katalogu jest najpierw kierowany do serwera pełniącego rolę korzenia (root) rozproszonej struktury katalogów. Dopiero serwer usług DFS przekierowuje żądanie klienta do fizycznego zasobu.

Usługa DFS to rozwiązanie synchronizacyjne do "ogólnego stosowania", można je jednak zaadaptować na potrzeby replikacji plików między oddziałami a centralą. Ważne jest to, że serwerem docelowym wskazywanym przez korzeń usługi DFS mogą być serwer, na którym działa usługa DFS, inny serwer w tej samej lokalizacji albo też serwer działający w innej lokalizacji należący do tej samej domeny. Wyobraźmy sobie instalację, w której w każdym oddziale działa korzeń DFS. Lokalny użytkownik, chcący pracować z plikiem, połączy się z lokalną usługą DFS, która domyślnie wskaże lokalny plik. Wygoda pracy jest zapewniona, co jednak z bezpieczeństwem danych?

W ramach DFS dostępna jest usługa synchronizacji danych o nazwie File Replication Services (FRS). To dzięki niej właśnie usługę DFS można skonfigurować w taki sposób, aby pliki zapisywane na jednym serwerze fizycznym były różnicowo synchronizowane do jednego bądź wielu serwerów należących do tej samej grupy DFS. Jednym z nich może być serwer działający w centrali. W razie niedostępności lokalnego serwera docelowego w oddziale lokalna usługa DFS wskaże inny serwer posiadający replikę żądanych plików. Sam serwer root usługi DFS może być, w razie potrzeby, zabezpieczony za pomocą klastra MCS.

W Windows 2000 Server mechanizm DFS był nieco siermiężny, ponieważ w razie awarii domyślnego serwera fizycznego serwer-korzeń DFS wskazywał losowo wybrany dostępny serwer zawierający replikę. W Windows Server 2003 istnieje - możliwość ustalenia precyzyjnego scenariusza zachowania się usługi DFS. W szczególności, za pomocą odpowiednich wpisów w Active Directory poszczególnym serwerom docelowym można przypisać parametry określające pierwszeństwo udostępniania replik w zależności od tego, z jakimi zasobami uległ awarii serwer i z jakiej lokalizacji napływa żądanie udostępnienia pliku. Taka konstrukcja stanowi zabezpieczenie na okoliczność tego, by w razie awarii kluczowego serwera plików zbyt wielu użytkowników nie zostało przekierowanych do lokalizacji podłączonej do sieci słabym łączem.

Usługa FRS replikuje w pierwszym rzędzie zawartość woluminu systemowego, a w szczególności uprawnienia Group Policy, metadane użytkowników, usług i aplikacji oraz skrypty. Replikować można także zawartość innych wskazanych woluminów lub folderów. FRS można również wykorzystać do dystrybucji aplikacji - zarówno nowych, jak i aktualizacji już zainstalowanych.

Każde przekierowanie żądań użytkowników do właściwego serwera DFS wymaga potwierdzenia uprawnień w Active Directory - uwierzytelnienie zawsze odbywa się za pośrednictwem mechanizmu Kerberos. Niezależnie od tego serwery należące do tej samej grupy DFS uwierzytelniają się wzajemnie certyfikatami PKI. Replikacja może się odbywać w trybie ciągłym albo też zgodnie z ustalonym harmonogramem, np. co godzinę lub w nocy. Dane przeznaczone do przesłania są gromadzone w osobnym folderze i kompresowane zgodnie z algorytmami dostępnymi standardowo w systemie plików NTFS.

Inteligencja w buforze

O tym, w jakim kierunku ewoluują plikowe rozwiązania replikacyjne dedykowane do obsługi biur terenowych, można się przekonać, przyglądając się bliżej rozwiązaniu ActaStor młodej amerykańskiej firmy Actona Technologies. Podobnie jak w przypadku Novell Nterprise Branch Office 2.0, rozwiązanie ActaStor składa się z jednego bądź więcej serwerów wyraźnie przeznaczonych dla centrali (CoreServer) oraz serwerów dla oddziałów (EdgeServer). W przeciwieństwie do zastosowanego przez Novella podejścia czysto programowego system opracowany przez Actona Technologies jest rozwiązaniem sprzętowo-programowym.

Najważniejsze różnice dotyczą jednak sposobu działania. ActaStor nie jest rozwiązaniem replikacyjnym, lecz lokalnie buforowaną kopią katalogów i plików przechowywanych na serwerze w centrali. Gdy użytkownik odwołuje się do pliku w centrali, EdgeServer sprawdza, czy żądany plik nie znajduje się w lokalnym buforze. Jeśli tak, sprawdza jego aktualność wzglądem kopii przechowywanej w centrali. Jeżeli od ostatniego otwarcia dokumentu nic się w nim nie zmieniło, użytkownik korzysta fizycznie z pliku lokalnego.

Jeżeli plik uległ jednak zmianie, EdgeServer enkapsuluje żądanie CIFS lub NFS w opracowany przez Actona Technologies wydajny protokół transportowy zapewniający zarówno kompresję danych, jak i przyspieszanie komunikacji na poziomie TCP/IP. Działający po stronie centrali CoreServer odbiera żądanie, rozpakowuje je i dekompresuje, a następnie przekazuje do właściwego serwera plików. Utworzony dynamicznie plik różnicowy tą samą drogą trafia z powrotem do EdgeServera. Jeżeli okaże się, że pliku w ogólne nie ma w lokalnym buforze, z centrali do EdgeServer pobierany jest cały plik.