Cum se configurează stocarea de obiecte S3 pentru ownCloud Infinite Scale

ownCloud Infinite Scale poate utiliza stocarea de obiecte compatibilă cu S3 pentru fișiere blob, păstrând în același timp metadatele fișierelor pe un sistem de fișiere compatibil POSIX. Această divizare este primul concept de înțeles: S3 nu este un înlocuitor drop-in pentru fiecare director de date local. În s3ngstructura acceptată, stocarea de obiecte păstrează conținutul fișierului binar, în timp ce metadatele rămân pe stocarea POSIX, cum ar fi un sistem de fișiere local sau NFS.

Acest ghid respectă documentația actuală despre stocarea ownCloud Infinite Scale, disponibilă în octombrie 2026. Este scris pentru administratorii care nu au familiarizat cu s3ngdriverul și doresc o configurație pe care o pot înțelege înainte de a o adapta la Docker Compose, systemd, Kubernetes sau o altă metodă de implementare.

Referințele oficiale utilizate în acest ghid sunt documentația de stocare ownCloud S3 , configurația serviciului Storage-Users și considerațiile generale privind stocarea .

Ce înseamnă S3 în ownCloud Infinite Scale

S3 este o API de stocare a obiectelor introdusă inițial de Amazon. Un serviciu compatibil cu S3 stochează datele ca obiecte într-un bucket și expune operațiunile prin API-uri bazate pe HTTP. ownCloud Infinite Scale utilizează s3ngdriverul de stocare pentru a plasa fișiere blob într-un astfel de bucket.

Stocarea POSIX înseamnă un sistem de fișiere care oferă comportamentul sistemului de fișiere așteptat de Infinite Scale pentru metadate. Cu s3ng, metadatele nu se mută în bucket-ul S3. ownCloud documentează explicit faptul că blob-urile merg în S3 în timp ce metadatele rămân în stocarea POSIX.

Această distincție previne o greșeală frecventă: îndreptarea Infinite Scale către un bucket și presupunerea că întreaga stare a serverului se află acum acolo. Nu este cazul. Planul dvs. de backup și recuperare trebuie să acopere atât metadatele POSIX, cât și blob-urile S3.

Pasul 1: Pregătiți bucket-ul, spațiul de stocare a metadatelor, acreditările și calea de rețea

Înainte de a schimba Scala Infinită, pregătiți patru lucruri:

• Un bucket S3 dedicat.
• O cale compatibilă POSIX pentru s3ngmetadate. Pentru o implementare cu mai multe noduri, ownCloud recomandă o atenție sporită în ceea ce privește stocarea partajată; NFS este utilizat în mod obișnuit atunci când mai multe instanțe Infinite Scale au nevoie de acces la calea de metadate.
• O cheie de acces și o cheie secretă doar cu permisiunile pentru bucket necesare pentru Infinite Scale.
• Accesibilitatea rețelei de la gazda sau containerul Infinite Scale până la endpoint-ul S3, de obicei prin HTTPS.

Nu faceți publică containerul. Infinite Scale se autentifică la container cu acreditări; accesul public nu este nici obligatoriu, nici de dorit. De asemenea, evitați reutilizarea unor acreditări de administrator generale atunci când se poate crea o identitate de serviciu dedicată.

Dacă utilizați Amazon S3, endpoint-ul și regiunea respectă convențiile AWS. Dacă utilizați un alt furnizor compatibil cu S3, confirmați formatul endpoint-ului, comportamentul regiunii, cerințele TLS și sintaxa politicii în documentația furnizorului respectiv. ownCloud avertizează în mod specific că un comportament precum detaliile de criptare poate diferi între furnizori.

Pasul 2: Activați driverul s3ng și furnizați setările de conexiune S3

Setarea principală pentru stocarea este STORAGE_USERS_DRIVER=s3ng. Serviciul Storage-Users este componenta Infinite Scale responsabilă pentru stocarea fișierelor utilizatorului. Configurația oficială menține, de asemenea, driverul de stocare a sistemului pe ocisbackend-ul normal.

