Moodle on AKS slow with Azure File and no file when using Azure blob

[ojordano]

Hello everyone.

I have a moodle running on Azure Kubernetes Services using an external Postrges DB.

I am actually trying to switch default storage disk to an azure storage account.

I have tried with Azure File, things looks good but application is very slow. Pages takes too much time to appear than normal time. Tried to use premium file share to improve performance but it is same.

I now want to use a blob or block container following this ( https://learn.microsoft.com/en-us/azure/aks/azure-csi-blob-storage-provision?tabs=mount-nfs%2Csecret#statically-provision-a-volume )

Tried to deploy an empty new moodle but seems moodle do not know how to write in container of a storage account.

Have anybody tried to do this please.?
any hint and help will be appreciable

[naioja]

@ojordano can you describe more the situation, are you using PV/PVC for your deployment, can you post maybe the deployment yaml here. Also what container are you using ? The one from the Moodle helm chart or the one from Moodle HQ ?

[ojordano]

Hello @naioja ;
@naioja
Thank you for helping on this .

So i am deploying the moodle from a Helm chart version 14.1.9 ( https://artifacthub.io/packages/helm/bitnami/moodle/14.1.9 ).

• AZURE FILE SCENARIO

1- my values looks like something like this :

moodleSkipInstall: true
moodlePassword: *************
allowEmptyPassword: false
mariadb
  enabled: false
extraEnvVars:
- name: PHP_MAX_INPUT_VARS
  value: "5000"
- name: PHP_POST_MAX_SIZE
  value: 500m
- name: PHP_UPLOAD_MAX_FILESIZE
  value: 500m
persistence
  existingClaim : azure-file-moodle-pvc
livenessProbe
  enabled: false
readinessProbe
  enabled: false
ingress
  enabled: true
  hostname: *************
  ingressClassName: nginx
  tls: true
  annotations:
    acme.cert-manager.io/http01-edit-in-place: "true"
    cert-manager.io/cluster-issuer: *************
    nginx.org/client-max-body-size: 500m  
containerSecurityContext
  enabled: false
externalDatabase
  type: pgsql
  host: ******
  port: 5432
  user: bn_moodle
  password: ********
  database: bitnami_moodle

2- The PVC given in the helm values reference a PV that reference a secrect and that secret reference a storage account containing the share used for moodle . so it all look like this :
SECRET

kubectl create secret generic azure-file-moodle -n moodle --from-literal=azurestorageaccountname=************ --from-literal=azurestorageaccountkey=***********

PV & PVC

apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: file.csi.azure.com
  name: azure-file-moodle-pv
spec:
  capacity:
    storage: 40Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: azurefile-csi
  csi:
    driver: file.csi.azure.com
    readOnly: false
    volumeHandle: 9e6091d1-7121-413a-bc6a-134df98b375a
    volumeAttributes:
      shareName: moodle-persistence
    nodeStageSecretRef:
      name: azure-file-moodle
      namespace: moodle
  mountOptions:
    - dir_mode=0777
    - file_mode=0777
    - uid=0
    - gid=0
    - mfsymlinks
    - cache=strict
    - nosharesock
    - nobrl
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-file-moodle-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 40Gi
  volumeName: azure-file-moodle-pv
  storageClassName: azurefile-csi

So those are my configuration.
At Azure side i have a storage account and a share named moodle-persistence

Site is UP, persistence are well bound; but page are very very very slow. When i try to use default disk it is good.
I tried using premium file share to see if high performance can help but nothing.

• AZURE BLOB SCENARIO

I did the same scenario but this time the used storage class is azureblob-fuse-premium and provisionner is blob.csi.azure.com but i have error stating that moodle was unable to attach to that volume.

[ojordano]

Hello
@naioja still looking foward for a help on this please :) :)

[naioja]

Looking at your deployment the only things I suspect could cause the problem are the user and group you have declared as mountOptions:

- uid=0
- gid=0

Please make sure you current process under which you run apache/nginx is able to conform to that uid/gid.