Hyppää sisältöön

Docs CSC now features an automatic Finnish translation. Click here for more information.

Warning!

Puhti and Mahti will be decommissioned after Roihu becomes available. Users should clean up unnecessary files and move any required data by the end of August 2026. See the Roihu data preparation instructions for details.

Puhti scratch is very full: keep only active data there and move or delete everything else. No new Puhti scratch quota will be granted.

Allas-tallennus Rahtissa

Lisätietoja Altaasta

Varmuuskopiointi Altaaseen

Rahtista voi tehdä varmuuskopioita Altaaseen eri tavoilla. Näytämme kaksi esimerkkiä: - Ensimmäisessä käytetään toista podia kopioimaan persistentin taltion sisältö Altaaseen. - Toinen on bash-skripti, joka suoritetaan omalta paikalliselta koneelta.

Tätä ensimmäistä esimerkkiä varten otamme käyttöön nginx-deploymentin, joka käyttää PersistentVolumeClaim-resurssia. Tarjoamme tiedostot testikäyttöä varten.

NGINX-deploymentin valmistelu

Ensin rakennamme ja otamme opasta varten käyttöön NGINX-palvelimen.

Rakennamme nginx-imagemme tällä Dockerfilellä: (koska tavallista nginx-imagea ei voi käyttää OpenShiftissä)

FROM nginx:stable

ENV LISTEN_PORT=8080

# support running as arbitrary user which belongs to the root group
RUN chmod g+rwx /var/cache/nginx /var/run /var/log/nginx

# users are not allowed to listen on privileged ports
RUN sed -i.bak "s/listen\(.*\)80;/listen ${LISTEN_PORT};/" /etc/nginx/conf.d/default.conf

# comment user directive as master process is run as user in OpenShift anyhow
RUN sed -i.bak 's/^user/#user/' /etc/nginx/nginx.conf

EXPOSE 8080

Jos rakennat imagen paikallisesti, muista puskea se projektiisi. Voit ottaa tämän nginx-palvelimen käyttöön tällä Deploymentilla:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: <our_custom_nginx_image>
        resources:
          limits:
            memory: "128Mi"
            cpu: "500m"
        ports:
          - containerPort: 8080
        volumeMounts:
        - name: myvol
          mountPath: /mnt
      volumes:
      - name: myvol
        persistentVolumeClaim:
          claimName: nginx-pvc

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  selector:
    app: nginx
  ports:
  - port: 8080

---
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: nginx-route
spec:
  host: ""
  path: /
  to:
    kind: Service
    name: nginx-svc
  tls:
    insecureEdgeTerminationPolicy: Redirect
    termination: edge

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nginx-pvc
spec:
  resources:
    requests:
      storage: 1Gi
  accessModes:
    - ReadWriteOnce
  storageClassName: standard-csi

Tallenna tiedosto ja ota se käyttöön tällä komennolla: oc apply -f {name_of_yaml_file} Deployment käyttää tässä esimerkissä PersistentVolumeClaim-resurssia.

Nyt kun nginx-podimme on käynnissä, haluamme kopioida PVC:n sisällön Altaaseen. Käytämme uutta deploymentia, jossa on rclone Docker image.

Ensimmäinen esimerkki: toisen podin käyttäminen

Luo rclone.conf, johon lisäät access_key_id- ja secret_access_key-arvosi.

Jos sinulla ei ole access_key_id- ja secret_access_key-arvoja, sinun täytyy ensin sourceta Pouta-projektisi ja käyttää sitten tätä komentoa tunnistetietojen luomiseen:

openstack ec2 credentials create

Kun tunnistetiedot on luotu, luo rclone.conf-tiedosto:

[default]
type = s3
provider = Other
env_auth = false
access_key_id = {ACCESS_KEY_ID}
secret_access_key = {SECRET_ACCESS_KEY}
endpoint = a3s.fi
acl = private

Korvaa {ACCESS_KEY_ID} ja {SECRET_ACCESS_KEY} omilla tunnistetiedoillasi.

Luo rclone.sh-skripti:

#!/bin/sh -e

rclone copy "/mnt/" "default:{BUCKET}"

echo "Done!"

Korvaa {BUCKET} kohdeämpärillä, johon haluat varmuuskopioida tiedostosi.

Sen jälkeen sinun täytyy luoda oma mukautettu rclone Docker image:

FROM rclone/rclone

COPY rclone.conf /.rclone.conf
COPY rclone.sh /usr/local/bin/
RUN chmod 755 /.rclone.conf
RUN chmod +x /usr/local/bin/rclone.sh
Jos luot imagen paikallisesti, muista puskea se projektiisi.

Kun tämä kaikki on tehty, voit ottaa rclone-podin käyttöön. Voit käyttää tätä esimerkkiä:

apiVersion: v1
kind: Pod
metadata:
  name: rclone
spec:
  containers:
  - name: copys3
    image: <your_rclone_image>
    command: ["/usr/local/bin/rclone.sh"]
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"
    volumeMounts:
    - name: vol-to-backup
      mountPath: /mnt/
  volumes:
  - name: vol-to-backup
    persistentVolumeClaim:
      claimName: nginx-pvc # Must match the PVC name that you want to backup

Tallenna tiedosto ja käytä tätä komentoa: oc apply -f {name_of_yaml_file}.

Warning

Jos PersistentVolumeClaim-resurssisi on ReadWriteOnce, sinun täytyy skaalata nginx-deployment alas, jotta rclonea ajava podi voi liittää taltion. Käytä tätä komentoa: oc scale --replicas=0 deploy/nginx Jos PersistentVolumeClaim-resurssisi on ReadWriteMany, deploymentia ei tarvitse skaalata alas. Voit tarkistaa tämän komennolla: oc get pvc. Näet joko RWO tai RWX.

