10. เข้าใจเกี่ยวกับเคอร์เนลสองตัวของ Oracle Linux “UEK” และ “RHCK”

Oracle Linux มีเคอร์เนลสองตัว: Red Hat Compatible Kernel (RHCK) ซึ่งเป็นเคอร์เนลที่เข้ากันได้กับ RHEL และ Unbreakable Enterprise Kernel (UEK) ซึ่งเป็นเคอร์เนลของ Oracle Linux เอง

หากคุณไม่เคยใช้ Oracle Linux มาก่อน คุณอาจกังวลเกี่ยวกับ Unbreakable Enterprise Kernel ในบทความนี้ เราจะอธิบายเกี่ยวกับ Unbreakable Enterprise Kernel รวมถึงความเข้ากันได้และเกณฑ์ในการตัดสินใจว่าเมื่อใดควรใช้

Red Hat Compatible Kernel และ Unbreakable Enterprise Kernel

ในฐานะการแนะนำพื้นฐาน เราจะให้ภาพรวมของ Red Hat Compatible Kernel และ Unbreakable Enterprise Kernel

Red Hat Compatible Kernel คืออะไร?

ตามชื่อที่บ่งบอก Red Hat Compatible Kernel (RHCK) เป็นเคอร์เนลที่เข้ากันได้กับ RHEL ซึ่งเป็นเพียงการสร้างใหม่จากซอร์สโค้ดเคอร์เนลของ RHEL เนื่องจากเป็นเพียงการสร้างใหม่ มันจะทำงานเหมือนกับ RHEL รวมถึงข้อบกพร่อง ตราบใดที่หมายเลขเวอร์ชันเหมือนกัน

ตารางต่อไปนี้แสดงเวอร์ชัน RHCK และ glibc สำหรับแต่ละเวอร์ชันหลักของ Oracle Linux เพื่อเน้นความเข้ากันได้ภายในเวอร์ชันหลักเดียวกันของ Linux เวอร์ชันพื้นฐานของส่วนประกอบสำคัญ เช่น เคอร์เนลและ glibc จะไม่เปลี่ยนแปลง แต่เมื่อมีการอัปเดต หมายเลขรุ่นจะเปลี่ยนตามที่อธิบายไว้ด้านล่าง

เวอร์ชัน Linux	เวอร์ชัน RHCK	เวอร์ชัน glibc
Oracle Linux 9	5.14.0	2.34
Oracle Linux 8	4.18.0	2.28
Oracle Linux 7	3.10.0	2.17

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

รูปที่ 1 เวอร์ชันและรุ่นของเคอร์เนล/glibc

Unbreakable Enterprise Kernel คืออะไร?

Unbreakable Enterprise Kernel (UEK) เป็นเคอร์เนลที่ไม่เหมือนใครของ Oracle Linux ซึ่งอิงจากเคอร์เนลที่ใหม่กว่า RHCK และเข้ากันได้กับ RHCK คู่มือต่อไปนี้ให้ข้อมูลอ้างอิงเกี่ยวกับคุณสมบัติของมัน

เอกสารอย่างเป็นทางการ: Unbreakable Enterprise Kernel

Unbreakable Enterprise Kernel (UEK) เป็นเคอร์เนล Linux ที่สร้างโดย Oracle และได้รับการสนับสนุนผ่านการสนับสนุน Oracle Linux โดยเน้นที่ประสิทธิภาพ ความเสถียร และการย้อนกลับขั้นต่ำโดยการติดตามซอร์สโค้ดหลักอย่างใกล้ชิดเท่าที่จะเป็นไปได้ UEK ได้รับการทดสอบอย่างดีและใช้เพื่อรัน Oracle’s Engineered Systems, Oracle Cloud Infrastructure และการใช้งานระดับองค์กรขนาดใหญ่สำหรับลูกค้า Oracle

คู่มือการติดตั้งฐานข้อมูลสำหรับ Linux

Unbreakable Enterprise Kernel รวมอยู่และเปิดใช้งานโดยค่าเริ่มต้นในเคอร์เนล Oracle Linux มันอิงจากเคอร์เนล Linux การพัฒนาหลักที่เสถียรล่าสุด และยังรวมถึงการปรับปรุงที่พัฒนาร่วมกับทีม Oracle Database, Oracle middleware และทีมวิศวกรรมฮาร์ดแวร์ Oracle เพื่อให้มั่นใจถึงความเสถียรและประสิทธิภาพสูงสุดสำหรับงานระดับองค์กรที่ต้องการมากที่สุด

