A nevem Center. System Center.

A Microsoft pár napja bejelentette, hogy megújítja a teljes System Center termékcsaládját, hogy azok a lehető legjobb megoldást nyújtsák magán- vagy hibrid felhők kialakításához és üzemeltetéséhez. Miközben a bejelentést elég nagy csinnadratta kísérte, úgy érzem, viszonylag gyorsan napirendre tért felette az iparág. Sőt, megkockáztatom, talán nem is ért el az üzenet a mostani, vagy a potenciális felhasználókhoz. Pedig merem állítani, hogy a rendszerfelügyelet, a virtualizáció és a (magán, hibrid) számítási felhők világában az évtized egyik legfontosabb és valószínűleg egyik legkockázatosabb lépését jelentette be a cég. Néhány pontban a lényeg:

• Minden System Center termék új verzióval jelentkezik. Nincs kivétel. Az egyedi termék-életciklusokat szinkronizálta a cég.
• Minden komponens megszűnik önálló termék lenni: egyetlen terméket lehet majd vásárolni, amit úgy hívnak, hogy “System Center".
• A termékek szinte mindegyike Cross-platform képességeket kap, vagyis nem csak Windows rendszerek felügyeletét lehet majd elvégezni. A SCOM már eddig is rendelkezett ilyen képességgel, most pedig tovább erősít a hálózatfelügyelet és a Java alkalmazás szerverek területén, az SCCM-ről ezt 2011-ben az MMS-en jelentettük be, az Orchestrator mindig is ilyen volt, a Virtual Machine Managernek pedig egyik újdonsága, hogy a Hyper-V mellett vSphere és XenServer felügyeletet is ellát majd.
• A System Centernek két kiadása lesz: Standard és Datacenter – vagyis nem lesz “Enterprise”. Funkcionális különbség nem lesz közöttük, kizárólag abban térnek el, hogy hány virtuális környezetre (Virtual Operating System Environment – VOSE) engedélyezett a használatuk. Standard esetén ez kettő, Datacenter esetén korlátlan.
• A termék licencelésének alapja – szerverek felügyelete esetén – kizárólag a fizikai processzor lesz. Nem lesz szerver licence, Management Server licenc stb. Meg kell számolni a processzorok számát, a rajtuk futó virtuális gépek számát, aztán választani a Standard vagy Datacenter kiadások között.
• A System Center termékekhez automatikusan jár SQL Runtime (gyakorlatilag “megfelelő mennyiségű” SQL Standard) – amelyet persze csak a System Center komponensekhez lehet majd használni.
• A csomaghoz megjelenik egy “Unified Installer” (UnI). Ez egy olyan eszköz, amellyel egyetlen kérdőív kitöltése után a teljes csomag automatikus telepítése elvégezhető. Világos, hogy az UnI nem lesz képes minden komponens minden összetett architektúrájának lekövetésére, de amikor kis környezetek (értsd: 1000 PC alatt!!) felügyeletét kell kialakítani, akkor jó szolgálatot fog tenni.

A legfontosabb változás?

Miért gondolom, hogy ez az évtized egyik legfontosabb bejelentése a maga területén? Meglátásom szerint azért, mert ezzel a Microsoft egyszerre gerjeszt új versenyt a régi és az új piacokon.

A Microsoftot hagyományosan a négy nagy rendszerfelügyeleti gyártó – HP, IBM, Computer Associates, BMC -  mögé sorolják a piacon, azzal a megjegyzéssel, hogy a Configuration Manager és az Operations Manager a legnagyobb installált bázisú szoftverek a maguk területén. Ezekkel a cégekkel és megoldásaikkal nem triviális versenyezni: olyan sokat fektettek már be, pénzben, tudásban, képzésben stb. az ügyfelek a versenytársak szoftvereibe, hogy csak a “tétet emelve” lehet ingerküszöb fölé nőni. Velük szemben tehát az drasztikusan egyszerűsített licencelés, és egyúttal a megemelt értékajánlat jelenthet alternatívát.

Ugyanakkor a legélesebb verseny nem itt zajlik. A VMware 13 évvel ezelőtti megjelenése, majd 11 évvel ezelőtti betörése az adatközpontokba legalább olyan forradalmi volt, mint az iPhone megjelenése az okostelefonok piacán. Kezdetben mindenki a meglévő piachoz mérte őket, s abban a tekintetben (értsd: a hagyományos rendszerfelügyelet tekintetében) a VMware nem számított nagy játékosnak. Mára fordult a kocka: a vSphere család a VMware cloud megoldásai és rendszerfelügyeleti portfóliója az egyik legerősebb rendszerfelügyeleti szállítóvá predesztinálja. És legyen bármilyen bonyolult a VMware licencelése, az még mindig nagyságrenddel egyszerűbb, és még mindig olcsóbb, mint a hagyományos rendszerfelügyeleti szállítók kínálata. Okos dolog volt a VMware részéről, hogy felvásároltatta magát az EMC-vel. Ez a húzás lehetővé tette, hogy ne merüljön el az ajánlat egy HP vagy egy IBM kínálat-tengerében, és a cég az EMC védőszárnyai alatt megőrizhesse dinamizmusát. Mára már látszik, hogy a védőszárny alatt micsoda madár fejlődött ki…Meglátásom szerint a Microsoft e második kihívást talán még nagyobbnak látja – s a teljes portfólió egybegyúrása egyetlen ajánlattá ez ellen is megfelelő fegyver lehet. Ettől a pillanattól kezdve ugyanis már nem lehet csak a Virtual Machine Manager-t összehasonlítani a vCenterrel. A “minden vagy semmi” ajánlat egyúttal a “minden vagy semmi” összehasonlításokat is magával hozza. Arról már nem is beszélve, hogy a mind nagyobb helyet követelő számítási felhő megoldásoknál már nem is lehet csupán egy-egy komponensre alapozni. A cloud a rendszerfelügyelet vonatkozásában is mindent visz.

A következmények a világban

Az ügyfelekre gyakorolt legfontosabb hatás, hogy újabb szerver-konszolidációt indíthat el. Egyrészt nagyobb virtuális gép sűrűség esetén jelentős árcsökkenés érhető el, másrészt a teljes portfólió teljesebb rendszerfelügyeletet tesz lehetővé, ami a legfőbb gátja a virtualizáció és magán számítási felhők további terjedésének. A konszolidáció, no meg az x86/84 rendszerek javuló skálázhatósága tovább fogja szűkíteni a Unix rendszerek életterét (ebbe a Linux nem tartozik). A maradó rendszerek és a Linux szerverek pedig immáron natív módon felügyelhetők System Center megoldásokkal.

Azt gondolom, hogy a Microsoft döntése lépéskényszerbe hozta a hagyományos rendszerfelügyeleti gyártókat, s talán nem túlzás azt mondani, hogy hosszú távon a teljes üzleti modelljük átgondolására késztetheti őket.

Nem marad érintetlen a VMware sem. Vita tárgyát képezheti, hogy elégséges-e a Microsoft portfóliója, de abban nincs vita, hogy a Microsoft potens versenytársa immár a VMware-nek. Ugyanakkor a Microsoftnak itt nem elégséges csak a rendszerfelügyeleti termékeit csatasorba állítania. A hypervisor képességek, már pusztán a prekoncepciók miatt is, legalább akkora hatással lesznek a rendszerek kiválasztása során, mint a rendszerfelügyelet.

