วิธีตั้งค่าพื้นที่จัดเก็บข้อมูลแบบอ็อบเจ็กต์ S3 สำหรับ ownCloud Infinite Scale

ownCloud Infinite Scale สามารถใช้พื้นที่จัดเก็บข้อมูลแบบอ็อบเจ็กต์ที่เข้ากันได้กับ S3 สำหรับไฟล์ไบนารี ในขณะที่เก็บข้อมูลเมตาของไฟล์ไว้ในระบบไฟล์ที่สอดคล้องกับมาตรฐาน POSIX แนวคิดแรกที่ต้องทำความเข้าใจคือ S3 ไม่ใช่สิ่งที่จะมาแทนที่ไดเร็กทอรีข้อมูลในเครื่องทุกแห่งได้โดยตรง ในs3ngรูปแบบที่รองรับ พื้นที่จัดเก็บข้อมูลแบบอ็อบเจ็กต์จะเก็บเนื้อหาไบนารีของไฟล์ ในขณะที่ข้อมูลเมตาจะยังคงอยู่บนพื้นที่จัดเก็บข้อมูล POSIX เช่น ระบบไฟล์ในเครื่องหรือ NFS

คู่มือนี้อ้างอิงจากเอกสารประกอบการใช้งาน ownCloud Infinite Scale ฉบับปัจจุบัน ซึ่งจะเผยแพร่ในเดือนตุลาคม 2026 เขียนขึ้นสำหรับผู้ดูแลระบบที่เพิ่งเริ่มต้นใช้s3ngงานไดรเวอร์และต้องการการตั้งค่าที่เข้าใจง่ายก่อนที่จะนำไปปรับใช้กับ Docker Compose, systemd, Kubernetes หรือวิธีการปรับใช้แบบอื่น

เอกสารอ้างอิงอย่างเป็นทางการที่ใช้ในคู่มือนี้ ได้แก่เอกสารเกี่ยวกับการจัดเก็บข้อมูล ownCloud S3 , การกำหนดค่าบริการ Storage-Usersและข้อควรพิจารณาทั่วไปเกี่ยวกับการจัดเก็บข้อมูล

S3 ใน ownCloud Infinite Scale หมายถึงอะไร

S3คือ API สำหรับจัดเก็บข้อมูลแบบอ็อบเจ็กต์ ซึ่งเปิดตัวครั้งแรกโดย Amazon บริการที่เข้ากันได้กับ S3 จะจัดเก็บข้อมูลในรูปแบบอ็อบเจ็กต์ภายในบัคเก็ต และเปิดเผยการดำเนินการต่างๆ ผ่าน API ที่ใช้ HTTP ownCloud Infinite Scale ใช้s3ngไดรเวอร์จัดเก็บข้อมูลนี้เพื่อวางไฟล์ข้อมูลขนาดใหญ่ (blob) ลงในบัคเก็ตดังกล่าว

พื้นที่จัดเก็บข้อมูลแบบ POSIXหมายถึงระบบไฟล์ที่ให้พฤติกรรมของระบบไฟล์ตามที่ Infinite Scale คาดหวังสำหรับเมตาเดตา ด้วยระบบนี้s3ngเมตาเดตาจะไม่ถูกย้ายไปยัง S3 bucket ownCloud ระบุไว้อย่างชัดเจนว่าบล็อบจะถูกย้ายไปยัง S3 ในขณะที่เมตาเดตาจะยังคงอยู่ในพื้นที่จัดเก็บข้อมูลแบบ POSIX

ความแตกต่างนี้ช่วยป้องกันความผิดพลาดที่พบบ่อย: การชี้ Infinite Scale ไปที่บัคเก็ตแล้วคิดว่าสถานะเซิร์ฟเวอร์ทั้งหมดอยู่ที่นั่น ซึ่งไม่ใช่เช่นนั้น แผนการสำรองข้อมูลและการกู้คืนของคุณต้องครอบคลุมทั้งเมตาเดต้าฝั่ง POSIX และบล็อบฝั่ง S3 ด้วย

