วิธีการตั้งค่าคลัสเตอร์ Collabora Online ที่มีหลายโหนด

คลัสเตอร์ Collabora Online ไม่ได้เป็นเพียงแค่coolwsdเซิร์ฟเวอร์ที่ทำงานได้ดีหลายเครื่องอยู่เบื้องหลังตัวกระจายโหลดแบบ Round-robin เท่านั้น การแก้ไขเอกสารร่วมกันขึ้นอยู่กับการส่งคำขอสำหรับเอกสารเดียวกันไปยังโหนด Collabora เดียวกัน แผนภูมิ Kubernetes ของ Collabora จึงระบุการกำหนดเส้นทางโดยใช้ตัวระบุเอกสาร WOPI (WOPI document identifier) WOPISrc​​ด้วยเหตุผลนี้ คู่มือนี้ใช้แผนภูมิ Helm ของ Collabora บน Kubernetes ที่ได้รับการดูแลรักษาเป็นตัวอย่างการตั้งค่าแบบหลายโหนด และระบุสิ่งที่ต้องเปลี่ยนแปลงสำหรับตัวควบคุม Ingress ที่แตกต่างกัน หรือการใช้งานที่ไม่ใช่ Kubernetes

ตรวจสอบแล้ว:แผนภูมิของ Collabora รองรับสำเนาหลายชุดและอธิบายความสัมพันธ์ต่อเอกสารโดยใช้WOPISrc. ขึ้นอยู่กับการปรับใช้:คำอธิบายประกอบขาเข้า การยุติ TLS การร้องขอทรัพยากร และความเหมาะสมของตัวควบคุมเซสชันไม่ควรสันนิษฐานว่า:ตัวกระจายโหลดหรือการตั้งค่า "เซสชันคงที่" ทุกแบบจะรักษาความสัมพันธ์ของเอกสารไว้ได้ ตรวจสอบพฤติกรรมเฉพาะของตัวควบคุมและทดสอบก่อนย้ายผู้ใช้ไปยังคลัสเตอร์

กลุ่มคลัสเตอร์นี้ทำอะไรได้บ้าง และมันไม่ได้ทำอะไรบ้าง

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

นอกจากนี้ Collabora ยังจัดทำเอกสารเกี่ยวกับ COOL Controller สำหรับ Kubernetes ซึ่งเพิ่มวิธีการจัดการเซสชันที่แตกต่างออกไป การกำหนดเส้นทางและการกำหนดค่าจะแตกต่างจากพูลจำลองแบบสแตนด์อโลน บทความนี้กำหนดค่าโมเดลความสัมพันธ์ของแหล่งข้อมูล WOPI ที่เรียบง่ายกว่า อย่านำไปใช้ร่วมกับการตั้งค่าโทเค็นเส้นทางเฉพาะของคอนโทรลเลอร์ เว้นแต่คุณได้ปรับใช้และกำหนดค่าคอนโทรลเลอร์สำหรับเวอร์ชันของคุณแล้ว

ขั้นตอน:ตัดสินใจว่าคุณต้องการบริการ Collabora แบบจำลองพื้นฐานเพื่อรองรับความจุและความซ้ำซ้อนของโหนด หรือการตั้งค่าที่จัดการโดยคอนโทรลเลอร์พร้อมพฤติกรรมที่รับรู้เซสชัน การตั้งค่าแบบหลังมีส่วนประกอบเพิ่มเติมและการกำหนดค่าเฉพาะเวอร์ชันหากคุณกำลังพิจารณาตัวเลือกนี้ โปรดตรวจสอบ ภาพรวมของ Collabora Online Controller

ก่อนที่คุณจะทำการติดตั้งระบบ

