Ile siedzib System Center Configuration Manager 2012 potrzebuję?
Najczestsze pytanie jakie pada, odnosnie planowania hierarchii System Center 2012 Configuration Manager', to ile siedzib powinno byc zainstalowanych ?
W System Center Configuration Manager 2007 , z reguly, wygladalo to tak (przepraszam, zawsze bylem slaby w rysunkach :-) ) :
Siedziba Centralna (Primary Site)
Siedziba Primary 1 Siedziba Primary X
(primary site; workstacje/region A) (primary site ; serwery / Region X)
secondary, secondary, secondary.............................secondary.
Czyniono to ze wzgledu na:
- koniecznosc odseparowanie konfiguracji (np. czy i jak kiedy skanowac klientów, pod katem brakujacych poprawek)
- koniecznosc odseparowania administracji / punkt zarzadzania
- architekture i przepustowosc lacz
W Configuration Manager 2007, "metadane", jak definicje kolekcji, paczek, ogloszen, zawsze byly replikowane w dól, nigdy w góre lub do siedziby na równoleglym poziomie. Zas dane z/o klientach, byly replikowane w góre.
System Center 2012 zmienil tu wiele. Po pierwsze, wprowadzono nowy mechanizm replikacji wykorzystujacy mechanizm Sql Server Broker'a. Ta droga sa przesylane glównie te informacje, które nie sa contentem (trescia, binariami). Pozostale dane dalej sa przesylane przy uzyciu protokolu SMB. Szczególowo przedstawia sie to tak:
| Typ replikacji | Typ danych | Przyklady |
|---|---|---|
Replikacja bazy danych |
Dane globalne |
Kolekcje, definicje paczek i deploymentów (przepraszam, nie znalazlem odpowiedniego slowa w rodzimym jezyku) |
Replikacja bazy danych |
Dane siedziby |
Czlonkostwo/zawartosc kolekcji (jaki, dane inwentarzowe, alerty |
Replikacja bazujaca na przesyle plików |
Zawartosc plików |
Zawartosc paczek, poprawek, obrazy WIM , dane z siedzib secondary |
Dane Globalne to, praktycznie, wszystko co , co mozna zdefiniowac w konsoli. Takie obiekty sa widoczne na kazdym Primary Site oraz na Central Administration Site. (oczywiscie mozna ograniczyc ich dostepnosc za pomoca Security Scope)
Dane siedziby to dane zwiazane z tym, co dzieje sie w ramach danej siedziby. Sa one dostepne na Primary Site, które je otrzymal oraz sa replikowane do Central Administration Site
Binaria/Tresc oraz dane z Secondary Site, sa dalej przesylane przy pomocy pików...
Wiemy wiec juz, co i gdzie sie replikuje... Teraz zastanówmy sie, czy punkty wymienione wyzej (odnosnie tego kiedy potrzebowalismy kolejnej siedziby CM2007) dalej maja znaczenie:
- Rózne ustawienia dla róznych Klientów: w Configuration Manager 2007 wiele ustawien mialo zastosowanie do calej siedziby.. w 2012 Configuration Manager, mozna robic ich granulacje na poziomie kolekcji.. Mozemy., np, stworzyc kolekcje "Stacje robocze" i "Serwery" i nadac im totalnie rózne konfiguracje, jak ustawienia agentów, cykle odswiezania itp
- Do takich kolekcji mozna przypisac administratorów. Taki administrator w swojej konsoli "zobaczy" tylko takich Klientów, do jakich ogranicza go przypisane kolekcja. Administrator moze zakladac nowe kolekcje, ale nigdy nie bedzie mial dostepnych innych zasobów niz tych, do której ogranicza go macierzysta kolekcja (np. "Serwery")
- Security Scope: wiele konfigurowalnych elementów (np. paczki/aplikacje) ma mozliwosc przypisanie Security Scope. Nadajac stosowne uprawnienia do takich Scope'ów mozna zdecydowac który administrator z którymi elementami ma pracowac.
Dodatkowo sprawe ulatwia wiele wbudowanych ról zabezpieczen (mozna definiowac wlasne) oraz to , ze dany administrator w konsoli widzi tylko te sekcje i zasoby, do których ma uprawnienia..
Przypominam tez, iz w 2012 Configuration Manager , Distribution Point maja funkcje sendera, wiec mozna, wreszcie, zarzadzac ruchem miedzy siedziba a DP. (taki pelny DP moze byc tez zainstalowany na systemach klienckich, poczawszy od Windows Vista).
Reasumujac:
- Kiedy potrzebuje nowy primary site?
- Bardzo mozliwe ze dopiero wtedy, jak zostanie przekroczona liczba wspieranych stacji dla jednej siedziby (100 tysiecy)
- Kiedy potrzebuje secondary site?
- Bardzo mozliwe ze dopiero wtedy, jak bedzie konieczne sterowanie replikacja od secondary w góre.
Nalezy pamietac jeszcze o jednym: gdy instalujemy pierwszy serwer w hierarchii nalezy podjac NIEODWOLALNA decyzje: czy ów serwer bedzie SAMODZIELNA siedziba Primary Site, czy tez Central Administration Site ? W przypadku tej drugiej opcji nalezy wtedy zainstalowac jeszcze przynajmniej jedna siedzibe Primary Site, gdyz Central Administration Site nie obsluguje klientów!.
To tak po krótce. Jak zawsze - design to temat rzeka. Powinien byc przemyslany , zaplanowany . Potem latwiej dokonac instalacji, gdy wszystko mamy na papierze..