A következő cikkek az Configuration Manager 2012 SP1 telephelyekkel kapcsolatos változásokat fogják bemutatni. A telephelyek tekintetében a Configuration Manager nagyjából olyan jelentős változásokon ment keresztül, mint amin a szoftverterítés.

Azt még a további részek előtt szeretném kihangsúlyozni, hogy az egyéb változások a termékben lehetővé teszik, hogy a legtöbb ügyfelünknél drasztikusan csökkenjen az Configuration Manager telephelyek száma. Ezt úgy kell érteni, hogy a fejlesztő csapat célja az volt, hogy az ügyfeleink 80%-ánál egyetlen elsődleges telephely képes legyen teljesíteni az elvárt igényeket. Vagyis a termék képes legyen kezelni azokat a legfőbb fájdalom pontokat amelyek miatt jelenleg több telephelyet kell létrehozni az SCCM 2007 esetében. Ez a kiszolgáló számok csökkentésén felül, növeli a reakció időt (gyorsabb az reakciók, válaszidők), csökkenti a hiba lehetőségeket, valamint kisimítja a ráncokat a rendszergazdák és kliens üzemeltetők arcán, de egyesek szerint a hajuk is sokkal fényesebb lesz tőle!

Tömören összefoglalva mik voltak azok a tervezési szempontok amik miatt korábban több telephelyre volt szükség, és mik azok a Configuration Manager 2012 funkciók amik kiváltják ezeket:

Csak említésképpen, hogy már 2007-ben és 2012-ben is egy telephely képes 100 000 kliens kezelni, egy management point pedig 25 000 kliens-t.

Történelem

Az SCCM 2007 és korábbi verziók kétféle site típust különböztettek meg, az Primary Site ami az elsődleges telephely és a Secondary Site, ami a másodlagos telephely néven ismert.

 Az elsődleges telephelyek hierarchiába voltak szervezhetők, egy elsődleges telephelynek megadható volt egy másik elsődleges telephely mint szülő telephely. A szülő-gyermek viszonylatban a magasabb hierarchia szinten (szülő) az üzemeltetők által létrehozott objektumok (gyűjtemények, szoftver csomagok, stb.) a hierarchiában lefelé a gyermek telephelyek irányába replikálódtak, míg a felügyelt számítógépekről származó adatok (státusz üzenetek, leltá adatok, stb.) pedig felfelé a gyermek telephelyekről a szülők irányába áramoltak. Ezen felül az elsődleges telephelyek fontos ismérve volt, hogy önálló telephelyi adatbázissal rendelkeznek, és hogy a legtöbb SCCM beállítás, beleértve a kliens és biztonsági beállításokat is elsődleges telephelyenként definiáltak, vagyis gyakorlatilag minden elsődleges telephely egy autonom rendszert képzett az SCCM infrastruktúrában. Ezeket az autonóm elsődleges telephelyek közül egy kitüntetett volt minden több telephelyes struktúrában, ez pedig az a telephely aminek nincsen szülő telephelye, a központi telephely (central site). Az elsődleges telephelyek szülő viszonya bármikor egyszerűen és fájdalom-mentesen módosítható, átrendezhető volt.

Egy másodlagos telephely közvetlenül és elmozdíthatatlanul kötődött az elsődleges telephelyéhez ahonnan telepítve lett, hiszen nem rendelkezett önálló adatbázissal, az elsődleges telephely adatbázisát (vagy annak egy lokális replikáját) használta. Egy másodlagos telephely tehát rögzített hierarchiában mindenképpen a hierarchia legalját jelentette (mivel másodlagos telephelynek már semmilyen gyermek telephelye nem lehetett)

Central Administration Site

Az előző részben végig használt múlt idő legfőbb oka annak a nyomatékosítása, hogy ezek a dolgok szignifikánsan, de meggyőződésem szerint a termék előnyére változtak.

Elsőként most már három telephely típus van: Az elsődleges és másodlagos telephelyek mellett megjelent a központi adminisztrációs telephely (Central Administration Site, vagy CAS). A CAS (HUB még nincs…) tulajdonképpen egy nagy riporting és felügyeleti adatbázis a teljes Configuration Manager hierarchiánkra, ez a hierarchia teteje. Itt gyűlik össze minden felügyelt kliensről minden adat, és minden a teljes Configuration Manager infrastruktúrát érintő adminisztrációs tevékenységet innen tudunk indítani. Fontos és szignifikáns különbség a CAS és egy SCCM 2007 Central Site között, hogy egy 2012-es CAS közvetlenül nem kezel klienseket. Van sitecode-ja de nem tartozhat hozzá kliens (pl.:nincs Management Point-ja). Ebből kifolyólag egy csomó telephelyi szerepkört nem is futtat, nem is tud futtatni (pl.: PXE Point, stb.). Vagyis ha CAS-unk van akkor legalább 1 elsődleges telephelyre még szükségünk lesz.

