รักษาระบบให้พร้อมใช้งานระหว่างการอัปเกรด SLES 15 SP5 เป็น SP6

การกำหนดช่วงเวลาบำรุงรักษาที่สั้นทำได้ยากเมื่อเซิร์ฟเวอร์ SLES ให้บริการลูกค้าอยู่ SUSE รองรับการย้าย Service Pack ออนไลน์จาก SLES 15 SP5 ไปยัง SP6 แต่เครื่องที่อัปเกรดแล้วยังคงต้องรีบูต คำว่า “ออนไลน์” ไม่ได้หมายความว่าไม่ต้องรีบูต เพื่อให้แอปพลิเคชันยังคงใช้งานได้ ควรทำการอัปเกรดโหนดสำรองทีละโหนด หรือสร้างเครื่องทดแทน SP6 และย้ายการรับส่งข้อมูลไปยังเครื่องนั้น เซิร์ฟเวอร์เครื่องเดียวไม่สามารถรักษาความพร้อมใช้งานของระบบปฏิบัติการของตนเองในขณะที่กำลังรีบูตได้

ตัวอย่างสถานการณ์:ทีมสมมติทีมหนึ่งใช้งานเว็บแอปพลิเคชันบนโหนด SLES 15 SP5 จำนวน 3 โหนด โดยมีตัวกระจายโหลด (load balancer) เป็นตัวกลาง แอปพลิเคชันสามารถให้บริการคำขอจากอีก 2 โหนดได้ในขณะที่โหนดหนึ่งกำลังอยู่ในระหว่างการบำรุงรักษา ลำดับขั้นตอนด้านล่างแสดงให้เห็นว่าทีมดังกล่าวสามารถย้ายคลัสเตอร์ได้อย่างไร นี่เป็นเพียงตัวอย่าง ไม่ใช่การยืนยันว่าได้ทำการทดสอบแล้ว หรือว่าทุกคลัสเตอร์สามารถทนต่อการหยุดทำงานของโหนดได้

1. เลือกเส้นทางที่ตรงกับบริการ

สำหรับการอัปเกรดจาก SLES 15 SP5 ไปเป็น SP6 นั้น SUSE ได้ระบุวิธีการอัปเกรดทั้งแบบออนไลน์และออฟไลน์ วิธีการออนไลน์ใช้การย้ายข้อมูลด้วย YaST หรือทำzypper migrationในขณะที่ระบบปฏิบัติการกำลังทำงานอยู่ จากนั้นจะต้องรีสตาร์ทระบบหลังจากการย้ายข้อมูลเสร็จสิ้น การเปลี่ยนแปลงแพ็กเกจอาจทำให้บริการต่างๆ รีสตาร์ทด้วย ดังนั้นการย้ายข้อมูลแบบออนไลน์เพียงอย่างเดียวจึงไม่สามารถรับประกันความต่อเนื่องของแอปพลิเคชันได้

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

ภาพแสดงคำสั่ง crm status ที่ใช้ในการตรวจสอบสถานะของคลัสเตอร์
ภาพประกอบแสดงคำสั่งสำหรับตรวจสอบสถานะความสมบูรณ์ของคลัสเตอร์ก่อนที่จะนำโหนดออกจากระบบ

2. ตรวจสอบเป้าหมายและเตรียมแผนการกู้คืน

ก่อนที่จะแตะต้องคลัสเตอร์ โปรดตรวจสอบเวอร์ชันเริ่มต้น การลงทะเบียน ที่เก็บข้อมูล และส่วนขยายที่รองรับ SUSE ระบุว่า SLES 15 SP5 ถึง SP6 เป็นเส้นทางที่รองรับ การย้ายข้อมูลแบบออนไลน์จำเป็นต้องลงทะเบียนเครื่องกับ SUSE Customer Center หรือเซิร์ฟเวอร์ RMT ในพื้นที่ ไคลเอนต์ SUSE Manager ต้องใช้ขั้นตอนการย้ายข้อมูลของไคลเอนต์ Manager แทนการเรียกใช้zypper migrationโดยตรง เป้าหมายที่ใช้งานได้อาจขึ้นอยู่กับผลิตภัณฑ์และส่วนขยายที่ลงทะเบียนไว้