ขั้นตอนที่ 1: เตรียมบัคเก็ต พื้นที่จัดเก็บข้อมูลเมตา ข้อมูลรับรอง และเส้นทางเครือข่าย

ก่อนที่จะเปลี่ยน Infinite Scale โปรดเตรียมสิ่งต่อไปนี้ 4 อย่าง:

• พื้นที่จัดเก็บข้อมูล S3 เฉพาะ
• เส้นทางสำหรับs3ngเมตาเดตาที่สอดคล้องกับมาตรฐาน POSIX สำหรับการใช้งานแบบหลายโหนด ownCloud แนะนำให้พิจารณาอย่างรอบคอบเกี่ยวกับการจัดเก็บข้อมูลร่วมกัน โดยทั่วไปจะใช้ NFS เมื่ออินสแตนซ์ Infinite Scale หลายตัวจำเป็นต้องเข้าถึงเส้นทางเมตาเดตา
• คีย์การเข้าถึงและคีย์ลับที่มีเฉพาะสิทธิ์การเข้าถึงบัคเก็ตที่ Infinite Scale ต้องการเท่านั้น
• การเข้าถึงเครือข่ายจากโฮสต์หรือคอนเทนเนอร์ของ Infinite Scale ไปยังปลายทาง S3 โดยปกติผ่านทาง HTTPS

อย่าเปิดเผยบัคเก็ตให้เป็นสาธารณะ Infinite Scale ใช้ข้อมูลประจำตัวในการตรวจสอบสิทธิ์การเข้าถึงบัคเก็ต การเข้าถึงแบบสาธารณะไม่จำเป็นและไม่พึงประสงค์ นอกจากนี้ ควรหลีกเลี่ยงการใช้ข้อมูลประจำตัวผู้ดูแลระบบแบบทั่วไปซ้ำ เมื่อสามารถสร้างข้อมูลประจำตัวบริการเฉพาะได้

หากคุณใช้ Amazon S3 ปลายทางและภูมิภาคจะเป็นไปตามข้อกำหนดของ AWS หากคุณใช้ผู้ให้บริการอื่นที่เข้ากันได้กับ S3 โปรดตรวจสอบรูปแบบปลายทาง พฤติกรรมของภูมิภาค ข้อกำหนด TLS และไวยากรณ์นโยบายในเอกสารของผู้ให้บริการนั้น ownCloud เตือนไว้อย่างชัดเจนว่าพฤติกรรมต่างๆ เช่น รายละเอียดการเข้ารหัส อาจแตกต่างกันไปในแต่ละผู้ให้บริการ

ขั้นตอนที่ 2: เปิดใช้งานไดรเวอร์ s3ng และป้อนการตั้งค่าการเชื่อมต่อ S3

การตั้งค่าพื้นที่จัดเก็บข้อมูลหลักคือSTORAGE_USERS_DRIVER=s3ng. บริการ Storage-Usersเป็นส่วนประกอบของ Infinite Scale ที่รับผิดชอบในการจัดเก็บไฟล์ของผู้ใช้ การกำหนดค่าอย่างเป็นทางการยังคงใช้ไดรเวอร์จัดเก็บข้อมูลของระบบบนocisแบ็กเอนด์ ปกติ

ชุดตัวแปรสภาพแวดล้อมขั้นต่ำจะมีลักษณะดังนี้:

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

ค่าตัวอย่างเป็นเพียงค่าตัวอย่างเท่านั้น โปรดใช้เอนด์พอยต์ ภูมิภาค บัคเก็ต และข้อมูลรับรองที่ผู้ให้บริการของคุณออกให้ อย่าบันทึกรหัสลับลงในที่เก็บ Git สาธารณะ ในการจัดการคอนเทนเนอร์ ควรใช้กลไกการจัดการรหัสลับของแพลตฟอร์มมากกว่าการฝังข้อมูลรับรองโดยตรงในไฟล์ Compose หรือ manifest

