3.2.1 SAULĖ IS technologinės architektūros (diegimo) schema

[RMasiliunaite]

5 pav. Saulė IS technologinės (diegimo) architektūros schema

Aukščiau pateikta principinė SAULĖ IS diegimo schema. Schemoje pateiktas PĮ diegimo paskirstymas tarp virtualių mašinų ir konteinerių yra iliustracinio pobūdžio ir turi būti tikslinamas projektavimo etape, apibrėžiant ir pagrindžiant diegimo paskirstymą kiekvienu atveju.

Lentelė 14. Reikalavimai SAULĖ IS technologinei architektūrai

Reikalavimai	Nr.
Turi būti įdiegtos šios SAULĖ IS aplinkos: ·        Produkcinė; ·        Testavimo; ·        Mokymų aplinka; ·        „Sand box“ aplinka. Turi būti galimybė pagal diegimo instrukciją įdiegti kitas (papildomas) aplinkas, valdyti diegimo apimtį ir pagrindinius parametrus. Testavimo aplinkos architektūriniai sprendimai turi būti paremti produkcinės aplinkos sprendimais. Testavimo aplinkos diegiamų komponentų kiekis gali būti mažinamas (ir / ar grupuojamas) siekiant racionalaus resursų panaudojimo, tokiems sprendimams turi būti gautas Perkančiosios organizacijos pritarimas. Testavimo aplinkai nėra keliami aukšto prieinamumo reikalavimai. Mokymų aplinka turi būti diegiama apimtimi, kuri bus reikalinga mokymams atlikti. Diegimo apimtis turės būti suderinta projektavimo etape. „Sand box“ aplinka turės būti diegiama pagal produkcinės aplinkos architektūrinius principus. „Sand box“ aplinkos diegiamų komponentų kiekis gali būti mažinamas (ir / ar grupuojamas) siekiant racionalaus resursų panaudojimo, tokiems sprendimams turi būti gautas Perkančiosios organizacijos pritarimas. „Sand box“ turi būti realizuojami aukšto prieinamumo sprendimai jų testavimo ir konfigūravimo tikslais. „Sand box“ aplinkos komponentai, įdiegimo apimtis, konfigūravimo parametrai ir panaudoti sprendimai turi būti keičiami Perkančiajai organizacijai nurodžius tokį poreikį. Visi pakeitimai turi būti atliekami siekiant parinkti, išbandyti ir realizuoti tinkamiausius sprendimus SAULĖS IS sukūrimui. Didelių duomenų platformos valdymo PĮ, konteinerių valdymo PĮ, VM platformos valdymo PĮ turi būti diegiama atskiroje techninėje įrangoje nuo techninės įrangos, kurioje įdiegta valdomi komponentai. Išimtys galimos jeigu kitokį diegimą oficialiai rekomenduoja naudojamos PĮ gamintojas. SAULĖS IS komponentai turi būti diegiami konteineriuose („Docker“ ar lygiaverčiuose) ir tiesiogiai virtualiose mašinose. Kiekvieno komponento diegimo principas turi būti pagrįstas projektavimo etape. Schemoje pateiktas PĮ diegimo paskirstymas tarp virtualių mašinų ir konteinerių yra iliustracinio pobūdžio. Konteineriai gali būti diegiami tiesiogiai tarnybinėse stotyse arba VM platformoje. Kiekvieno komponento diegimo principas turi būti pagrįstas projektavimo etape. Testavimo, Mokymosi, „Sand box“ aplinkose turi būti naudojami aktualūs, bet tik „nuasmeninti“ duomenys.	1.
Architektūrinis sprendimas turi užtikrinti SAULĖ IS aukštą prieinamumą (angl. High availability), kuris gali būti realizuojamas virtualizacijos programinės įrangos funkcionalumu, konteinerių orkestravimo programinės įrangos funkcionalumu,  operacinių sistemų funkcionalumu, techninės įrangos galimybėmis ar kitos programinės įrangos pagalba. Aukštas prieinamumas turi būti realizuojamas paslaugų lygyje, integracijų lygyje ir duomenų lygyje. Visų diegiamų komponentų ir jų valdymo komponentų diegimas turi užtikrinti jų aukštą prieinamumą. Aukšto prieinamumo sprendimai turi būti paremti naudojamos PĮ gamintojo rekomendacijomis (pateikiant nuorodas į gamintojo skelbiamas diegimo (aukšto patikimumo) rekomendacijas). Didelių duomenų platformos duomenų mazgai (angl. data nodes) turi būti bent jau triplikuojami. Didelių duomenų valdymo mazgai (angl. name nodes) turi būti diegiami pagal PĮ gamintojo rekomendacijas jų aukštam prieinamumui užtikrinti. Aukšto prieinamumo užtikrinimui ir srautų balansavimui turi būti naudojami apkrovų balansatoriai (angl. load balancers), kurie gali būti diegiami kaip programinė įranga arba naudojama specializuota duomenų centro teikiama techninė įranga (angl. appliances). Aukšto prieinamumo sprendimas turi užtikrinti RPO – 15 min., RTO – 1 val. (kai tokį ar geresnį paslaugų teikimo lygį užtikrina duomenų centro infrastruktūra).	2.
SAULĖ IS turi būti kuriama ir diegiama vadovaujantis mikroservisų architektūros principais: ·        SAULĖ IS turi būti dekomponuojama į logiškus, racionalius, savarankiškai veikiančius programinius vienetus (mikroservisus), kurie su kitais SAULĖS IS mikroservisais komunikuotų RESTful ar lygiaverčių technologijų principais; ·        Mikroservisai turi realizuoti nuosavas duomenų struktūras (tiesiogiai naudojamas tik paties mikroservisų) (išimtys taikomos analizės PĮ, dirbtinio intelekto PĮ ir pan.). ·        Turi būti naudojama PĮ, kuri užtikrintų automatinį mikroservisų paleidimą veikti (angl. auto scaling), kai yra pasiekiamos nustatytos ribinės mikroserviso apkrovos. Bendras SAULĖS IS sprendimas turi leisti (neriboti) mikroservisų automatinio paleidimo funkcionalumo. ·        Turi būti naudojamas mikroservisų paieškos servisas (angl. service registry, service discovery). ·        Komunikavimui tarp mikroservisų turi būti naudojama žinučių eilių valdymo ar lygiavertė programinė įranga. ·        Mikroservisų įdiegimas, veikimas ir išjungimas turi būti nepriklausomas nuo kitų mikroservisų veikimo ar neveikimo. ·        Turi būti naudojami ir kiti būtini mikroservisų architektūros realizavimo principai, remiantis SAULĖS IS architektūros realizavimui naudojamos PĮ gamintojų rekomendacijomis. ·        Naujų SAULĖS IS versijų diegimas neturi reikalauti SAULĖS IS stabdymo (pakartotinio paleidimo). Turi būti vengiama realizuoti monolitines aplikacijas – programinę įrangą, kuri skirtingus dalykinius uždavinius ir savarankiškus panaudos atvejus realizuoja vienoje (ar vos keliuose) aplikacijoje (vienas (ar keli) sukompiliuoti programinės įrangos išeities kodų failai įdiegti viename aplikacijų serveryje).	3.