• คลัสเตอร์ Kubernetes ที่ใช้งานได้, Helm, DNS สำหรับชื่อโฮสต์ Collabora สาธารณะ และ ingress หรือ reverse proxy ที่รองรับ TLS
• การผสานรวม WOPI เช่น Nextcloud ที่กำหนดค่าให้ใช้ชื่อโฮสต์สาธารณะของ Collabora เพียงชื่อเดียว แทนที่จะใช้ที่อยู่ของแต่ละพ็อด
• โฮสต์ WOPI ที่ Collabora อนุญาตให้ยอมรับ จะถูกป้อนในcollabora.aliasgroupsการตั้งค่า ของแผนภูมิ
• มี CPU และหน่วยความจำเพียงพอสำหรับงานประมวลผลเอกสาร พร้อมทั้งมีวิธีตรวจสอบสถานะของ Pod, บันทึกการเข้าถึง และการใช้ทรัพยากร
• ช่วงเวลาสำหรับการบำรุงรักษาในช่วงเริ่มต้นการใช้งาน และเอกสารทดสอบที่มีบัญชีผู้ใช้สองบัญชีแยกกัน

บริการ Collabora Online แบบเฉพาะนั้นแตกต่างจากเซิร์ฟเวอร์ CODE ในตัวของ Nextcloud Nextcloud อธิบายว่าตัวเลือกในตัวนั้นมีไว้สำหรับการใช้งานส่วนบุคคลหรือทีมขนาดเล็ก และไม่มีคุณสมบัติการปรับขนาดขั้นสูงของเซิร์ฟเวอร์เฉพาะคำแนะนำ:หากคุณต้องการกลุ่มโหนด Collabora หลายโหนด ให้วางแผนใช้บริการเฉพาะและตรวจสอบรูปแบบการอนุญาตใช้งานและการสนับสนุนที่เหมาะสมกับการใช้งานของคุณ ดูคู่มือการติดตั้ง Nextcloud Office

ขั้นตอนที่ 1: เลือกรูปแบบการกำหนดเส้นทาง

โมเดลแบบสแตนด์อโลนที่บันทึกไว้WOPISrcจะใช้แฮชเพื่อระบุเอกสารในคำขอ WOPI คำขอสำหรับเอกสารหนึ่งฉบับจะต้องส่งไปยังพอดเดียวกัน ในขณะที่คำขอสำหรับเอกสารที่แตกต่างกันสามารถกระจายไปยังพอดต่างๆ ได้ กฎแบบวนรอบทั่วไปไม่ตรงตามข้อกำหนดนี้

การดำเนินการ:ใช้การใช้งาน ingress ที่ได้รับการสนับสนุนโดยเอกสารของ chart เช่น ตัวอย่าง ingress ของ NGINX หรือ HAProxy ที่ระบุไว้ในเอกสาร หรือใช้ reverse proxy ใน namespace ของ chart ในกรณีที่คลัสเตอร์ไม่อนุญาตให้ใช้ ingress controller ที่เหมาะสม หากคุณใช้ proxy อื่น ให้ตรวจสอบว่า proxy นั้นสามารถกำหนดเส้นทางคำขอจากแหล่ง WOPI ได้อย่างสม่ำเสมอ ทั้งสำหรับคำขอ HTTP ทั่วไปและการเชื่อมต่อ WebSocket ที่มีอายุการใช้งานยาวนาน

ขั้นตอนที่ 2: ตรวจสอบแผนภูมิและเลือกเวอร์ชัน

แผนภูมิและค่าต่างๆ อาจเปลี่ยนแปลงไปตามเวลา ก่อนการติดตั้ง โปรดตรวจสอบไฟล์ README และค่าต่างๆ ของแผนภูมิฉบับปัจจุบันอย่างเป็นทางการ แทนที่จะคัดลอกการตั้งค่าที่เขียนขึ้นสำหรับเวอร์ชันเก่า ตัวอย่างด้านล่างนี้อ้างอิงจากเอกสารแผนภูมิ Collabora ที่ได้รับการดูแลรักษาอย่างดี ซึ่งได้รับการตรวจสอบเมื่อวันที่ 6 ตุลาคม 2026 โปรดถือว่าบันทึกการเผยแพร่และค่าต่างๆ ในเวอร์ชันปัจจุบันของที่เก็บข้อมูลเป็นข้อมูลที่ถูกต้องที่สุดสำหรับการติดตั้งของคุณ