ประเด็นหลักคือ:

• UEK เป็นเคอร์เนล Linux ที่พัฒนาและสนับสนุนโดย Oracle
• เคอร์เนลเริ่มต้นของ Oracle Linux
• อิงจากเวอร์ชันเสถียรใหม่ของเคอร์เนล Linux หลัก
• พัฒนาร่วมกับทีม Exadata และ Oracle Database โดยเน้นที่ประสิทธิภาพและความเสถียร
• ทดสอบในสภาพแวดล้อมงานระดับองค์กรขนาดใหญ่ รวมถึง Exadata และ Oracle Cloud Infrastructure

ความสัมพันธ์ระหว่าง Oracle Linux และเวอร์ชันเคอร์เนล

หมายเลขเวอร์ชันของ UEK เปลี่ยนแปลงขึ้นอยู่กับเคอร์เนลที่มันอิง และถูกตั้งชื่อ เช่น UEK6 และ UEK7 นอกจากนี้ ความแตกต่างที่สำคัญจาก RHCK คือเวอร์ชันหลักของ Oracle Linux และเวอร์ชัน UEK ไม่คงที่ ตารางต่อไปนี้แสดงความสัมพันธ์ระหว่าง UEK และ Oracle Linux จากตารางนี้ คุณจะเห็นว่า Oracle Linux 8 สามารถใช้ UEK6 และ UEK7 ได้

เวอร์ชัน UEK	เวอร์ชันเคอร์เนล	Oracle Linux 7	Oracle Linux 8	Oracle Linux 9
UEK7	5.15.0	×	○	○
UEK6	5.4.17	○	○	×
UEK5	4.14.35	○	×	×
UEK4	4.1.12	○	×	×

ตารางต่อไปนี้เปรียบเทียบเวอร์ชันเคอร์เนลของ RHCK และ UEK สำหรับ Oracle Linux Oracle Linux 9 เปิดตัวในปี 2022 ดังนั้นความแตกต่างระหว่างเวอร์ชัน RHCK และ UEK จึงเล็กน้อย อย่างไรก็ตาม เนื่องจาก Oracle Linux 7 และ Oracle Linux 8 ได้รับการปล่อยมาระยะหนึ่งแล้ว ความแตกต่างระหว่างเวอร์ชัน RHCK และ UEK จึงมีมาก

เวอร์ชัน Linux	RHCK	UEK
Oracle Linux 9	5.14.0	5.15.0
Oracle Linux 8	4.18.0	5.4.17, 5.15.0
Oracle Linux 7	3.10.0	4.1.12, 4.14.35, 5.4.17

การตั้งชื่อเวอร์ชันเคอร์เนล Linux

ตอนนี้เราได้กล่าวถึงเวอร์ชันเคอร์เนล Linux แล้ว มาดูการตั้งชื่ออีกครั้งกันเถอะ จริง ๆ แล้วไม่มีอะไรที่แน่นอน เพราะมันมีการเปลี่ยนแปลงหลายครั้งและการตั้งชื่อมีความแตกต่างเล็กน้อยระหว่าง kernel.org ดั้งเดิมและการกระจาย Linux

การตั้งชื่อที่ kernel.org

ขั้นแรก มาดูการตั้งชื่อที่ใช้โดยเว็บไซต์เคอร์เนล Linux อย่างเป็นทางการ kernel.org เคอร์เนล Linux ถูกตั้งชื่อเช่น ” abc ” และเรียกดังนี้ อย่างไรก็ตาม การตั้งชื่อนี้ไม่ใช่สิ่งที่แน่นอน

a : หมายเลขรุ่นหลัก
b : หมายเลขรุ่นย่อย
c : หมายเลขแพตช์หรือหมายเลขแก้ไข

นอกจากนี้ เวอร์ชันถัดจาก 5.19 คือ 6.0 แต่ไม่ใช่เพราะฟังก์ชันมีการเปลี่ยนแปลงอย่างมาก มันเป็นเพียงเพราะไม่พึงประสงค์ที่ตัวเลข b จะใหญ่เกินไป และเป็นธรรมเนียมที่จะนับ a ขึ้นเมื่อ b ถึงประมาณ 20 และ c เป็นการแก้ไขระดับแพตช์ เช่น การแก้ไขข้อบกพร่อง ด้วยเหตุนี้ จึงเป็นเรื่องปกติที่จะเรียกหมายเลขรุ่นหรือหมายเลขเวอร์ชันว่าเป็นการรวมกันของ ” ab ” หรือ ” abc “