ข้อมูลการเผยแพร่ของ SUSE ระบุว่า ณ วันที่ 1 มกราคม 2026 SLES 15 SP6 ได้ย้ายไปอยู่ใน LTSS แล้ว โปรดตรวจสอบให้แน่ใจว่าการสมัครใช้งานและแหล่งลงทะเบียนของคุณรองรับ SP6 ก่อนที่จะกำหนดเวลาการย้ายข้อมูลนี้ หากไม่มีให้บริการ โปรดอย่าบังคับเปลี่ยนแปลงที่เก็บข้อมูลเพื่อเลียนแบบการย้ายข้อมูลที่ได้รับการสนับสนุน

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

ตัวอย่างเทอร์มินัลที่แสดงคำสั่ง zypper migration พร้อมสำหรับการตรวจสอบเป้าหมาย service-pack ที่พร้อมใช้งาน
ตัวอย่างคำสั่งการย้ายข้อมูล โปรดรันคำสั่งนี้บนโหนดที่จะอัปเกรดหลังจากตรวจสอบแล้วว่าโหนดเป้าหมายพร้อมใช้งาน

3. อัปเกรดโหนดที่หมดไฟทีละโหนด

สำหรับแต่ละโหนด ให้ปฏิบัติตามขั้นตอนการอัปเกรดแบบค่อยเป็นค่อยไปของ SLE HA และคู่มือการใช้งานคลัสเตอร์ของคุณ ห้ามอัปเกรดหลายโหนดพร้อมกัน เว้นแต่ขั้นตอนเฉพาะของผลิตภัณฑ์จะอนุญาตไว้อย่างชัดเจน

  1. ตรวจสอบให้แน่ใจว่าโหนดที่เหลือสามารถรองรับปริมาณงานได้ตรวจสอบสถานะของแอปพลิเคชันและคลัสเตอร์ ย้ายหรือระบายปริมาณการใช้งานออกจากโหนดโดยใช้การควบคุมที่ระบุไว้สำหรับตัวจัดการโหลดและทรัพยากรคลัสเตอร์ของคุณ อย่าดำเนินการต่อหากโหนดที่เหลือไม่สามารถรักษาจำนวนโหนดที่เพียงพอหรือตรงตามความจุขั้นต่ำของบริการได้
  2. หยุดการทำงานของคลัสเตอร์บนโหนดนั้น SUSE เตือนว่าการปล่อยให้ตัวจัดการทรัพยากรคลัสเตอร์ทำงานอยู่ระหว่างการอัปเดตซอฟต์แวร์อาจทำให้โหนดที่ใช้งานอยู่ถูกปิดกั้น บนโหนดที่เลือกสำหรับการบำรุงรักษา ให้เรียกใช้คำสั่งต่อไปนี้:
sudo crm cluster stop
ภาพแสดงตัวอย่างคำสั่งหยุดคลัสเตอร์ CRM บนโหนดที่เลือกสำหรับการบำรุงรักษา
ตัวอย่างคำสั่งในการหยุดการทำงานของคลัสเตอร์บนโหนดที่กำลังได้รับการอัปเกรด ตามข้อกำหนดของขั้นตอนการอัปเกรดแบบต่อเนื่อง
  1. เริ่มการย้าย Service Pack และตรวจสอบข้อเสนอ เรียกใช้คำสั่งการย้ายข้อมูล Zypper ตามเอกสาร:
sudo zypper migration

เลือก SLES 15 SP6 เฉพาะเมื่อปรากฏเป็นเป้าหมายที่ใช้งานได้เท่านั้น อ่านรายละเอียดของที่เก็บซอฟต์แวร์และแผนการติดตั้งแพ็กเกจ โดยเฉพาะแพ็กเกจที่เสนอให้ลบหรือลดระดับ และหยุดการติดตั้งหากการเปลี่ยนแปลงไม่เป็นไปตามที่คาดไว้ อย่ารับแผนที่คุณยังไม่ได้ตรวจสอบ รายชื่อแพ็กเกจที่แน่นอนจะแตกต่างกันไปตามซอฟต์แวร์ที่ติดตั้งและส่วนขยายที่ลงทะเบียนไว้