helm repo add collabora https://collaboraonline.github.io/online/
helm repo update
helm search repo collabora/collabora-online --versions
helm show values collabora/collabora-online

ขั้นตอนการดำเนินการ:เลือกเวอร์ชันของแผนภูมิที่ตรงกับนโยบายการควบคุมการเปลี่ยนแปลงของคุณ และบันทึกเวอร์ชันของอิมเมจ Collabora ที่ใช้งาน ตรึงเวอร์ชันของแผนภูมิไว้เพื่อให้สามารถอัปเกรดซ้ำได้ หลีกเลี่ยงการใช้เวอร์ชันที่ไม่ได้รับการตรวจสอบในสภาพแวดล้อมการใช้งานจริง คู่มือการตั้งค่าของแผนภูมิเองอยู่ใน ไฟล์ README ของ Collabora Online for Kubernetes

ขั้นตอนที่ 3: เตรียมค่าสำหรับสำเนาสามชุด

ตัวอย่างนี้สมมติว่าใช้ NGINX Ingress Controller, การยุติการเชื่อมต่อ TLS ที่ฝั่ง Ingress และโฮสต์ WOPI ภายนอกที่cloud.example.com. แทนที่ชื่อโฮสต์ทั้งสองด้วยชื่อโฮสต์ของคุณเอง หากการยุติการเชื่อมต่อ TLS เกิดขึ้นที่อื่น หรือคุณใช้ HAProxy ให้ใช้การกำหนดค่าที่ระบุไว้ในเอกสารของ Controller นั้นแทน

replicaCount: 3

autoscaling:
  enabled: false

ingress:
  enabled: true
  className: nginx
  annotations:
    nginx.ingress.kubernetes.io/upstream-hash-by: "$arg_WOPISrc"
    nginx.ingress.kubernetes.io/proxy-body-size: "0"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "600"
  hosts:
    - host: office.example.com
      paths:
        - path: /
          pathType: ImplementationSpecific

collabora:
  aliasgroups:
    - host: "https://cloud.example.com:443"
  extra_params: --o:ssl.enable=false --o:ssl.termination=true

ค่าแฮชและค่าหมดเวลาที่แสดงด้านบนเป็นตัวอย่าง NGINX ในแผนภูมิ บรรทัดนี้extra_paramsเหมาะสมเฉพาะเมื่อพร็อกซีแบบย้อนกลับยุติ TLS และเชื่อมต่อกับ Collabora ผ่าน HTTP เท่านั้น อย่าใช้ค่านี้โดยไม่เปลี่ยนแปลงหากโครงสร้าง TLS ของคุณแตกต่างออกไป กำหนดค่าความลับ TLS ขาเข้าและโฮสต์ตามตัวจัดการใบรับรองและค่าแผนภูมิในเครื่องของคุณ ส่วนที่ยกมานี้ไม่ได้รวมการตั้งค่าเฉพาะของผู้ให้บริการเหล่านั้นไว้

ขั้นตอน:บันทึกไฟล์นี้เป็นไฟล์my_values.yaml.txt เพิ่มการตั้งค่า TLS ที่จำเป็นสำหรับ Ingress ของคุณ และเปรียบเทียบคีย์ทุกตัวกับคีย์ของ Chart Release ที่เลือกไว้values.yamlรักษาชื่อโฮสต์สาธารณะของ Collabora ให้สอดคล้องกันทั้งในส่วนของ DNS, TLS, URL ของ Collabora ในการผสานรวม และการกำหนดเส้นทางพร็อกซี

ขั้นตอนที่ 4: ติดตั้ง Collabora เวอร์ชันใหม่

ติดตั้งลงในเนมสเปซที่กำหนดไว้ แทนที่<chart-version>ด้วยเวอร์ชันที่เลือกในขั้นตอนที่ 2 วงเล็บเหลี่ยมในที่นี้เป็นเพียงตัวอย่างเพื่ออธิบายเท่านั้น ไม่ควรพิมพ์ตามตัวอักษร

helm install --create-namespace   --namespace collabora   collabora-online collabora/collabora-online   --version <chart-version>   -f my_values.yaml

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