ในแผนภาพต่อไปนี้ Major Release ถูกขีดฆ่าเพราะไม่ค่อยได้ใช้มากนัก แต่ยังคงใช้เมื่อต้องการระบุตัวเลขแรกอย่างชัดเจน

รูปที่ 2 การตั้งชื่อเวอร์ชันเคอร์เนล Linux

ลองดูแผนภาพต่อไปนี้ มันแสดงประวัติการพัฒนาของเคอร์เนล Linux ส่วนที่เป็นสีเทาคือช่วงการพัฒนา และหลังจากช่วงเวลาหนึ่ง การพัฒนาจะย้ายไปยังเวอร์ชันถัดไป กล่าวอีกนัยหนึ่ง การปล่อย Linux เฉพาะ ” abc ” จะทำซ้ำวงจรชีวิตของ “การพัฒนา → การสนับสนุน → LTS (Long Time Support)” ทุก ๆ สองสามปี เคอร์เนล LTS จะปล่อยออกมาปีละครั้ง และได้รับการสนับสนุนประมาณห้าปี

ที่มา: https://en.wikipedia.org/wiki/Linux_kernel_version_history

รูปที่ 3 ประวัติเวอร์ชันเคอร์เนล Linux 6.x

รูปที่ 4 ประวัติเวอร์ชันเคอร์เนล Linux 5.x

การตั้งชื่อของการกระจาย Linux

การตั้งชื่อของการกระจาย Linux และ kernel.org มีความแตกต่างเล็กน้อย เคอร์เนลของการกระจาย Linux ถูกตั้งชื่อเช่น ” abc-z ” แต่ในความเป็นจริง การกระจายส่วนใหญ่มี ” ab0-z ” โดยที่ c เป็นศูนย์ นี่เป็นจริงไม่เพียงแต่สำหรับ RHEL แต่ยังรวมถึง Ubuntu และสำหรับ UEK7 และหลังจากนั้นด้วย

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

รูปที่ 5 ชื่อการกระจาย Linux

คำว่า Base Version เป็นคำใหม่สำหรับแพลตฟอร์ม มันบ่งบอกถึงเวอร์ชัน kernel.org ที่มันอิง อย่างไรก็ตาม ตัวเลข c ถูกบังคับให้เป็นศูนย์ ดังนั้นแม้ว่าเวอร์ชันพื้นฐานจะเป็น 5.15.0 เวอร์ชันเคอร์เนลที่มันอิงไม่จำเป็นต้องเป็น 5.15.0 ตัวอย่างเช่น UEK7 เป็นเวอร์ชัน 5.15.0 แต่จริง ๆ แล้วมันอิงจาก 5.15.6

$ rpm -q --changelog  kernel-uek-5.15.0-105.125.6.2.2.el9uek | tail -n 2
- Linux 5.15.6 (Greg Kroah-Hartman)

ความสัมพันธ์ระหว่าง mainline, longterm, stable และ rc

มาดูหน้าของเคอร์เนล Linux อย่างเป็นทางการกัน The Linux Kernel Archives มีเวอร์ชันเคอร์เนล Linux หลายตัวที่ระบุไว้ พร้อมป้ายกำกับเช่น mainline, longterm, stable และ rc ฉันจะอธิบายแต่ละตัวด้านล่าง

รูปที่ 6 The Linux Kernel Archives

แผนภาพต่อไปนี้แสดงเวอร์ชันเคอร์เนลบางส่วนที่ตัดตอนมาจาก kernel.org พร้อมเพิ่มความเห็น Mainline คือการพัฒนาหลัก เมื่อมี rc (Release candidate) พร้อมใช้งาน มันจะกลายเป็นเวอร์ชันอย่างเป็นทางการ ดังนั้น mainline และ stable หมายถึงสถานะเดียวกัน ในบรรดาเวอร์ชันที่เสถียร ทุก ๆ สองสามเวอร์ชันจะกลายเป็น long-term และได้รับการสนับสนุนเป็นเวลานาน

รูปที่ 7 วงจรชีวิตบน kernel.org

Backporting คืออะไร?