A következmények Magyarországon

Hogyan változik nálunk a helyzet? Magyarországon évek óta a System Center termékek csomagban vásárlását ajánlottuk az ügyfeleknek, és ők többnyire hallgattak a tanácsainkra. Számukra a változás minimális. A Datacenter változatokat processzorszámra vetítve ekvivalensen váltjuk be. Az Enterprise változatoknál pedig egy licencért változatért két standard-ot adunk, amely így megint csak értékazonos váltás lesz.. Van ugyanakkor egy olyan ügyfélkör is, akik komponenseket, tipikusan SCOM-ot vagy SCCM-et vásároltak. Attól függően, hogy van-e érvényes szoftverfrissítésük vagy sem, másképp-másképp élhetik meg a változást. A frissítés-védelemmel rendelkezők azt tapasztalhatják, hogy bizonyos átváltási arány mellett hirtelen ölükbe hullik a teljes portfolió. Ez azonnali pozitív hír. A frissítésük meghosszabbítása ugyanakkor megdrágul. Akik nem rendelkeznek frissítés-védelemmel, és csak egy komponenst vásároltak, nos ők nehezebb helyzetbe kerülnek, mivel mostantól csak a drágább csomag lesz elérhető számukra – kivéve, ha egyébként szerver konszolidáció is zajlik náluk, mivel a konszolidáció árcsökkentő hatású.

Elképzelhetők olyan vásárlók is, akik a rendszerfelügyeletük kialakítását nem egy kiforrott stratégia mentén végzik, hanem aktuális problémákra gyors és egyszerű megoldást keresnek. Nos, nekik a System Center ajánlat esetleg kevésbé lesz vonzó, bár persze adott helyzettől és ártól függhet, mit gondolhatnak a Microsoft megoldásáról.

S végül lesznek olyan ügyfelek, amelyek számára ez a System Center csomag – még a legkisebb kiszerelésben is -  egyelőre nagy és bonyolult. Számukra a Microsoft még nem mondott semmit. A bejelentés egyelőre adós a System Center Essentials jövöjének felvázolásával.

Ha mindehhez még hozzáveszem a “Windows Server 8” és a benne lévő Hyper-V új képességeit, azt hiszem nem túlzás, ha azt mondom: az izgalmak csak most kezdődnek.

A Nagy Vihar (Perfect storm)

 A perfect storm is an expression that describes
an event where a rare combination of circumstances
will aggravate a situation drastically

– Wikipedia –

Meglepően csöndesen fogadta a virtualizáció világa a nyár elején, hogy a Gartnernek az x86 virtualizációs piacra vonatkozó, 2011-es “Magic Quadrant” (MQ) elemzése a Microsoft megoldását a vezető negyedbe helyezte. Pedig megér néhány sort elmélkedni ennek a változásnak a jelentőségén, főleg a nyári, és a várható őszi események fényében.

Mi a fene az a Magic Quadrant?

A “Magic Quadrant” egy vezetői elemzői módszer, a Gartner saját találmánya. Sok mindenre használhatják: a segítségével fel lehet térképezni egy termékportfoliót, vagy – mint esetünkben – elemezni lehet egy piaci szegmenset, amely jelentős növekedéssel kecsegtet, s amelyben a versenytársak igyekeznek megkülönböztetni magukat. Egy MQ szinte soha nem egy konkrét termékre vonatkozik, hanem mindig egy üzleti problémára, amelyet a versenyben résztvevők egy vagy több termékkel és/vagy megoldással, szolgáltatásokkal igyekeznek lefedni. A Gartner jelenleg 53 piaci szegmensre végez el rendszeresen elemzéseket, ezek egyike az x86 virtualizáció piaca. Az elemzések között vannak régóta vezetettek és egész újak is – a szóban forgó virtualizációs elemzés az utóbbiak közé tartozik, másodszor jelent meg. A MQ végterméke egy tanulmány, benne egy 4×4-es tábla, amelyben a felmérés eredményeként a Gartner elemzői elhelyezik a piaci szereplőket. Nagyjából így:

 

Az elemezés kétféle koordinátát tartalmaz, a végrehajtási képességet (Ability to Execute) és a vízió teljességét (Completness of Vision). Nézzük röviden, melyik mit takar.

A végrehajtás képessége (Ability to Execute)
Maga a végrehajtás képessége is egy összetett mutató, amelyet eltérő súlyozással az alábbi vizsgált tényezők alkotják:

• Termékek/szolgáltatások
• Általános életképesség (Overall Viability
• Kereskedelmi tevékenység és árazás.
• Piaci reagálóképesség a jelenben és a múltban
• Marketing tevékenység végrehajtás (Marketing execution)
• A felhasználók tapasztalatai (Customer Experience
• Üzemmenet (Operations

Sajnos meghaladja a cikk terjedelmét mindegy egyes tényező kifejtése, akit érdekel, azt a cikk végén található hivatkozásnál elolvashatja. Amire érdemes odafigyelni az az, hogy a tényezők a jelenre és a múltra, valamint a konkrét végrehajtásra összpontosítanak.

A vízió teljessége (Completness of Vision)
Ahogy az előző, úgy ez a koordináta is egy meglehetősen összetett dolog, amely az alábbi tényezőket egyesíti:

• A piac megértése (Market Understanding)
• Marketing stratégia (Marketing Strategy)
• Kereskedelmi stratégia (Sales Strategy)
• Termékstratégia (Offering (Product) Strategy)
• Üzleti modell (Business Model)
• Vertikális/iparági stratégia (Vertical/Industry Strategy)
• Innováció (Innovation)
• Földrajzi stratégia (Geographic Strategy)

Részletekre itt sincs mód, de megint csak érdemes észrevenni, hogy itt a gyártók (nyilvános) terveit, elképzeléseit elemzi a Gartner, vagyis a jelen és a jövő a fő szempont

A Magic Quadrant negyedei
A kétféle dimenzió mentén végül négy területre osztja a piacot a Gartner:

• Vezetők (Leaders) – Jól teljesítenek a piacon és jól pozícionálják magukat a jövőre tekintettel.
• Vízionálók (Visioners) – Értik merre tart a piac, vagy van elképzelésük arról, hogyan igazodjanak a változó piachoz, de a jelenlegi végrehajtás nem elég jó .
• Kihívók (Challengers) – Jól működnek, esetleg dominálják a piac egyes részeit, de nem mutatják, hogy kellően értenék merre tart a piac, illetve hogyan változnak az igények.
• Réspiaci szereplők (Niche players) – Kétféle szereplő is előfordulhat itt: Vannak, akik kis szereplők, de jól fókuszálnak egy-egy részterületre. Emellett vannak, lehetnek globális szereplők, akik nem fókuszáltak, és nem elég innovatívak vagy nem teljesítenek elég jól a piacon.

Mire kapunk választ egy MQ-ban?
Látható, hogy a végeredmény látszólag egyszerű, az értékelési szempontok viszont egyáltalán nem azok. Gyakori hiba egy-egy MQ értelmezésnél, hogy a teljes mutató helyett csupán egy-egy tényezőt “lát bele” az olvasó az elemzés eredményébe. Azt például semmiképp sem mondhatjuk, hogy a függőleges tengely csak marketing és kereskedelem, a vízszintes meg technológia. Egy MQ végeredményben olyan kérdésekre próbál választ adni, hogy:

• Mely gyártók a számottevő szereplők a piacon?
• Ki vagy kik a piacvezetők?
• Érdemes-e egy adott technológiánál egy adott megoldás szállítóját figyelembe venni?
• Milyen a versenyzők egymáshoz viszonyított helyzete?
• Mire kell készülni egy gyártó kiválasztása esetén? (Pl.: előremutató technológia és innováció, de gyenge támogatás stb.)
• A megoldásoknak, gyártóknak  milyen erős és gyenge pontjaik vannak?

Vagyis egy MQ egy döntést segítő, azt előkészítő tanulmány, olyan szakértőktől, akiknek napi feladata ezt a technológiai szegmenset és a szereplőket figyelni. Fontos tudni, hogy az MQ erősen épít az ügyfelektől kapott visszajelzésekre. Végeredményben ők látják ilyennek, vagy olyannak a megoldásokat.

Változások és elemzések az új kiadásban
A 2010-es és 2011-es éveket összevetve jó néhány változás látható. Eltűnt a Novell, ennek oka, hogy felvásárolták, s a tanulmány készítésének időszakában még nem dőlt el a SUSE részleg sorsa. Jövőre valószínűleg visszatér a most már leválasztott SUSE csapat. Az elmúlt évben az Oracle racionalizálta a portfólióját, ezért már csak egyszer szerepel. A Citrix erősített a végrehajtásban, ezért a vezető negyedbe került. Végül a Microsoft egy jobb piaci megértést, illetve innovatívabb portfóliót mutatott fel, ezért jobbra mozdult, így szintén bekerült a vezető negyedbe. Érdemes megnézni azt is, mit ír a Gartner a piac két legnagyobb szereplőjéről.

• VMware:  Erőssége a stratégia és a tervei a magán és hibrid számítási felhőkre vonatkozóan. (Naná, ők fújják a passzát szelet!). Technológiai vezető és innovátor. Magas ügyfél-elégedettség és nagy installált bázis, különösen az (amerikai értelemben vett) nagyvállalatok és technológiai szolgáltatók körében. A VMware-nek a Gartner szerint oda kell figyelnie árbevétel növekedésre, tekintettel arra, hogy a nagyvállalati szegmens telítődik, a kis- és középvállalatok viszont alacsonyabb árakat várnak. Figyelnie kell arra, hogy továbbra is figyeljenek rá – erősödik a verseny a Microsofttal. Végezetül az elemzők felhívják a figyelmet, hogy a VMware függ az olyan kihívásokkal teli piacoktól mint az IT szolgáltatás automatizáció.
• Microsoft: erőssége, hogy a virtualizációs rendszerfelügyelet ismerős lehet a Windows üzemeltetők számára. Erős Windows Server pozíciói vannak az (amerikai értelemben vett!) középvállalatoknál. Ezen cégekhez jó megoldásokat és árakat ad. Végezetül a Microsoft az Microsoft, vagyis egyike a négy AAA cégnek a S&P500-as listáján (értsd: a cég pénzügyi helyzete stabil). A Microsoftnak figyelnie kell arra, hogy nehéz lesz átkonvertálnia vagy körbebástyáznia a VMware installált bázisát, különösen a nagyvállalatoknál. Az MS erős versenyre számíthat a partneri csatornákért és a szolgáltatókért folytatott küzdelemben. Végül a Gartner szerint gond az, hogy a Hypervisor szülő partíciója Windows.

Érdekes megállapítás – de általam is tapasztalt tény – hogy a VMware magas árai, és az abból képzett partneri kedvezmény miatt a partnerek szívesebben árulják a “jövedelmezőbb” megoldást.

A 2011-es elemzés jelentősége
A legnagyobb és legfontosabb változás kétségkívül a Microsoft vezető negyedbe való belépése. Számos  nagy informatikai szervezet ugyanis szinte csak akkor áll szóba egy-egy szállítóval egy adott megoldással kapcsolatban, ha az már a vezető negyedben van. Erre a tanulmányra komoly ajtók nyílnak meg. Mindezt ráadásul a 2009-es, tehát a már nem egészen mai gyerek Hyper-V-vel és SCVMM-mel érte el a cég!

A Nagy Vihar
A nyár folyamán néhány esemény tovább növelte a piacon a feszültséget és a várakozásokat. Júliusban a VMware bejelentette a vSphere családja új generációját, nem mellesleg az új licencelési elveit is. Ez meglehetősen sok ellenérzést váltott ki – és ekkor nagyon finoman fogalmaztam. (Kollégáim két hosszú cikkben elemezték a történteket és a következményeket itt, meg itt.) Az VMware ügyfelek elégedettsége erőteljesen csökkent és a megbízható szállítói mivolta megkérdőjeleződött. Sokáig fog tartani, mire a helyi mérnökök ezt a csorbát szorgos munkával kiköszörülik, ha egyáltalán ez lehetséges. De ez még mindig nem a vége. A Microsoft augusztus folyamán elkezdte csepegtetni az új generációs operációs rendszeréről az információkat, és már mindenki tudja, hogy az igazán fontos bejelentések a jövő heti BUILD konferencián várhatók. Vigyázó szemetek Anaheim-re vessétek!

Azt hiszem, hogy a Gartner által kinyilvánított MS vezetői pozíció, a VMware ügyfél-elégedettségi fiaskója és a teljes Windows kínálat (kliens, szerver, Phone és Azure) valamint System Center termékcsalád minden tagjának új verziója együtt egy igazi tökéletes vihar. Előszélnek megteszi ez: Bringing Hyper-V to Windows “8”. Izgalmas ősz következik !

Keddtől BUILD!

Opalis – a mindent összeragasztó ragasztó

Bár már több mint egy éve, hogy a Microsoft a portfóliójába illesztette, mégis kevesen hallottak róla. Jelenleg a System Center termékcsalád tagja, s amikor bemutatjuk, valami ehhez hasonló ábrán szokott szerepelni.

Bár semmi kétség, hogy az Opalis jó helyen van a System Center családban, meglehetősen furcsa tag a többiekhez képest. Szemben ugyanis a Configuration Managerrel vagy az Operations Managerrel, az Opalis igazából nem menedzsel semmit. Ha a korábbi családtagok egyikét használni kezdjük, akkor képesek leszünk telepíteni, monitorozni, eseményt gyűjteni, menteni stb. stb. Az Opalis semmi ilyesmit nem tud. Telepítés után magától nem csinál semmit

Az Opalis egy IT folyamat-automatizációs motor, a pontos angol kifejezéssel Run Book Automation software. Nem az a feladata, hogy cselekedjen, hanem az, hogy rögzíteni (megalkotni) lehessen benne számos folyamatot, amelyben szerepelhet telepítés, frissítés, mentés vagy szinte bármi más, az Opalis pedig gondoskodik róla, hogy a megfelelő eszköz a megfelelő műveletet végrehajtsa. A műveletekből úgy lesz folyamat, hogy az egyik művelet eredményét felhasználhatja egy másik, az egyik művelet végére várhat a másik, sőt egy művelet eredményétől függően több végrehatási ágra is szétválhat a végrehajtás.

Az Opalis nagyszerűsége abban rejlik, hogy mindezt nem programozással, hanem ikonok összehuzogatásával, viszonylag gyorsan és egyszerűen létre lehet hozni. Mivel ez így talán még mindig eléggé ködös, mutatok egy pár perces videót egy lehetséges folyamatról.

A bemutató során emlegetett 6.3-as verzió egyébként november végén megjelent, frissítésévédelemmel a System Center vásárlók (SMSE/SMSD tulajdonosok) elérhetik. Természetesen mindez csak egyetlen példa, a szoftver lényege, hogy intuitív módon szinte bármit automatizálni lehet. További érdekes információk:

• 8-Minute-Demo – Opalis CMDB Federation and Event Remediation
• 8-Minute-Demo Opalis and the SharePoint Integration Pack
• 8-Minute-Demo – Opalis Manual Workflow Initiation
• VMM Workflows
• Integration Pack for Windows Tasks
• Workflow Authoring Examples and Samples

Az Opalis nem a világegyenlet megoldása. Automatizáció létezett korábban is scriptek formájában, nem is beszélve arról, hogy ezeket a tevékenységeket kézzel el lehet végezni. Ugyanakkor azt mindenki tudja, hogy igazán jó scripteket kevesen tudnak írni, legalábbis sokkal kevesebben, mint ahányuknak erre egyébként szükségük lenne. De még a jó scriptelőknek is csak egy töredéke dokumentálja a munkáját  – így aztán a scripttől sokan idegenkednek. Kézzel, emberi erőforrással szintén sok minden megoldható, csak éppen nem nyomon követhető, illetve ismétlődés esetén gyakran nem ugyanazt az eredményt adja a “biorobot” (És már a kifejezés is mutatja, hogy a lélektelen ismétlődő feladatokat nem szeretik az emberek.)

Az Opalis ezzel szemben viszonylag egyszerűen, átlátható módon – öndokumentáló jelleggel  – képes automatizálni. Alkalmas az ismétlődő feladatok precíz végrehajtására, de jó lehet az egyszer vagy ritkán végrehajtandó feladatok rögzítésére is. Nem kódolásban gondolkodik – bár azzal igény szerint könnyen kiegészíthető – hanem a vizualizációra helyezi a hangsúlyt. Az egyes rendszerfelügyeleti (vagy éppenséggel nem rendszerfelügyeleti) szoftverek tevékenységeit (activity) ismeri, azokat képes megszólítani.

Ez azonban még mindig kevés. A video láttán az első kérdés az emberben az, vajon hogyan működik ez nem Microsoft szoftverekkel. Jó hírem van: majdnem azt mondhatom, hogy jobban együttműködik a nem Microsoft rendszerfelügyeleti szoftverekkel, mint a saját System Center családtagokkal. Olyannyira, hogy a 6.3-as verzió előtt nem is létezett integrációs csomag (IP) System Center termékhez az SMS-t (!!) és a SCOM-ot leszámítva. Íme a jelenlegi IP lista – nem számítva a Codeplexről letölthetőket:

• BladeLogic Operations Manager
• BMC Atrium CMDB
• BMC Event Manager
• BMC PATROL
• BMC Remedy ARS
• CA AutoSys
• CA eHealth
• CA NSM
• CA Service Desk
• CA Spectrum
• EMC Smarts InCharge
• FTP
• HP Asset Manager
• HP iLO
• HP OpenView Operations
• HP OpenView Service Desk
• HP Service Manager
• HP Network Node Manager
• IBM Tivoli NetCool / OMNIbus
• IBM Tivoli Enterprise Console
• IBM Tivoli Storage Manager
• Microsoft Active Directory
• Microsoft System Center Configuration Manager
• Microsoft System Center Operations Manager
• Microsoft System Center Virtual Machine Manager
• Microsoft System Center Service Manager
• Symantec Net Backup
• VMware vSphere

Értelem szerűen, minél több integrációs csomaggal rendelkezik a szoftver, annál nagyobb a szabadságfoka, s annál többféle folyamat automatizálható vele. Azt gondolom, hogy az Opalis jelentősége nem lebecsülhető. A legegyszerűbb sharepoint lista figyeléstől egy teljes private cloud automatizációig bármit képes elvégezni, s alapvető szerepet játszhat az informatikai üzemeltetésben. Azt hiszem, sokat foglalkozom majd ezzel a technológiával.

Szervezetek egyesülése és a virtualizáció

Érdekes egybeesés, hogy mind a vállalati, mind pedig az állami szektorban belefutottam egy szervezeti egyesüléses történetbe, s mindkét helyen azonos szituáció alakult ki. Az egyik előd VMware-t futtat, a másik Hyper-V-t. Adódik a kérdés, vajon mi maradjon az egyesülés után? Lehet persze “szerelemből” válaszolni, és nyugodtan elhiheti mindenki, a döntéshozók részéről van is erre hajlam, én mégis azt mondom, mérlegeljünk józanul, ugyanis nem csak technológia és nem is csupán csak pénz áll a dolgok mögött. Nézzük a döntési teret, vagy legalábbis annak nagyobbik részét:

• A vSphere lesz a “szabvány”. Szokták volt mondani, hogy “Sohasem rúgtak még ki senkit azért, mert IBM-et vásárolt”. Vagy a sárkányfűárus sárkányfűre vonatkozó megjegyzése is ideillik: “Ha ez nem segít, akkor semmi”. Nagyjából kiviláglik, hogy az ilyen döntés mögött a legfontosabb hajtóerő a biztonságra törekvés. Előnye még a megoldásnak, hogy homogenitást teremt, amely végső soron és hosszú távon a leginkább kívánatos az üzemeltetési költségek szempontjából. Emellett optimális erőforrás használatot tesz lehetővé, hiszen a egyesített homogén rendszer valószínűleg nagyobb “egybefüggő” kapacitással rendelkezik, mint az egyesülés előtti rendszerek. Persze ennek a döntésnek vannak hátrányai is. Szoftver licenc beszerzést igényel – sokszor nem is keveset. Végre kell hajtani egy migrációs projektet, ez szintén idő és pénz. Ha a Hyper-V-s környezet System Centerrel felügyelt, akkor a beruházás esetleg még nem térült meg, a migráció után pedig néhány komponens (például DPM) nem, vagy csak részben lesz használható. Ezen felül képezni kell a munkatársakat is: vagy azért, mert az üzemeltetői csapatok érintetlenül megmaradnak, ekkor a hyper-v-s részleget fel kell hozni Vmware tudásszintre, vagy azért, mert a vmwares csapat átveszi az összes virtualizációs feladatot, de ekkor a hyper-v-s üzemeltetőknek kell más munkát végeznie, s ahhoz képzés is járul. Végül, ha a csapatot megvágják, akkor végkielégítésekkel kell számolni.
• A Hyper-V lesz a “szabvány”. A fenti helyezet fordított előjellel. A fő motiváció itt a költségtakarékosság lehet. A Hyper-V ár/érték aránya jobb, ha pedig műszakilag is kielégíti az igényeket, akkor nincs akadálya ennek az útnak. Előnye a lépésnek a korábban már emlegetett homogenitás, optimális erőforrás kihasználás. Költségek itt is felmerülnek, nem is kevés: ugyanúgy van migrációs projekt, jelentkezhetnek addícionális System Center licenc költségek. Éppúgy , mint az első esetben, itt is felmerülhet, hogy a korábbi (VMware) beruházás még nem térült meg, a migráció után pedig lehet, hogy további szoftverekről kell lemondani, miközben azok még amortizálódnak.
• Mindkét technológiai a helyén marad, külön rendszerfelügyelettel. Ha az első két verzió hátrányai (migrációs projekt, korábbi, meg nem térülő beruházás, nem kívánatos szervezeti átalakulás) túlságosan is fájnak, akár az is elképzelhető, hogy mindkét rendszer marad a helyén. Ekkor nincs migrációs projekt, minden korábbi befektetés ketyeg tovább, viszont a technológiai erőforrásokkal nem bánik hatékonyan a szervezet, illetve a rendszerfelügyelet emberi erőforrás igénye sem változik.
• Mindkét technológia a helyén marad, egyesített rendszerfelügyelettel. Elsőre ez egy remek ötlet. A Virtual Machine Manager  segítségével a VMware napi üzemeltetési feladatok elláthatók. Nincs migrációs projekt, nincs meg nem térült beruházás, sőt még az üzemeltetési szervezet is csökkenthető valamilyen mértékben. Persze az egyesített rendszerfelügyelet papíron szép, de egyelőre nem varratmentes megoldás. Az SCVMM számos limitációval rendelkezik, a DPM VMware-nél csak a vendég Windows rendszerekhez használható, a SCOM pedig többnyire nem egy VMware, hanem egy HP, BMC, CA vagy IBM megoldással néz szembe – az megér egy külön bejegyzést.

  Láthatjuk, hogy nincs egyetlen járható út, bármely döntésnek előnyei és hátrányai is vannak. Azt pedig, hogy melyiket érdemes választani nem kis mértében befolyásolhatja néhány egyéb tényező is. Ilyen például:

• Licenc szerződések és/vagy támogatás lejárta. Ha az egyik rendszer nagyon öreg, az a migráció felé billentheti a mérleget. Ha már nem is támogatott, az még inkább.
• A rendszer súlya. Ha az egyik egy éles környezet, a másikkal pedig legfeljebb kísérletezget az IT csapat, ott nem kétséges, hogy a homogenizáció vonzóbb lehetőség. Ha mindkét rendszer “nagy”, akkor az az együttélési szituációkat helyezi előtérbe. A “nagy” persze egy relatív fogalom, a szervezet méretéhez, változtatási képességéhez viszonyítok.
• Az üzemeltetők agilitása. Ha az egyik virtualizációs csapat önálló, lelkes és agilis, míg a másik azt sem tudja pontosan, hogy mi van a kezében, akkor ez a homogenitás megteremtése felé terelheti a döntést..
• Az informatikai szervezet érettsége. Az érettebb szervezetek kisebb költséggel, hatékonyabban és agilisen működnek. Ez könnyedén ellensúlyozni képes migrációs költségeket vagy éppenséggel egyik vagy másik termék árelőnyét. Legjobb példa erre a Microsoft 2010 nyári felmérése. A diagramokból látszik, hogy az IT érettség sokkal jobban befolyásolja a költségek alakulását, mint egy adott technolgia kiválasztása.

Azt hiszem sikerült felvillantanom, hogy a probléma sokkal összetettebb annál, minthogy csupán zsigeri preferenciák alapján szülessenek döntések. “Szerelem” helyett bölcs körültekintést ajánlok.

Megjelent a System Center Service Manager 2010

2010. április 20. fontos dátum lesz az informatikai üzemeltetés történetében. A Microsoft kiadta a System Center Service Manager 2010 terméket – a Service Manager első változatát. Na végre! – mondhatja bárki, aki követte a szoftver életútját. Nagyjából éppen két évet késett az eredeti tervekhez képest. Ott voltam azon a belső konferencián, amikor bejelentették, hogy az eredetileg 2007. év végére tervezett megjelenés 2010 első félévére csúszik. A 2 év csúszás az lényegében azt jelentette, hogy majdnem előről kezdték a fejlesztést. No, ez persze így nem igaz, hiszen a kód és az architektúra jelentős része közös az Operations Managerrel, de azért jócskán hátradőlt a csapat, hogy végiggondolja a hogyan továbbot. Volt miért. Az eredeti Béta1 kb. 200 gép kezelése környékén bedőlt, nem lehetett tovább terhelni. A minap megjelent RTM 50 000 desktopig skálázható. Ennél ugyan lennének nagyobb rendszerek is, de az ügyfelek többségének ez elfogadható nagyságrend.

Azt hiszem, kevés olyan System Center termék van, amelyhez ekkora várakozások fűződnek. Ha a Microsoft belép egy piacra, ott többnyire drasztikusan leszorítja az árakat. Ez most is így van, még akkor is, ha a szokásos SC árakhoz képes a Service Manager jóval drágább. (Na ja, a Remedy-hez meg a CA ServiceDesk-hez kell ezt nézni). Az alacsonyabb ár segít túllépni a kevesebb referencia problémáján, átbillenti a költségekre érzékenyebb ügyfeleket, no meg azokat, akik a korábbi megoldásokat egyszerűen nem érhették fel. Nem utolsó sorban óriási a várakozás azon üzemeltetési vezetők körében, akik bevásároltak (és bevezettek) egy csomó más System Center terméket, és most azt gondolják, hogy a Service Manager rendbeteszi majd a folyamataikat is. Arra való, nem?

De egyáltalán mit tud a Service Manager? Ezt részben a Microsoft Operations Frameworkkel lehet megmérni. Elvégre ez az az üzemeltetési módszertan, amelyet a Microsoft ajánl, s amely módszertan gyakorlatba ültetését épp a Service Manager hivatott a jövőben a leginkább segíteni. A MOF – ahogy az ábrából is látható – három fázisból (Plan, Deliver, Operate), egy rétegből (Manage), ezeken belül pedig egymással kereszben kasuló összefüggő Service Management Fuction-ökből (SMF) áll. Minden egyes SMF-en belül folyamatok (Process), azon belül pedig feladatok (Task) vannak. A fázisokat, és néha egy-egy SMF-et ún. Review-k választják el egymástól. Rögtön szögezzük le, hogy a Service Managernek nem feladata minden SMF támogatása, hiszen bizonyos üzemeltetési feladatokat esetleg nem is lehet rendszerfelügyeleti szoftverrel lefedni – pl. Business/IT Aignment – vagy éppenséggel más termékek végzik azt. Hogy mást ne mondjak, a “Service Monitoring and Control” SMF rendszerfelügyeleti eszközökkel támogatható folyamatait a SCOM segíti. No, szóval, ha a MOF egy térkép, akkor a Service Manager alapképességei közé az alábbi SMF-ek támogatása tartozik:

1. Operations(*)
2. Customer Service
3. Problem Management
4. Change and Configuration
5. Gvernance, Risk and Compliance – GRC (**)

Két SMF támogatást is megcsillagoztam. Az első az Operations, amelyben az üzemeltetési leírások készülnek, vagy finomodnak. A Service Manager tartalmaz egy tudásbázist (Knowledge base), s bár persze másképp is lehet, én mégis ebben tárolnám az üzemeltetési feladatok leírását – már persze azokat, ahol emberi munkára van szükség. A második megjegyzés a GRC-t illeti. Jelenleg még nem része a terméknek, külön, Solution Accelerator formában jelenik meg a “Governance, Risk and Compliance” Management Pack, az azonos nevű SMF támogatására. Hogy pontosan mikor, azt nem tudni. Jelenleg beta1 állapotban van a Management Pack, ez még csak az SM béta 2-vel működik jól. Május végén várható egy Béta 2, amely telepíthető lesz a Service Manager RTM kiadásra. A GRC RTM talán őszre lesz kész, de pontos dátm még nem ismert.

Mindez nem tűnik soknak, de ne feledjük, hogy a fenti SMF-ek végrehajtása során rengeteg információ keletkezik a Service Managerben, így a Management Review-k közül jónéhány (Policy & Control, Operational Health, Service Alignment) főleg az SM-ől nyert adatokból, kimutatásokból és jelentésekből táplálkozhat. A folyamatok legfontosabb teljesítmény-indikátoraihoz (Key performance Indicator KPI) külön beépített jelentések találhatók, de SQL Report Builder segítségével tetszőleges más jelentés is elkészíthető. Önmagában ez még mindig kevés lehet. Szerencsére a Service Manager egy kiterjeszthető platform, pontosan olyan könnyen, ahogy az Operations Managerbe importálunk egy új MP-t. Ilyen Management Pack formájában jelenik meg a Provance cég IT Asset Management megoldása, amely több SMF-en is átívelve az IT eszközök (hardver, szoftver, licenc(!)) életciklusát hivatott támogatni. Mindezen képességekkel a Service Manager több is, meg kevesebb is, mint a konkurrensei. Egy példa: a Remedy bizonyosan szofisztikáltabb és összetettebb Helpdesk megoldást biztosít, de nem valószínű, hogy GRC tevékenységeket is támogat.

Amiben – megkockáztatom – erősebb lehet a Service Manager a versenytársainál, az az integráció (és persze első körben a System Center termékekkel való integráció). A 250 PC-nél többel rendelkező szervezetek többségének van Microsoft Enterprise Agreement (vagy más, nagyvállalati) szerződése. Ezen szerződések közel kétharmadában van System Center Configuration Managre (SCCM) CAL. Még ha a megvásárolt és a telepített példányok nem is esnek egybe, azt nem mi mondjuk, hanem a Gartner állítja rólunk, hogy az SCOM és az SCCM a legtöbb példányban használt rendszerfelügyeleti eszköz. Ha ez így van, akkor a Service Managerrel jól járhatnak a korábbi SC termékeket már használó szervezetek: a System Center Service Managerben ugyanis a CMDB (CMS) felépíthető adat-importálással is. Az Active Directoryból a felhasználók és felhasználói csoportok, a Configuration Managerből a hardver és szoftver (+ szoftver frissítési) információk, az Operations Managerből pedig a riasztások kerülhetnek át az SM-be, hogy aztán különböző folyamatokat indíthassanak el, vagy azok hathassanak rájuk. Aki épített már CMDB-t, az tudja értékelni az ilyen kapcsolatokat. Emellett integrációnak tartom azt, hogy SQL szervert használ a termék, azon belül SQL reporting service-t, az önkiszolgáló portál Sharepointtal integrálható, a SM konzol mögött ülők látják az incidens kezdeményezők vagy éppen a támogató mérnökök jelenlét információit  az Office Communications Server segítségével stb. stb.

Ez idáig a technológia. A cikket azzal kezdtem, hogy a terméket nagy várakozások előzték meg. E mögött a várakozás mögött sokszor az az elgondolás húzódik meg, hogy a Service Manager implementálása jobbá teszi majd a folyamatokat, mert kikényszeríti azok végrehajtását. Rossz hírem van! A Service Manager csak technológia. Nem képes a folyamatok kialakítására. Nem képes a MOF félig elméleti félig gyakorlati javaslatainak implementálására. Sőt, a helyzet még ennél is rosszabb. Nem képes a rossz technológiából jót csinálni. Ha az én SCOM rendszerembe ömlenek a felesleges riasztások, akkor a Service Managerben mérhetetlen mennyiségen fognak keletkezni a felesleges incidensek, és értéktelenek lesznek az incidensekről szóló kimutatások. Ha nem tiszta a AD adattartalma, és rég kidobott számítógépek, távozott felhasználókkal van tele a címtár, akkor hibás lesz a hardver leltárunk és rosszul fog kalkulálni a felhasználók számát figyelembe vevő licence modell. Hadd ne folytassam.

Isten ments, hogy valaki Service Manager-t implementáljon!  Tűzze ki célul, hogy egy üzemeltetési vagy támogatási mutatót javítani fog, hogy SLA-t mér, hogy incidens számot csökkent. A Service Manager segíteni fog a mutató kiszámításában, az SLA mérésében. De a Service Manager nem lehet cél.  l’art pour l’art “bevezetésével” semmi nem változik, semmi sem javul, semmi sem lesz jobb. “A fool wth a tool is just a fool”, ahogy az angol mondja. (Egy bolond egy szerszámmal, az csak egy bolond!)

Szóval hajrá MOF, hajrá ITIL, itt van végre egy viszonylag olcsó, friss architektúrával rendelkező, jól integrálódó és az üzemeltetési feladatokat sokrétűen támogató eszköz. De csak egy eszköz, semmi más.

Audit Collection Service

Az ilyen munkát nem szeretem, de néha elkerülhetetlen, és meg kell csinálni. A minap egy kollégám kért az Audit Collection Service szolgáltatásról egy két oldalas vezetői összefoglalót. (Ha már vannak bevezetett fogalmaink: 100-as szintű anyag 🙂 ) Rákerestem, és meglepődve tapasztaltam, hogy magyarul lényegében nincs semmilyen info erről a System Center Operations Manager 2007 komponensről.  (Érdekes egyébként a felhozatal. Első helyen Szalontay Zoli és Fülöp Miki 2005. március 23.-i előadása jön fel. Ez az Audit Collection nem pont az az Adit Collection. Aztán jön Somogyi Csabi TechNet cikke, ahol a kliens felügyeletnél egyetlen mondatban megemlíti, ki sem fejtve, mi is az az ACS. Aztán Varánusz kolléga nem tudta mi lett a MACS-sel. Budai Peti válaszul hivatkozott Kelemen Laci ACS cikkére (az egyetlen részletes anyagra) amit viszont a kereső egyáltalán nem talált meg. Végezetül még ez a webnapló állt elő, mint forrás. Egy alkalommal megemlítettem az Audit Collection adatbázis igényét, még a SCOM nem is végleges változatának kipróbálása idején.

Nem volt mit tennem, készítettem egy két oldalas, kifejezetten vezetőknek szánt, enyhén marketingszagú anyagot. (Az "enyhén" eufemizmus: nagyon marketingszagú). Először nem gondoltam közzétenni, de mivel a célja éppen az, hogy hozzáértők egy előterjesztésben betehessenek két oldalnyi értelmes szöveget a témáról hozzá nem értők számára, gondolom nem bánjátok, ha megosztom. Van, aki hasznát veheti. Kíváncsi vagyok, hogy pár nap múlva mit hoznak a keresők. 🙂

Biztonsági események gyűjtése
(Audit Collection Service)

Bevezető

Napjaink informatikai rendszereinek egyik legnagyobb kihívása a biztonsági problémák kezelése. Szemben más IT feladatokkal, a biztonság kérdése nem oldható meg egyetlen termék megvásárlásával, vagy egyszeri intézkedésekkel. Az informatikai biztonság az általánosan elfogadott megközelítés szerint a kockázatok kezelése méghozzá az IT megoldások (termékek), az IT folyamatok és a szakemberek hatékony összehangolásával.

A biztonsági események gyűjtésének problémái

A biztonsági folyamatok egyik kiemelten fontos eleme az Informatikai rendszerek üzemeltetése során keletkezett biztonsági események (bejelentkezések, biztonsági csoporttagság változások, adott felhasználói jogok érvényesítése stb.) elosztott naplózása, majd e naplóállományok központi adattárba juttatása a lehető leggyorsabb és legbiztonságosabb módon. A szokásos eseménygyűjtő technikák a biztonsági események gyűjtésére alkalmatlanok, mert a két feladat nagyságrendileg eltérő. A hagyományos eseménybejegyzések egy kivételes állapot létrejöttekor keletkeznek, ezzel szemben a biztonsági események folyamatosan ismétlődnek. A „hétköznapi események” többnyire önmagukban állnak, miközben egymással összefüggő biztonsági események akár több rendszerben, elszórtan keletkezhetnek. Végül a normál eseményeket többnyire elegendő néhány hónapig tárolni, míg a biztonsági események archiválását törvényi előírások szabályozhatják, és akár több évig is meg kell őrizni őket.

Az Audit Collection Service

A Microsoft a System Center Operations Manager 2007 rendszerfelügyeleti megoldásába integrálta a biztonsági események hatékony gyűjtésének funkcióját Audit Collection Service (ACS) néven. Az Audit Collection Service felügyelete alatt végfelhasználói munkaállomásokról és felügyelt Windows kiszolgálókról lehet közel valós időben óriási mennyiségű biztonsági eseményt begyűjteni, azokat adatbázisban tárolni, illetve igény szerint lekérdezni. Az ACS-t úgy tervezték, hogy lépést tartson a biztonsági események számának ugrásszerű növekedésével, észlelje az események megváltoztatására, törlésére irányuló kísérleteket. A System Center Operations Manager szerepkör elválasztási képességét kihasználva az ACS teljes egészében különállóan – a biztonsági osztály, vagy külső auditorok által – felügyelhető. Az események archiválását a Microsoft SQL Server adattárház képességei segítik.

Az Audit Collection Service bevezetésének előnyei

Az Audit Collection Service bevezetése egyaránt hordoz technológiai és üzleti előnyöket.

Technológiai előnyök:

·       Az események gyűjtése közel valósidejű. A felügyelt rendszer az eseményeket a keletkezésük pillanatában elkapja és a helyi naplóban való rögzítéssel egyidejűleg továbbítja az ACS gyűjtők felé.

·       Skálázhatóság. Egy ACS rendszer 150 tartományvezérlő, vagy 3000 kiszolgáló vagy 20 000 munkaállomás eseményeit képes begyűjteni. Egy esemény mérete a lehető legkisebb (70 bájt), hogy a naplózás ne terhelje a hálózatot.

·       Biztonságos adattovábbítás. A felügyelt rendszerek kizárólag biztonságos csatornán kommunikálnak a gyűjtő szerverekkel. A gyűjtő kiesése esetén másik kiszolgálóra terelhetők a felügyelt kliensek.

·       Manipulációk felfedezése. Az ACS beépített jelentéseket tartalmaz a biztonsági események manipulálási kísérletek felfedezésére.

·       A SCOM architektúrával való együttélés. Az Audit Collection Services nem igényel külön kliens telepítést, de a SCOM rendszerben az adminisztráció szükség szerint teljesen elkülöníthető. Az ACS jelentések bármikor módosíthatók és újakkal bővíthetők akár saját fejlesztés révén, akár harmadik gyártó megoldásaival.

·       Hatékony tárolás. A nagyon nagy mennyiségű esemény tárolása rendkívül hatékony, mivel a kevés eseménytípust sematizálva tárolja a rendszer.

Üzleti előnyök:

·        Törvényi előírásoknak való megfelelés. A biztonsági események gyűjtését és tárolását külső szabályozó szervek előírhatják. Ezen előírások betartását az ACS magas műszaki színvonalon (skálázhatóság, integritás-védelem stb.) segíti.

·        Felhasználói tevékenység nyomon követése. A begyűjtött eseményekből készített jelentések alapján meghatározható, hogy egy adott felhasználó adott időben milyen tevékenységeket végezett egy vagy több rendszeren.

·        Biztonsági házirendek betartásának ellenőrzése. A biztonsági csoporttagságok változásának figyelésével hozzáférés-szabályozás valósítható meg.

·        Az Auditor és az Adminisztrátor/Operátor szerepkörök elválasztása. A System Center Operations Manager 2007 szerepkör elválasztásai képességei az Audit Collection Service komponensekre is kiterjed. Az auditor szerepkör elválasztása lehetővé teszi, hogy a szándékos károkozó üzemeltetőket fel lehessen fedezni.

·        Behatolási kísérletek felfedezése. A több rendszerből összegyűjtött biztonsági események összevetésével behatolási kísérleteket lehet felfedezni.

A System Center termékcsalád

Ahogy korábban már említettem, a Microsoft Magyarország nagyvállalati ügyfelekkel foglalkozó részlegében (EPG), azon belül a megoldásértékesítő csapatban (STU) dolgozom rendszermérnökként, és többek között, de nem kizárólagosan az összes System Center márkanév alá tartozó termék ismerete a feladatom. Most megnézzük, hogy mi is az a "System Center".

Először 2005-ben találkoztam a névvel, és kezdetben nem volt más, mint az akkor meglévő rendszerfelügyeleti termékek jelzés-szerű összevonása. A megfogalmazás azért nem pontos, mert megjelent még egy kiegészítő termék is már igaz "system center" előtaggal. Valahogy így:

System Center 2005 termékcsalád:

• Microsoft Operations Manager 2005 (rövid nevén: MOM 2005)
• Systems Management Server 2003 (rövid nevén: SMS 2003)
• System Center Reporting Server 2005

A három terméket együtt is meg lehetett vásárolni, természetesen kedvezménnyel. A korszakból egy hír itt olvasható.

A következő évben már kiteljesedett a termékcsalád néhány új, elsőgenerációs alkalmazással, és így nézett ki a portfólió (Korabeli tudósítás itt):

• Microsoft Operations Manager 2005 (rövid nevén: MOM 2005)
• Systems Management Server 2003 R2 (rövid nevén: SMS 2003 R2)
• System Center Reporting Manager 2006
• System Center Capacity Planner 2006
• System Center Data Protection Manager 2006

Az igazi áttörés azonban a 2007-es év. A két legfontosabb termék megújul és a DSI alapját képező SDM technológia megjelenik bennük, az első generációs alkalmazásokat lecseréljük második generációsra, és egy újabb "hullám" első generációs megoldásunk érkezik olyan friss vállalati szabványokkal, mint a WS-Management és a Powershell támogatás. Nézzük, hogyan fest a System Center termékcsalád 2007-ben:

• System Center Operations Manager 2007 (Rövid nevén: SCOM 2007. a MOM 2005 utódja)
• System Center Remote Operations Manager 2007
• System Center Engyro
• System Center Desktop Error Monitoring
• System Center Essentials 2007
• System Center Configuration Manager 2007 (Rövid nevén: SCCM 2007, az SMS 2003 utódja)
• System Center Virtual Application Server
• System Center Capacity Planner 2007
• System Center Data Protection Manager 2007
• System Center Virtual Machine Manager 2007

A Virtual Machine Manager "nagy" terméknek néz ki már most is, de a dolognak azonban koránt sincs vége, 2008-ban ugyanis egy újabb zászlóshajó indulhat el:

• System Center Service Manager 2008

A 2007-es generáció tagjait majd külön-külön is bemutatom.

Frissítés:

Megfeledkeztem róla, hogy a System Center nem csak termék, hanem szolgáltatás is. Pár hónapon belül elérhető lesz a

• System Center Online Services

SCOM 2007 adatbázisok méretezése

Egy alapos cikk a System Center Operations Manager 2007 adatbázisainak méretezéséhez.  Adatbázisainak? Igen, mert három adatbázis is tartozik a SCOM 2007-hez: az operatiív adatbázis, az adattárház és az audit események adatbázisa. Aki méretezni szeretne egy ilyen rendszert, ez a cikk jó kiindulópont

Quote

Estimating Database Sizes for OpsMgr 2007

• OpsDB 
• Data Warehouse DB
• ACS DB

Update:

Jó lenne egy Excel táblázat a méretezés elvégzéséhez? Ez is elkészült már, Ian Blyth munkája. Letölthető innen: http://systemcenterforum.org/wp-content/uploads/SCOM2007DBestimatorv1.xls

PowerGUI

Egy valamire való Windows rendszergazda minden parancssoros felületre talál GUI-t .

Viccet félretéve. A Powershell egyszerre hívogató és riasztó. Tudjuk, hogy meg kell tanulnunk, de amint a kezünk közé kerül, rögtön a kattintgatós világ tetszik jobban. A kacérkodó visszahőkölőknek adhat lökést a PowerGUI nevű kis eszköz. Ez egy beépülő modulokkal bővíthető, ingyenes grafikus felület, amelynek a segítségével jónéhány tevékenység grafikus felületen jelenik meg, ám bárki átkattinthat a ‘PowerShell Code’ fülre, és máris ott virít, hogy milyen kód fut a grafika mögött. A kezdő powershellesek álma, hiszen ez az eszközke épp azt a átmenetet biztosítja számukra, amely a GUI alapú üzemeltetésről a parancssor alapúra vezet. Az oldalon van egy rövid kis bemutató, amely munka közben mutatja meg, mit tud a PowerGUI. Ha érdekel, tölts le. Ingyenes.

A System Center Operation Manager kliens felügyeleti lehetőségei

A TechNet napon alig érintettük a témát, ezért érdemes pár mondatot szentelni rá. A System Center Operation Manager 2007 az első olyan termék, amelyet kifejezetten úgy terveztek, hogy a desktopok felügyeletét is képes legyen elvégezni. A megoldás három alapszituáció kiszolgálására készült.

1. Agentless Exception Monitoring (AEM)

A desktop gépekre nem kerül fel Operation Manager ügynök, viszont a gépeket úgy konfiguráljuk, hogy az alkalmazások összeomlásáról automatikusan elkészülő műszaki adatokat az Operation Manager megkapja. Az adatokat opcionálisan tovább lehet küldeni a Microsoft felé. A beküldött adatokból statisztikai jelentéseket lehet készíteni. A beépített jelentések segítségével meg lehet becsülni az összeomlások költségét (költség rendelhető egy adott összeomláshoz), az összeomlások trendje elemezhető, továbbá gépenként láthatjuk a hibák és összeomlások számát. Az AEM nem igényel Operation Manager Client CAL-t.

(Ismerős lehet a funkció, korábban úgy hívták, hogy Corporate Error Reporting, és azon Microsoft felhasználók juthattak hozzá, akik frissítési garanciával vásárolták meg az MS licenceket)

2. Collective Health Monitoring (CHM)

Ebben a szituációban a desktop gépekre Operation Manager 2007 ügynök kerül, de a gépek csak összegző jellegű információkat küldenek, illetve csak a legkritikusabb hibákat jelzik. Az Operation Manager – ahogy az a szituáció nevéből látható – a desktopok kollektív egészségét vizsgálja, nem cél egy egyes gépeket kezelni. Az ilyen üzemmódhoz tartozó jelentések is összegző jellegűek. A gépcsoportokra vonatkozó jelentések a dektopokkal kapcsolatos szolgáltatási szint szerződések megkötésekor és ellenőrzésekor használhatók. A CHM használatba vételéhez Operation Manager 2007 Client CAL szükséges.

3. Business Critical Desktop Monitoring (BCDM)

Ebben a szituációban a klienseket úgy kezeljük, mintha szerverek lennének, tehát minden – rájuk jellemző – információt gyűjtünk, elemzünk és értékelünk. A gépekre Operation Manager 2007 ügynök kerül, és annak központi beállításától függ, hogy CHM vagy BCDM „üzemmódban” működik-e. A BCDM szituációt elsősorban ATM-ek, ügyfélszolgálati gépek, gyártósori vezérlőgépek esetén célszerű alkalmazni, vagyis olyankor, amikor a desktop rendelkezésre állása és teljesítménye közvetlen hatást gyakorol az üzleti folyamatra. A BCDM használatba vételéhez Operation Manager 2007 Client CAL szükséges.

A második és harmadik szituációt az Operation Manager 2007 két, beépített Management Pack segítségével támogatja. Ezek a „Windows Management Pack” és a „Information Worker Management Pack”. Az első Windows 2000/XP/Vista, a második Internet Explorer 5, 6, 7, Office 2000, XP, 2003, 2007-hez használható. A legfontosabb képességeik az alábbiak. (Nem teljes lista!)

Windows Management Pack:

1. Szervíz rendelkezésre állás figyelése
2. Szervíz hibák észlelése
3. Tárolórendszer rendelkezésre állás figyelése (csak Vista)
4. Tárolórendszer kapacitás problémák (csak Vista)
5. Alrendszer teljesítmény problémák észlelése
6. Shell teljesítmény (csak Vista)
7. Lemez- és memória meghibásodások (csak Vista)
8. Aggregált riportok (Desktop Memory Report, Desktop Disk Heath Report, Desktop Performance stb.)
9. Vista Specifikus riportok (Memória probléma jelentés, Diszkhasználat, indítási/leállítási idő stb.)

Information Worker Management Pack

1. Internet Explorer site rendelkezésre állás
2. Outlook Mail rendelkezésre állás
3. Files Server és file rendelkezésre állás
4. Adatforrás (adatbázis) rendelkezésre állás