ขั้นตอน:ตรวจสอบการเผยแพร่และรอจนกว่าสำเนาทั้งหมดจะพร้อมใช้งาน:

helm status collabora-online -n collabora
kubectl get pods,svc,ingress -n collabora
kubectl get events -n collabora --sort-by=.lastTimestamp

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

ขั้นตอนที่ 5: เชื่อมต่อแอปพลิเคชัน WOPI

ในการตั้งค่าการผสานรวมสำนักงานของแพลตฟอร์มไฟล์ ให้ตั้งค่า URL ของเซิร์ฟเวอร์ Collabora เป็นปลายทางสาธารณะ ตัวอย่างเช่นhttps://office.example.comอย่าชี้แอปพลิเคชันไปยัง IP ของพ็อดหรือชื่อบริการเฉพาะของ Kubernetes เว้นแต่ว่าการผสานรวมนั้นทำงานอยู่ภายในคลัสเตอร์ และการออกแบบของคุณรองรับการกำหนดเส้นทางส่วนตัวอย่างชัดเจน

ชื่อโฮสต์ในไฟล์aliasgroupsต้องระบุถึงโฮสต์ WOPI ที่จัดเก็บและให้บริการเอกสาร ไม่ใช่ชื่อโฮสต์ของ Collabora การไม่ตรงกันอาจทำให้การตรวจสอบความถูกต้องของโฮสต์ WOPI ล้มเหลว แม้ว่าพอดและอินเกรสของ Collabora จะทำงานได้ปกติก็ตาม

ขั้นตอน:ป้อน URL สาธารณะของ Collabora เดียวกันลงในการตั้งค่าการผสานรวม บันทึก และตรวจสอบว่าการเชื่อมต่อหรือการตรวจสอบการค้นหาสำเร็จหรือไม่ หากล้มเหลว ให้ตรวจสอบรายการอนุญาต WOPI ของแอปพลิเคชัน กลุ่มนามแฝงของ Collabora DNS TLS และส่วนหัวพร็อกซี ก่อนที่จะเปลี่ยนจำนวนสำเนา

ขั้นตอนที่ 6: ทดสอบความสัมพันธ์และการทำงานร่วมกันของเอกสาร

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

การดำเนินการ:ตรวจสอบว่าแฮชของแหล่งข้อมูล WOPI มีอยู่และถูกนำไปใช้อย่างสม่ำเสมอในคำขอที่สร้างขึ้นสำหรับเอกสารเดียวกัน รวมถึงการอัปเกรด WebSocket ด้วย หากผู้ใช้ไม่เห็นการแก้ไขของกันและกัน ให้เปรียบเทียบการเลือกแบ็กเอนด์สำหรับเอกสารเดียวกันก่อนที่จะตรวจสอบโฮสต์ WOPI หรือแคชของเบราว์เซอร์

ขั้นตอนที่ 7: ทดสอบการจัดการสถานะสุขภาพและการสูญเสียโหนด

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

ขั้นตอนการดำเนินการ:ในสภาพแวดล้อมการทดสอบ ให้ลบ Pod หนึ่งตัวออกจากบริการในระหว่างเซสชันการแก้ไขที่ใช้งานอยู่ สังเกตพฤติกรรมของไคลเอ็นต์และการกำหนดเส้นทางพร็อกซี จากนั้นเปิดเอกสารอีกครั้งและยืนยันว่าเอกสารเข้าถึง Pod ที่ทำงานได้ปกติ อย่าทำการทดสอบนี้กับเอกสารที่ใช้งานจริงโดยไม่มีแผนการบำรุงรักษาที่ได้รับการอนุมัติ สำหรับการรักษาความต่อเนื่องของเซสชันที่เข้มงวดมากขึ้น ให้ประเมิน COOL Controller และการตั้งค่า route-token เฉพาะเวอร์ชัน

ขั้นตอนที่ 8: ตรวจสอบ ปรับแต่ง และอัปเกรดอย่างรอบคอบ