วิธีการใช้งานของคุณจะเป็นตัวกำหนดว่าตัวแปรเหล่านี้จะอยู่ที่ใด การใช้งาน Docker Compose อาจวางตัวแปรเหล่านี้ไว้ในenvironmentส่วนของบริการ Infinite Scale หรือโหลดมาจากไฟล์สภาพแวดล้อม การใช้งาน systemd สามารถใช้ไฟล์สภาพแวดล้อมหรือการกำหนดค่าหน่วยได้ ส่วน Kubernetes มักจะแทรกตัวแปรเหล่านี้ผ่าน Secret และ Deployment หรือ StatefulSet ชื่อตัวแปรเป็นส่วนสำคัญ ส่วนไวยากรณ์โดยรอบขึ้นอยู่กับแพลตฟอร์มของคุณ

ขั้นตอนที่ 3: มอบสิทธิ์การเข้าถึงบัคเก็ตที่ Infinite Scale ต้องการ

นโยบายบัคเก็ต (Bucket Policy ) คือกฎการจัดการข้อมูลประจำตัวและการเข้าถึง (Identity and Access Management หรือ IAM) ที่ควบคุมการกระทำที่ข้อมูลประจำตัวที่ได้รับการตรวจสอบสิทธิ์สามารถดำเนินการกับบัคเก็ตและวัตถุภายในบัคเก็ตได้ ownCloud จะเผยแพร่รูปแบบนโยบายที่จำเป็นสำหรับs3ngไดรเวอร์

โปรดแทนที่bucket-nameในนโยบายต่อไปนี้ด้วยชื่อบัคเก็ตจริงของคุณ:

{
  "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/*"]
    }
  ]
}

อย่าแก้ปัญหาข้อผิดพลาด "ปฏิเสธการเข้าถึง" ด้วยการให้สิทธิ์การs3:*เข้าถึงทุกบัคเก็ตในบัญชี เริ่มต้นด้วยสิทธิ์การเข้าถึงที่กำหนดไว้สำหรับแต่ละบัคเก็ตตามเอกสารกำกับไว้ จากนั้นค่อยปรับเปลี่ยนเมื่อผู้ให้บริการ S3 ของคุณต้องการสิทธิ์การเข้าถึงที่เฉพาะเจาะจงสำหรับผู้ให้บริการนั้นๆ

ขั้นตอนที่ 4: รีสตาร์ท Infinite Scale และตรวจสอบเส้นทางการจัดเก็บข้อมูล

ใช้การกำหนดค่าโดยใช้ขั้นตอนการรีสตาร์ทตามปกติสำหรับการปรับใช้ของคุณ ตัวอย่างเช่น การติดตั้ง systemd อาจใช้คำสั่ง `start_container_restart` systemctl restart ocisในขณะที่การปรับใช้ Compose จะสร้างใหม่หรือรีสตาร์ทคอนเทนเนอร์บริการที่ได้รับผลกระทบ ตรวจสอบบันทึกทันทีหลังจากเริ่มต้นระบบเพื่อหาข้อผิดพลาดเกี่ยวกับการตรวจสอบสิทธิ์ DNS TLS ภูมิภาค หรือสิทธิ์การเข้าถึง

การแสดงรายการบัคเก็ตด้วย CLI ของผู้ให้บริการ S3 ของคุณพิสูจน์ได้ว่าโฮสต์และข้อมูลรับรองสามารถเข้าถึงบัคเก็ตได้ แต่ไม่ได้พิสูจน์ว่า Infinite Scale กำลังเขียนบล็อบอย่างถูกต้อง วิธีการทดสอบแบบครบวงจรที่ดีกว่าคือการเริ่มต้น Infinite Scale อัปโหลดไฟล์ขนาดเล็กผ่านอินเทอร์เฟซเว็บของ ownCloud ดาวน์โหลดไฟล์นั้นอีกครั้ง และตรวจสอบบันทึกการบริการเพื่อหาข้อผิดพลาด

