Når du trenger å omkonfigurere et eksisterende Cognos -miljø til å bruke en annen ekstern sikkerhetskilde (f.eks. Active Directory, LDAP, osv.), Er det en håndfull tilnærminger du kan ta. Jeg liker å kalle dem "De gode, de dårlige og de stygge." Før vi utforsker disse gode, dårlige og stygge tilnærmingene, la oss se på noen vanlige scenarier som har en tendens til å drive endringer i autentiseringsnavnområdet i et Cognos -miljø.
Vanlige forretningsdrivere:
Oppdaterer maskinvare eller operativsystem - Modernisering av BI -maskinvare/infrastruktur kan være en hyppig driver. Mens resten av Cognos kan kjøre som en mester på din slanke nye maskinvare og moderne 64-biters operativsystem, lykke til med å migrere circa 2005-versjonen av Access Manager til den nye plattformen. Access Manager (første gang utgitt med serie 7) er en ærverdig overlevelse fra mange dager siden for mange Cognos -kunder. Det er den eneste grunnen til at mange kunder beholder den gamle gamle versjonen av Windows Server 2003. Skriften har vært på veggen for Access Manager ganske lenge. Det er eldre programvare. Jo før du kan gå bort fra det, jo bedre.
Standardisering av applikasjoner- Organisasjoner som ønsker å konsolidere autentiseringen av alle applikasjonene sine mot en sentralt administrert bedriftskatalogserver (f.eks. LDAP, AD).
Fusjoner og oppkjøp- Firma A kjøper selskap B og trenger selskapets B Cognos -miljø for å peke til firmaets katalogserver, uten å forårsake problemer med deres eksisterende BI -innhold eller konfigurasjon.
Selskapsavhendelser- Dette er det motsatte av fusjonsscenariet, en del av et selskap blir spunnet til sin egen enhet og må nå peke på det eksisterende BI -miljøet på den nye sikkerhetskilden.
Hvorfor navneromsoverføring kan være rotete
Å peke et Cognos-miljø på en ny sikkerhetskilde er ikke så enkelt som å legge til det nye navneapparatet med de samme brukerne, gruppene og rollene, koble fra det gamle navnområdet og VOILA!- alle dine Cognos-brukere i det nye navneområdet samsvarer med innholdet deres. Faktisk kan du ofte ende opp med et blodig rot i hendene, og her er grunnen ...
Alle Cognos sikkerhetsprinsipper (brukere, grupper, roller) refereres til av en unik identifikator kalt en CAMID. Selv om alle andre attributter er like, er CAMID for en bruker i en eksisterende autentiseringsnavnområdet vil ikke være det samme som CAMID for den brukeren i nytt navneområde. Dette kan ødelegge kaos på et eksisterende Cognos -miljø. Selv om du bare har noen få Cognos -brukere, må du innse at CAMID -referanser finnes på MANGE forskjellige steder i Content Store (og kan til og med eksistere utenfor Content Store i Framework -modeller, transformatormodeller, TM1 -applikasjoner, kuber, planleggingsapplikasjoner osv. ).
Mange Cognos -kunder tror feilaktig at CAMID egentlig bare betyr noe for Min mappe -innhold, brukerpreferanser, etc. Dette kan ikke være lenger fra sannheten. Det er ikke bare et spørsmål om antall brukere du har, det er mengden Cognos -objekter du trenger å være bekymret for. Det er over 140 forskjellige typer Cognos -objekter bare i Content Store, hvorav mange kan ha flere CAMID -referanser.
For eksempel:
- Det er ikke uvanlig at en enkelt plan i innholdsbutikken har flere CAMID -referanser (CAMID av planseieren, CAMID til brukeren planen skal kjøres som, CAMID for hver bruker eller distribusjonsliste den skal sende genererte rapportutdata til via e -post til , etc.).
- Hvert objekt i Cognos har en sikkerhetspolicy som styrer hvilke brukere som kan få tilgang til objektet (tenk "kategorien Tillatelser"). En enkelt sikkerhetspolicy som henger utenfor mappen i Cognos Connection, har en CAMID -referanse for hver bruker, gruppe og rolle som er spesifisert i denne policyen.
- Forhåpentligvis forstår du poenget - denne listen fortsetter og fortsetter!
Det er ikke uvanlig at en betydelig innholdsbutikk inneholder titusenvis av CAMID -referanser (og vi har sett noen store med hundretusener).
Gjør nå regnestykket på det som er inne din Cognos -miljøet, og du kan se at du potensielt har å gjøre med horder av CAMID -referanser. Det kan være et mareritt! Hvis du bytter (eller konfigurerer på nytt) autentiseringsnavnområdet, kan alle disse CAMID-referansene stå i en uløselig tilstand. Dette fører uunngåelig til Cognos -innholds- og konfigurasjonsproblemer (f.eks. Tidsplaner som ikke lenger kjøres, innhold som ikke lenger er sikret slik du tror det er, pakker eller kuber som ikke lenger korrekt implementerer datasikkerhet, tap av Min mappe -innhold og bruker preferanser, etc.).
Overgangsmetoder for Cognos navneplass
Nå som vi vet at et Cognos -miljø kan ha titusenvis av CAMID -referanser som vil kreve å finne, kartlegge og oppdatere til den tilsvarende nye CAMID -verdien i det nye autentiseringsnavnområdet, la oss diskutere de gode, dårlige og stygge tilnærmingene for å løse dette problemet.
The Good: Erstatning av navneområde med Persona
Den første metoden (Namespace Replacement) bruker Motio'S, Persona IQ produkt. Når du tar denne tilnærmingen, blir ditt eksisterende navneområde "erstattet" med et spesielt navneområde for Persona som lar deg virtualisere alle sikkerhetsprinsipper som er utsatt for Cognos. Eksisterende sikkerhetsprinsipper vil bli eksponert for Cognos med nøyaktig samme CAMID som før, selv om de kan bli støttet av et hvilket som helst antall eksterne sikkerhetskilder (f.eks. Active Directory, LDAP eller til og med Persona-databasen).
Den vakre delen med denne tilnærmingen er at den krever NULL endringer i Cognos -innholdet. Dette er fordi Persona kan opprettholde CAMID-er fra eksisterende rektorer, selv når de støttes av en ny kilde. Så ... alle de titusenvis av CAMID -referanser i innholdsbutikken, eksterne modeller og historiske kuber? De kan bli akkurat som de er. Det kreves ikke noe arbeid.
Dette er den minst risikofylte, laveste innvirkningsmetoden du kan bruke for å overføre ditt eksisterende Cognos -miljø fra en ekstern sikkerhetskilde til en annen. Det kan gjøres på under en time med omtrent 5 minutter med Cognos nedetid (den eneste Cognos nedetid er å starte Cognos på nytt når du har konfigurert Persona -navneområdet).
The Bad: Navneplassmigrasjon ved bruk av Persona
Hvis den enkle, lavrisiko-tilnærmingen bare ikke er din kopp te, så er det det is et annet alternativ.
Persona kan også brukes til å utføre en navneoverføring.
Dette innebærer å installere et andre autentiseringsnavnområde i Cognos -miljøet, kartlegge (forhåpentligvis) alle dine eksisterende sikkerhetsprinsipper (fra det gamle navnerommet) til tilsvarende rektorer i det nye navnerommet, deretter (her er den morsomme delen), finne, kartlegge og oppdatere alle én CAMID -referanse som finnes i Cognos -miljøet ditt: innholdsbutikken, rammemodeller, transformatormodeller, historiske kuber, TM1 -applikasjoner, planleggingsapplikasjoner, etc.
Denne tilnærmingen har en tendens til å være stressende og prosessintensiv, men hvis du er en Cognos -administrator som trenger litt adrenalinkick for å føle seg levende (og ikke har noe imot telefonsamtaler sent på kvelden / tidlig på morgenen), så kanskje ... denne er alternativet du leter etter?
Persona kan brukes til å automatisere deler av denne prosessen. Det vil hjelpe deg med å lage en kartlegging mellom de gamle sikkerhetsprinsippene og de nye sikkerhetsprinsippene, automatisere brute force "finn, analyser, oppdater" logikk for innhold i innholdsbutikken din, etc. Hva Persona kan automatisere noen av oppgavene her, mye av arbeidet i denne tilnærmingen involverer "mennesker og prosess" i stedet for faktisk teknologi.
For eksempel - å samle informasjon om hver Framework Manager -modell, hver Transformer -modell, hver Planning / TM1 -applikasjon, hver SDK -applikasjon, hvem som eier dem og planlegge hvordan de skal oppdateres og distribueres, kan være mye arbeid. Koordinerende driftsstans for hvert av Cognos -miljøene du ønsker å prøve dette i, og vedlikeholdsvinduer der du kan prøve overføringen, kan innebære planlegging og Cognos "nedetid". Å komme med (og utføre) en effektiv testplan for etter migreringen kan også være en ganske bjørn.
Det er også ganske normalt at du vil gjøre denne prosessen først i et ikke-produksjonsmiljø før du prøver det i produksjon.
Selv om navnespace -migrasjon med personer fungerer (og det er langt bedre enn den "stygge" tilnærmingen nedenfor), er det mer invasivt, risikabelt, involverer langt mer personell og tar langt flere mannstimer å utføre enn erstatning av navneområde. Vanligvis må migrasjoner utføres i "off -timer", mens Cognos -miljøet fremdeles er online, men begrenset skjemabruk av sluttbrukere.
The Ugly: Manuelle navneområder Migrasjonstjenester
Den stygge metoden innebærer den misunnelsesverdige tilnærmingen til å prøve manuelt migrere fra ett autentiseringsnavnområde til et annet. Dette innebærer å koble et andre autentiseringsnavnområde til Cognos -miljøet, og deretter forsøke å flytte eller gjenskape mye av det eksisterende Cognos -innholdet og konfigurasjonen manuelt.
Hvis du for eksempel bruker denne tilnærmingen, kan en Cognos -administrator prøve å:
- Gjenopprett gruppene og rollene i det nye navneområdet
- Gjenskap medlemskapene til disse gruppene og rollene i det nye navnerommet
- Kopier innholdet i mappene mine, brukerpreferanser, portalfaner osv. Manuelt fra hver kildekonto til hver målkonto
- Finn hvert policy -sett i Content Store, og oppdater det for å referere til tilsvarende prinsipper i det nye navneområdet på nøyaktig samme måte som det refererte til rektorer fra det gamle navnerommet
- Gjenopprett alle tidsplanene og fyll dem med tilsvarende legitimasjon, mottakere, etc.
- Tilbakestill alle "eier" og "kontakt" -egenskapene til alle objektene i Content Store
- [Omtrent 40 andre ting i Content Store som du kommer til å glemme]
- Samle alle FM -modellene med sikkerhet på objekt- eller datanivå:
- Oppdater hver modell tilsvarende
- Publiser hver modell på nytt
- Fordel den modifiserte modellen tilbake til den opprinnelige forfatteren
- Lignende arbeid for transformatormodeller, TM1 -applikasjoner og planprogrammer som er sikret mot det opprinnelige navnerommet
- [og mange flere]
Mens noen Cognos -masochister i hemmelighet kan fnise av glede av ideen om å klikke 400,000 XNUMX ganger i Cognos Connection, har denne tilnærmingen en tendens til å være ekstremt kjedelig, tidkrevende og feilutsatt. Det er imidlertid ikke det største problemet med denne tilnærmingen.
Det største problemet med denne tilnærmingen er at den nesten alltid fører til en ufullstendig migrasjon.
Ved å bruke denne tilnærmingen finner og prøver du (smertefullt) å kartlegge de CAMID -referansene du kjenner til ... men har en tendens til å la alle CAMID -referansene du vet ikke om.
Når du tror du er ferdig med denne tilnærmingen, det er du ofte ikke virkelig gjort.
Du har objekter i innholdsbutikken din som ikke lenger er sikret slik du tror de er ... du har tidsplaner som ikke kjører slik de pleide å kjøre, du har data som ikke lenger er sikret slik du tenker det er, og du kan til og med ha uforklarlige feil for visse operasjoner som du kan egentlig ikke sette fingeren på.
Grunner til at de dårlige og stygge tilnærmingene kan være fryktelige:
- Automatiserte navneområdemigrasjoner legger mye vekt på Content Manager. Inspeksjonen og potensiell oppdatering av hvert enkelt objekt i Content Store kan ofte resultere i titusenvis av SDK -anrop til Cognos (praktisk talt alle flyter gjennom Content Manager). Denne unormale spørringen øker vanligvis minnebruk / belastning og setter innholdsbehandling i fare for å krasje under overføringen. Hvis du allerede har en viss grad av ustabilitet i Cognos -miljøet ditt, bør du være veldig redd for denne tilnærmingen.
- Navneplassoverføringer krever et betydelig vedlikeholdsvindu. Cognos må være oppe, men du vil ikke at folk skal gjøre endringer under migreringsprosessen. Dette vil vanligvis kreve at navnerom -migrering starter når ingen andre jobber, la oss si klokken 10 en fredag kveld. Ingen ønsker å starte et stressende prosjekt klokken 10 en fredag kveld. For ikke å nevne, dine mentale evner er sannsynligvis ikke på sitt beste arbeidskvelder og helger på et prosjekt som gjør krever at du er skarp!
- Jeg har nevnt at Navneplassmigrasjoner er tidskrevende og arbeidskrevende. Her er litt mer om det:
- Innholdskartleggingsprosessen bør gjøres med presisjon, og det krever teamsamarbeid og mange arbeidstimer.
- Flere tørrkjøringer er påkrevd for å se etter feil eller problemer med migrering. En typisk migrasjon går ikke perfekt på første forsøk. Du trenger også en gyldig sikkerhetskopi av Content Store som kan gjenopprettes i slike tilfeller. Vi har sett mange organisasjoner som ikke har en god sikkerhetskopi tilgjengelig (eller har en sikkerhetskopi som de ikke skjønner er ufullstendig).
- Du må identifisere alt utenfor innholdsbutikken som kan bli påvirket (rammemodeller, transformatormodeller osv.). Denne oppgaven kan innebære koordinering på tvers av flere team (spesielt i store delte BI -miljøer).
- Du trenger en god testplan som involverer representanter for mennesker med ulik grad av tilgang til Cognos -innholdet ditt. Nøkkelen her er å bekrefte kort tid etter at migreringen er fullført at alt er fullstendig migrert og fungerer som du forventer. Det er vanligvis upraktisk å bekrefte alt, så du ender opp med å bekrefte det du håper er representative prøver.
- Du må ha broad kunnskap om Cognos -miljøet og ting som er avhengige av det. For eksempel må historiske kuber med tilpassede visninger gjenoppbygges hvis du går NSM -ruten.
- Hva om du eller selskapet du har outsourcet navnerommet til å glemme noe, for eksempel… SDK -applikasjoner? Når du har snudd bryteren, slutter disse tingene å fungere hvis de ikke oppdateres riktig. Har du riktig kontroll for å legge merke til dette umiddelbart, eller vil det ta flere uker / måneder før symptomene begynner å dukke opp?
- Hvis du har gjennomgått mange Cognos -oppgraderinger, kan du potensielt ha objekter i Content Store som er i en inkonsekvent tilstand. Hvis du ikke jobber med SDK, kan du ikke se hvilke objekter som er i denne tilstanden.
Hvorfor erstatning av navnerom er det beste alternativet
De viktigste risikofaktorene og tidkrevende trinnene jeg nettopp har skissert, elimineres når metoden Persona Namespace Replacement brukes. Ved å bruke Namespace Replacement -tilnærmingen har du 5 minutter med Cognos nedetid, og ingenting av innholdet ditt må endres. Den "gode" metoden virker som en kuttet og tørr "no-brainer" for meg. Fredagskvelder er for å slappe av, ikke stresse over det faktum at Content Manager nettopp krasjet midt i en navneoverføring.