มีคำที่ควรจำที่นี่: backporting Backporting หมายถึงการนำคุณสมบัติหรือการแก้ไขที่มีอยู่ในเวอร์ชันใหม่ของซอฟต์แวร์ไปใช้กับเวอร์ชันเก่าของซอฟต์แวร์

ตัวอย่างเช่น การนำแพตช์ใหม่ที่แนะนำในเวอร์ชัน 6.0 ไปใช้กับเวอร์ชัน 5.0 เรียกว่า backporting โดยทั่วไป ยิ่งความแตกต่างระหว่างสองเวอร์ชันมากเท่าไหร่ ความแตกต่างในฐานโค้ดก็ยิ่งมากขึ้นเท่านั้น ทำให้การใช้งานยากขึ้น นอกจากนี้ ยังมีกรณีที่ข้อบกพร่องที่เป็นปัญหาไม่มีอยู่ในเวอร์ชันเก่า ทำให้ backporting ไม่จำเป็น

บางคนอาจสงสัยว่าสิ่งที่ตรงข้ามกับ backport คืออะไร ตัวอย่างเช่น มันคือกรณีของการนำการแก้ไขข้อบกพร่องจากซอฟต์แวร์เวอร์ชัน 5.0 ไปใช้กับซอฟต์แวร์เวอร์ชัน 6.0 ที่ใหม่กว่า ฉันได้ทำการวิจัย แต่ไม่มีคำศัพท์ทั่วไป และดูเหมือนว่า backport, merging, forward-porting ฯลฯ ถูกใช้ ดูเหมือนว่าหลายคนเรียกมันว่า backport โดยไม่คิดมาก

ข้อความต่อไปนี้เป็นส่วนหนึ่งของคำอธิบายของ UEK ที่แนะนำในตอนต้น

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

เมื่อพิจารณาสิ่งที่เราได้พูดคุยมาจนถึงตอนนี้ Oracle อ้างดังนี้:

• ฐานซอร์สโค้ด mainline ที่ใหม่กว่าน่าจะมีประสิทธิภาพและความเสถียรที่ดีกว่า เพราะมันรวมคุณสมบัติใหม่และการแก้ไขข้อบกพร่องมากขึ้น
• การเริ่มต้นด้วยซอร์สโค้ด mainline ที่ใหม่กว่าหมายถึงมีความแตกต่างในซอร์สโค้ดน้อยลง ดังนั้นจึงต้องการการ backporting น้อยที่สุด

ความรู้พื้นฐานของ Linux ภายใน

หนึ่งในสิ่งที่สำคัญที่สุดที่ต้องรู้เกี่ยวกับ UEK คือความเข้ากันได้กับเคอร์เนล RHEL (RHCK) เพื่อเข้าใจความเข้ากันได้ ความรู้เกี่ยวกับระบบปฏิบัติการ Linux เป็นสิ่งจำเป็น ดังนั้น เราจะอธิบายพื้นฐานของโครงสร้างภายในของ Linux

ส่วนประกอบหลักของระบบปฏิบัติการ Linux

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

• เคอร์เนล Linux
  เคอร์เนลเป็นส่วนประกอบหลักของระบบปฏิบัติการ Linux มันรับคำขอจากแอปพลิเคชันและจัดการกระบวนการและหน่วยความจำเพื่อดำเนินการโปรแกรม มันยังใช้ไดรเวอร์อุปกรณ์ ซึ่งเป็นโมดูลเคอร์เนล เพื่อจัดการระบบไฟล์และควบคุมอุปกรณ์สำหรับ I/O บทบาทของเคอร์เนลสามารถสรุปได้ดังนี้ ควรเข้าใจว่าเป็นฟังก์ชันที่ทำงานกับฮาร์ดแวร์
  • การจัดการทรัพยากรฮาร์ดแวร์สำหรับ CPU, หน่วยความจำ, ดิสก์, การ์ดเครือข่าย ฯลฯ
  • การจัดการและควบคุมกระบวนการสำหรับแอปพลิเคชันที่ทำงานบน Linux
• โมดูลเคอร์เนล
  โมดูลเคอร์เนลเป็นไฟล์ไบนารีที่ขยายฟังก์ชันของเคอร์เนล ส่วนใหญ่เป็นไดรเวอร์อุปกรณ์ และอยู่ในรูปแบบที่สามารถโหลดได้เมื่อต้องการ ช่วยให้สามารถรองรับฮาร์ดแวร์ใหม่ได้โดยเพียงแค่เพิ่มไดรเวอร์ และยังลดการใช้หน่วยความจำ