หากเวอร์ชัน Infinite Scale ที่คุณติดตั้งไว้มีคำสั่งบำรุงรักษา blobstore ตามที่ ownCloud ได้ระบุไว้ คุณสามารถใช้คำสั่งนี้ได้เช่นกันocis storage-users blobstore checkownCloud อธิบายคำสั่งนี้ว่าเป็นกระบวนการอัปโหลด/ดาวน์โหลด/ลบข้อมูลแบบไป-กลับกับ blobstore ที่กำหนดค่าไว้ ตรวจสอบเอกสารยืนยัน blobstore อย่างเป็นทางการสำหรับไวยากรณ์เฉพาะเวอร์ชัน

อย่าคาดหวังว่าชื่อไฟล์ต้นฉบับจะปรากฏเป็นอ็อบเจ็กต์ S3 ทั่วไป

หนึ่งในความเข้าใจผิดที่เกิดขึ้นได้ง่ายที่สุดคือ การเรียกดูบัคเก็ตแล้วคาดหวังโครงสร้างโฟลเดอร์ที่คุ้นเคยเหมือนที่ผู้ใช้คุ้นเคย เช่นDocuments/report.pdfInfinite Scale มอง S3 เป็นที่เก็บข้อมูลบล็อบ ไม่ใช่ระบบไฟล์ที่ผู้ใช้มองเห็นได้s3ngรูปแบบคีย์ที่ระบุไว้ในเอกสารนั้นอิงตาม ID ของพื้นที่และ ID ของบล็อบ ในขณะที่เนมสเปซที่มนุษย์อ่านได้นั้นถูกสร้างขึ้นใหม่จากเมตาเดต้า

นั่นหมายความว่าคุณไม่ควรเปลี่ยนชื่อ จัดระเบียบ หรือลบวัตถุภายในบัคเก็ตด้วยตนเองเพียงเพราะคีย์ของวัตถุเหล่านั้นดูไม่คุ้นเคย ควรจัดการไฟล์ของผู้ใช้ผ่าน ownCloud การจัดการบัคเก็ตโดยตรงอาจทำให้ความสัมพันธ์ระหว่างเมตาเดต้าและบล็อบเสียหายได้

การอัปโหลดขนาดใหญ่: ตรวจสอบขนาดชิ้นส่วนหลายส่วนก่อนการผลิต

S3 ใช้การอัปโหลดแบบหลายส่วนเพื่อแบ่งไฟล์ขนาดใหญ่เป็นส่วนๆ เอกสารของ ownCloud STORAGE_USERS_S3NG_PUT_OBJECT_PART_SIZEมีวิธีการควบคุมขนาดของส่วนต่างๆ โดยค่าเริ่มต้นที่ระบุไว้คือ 16 MiB เมื่อไม่ได้ระบุค่าที่ชัดเจน

Amazon S3 อนุญาตให้มีการอัปโหลดแบบหลายส่วนได้สูงสุด 10,000 ส่วน โดยแต่ละส่วนมีขนาด 16 MiB ซึ่งจะเทียบเท่ากับประมาณ 160 GiB ก่อนที่จะถึงขีดจำกัดจำนวนส่วน หากผู้ใช้ของคุณอัปโหลดไฟล์ขนาดใหญ่เป็นประจำ ควรคำนวณขนาดส่วนที่ต้องการก่อนเริ่มใช้งานจริง แทนที่จะรอจนการถ่ายโอนขนาดใหญ่ล้มเหลว