ภาพหน้าจอแสดงเป้าหมายการย้ายข้อมูลโดยเลือก SLES 15 SP6
ภาพแสดงตัวเลือกเป้าหมายโดยละเอียด ตรวจสอบแพ็คเกจผลิตภัณฑ์และบริการที่เสนอสำหรับโฮสต์ที่ระบุ
ตัวอย่างข้อความแจ้งเตือนในเทอร์มินัลเพื่อตรวจสอบการเปลี่ยนแปลงแพ็กเกจก่อนดำเนินการย้ายเซอร์วิสแพ็กเกจต่อไป
ตัวอย่างข้อความแจ้งเตือนการตรวจสอบแพ็กเกจ: ตรวจสอบการลบ การลดระดับ และการเปลี่ยนแปลงในที่เก็บข้อมูลก่อนดำเนินการต่อ
  1. รีบูตโหนดที่ได้รับการอัปเกรดแล้วหลังจากที่ Zypper รายงานว่าการย้ายข้อมูลสำเร็จ ให้รีสตาร์ทเครื่องเพื่อให้บูตเคอร์เนลและบริการ SP6:
sudo reboot
ภาพหน้าจอเทอร์มินัลแสดงคำสั่งรีบูตหลังจากย้าย Service Pack เสร็จสิ้น
ขั้นตอนการรีบูตแสดงตัวอย่าง; โหนดนี้จะไม่สามารถใช้งานได้ในระหว่างการรีสตาร์ท ดังนั้นโหนดคลัสเตอร์ที่เหลือจะต้องรับช่วงการให้บริการต่อไป
  1. กลับเข้าร่วมและตรวจสอบก่อนที่จะย้ายไปยังโหนดถัดไปหลังจากที่โหนดกลับมาแล้ว ให้เริ่มการทำงานของคลัสเตอร์:
sudo crm cluster start
sudo crm status

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

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

4. ตรวจสอบบริการ ไม่ใช่แค่ป้ายชื่อระบบปฏิบัติการ

หลังจากอัปเกรดโหนดทั้งหมดแล้ว ให้ยืนยันการเผยแพร่ด้วยคำสั่ง `release` cat /etc/os-releaseตรวจสอบสถานะคลัสเตอร์ด้วยคำสั่ง `cluster health` crm statusและตรวจสอบหน่วย systemd ที่ล้มเหลวด้วย คำสั่ง `systemd unit` systemctl --failedจากนั้นทดสอบแอปพลิเคชันจริงผ่านที่อยู่ไคลเอ็นต์ปกติ รวมถึงการตรวจสอบสถานะ การเข้าถึงฐานข้อมูลหรือพื้นที่จัดเก็บ และงานที่กำหนดไว้ซึ่งมีความสำคัญต่อผู้ใช้ ตรวจสอบบันทึกการย้ายข้อมูลและยืนยันว่าที่เก็บข้อมูลและส่วนขยายที่คาดหวังนั้นทำงานอยู่บนทุกโหนด

การย้ายระบบปฏิบัติการที่ประสบความสำเร็จไม่ได้หมายความว่าทุกส่วนประกอบของแอปพลิเคชันจะเข้ากันได้ หรือไม่มีการร้องขอใดถูกขัดจังหวะ หากแอปพลิเคชันไม่สามารถทนต่อการสลับโหนดได้ ให้ใช้การปรับใช้แบบบลู-กรีนพร้อมการจำลองข้อมูลที่ตรวจสอบแล้วและการสลับปลายทางที่ควบคุมได้ หรือวางแผนช่วงเวลาการบำรุงรักษา สำหรับตัวเลือกคำสั่งและเงื่อนไขการสนับสนุนที่แน่นอน โปรดดูคู่มือการอัปเกรดออนไลน์ SLES 15 SP6 ของ SUSE เส้นทางการอัปเกรดที่รองรับขั้นตอนการอัปเกรดแบบหมุนเวียน SLE HAและบันทึกประจำรุ่น SUSE Multi-Linux Manager 5.1สำหรับบันทึกการเปลี่ยนผ่านวงจรชีวิต SP6

ฝากความเห็น

เปิดใช้งานการแพตช์สด SLES และตรวจสอบการแก้ไขเคอร์เนล

เปิดใช้งานการแพตช์สด SLES และตรวจสอบการแก้ไขเคอร์เนล

ตั้งค่าเส้นทาง Live Patching ที่ถูกต้องสำหรับ SLES 16.0 หรือ 15 SP7 ใช้การแก้ไขเคอร์เนลที่เหมาะสม และตรวจสอบว่าสิ่งใดทำงานอยู่โดยไม่สับสนกับการอัปเดตเคอร์เนลที่ต้องรีบูตเครื่อง

รักษาระบบให้พร้อมใช้งานระหว่างการอัปเกรด SLES 15 SP5 เป็น SP6

รักษาระบบให้พร้อมใช้งานระหว่างการอัปเกรด SLES 15 SP5 เป็น SP6

