Gdy musisz ponownie skonfigurować istniejące środowisko Cognos, aby korzystało z innego zewnętrznego źródła bezpieczeństwa (np. Active Directory, LDAP itp.), możesz zastosować kilka metod. Lubię je nazywać „Dobry, Zły i Brzydki”. Zanim omówimy te dobre, złe i brzydkie podejścia, przyjrzyjmy się kilku typowym scenariuszom, które mają tendencję do powodowania zmian przestrzeni nazw uwierzytelniania w środowisku Cognos.
Wspólne sterowniki biznesowe:
Aktualizacja sprzętu lub systemu operacyjnego – Częstym czynnikiem napędzającym może być modernizacja sprzętu/infrastruktury BI. Podczas gdy reszta Cognos może działać jak mistrz na twoim nowym, eleganckim sprzęcie i nowoczesnym 64-bitowym systemie operacyjnym, powodzenia w migracji twojej wersji Access Managera z około 2005 roku na tę nową platformę. Access Manager (po raz pierwszy wydany z Serią 7) to szacowna pamiątka z minionych dni dla wielu klientów Cognos. Jest to jedyny powód, dla którego wielu klientów trzyma się tej zboczonej, starej wersji Windows Server 2003. Pisanie o Access Manager krążyło już od dłuższego czasu. Jest to starsze oprogramowanie. Im szybciej odejdziesz, tym lepiej.
Standaryzacja aplikacji– Organizacje, które chcą skonsolidować uwierzytelnianie wszystkich swoich aplikacji na jednym centralnie administrowanym firmowym serwerze katalogowym (np. LDAP, AD).
fuzje i przejęcia– Firma A kupuje firmę B i potrzebuje środowiska Cognos firmy B, aby wskazywało serwer katalogowy firmy A bez powodowania problemów z istniejącą zawartością lub konfiguracją BI.
Zbycia korporacyjne– Jest to przeciwieństwo scenariusza fuzji, część firmy zostaje wydzielona do własnego podmiotu i teraz musi skierować swoje istniejące środowisko BI na nowe źródło bezpieczeństwa.
Dlaczego migracje przestrzeni nazw mogą być bałaganiarskie
Wskazanie środowiska Cognos na nowe źródło bezpieczeństwa nie jest tak proste, jak dodanie nowej przestrzeni nazw z tymi samymi użytkownikami, grupami i rolami, odłączenie starej przestrzeni nazw i VOILA! — wszyscy użytkownicy Cognos w nowej przestrzeni nazw są dopasowywani do ich treść. W rzeczywistości często możesz skończyć z krwawym bałaganem na rękach, a oto dlaczego…
Do wszystkich podmiotów zabezpieczeń Cognos (użytkowników, grup, ról) odwołuje się unikalny identyfikator zwany CAMID. Nawet jeśli wszystkie inne atrybuty są takie same, CAMID dla użytkownika w Przede wszystkim system został opracowany przestrzeń nazw uwierzytelniania nie będzie taka sama jak CAMID dla tego użytkownika w nowa przestrzeń nazw. Może to siać spustoszenie w istniejącym środowisku Cognos. Nawet jeśli masz tylko kilku użytkowników Cognos, musisz zdać sobie sprawę, że odniesienia CAMID istnieją w WIELU różnych miejscach w Twoim składnicy treści (i mogą nawet istnieć poza składnicą treści w modelach Framework, modelach Transformer, aplikacjach TM1, kostkach, aplikacjach do planowania itp. ).
Wielu klientów Cognos błędnie uważa, że CAMID tak naprawdę liczy się tylko dla zawartości Mojego folderu, preferencji użytkownika itp. To nie może być dalsze od prawdy. To nie tylko kwestia liczby użytkowników, ale liczba obiektów Cognos, którymi musisz się zająć. W składnicy treści znajduje się ponad 140 różnych typów obiektów Cognos, z których wiele może mieć wiele odniesień CAMID.
Na przykład:
- Nie jest niczym niezwykłym, że jeden harmonogram w Twoim magazynie treści ma wiele odniesień CAMID (CAMID właściciela harmonogramu, CAMID użytkownika, pod którym harmonogram powinien działać, CAMID każdego użytkownika lub listy dystrybucyjnej, do którego należy wysłać e-mailem wygenerowany raport wyjściowy do itp.).
- Każdy obiekt w Cognos ma politykę bezpieczeństwa, która określa, którzy użytkownicy mogą uzyskać dostęp do obiektu (pomyśl „karta Uprawnienia”). Pojedyncza polityka bezpieczeństwa zawieszona na tym folderze w Cognos Connection ma odniesienie CAMID dla każdego użytkownika, grupy i roli, które są określone w tej polityce.
- Mam nadzieję, że rozumiesz, o co chodzi – ta lista jest długa!
Nierzadko zdarza się, że spory magazyn treści zawiera dziesiątki tysięcy odniesień CAMID (a widzieliśmy kilka dużych z setkami tysięcy).
Teraz policz, co jest w Twój Środowisko Cognos i widać, że potencjalnie masz do czynienia z hordami referencji CAMID. To może być koszmar! Przełączanie (lub ponowne konfigurowanie) przestrzeni nazw uwierzytelniania może pozostawić wszystkie te odwołania CAMID w stanie nierozwiązywalnym. To nieuchronnie prowadzi do problemów z zawartością i konfiguracją Cognos (np. harmonogramy, które już nie działają, zawartość, która nie jest już zabezpieczona w sposób, w jaki myślisz, pakiety lub kostki, które nie implementują już prawidłowo zabezpieczeń na poziomie danych, utrata zawartości Mojego folderu i użytkownika preferencje itp.).
Metody przejścia przestrzeni nazw Cognos
Teraz, wiedząc, że środowisko Cognos może mieć dziesiątki tysięcy odniesień CAMID, które będą wymagały znalezienia, mapowania i aktualizacji do odpowiadającej im nowej wartości CAMID w nowej przestrzeni nazw uwierzytelniania, omówmy dobre, złe i brzydkie podejścia do rozwiązania tego problemu.
Dobry: Zastąpienie przestrzeni nazw za pomocą Persona
Pierwsza metoda (Zastępowanie przestrzeni nazw) wykorzystuje Motiojest, IQ osoby produkt. Przyjmując takie podejście, istniejąca przestrzeń nazw jest „zastępowana” specjalną przestrzenią nazw Persona, która umożliwia wirtualizację wszystkich podmiotów zabezpieczeń, które są udostępniane Cognos. Istniejące wcześniej podmioty zabezpieczeń zostaną udostępnione Cognos z dokładnie tym samym CAMID co wcześniej, nawet jeśli mogą być wspierane przez dowolną liczbę zewnętrznych źródeł zabezpieczeń (np. Active Directory, LDAP lub nawet bazę danych Persona).
Piękne w tym podejściu jest to, że wymaga ZERO zmian w treści Cognos. Dzieje się tak, ponieważ Persona może utrzymywać CAMID wcześniej istniejących zleceniodawców, nawet jeśli są one wspierane przez nowe źródło. A więc… wszystkie te dziesiątki tysięcy referencji CAMID w Twoim Content Store, zewnętrznych modelach i historycznych kostkach? Mogą pozostać dokładnie takie, jakie są. Nie jest wymagana żadna praca.
Jest to zdecydowanie najmniej ryzykowne i najmniej obciążające podejście, którego można użyć do przenoszenia istniejącego środowiska Cognos z jednego zewnętrznego źródła zabezpieczeń do drugiego. Można to zrobić w niecałą godzinę z około 5 minutami przestoju Cognos (jedynym przestojem Cognos jest ponowne uruchomienie Cognos po skonfigurowaniu przestrzeni nazw Persona).
Bad: Migracja przestrzeni nazw przy użyciu Persona
Jeśli łatwym podejściem o niskim ryzyku nie jest po prostu twoja filiżanka herbaty, to tam is inna opcja.
Persona może być również używana do przeprowadzania migracji przestrzeni nazw.
Obejmuje to zainstalowanie drugiej przestrzeni nazw uwierzytelniania w środowisku Cognos, mapowanie (miejmy nadzieję) wszystkich istniejących podmiotów zabezpieczeń (ze starej przestrzeni nazw) na odpowiadające im podmioty w nowej przestrzeni nazw, a następnie (oto zabawna część), znajdowanie, mapowanie i aktualizowanie każdego pojedyncze odniesienie CAMID, które istnieje w środowisku Cognos: składnica treści, modele ramowe, modele transformatorów, kostki historyczne, aplikacje TM1, aplikacje do planowania itp.
Takie podejście jest zwykle stresujące i intensywnie przetwarzające procesy, ale jeśli jesteś administratorem Cognos, który potrzebuje odrobiny adrenaliny, aby poczuć się żywym (i nie ma nic przeciwko telefonom późnym wieczorem lub wczesnym rankiem), to może… to jest opcja, której szukasz?
Persona może być wykorzystana do zautomatyzowania części tego procesu. Pomoże Ci utworzyć mapowanie między starymi podmiotami zabezpieczeń a nowymi podmiotami zabezpieczeń, zautomatyzować logikę brute force „znajdź, przeanalizuj, zaktualizuj” dla zawartości w magazynie treści itp. Co Persona może zautomatyzować niektóre zadania tutaj, dużo pracy w tym podejściu dotyczy raczej „ludzi i procesu”, niż rzeczywistej technologii.
Na przykład – kompilacja informacji o każdym modelu Framework Managera, każdym modelu Transformera, każdej aplikacji Planning/TM1, każdej aplikacji SDK, która jest ich właścicielem, oraz zaplanowanie ich aktualizacji i redystrybucji może być bardzo pracochłonne. Koordynowanie przestojów dla każdego środowiska Cognos, w którym chcesz to wypróbować, oraz okien konserwacyjnych, podczas których można podjąć próbę migracji, może obejmować planowanie i „przestój” Cognos. Wymyślenie (i wykonanie) skutecznego planu testów po migracji również może być nie lada wyzwaniem.
To całkiem normalne, że najpierw będziesz chciał wykonać ten proces w środowisku nieprodukcyjnym zanim wypróbowanie go w produkcji.
Chociaż migracja przestrzeni nazw z Persona działa (i jest znacznie lepsza niż podejście „Brzydkie” poniżej), jest bardziej inwazyjna, bardziej ryzykowna, angażuje znacznie więcej personelu i zajmuje znacznie więcej roboczogodzin niż zastępowanie przestrzeni nazw. Zazwyczaj migracje należy wykonywać poza godzinami pracy, podczas gdy środowisko Cognos jest nadal w trybie online, ale korzystanie z formularzy jest ograniczone przez użytkowników końcowych.
Brzydki: Usługi ręcznej migracji przestrzeni nazw
Brzydka metoda obejmuje nie do pozazdroszczenia podejście polegające na próbie: ręcznie migrować z jednej przestrzeni nazw uwierzytelniania do innej. Obejmuje to połączenie drugiej przestrzeni nazw uwierzytelniania ze środowiskiem Cognos, a następnie próbę ręcznego przeniesienia lub odtworzenia znacznej części istniejącej treści i konfiguracji Cognos.
Na przykład, stosując to podejście, administrator Cognos może próbować:
- Odtwórz grupy i role w nowej przestrzeni nazw
- Odtwórz członkostwo tych grup i ról w nowej przestrzeni nazw
- Ręcznie skopiuj zawartość moich folderów, preferencje użytkownika, zakładki portalu itp. z każdego konta źródłowego do każdego konta docelowego
- Znajdź każdy zestaw zasad w magazynie treści i zaktualizuj go, aby odwoływał się do równoważnych podmiotów zabezpieczeń w nowej przestrzeni nazw w dokładnie taki sam sposób, w jaki odwoływał się do podmiotów ze starej przestrzeni nazw
- Odtwórz wszystkie harmonogramy i wypełnij je odpowiednimi danymi uwierzytelniającymi, odbiorcami itp.
- Zresetuj wszystkie właściwości „właściciel” i „kontakt” wszystkich obiektów w składnicy treści
- [Około 40 innych rzeczy w Content Store, o których zapomnisz]
- Zbierz wszystkie modele FM z zabezpieczeniami na poziomie obiektu lub danych:
- Zaktualizuj odpowiednio każdy model
- Opublikuj ponownie każdy model
- Przekaż zmodyfikowany model z powrotem do oryginalnego autora
- Podobna praca dla modeli Transformer, aplikacji TM1 i aplikacji planistycznych, które są zabezpieczone przed oryginalną przestrzenią nazw
- [i wiele więcej]
Podczas gdy niektórzy masochiści z Cognos mogą potajemnie chichotać z radości na myśl o kliknięciu 400,000 XNUMX razy w Cognos Connection, dla większości rozsądnych ludzi takie podejście wydaje się być niezwykle żmudne, czasochłonne i podatne na błędy. Nie jest to jednak największy problem w tym podejściu.
Największym problemem z tym podejściem jest to, że prawie zawsze prowadzi do niepełnej migracji.
Stosując to podejście, (boleśnie) znajdujesz i próbujesz zmapować te odniesienia CAMID, o których wiesz… ale zwykle pozostawiasz wszystkie te odniesienia CAMID, które nie wiem o.
Po myśleć skończyłeś z tym podejściem, często nie jesteś naprawdę Gotowe.
Masz obiekty w swoim magazynie treści, które nie są już zabezpieczone w sposób, w jaki myślisz, że są… masz harmonogramy, które nie działają tak, jak kiedyś, masz dane, które nie są już zabezpieczone tak, jak myślisz tak jest i możesz mieć nawet niewyjaśnione błędy dla niektórych operacji, które: tak naprawdę nie możesz położyć palca.
Powody, dla których złe i brzydkie podejście może być okropne:
- Zautomatyzowane migracje przestrzeni nazw kładą duży nacisk na Content Manager. Inspekcja i potencjalna aktualizacja każdego pojedynczego obiektu w Twoim magazynie treści może często skutkować dziesiątkami tysięcy wywołań SDK do Cognos (z których praktycznie wszystkie przepływają przez Menedżera treści). To nienormalne zapytania zazwyczaj zwiększają zużycie/obciążenie pamięci i narażają Menedżera treści na ryzyko awarii podczas migracji. Jeśli masz już jakąś niestabilność w swoim środowisku Cognos, powinieneś bardzo się obawiać takiego podejścia.
- Migracje przestrzeni nazw wymagają dużego okna obsługi. Cognos musi działać, ale nie chcesz, aby ludzie wprowadzali zmiany podczas procesu migracji. Zwykle wymaga to rozpoczęcia migracji przestrzeni nazw, gdy nikt inny nie pracuje, powiedzmy o 10:10 w piątek wieczorem. Nikt nie chce zaczynać stresującego projektu o XNUMX w piątek wieczorem. Nie wspominając o tym, że twoje zdolności umysłowe prawdopodobnie nie są najlepsze wieczory i weekendy w pracy nad projektem, który: robi wymagaj bycia ostrym!
- Wspomniałem, że migracje przestrzeni nazw są czasochłonne i pracochłonne. Oto trochę więcej na ten temat:
- Proces mapowania treści powinien być wykonany precyzyjnie, a to wymaga współpracy zespołowej i wielu roboczogodzin.
- Aby sprawdzić błędy lub problemy związane z migracją, wymagane jest wielokrotne uruchomienie próbne. Typowa migracja nie przebiega idealnie za pierwszym razem. Potrzebna będzie również prawidłowa kopia zapasowa magazynu treści, którą można w takich przypadkach przywrócić. Widzieliśmy wiele organizacji, które nie mają dobrej kopii zapasowej (lub mają kopię zapasową, o której nie zdają sobie sprawy, że jest niekompletna).
- Musisz wszystko zidentyfikować zewnętrzne Content Store, na który może mieć wpływ potencjalny wpływ (modele ramowe, modele transformatorów itp.). To zadanie może obejmować koordynację między wieloma zespołami (szczególnie w dużych współużytkowanych środowiskach BI).
- Potrzebujesz dobrego planu testów, który obejmuje reprezentatywne osoby o różnym stopniu dostępu do treści Cognos. Kluczem jest tutaj sprawdzenie, zaraz po zakończeniu migracji, czy wszystko jest w pełni zmigrowane i działa zgodnie z oczekiwaniami. Weryfikacja wszystkiego jest zazwyczaj niepraktyczna, więc kończy się weryfikacją tego, co masz nadzieję, że są reprezentatywnymi próbkami.
- Musisz mieć broad znajomość środowiska Cognos i rzeczy od niego zależnych. Na przykład historyczne kostki z niestandardowymi widokami MUSZĄ zostać odbudowane, jeśli pójdziesz drogą NSM.
- Co się stanie, jeśli Ty lub firma, której zleciłeś migrację przestrzeni nazw, zapomni o czymś, na przykład… aplikacjach SDK? Po przełączeniu przełącznika te rzeczy przestają działać, jeśli nie są prawidłowo aktualizowane. Czy masz odpowiednie kontrole, aby zauważyć to natychmiast, czy też minie kilka tygodni/miesięcy, zanim objawy zaczną się pojawiać?
- Jeśli przeszedłeś wiele uaktualnień Cognos, potencjalnie możesz mieć obiekty w swoim składnicy treści, które są w niespójnym stanie. Jeśli nie pracujesz z pakietem SDK, nie będziesz w stanie zobaczyć, które obiekty znajdują się w tym stanie.
Dlaczego zastąpienie przestrzeni nazw jest najlepszą opcją?
Kluczowe czynniki ryzyka i czasochłonne kroki, które właśnie nakreśliłem, są eliminowane, gdy używana jest metoda zastępowania przestrzeni nazw Persona. Korzystając z podejścia zastępowania przestrzeni nazw, masz 5 minut przestoju Cognos i żadna z Twoich treści nie musi się zmieniać. „Dobra” metoda wydaje mi się ciętym i suchym „bez myślenia”. Piątkowe wieczory to relaks, a nie stresowanie się faktem, że Menedżer treści właśnie się zawiesił w trakcie migracji przestrzeni nazw.