Un set minimal de variabile de mediu arată astfel:

STORAGE_USERS_DRIVER=s3ng
STORAGE_USERS_S3NG_ROOT=/var/lib/ocis/storage/users
STORAGE_SYSTEM_DRIVER=ocis

STORAGE_USERS_S3NG_ENDPOINT=https://s3.example.com
STORAGE_USERS_S3NG_REGION=us-east-1
STORAGE_USERS_S3NG_ACCESS_KEY=YOUR_ACCESS_KEY
STORAGE_USERS_S3NG_SECRET_KEY=YOUR_SECRET_KEY
STORAGE_USERS_S3NG_BUCKET=ocis-files

Valorile exemplificate sunt substituenți. Folosește endpoint-ul, regiunea, bucket-ul și acreditările emise de furnizorul tău. Nu comite cheia secretă într-un depozit Git public. În orchestrarea containerelor, este de preferat mecanismul de gestionare a secretelor al platformei, decât încorporarea acreditărilor direct într-un fișier sau manifest Compose.

Metoda de implementare determină unde se plasează aceste variabile. O implementare Docker Compose le poate plasa în secțiunea serviciului Infinite Scale environmentsau le poate încărca dintr-un fișier de mediu. O implementare systemd poate utiliza un fișier de mediu sau o configurație de unitate. Kubernetes le injectează de obicei printr-un Secret și Deployment sau StatefulSet. Numele variabilelor sunt partea importantă; sintaxa aferentă depinde de platforma dvs.

Pasul 3: Acordați permisiunile de care are nevoie Infinite Scale pentru bucket

O politică de tip bucket este o regulă de gestionare a identității și accesului (IAM) care controlează acțiunile pe care o identitate autentificată le poate efectua împotriva unui bucket și a obiectelor sale. ownCloud publică un model de politică necesar pentru s3ngdriver.

Înlocuiți bucket-nameîn politica următoare cu numele real al bucket-ului:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListBucket",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::bucket-name"]
    },
    {
      "Sid": "ActionsInBucketContext",
      "Effect": "Allow",
      "Action": [
        "s3:*Object",
        "s3:*MultipartUpload",
        "s3:ListMultipartUploadParts"
      ],
      "Resource": ["arn:aws:s3:::bucket-name/*"]
    }
  ]
}

Nu rezolvați o eroare de acces refuzat prin acordarea permisiunilor s3:*pentru fiecare bucket din cont. Începeți cu permisiunile documentate la nivel de bucket, apoi adaptați-le doar atunci când furnizorul S3 necesită un echivalent specific furnizorului.

Pasul 4: Reporniți Infinite Scale și verificați calea de stocare

Aplicați configurația utilizând procedura normală de repornire pentru implementarea dvs. De exemplu, o instalare systemd poate utiliza systemctl restart ocis, în timp ce o implementare Compose ar recrea sau reporni containerele de servicii afectate. Verificați jurnalele imediat după pornire pentru erori de autentificare, DNS, TLS, regiune sau permisiune.

O listare a bucket-urilor cu interfața CLI a furnizorului S3 dovedește că gazda și acreditările pot ajunge la bucket, dar nu dovedește în sine că Infinite Scale scrie corect fișiere blob. Cel mai bun test end-to-end este să porniți Infinite Scale, să încărcați un fișier mic prin interfața web ownCloud, să îl descărcați din nou și să revizuiți jurnalele de servicii pentru erori.

Dacă versiunea Infinite Scale instalată include comanda de întreținere blobstore documentată de ownCloud, puteți utiliza și comanda ocis storage-users blobstore check. ownCloud descrie această comandă ca o comandă dus-întors de încărcare/descărcare/ștergere către blobstore-ul configurat. Consultați documentația oficială de verificare a blobstore-ului pentru sintaxa specifică versiunii.

