Când trebuie să reconfigurați un mediu Cognos existent pentru a utiliza o sursă de securitate externă diferită (de exemplu, Active Directory, LDAP etc.), există o mână de abordări pe care le puteți lua. Îmi place să le spun „Bine, Rău și Urât”. Înainte de a explora aceste abordări bune, rele și urâte, să aruncăm o privire la câteva scenarii obișnuite care tind să conducă la modificări ale spațiului de nume de autentificare într-un mediu Cognos.
Drivere comune pentru afaceri:
Actualizarea hardware-ului sau a sistemului de operare - Modernizarea hardware-ului / infrastructurii BI poate fi un driver frecvent. În timp ce restul Cognos ar putea funcționa ca un campion pe noul dvs. hardware elegant și pe sistemul de operare modern pe 64 de biți, noroc să vă migrați versiunea de versiune 2005 din Access Manager către noua platformă. Access Manager (lansat pentru prima dată cu seria 7) este o venerabilă reținere din zilele trecute pentru mulți clienți Cognos. Este singurul motiv pentru care mulți clienți păstrează în jurul acelei versiuni cruciale de Windows Server 2003. Scrierea a fost pe perete pentru Access Manager de ceva timp. Este un software vechi. Cu cât puteți trece mai repede de la acesta, cu atât mai bine.
Standardizarea aplicației- Organizațiile care doresc să consolideze autentificarea tuturor aplicațiilor pe un singur server de director corporativ administrat central (de exemplu, LDAP, AD).
Fuziuni și achiziții- Compania A cumpără Compania B și are nevoie de mediul Cognos al Companiei B pentru a indica serverul de directoare al Companiei A, fără a provoca probleme legate de conținutul sau configurația BI existentă.
Dezinvestiri corporative- Acesta este opusul scenariului de fuziune, o porțiune a unei companii este separată în propria entitate și acum trebuie să indice mediul BI existent către noua sursă de securitate.
De ce migrațiile spațiului de nume pot fi dezordonate
Îndreptarea unui mediu Cognos către o nouă sursă de securitate nu este la fel de simplă ca adăugarea noii spații de nume cu aceiași utilizatori, grupuri și roluri, deconectarea vechiului spațiu de nume și VOILA! conținutul lor. De fapt, puteți ajunge adesea cu o mizerie sângeroasă pe mâini și iată de ce ...
Toate principalele de securitate Cognos (utilizatori, grupuri, roluri) sunt menționate de un identificator unic numit CAMID. Chiar dacă toate celelalte atribute sunt egale, CAMID pentru un utilizator dintr-un existent spațiul de nume de autentificare nu va fi același cu CAMID pentru acel utilizator din nou spațiu de nume. Acest lucru poate distruge un mediu Cognos existent. Chiar dacă aveți doar câțiva utilizatori Cognos, trebuie să vă dați seama că referințele CAMID există în MULTE locuri diferite din Magazinul dvs. de conținut (și pot exista chiar și în afara magazinului dvs. de conținut în modele cadru, modele transformatoare, aplicații TM1, cuburi, aplicații de planificare etc. ).
Mulți clienți Cognos cred din greșeală că CAMID contează cu adevărat doar pentru conținutul Folderului meu, preferințele utilizatorilor etc. Acest lucru nu ar putea fi mai departe de adevăr. Nu este vorba doar de numărul de utilizatori pe care îl aveți, ci de cantitatea de obiecte Cognos de care trebuie să vă preocupați. Există peste 140 de tipuri diferite de obiecte Cognos doar în Magazinul de conținut, dintre care multe pot avea mai multe referințe CAMID.
De exemplu:
- Nu este neobișnuit ca o singură programare din Magazinul dvs. de conținut să aibă mai multe referințe CAMID (CAMID-ul proprietarului programului, CAMID-ul utilizatorului pe care ar trebui să-l ruleze programul, CAMID-ul fiecărui utilizator sau lista de distribuție pe care ar trebui să trimită prin e-mail rezultatul raportului , etc.).
- Fiecare obiect din Cognos are o politică de securitate care reglementează utilizatorii care pot accesa obiectul (gândiți-vă la „fila Permisiuni”). O singură politică de securitate suspendată de acel folder în Cognos Connection are o referință CAMID pentru fiecare utilizator, grup și rol specificat în acea politică.
- Sperăm că obțineți ideea - această listă continuă și continuă!
Nu este neobișnuit ca un Magazin de conținut considerabil să conțină zeci de mii de referințe CAMID (și am văzut unele mari cu sute de mii).
Acum, faceți calculele în ceea ce este în ta Cognos mediu și puteți vedea că aveți potențial de-a face cu hoarde de referințe CAMID. Poate fi un coșmar! Schimbarea (sau reconfigurarea) spațiului de nume de autentificare poate lăsa toate aceste referințe CAMID într-o stare irezolvabilă. Acest lucru duce inevitabil la probleme de configurare și conținut Cognos (de exemplu, programări care nu mai rulează, conținut care nu mai este securizat așa cum credeți că este, pachete sau cuburi care nu mai implementează corect securitatea la nivel de date, pierderea conținutului folderului meu și a utilizatorului preferințe etc.).
Metode de tranziție a spațiului de nume Cognos
Acum, știind că un mediu Cognos poate avea zeci de mii de referințe CAMID care vor necesita găsirea, maparea și actualizarea la noua lor valoare CAMID corespunzătoare în noul spațiu de nume de autentificare, să discutăm abordările bune, rele și urâte pentru rezolvarea acestei probleme.
Bun: Înlocuirea spațiului de nume cu Persona
Prima metodă (Înlocuirea spațiului de nume) utilizează Motio„S, IQ Persona produs. Urmând această abordare, spațiul de nume existent este „înlocuit” cu un spațiu de nume special Persona care vă permite să virtualizați toate principalele de securitate expuse Cognos. Principalii de securitate pre-existenți vor fi expuși Cognos cu exact același CAMID ca înainte, chiar dacă pot fi susținuți de orice număr de surse de securitate externe (de exemplu, Active Directory, LDAP sau chiar baza de date Persona).
Partea frumoasă a acestei abordări este că necesită ZERO modificări ale conținutului dvs. Cognos. Acest lucru se datorează faptului că Persona poate menține CAMID-urile principalelor preexistente, chiar și atunci când sunt susținute de o nouă sursă. Deci ... toate acele zeci de mii de referințe CAMID din Magazinul dvs. de conținut, modele externe și cuburi istorice? Pot rămâne exact așa cum sunt. Nu este nevoie de muncă.
Aceasta este de departe cea mai puțin riscantă abordare cu cel mai mic impact pe care o puteți utiliza pentru tranziția mediului dvs. Cognos existent de la o sursă de securitate externă la alta. Se poate face în mai puțin de o oră cu aproximativ 5 minute de nefuncționare Cognos (singurul timp de nefuncționare Cognos este repornirea Cognos după ce ați configurat spațiul de nume Persona).
Răul: Migrarea spațiului de nume folosind Persona
Dacă abordarea ușoară și cu risc redus nu este doar ceașca ta de ceai, atunci acolo is altă opțiune.
Persona poate fi, de asemenea, utilizat pentru a efectua o migrare a spațiului de nume.
Aceasta implică instalarea unui al doilea spațiu de nume de autentificare în mediul dvs. Cognos, maparea (sperăm) a tuturor principalelor dvs. de securitate existente (de la vechiul spațiu de nume) la principalele corespunzătoare din noul spațiu de nume, apoi (aici este partea distractivă), găsirea, maparea și actualizarea fiecărui referință CAMID unică care există în mediul dvs. Cognos: Magazinul dvs. de conținut, modelele cadru, modelele transformatoare, cuburile istorice, aplicațiile TM1, aplicațiile de planificare etc.
Această abordare tinde să fie stresantă și intensivă în proces, dar dacă sunteți genul de administrator Cognos care are nevoie de un pic de adrenalină pentru a se simți în viață (și nu-i deranjează noaptea târziu / apelurile telefonice dimineața devreme), atunci poate ... acest este opțiunea pe care o căutați?
Persona poate fi folosit pentru a ajuta la automatizarea unor porțiuni din acest proces. Vă va ajuta să creați o mapare între vechile directoare de securitate și noile directoare de securitate, să automatizați logica forței brute „găsiți, analizați, actualizați” pentru conținutul din magazinul dvs. de conținut etc. Ce poate Persona automatiza unele dintre sarcinile de aici, mult din această abordare implică mai degrabă „oameni și procese” decât tehnologie reală.
De exemplu - compilarea informațiilor despre fiecare model Framework Manager, fiecare model Transformer, fiecare aplicație Planning / TM1, fiecare aplicație SDK, cine le deține și planificarea modului în care vor fi actualizate și redistribuite poate fi o mulțime de lucru. Coordonarea întreruperilor pentru fiecare dintre mediile Cognos în care doriți să încercați acest lucru și ferestrele de întreținere în timpul cărora puteți încerca migrarea pot implica planificare și „timp de inactivitate” Cognos. Venirea (și executarea) unui plan de testare eficient după migrarea dvs. poate fi, de asemenea, destul de ursitoare.
Este, de asemenea, destul de normal să doriți să faceți acest proces mai întâi într-un mediu non-producție înainte încercând-o în producție.
În timp ce Migrarea spațiului de nume cu Persona funcționează (și este mult mai bună decât abordarea „Urâtă” de mai jos), este mai invazivă, mai riscantă, implică mult mai mult personal și necesită mult mai multe ore de muncă decât înlocuirea spațiului de nume. De obicei, migrațiile trebuie făcute în timpul „orelor libere”, în timp ce mediul Cognos este încă online, dar utilizarea restricționată a formularului de către utilizatorii finali.
Ugly: Servicii manuale de migrare a spațiului de nume
Metoda Urâtă implică abordarea de neinvidiat a încercării de a manual migrează de la un spațiu de nume de autentificare la altul. Aceasta implică conectarea unui al doilea spațiu de nume de autentificare la mediul dvs. Cognos, apoi încercarea de a muta manual sau de a recrea o mare parte din conținutul și configurația Cognos existente.
De exemplu, folosind această abordare, un administrator Cognos poate încerca să:
- Recreați grupurile și rolurile în noul spațiu de nume
- Recreați membrii acestor grupuri și roluri în noul spațiu de nume
- Copiați manual conținutul folderelor mele, preferințele utilizatorului, filele portalului etc. din fiecare cont sursă în fiecare cont țintă
- Găsiți fiecare set de politici din Magazinul de conținut și actualizați-l pentru a face referință la principalele echivalente din noul spațiu de nume în același mod în care a făcut referință la principalele din spațiul de nume vechi
- Recreați toate programele și completați-le cu acreditări corespunzătoare, destinatari etc.
- Resetați toate proprietățile „proprietarului” și „contactului” tuturor obiectelor din Magazinul de conținut
- [Vreo 40 de alte lucruri din Magazinul de conținut de care veți uita]
- Adunați toate modelele FM cu securitate la nivel de obiect sau de date:
- Actualizați fiecare model în consecință
- Reeditați fiecare model
- Redistribuiți modelul modificat înapoi la autorul original
- Lucrări similare pentru modelele Transformer, aplicațiile TM1 și aplicațiile de planificare care sunt protejate împotriva spațiului de nume original
- [si multe altele]
În timp ce unii masochisti Cognos s-ar putea să chicotească în secret de bucurie la ideea de a da clic de 400,000 de ori în Cognos Connection, pentru cei mai sensibili oameni, această abordare tinde să fie extrem de plictisitoare, consumatoare de timp și predispusă la erori. Cu toate acestea, aceasta nu este cea mai mare problemă cu această abordare.
Cea mai mare problemă cu această abordare este că aproape mereu duce la o migrație incompletă.
Folosind această abordare, găsiți (dureros) și încercați să mapați acele referințe CAMID despre care știți ... dar aveți tendința de a lăsa toate acele referințe CAMID pe care le nu știu despre.
Odată ce ați crede ai terminat cu această abordare, de multe ori nu ești într-adevăr Terminat.
Aveți obiecte în magazinul dvs. de conținut care nu mai sunt securizate așa cum credeți că sunt ... aveți programe care nu funcționează așa cum funcționau înainte, aveți date care nu mai sunt securizate așa cum credeți este, și este posibil să aveți chiar erori inexplicabile pentru anumite operațiuni care nu prea poți pune degetul.
Motive pentru care abordările rele și urâte pot fi îngrozitoare:
- Migrațiile automate ale spațiului de nume pun mult accent pe Managerul de conținut. Inspecția și actualizarea potențială a fiecărui obiect din Magazinul dvs. de conținut pot duce adesea la zeci de mii de apeluri SDK către Cognos (practic toate acestea trec prin Content Manager). Această interogare anormală crește de obicei utilizarea / încărcarea memoriei și pune Managerul de conținut în pericol de blocare în timpul migrării. Dacă aveți deja o anumită instabilitate în mediul dvs. Cognos, ar trebui să vă fie foarte teamă de această abordare.
- Migrațiile spațiului de nume necesită o fereastră de întreținere considerabilă. Cognos trebuie să fie activat, dar nu doriți ca oamenii să facă schimbări în timpul procesului de migrare. Acest lucru va necesita, de obicei, migrarea spațiului de nume să înceapă atunci când nimeni altcineva nu lucrează, să zicem la 10 seara, vineri seara. Nimeni nu vrea să înceapă un proiect stresant, la 10 seara, vineri seara. Ca să nu mai vorbim, facultățile tale mentale nu sunt probabil în cele mai bune nopți și weekenduri de lucru pentru un proiect care face îți cer să fii ascuțit!
- Am menționat că Migrarea spațiului de nume necesită mult timp și muncă. Iată mai multe despre asta:
- Procesul de cartografiere a conținutului trebuie făcut cu precizie și acest lucru necesită colaborarea echipei și multe ore de muncă.
- Sunt necesare repetări multiple pentru a verifica erorile sau problemele legate de migrare. O migrație tipică nu merge perfect la prima încercare. De asemenea, veți avea nevoie de o copie de rezervă validă a Magazinului dvs. de conținut care poate fi restaurată în astfel de cazuri. Am văzut multe organizații care nu dispun de o copie de rezervă bună (sau au o copie de rezervă pe care nu o realizează incompletă).
- Trebuie să identificați totul exterior Magazinul de conținut care poate fi potențial afectat (modele cadru, modele de transformatoare etc.). Această sarcină poate implica coordonarea între mai multe echipe (în special în medii mari de BI partajate).
- Aveți nevoie de un plan de testare bun, care să implice persoane reprezentative cu grade diferite de acces la conținutul dvs. Cognos. Cheia aici este să verificați la scurt timp după finalizarea migrării că totul este complet migrat și funcționează așa cum vă așteptați. Este de obicei impracticabil să verificați totul, așa că veți ajunge să verificați ceea ce sperați că sunt mostre reprezentative.
- Trebuie să aveți broad cunoașterea mediului Cognos și a lucrurilor care depind de acesta. De exemplu, cuburile istorice cu vizualizări personalizate TREBUIE să fie reconstruite dacă mergeți pe ruta NSM.
- Ce se întâmplă dacă dvs. sau compania ați externalizat migrarea spațiului de nume pentru a uita de ceva, cum ar fi ... aplicațiile SDK? După ce ați răsucit comutatorul, aceste lucruri nu mai funcționează dacă nu sunt actualizate corect. Aveți verificările adecvate pentru a observa acest lucru imediat sau vor trece câteva săptămâni / luni până când simptomele vor începe să apară?
- Dacă ați suferit numeroase actualizări Cognos, puteți avea în magazinul dvs. de conținut obiecte care se află într-o stare inconsistentă. Dacă nu lucrați cu SDK, nu veți putea vedea ce obiecte se află în această stare.
De ce înlocuirea spațiului de nume este cea mai bună opțiune
Factorii cheie de risc și pașii consumatori de timp pe care tocmai le-am subliniat sunt eliminați atunci când se utilizează metoda de înlocuire a spațiului de nume Persona. Folosind abordarea de înlocuire a spațiului de nume, aveți 5 minute de nefuncționare Cognos și niciunul dintre conținuturile dvs. nu trebuie să se schimbe. Metoda „Bine” mi se pare o „neînțelegere” tăiată și uscată. Vineri seara sunt pentru relaxare, fără a vă sublinia faptul că Managerul dvs. de conținut tocmai s-a prăbușit în mijlocul unei migrații a spațiului de nume.
