Ha egy meglévő Cognos környezetet egy másik külső biztonsági forrás (pl. Active Directory, LDAP, stb.) Használatára kell konfigurálnia, akkor néhány módszer közül választhat. Szeretem őket "jónak, rossznak és csúfnak" nevezni. Mielőtt felfedeznénk ezeket a jó, rossz és csúnya megközelítéseket, nézzünk meg néhány gyakori forgatókönyvet, amelyek hajlamosak a hitelesítési névtér változásaira Cognos környezetben.
Közös üzleti meghajtók:
Hardver vagy operációs rendszer frissítése - A BI hardver/infrastruktúra modernizálása gyakori hajtóerő lehet. Míg a többi Cognos futhat, mint egy bajnok az elegáns új hardverén és a modern 64 bites operációs rendszeren, sok sikert kíván az Access Manager 2005-ös verziójának áttelepítéséhez az új platformra. Az Access Manager (először a 7. szériával együtt megjelent) sok Cognos -ügyfél tiszteletreméltó birtoklása az elmúlt napokban. Ez az egyetlen oka annak, hogy sok ügyfél a Windows Server 2003 durva régi verzióját tartja körül. Az írás már jó ideje a falra került az Access Manager számára. Ez egy régi szoftver. Minél hamarabb távolodhat el tőle, annál jobb.
Alkalmazás szabványosítás- Azok a szervezetek, akik minden alkalmazásuk hitelesítését egy központilag felügyelt vállalati címtárkiszolgálón (pl. LDAP, AD) szeretnék megszilárdítani.
Fúziók és felvásárlások- Az A vállalat megvásárolja a B vállalatot, és szüksége van a B vállalat Cognos környezetére, hogy mutasson az A vállalat címtárszerverére, anélkül, hogy problémákat okozna a meglévő BI tartalmával vagy konfigurációjával.
Vállalati elidegenítések- Ez ellentétes az egyesülési forgatókönyvvel, egy vállalat egy része saját egységgé válik, és most meg kell mutatnia a meglévő BI környezetet az új biztonsági forrás felé.
Miért lehetnek rendetlenek a névtér -áttelepítések?
A Cognos környezetet egy új biztonsági forrásra mutatni nem olyan egyszerű, mint az új névtér hozzáadása ugyanazokkal a felhasználókkal, csoportokkal és szerepekkel, a régi névtér és a VOILA leválasztása!- az összes névtérbeli Cognos-felhasználó illeszkedik tartalmukat. Valójában gyakran véres zűrzavarba kerülhet a keze, és ez az oka annak, hogy…
A Cognos összes biztonsági elvére (felhasználók, csoportok, szerepkörök) egy egyedi azonosító hivatkozik, amelyet CAMID -nek hívnak. Még akkor is, ha az összes többi attribútum egyenlő, a CAMID egy felhasználóhoz az létező a hitelesítési névtér nem ugyanaz, mint az adott felhasználó CAMID -je a új névtér. Ez tönkreteheti a meglévő Cognos környezetet. Még akkor is, ha csak néhány Cognos felhasználója van, tudnia kell, hogy a CAMID -hivatkozások a Tartalomáruház SOK különböző helyén léteznek (és akár a Content Store -n kívül is létezhetnek keretmodellekben, transzformátormodellekben, TM1 -alkalmazásokban, kockákban, tervezési alkalmazásokban stb.) ).
Sok Cognos -ügyfél tévesen úgy gondolja, hogy a CAMID valóban csak a Saját mappa tartalmára, felhasználói preferenciáira stb. Vonatkozik. Ez nem lehet távolabb az igazságtól. Nem csak a felhasználók számáról van szó, hanem a Cognos objektumok mennyiségéről is. A Tartalomtárban több mint 140 különböző típusú Cognos objektum található, amelyek közül soknak több CAMID -referenciája is lehet.
Például:
- Nem ritka, hogy a Tartalomáruház egyetlen ütemezésében több CAMID -referencia is szerepel (az ütemezés tulajdonosának CAMID -je, a felhasználó CAMID -je, amelyet az ütemtervnek kell futtatnia, minden felhasználó vagy terjesztési lista CAMID -je, amelyhez e -mailben kell küldeni a generált jelentéskimenetet) stb.).
- A Cognos minden objektumának biztonsági házirendje van, amely szabályozza, hogy mely felhasználók férhetnek hozzá az objektumhoz (gondoljon az „Engedélyek fülre”). A Cognos Connection ezen a mappáján egyetlen biztonsági házirend rendelkezik CAMID hivatkozással az adott házirendben meghatározott minden felhasználóra, csoportra és szerepkörre.
- Remélhetőleg érted a lényeget - ez a lista folytatódik!
Nem ritka, hogy egy jókora tartalomtároló több tízezer CAMID -referenciát tartalmaz (és láttunk néhány nagy, százezres referenciát).
Most számolj azzal, ami benne van a te Cognos környezetben, és láthatja, hogy potenciálisan CAMID -hivatkozások hordáival van dolga. Rémálom lehet! A hitelesítési névtér átkapcsolásával (vagy újrakonfigurálásával) mindezek a CAMID-hivatkozások megoldhatatlan állapotban maradhatnak. Ez elkerülhetetlenül Cognos tartalom- és konfigurációs problémákhoz vezet (pl. Ütemezések, amelyek már nem futnak, olyan tartalom, amely már nem biztosított az Ön szerint, csomagok vagy kockák, amelyek már nem megfelelően hajtják végre az adatszintű biztonságot, a Saját mappa tartalmának és felhasználójának elvesztése preferenciák stb.).
Cognos névtér átmeneti módszerek
Most, annak tudatában, hogy egy Cognos környezet több tízezer CAMID -hivatkozást tartalmazhat, amelyek megkövetelik a megfelelő új CAMID -érték megtalálását, leképezését és frissítését az új hitelesítési névtérben, beszéljük meg a probléma megoldásának jó, rossz és csúnya megközelítéseit.
A Good: Névtér helyettesítése Persona -val
Az első módszer (Namespace Replacement) használja Motio„S, Persona IQ termék. Ezt a megközelítést alkalmazva a meglévő névteret „lecseréli” egy speciális Persona névtérre, amely lehetővé teszi a Cognos -nak kitett összes biztonsági elv virtualizálását. A már meglévő biztonsági elvek ugyanolyan CAMID-nak vannak kitéve a Cognos-nak, mint korábban, annak ellenére, hogy bármilyen külső biztonsági forrással (pl. Active Directory, LDAP vagy akár a Persona adatbázis) is támogathatók.
Ennek a megközelítésnek az a szép része, hogy NULLA változtatásokat igényel a Cognos tartalmában. Ennek az az oka, hogy a Persona képes fenntartani a már meglévő megbízók CAMID-jeit, még akkor is, ha új források támogatják őket. Szóval ... mindaz a tízezer CAMID -referencia a tartalomtárban, külső modellek és történelmi kockák? Pontosan úgy maradhatnak, ahogy vannak. Nincs szükség munkára.
Ez messze a legkevésbé kockázatos, legalacsonyabb hatású megközelítés, amellyel meglévő Cognos környezetét egyik külső biztonsági forrásról a másikra válthatja. Ez egy óra alatt elvégezhető, körülbelül 5 perces Cognos leállással (az egyetlen Cognos állásidő a Cognos újraindítása, miután konfigurálta a Persona névteret).
A Bad: Névtér migráció a Persona használatával
Ha az egyszerű, alacsony kockázatú megközelítés nem a teája, akkor ott van is egy másik lehetőség.
A Persona névtér -áttelepítésre is használható.
Ez magában foglalja egy második hitelesítési névtér telepítését a Cognos környezetbe, (remélhetőleg) az összes meglévő biztonsági elv (a régi névtérből) hozzárendelését az új névtér megfelelő elveihez, majd (itt a szórakoztató rész), az összes megtalálását, feltérképezését és frissítését egyetlen CAMID -referencia, amely létezik a Cognos környezetében: a tartalomtár, a keretmodellek, a transzformátormodellek, a történelmi kockák, a TM1 -alkalmazások, a tervezési alkalmazások stb.
Ez a megközelítés általában stresszes és folyamatigényes, de ha Ön az a fajta Cognos -adminisztrátor, akinek szüksége van egy kis adrenalin -rohamra, hogy életben érezze magát (és nem bánja a késő esti / kora reggeli telefonhívásokat), akkor talán… ezt az opció amit keresel?
A Persona segítségével automatizálhatók ennek a folyamatnak a részei. Segítségével leképezést hozhat létre a régi biztonsági elvek és az új biztonsági elvek között, automatizálhatja a tartalomtároló tartalmának nyers erő „megtalálása, elemzése, frissítése” logikáját stb. ebben a megközelítésben a munka az „embereket és folyamatokat” foglalja magában, nem pedig a tényleges technológiát.
Például - rengeteg munka lehet összegyűjteni az információkat minden Framework Manager modellről, minden Transformer modellről, minden Planning / TM1 alkalmazásról, minden SDK alkalmazásról, hogy ki a tulajdonosuk, és megtervezni, hogyan frissítik és újra elosztják. A kimaradások összehangolása minden Cognos környezetben, amelyet meg szeretne próbálni, és a karbantartási ablakok, amelyek során megpróbálhatja az áttelepítést, magában foglalhatja a tervezést és a Cognos „leállási időt”. Az áttelepítés utáni hatékony tesztterv kidolgozása (és végrehajtása) szintén medve lehet.
Az is teljesen normális, hogy ezt a folyamatot először nem termelési környezetben szeretné elvégezni előtt kipróbálni a gyártásban.
Míg a névtér -migráció a személyekkel működik (és sokkal jobb, mint az alábbi „Csúnya” megközelítés), sokkal invazívabb, kockázatosabb, sokkal több személyzetet foglal magában, és sokkal több emberórát vesz igénybe, mint a névtér -csere. Jellemzően az áttelepítéseket a „nyitvatartási időben” kell elvégezni, miközben a Cognos környezet még mindig online, de a végfelhasználók korlátozott űrlaphasználatot végeznek.
Az Ugly: Kézi névtér -áttelepítési szolgáltatások
A Csúnya módszer magában foglalja az irigylésre méltó megközelítést kézzel válasszon át egy hitelesítési névtérből a másikba. Ez magában foglalja egy második hitelesítési névtér csatlakoztatását a Cognos környezethez, majd a meglévő Cognos tartalom és konfiguráció nagy részének manuális áthelyezését vagy újratelepítését.
Például ezt a megközelítést alkalmazva a Cognos rendszergazda megpróbálhatja:
- Hozza létre újra a csoportokat és szerepeket az új névtérben
- Létrehozza e csoportok és szerepek tagságát az új névtérben
- Másolja manuálisan a mappáim tartalmát, felhasználói beállításait, portál lapjait stb. Minden forrásfiókból minden célfiókba
- Keresse meg a házirend -készleteket a Tartalomtárban, és frissítse őket az új névtérben lévő egyenértékű elvekre, ugyanúgy, ahogyan a régi névtérbeli elvekre hivatkozott.
- Hozza létre újra az összes ütemtervet, és töltse ki őket megfelelő hitelesítő adatokkal, címzettekkel stb.
- Állítsa vissza a Tartalomtárban található összes objektum „tulajdonos” és „kapcsolat” tulajdonságát
- [Körülbelül 40 egyéb dolog a Tartalomboltban, amelyeket elfelejtesz]
- Gyűjtse össze az összes FM -modellt objektum- vagy adatszintű biztonsággal:
- Ennek megfelelően frissítse az egyes modelleket
- Tegye újra közzé az egyes modelleket
- A módosított modellt terjessze vissza az eredeti szerzőnek
- Hasonló munka a transzformátor modellek, a TM1 alkalmazások és a tervezési alkalmazások számára, amelyek az eredeti névtérrel szemben védettek
- [és még sok más]
Míg néhány Cognos mazochista titokban felröhöghet örömében azon a gondolaton, hogy 400,000 XNUMX alkalommal kattintanak a Cognos Connection szolgáltatásban, a legtöbb értelmes ember számára ez a megközelítés rendkívül unalmas, időigényes és hibalehetőséget okoz. Ezzel a megközelítéssel azonban nem ez a legnagyobb probléma.
A legnagyobb probléma ezzel a megközelítéssel az, hogy majdnem mindig hiányos migrációhoz vezet.
Ezzel a megközelítéssel (fájdalmasan) megtalálja és megpróbálja feltérképezni azokat a CAMID -hivatkozásokat, amelyekről tud ... de hajlamos az összes CAMID -referencia elhagyására. nem tud róla.
Miután Szerintem Ha befejezte ezt a megközelítést, gyakran nem tényleg Kész.
Vannak olyan tárgyai a tartalomtárban, amelyek már nincsenek úgy védve, ahogyan Ön gondolja ... vannak olyan ütemezései, amelyek nem úgy működnek, mint korábban, vannak olyan adatai, amelyek már nem úgy vannak védve, ahogy gondolja ez az, és bizonyos műveleteknél megmagyarázhatatlan hibák is előfordulhatnak nem nagyon tudod rátenni az ujjad.
A rossz és csúnya megközelítések félelmetes okai:
- Az automatikus névtér -áttelepítés nagy terhet ró a Tartalomkezelőre. A Tartalomáruház minden egyes objektumának ellenőrzése és esetleges frissítése gyakran több tízezer SDK -hívást eredményezhet a Cognos -ba (amelyek gyakorlatilag mindegyike a Tartalomkezelőn keresztül történik). Ez a rendellenes lekérdezés általában megnöveli a memóriahasználatot / terhelést, és a tartalomkezelőt összeomlás veszélye fenyegeti az áttelepítés során. Ha már bármilyen mértékű instabilitás tapasztalható a Cognos környezetében, nagyon félnie kell ettől a megközelítéstől.
- A névtér -áttelepítésekhez jelentős karbantartási idő szükséges. A Cognos -nak fent kell lennie, de nem szeretné, ha az emberek változtatnának az áttelepítési folyamat során. Ez általában megköveteli, hogy a névtér áttelepítése akkor kezdődjön el, amikor senki más nem dolgozik, mondjuk péntek este 10 órakor. Senki nem akar stresszes projektbe kezdeni péntek este 10 órakor. Arról nem is beszélve, hogy a mentális képességeid valószínűleg nem a legjobb munkaéjszakákon és hétvégéken dolgoznak egy projekten nem megköveteli, hogy éles legyél!
- Már említettem, hogy a névtér -migráció idő- és munkaigényes. Itt egy kicsit bővebben erről:
- A tartalomleképezési folyamatot pontosan kell elvégezni, és ez csapatmunkát és sok munkaórát igényel.
- Többszöri szárazonfutásra van szükség az áttelepítés hibáinak vagy problémáinak ellenőrzéséhez. Egy tipikus migráció első próbálkozásra nem megy tökéletesen. Szüksége lesz a tartalomtároló érvényes biztonsági mentésére is, amely ilyen esetekben visszaállítható. Sok olyan szervezetet láttunk, amelyek nem rendelkeznek jó biztonsági mentéssel (vagy vannak olyan biztonsági mentések, amelyekről nem tudják, hogy hiányosak).
- Mindent azonosítani kell kívül a tartalomtároló, amelyet potenciálisan érinthet (keretmodellek, transzformátor modellek stb.). Ez a feladat magában foglalhatja több csapat közötti koordinációt (különösen nagy, megosztott BI környezetekben).
- Szüksége van egy jó teszttervre, amely magában foglalja a reprezentatív embereket, akik különböző mértékben férnek hozzá Cognos -tartalmaihoz. A legfontosabb itt az, hogy röviddel az áttelepítés befejezése után ellenőrizze, hogy minden teljesen áttelepült és a várt módon működik. Jellemzően nem praktikus mindent ellenőrizni, így végül ellenőrizni fogja, hogy reményei szerint reprezentatív minták.
- Biztosan van broad a Cognos környezet és a tőle függő dolgok ismerete. Például az egyéni nézetekkel rendelkező történelmi kockákat újra kell építeni, ha az NSM útvonalat választja.
- Mi a teendő, ha Ön vagy az a cég, amelyet a névtér áttelepítésével kiszervezett, elfelejt valamit, például… SDK -alkalmazásokat? Miután elfordította a kapcsolót, ezek a dolgok leállnak, ha nem frissítik megfelelően. Rendelkezik a megfelelő ellenőrzésekkel, hogy ezt azonnal észrevegye, vagy több hét / hónap múlva jelentkeznek a tünetek?
- Ha számos Cognos frissítésen esett át, akkor előfordulhat, hogy a Tartalomtárban objektumok vannak, amelyek inkonzisztens állapotban vannak. Ha nem az SDK -val dolgozik, akkor nem láthatja, hogy mely objektumok vannak ebben az állapotban.
Miért a legjobb lehetőség a névtér cseréje
Az általam felvázolt legfontosabb kockázati tényezők és időigényes lépések kiküszöbölhetők a Persona Namespace Replacement módszer használatakor. A névtér -csere módszerrel 5 perc Cognos -állásidő áll rendelkezésre, és semmilyen tartalomnak nem kell megváltoznia. A „jó” módszer számomra vágott és száraz „értelmetlen”. A péntek esték a pihenésre szolgálnak, nem pedig azon, hogy a tartalomkezelő éppen lezuhant a névtér áttelepítésének közepette.
