Redundanssi ja korkea käytettävyys
Tiedonkeruussa katkos ei ole pelkkä haitta — se on aukko aikasarjassa, jota ei jälkikäteen aina saa täytettyä. DataPortiassa vikasietoisuus rakennetaan kolmella erillisellä tasolla: OPC UA -yhteydelle, tietokannalle ja sovellukselle. Jokainen taso määritellään erikseen ja jokainen maksaa rautaa.
- 3
- tasoa OPC UA, tietokanta, sovellus
- 15–30 s
- vaihtoaika Sovellustason vaihto
- 2 000+
- arvoa / s Kirjoitusläpäisy
- 8 GB
- RAM / palvelin Minimivaatimus
Menetänkö dataa, jos palvelin kaatuu?
Riippuu siitä, mikä kaatuu. Jos tietokanta katoaa hetkeksi, aikasarjaan ei jää aukkoa lainkaan: DataPortia™ puskuroi arvot muistiin ja kirjoittaa ne perästä, kun yhteys palaa. Jos DataPortia-palvelin itse kaatuu, keruu katkeaa siksi ajaksi, joka kuluu ennen kuin varapalvelin ottaa vuoron.
Muistipuskuri kattaa enintään 120 000 tietuetta yhteyttä kohden — noin 10 minuuttia täydellä yhden sekunnin ja 200 mittapisteen kuormalla. Hälytyksille ja tapahtumille puskuri on oletuksena 50 000 tapahtumaa. Sitä pidempi tietokantakatko alkaa jättää aukkoa.
Tarkemmin: miten aukkopohjainen historiatuonti toimii
Sovellustason vaihdossa jäänyttä aukkoa voi paikata jälkikäteen. Historiatuonti lukee arvot automaatiojärjestelmän omasta OPC UA -historiarekisteristä. Luku on aukkopohjainen: se hakee vain puuttuvat jaksot ja ohittaa jo tuodut, joten samaa dataa ei kahdenneta. Tämä edellyttää, että automaatiojärjestelmä itse säilyttää historiaa — DataPortia ei voi lukea arvoja, joita ei ole missään tallessa. Tuonnin määrittelystä kerrotaan sivulla OPC UA -tiedonkeruu.
Mitä redundanssi kattaa DataPortiassa?
Redundanssi kattaa kolme erillistä tasoa. OPC UA -tasolla jokaiselle yhteydelle voi määrittää varapalvelinparin, johon vaihdetaan automaattisesti. Tietokantatasolla PostgreSQL replikoi datan toiselle koneelle streaming replication -menetelmällä, ja vaihdon voi automatisoida DataPortian omalla DPFC-kontrollerilla. Sovellustasolla toinen DataPortia-palvelin odottaa valmiustilassa ja ottaa keruun vastuun 15–30 sekunnissa, jos aktiivinen lakkaa vastaamasta. Tasot ovat toisistaan riippumattomia: käyttöön voi ottaa yhden, kaksi tai kaikki kolme.
Taulukko: mitä kukin taso suojaa
| Taso | Mekanismi | Mitä se suojaa |
|---|---|---|
| OPC UA -yhteys | Varapalvelinpari yhteyskohtaisesti, automaattinen vaihto | Automaatiojärjestelmän OPC UA -palvelimen vika tai verkkokatkos |
| Tietokanta | PostgreSQL:n fyysinen streaming replication; automaattinen vaihto DPFC:llä, pg_auto_failoverilla tai Patronilla | Tietokantapalvelimen levy-, kone- tai käyttöjärjestelmävika |
| Sovellus | Aktiivinen-passiivinen-kokoonpano, vaihtoaika 15–30 s. Vaatii HA-lisäosan lisenssin | DataPortia-palvelimen kaatuminen tai suunniteltu huoltokatko |
Termit: varapalvelinpari, streaming replication, aktiivinen-passiivinen
- Varapalvelinpari
- Kaksi OPC UA -palvelinosoitetta saman yhteyden takana. Jos ensisijainen ei vastaa, yhteys siirtyy toiseen ilman käyttäjän toimia.
- Streaming replication
- PostgreSQLin oma menetelmä, jossa tapahtumaloki siirretään jatkuvana virtana toiselle tietokantapalvelimelle.
- Aktiivinen-passiivinen
- Vain toinen DataPortia-palvelin kerää dataa kerrallaan. Valmiustilainen palvelin näyttää käyttöliittymän normaalisti, mutta sen OPC UA -tiedonkeruu ja hälytystilaukset ovat pois päältä siihen asti että se ottaa vuoron.
- DPFC
- DataPortia Failover Controller. Atorcomin oma erillinen ohjelma, joka valvoo PostgreSQL-paria ja hoitaa vaihdon automaattisesti — myös Windowsilla.
Mitä tapahtuu, kun OPC UA -palvelin ei vastaa?
Jokaiselle OPC UA -yhteydelle voi määrittää kaksi palvelinosoitetta. Kun ensisijainen lakkaa vastaamasta, DataPortia siirtää yhteyden varaosoitteeseen automaattisesti ja jatkaa tilausten lukemista sieltä ilman käyttäjän toimia. Määrittely tehdään yhteyskohtaisesti, joten kaikkia yhteyksiä ei ole pakko kahdentaa. Vaihto ei edellytä muutoksia automaatiojärjestelmään.
Tarkemmin: mitä tämä taso suojaa ja mitä ei
Taso suojaa automaatiopään vialta: kaatuneelta OPC UA -palvelimelta, vaihdetulta prosessiasemalta tai katkenneelta verkkoreitiltä. Se ei suojaa DataPortian omalta vialta — siihen tarvitaan sovellustason pari. Varapalvelinparin edellytys on, että automaatiojärjestelmässä todella on toinen OPC UA -palvelin: DataPortia ei luo sellaista, vaan käyttää sitä mikä on olemassa. Yhteyksien määrittelystä kerrotaan sivulla OPC UA -tiedonkeruu.
Miten tietokanta suojataan palvelinvialta?
DataPortia tallentaa datan PostgreSQL 18:aan ja TimescaleDB:hen. Vikasietoisuus hoidetaan PostgreSQL:n omalla fyysisellä streaming replication -menetelmällä, jossa data kirjoittuu jatkuvasti toiselle tietokantapalvelimelle. TimescaleDB vaatii nimenomaan fyysisen replikaation — looginen replikaatio ei tue kaikkia sen sisäisiä rakenteita. Replikointi on jatkuvaa, ei ajastettu varmuuskopio.
Molemmilla tietokantasolmuilla on oltava täsmälleen sama PostgreSQL 18- ja TimescaleDB-versio. Fyysinen replikaatio ei toimi eri versioiden välillä. Lisäksi max_connections on nostettava vähintään arvoon 150, koska kaksi DataPortia-instanssia varaa yhdessä noin 120 yhteyttä.
Tarkemmin: vakiotekniikkaa ja replikointilinkin mitoitus
Tietokantataso on vakiintunutta PostgreSQL-tekniikkaa, ei tuotekohtaista viritystä. Se on hyvä asia: klusteria hallitaan tutuilla työkaluilla, ja tietokantaosaaja ylläpitää sitä ilman erillistä koulutusta. Vastapainoksi failover-logiikka on tietokantapuolen vastuulla — DataPortia toimii sen kanssa, mutta ei korvaa sitä.
Mitoita replikointilinkki kirjoitusmäärän mukaan: läpäisy on 2 000+ arvoa sekunnissa eli enimmillään 172 miljoonaa riviä vuorokaudessa. Pakkaus ja säilytysajat käsitellään sivulla OPC UA -tiedonkeruu; replikoinnin läpi kulkee joka tapauksessa tuore, pakkaamaton kirjoitusvirta.
Mikä on DataPortia Failover Controller?
DPFC on Atorcomin oma erillinen ohjelma, joka valvoo PostgreSQL-paria ja hoitaa vaihdon automaattisesti. Sen olennaisin ero valmiisiin työkaluihin on alusta: pg_auto_failover ja Patroni ovat Linux-keskeisiä eivätkä tue Windowsia, joten Windows-ympäristössä automaattinen tietokantavaihto ei aiemmin ollut vaihtoehto lainkaan. DPFC tuo sen myös sinne.
| Vaihtoehto | Alusta | Vaihto |
|---|---|---|
| Skriptattu replikaatio | Windows ja Linux | Manuaalinen promote-komento |
| pg_auto_failover tai Patroni | Vain Linux | Automaattinen |
| DataPortia Failover Controller | Windows ja Linux | Automaattinen |
Tarkemmin: miksi valvontasolmu ja mitä se ei ratkaise
DPFC ajetaan erillisenä prosessina, ei DataPortian sisällä. Syy on yksinkertainen: kun ensisijainen tietokanta on alhaalla, DataPortia itse on joko alhaalla tai kaatumassa — komponentti, jonka tehtävä on huomata se, ei voi asua kaatuvan ohjelman sisällä.
Suositeltu kokoonpano on kolme DPFC-prosessia: yksi kummallakin tietokantasolmulla ja yksi erillisellä valvontasolmulla, joka ratkaisee kumpi solmu on ensisijainen. Valvontasolmuksi riittää kevyt kone. Jos valvontasolmu on alhaalla, automaattista vaihtoa ei tapahdu — tietokannat itse toimivat normaalisti ja vaihdon voi tehdä käsin. Sama rajoitus koskee pg_auto_failoverin omaa monitoria.
Kuinka kauan katkos kestää, kun DataPortia-palvelin kaatuu?
Riippuu siitä miten se kaatuu. Jos DataPortia-prosessi kaatuu mutta kone jää pystyyn, käyttöjärjestelmä sulkee sen tietokantaistunnot ja johtajalukitus vapautuu heti — vaihto kestää noin 15–30 sekuntia. Jos koko kone kuolee sähkö- tai verkkokatkoon, PostgreSQL huomaa kuolleen istunnon vasta TCP keepalive -mekanismin kautta, ja oletusasetuksilla se voi kestää huomattavasti pidempään.
Nopea vaihto myös kovassa vikatilanteessa vaatii keepalive-asetusten virittämisen postgresql.conf-tiedostoon. Ilman sitä luvattu vaihtoaika koskee vain siistiä kaatumista. Asetukset käydään läpi käyttöönotossa.
Tarkemmin: huoltokatkot, tietokannan failover-aika ja aikaleimat
Sama mekanismi palvelee suunniteltua huoltoa: aktiivisen palvelimen voi ajaa alas ja keruu siirtyy varakoneelle, joten käyttöjärjestelmäpäivitykset ja uudelleenkäynnistykset eivät enää katkaise keruuta tunneiksi. Vaihtoaika koskee vain sovellustasoa — tietokannan failover-aika riippuu klusterin omasta kokoonpanosta.
Vaihto alustaa yhteydet samalla tavalla kuin normaali käynnistys: vain ne yhteydet, joissa Yhdistä käynnistyksessä on päällä, muodostuvat automaattisesti valmiustilaisella solmulla. Tuotantoyhteyksissä tämän asetuksen on oltava päällä, muuten korkea käytettävyys ei toimi.
Hälytykset ja tapahtumat tallentuvat automaatiopalvelimen alkuperäisellä aikaleimalla millisekuntitarkkuudella, joten vaihdon jälkeen kerätty aineisto asettuu aikajanalle oikeaan kohtaan eikä vaihtohetki vääristä tapahtumien järjestystä. Aiheesta enemmän sivulla hälytykset ja tapahtumat.
Tarvitsenko kaksi palvelinta?
Et, jos raportointi kestää muutaman tunnin katkoksen. Yksi palvelin riittää valtaosassa asennuksia, ja OPC UA -tason varapalvelinparit toimivat myös yhden palvelimen kokoonpanossa. Toista palvelinta tarvitaan vasta, kun tiedonkeruun on jatkuttava myös DataPortia-koneen vian tai huollon yli. Sovellus- ja tietokantatason redundanssi edellyttävät toista konetta.
Minimivaatimukset koskevat jokaista palvelinta, jolla ohjelmisto ajetaan: 8 GB RAM (suositus 16–32 GB) ja 100 GB SSD.
Tarkemmin: mitä katkos maksaa
Palvelinmäärä on ennen muuta kysymys siitä, mitä katkos maksaa. Jos aikasarja on osa viranomaisraportointia tai laskutusta, aukko on kalliimpi kuin toinen kone. Jos data ohjaa kunnossapitoa ja kuukausiseurantaa, yksi palvelin ja huolellinen varmuuskopiointi ovat oikea mitoitus. Kokoonpano käydään läpi käyttöönoton yhteydessä, joten palvelinmäärää ei tarvitse päättää yksin.
Mitä korkea käytettävyys vaatii käyttöönotolta?
Korkea käytettävyys ei ole valintaruutu asetuksissa. Se vaatii vähintään yhden lisäpalvelimen, PostgreSQL-replikoinnin määrittelyn, verkkosuunnittelun ja päätöksen siitä, mitkä yhteydet ovat redundantteja. Kaikki kolme tasoa konfiguroidaan erikseen, ja ne on syytä myös testata erikseen ennen tuotantokäyttöä. Mikään näistä ei ole eksoottista, mutta yksikään ei tapahdu itsestään ohjelmistoa asennettaessa.
Raja 01
Sovellusvaihto jättää aukon
Lyhyt tietokantakatko ei jätä aukkoa — muistipuskuri kattaa sen. Sovelluspalvelimen kaatuminen jättää.
Raja 02
Automaatiopää ratkaisee
Varapalvelinpari edellyttää toista OPC UA -palvelinta automaatiojärjestelmässä.
Raja 03
Tietokanta on omaa työtään
Failover-klusteri on PostgreSQL-osaamista, ei DataPortian asetussivu.
Tarkemmin: ylläpidon työmäärä
Jos ympäristössä on jo PostgreSQL-osaamista tai valmis klusteri, DataPortia asettuu sen päälle. Jos ei ole, laske mukaan myös ylläpidon työmäärä — kahden palvelimen kokoonpano on pysyvästi enemmän hallittavaa kuin yhden.
Usein kysyttyä redundanssista
Redundanssi on kokoonpanoasia, joka mitoitetaan hyväksyttävän katkoksen pituuden mukaan, ei oletuksena kaikille samalla tavalla. Alla lyhyet vastaukset kysymyksiin, jotka toistuvat korkeasta käytettävyydestä keskusteltaessa: tarvitaanko eri ohjelmistoversio, voiko redundanssin lisätä jälkikäteen, mitä se maksaa ja voiko kokoonpanoa testata ennen ostoa.
Tarvitseeko korkea käytettävyys eri ohjelmistoversion?
Ei. Toiminnot ovat samassa ohjelmistossa, ja kokoonpano käydään läpi käyttöönoton yhteydessä.
Voiko redundanssin lisätä myöhemmin?
Redundanssi on kokoonpanoasia, joten sen voi rakentaa myös olemassa olevan asennuksen päälle. Käytännössä se tarkoittaa uutta palvelinta ja tietokantatason suunnittelua uudelleen, joten kerro suunnitelmasta mieluummin aikaisin kuin myöhään.
Toimiiko DataPortia pg_auto_failoverin tai Patronin kanssa?
Kyllä. Tietokantataso perustuu PostgreSQL:n omaan streaming replicationiin, joten pg_auto_failover ja Patroni käyvät molemmat. Ne toimivat kuitenkin vain Linuxissa. Windows-ympäristössä automaattinen vaihto tehdään DataPortian omalla DPFC-kontrollerilla — vaihtoehtona on skriptattu replikaatio ja käsin annettava promote-komento.
Menetetäänkö hälytyksiä vaihdon aikana?
Tietokantakatkossa ei: hälytys- ja tapahtumatilaukset puskuroivat muistiin oletuksena 50 000 tapahtumaa ja purkavat puskurin, kun yhteys palaa. Sovelluspalvelimen kaatuessa vaihdon aikaisia tapahtumia ei kerätä. Kerätyt hälytykset säilyttävät automaatiopalvelimen alkuperäisen millisekuntiaikaleiman. DataPortia on raportoiva järjestelmä: hälytysten ensisijainen käsittely kuuluu automaatiojärjestelmään, ei raportointiohjelmistoon.
Mitä korkea käytettävyys maksaa?
Kolme erää: lisärauta, määrittelytyö ja lisenssit. Sovellustason kahdennus vaatii erillisen HA-lisäosan lisenssin, joka lisensoidaan asennuskohtaisesti — yksi lisenssi kattaa koko parin. Sen lisäksi peruslisenssi on laitteistosidottu, joten kumpikin palvelin tarvitsee oman peruslisenssinsä — tai käytetään floating-lisenssiä, joka on suunniteltu juuri tähän. Kerro ympäristösi, niin lasken kokonaisuuden.
Voiko kokoonpanoa testata ennen ostoa?
Osittain. Kokeilu on 30 päivää ilman sitoumusta, mutta HA-lisäosa ei sisälly kokeilujaksoon — kahdennuskytkintä ei siis saa päälle kokeiluversiossa. Tiedonkeruun, raportoinnin ja kaiken muun voi testata normaalisti, ja korkean käytettävyyden kokoonpanon käyn läpi kanssasi erikseen.
Jos tiedonkeruun on jatkuttava myös silloin kun jokin hajoaa, käy ympäristö läpi ennen asennusta: montako OPC UA -palvelinta on käytettävissä, mitä tietokantapuolella jo ajetaan ja kuinka pitkä katkos on hyväksyttävä.
Muut osa-alueet: raportointi, integraatiot ja DataPortian yleiskuvaus.