Designdokument for Exchange integrasjonen

3.2.1   Generell oversikt over Cerebrum-komponenter

Applikasjonen, eller "motoren", for hendelsesbasert oppdatering, kalles Exchange Event Daemon i dette tilfellet. EED er, og besørger, oppstart av forskjellige komponenter som besørger propagering av hendelser mellom APIet og integrasjoner.

3.2.2   Komponenter

EED består i hovedsak av følgende komponenter (klasser/prosesser):

• Notification Collector

  Denne komponenten lytter etter NOTIFY-hendelser fra Postgres (valg av hvilke kanaler det lyttes på, skjer på bakgrunn av konfigurasjon). Hendelsene som blir mottatt, blir lagt i en kø, for videre behandling av Exchange Client. Hendelsene blir også markert som "under behandling" i Postgres-databasen.

• Delayed Notification Collector Den forsinkede hendelseshenteren samler hendelser og legger disse på køen. Innsamling av hendelser skjer på bakgrunn av kriterier som omfatter hvor mange ganger en hendelse har feilet, hvor lenge det er siden den feilet, og hvor lenge det er siden hendelsen ble opprettet.

  Typisk vil den forsinkede hendelseshenteren samle alle tidligere feilede, og nye, hendelser, når integrasjonen starter, siden Notification Collector ikke vil ha begrep om at disse har inntruffet.

  Hendelseshenteren kjører periodisk for å samle inn feilede hendelser.

• Exchange Client

  Komponenten henter nye hendelser som skal behandles fra køen, og leter opp endringsinformasjonen fra tabellen event_log. Endringens karakter bestemmer videre hvilke kall som blir gjort mot Exchange. Når hendelsen er bekreftet utført i Exchange, oppdaterer Exchange Client aktuell rad i event_log som utført.

3.2.3   Generell oversikt over flyt i Exchange Event Daemon

1. NotificationCollector startes
2. Ubehandlede hendelser laget før NotificationCollector ble startet hentes inn og settes i kø. Hvis ingen meldinger om hendelser blir mottatt i løpet av et gitt tidsrom, så sjekker NotificationCollector databasen etter endringer som ikke har blitt tatt.
3. Et gitt antall instanser av Exchange Client starter
4. EED kjører et utplukk fra event_log med jevne mellomrom, som henter ut ubehandlede hendelser fra fortiden, og køer disse

+-------+
|       |                 +--------+
| *-    |        +--------|  EED   |----------+
| import|        |        +--------+          |
|       |        |               |            |
|       |        |             +---+          |
+-------+        |    +-------→|CLQ| ---+     |
    | 1.         | 4. |        +---+    | 5.  |
    |            |    |           ↑     |     |
    ↓            |    |           |     ↓     |
+----------+    +--------------+  |   +-----------+
|          |    | Notification |  |   | Exchange- |
| Cerebrum |    | Collector    |  |   | Event-    |
|          |    |              |  |   | Handler   |
+----------+    +--------------+  |   +-----------+
       |           ↑              |    |      |
       |           |              +----+   6. |
       |           |               7.         ↓
       |           | 3.                +----------+
       | 2.        |                   | Exchange |
       ↓           |                   | Client   |
    +------------+ |                   +----------+
    |            | |                       |
    |  Trigger-  |-+                       |  +------------+
    |  procedure |                         +-→|            |
    |            |                            |  Exchange  |
    +------------+                            |            |
                                              +------------+

1. En importen fra et kildesystem kjører, og lagrer f.eks. nye personer i Cerebrum. Når det logges hendelser, konsulterer APIet tabellen event_to_target, for å avgjøre hvilke målsystem det skal lages hendelser for.
2. Når rader skrives til event_log tabellen, startes en utløserprosedyre på databasesiden
3. Utløserprosedyren sender en beskjed til NotificationCollector om at en hendelse har inntruffet
4. NotificationCollector henter ut aktuell informasjon om hendelsen, og legger hendelsen på køen som deles med ExchangeClient
5. ExchangeEventHandler henter ut hendelser fra køen
6. ExchangeEventHandler utfører passende kall mot Exchange, alt etter hva hendelsen dikterer, via ExchangeClient
7. Hvis kallet mot Exchange ikke kan bli utført ved daværende tidspunkt køes hendelsen på nytt.

3.2.4   Bruk av PSSessions

