Hyppää sisältöön

Welcome to our weekly research support coffee hour on Zoom! Click here for more information.

Warning!

Puhti scratch disk is becoming very full (80+ % ) resulting in performance degradation. Everybody is advised to only keep actively processed data on scratch, all other data should be deleted, transferred to host institute or stored in Lumi-O. No new quota will be granted. Click here for a tool for examining your disk usage.

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. - Toisessa käytetään 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 testaustarkoituksiin.

NGINX-deploymentin valmistelu

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

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, älä unohda ladata sitä projektisi rekisteriin. 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 tähän 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 source-komennolla ottaa Pouta-projektisi käyttöön ja sitten luoda tunnistetiedot tällä komennolla:

openstack ec2 credentials create

Kun tunnistetiedot on luotu, tee 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, älä unohda ladata sitä projektisi rekisteriin.

Kun tämä kaikki on tehty, voit ottaa käyttöön rclone-podisi. 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 asian tällä komennolla: oc get pvc. Näet joko RWO tai RWX.

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

Tässä ratkaisussa on HYVIÄ ja HUONOJA puolia:
Hyvät puolet:

  • Suoritat podin omassa Rahti-projektissasi

Huonot puolet:

  • 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äsi yllä olevan esimerkin mukaisesti. Esimerkiksi rclone.conf-polku voi sijaita paikassa ~/.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 sen jälkeen, kun tiedostot on ladattu Altaaseen.

# 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 HYVIÄ ja HUONOJA puolia:

Hyvät puolet:

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

Huonot puolet:

  • Suorituskyky: tämä menetelmä voi olla hitaampi, erityisesti jos taltiossa 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. Ratkaisuna voi olla kaikkien pienten tiedostojen kokoaminen yhdeksi arkistotiedostoksi, kuten tar-tiedostoksi.
  • Koska tallennuspooli on jaettu, viive voi vaihdella. Jaettu laitteisto tarkoittaa käyttäjien kesken jaettua suorituskykyä.
  • 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