Strukturen for miljøer følger Netcompanys etablerede miljøer for andre infrastrukturløsninger som fx borger.dk og udover de kravstillede miljøer etablerer Netcompany best practice for miljøer med høj tilgængelighed, hvor Produktion og Præprod etableres i to datacentre. Udover de kravstillede miljøer, Produktion, Præprod, Brugertest og Test findes også et udviklingsmiljø til bygning af softwarenden udviklede kildekode.

...

Figur 1 - Etablerede miljøer.

...

Figur 1 De Opsætningen af IT-miljøer, som Netcompany etablerer og driftermiljøerne illustreret i figur 1, er kendetegnet ved følgende træk:

• Redundans. Der er redundans på produktion (Prod) og præproduktion (PræProd), mens brugertest-, test- og udviklingsmiljøer kører på ét site

...

• .

...

...

...

• Adskillelse af Prod og non-Prod. De tekniske miljøer er opdelt, så ingen virtuelle maskiner deles mellem produktion og de øvrige miljøer. Adskillelsen sikrer

...

• fortroligheden af produktionsdata

...

• , samt at

...

• testdata ikke utilsigtet gøres tilgængeligt i produktionsmiljøet. Adgangen til de forskellige miljøer sikres gennem netværksopsætningen og ved konfiguration af

...

• firewallkomponenter i

...

• driftscentre. 

...

• Retvisende performance-test. De virtuelle maskiner, der anvendes i ikke-

...

• produktionsmiljøerne, har samme resurser som produktionsmiljøet, og der kan derfor

...

• gennemføres retvisende performancetests i disse miljøer. Dette sikrer,

...

• at nye funktioner kan performancetestes tidligt og med et retvisende

...

• resultat. Præprod miljøet er topologisk identisk med Prod, hvilket gør det muligt at sikre robust afprøvning som fx effektiv load balancing, scale up eller disaster recovery.  

...

• Fælles infrastrukturservices. For at sikre opfyldelse af servicemålene, er løsningen understøttet

...

• af tværgående infrastrukturservices, der sikrer opsamling af logs, netværk, backup, samt overvågning af servere, applikationer, netværk og fysisk infrastruktur.

...

•  

• Installationsvejledning. Dokumentation indeholder en udførlig installationsvejledning for etablering af nye miljøer eller til retablering af eksisterende miljøer.

Komponenter i det enkelte miljø

Det enkelte miljø indeholder komponenterne Orkestrering, Indeks, Database og Administration (Option), som er vist for et redundant miljø på figuren nedenfor:

...

Figur 2 Sammensætning Figur 2 - Sammensætning af redundant miljø. De grønne elementer repræsenterer instanser af en applikationskomponenten deployet som Docker image. 

Visningsklienter tilgår Orkestreringskomponenten via redundante netværksservices, herunder load balancer og Orkestreringskomponenten henter ligeledes data fra Datakilde over netværket. Opdatering af Indeks for Datakilde og brugeradgang til Administrationskomponent m.m. er udeladt for korthedens skyld, men følger samme principper. Synkronisering mellem de to redundante databasekomponenter sker igennem replikering i Databasekomponenterne, mens de øvrige dele af løsningen er stateless. De grønne komponenter kører alle i Docker, der sikrer styring af hukommelse, CPU og netværk, så servicemål for svartiden kan sikres og ensartet deployment af samme images for Orkestreringskomponent, Indekskomponent og eventuel Administrationskomponent på tværs af miljøer for minimering af driftsfejl. 

Dette bliver yderligere tydeliggjort i nedenstående figur hvor load balancer er medtaget for at tydeliggøre hvordan sammenspillet mellem de to miljøer faciliteres.

...

Figur 3 Opbygning af redundant miljø med load balancer

En forespørgsel kommer fra netværket igennem load balancer, der sender det videre til et af de to datacentre. Forespørgslen bliver derefter processeret i det datacenter det er blevet sendt til. Hvis der i løbet af denne processering benyttes databasen, går dette igennem database load balancer. Database load balancer sender forespørgslen videre til hoved database instansen. Foretages der ændringer i data, bliver disse umiddelbart efter gennemførsel af ændring synkroniseret til replika databasen.

