Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

GDOKEDNT Her finder du beskrivelse af de miljøer der er opsat for Orkestreringskomponenten

Redaktør: Kurt Hansen


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 også et udviklingsmiljø til bygning af softwaren.

Figur 1 De IT-miljøer, som Netcompany etablerer og drifter. Der er redundans på produktion (Prod) og præproduktion (PræProd), mens brugertest-, test- og udviklingsmiljøer kører på ét site. Løsningen benytter desuden Netcompany infrastrukturservices som netværk, overvågning, logning og backup illustreret med grå farve.

 

Opsætningen af IT-miljøerne er kendetegnet ved følgende træk:

·       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 at fortroligheden af produktionsdata overholdes, samt at test data ikke utilsigtet gøres tilgængeligt i produktionsmiljøet. Adgangen til de forskellige miljøer sikres gennem netværksopsætningen og ved konfiguration af firewall komponenter i Netcompanys driftscentre. 

·       Retvisende performance-test. De virtuelle maskiner der anvendes i ikke-produktionsmiljøerne har samme ressourcer som produktionsmiljøet, og kan derfor gennemføre retvisende performancetests, hvilket sikrer at nye funktioner kan performancetestes tidligt og med et retvisende resultat også på de nedskalerede miljøer. 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.  

·       Eksisterende infrastrukturservices. For at sikre opfyldelse af servicemålene, er løsningen understøttet af Netcompanys tværgående infrastrukturservices, der sikrer opsamling af logs, netværk, backup, samt overvågning af servere, applikationer, netværk og fysisk infrastruktur. Disse komponenter har høj driftssikkerhed ved placering på tværs af driftssites og kan skaleres både op og ud. Designet er uden bindinger til Netcompanys specifikke infrastrukturservices og sikrer således flytbarhed til andre leverandører. Anvendelsen sikrer desuden både en robust tidsplan og en sikker implementering på kendte services.

·       Dokumenteret installationsvejledning. Netcompanys standarddokumentation indeholder en udførlig installationsvejledning som udarbejdes og afprøves som en del af dokumentationsprøven. Vejledningen er nok den vigtigste forudsætning for en succesfuld flytning af løsningen til et nyt driftsmiljø. Netcompany har omfattende erfaringer med overtagelse af driftsydelser fra andre leverandører af offentlig infrastruktur. Disse erfaringer er indarbejdet i strukturen og indholdet i installationsvejledning og de øvrige dokumentationstyper i Netcompanys metode.

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 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.

 

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

Standardprogrammel

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ås. 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 til at integrere Apache Camel med egen applikationskode og sikre testbare applikationer igennem implementering af inversion of control. 

·       JSON Schema Validator: Java komponent 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 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 noder.

·       Docker: Container teknologi, der samler alt standardprogrammel og udviklet 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 på den underliggende virtuelle maskine og ved behov for at skalere ud kan anvendes 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.

 Historik
Version Date Comment
Current Version (v. 2) Feb 18, 2021 19:09 Kurt Hansen
v. 7 Nov 11, 2021 09:52 Astrid Cold
v. 6 Nov 04, 2021 14:07 Astrid Cold
v. 5 Oct 29, 2021 12:44 Kurt Hansen
v. 4 Apr 19, 2021 16:21 Kurt Hansen
v. 3 Apr 19, 2021 16:21 Kurt Hansen
v. 2 Feb 18, 2021 19:09 Kurt Hansen
v. 1 Jun 15, 2020 08:39 Kurt Hansen
  • No labels