• ไลบรารีระบบ
  ไลบรารีระบบ (หรือเรียกง่าย ๆ ว่าไลบรารี) เป็นชุดของฟังก์ชันที่โปรแกรมใช้กันทั่วไป โดยให้ฟังก์ชันส่วนใหญ่ที่ระบบปฏิบัติการจัดหาให้ ที่มีชื่อเสียงที่สุดคือ glibc ซึ่งเป็นไลบรารี C มาตรฐานที่ใช้ใน Linux มันถูกเรียกว่า glibc เพราะเดิมพัฒนาโดย GNU ในชื่อ GNU C Library

รูปที่ 8 โครงสร้างภายในของ Linux

เข้าใจพื้นฐาน (ฟังก์ชันไลบรารีและการเรียกระบบ)

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

“ไลบรารี /lib64” /usr/lib ถูกติดตั้งอยู่ใน หากคุณแสดงข้อมูลสัญลักษณ์ของ glibc ด้วยคำสั่ง nm คุณจะเห็นว่ามันมี printf() ข้อมูลสัญลักษณ์หมายถึงฟังก์ชันและตัวแปรที่อยู่ในไลบรารีหรือโปรแกรมที่สามารถรันได้

printf() ทำงานตามที่ระบุในอาร์กิวเมนต์ โดยออกคำสั่งไปยังเคอร์เนลหากจำเป็น

$ rpm -qf /lib64/libc.so.6
glibc-2.34-60.0.3.el9.x86_64

$ nm /lib64/libc.so.6 | grep "T printf"
000000000006f430 T printf
000000000006e8f0 T printf_size
000000000006f350 T printf_size_info

“การเรียกระบบ” ให้ฟังก์ชันเพื่อดำเนินการกับฮาร์ดแวร์ เช่น การป้อน/ส่งออกไฟล์, การสร้างกระบวนการใหม่, การสื่อสารผ่านเครือข่าย ฯลฯ ในรูปที่ 8 การเรียกระบบถูกเรียกโดยตรงจากแอปพลิเคชัน อย่างไรก็ตาม มันยังสามารถเรียกผ่านฟังก์ชันห่อการเรียกระบบที่รวมอยู่ใน glibc ได้

คุณอ่านมาถึงตรงนี้หรือยัง? คุณจะเห็นว่าไลบรารีเช่น glibc มีความสำคัญมาก ด้วยเหตุนี้ การกระจายที่อิงจาก RHEL จะไม่เปลี่ยนเวอร์ชัน glibc จนกว่าเวอร์ชันหลักจะเปลี่ยน

โหมดเคอร์เนลและโหมดผู้ใช้

อธิบายถึง โหมดเคอร์เนล และ โหมดผู้ใช้

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

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

สรุปความรู้พื้นฐาน

มาสรุปพื้นฐานของโครงสร้างภายใน Linux ที่เราได้กล่าวถึงมาจนถึงตอนนี้อย่างสั้น ๆ

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

คอนเทนเนอร์ทำงานอย่างไร

ต่อไป เราจะอธิบายเกี่ยวกับคอนเทนเนอร์ คุณอาจสงสัยว่า “ทำไมต้องคอนเทนเนอร์?” หลังจากอธิบายเกี่ยวกับเคอร์เนล นั่น是因为การเข้าใจว่าคอนเทนเนอร์ทำงานอย่างไรเป็นหัวข้อที่ดีสำหรับการเข้าใจความเข้ากันได้ของเคอร์เนล

โครงสร้างคอนเทนเนอร์

แผนภาพต่อไปนี้เปรียบเทียบการจำลองเสมือนแบบใช้ Hypervisor และแบบใช้คอนเทนเนอร์: เครื่องเสมือนมี Guest OS และเคอร์เนล ในขณะที่คอนเทนเนอร์มีเพียงแอปพลิเคชันและไลบรารี แต่ไม่มีเคอร์เนล

รูปที่ 9 ความแตกต่างระหว่างแบบ Hypervisor และแบบคอนเทนเนอร์

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

รูปที่ 10 คอนเทนเนอร์ทำงานอย่างไร

ความเข้ากันได้ของเคอร์เนล Linux

มีสิ่งสำคัญที่นี่

มันจะทำงานได้แม้ว่าระบบปฏิบัติการที่สร้างภาพคอนเทนเนอร์จะเป็นเวอร์ชัน Linux ที่แตกต่างจาก Host OS