Figuren viser opsætning for produktionsmiljøet, hvor de øvrige miljøer er etableret på tilsvarende vis.

Udviklingsmiljøet indeholder desuden et kode repository og benyttes til at bygge softwarenkildekoden, der efterfølgende kan deployes til alle miljøer.

...

Komponenterne i løsningen er designet med applikationsdriftsprogrammel, middleware, runtime environments og operativsystem, som er velafprøvede standardkomponenter, som Netcompany har erfaring med fra POC og/eller fra andre løsninger. Det sikrer Digitaliseringsstyrelsen en løsning med stor leverancesikkerhed og høj stabilitet i drift. Derudover er er alt softwaren markedsudbredt Open Source, så bindinger til dyre licenser og leverandør undgåsanvendelse af Open Source standardprogrammel som udgangspunkt. Det anvendte standardprogrammel er beskrevet nedenfor:

·       Apache Camel: Integrationsrammeværk, der benyttes til at behandle forespørgsler fra visningsklienter, hente nødvendige data fra datakilder parallelt og samle svar i det korrekte format. Apache Camel er velafprøvet generelt og indgik i POC, hvor det opfyldte de nødvendige krav. Netcompany kan derfor med stor sikkerhed stå inden for softwaren og har de nødvendige kompetencer til den nødvendige udvikling og løbende vedligehold.

·       Spring Boot: Java rammeværk, der er velegnet  Javarammeværk til at integrere Apache Camel med egen applikationskode og sikre testbare applikationer igennem implementering af inversion of controlden udviklede applikationskode. 

·       JSON Schema Validator: Java komponent Javakomponent til validering af JSON Schema, der anbefales af udgiverne af JSON Schema.

·       OpenJDK: Runtime environment for Java standardprogrammel (Apache Camel, Spring Boot og JSON Schema Validator) såvel som egenudviklet kode, der er bredt anvendt og dermed sikrer flytbarhed. Netcompany har god erfaring fra mange andre løsninger med OpenJDK, hvilket giver et højt kompetenceniveau til sikker drift.

·       PostgreSQL: Alt data samles i administrations- og konfigurationsdata af Orkestreringskomponenten er samlet i en PostgreSQL database og tilgås af applikationskomponenter via standardiseret SQL-grænseflade og anvender ingen produktspecifikke databasefunktioner, der gør anvendelse af anden database simpel. For produktion og præproduktionsmiljøer replikeres data på tværs af driftssites, hvilket sikrer at miljøerne altid er korrekt synkroniseret. Netcompany har lang erfaring med brug af PostgreSQL og skalering både op ved forøgelse af hukommelse, CPU og storage i den virtuelle maskine og ud ved anvendelse af flere noder i samme cluster med optimeret brug af forskellige roller for de enkelte nodergrænseflade.

·       Docker: Container teknologiContainerteknologi, der samler alt standardprogrammel og udviklet udvikler applikation for de enkelte komponenter, hvilket sikrer at komponenterne er fuldstændigt identiske på tværs af udvikling-, test- og produktionsmiljøer. Det minimerer risici for fejl ved deployment og sikrer dermed stabil drift. Derudover kan hukommelse, CPU og netværk styres for de enkelte komponenter, så det undgås at fx opdatering af Indeks giver overbelastning af database med dertilhørende forhøjede svartider. Ved at holde alle komponenter på samme virtuelle maskine sikres et meget forenklet setup, hvor svartiden inden for Orkestrerings-komponenten ikke afhænger af andres servere og skal over netværket, hvilket gør fejlfinding simplere.Ved behov for at skalere op udvides ressourcer Ved skaleringsbehov udvides resurser på den underliggende virtuelle maskine og ved behov for at skalere ud kan anvendes , eller der kan skaleres ved at anvende flere virtuelle maskiner. Docker gør det muligt at afvikle hele løsningen hvor Open Container Initiative Runtime Specification understøttes. 

·       Oracle Linux: Operativsystem fra Oracle , der står bag ved Java og dermed giver høj sikkerhed for understøttelsen af Java. Oracle Linux har høj modenhed og er baseret på Red Hat Enterprise Linux, hvilket sikrer bred kompatibilitet med andre udgaver af Linux.