Quando è necessario riconfigurare un ambiente Cognos esistente per utilizzare un'origine di sicurezza esterna diversa (ad es. Active Directory, LDAP, ecc.), è possibile adottare alcuni approcci. Mi piace chiamarli "Il buono, il brutto e il cattivo". Prima di esplorare questi approcci Buono, Cattivo e Brutto, diamo un'occhiata ad alcuni scenari comuni che tendono a guidare le modifiche allo spazio dei nomi di autenticazione in un ambiente Cognos.
Driver aziendali comuni:
Aggiornamento dell'hardware o del sistema operativo – La modernizzazione dell'hardware/dell'infrastruttura BI può essere un fattore trainante frequente. Mentre il resto di Cognos può funzionare come un campione sul tuo nuovo elegante hardware e sul moderno sistema operativo a 64 bit, buona fortuna per la migrazione della tua versione circa del 2005 di Access Manager su quella nuova piattaforma. Access Manager (rilasciato per la prima volta con la serie 7) è un venerabile retaggio dei tempi passati per molti clienti Cognos. È l'unico motivo per cui molti clienti conservano quella vecchia versione di Windows Server 2003. La scritta è stata appesa al muro per Access Manager per un po' di tempo. È un software legacy. Prima puoi allontanarti da esso, meglio è.
Standardizzazione delle applicazioni– Organizzazioni che desiderano consolidare l'autenticazione di tutte le loro applicazioni su un server di directory aziendale amministrato centralmente (ad es. LDAP, AD).
Fusioni e acquisizioni– L'azienda A acquista l'azienda B e necessita che l'ambiente Cognos dell'azienda B punti al server di directory dell'azienda A, senza causare problemi al contenuto o alla configurazione BI esistente.
Cessioni aziendali– Questo è l'opposto dello scenario di fusione, una parte di un'azienda viene scorporata in una propria entità e ora deve puntare l'ambiente BI esistente verso la nuova fonte di sicurezza.
Perché le migrazioni dello spazio dei nomi possono essere disordinate?
Puntare un ambiente Cognos a una nuova origine di sicurezza non è semplice come aggiungere il nuovo spazio dei nomi con gli stessi utenti, gruppi e ruoli, disconnettere il vecchio spazio dei nomi e VOILA!: tutti gli utenti Cognos nel nuovo spazio dei nomi sono abbinati a il loro contenuto. In effetti, spesso puoi finire con un pasticcio sanguinante sulle mani, ed ecco perché...
Tutte le entità di sicurezza Cognos (utenti, gruppi, ruoli) sono referenziate da un identificatore univoco denominato CAMID. Anche se tutti gli altri attributi sono uguali, il CAMID per un utente in un esistente lo spazio dei nomi di autenticazione non sarà lo stesso del CAMID per quell'utente nel nuovi spazio dei nomi. Questo può causare danni a un ambiente Cognos esistente. Anche se hai solo pochi utenti Cognos, devi renderti conto che i riferimenti CAMID esistono in MOLTE posizioni diverse nel tuo Content Store (e possono anche esistere al di fuori del tuo Content Store in modelli Framework, modelli Transformer, applicazioni TM1, cubi, applicazioni di pianificazione ecc. ).
Molti clienti Cognos credono erroneamente che CAMID sia davvero importante solo per il contenuto di My Folder, le preferenze dell'utente, ecc. Questo non potrebbe essere più lontano dalla verità. Non è solo una questione di numero di utenti, è la quantità di oggetti Cognos di cui ti devi preoccupare. Ci sono oltre 140 diversi tipi di oggetti Cognos solo nel Content Store, molti dei quali possono avere più riferimenti CAMID.
Per esempio:
- Non è raro che una singola pianificazione nel Content Store abbia più riferimenti CAMID (il CAMID del proprietario della pianificazione, il CAMID dell'utente con cui deve essere eseguita la pianificazione, il CAMID di ciascun utente o lista di distribuzione a cui inviare l'output del rapporto generato , eccetera.).
- Ogni oggetto in Cognos ha una politica di sicurezza che governa quali utenti possono accedere all'oggetto (si pensi alla "Scheda Autorizzazioni"). Una singola policy di sicurezza sospesa in quella cartella in Cognos Connection ha un riferimento CAMID per ogni utente, gruppo e ruolo specificato in quella policy.
- Spero che tu capisca il punto: questa lista potrebbe continuare all'infinito!
Non è raro che un Content Store di notevoli dimensioni contenga decine di migliaia di riferimenti CAMID (e ne abbiamo visti di grandi con centinaia di migliaia).
Ora, fai i conti su cosa c'è dentro il tuo Cognos e puoi vedere che hai potenzialmente a che fare con orde di riferimenti CAMID. Può essere un incubo! Cambiare (o riconfigurare) il tuo spazio dei nomi di autenticazione può lasciare tutti questi riferimenti CAMID in uno stato irrisolvibile. Ciò porta inevitabilmente a problemi di contenuto e configurazione di Cognos (ad es. pianificazioni che non vengono più eseguite, contenuto che non è più protetto nel modo in cui si pensa, pacchetti o cubi che non implementano più correttamente la sicurezza a livello di dati, la perdita del contenuto di My Folder e dell'utente preferenze, ecc.).
Metodi di transizione dello spazio dei nomi Cognos
Ora, sapendo che un ambiente Cognos può avere decine di migliaia di riferimenti CAMID che richiederanno la ricerca, la mappatura e l'aggiornamento al loro nuovo valore CAMID corrispondente nel nuovo spazio dei nomi di autenticazione, discutiamo degli approcci Buono, Cattivo e Brutto per risolvere questo problema.
Il buono: Sostituzione dello spazio dei nomi con Persona
Il primo metodo (sostituzione dello spazio dei nomi) utilizza Motio'S, QI personale Prodotto. Con questo approccio, lo spazio dei nomi esistente viene "sostituito" con uno speciale spazio dei nomi Persona che consente di virtualizzare tutte le entità di sicurezza esposte a Cognos. Le entità di sicurezza preesistenti saranno esposte a Cognos con lo stesso identico CAMID di prima, anche se possono essere supportate da un numero qualsiasi di origini di sicurezza esterne (ad es. Active Directory, LDAP o persino il database Persona).
La parte bella di questo approccio è che richiede ZERO modifiche ai tuoi contenuti Cognos. Questo perché Persona può mantenere i CAMID dei principali preesistenti, anche quando sono supportati da una nuova fonte. Quindi... tutte quelle decine di migliaia di riferimenti CAMID nel tuo Content Store, modelli esterni e cubi storici? Possono rimanere esattamente come sono. Non è richiesto alcun lavoro.
Questo è di gran lunga l'approccio meno rischioso e con il minor impatto possibile per la transizione dell'ambiente Cognos esistente da un'origine di sicurezza esterna a un'altra. Può essere eseguito in meno di un'ora con circa 5 minuti di inattività di Cognos (l'unico tempo di inattività di Cognos è il riavvio di Cognos dopo aver configurato lo spazio dei nomi di Persona).
Il Bad: Migrazione dello spazio dei nomi tramite Persona
Se l'approccio facile ea basso rischio non fa per te, allora c'è is un'altra opzione.
Persona può essere utilizzato anche per eseguire una migrazione dello spazio dei nomi.
Ciò comporta l'installazione di un secondo spazio dei nomi di autenticazione nel proprio ambiente Cognos, mappando (si spera) tutti i principali di sicurezza esistenti (dal vecchio spazio dei nomi) ai principali corrispondenti nel nuovo spazio dei nomi, quindi (ecco la parte divertente), trovando, mappando e aggiornando ogni singolo riferimento CAMID esistente nell'ambiente Cognos: Content Store, modelli di framework, modelli di trasformatore, cubi storici, applicazioni TM1, applicazioni di pianificazione, ecc.
Questo approccio tende ad essere stressante e ad alta intensità di elaborazione, ma se sei il tipo di amministratore di Cognos che ha bisogno di una scarica di adrenalina per sentirsi vivo (e non si preoccupa delle telefonate a tarda notte/mattina presto), allora forse... questo è l'opzione che stai cercando?
Persona può essere utilizzato per automatizzare parti di questo processo. Ti aiuterà a creare una mappatura tra le vecchie entità di sicurezza e le nuove entità di sicurezza, automatizzare la forza bruta "trova, analizza, aggiorna" la logica per i contenuti nel tuo archivio di contenuti, ecc. Quale Persona può automatizzare alcune delle attività qui, molto del lavoro in questo approccio coinvolge "persone e processi" piuttosto che la tecnologia reale.
Ad esempio, la compilazione di informazioni su ogni modello Framework Manager, ogni modello Transformer, ogni applicazione Planning / TM1, ogni applicazione SDK, chi li possiede e pianificare come verranno aggiornati e ridistribuiti può essere molto lavoro. Il coordinamento delle interruzioni per ciascuno degli ambienti Cognos in cui si desidera eseguire questa operazione e le finestre di manutenzione durante le quali è possibile tentare la migrazione possono comportare la pianificazione e il "tempo di inattività" di Cognos. Anche elaborare (ed eseguire) un piano di test efficace per dopo la migrazione può essere piuttosto un orso.
È anche abbastanza normale che tu voglia prima fare questo processo in un ambiente non di produzione prima provandolo in produzione.
Sebbene la migrazione dello spazio dei nomi con Persona funzioni (ed è molto meglio dell'approccio "brutto" di seguito), è più invasiva, più rischiosa, coinvolge molto più personale e richiede molte più ore di lavoro rispetto alla sostituzione dello spazio dei nomi. In genere le migrazioni devono essere eseguite durante le "ore libere", mentre l'ambiente Cognos è ancora online, ma l'utilizzo del modulo da parte degli utenti finali è limitato.
Il Cattivo: Servizi di migrazione manuale dello spazio dei nomi
Il metodo Ugly implica l'approccio poco invidiabile di tentare di manualmente migrare da uno spazio dei nomi di autenticazione a un altro. Ciò comporta la connessione di un secondo spazio dei nomi di autenticazione all'ambiente Cognos, quindi il tentativo di spostare o ricreare manualmente gran parte del contenuto e della configurazione Cognos esistenti.
Ad esempio, utilizzando questo approccio, un amministratore Cognos potrebbe tentare di:
- Ricreare i gruppi e i ruoli nel nuovo spazio dei nomi
- Ricrea le appartenenze di quei gruppi e ruoli nel nuovo spazio dei nomi
- Copia manualmente il contenuto delle mie cartelle, le preferenze dell'utente, le schede del portale, ecc. da ciascun account di origine a ciascun account di destinazione
- Trova ogni Policy Set nel Content Store e aggiornalo per fare riferimento a principal equivalenti nel nuovo spazio dei nomi esattamente nello stesso modo in cui faceva riferimento ai principal dal vecchio spazio dei nomi
- Ricreare tutte le pianificazioni e popolarle con credenziali, destinatari, ecc. corrispondenti.
- Ripristina tutte le proprietà "proprietario" e "contatto" di tutti gli oggetti nel Content Store
- [Circa 40 altre cose nel Content Store di cui ti dimenticherai]
- Raccogli tutti i modelli FM con sicurezza a livello di oggetti o dati:
- Aggiorna ogni modello di conseguenza
- Ripubblica ogni modello
- Ridistribuire il modello modificato all'autore originale
- Lavoro simile per i modelli Transformer, le applicazioni TM1 e le applicazioni di pianificazione che sono protette dallo spazio dei nomi originale
- [e molti altri]
Mentre alcuni masochisti di Cognos potrebbero segretamente ridere di gioia all'idea di fare clic 400,000 volte in Cognos Connection, per le persone più sensate, questo approccio tende ad essere estremamente noioso, dispendioso in termini di tempo e soggetto a errori. Tuttavia, questo non è il problema più grande con questo approccio.
Il problema più grande con questo approccio è che quasi sempre porta a una migrazione incompleta.
Usando questo approccio, trovi (dolorosamente) e cerchi di mappare quei riferimenti CAMID che conosci... ma tendi a lasciare tutti quei riferimenti CAMID che non so.
Una volta che si think hai finito con questo approccio, spesso non lo sei veramente fatto.
Hai oggetti nel tuo archivio di contenuti che non sono più protetti nel modo in cui pensi che siano ... hai pianificazioni che non funzionano come prima, hai dati che non sono più protetti come pensi lo è, e potresti anche avere errori inspiegabili per determinate operazioni che non puoi davvero mettere il dito sopra.
Ragioni per cui gli approcci cattivi e brutti possono essere terribili:
- Le migrazioni automatizzate dello spazio dei nomi mettono a dura prova Content Manager. L'ispezione e il potenziale aggiornamento di ogni singolo oggetto nel Content Store può spesso comportare decine di migliaia di chiamate SDK a Cognos (praticamente tutte che passano attraverso Content Manager). Questa query anomala in genere aumenta l'utilizzo/carico della memoria e mette il Content Manager a rischio di arresto anomalo durante la migrazione. Se hai già una certa instabilità nel tuo ambiente Cognos, dovresti avere molta paura di questo approccio.
- Le migrazioni dello spazio dei nomi richiedono una finestra di manutenzione considerevole. Cognos deve essere attivo, ma non vuoi che le persone apportino modifiche durante il processo di migrazione. Ciò richiederà in genere che la migrazione dello spazio dei nomi inizi quando nessun altro sta lavorando, diciamo alle 10:10 di venerdì sera. Nessuno vuole iniziare un progetto stressante alle XNUMX:XNUMX di venerdì sera. Per non parlare del fatto che le tue facoltà mentali probabilmente non sono al meglio lavorando di notte e nei fine settimana su un progetto che effettua richiedono di essere acuto!
- Ho detto che le migrazioni dello spazio dei nomi richiedono molto tempo e lavoro. Ecco un po' di più su questo:
- Il processo di mappatura dei contenuti dovrebbe essere eseguito con precisione e ciò richiede la collaborazione del team e molte ore di lavoro.
- Sono necessarie più prove a secco per verificare la presenza di errori o problemi con una migrazione. Una tipica migrazione non va perfettamente al primo tentativo. Avrai anche bisogno di un backup valido del tuo Content Store che può essere ripristinato in questi casi. Abbiamo visto molte organizzazioni che non dispongono di un buon backup disponibile (o hanno un backup che non si rendono conto che è incompleto).
- Devi identificare tutto al di fuori il Content Store che potrebbe essere potenzialmente interessato (modelli framework, modelli trasformatore, ecc.). Questa attività può comportare il coordinamento tra più team (in particolare in ambienti di BI condivisi di grandi dimensioni).
- Hai bisogno di un buon piano di test che coinvolga persone rappresentative con vari gradi di accesso ai tuoi contenuti Cognos. La chiave qui è verificare poco dopo il completamento della migrazione che tutto sia completamente migrato e funzioni come previsto. In genere non è pratico verificare tutto, quindi finisci per verificare quelli che speri siano campioni rappresentativi.
- Devi avere broad conoscenza dell'ambiente Cognos e delle cose che da esso dipendono. Ad esempio, i cubi storici con viste personalizzate DEVONO essere ricostruiti se si segue il percorso NSM.
- E se tu o l'azienda a cui hai esternalizzato la migrazione dello spazio dei nomi dimenticasse qualcosa, come... le applicazioni SDK? Una volta attivato l'interruttore, queste cose smettono di funzionare se non vengono aggiornate correttamente. Hai i controlli adeguati per notarlo immediatamente, o ci vorranno diverse settimane / mesi prima che i sintomi inizino a emergere?
- Se sono stati eseguiti numerosi aggiornamenti di Cognos, è possibile che nel Content Store siano presenti oggetti in uno stato incoerente. Se non utilizzi l'SDK, non sarai in grado di vedere quali oggetti si trovano in questo stato.
Perché la sostituzione dello spazio dei nomi è l'opzione migliore
I principali fattori di rischio e i passaggi dispendiosi in termini di tempo che ho appena delineato vengono eliminati quando viene utilizzato il metodo di sostituzione dello spazio dei nomi Persona. Utilizzando l'approccio di sostituzione dello spazio dei nomi, hai 5 minuti di inattività di Cognos e nessuno dei tuoi contenuti deve cambiare. Il metodo "Buono" mi sembra un "no-brainer" tagliato e secco. I venerdì sera sono per rilassarsi, non per stressarsi per il fatto che il tuo Content Manager si è appena schiantato nel bel mezzo di una migrazione dello spazio dei nomi.