ตัวอย่างเช่น สมมติว่า Host OS ที่รันเครื่องยนต์คอนเทนเนอร์คือ Ubuntu Server 22.04 LTS ในกรณีนี้ แม้ว่าภาพคอนเทนเนอร์จะถูกสร้างด้วย Oracle Linux 9 มันจะทำงานได้ตราบใดที่มีไลบรารีและไบนารีที่จำเป็นรวมอยู่ แม้ว่าทั้งคู่ต้องเป็น Linux พวกมันสามารถทำงานได้แม้ว่าเวอร์ชันเคอร์เนล Linux จะแตกต่างกันเล็กน้อย

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

รูปที่ 11 ความเข้ากันได้ของเคอร์เนล Linux

ให้ฉันอธิบายเพิ่มเติมเล็กน้อย ดูรูปที่ 12 ด้านล่าง อินเทอร์เฟซระหว่างแอปพลิเคชันและเคอร์เนลในระบบเรียก Linux เรียกว่า Application Binary Interface (ABI) เคอร์เนล Linux ถูกพัฒนาโดยคำนึงถึงความเข้ากันได้เพื่อให้ระบบเรียกที่มีอยู่จากเวอร์ชันก่อนหน้าสามารถเรียกได้ด้วยข้อกำหนดเดียวกัน ดังนั้น แม้ว่าเวอร์ชันเคอร์เนล Linux จะแตกต่างกันเล็กน้อย แอปพลิเคชันจะทำงานเหมือนกัน

รูปที่ 12 การรักษาความเข้ากันได้ผ่าน Application Binary Interface

Application Binary Interface (ABI)

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

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

รูปที่ 13 ความเข้ากันได้ที่รักษาโดย ABI

ความไม่เข้ากันที่ควรระวัง

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

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

รูปที่ 14 ความไม่เข้ากันของโมดูลเคอร์เนล

เปรียบเทียบ UEK และ RHCK

ตอนนี้เราได้กล่าวถึงพื้นฐานแล้ว เราสามารถไปยังหัวข้อหลักของการเปรียบเทียบ: ความเข้ากันได้และคุณสมบัติ

ความเข้ากันได้กับ RHCK

นี่คือเรื่องเกี่ยวกับความเข้ากันได้ระหว่าง UEK และ RHCK หากคุณอ่านมาถึงตรงนี้ คุณน่าจะรู้แล้ว UEK ถูกพัฒนาเพื่อรักษาความเข้ากันได้ของ ABI กับ RHCK ดังนั้น หากเป็นแอปพลิเคชันปกติที่ทำงานในโหมดผู้ใช้ มันจะเข้ากันได้

อย่างไรก็ตาม มีบางสิ่งที่ต้องคำนึงถึง

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

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

ไม่มีตัวเลือกซอฟต์แวร์ญี่ปุ่นให้เลือกมากนัก แต่คุณสามารถตรวจสอบความเข้ากันได้ของ Oracle Linux ได้ใน แคตตาล็อก ISV ของ Oracle Linux

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

นอกจากนี้ เนื่องจากเครื่องเซิร์ฟเวอร์ติดตั้งฮาร์ดแวร์พิเศษ เช่น RAID คอนโทรลเลอร์และ NIC ผู้ผลิตอาจจัดหาไดรเวอร์อุปกรณ์ของตัวเอง หากไดรเวอร์ไม่ได้รับการสนับสนุน คุณอาจไม่สามารถใช้งานได้

ตรวจสอบหน้าเว็บของผู้ผลิตหรือ รายการรับรองฮาร์ดแวร์ Oracle Linux เพื่อดูข้อมูลการสนับสนุน ซึ่งรวมถึงข้อมูลเกี่ยวกับการสนับสนุน RHCK และ UEK ด้วย

ความแตกต่างของคุณสมบัติ

มันยากที่จะสรุปความแตกต่างของคุณสมบัติ เพราะมันแตกต่างกันไปตามเวอร์ชันเคอร์เนล แต่โดยทั่วไปแล้ว UEK อิงจากเคอร์เนล mainline ที่ใหม่กว่า ดังนั้นมันมีประสิทธิภาพที่ดีกว่าและมีคุณสมบัติมากกว่า

