Ko morate znova konfigurirati obstoječe okolje Cognos za uporabo drugega zunanjega varnostnega vira (npr. Active Directory, LDAP itd.), Lahko uporabite nekaj pristopov. Rad jih imenujem "dobri, slabi in grdi." Preden raziščemo te dobre, slabe in grde pristope, si oglejmo nekaj pogostih scenarijev, ki ponavadi povzročijo spremembe imenskega prostora za preverjanje pristnosti v okolju Cognos.
Pogosti poslovni gonilniki:
Posodabljanje strojne opreme ali operacijskega sistema - Posodobitev strojne opreme/infrastrukture BI je lahko pogost dejavnik. Medtem ko lahko preostali del programa Cognos deluje kot prvak v vaši elegantni novi strojni opremi in sodobnem 64-bitnem operacijskem sistemu, pa veliko sreče pri selitvi vaše različice programa Access Manager iz leta 2005 na to novo platformo. Access Manager (prvič izdan s serijo 7) je za mnoge stranke Cognos časten prelomnik iz preteklih dni. To je edini razlog, da se številne stranke obdržijo te krute stare različice operacijskega sistema Windows Server 2003. Pisanje za Access Manager je že dolgo v steni. Gre za starejšo programsko opremo. Prej ko se lahko od nje odmaknete, bolje je.
Standardizacija aplikacij- Organizacije, ki želijo združiti preverjanje pristnosti vseh svojih aplikacij na enem centralno upravljanem strežniku podjetij (npr. LDAP, AD).
Združitve in prevzemi- Podjetje A kupi podjetje B in potrebuje okolje Cognos podjetja B, da pokaže na imeniški strežnik podjetja A, ne da bi povzročilo težave pri obstoječi vsebini ali konfiguraciji BI.
Korporativna odstopanja- To je nasprotje scenarija združitve, del podjetja se odcepi v svoj subjekt in mora zdaj svoje obstoječe okolje BI usmeriti v nov vir zaščite.
Zakaj so selitve imenskega prostora lahko zmedene
Usmeritev okolja Cognos na nov vir zaščite ni tako preprosta kot dodajanje novega imenskega zapisa z istimi uporabniki, skupinami in vlogami, prekinitev povezave s starim imenskim prostorom in VOILA!- vsi vaši uporabniki Cognos v novem imenskem prostoru se ujemajo z njihovo vsebino. Pravzaprav se lahko pogosto konča s krvavim neredom na rokah, in evo zakaj ...
Na vse varnostne principale Cognos (uporabnike, skupine, vloge) se sklicuje edinstven identifikator, imenovan CAMID. Tudi če so vsi drugi atributi enaki, CAMID za uporabnika v obstoječih imenski prostor za preverjanje pristnosti ne bo enak CAMID za tega uporabnika v novo imenski prostor. To lahko uniči obstoječe okolje Cognos. Tudi če imate le nekaj uporabnikov programa Cognos, se morate zavedati, da reference CAMID obstajajo na MNOGIH različnih mestih v vaši trgovini z vsebinami (in lahko obstajajo celo zunaj vaše shrambe vsebine v modelih Framework, modelih transformatorjev, aplikacijah TM1, kockah, aplikacijah za načrtovanje itd.) ).
Mnogi kupci Cognosa pomotoma menijo, da je CAMID res pomemben le za vsebino Moje mape, nastavitve uporabnikov itd. To ne more biti dlje od resnice. Ne gre samo za število uporabnikov, ampak za količino predmetov Cognos, ki jih morate skrbeti. Samo v trgovini z vsebinami je več kot 140 različnih vrst objektov Cognos, od katerih imajo mnogi lahko več referenc CAMID.
Na primer:
- Nič nenavadnega ni, da ima en sam razpored v vaši trgovini z vsebinami več referenc CAMID (CAMID lastnika razporeda, CAMID uporabnika, ki naj bi se urnik izvajal kot, CAMID vsakega uporabnika ali distribucijskega seznama, na katerega bi moral poslati poročilo po e -pošti itd.).
- Vsak predmet v Cognosu ima varnostno politiko, ki določa, kateri uporabniki lahko dostopajo do objekta (pomislite na zavihek »Dovoljenja«). En sam varnostni pravilnik, ki visi za to mapo v Cognos Connection, ima referenco CAMID za vsakega uporabnika, skupino in vlogo, ki je podana v tem pravilniku.
- Upajmo, da razumete bistvo - ta seznam se lahko nadaljuje!
Nič nenavadnega ni, da velika trgovina z vsebinami vsebuje na desetine tisoč referenc CAMID (in videli smo nekaj velikih z več sto tisoč).
Zdaj pa izračunaj, kaj je notri vaš Cognos in vidite, da imate potencialno opravka s hordami referenc CAMID. Lahko je nočna mora! Če preklopite (ali znova konfigurirate) svoj imenski prostor za preverjanje pristnosti, lahko vse te reference CAMID ostanejo v nerazrešljivem stanju. To neizogibno vodi v težave z vsebino in konfiguracijo programa Cognos (npr. Razporedi, ki se ne izvajajo več, vsebina, ki ni več zavarovana, kot mislite, paketi ali kocke, ki ne izvajajo več pravilno varnosti na ravni podatkov, izguba vsebine Moje mape in uporabnika preference itd.).
Metode prehoda imenskega prostora Cognos
Zdaj, ko vemo, da ima lahko okolje Cognos na desetine tisoč referenc CAMID, ki bodo zahtevale iskanje, preslikavo in posodabljanje na ustrezno vrednost CAMID v novem imenskem prostoru za preverjanje pristnosti, se pogovorimo o pristopih dobrega, slabega in grdega za rešitev tega problema.
Dobro: Zamenjava imenskega prostora s Persono
Prva metoda (zamenjava imenskega prostora) uporablja Motio's, Osebni IQ izdelek. S tem pristopom se vaš obstoječi imenski prostor "nadomesti" s posebnim imenskim prostorom Persona, ki vam omogoča, da virtualizirate vse varnostne principale, ki so izpostavljeni Cognosu. Obstoječi varnostni ravnatelji bodo izpostavljeni Cognosu z enakim CAMID-om kot doslej, čeprav so lahko podprti s številnimi zunanjimi varnostnimi viri (npr. Active Directory, LDAP ali celo zbirko podatkov Persona).
Lep del tega pristopa je, da zahteva nič sprememb vsebine Cognos. To je zato, ker lahko Persona vzdržuje CAMID-jeve že obstoječe ravnatelje, tudi če so podprti z novim virom. Torej… vseh teh deset tisoč referenc CAMID v vaši trgovini z vsebinami, zunanjih modelov in zgodovinskih kock? Lahko ostanejo točno takšni, kot so. Delo ni potrebno.
To je daleč najmanj tvegan pristop z najmanjšim vplivom, ki ga lahko uporabite za prehod obstoječega okolja Cognos iz enega zunanjega varnostnega vira v drugega. To je mogoče storiti v manj kot eni uri s približno 5 minutami izpadov programa Cognos (edini čas izpada programa Cognos je ponovni zagon programa Cognos, ko konfigurirate imenski prostor Persona).
Bad: Migracija imenskega prostora z uporabo Persona
Če enostaven pristop z nizkim tveganjem ni le vaša skodelica čaja, potem obstaja is druga možnost.
Persona se lahko uporablja tudi za selitev imenskega prostora.
To vključuje namestitev drugega imenskega prostora za preverjanje pristnosti v vašem okolju Cognos, preslikavo (upajmo) vseh vaših obstoječih varnostnih ravnateljev (iz starega imenskega prostora) v ustrezne ravnatelje v novem imenskem prostoru, nato (tukaj je zabaven del), iskanje, preslikavo in posodabljanje vsakega ena referenca CAMID, ki obstaja v vašem okolju Cognos: vaša trgovina vsebin, okvirni modeli, modeli transformatorjev, zgodovinske kocke, aplikacije TM1, aplikacije za načrtovanje itd.
Ta pristop je ponavadi stresen in procesno intenziven, če pa ste tak administrator Cognosa, ki potrebuje malo adrenalina, da se počuti živo (in ne moti poznih nočnih / zgodnjih jutranjih telefonskih klicev), potem morda ... ta je možnost, ki jo iščete?
Persona se lahko uporabi za avtomatizacijo delov tega procesa. Pomagal vam bo ustvariti preslikavo med starimi in novimi varnostnimi ravnatelji, avtomatizirati grobo silo logike "poišči, analiziraj, posodobi" vsebino v svoji trgovini z vsebinami itd. Kaj lahko Persona avtomatizira nekatere naloge tukaj, veliko delo pri tem pristopu vključuje "ljudi in proces" namesto dejanske tehnologije.
Na primer - zbiranje informacij o vsakem modelu Framework Manager, vsakem modelu Transformer, vsaki aplikaciji Planning / TM1, vsaki aplikaciji SDK, kdo je njihov lastnik, in načrtovanje, kako bodo posodobljeni in razdeljeni, je lahko veliko dela. Usklajevanje izpadov za vsako od okolij Cognos, v katerem želite to poskusiti, in vzdrževalna okna, v katerih lahko poskusite seliti, lahko vključujejo načrtovanje in "čas pomanjkanja" programa Cognos. Priprava (in izvedba) učinkovitega preskusnega načrta za vašo selitev je lahko prav tako medved.
Prav tako je povsem normalno, da boste ta postopek najprej želeli izvesti v neproizvodnem okolju pred poskusite v proizvodnji.
Migracija imenskega prostora s Persono sicer deluje (in je veliko boljša od spodnjega pristopa »Grda«), vendar je bolj invazivna, bolj tvegana, vključuje veliko več osebja in za njeno izvedbo je potrebnih veliko več delovnih ur kot zamenjava imenskega prostora. Običajno je treba selitve izvajati v času "izven delovnega časa", medtem ko je okolje Cognos še vedno na spletu, vendar ga končni uporabniki omejujejo.
Ugly: Ročne storitve selitve imenskega prostora
Metoda Ugly vključuje nezavidljiv pristop poskušanja ročno preseliti iz enega imenskega prostora za preverjanje pristnosti v drugega. To vključuje povezavo drugega imenskega prostora za preverjanje pristnosti v okolje Cognos, nato pa poskusite ročno premakniti ali znova ustvariti večino obstoječe vsebine in konfiguracije Cognos.
S tem pristopom lahko skrbnik Cognos na primer poskusi:
- Ponovno ustvarite skupine in vloge v novem imenskem prostoru
- Ponovno ustvarite članstva teh skupin in vloge v novem imenskem prostoru
- Ročno kopirajte vsebino mojih map, uporabniške nastavitve, zavihke portala itd. Iz vsakega izvornega računa v vsak ciljni račun
- Poiščite vsak nabor pravilnikov v shrambi vsebine in ga posodobite tako, da se sklicuje na enakovredne principale v novem imenskem prostoru na popolnoma enak način, kot se je skliceval na ravnatelje iz starega imenskega prostora
- Ponovno ustvarite vse razporede in jih napolnite z ustreznimi poverilnicami, prejemniki itd.
- Ponastavi vse lastnosti »lastnik« in »stik« vseh predmetov v shrambi vsebine
- [Približno 40 drugih stvari v trgovini z vsebinami, na katere boste pozabili]
- Zberite vse modele FM z zaščito predmetov ali podatkovnih ravni:
- Vsak model ustrezno posodobite
- Ponovno objavite vsak model
- Prerazporedite spremenjeni model nazaj k prvotnemu avtorju
- Podobno deluje za modele Transformer, aplikacije TM1 in aplikacije za načrtovanje, ki so zavarovane pred prvotnim imenskim prostorom
- [in še veliko več]
Medtem ko bi se nekateri mazohisti Cognosa na skrivaj smejali od veselja ob ideji, da bi v Cognos Connection kliknili 400,000 krat, je za večino razumnih ljudi ta pristop ponavadi zelo dolgočasen, dolgotrajen in nagnjen k napakam. Vendar to ni največji problem tega pristopa.
Največja težava tega pristopa je, da je skoraj vedno vodi v nepopolno selitev.
S tem pristopom (boleče) poiščete in poskušate preslikati tiste reference CAMID, ki jih poznate ... vendar običajno pustite vse te reference CAMID, ki jih ne vem za.
Ko mislim s tem pristopom ste končali, pogosto niste res storiti.
V trgovini z vsebinami imate predmete, ki niso več zavarovani tako, kot mislite, da so ... imate urnike, ki ne tečejo tako, kot so se izvajali nekoč, imate podatke, ki niso več zavarovani tako, kot mislite tako je in morda imate celo nepojasnjene napake pri določenih operacijah prsta si res ne moreš dati.
Razlogi, zakaj so slabi in grdi pristopi lahko grozni:
- Samodejne selitve imenskega prostora dajejo upravitelju vsebine velik stres. Pregled in morebitna posodobitev vsakega posameznega predmeta v vaši trgovini z vsebinami lahko pogosto povzroči več deset tisoč klicev SDK v Cognos (skoraj vsi tečejo prek upravitelja vsebine). To nenormalno poizvedovanje običajno poveča porabo / obremenitev pomnilnika in ogrozi zrušitev upravitelja vsebine med selitvijo. Če že imate v svojem okolju Cognos nekaj nestabilnosti, bi se morali tega pristopa zelo bati.
- Migracije imenskega prostora zahtevajo veliko okno za vzdrževanje. Cognos mora biti pripravljen, vendar ne želite, da se ljudje med procesom selitve spreminjajo. To običajno zahteva, da se migracija imenskega prostora začne, ko nihče drug ne dela, recimo ob petih zvečer ob 10. Nihče ne želi v petek zvečer ob 10. uri začeti stresnega projekta. Da ne omenjam, da vaše miselne sposobnosti verjetno niso najboljše med delovnimi noči in vikendi pri projektu, ki ne zahtevajte, da ste ostri!
- Omenil sem, da so migracije imenskega prostora časovno in delovno intenzivne. Tukaj je še nekaj o tem:
- Postopek preslikave vsebine je treba izvesti natančno, kar zahteva sodelovanje ekipe in veliko ur.
- Za preverjanje napak ali težav pri selitvi je potrebno več suhih tekov. Tipična selitev v prvem poskusu ne gre popolnoma. Potrebovali boste tudi veljavno varnostno kopijo svoje trgovine z vsebinami, ki jo je v takih primerih mogoče obnoviti. Videli smo veliko organizacij, ki nimajo na voljo dobre varnostne kopije (ali imajo varnostno kopijo, za katero se ne zavedajo, da je nepopolna).
- Vse morate identificirati zunaj shranjevanje vsebine, na katero bi lahko vplivali (okvirni modeli, modeli transformatorjev itd.). Ta naloga lahko vključuje usklajevanje med več skupinami (zlasti v velikih skupnih okoljih BI).
- Potrebujete dober testni načrt, ki vključuje reprezentativne ljudi z različnimi stopnjami dostopa do vaše vsebine Cognos. Ključno pri tem je, da kmalu po selitvi preverite, ali je vse v celoti preseljeno in deluje, kot pričakujete. Preverjanje vsega je običajno nepraktično, zato na koncu preverite, za kaj upate, da so reprezentativni vzorci.
- Morate imeti broad poznavanje okolja Cognos in stvari, ki so od njega odvisne. Na primer, zgodovinske kocke s pogledi po meri je treba obnoviti, če greste po poti NSM.
- Kaj pa, če ste vi ali podjetje, ki ste ga prepustili zunanjemu selitvi imenskega prostora, pozabili na nekaj, na primer ... aplikacije SDK? Ko pritisnete stikalo, te stvari prenehajo delovati, če niso pravilno posodobljene. Ali imate opravljene ustrezne preglede, da to takoj opazite, ali bo minilo nekaj tednov / mesecev, preden se simptomi pojavijo?
- Če ste doživeli številne nadgradnje programa Cognos, imate lahko v svoji trgovini z vsebinami predmete, ki so v neskladnem stanju. Če ne delate s SDK -jem, ne boste mogli videti, kateri predmeti so v tem stanju.
Zakaj je zamenjava imenskega prostora najboljša možnost
Ključni dejavniki tveganja in zamudni koraki, ki sem jih pravkar opisal, so odpravljeni, ko se uporabi metoda zamenjave imenskega prostora Persona. S pristopom zamenjave imenskega prostora imate na voljo 5 minut izpadov programa Cognos in nobene vaše vsebine ni treba spreminjati. "Dobra" metoda se mi zdi kot rezano in suho "brez mozga". Petkovi noči so namenjeni sprostitvi, ne da bi se obremenjevali z dejstvom, da se je vaš upravitelj vsebine pravkar sesul sredi selitve imenskega prostora.