Nu vă așteptați ca numele fișierelor originale să apară ca obiecte S3 normale.

Una dintre cele mai ușoare concepții greșite este să răsfoiți bucket-ul și să vă așteptați la un arbore de foldere familiar al utilizatorului, cum ar fi Documents/report.pdf. Infinite Scale tratează S3 ca un depozit de blob-uri, nu ca un sistem de fișiere orientat spre utilizator. s3ngFormatul cheii documentat se bazează pe ID-uri de spațiu și ID-uri de blob-uri, în timp ce spațiul de nume lizibil de către om este reconstruit din metadate.

Asta înseamnă că nu ar trebui să redenumiți, să reorganizați sau să ștergeți manual obiectele din interiorul bucket-ului doar pentru că cheile lor par nefamiliare. Gestionați fișierele utilizatorului prin ownCloud. Manipularea directă a bucket-ului poate rupe relația dintre metadate și blob-uri.

Încărcări mari: verificați dimensiunea piesei multiparte înainte de producție

S3 folosește încărcarea multipart pentru a împărți obiecte mari în părți. Documente ownCloud STORAGE_USERS_S3NG_PUT_OBJECT_PART_SIZEpentru controlul dimensiunii părților. Implicit documentat este de 16 MiB atunci când nu este furnizată nicio valoare explicită.

Amazon S3 permite cel mult 10.000 de părți într-o singură încărcare multiparte. Cu o dimensiune a părții de 16 MiB, aceasta corespunde la aproximativ 160 GiB înainte ca limita numărului de părți să devină o problemă. Dacă utilizatorii dvs. încarcă în mod regulat fișiere mai mari, calculați dimensiunea necesară a părții înainte de lansare, în loc să așteptați eșecul unui transfer mare.

Compromisul este simplu: componentele mai mari acceptă fișiere cu un număr maxim de solicitări, dar modifică și caracteristicile memoriei, buffering-ului, reîncercărilor și transferului. ownCloud menționează, de asemenea, că datele fișierelor primite necesită stocare temporară în timp ce sunt bufferizate, așadar planificarea capacității trebuie să includă mai mult decât simpla memorie internă.

Probleme frecvente și ce trebuie verificat mai întâi

Faceți backup împreună pentru blob-urile S3 și metadatele POSIX

Cu s3ng, bucket-ul reprezintă doar jumătate din starea de stocare. Documentația de backup a ownCloud precizează că o configurație S3 distribuită trebuie să includă configurația, datele de sistem, metadatele și blob-urile. Documentația de restaurare impune, de asemenea, ca aceste seturi de date să fie restaurate în mod consecvent.

Pentru un serviciu de producție, documentați montarea metadatelor, bucket-ul, acreditările sau rolul, fișierele de configurare și procedura de backup în același runbook. Testați recuperarea înainte de a vă baza pe design. Referințele oficiale relevante sunt ghidul de backup ownCloud și considerațiile privind restaurarea .

Punct de plecare recomandat

Pentru o primă implementare, păstrați designul simplu: utilizați un bucket S3 dedicat pentru blob-uri, o cale persistentă de metadate POSIX, o identitate de serviciu dedicată cu permisiunile documentate pentru bucket, HTTPS către endpoint-ul de stocare a obiectelor și setările implicite multipart, cu excepția cazului în care dimensiunile așteptate ale fișierelor necesită o modificare.

După configurare, validați separat trei niveluri: accesul la rețea și la credențiale la bucket, pornirea Infinite Scale fără erori de stocare și o încărcare/descărcare efectivă prin ownCloud. După ce aceste verificări sunt satisfăcute, treceți la monitorizare, copii de rezervă, reguli de ciclu de viață și optimizarea performanței. Această secvență facilitează mult depanarea, deoarece fiecare test răspunde la o întrebare diferită, în loc să trateze „S3 funcționează” ca un singur rezultat de tipul „totul sau nimic”.