ตัวอย่างเช่น ใน Oracle Linux 9 เวอร์ชันพื้นฐานของ UEK7 คือ 5.15.0 และเวอร์ชันพื้นฐานของ RHCK คือ 5.14.0 ในจุดนี้ไม่มีความแตกต่างมากนัก อย่างไรก็ตาม ดังที่แสดงในตารางต่อไปนี้ UEK เปลี่ยนแปลงแม้ในเวอร์ชันหลักเดียวกัน ในอีกไม่กี่ปี UEK8 จะถูกปล่อยสำหรับ Oracle Linux 9 และความแตกต่างในเวอร์ชันเคอร์เนลจะกว้างขึ้น

เวอร์ชัน Linux	UEK4	UEK5	UEK6	UEK7
Oracle Linux 9	×	×	×	○
Oracle Linux 8	×	×	○	○
Oracle Linux 7	○	○	○	×

คุณสมบัติที่รู้จักกันดีที่เฉพาะเจาะจงสำหรับ UEK รวมถึง ocfs2 และ btfs มีอื่น ๆ อีก แต่สำหรับรายละเอียด โปรดดู “คุณสมบัติใหม่และการเปลี่ยนแปลง” ใน “บันทึกการปล่อย Unbreakable Enterprise Kernel“

รูปที่ 15 บันทึกการปล่อย Unbreakable Enterprise Kernel Release 7

สรุป: ควรใช้ UEK หรือ RHCK เมื่อใด?

UEK ถูกออกแบบมาสำหรับงาน Oracle Database ขนาดใหญ่และ Oracle Linux KVM และอิงจากเคอร์เนลที่ใหม่กว่า ซึ่งหมายความว่ามันมักจะให้ประสิทธิภาพและคุณสมบัติที่ดีกว่า

อย่างไรก็ตาม UEK ไม่ใช่สิ่งจำเป็นอย่างยิ่ง ฉันเชื่อว่าคุณควรใช้มันตามสถานการณ์และวัตถุประสงค์ ในกรณีต่อไปนี้ 1 และ 2 คุณควรพิจารณาใช้ RHCK สิ่งที่สำคัญคือการเข้าใจความแตกต่างระหว่าง UEK และ RHCK และใช้มันอย่างเหมาะสม ฉันจะแนะนำตารางที่สรุปสิ่งที่ฉันได้อธิบายมาจนถึงตอนนี้ด้วย

1. หากคุณใช้เซิร์ฟเวอร์จริงและผู้ผลิตสนับสนุนเฉพาะ RHCK
   ให้ใช้ RHCK
2. หากคุณใช้ซอฟต์แวร์เชิงพาณิชย์และผู้จำหน่ายสนับสนุนเฉพาะ RHCK
   ควรใช้ RHCK อย่างไรก็ตาม หากคุณใช้ในระบบของคุณเองและสามารถยอมรับความเสี่ยงได้ UEK ก็เป็นตัวเลือกหนึ่ง

ข้อดีและข้อเสียของ UEK เทียบกับ RHCK

รายการ	ข้อดี	ข้อเสีย
ฟังก์ชันและประสิทธิภาพ	ขึ้นอยู่กับว่าเปรียบเทียบ UEK และ RHCK เวอร์ชันใด UEK น่าจะมีคุณสมบัติและประสิทธิภาพที่ดีกว่าเพราะใช้เคอร์เนล mainline ที่ใหม่กว่า และอาจมีการปรับปรุงสำหรับ Oracle Database
ความเข้ากันได้ของแอปพลิเคชันที่ทำงานในโหมดผู้ใช้	เข้ากันได้	ในกรณีของผลิตภัณฑ์แพ็คเกจเชิงพาณิชย์ อาจไม่มีการสนับสนุนขึ้นอยู่กับนโยบายการสนับสนุนของผู้จำหน่าย
โมดูลเคอร์เนลที่ทำงานในโหมดเคอร์เนล	ไดรเวอร์อุปกรณ์ ฯลฯ ที่ให้มาในรูปแบบซอร์สโค้ดน่าจะเข้ากันได้	ซอฟต์แวร์แอนตี้ไวรัสและไดรเวอร์อุปกรณ์ที่ทำงานในโหมดเคอร์เนลโดยทั่วไปไม่เข้ากันได้
อื่น ๆ		เซิร์ฟเวอร์จากผู้ผลิตที่มีชื่อเสียงอาจสนับสนุน Oracle Linux (RHCK) แต่ไม่สนับสนุน UEK