Når Exchange-integrasjonen skal provisjonere noe i Exchange, kobler den seg først til en springbrett-maskin med WinRM protokollen, på samme måte som AD2-integrasjonen gjør i dag.

Fra springbrett-maskinen opprettes det en PSSession (omtrent det samme som SSH), fra springbrett-maskinen, til en management-maskin, der kommandoer kjøres.

Behovet for å benytte PSSessions er todelt:

1. Besørge privilegieeskalering, da WinRM kobler seg til med en maskin-lokal bruker. Følgelig må man gjøre PSSession mot en ny maskin, da det ikke er lov å gjøre mot localhost.
2. For å kjøre en Exchange-kommando, må modulen (?) RemoteExchange.ps1 sources, og funksjonen Connect-ExchangeServer kjøres. Dette tar alt fra 10 til 60 sekunder (!). Ved bruk av PSSessions trenger man ikke å gjøre dette per Exchange-kommando som kjøres.

Flytskjemaet nedenfor illustrerer tre eksekveringer av kommandoen New-Mailbox, gjennom integrasjonens livssyklus (fra start til stop).

1. I det første kallet opprettes en PSSession med New-PSSession, og kallet avsluttes med Disconnect-PSSession, for å gjøre PSSessionen tilgjengelig for fremtidige kall.
2. I det andre kallet gjøres Get-PSSession for å hente en eksisterende PSSession, før eksekvering.
3. I det tredje og siste kallet, avslutter vi med å utføre Remove-PSSession, for å avslutte eksisterende sesjon.

3.2.5   Bruk av tråder og prosesser

EED bruker en kombinasjon av tråder og prosesser for å gjøre jobben sin. I begynnelsen var det planlagt å støtte flere samtidige kall mot Exchange, for å få god hastighet på provisjonering, spesielt i perioder med høy last, som for eksempel semesterstart.

Integrasjonen kunne ikke belage seg på å kjøre flere samtidige instanser av ExchangeEventHandler som tråder i EED, da urllib2 som benyttes til kommunikasjon over HTTP(S) av WinRM klienten, ikke er trådsikker. Følgelig blir ExchangeEventHandler, NotificationCollector og DelayedNotificationCollector kjørt som prosesser.

At flere tett relaterte komponenter kjøres som prosesser, byr på problemer i forbindelse med logging. logger rammeverket var ikke prosess-sikkert, noe som resulterte i høyst inkonsistente logger. Dette er fikset ved starte en logger-tråd fra EED, som lytter på en kø etter loggmeldinger fra de prosessene som EED starter, før logger tråden skriver loggmeldingene til fil.

Dette kunne vært løst bedre ved en av følgende: - Benytte noe annet en urllib2 i WinRM-klienten, slik at prosess-behov bortfalt. - Implementere låsing på filnivå i logger. - Logge til forskjellige filer for hver komponent.

Nu er det dog slik, at Exchange ikke låser objekter når de oppdateres. Dette ser vi effekten av hvis vi kjører et moderat antall samtidige arbeidere (ExchangeEventHandler), og oppretter en bruker. Brukeren vil da ende opp med et subsett av sine adresser, da de forskjellige arbeiderne setter en adresse hver, omtrent samtidig. Dette kunne vært løst ved å låse hendelser på bakgrunn av entiteten de berører, men dette er ikke trivielt.

3.2.6   Relaterte tabeller i databasen

event_log

Tabell som inneholder utestående hendelser.

target_system_code

Oversikt over målsystemer som kan motta hendelser. Brukes av APIet til mangfoldiggjøring av en hendelse.

event_to_target

Binding av hendelsestyper til målsystem. Populeres av contrib/populate-target-systems.py, på bakgrunn av konfigurasjon (eventconf.py).

3.2.7   Verifikasjon av tilstand mellom Cerebrum og Exchange

Det er utarbeidet funksjonalitet for å verifisering at tilstanden i Cerebrum og Exchange er korrekt. Dette eksisterer for konti og distribusjonsgrupper.

Tilstandsverifikasjonsjobbene henter ut informasjon fra Cerebrum via API, og fra Exchange via LDAPS, og sammenligner disse, før eventuelt avvik blir rapportert per e-post til interessenter.

Valget av LDAPS er begrunnet i kjøretid. LDAP er raskere med tanke på oppslag enn Exchange sine administrasjonskommandoer.

Følgende verktøy implementerer denne funksjonaliteten: - contrib/exchange/exchange_group_state_verification.py - contrib/exchange/exchange_mailbox_state_verification.py