Amennyiben egy infrastruktúrában több mint 50 000 felügyelendő kliens van abban az esetben a dedikált CAS szükséges, és ráadásul azt a CAS-t Enterprise Edition SQL kiszolgálóra kell telepíteni, az adatbázis particionálhatóság végett.

Primary site

A elsődleges telephelyek is jelentős változásokon mentek keresztül. Ők továbbra is kezelnek klienseket, azonban egy elsődleges telephely két féleképpen tud létezni, amit a site telepítésekor a telepítő varázslóban kell meghatározni:

• Egyedül, önállóan úgy hogy nem riportol egy CAS-nak. Ez később egyszer módosítható, egyszer tehető be be egy CAS alá, onnan azonban csak teljes újra telepítéssel, a meglevő adatok elvesztésével lehet eltávolítani. Egy önálló elsődleges telephely esetében ebben az esetben nem beszélhetünk hierarcháról mivel csak ez az egy telephelyünk van és több nem is lehet a jövőben sem.
• Egy CAS -nak riportol az elsődleges telephelyünk. Ekkor beszélhetünk hierarchiáról. Azonban ez a hierarchia később nem módosítható, vagyis ha a PRI site kódunkat a CEN site kódú CAS site-hoz rendeltük akkor később a PRI site-t csak újratelepítéssel tudjuk a CAS site kódú CAS site-hoz átrendelni.

Bár a fentiekből implicit következik, de mégis explicit kihangsúlyoznám: Egy elsődleges telephely csak egy CAS-nak lehet a gyermeke, tehát a site struktúránkban kizárólag egy rétegben lehetnek elsődleges telephelyek, közvetlenül a CAS alatt. Egy hierarchiában legfeljebb 25 elsődleges telephely lehet. Viszont itt visszautalnék, hogy az elsődleges telephely kizárólag oldalra skálázódási célokat szolgál, egyéb szeparációs igény már nincsen. Szintén fontos kihangsúlyozni, hogy egy elsődleges telephely hierarchia tagsága utólag nem módosítható. Tehát vége az egyszerű hierarchia átrendezéseknek módosításoknak, pl. egy cég összeolvadás esetében, viszont:

• Hányszor is van ilyenre szükség egy hierarchia életében? Ha 3 évnél gyakrabban hozzá kell nyúlogatni egy hierarchiához akkor ott valami alapvetően nem jó.
• A külön site-oknak hangsúlyozom ismét, csak oldalra skálázódási szerepe van. Tehát egy cég össze olvadásánál egy Configuration Manager migráció és konszolidáció a helyes út.
• Ha két 2012-es infrastruktúrájú céget kell összeolvasztani (pl.: egy felvásárlás) akkor egy Configuration Manager kliens migrációt kell végrehajtani. Ahol a kliens migráció alatt azt értem, hogy az egyik 2012-es infrastruktúra klienseit átrendeljük a másik infrastruktúrára (újratelepítés, vagy script révén) és kész is vagyunk.

Secondary site

Másodlagos telephelyek lényegében okosabbak lettek a korábbi verziókhoz képest. Tehát az ami eddig is jellemezte őket továbbra is igazak. Fontos újdonság, hogy mindenképpen rendelkeznek saját adatbázissal, de ezzel nincs adminisztratív tennivaló az elsődleges telephelyről indított telepítés során települ egy lokális SQL Express a másodlagos telephelyi kiszolgálóra.

A másodlagos telephelyek tehát továbbra is egy elsődleges telephely adatbázisát használják. Ez azt jelenti, hogy egy SCCM 2012-es hierarchia legfeljebb háromrétegű lehet:

1. Central Administration Site (1 db)
2. Elsődleges telephelyek (max 25 db)
3. Másodlagos telephelyek (250 másodlagos telephely per elsődleges telephely)

Azonban jelentős újdonság a másodlagos telephelyek szempontjából, hogy a hálózati forgalom legnagyobb részét adó csomag disztribúció (package) viszont hierarchiába szervezhető. Tehát egy másodlagos telephely disztribúciós pontja képes egy másik másodlagos telephelyről replikálni a hálózati forgalom nagy részét jelentőcsomagokat, ha az hálózati topológia szempontjából optimálisabban kivitelezhető. Ezt illusztrálja a következő ábra:

A global data és site data kifejtésre kerül egy következő cikkben. Ami fontos üzenet most, hogy a telephelyek adatai és a hálózati forgalom nagy részét adó csomagok adatáramlási útvonalai eltérhetnek egymástól.

Fontos hangsúlyoznom még egyszer az alap tételt miszerint a legtöbb ügyfelünk esetében egyetlen egy Configuration Manager telephely elegendő lesz: Az 2012 Configuration Manager SP1 rendelkezik sender képes disztribúciós ponttal is, tehát én egy telephelyen belül is tudom szabályozni az hogy a csomagok kiküldése mikor történjen. Tehát ha van egy több telephelyes hálózati topológiánk akkor sem feltétlenül kell Configuration Manager telephelyi hierarchiát kialakítanunk ahhoz hogy a WAN vonalon keresztüli csomag küldést szabályozni tudjuk.