ติดตามการรีสตาร์ท Pod, การใช้งาน CPU และหน่วยความจำ, ข้อผิดพลาดของคำขอและ WebSocket, ความหน่วงแฝงของ Ingress และรายงานของผู้ใช้เกี่ยวกับการโหลดเอกสารหรือการเชื่อมต่อใหม่ เอกสารประกอบแผนภูมิของ Collabora มีคำแนะนำเกี่ยวกับการตรวจสอบ Kubernetes กำหนดทรัพยากรจากปริมาณงานที่สังเกตได้ แทนที่จะคัดลอกตัวเลขตัวอย่าง: ขนาดเอกสาร เซสชันพร้อมกัน ฟอนต์ และรูปแบบการแก้ไข ล้วนส่งผลต่อความจุ

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

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

ความเข้าใจผิดทั่วไปที่ควรตรวจสอบ

• “การสร้างสำเนาสามชุดจะสร้างคลัสเตอร์ที่ใช้งานได้โดยอัตโนมัติ”สำเนาเพียงอย่างเดียวไม่สามารถกำหนดค่าความสัมพันธ์ของเอกสารได้ โปรดตรวจสอบให้แน่ใจว่าแฮชขาเข้าบนแหล่งที่มาของ WOPI หรือตัวควบคุมของคุณให้การกำหนดเส้นทางเซสชันตามที่ต้องการ
• “การกำหนดเซสชันแบบคงที่โดยอิงจาก IP ของผู้ใช้ก็เพียงพอแล้ว”นั่นไม่ใช่กฎที่ระบุไว้ในแผนภูมิของ Collabora สำหรับพูล Kubernetes แบบสแตนด์อโลน ผู้ใช้ที่ทำงานร่วมกันในเอกสารเดียวกันจะต้องมารวมกันที่โหนดเดียวกัน แม้ว่าพวกเขาจะมาจากอุปกรณ์หรือเครือข่ายที่แตกต่างกันก็ตาม กำหนดค่าการเชื่อมโยงตามเอกสารและทดสอบกับผู้ใช้สองคน
• “หน้าแรกที่แสดงผลได้ปกติแสดงว่าคลัสเตอร์พร้อมใช้งานแล้ว”แต่มันแสดงเพียงแค่ว่ามีการส่งคำขอ HTTP สำเร็จเพียงครั้งเดียวเท่านั้น ควรทดสอบการเปิดและแก้ไขเอกสารร่วมกัน การอัปเกรด WebSocket และพฤติกรรมเมื่อพ็อดตัวใดตัวหนึ่งไม่พร้อมใช้งาน
• “การเพิ่มโหนดรับประกันว่าเซสชันที่ใช้งานอยู่จะยังคงอยู่แม้โหนดจะสูญหาย”พูลความสัมพันธ์แหล่งที่มา WOPI พื้นฐานจะส่งเอกสารไปยังโหนด แต่ไม่ได้สร้างความมั่นใจว่ากระบวนการแก้ไขในหน่วยความจำจะถูกจำลอง ตรวจสอบพฤติกรรมการกู้คืนที่คาดหวังในการทดสอบแบบควบคุม หรือประเมินคุณสมบัติการจัดการเซสชันแยกต่างหากของคอนโทรลเลอร์

สำหรับระบบที่ไม่ใช้ Kubernetes หลักการทางสถาปัตยกรรมจะเหมือนกัน แต่คำสั่ง chart ของ Kubernetes และ annotation ของ ingress จะใช้ไม่ได้ ให้ใช้การกำหนดค่า proxy สำหรับเวอร์ชัน Collabora และ load balancer ของคุณ ตรวจสอบให้แน่ใจว่ารองรับการเชื่อมต่อ WebSocket ที่มีอายุการใช้งานยาวนาน และใช้งานการกำหนดเส้นทางต่อเอกสารโดยใช้ซอร์สโค้ด WOPI คู่มือ Collabora Online SDKอธิบายถึง load balancing และWOPISrcข้อกำหนด affinity ตรวจสอบส่วนที่เทียบเท่าในคู่มือสำหรับเวอร์ชันที่คุณใช้งาน