3.8 Levyn käyttö Tiken OpenShiftissä
Yleistä levyn käytöstä Openshift- ja Kubernetes-alustoilla
https://kubernetes.io/docs/concepts/storage/persistent-volumes/
Lähtökohtaisesti kontin sisällä levylle kirjoitetut muutokset menetetään kun kontti sammuu ja poistetaan. Säilytettävä data täytyy kirjoittaa kontin ulkopuolelta liitettävään levyosioon tai hakemistoon.
Pysyvän datan tallennus tapahtuu Kuberneteksessa abstraktioilla PersistentVolume (PV) ja PersistentVolumeClaim (PVC).
- PersistentVolume (pv) on klusterin tasoinen olio, jolla klusteri viittaa mountattavaan levyyn.
- PersistentVolumeClaim (pvc) on nimiavaruuden eli Openshift-projektin tasoinen olio, jolla Pod voi viitata PersistentVolumeen.
- Näiden kahden välisen liitoksen avulla Podissa oleva kontti voi kirjoittaa jonnekin persistoitavalle levylle.
Podin määrityksen spec-osiossa annetaan kontille volumemount. Volumemountilla viitataan PVC-olioon. Kun PVC-olio on sidottu PV-olioon, Kubernetes huolehtii, että pod ajetaan samalle alustanodella, jolla PV:ssä viitattu levy fyysisesti sijaitsee. Näin pod saa halutun siivun pysyvää tallennustilaa.
Tiken Openshift ja levymountit
Tiken Openshift-alustalla PersistentVolumet tulevat suoraan VMWare-tallennustilasta dynaamisesti provisioituna.
Projekti, jolla on sopivaa quotaa, voi itse määritellä sopivan PersistentVolumeClaim-olion, ja alusta luo automaattisesti levyn (PersistentVolumen) ja tuo sen automaattisesti käyttöön.
Yliopistolla on kuitenkin hajautettu konttialustan tallennus kahteen eri taustajärjestelmään, ja projekti joutuu määrittelemään PersistentVolumeClaimissa StorageClassNamen, joka ohjaa levyn tulemaan oikeasta taustajärjestelmästä. Kullakin projektilla on käytettävissään levyä vain yhdestä taustajärjestelmästä. Konttitilauksen yhteydessä ylläpito valitsee, kummasta taustajärjestelmästä projekti saa levynsä. Tieto oikeasta taustajärjestelmästä kerrotaan projektin tilauksen hyväksynnän yhteydessä.
Esimerkki:
Jos projektisi levytila määritellään StorageClassNamella "pomppa24", saat 10 gigatavua tallennustilaa seuraavanlaisella PersistentVolumeClaim-määrityksellä:
kind: PersistentVolumeClaim
metadata:
name: projektin-persistentvolumeclaim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
storageClassName: pomppa24
Podin volume-määrityksessä viitataan tämän jälkeen PVC:n nimeen "projektin-persistentvolumeclaim".
Jos et tiedä, mikä StorageClassName projektillasi on käytössä, voit katsoa asian itse:
Name: default-resource-quotas
Namespace: xxxxxxxx
Resource Used Hard
-------- ---- ----
nappi-talusta-sata-03-sc.storageclass.storage.k8s.io/persistentvolumeclaims 0 0
persistentvolumeclaims 0 10
pomppa24.storageclass.storage.k8s.io/persistentvolumeclaims 0 10
pomppa25.storageclass.storage.k8s.io/persistentvolumeclaims 0 0
thin.storageclass.storage.k8s.io/persistentvolumeclaims 0 0
.
.
.
Yllä olevassa esimerkissä näkyy, että projektilla on lupa pitää kymmenen PersistentVolumeClaimia pomppa24:ssä, eikä yhtään claimia toisiin StorageClassNameihin.
Levyyn liittyvät reunaehdot Tiken konttialustalla tällä hetkellä
Katso sivu Konttipalvelun reunaehdot projekteille. Levytilaa koskevia asioita kertauksena:
- Levyt ovat VMWaren dynamic provision -virtuaalikonelevyjä, jotka rajoittuvat vain yhteen alustavirtuaalikoneeseen kerrallaan.
- https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes
- Useampi kuin yksi podi VOI mountata saman PVC:n, MUTTA tällöin kaikkia näitä podeja on ajettava samalla nodella. Jos tarkoituksenasi on luoda vikasietoisuutta käyttämällä anti-affinityjä ja pakottaa podeja hajautumaan eri nodeille, tämä on luultavasti ongelma.
- Klusterien laajuista automaattista varmuuskopiointia ei ole (vielä) järjestetty projektien omalle datalle. Huolehdithan itse projektisi datan varmuuskopioinnista.
Suositeltu yhteydenottotapa kysymyksiin on:
https://helsinkifi.slack.com #kontit
Resurssien lisäys/muutospyynnöt kannattaa lähettää sähköpostilla.
grp-openshift-owner@helsinki.fi (alustan ylläpito ja kehitys)
tike-ohjelmistotuotanto@helsinki.fi (sovelluskehitys)