SLES 15 SP5 สามารถอัปเกรดแบบออนไลน์เป็น SP6 ได้ แต่แต่ละโหนดจะต้องรีบูต ใช้การอัปเกรดแบบค่อยเป็นค่อยไป (rolling upgrade) หรือการเปลี่ยนระบบแบบสีฟ้า-เขียว (blue-green cutover) ที่ผ่านการทดสอบแล้ว เพื่อให้สามารถเข้าถึงเวิร์กโหลดได้อย่างต่อเนื่อง

สร้างโปรไฟล์ AppArmor แบบกำหนดเองบน SUSE Linux

สร้างโปรไฟล์ AppArmor แบบกำหนดเองบน SUSE Linux

สร้าง ปรับแต่ง และตรวจสอบโปรไฟล์ AppArmor ที่มีสิทธิ์ขั้นต่ำสุดบน SLES 15 SP7 พร้อมหมายเหตุที่ชัดเจนเกี่ยวกับค่าเริ่มต้นของ SELinux ใน SLES 16

ใช้งาน SLES 15 STIG อย่างปลอดภัยด้วย OpenSCAP

ใช้งาน SLES 15 STIG อย่างปลอดภัยด้วย OpenSCAP

ใช้โปรไฟล์ STIG ที่ SUSE รองรับเพื่อสแกน SLES 15 ทดสอบการแก้ไข ตรวจสอบผลการค้นพบที่เหลือ และเก็บรักษาหลักฐานการประเมิน

กู้คืนการเข้าถึง Cockpit ไปยัง SUSE Linux Enterprise Server

กู้คืนการเข้าถึง Cockpit ไปยัง SUSE Linux Enterprise Server

ตรวจสอบหาสาเหตุของการเชื่อมต่อ Cockpit ที่ล้มเหลวผ่านทาง DNS, พอร์ต 9090, ซ็อกเก็ต systemd, firewalld, TLS และการตั้งค่าการเข้าสู่ระบบ โดยใช้คำแนะนำล่าสุดของ SUSE

กำหนดค่าการสลับใช้งานอีเธอร์เน็ตที่เชื่อถือได้ด้วย Bonding ใน SLES 15

กำหนดค่าการสลับใช้งานอีเธอร์เน็ตที่เชื่อถือได้ด้วย Bonding ใน SLES 15

สร้างการเชื่อมต่ออีเธอร์เน็ตสำรองบน ​​SLES 15 โดยใช้ YaST และ Wicked กำหนดค่าการเชื่อมต่อแบบแอคทีฟ-สำรอง และตรวจสอบพอร์ตทั้งสองและการสลับการทำงานเมื่อเกิดข้อผิดพลาด

สร้างโปรไฟล์ AutoYaST ที่สามารถนำกลับมาใช้ใหม่ได้สำหรับการติดตั้ง SLES 15

สร้างโปรไฟล์ AutoYaST ที่สามารถนำกลับมาใช้ใหม่ได้สำหรับการติดตั้ง SLES 15

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

การตั้งค่า KVM ใน SLES 15: กำหนดให้ VM ที่เลือกเริ่มต้นทำงานเมื่อบูตเครื่อง

การตั้งค่า KVM ใน SLES 15: กำหนดให้ VM ที่เลือกเริ่มต้นทำงานเมื่อบูตเครื่อง

ติดตั้งเครื่องมือ SLES 15 KVM และ libvirt เปิดใช้งานบริการโฮสต์ที่ถูกต้อง และกำหนดค่าเครื่องเสมือนที่เลือกให้เริ่มต้นทำงานหลังจากรีบูตเครื่อง

ทำการสำรองข้อมูล Nextcloud อย่างสม่ำเสมอโดยอัตโนมัติด้วย Restic และ Cron

ทำการสำรองข้อมูล Nextcloud อย่างสม่ำเสมอโดยอัตโนมัติด้วย Restic และ Cron

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

สำรองข้อมูลและกู้คืนกล่องจดหมาย Zimbra CE โดยใช้การส่งออก TGZ

สำรองข้อมูลและกู้คืนกล่องจดหมาย Zimbra CE โดยใช้การส่งออก TGZ

ส่งออกกล่องจดหมาย Zimbra Community Edition ส่วนบุคคล ตรวจสอบความถูกต้องของการสำรองข้อมูล TGZ และกู้คืนรายการที่หายไปโดยไม่เขียนทับอีเมลที่มีอยู่