ข้อแลกเปลี่ยนนั้นตรงไปตรงมา: ส่วนที่ใหญ่กว่าจะรองรับไฟล์ขนาดสูงสุดที่ใหญ่กว่าด้วยจำนวนคำขอที่น้อยลง แต่ก็จะเปลี่ยนแปลงหน่วยความจำ การบัฟเฟอร์ การลองใหม่ และลักษณะการถ่ายโอนด้วย ownCloud ยังระบุอีกว่าข้อมูลไฟล์ขาเข้าต้องการพื้นที่จัดเก็บชั่วคราวในระหว่างการบัฟเฟอร์ ดังนั้นการวางแผนความจุจึงต้องครอบคลุมมากกว่าแค่บัคเก็ตระยะไกล

ปัญหาที่พบบ่อยและสิ่งที่ควรตรวจสอบก่อน

สำรองข้อมูลบล็อบ S3 และข้อมูลเมตา POSIX พร้อมกัน

ในกรณีนี้s3ngบักเก็ตเป็นเพียงครึ่งหนึ่งของสถานะการจัดเก็บข้อมูล เอกสารเกี่ยวกับการสำรองข้อมูลของ ownCloud ระบุว่า การตั้งค่า S3 แบบกระจายต้องรวมถึงการกำหนดค่า ข้อมูลระบบ เมตาเดต้า และบล็อบ เอกสารเกี่ยวกับการกู้คืนก็ระบุเช่นกันว่าชุดข้อมูลเหล่านั้นจะต้องได้รับการกู้คืนอย่างสม่ำเสมอ

สำหรับบริการที่ใช้งานจริง ให้บันทึกรายละเอียดเกี่ยวกับการเชื่อมต่อเมตาเดต้า บักเก็ต ข้อมูลรับรองหรือบทบาท ไฟล์การกำหนดค่า และขั้นตอนการสำรองข้อมูลไว้ในคู่มือเดียวกัน ทดสอบการกู้คืนก่อนที่จะนำการออกแบบไปใช้จริง เอกสารอ้างอิงอย่างเป็นทางการที่เกี่ยวข้องคือคู่มือการสำรองข้อมูล ownCloudและข้อควรพิจารณาในการกู้คืน

จุดเริ่มต้นที่แนะนำ

สำหรับการใช้งานครั้งแรก ให้ออกแบบให้เรียบง่าย: ใช้ S3 bucket เฉพาะสำหรับไฟล์ไบนารี (blobs) หนึ่งอัน, เส้นทางเมตาเดตา POSIX แบบถาวรหนึ่งเส้น, รหัสประจำตัวบริการเฉพาะที่มีสิทธิ์การใช้งาน bucket ตามที่ระบุไว้, HTTPS ไปยังปลายทางของที่เก็บข้อมูลแบบอ็อบเจ็กต์ และการตั้งค่า multipart ตามค่าเริ่มต้น เว้นแต่ขนาดไฟล์ที่คาดหวังจะต้องการการเปลี่ยนแปลง

หลังจากตั้งค่าเสร็จแล้ว ให้ตรวจสอบสามส่วนแยกกัน ได้แก่ การเข้าถึงเครือข่ายและข้อมูลประจำตัวไปยังบัคเก็ต การเริ่มต้นใช้งาน Infinite Scale โดยไม่มีข้อผิดพลาดในการจัดเก็บข้อมูล และการอัปโหลด/ดาวน์โหลดจริงผ่าน ownCloud เมื่อการตรวจสอบเหล่านี้ผ่านแล้ว ให้ดำเนินการต่อในส่วนของการตรวจสอบ การสำรองข้อมูล กฎวงจรชีวิต และการปรับแต่งประสิทธิภาพ ลำดับขั้นตอนดังกล่าวจะทำให้การแก้ไขปัญหาทำได้ง่ายขึ้นมาก เพราะการทดสอบแต่ละครั้งจะตอบคำถามที่แตกต่างกัน แทนที่จะมองว่า “S3 ใช้งานได้” เป็นผลลัพธ์แบบทั้งหมดหรือไม่มีเลยเพียงอย่างเดียว