Podi suoritetaan ja varmuuskopioi PVC:si sisällön Altaaseen. Muista skaalata alkuperäinen deployment takaisin ylös (oc scale --replicas=1 deploy/nginx) kopioinnin valmistuttua.

Tässä ratkaisussa on ETUJA ja HAITTOJA:
Edut:

  • Aja podi omassa Rahti-projektissasi

Haitat:

  • PVC on ReadWriteOnce, joten käyttökatko on välttämätön.

Toinen esimerkki: bash-skriptin käyttäminen

Jotta seuraava skripti toimisi, oletamme, että rclone-komentoriviohjelma on asennettu ja Allas-ämpärin nimi on luotu. rclone.conf tulee olla asetettuna paikallisessa järjestelmässä kuten yllä olevassa esimerkissä on kuvattu. Esimerkiksi rclone.conf-polku voi sijaita osoitteessa ~/.config/rclone/rclone.conf. Lisätietoja Allas-ämpärin luomisesta. Tämä skripti varmuuskopioi Rahtissa käyttöönotetun sovelluksen. Sovelluksella on esimerkiksi nimi /backup volumeMounts-määrityksen mountPath-arvona.

#!/bin/env bash

# Set your pod name, source directory, and destination directory
if [[ -z $1 ]];
then
    echo "No Podname parameter passed."
    exit 22
else
     echo "The POD_NAME = $1 is set."
fi

POD_NAME=$1
SOURCE_DIR="/backup"
TIMESTAMP=$(date '+%Y%m%d%H%M%S') # Generate a timestamp
DEST_DIR="/tmp/pvc_backup_$TIMESTAMP.tar.gz" # Include the timestamp in the filename
RCLONE_CONFIG_PATH="your/path/to/rclone.conf"
S3_BUCKET="pvc-test-allas" # Your bucket name

# Echo function to display task messages
echo_task() {
  echo "$(date '+%Y-%m-%d %H:%M:%S') - $1"
}

# Function to handle errors
handle_error() {
  echo_task "Error: $1"
  exit 1
}

# Check if the pod exists
oc get pod "$POD_NAME" &>/dev/null
if [ $? -ne 0 ]; then
  echo_task "Pod $POD_NAME not found. Aborting backup."
  exit 1
fi

# Create a tar archive within the pod
echo_task "Creating a tar archive within the pod..."
oc exec "$POD_NAME" -- /bin/sh -c "tar -czf /tmp/pvc_backup.tar.gz -C $SOURCE_DIR ."
if [ $? -ne 0 ]; then
  handle_error "Failed to create a tar archive in the pod. Aborting backup."
fi

# Copy the tar archive to the local machine
echo_task "Copying the tar archive to the local machine..."
oc cp "$POD_NAME:/tmp/pvc_backup.tar.gz" "$DEST_DIR"
if [ $? -ne 0 ]; then
  handle_error "Failed to copy the tar archive to the local machine. Aborting backup."
fi
echo_task "Backup completed successfully. The archive is stored in $DEST_DIR."

# Use Rclone to sync the tarball to S3
echo_task "Syncing the tarball to S3..."
rclone --config "$RCLONE_CONFIG_PATH" sync "$DEST_DIR" default:"$S3_BUCKET"
if [ $? -ne 0 ]; then
  handle_error "Failed to upload tarball to S3"
fi
echo_task "Backup completed successfully. The archive is stored in $S3_BUCKET$DEST_DIR"

exit 0

Jos sinun täytyy siivota tar-arkistotiedostot, voit lisätä seuraavan skriptin Allas-tallennuksen jälkeen.

# Clean up the tar archive in the pod
oc exec "$POD_NAME" -- /bin/sh -c "rm /tmp/pvc_backup.tar.gz"

# Clean up temporary files
rm -rf /tmp/pvc_backup*
or
rm "$DEST_DIR"
Skripti voidaan suorittaa seuraavasti olettaen, että skriptin nimi on push_to_allas.sh ja että se on suoritettava:

./push_to_allas.sh "mypod-vol"

Tässä ratkaisussa on ETUJA ja HAITTOJA:

Edut:

  • Yksinkertaisuus: Käsittelet taltiota käytännössä kuten mitä tahansa muuta hakemistoa. Datan kopioiminen hakemistosta Altaaseen on suoraviivaista.
  • Joustavuus: Voit valita tietyt tiedostot tai hakemistot liitoksesta kopioitavaksi Altaaseen, ja ratkaisu sopii hyvin pienikokoisille tiedostoille.

Haitat:

  • Suorituskyky: Tämä menetelmä voi olla hitaampi, erityisesti jos taltiolla on suuri määrä tiedostoja.

Tallennuksen suorituskyky

Allasta käytettäessä suorituskyvyn kannalta on otettava huomioon useita asioita:

  • Pieni io heikentää tallennuksen suorituskykyä. Samalla kokonaiskoolla yksi suuri tiedosto on nopeampi kuin joukko pieniä tiedostoja. Yksi ratkaisu voi olla kerätä kaikki pienet tiedostot yhteen arkistotiedostoon, kuten tar-tiedostoon.
  • Koska tallennuspooli on jaettu, viive voi vaihdella. Jaettu laitteisto tarkoittaa jaettua suorituskykyä eri käyttäjien kesken.
  • Yksisäikeinen io on hidasta, joten monisäikeistä io:ta kannattaa käyttää aina kun mahdollista.

Suomenkielinen tekoälykäännös

Sisällössä voi esiintyä virheellistä tietoa tekoälykäännöksestä johtuen.

Klikkaa tästä antaaksesi palautetta