Volumul GlusterFS se blochează/se blochează după acces rapid la fișierele de sesiune PHP din containerul PHP Docker

2021-10-05 ÎNTREBARE ȘI TEXT ACTUALIZAT DUPĂ O MAI MULTE ANALIZĂ, REDUS LA CAZUL MINIMALE

Scurta descriere

Un cluster Nomad/Consul rulează, cu Traefik (cu configurație minimă) ca sarcină de sistem pe fiecare client Nomad. Există 3 servere nomazi, 3 servere consul, 3 clienți nomazi și 3 servere Gluster în acest moment. Configurație foarte asemănătoare cu aceasta articol stabilit despre crearea unui cluster Nomad/Consul

Imaginile și site-urile de bază funcționează bine.

Problema

Am început să port primul site mai mare bazat pe PHP (cu un număr mai mare de încărcări de dependență a paginii pe site) în acest cluster și mă confrunt cu o problemă ciudată pe care am semnalat-o, dar nu o pot rezolva corect.

Sarcinile se încarcă bine și se înregistrează ca în Consul, Traefik și Nomad. Paginile mici (cu puține dependențe) funcționează bine.

Ori de câte ori o pagină are prea multe încărcări de dependență, Apache blochează acele conexiuni specifice.

Când deschid o nouă fereastră de browser Incognito și merg la adresa URL, se încarcă pagina principală și aproximativ 10-15 dintre dependențe. Ceilalți rămân într-o stare de așteptare în browser. Starea browserului continuă să se „învârtă” (ca la încărcare). Închiderea ferestrei și deschiderea uneia noi îmi permite să repet procesul.

Am rezolvat problema la faptul că directorul de sesiuni PHP este mapat (prin Docker) la un director pe o montură GlusterFS.

Mutarea maparii volumului într-un director diferit care este gazdă bazat pe același server elimină problema și site-ul se încarcă așa cum ar trebui.

Concluzie: Interacțiunea dintre volumele Docker și montura Gluster provoacă probleme la „sarcină grea”. Cu doar câteva solicitări totul funcționează bine. Cu o mulțime de solicitări de acces la fișierul de sesiune PHP, lucrurile se blochează și nu se recuperează.

Întrebare: Acest lucru este probabil cauzat fie de o problemă de configurare Gluster, fie de modul în care este configurată montura /etc/fstab. Vă rugăm să ajutați la rezolvarea acestei probleme!

IZOLARE

Directorul de sesiuni PHP este setat la /var/php_session în imaginile PHP config și mapate în Nomad / Docker la /data/storage/test/php_sessions.

The /data/storage/test/php_sessions directorul este deținut de utilizatorul 20000 pentru a vă asigura că toate nodurile au acces la aceleași sesiuni PHP:

client:/data/storage/test$ ls -ln .
drwxr-xr-x 2 20000 20000 6 oct 5 14:53 php_sessions
drwxr-xr-x 2 20000 20000 6 oct 5 14:53 încărcare

Când se schimbă maparea volumului nomad (în /etc/nomad/nomad.hcl) din:

client {

  host_volume „sesiuni-test” {
    cale = "/data/storage/test/php_sessions"
    read_only = false
  }

}

la

client {

  host_volume „sesiuni-test” {
    cale = "/tmp/php_sessions"
    read_only = false
  }

}

(Și asigurându-mă /tmp/php_sessions este, de asemenea, deținut de utilizatorul 20000)

Totul funcționează din nou.

Date detaliate (Mai multe la cerere)

Conținutul /etc/fstab:

LABEL=cloudimg-rootfs / ext4 implicite 0 1
LABEL=UEFI /boot/efi vfat defaults 0 1
gluster-01,gluster-02,gluster-03:/storage /data/storage glusterfs _netdev,defaults,direct-io-mode=disable,rw

Dockerfile pentru imaginea site-ului:

DIN php:7.4.1-apache
ENV APACHE_DOCUMENT_ROOT /var/www/htdocs
WORKDIR /var/www

RUN docker-php-ext-install mysqli pdo_mysql

# Faceți rădăcina Apache configurabilă
RUN sed -ri -e 's!/var/www/html!${APACHE_DOCUMENT_ROOT}!g' /etc/apache2/sites-available/*.conf
RUN sed -ri -e 's!/var/www/!${APACHE_DOCUMENT_ROOT}!g' /etc/apache2/apache2.conf /etc/apache2/conf-available/*.conf

# Ascultați pe portul 1080 în mod implicit pentru utilizatori non-root
RUN sed -ri 's/Listen 80/Listen 1080/g' /etc/apache2/ports.conf
RUN sed -ri 's/:80/:1080/g' /etc/apache2/sites-enabled/*

# Utilizați propria configurație
COPY data/000-default.conf /etc/apache2/sites-enabled/

# Activați producția ini
RUN cp /usr/local/etc/php/php.ini-production /usr/local/etc/php/php.ini

RUN a2enmod rescrie și& a2enmod remoteip

COPY --from=composer:latest /usr/bin/composer /usr/local/bin/composer
COPY --chown=www-data:www-data . /var/www

RUN /usr/local/bin/composer --no-cache --no-ansi --no-interaction install

# În sfârșit, adăugați modificări de securitate
COPIEAZĂ data/changes.ini /usr/local/etc/php/conf.d/

Fișierul nomad este redus la ceea ce declanșează problema: cu următorul plan de muncă Nomad:

job „test” {
  centre de date = ["dc1"]

  grup „test-staging” {
    număr = 1

    retea {
      portul „php_http” {
        până la = 1080
      }
    }

    volum „sesiuni-test” {
      tip = "gazdă"
      read_only = false
      sursa = "sesiuni de testare"
    }

    volum „încărcare de test” {
      tip = "gazdă"
      read_only = false
      sursă = „încărcare-test”
    }

    serviciu {
      nume = "test-staging"
      port = "php_http"

      etichete = [
        "traefik.enable=true",
        "traefik.http.routers.test.php_staging.rule=Host(`staging.xxxxxx.com`)",
      ]

      Verifica {
        tip = "tcp"
        port = "php_http"
        interval = "5s"
        timeout = "2s"
      }
    }

    sarcină „test” {
      driver = "docker"
      utilizator = "20000"

      config {
        imagine = "docker-repo:5000/test/test:latest"
        porturi = ["php_http"]
      }

      volum_mount {
        volum = "sesiuni de testare"
        destinație = "/var/php_sessions"
        read_only = false
      }

      volum_mount {
        volum = "încărcare-test"
        destinație = "/var/upload"
        read_only = false
      }

      șablon {
        date = <<EOF
1.2.3.4
EOF

        destinație = „local/trusted-proxies.lst”
      }
    }
  }
}