Configuration Manager 2012 SP1 telephelyek

A következo 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 jelentos változásokon ment keresztül, mint amin a szoftverterítés.

Azt még a további részek elott szeretném kihangsúlyozni, hogy az egyéb változások a termékben lehetové teszik, hogy a legtöbb ügyfelünknél drasztikusan csökkenjen az Configuration Manager telephelyek száma. Ezt úgy kell érteni, hogy a fejleszto csapat célja az volt, hogy az ügyfeleink 80%-ánál egyetlen elsodleges telephely képes legyen teljesíteni az elvárt igényeket. Vagyis a termék képes legyen kezelni azokat a legfobb 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ó idot (gyorsabb az reakciók, válaszidok), csökkenti a hiba lehetoségeket, valamint kisimítja a ráncokat a rendszergazdák és kliens üzemeltetok arcán, de egyesek szerint a hajuk is sokkal fényesebb lesz tole!

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 elsodleges telephely és a Secondary Site, ami a másodlagos telephely néven ismert.

 Az elsodleges telephelyek hierarchiába voltak szervezhetok, egy elsodleges telephelynek megadható volt egy másik elsodleges telephely mint szülo telephely. A szülo-gyermek viszonylatban a magasabb hierarchia szinten (szülo) az üzemeltetok által létrehozott objektumok (gyujtemé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épekrol származó adatok (státusz üzenetek, leltá adatok, stb.) pedig felfelé a gyermek telephelyekrol a szülok irányába áramoltak. Ezen felül az elsodleges 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 elsodleges telephelyenként definiáltak, vagyis gyakorlatilag minden elsodleges telephely egy autonom rendszert képzett az SCCM infrastruktúrában. Ezeket az autonóm elsodleges telephelyek közül egy kitüntetett volt minden több telephelyes struktúrában, ez pedig az a telephely aminek nincsen szülo telephelye, a központi telephely (central site). Az elsodleges telephelyek szülo viszonya bármikor egyszeruen és fájdalom-mentesen módosítható, átrendezheto volt.

Egy másodlagos telephely közvetlenül és elmozdíthatatlanul kötodött az elsodleges telephelyéhez ahonnan telepítve lett, hiszen nem rendelkezett önálló adatbázissal, az elsodleges 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 elozo részben végig használt múlt ido legfobb oka annak a nyomatékosítása, hogy ezek a dolgok szignifikánsan, de meggyozodésem szerint a termék elonyére változtak.

Elsoként most már három telephely típus van: Az elsodleges é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 gyulik össze minden felügyelt kliensrol minden adat, és minden a teljes Configuration Manager infrastruktúrát érinto 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). Ebbol 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 elsodleges telephelyre még szükségünk lesz.

Amennyiben egy infrastruktúrában több mint 50 000 felügyelendo 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 elsodleges telephelyek is jelentos változásokon mentek keresztül. Ok továbbra is kezelnek klienseket, azonban egy elsodleges telephely két féleképpen tud létezni, amit a site telepítésekor a telepíto varázslóban kell meghatározni:

• Egyedül, önállóan úgy hogy nem riportol egy CAS-nak. Ez késobb egyszer módosítható, egyszer teheto be be egy CAS alá, onnan azonban csak teljes újra telepítéssel, a meglevo adatok elvesztésével lehet eltávolítani. Egy önálló elsodleges 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övoben sem.
• Egy CAS -nak riportol az elsodleges telephelyünk. Ekkor beszélhetünk hierarchiáról. Azonban ez a hierarchia késobb nem módosítható, vagyis ha a PRI site kódunkat a CEN site kódú CAS site-hoz rendeltük akkor késobb a PRI site-t csak újratelepítéssel tudjuk a CAS site kódú CAS site-hoz átrendelni.

Bár a fentiekbol implicit következik, de mégis explicit kihangsúlyoznám: Egy elsodleges telephely csak egy CAS-nak lehet a gyermeke, tehát a site struktúránkban kizárólag egy rétegben lehetnek elsodleges telephelyek, közvetlenül a CAS alatt. Egy hierarchiában legfeljebb 25 elsodleges telephely lehet. Viszont itt visszautalnék, hogy az elsodleges 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 elsodleges telephely hierarchia tagsága utólag nem módosítható. Tehát vége az egyszeru 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 alapvetoen 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 oket továbbra is igazak. Fontos újdonság, hogy mindenképpen rendelkeznek saját adatbázissal, de ezzel nincs adminisztratív tennivaló az elsodleges telephelyrol 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 elsodleges telephely adatbázisát használják. Ez azt jelenti, hogy egy SCCM 2012-es hierarchia legfeljebb háromrétegu lehet:

1. Central Administration Site (1 db)
2. Elsodleges telephelyek (max 25 db)
3. Másodlagos telephelyek (250 másodlagos telephely per elsodleges telephely)

Azonban jelentos ú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 szervezheto. Tehát egy másodlagos telephely disztribúciós pontja képes egy másik másodlagos telephelyrol replikálni a hálózati forgalom nagy részét jelentocsomagokat, ha az hálózati topológia szempontjából optimálisabban kivitelezheto. Ezt illusztrálja a következo ábra:

A global data és site data kifejtésre kerül egy következo 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 elegendo 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.