"เราสามารถอัพเกรดเซิร์ฟเวอร์ EL5 ที่ใช้งานจริงของเราเป็น EL6 ได้หรือไม่"

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

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

ฉันไม่ได้พยายามกระตุ้นการตอบสนองเกี่ยวกับการจัดการการกำหนดค่า ("Puppetize ทุกอย่าง " ไม่ได้นำไปใช้เสมอ ) หรือวิธีที่ลูกค้าควรวางแผนได้ดีขึ้น นี่เป็นตัวอย่างจริงของสภาพแวดล้อมที่เติบโตและเจริญเติบโตในความสามารถในการผลิต แต่ไม่เห็นเส้นทางที่สะอาดเพื่อย้ายไปยังระบบปฏิบัติการรุ่นต่อไป

สภาพแวดล้อม A:
องค์กรที่ไม่แสวงหาผลกำไรที่มี40 x Red Hat Enterprise Linux 5.4 และ 5.5เว็บเซิร์ฟเวอร์ฐานข้อมูลและเมลเซิร์ฟเวอร์เรียกใช้จาวาแอปพลิเคชันเว็บ Java, ตัวโหลดบาลานซ์ของซอฟต์แวร์และฐานข้อมูล Postgres ระบบทั้งหมดถูกจำลองเสมือนบน VMWare vSphere สองคลัสเตอร์ในสถานที่ต่างกันโดยแต่ละแห่งมี HA, DRS และอื่น ๆ

สภาพแวดล้อม B:
บริษัท การค้าทางการเงินความถี่สูงที่มีระบบ200 x CentOS 5.xในสถานที่ร่วมหลายแห่งที่ดำเนินงานการค้าการผลิตสนับสนุนการพัฒนาภายในและฟังก์ชั่น Back-office เซิร์ฟเวอร์การค้ากำลังทำงานบนฮาร์ดแวร์เซิร์ฟเวอร์สินค้าโภคภัณฑ์ที่ทำจากโลหะ พวกเขาได้มากมายsysctl.conf, rtctlขัดจังหวะผูกพันและคนขับปรับแต่งในสถานที่เพื่อลดความล่าช้าการส่งข้อความ บางคนมีเมล็ดที่กำหนดเองและ / หรือเรียลไทม์ เวิร์คสเตชั่นสำหรับนักพัฒนานั้นกำลังเรียกใช้ CentOS รุ่นที่คล้ายคลึงกัน

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

• สำหรับ บริษัท ที่ไม่แสวงหาผลกำไรนั้นจะเชื่อมโยงกับ Apache เคอร์เนลและบางสิ่งที่จะทำให้นักพัฒนามีความสุข
• ใน บริษัท การค้ามันเกี่ยวกับการปรับปรุงบางอย่างในเคอร์เนลเครือข่ายสแต็คและ GLIBC ซึ่งจะทำให้นักพัฒนามีความสุข

ทั้งสองอย่างเป็นสิ่งที่ไม่สามารถบรรจุหรืออัปเดตได้ง่ายโดยไม่ต้องเปลี่ยนระบบปฏิบัติการอย่างมาก

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

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

คำตอบที่นี่คืออะไร การแจกแจงอื่น ๆ (.deb-based, Arch และ Gentoo) ดูเหมือนจะมีความสามารถนี้หรือเป็นเส้นทางที่ดีกว่า สมมติว่าเราพบการหยุดทำงานเพื่อทำงานนี้อย่างถูกต้อง :

• ลูกค้าเหล่านี้ควรทำอย่างไรเพื่อหลีกเลี่ยงปัญหาเดียวกันเมื่อ EL7 เปิดตัวและมีเสถียรภาพ?
• หรือเป็นกรณีที่ผู้คนต้องลาออกเพื่อสร้างใหม่ทุกสองสามปีหรือไม่
• สิ่งนี้ดูเหมือนจะแย่ลงเมื่อ Enterprise Linux พัฒนาขึ้น ... หรือฉันแค่จินตนาการมัน
• สิ่งนี้ทำให้ผู้อื่นไม่สามารถใช้ Red Hat และระบบปฏิบัติการอนุพันธ์ได้หรือไม่?

ฉันคิดว่ามันมีมุมการจัดการการกำหนดค่า แต่การติดตั้ง Puppet ส่วนใหญ่ที่ฉันเห็นแปลไม่ดีในสภาพแวดล้อมด้วยแอปพลิเคชันเซิร์ฟเวอร์ที่ปรับแต่งได้สูง ( Environment Bอาจมีเซิร์ฟเวอร์เดียวที่มีifconfigผลลัพธ์เช่นนี้ ) ฉันน่าสนใจในการรับฟังข้อเสนอแนะเกี่ยวกับวิธีการจัดการการกำหนดค่าที่สามารถใช้เพื่อช่วยให้องค์กรสามารถข้ามรุ่นหลักของ RHEL ได้

(หมายเหตุผู้เขียน: คำตอบนี้อ้างถึง RHEL 6 และรุ่นก่อนหน้าตอนนี้ RHEL 7 มีเส้นทางการอัปเกรดที่รองรับอย่างเต็มที่จาก RHEL 6 ซึ่งมีรายละเอียดอยู่ที่ท้าย)

ในการเริ่มต้นฉันควรทราบว่ามีสองวิธีในการอัปเกรดแบบแทนที่:

1. ลดลงในดีวีดีการติดตั้ง (หรือใช้ภาพดีวีดีผ่าน iLO / Idrac) linux upgradeanyบูตจากมันและเลือกอัพเกรดเช่น
2. อัปเดตredhat-releaseRPM ด้วยตนเองเรียกใช้yum distro-sync(นี่คือการปรับให้สั้นลงเล็กน้อย) และรีบูต

วิธีที่ 1 ไม่ได้รับการสนับสนุน วิธีที่ 2 มีไว้สำหรับวัวจริง นอกเหนือจากการติดตั้งใหม่ที่แนะนำฉันได้ทำทั้งสองอย่างนี้ ...

ฉันต้องการความช่วยเหลือหรือไม่?

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

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

ทำไมไม่ทำการอัปเกรดแบบแทนที่?

นี่คือสิ่งที่ Red Hat พูดเกี่ยวกับ :

Red Hat ไม่สนับสนุนการอัปเกรดแบบแทนที่ระหว่าง Red Hat Enterprise Linux เวอร์ชันหลักใด ๆ รุ่นหลักถูกแทนด้วยการเปลี่ยนแปลงทั้งเวอร์ชัน ตัวอย่างเช่น Red Hat Enterprise Linux 5 และ Red Hat Enterprise Linux 6 เป็นทั้งเวอร์ชันหลักของ Red Hat Enterprise Linux

การอัปเกรดแบบแทนที่ในรุ่นใหญ่ ๆ จะไม่เก็บการตั้งค่าระบบบริการหรือการกำหนดค่าแบบกำหนดเองทั้งหมดไว้ ดังนั้น Red Hat ขอแนะนำให้ติดตั้งใหม่เมื่ออัพเกรดจากรุ่นหลักหนึ่งเป็นรุ่นอื่น

พวกเขาเตือนเพิ่มเติม:

อย่างไรก็ตามโปรดสังเกตข้อ จำกัด ต่อไปนี้ก่อนที่คุณจะเลือกอัพเกรดระบบของคุณ:

• ไฟล์การกำหนดค่าแพคเกจส่วนบุคคลอาจหรืออาจไม่ทำงานหลังจากทำการอัปเกรดเนื่องจากการเปลี่ยนแปลงในรูปแบบไฟล์หรือรูปแบบการกำหนดค่าต่างๆ
• หากคุณมีผลิตภัณฑ์ชั้นหนึ่งของ Red Hat (เช่น Cluster Suite) ที่ติดตั้งไว้อาจต้องอัปเกรดด้วยตนเองหลังจากการอัปเกรด Red Hat Enterprise Linux เสร็จสิ้นแล้ว
• แอปพลิเคชันบุคคลที่สามหรือ ISV อาจทำงานไม่ถูกต้องหลังจากการอัพเกรด

แน่นอนว่าพวกเขาจะอธิบายวิธีการอัปเกรดแบบแทนที่ด้วยวิธีที่ 1 ในกรณีที่คุณต้องการทำเช่นนั้นจริงๆ มีคุณสมบัติอยู่และ Red Hat ใช้เวลาในการพัฒนาดังนั้นจึงได้รับการสนับสนุนในคุณลักษณะนี้ แต่ถ้ามีอะไรผิดพลาด Red Hat จะบอกให้คุณติดตั้งใหม่ พวกเขาจะไม่ให้การสนับสนุนผู้ขายสำหรับสิ่งที่แตกเป็นผลมาจากการอัพเกรด

สำหรับบันทึกฉันไม่เคยมีปัญหากับการอัพเกรด RHEL / CentOS หรือ Fedora ในระบบที่ฉันไม่สามารถแก้ไขได้ ปัญหาทั่วไปมาจากแพ็คเกจที่ถูกเปลี่ยนชื่อคลังเก็บข้อมูลของบุคคลที่สามและรุ่นที่ไม่ตรงกันระหว่างสถาปัตยกรรม i386 และ x86_64 ของแพ็คเกจ ตัวติดตั้งค่อนข้างดีกว่าในการจัดการสิ่งเหล่านี้yumฉันคิดว่า

ฉันจะอัพเกรดได้อย่างไร

โดยทั่วไปฉันเตือนผู้คนว่าพวกเขาควรวางแผนในหน้าต่างการบำรุงรักษาทุกๆ 3-4 ปีเพื่ออัปเดตระบบ RHEL จากรุ่นหลักหนึ่งไปยังรุ่นถัดไป ในขณะที่การอัพเกรดโดยทั่วไปเป็นไปอย่างราบรื่นสิ่งที่ไม่คาดคิดสามารถเกิดขึ้นได้เสมอ

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

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

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

การสลับการแจกแจงจะช่วยหรือไม่

การแจกแจงแบบเดเบียนมีวิธีอัปเกรดแบบแทนที่และส่วนใหญ่ใช้งานได้ แต่ไม่ได้รับการยกเว้นจากปัญหา สิ่งต่าง ๆ มากมายสำหรับผู้ที่อัพเกรดจาก Ubuntu 10.04 LTS เป็น 12.04 LTSผ่านวิธีการที่รองรับเช่น ไม่ชัดเจนว่า Debian หรือ Canonical กำลังใส่เวลาในการพัฒนาเพียงพอในการ "สนับสนุน" คุณสมบัตินี้เช่นทำให้แน่ใจว่ามันใช้งานได้ และคุณยังต้องซื้อการสนับสนุนจากผู้จำหน่ายสำหรับการแจกจ่ายนี้หากคุณต้องการให้ใครสักคนกุมมือคุณไว้ ดังนั้นฉันสงสัยว่าคุณจะได้รับมากจากการเปลี่ยนเป็นการกระจาย

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

อนาคตจะมีอะไร

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

CentOS ยังทำการทดลองกับพื้นที่เก็บข้อมูลแบบโรลลิ่ง แต่มันใช้เฉพาะระหว่างรุ่นรอง (เช่น 6.3-6.4)

ฉันใช้เวลาในย่อหน้าสุดท้ายของคุณ:

ฉันคิดว่ามันมีมุมการจัดการการกำหนดค่า แต่การติดตั้ง Puppet ส่วนใหญ่ที่ฉันเห็นแปลไม่ดีในสภาพแวดล้อมด้วยแอปพลิเคชันเซิร์ฟเวอร์ที่ปรับแต่งได้สูง (Environment B อาจมีเซิร์ฟเวอร์เดียวซึ่งมีเอาต์พุต ifconfig มีลักษณะเช่นนี้) ฉันน่าสนใจในการรับฟังข้อเสนอแนะเกี่ยวกับวิธีการจัดการการกำหนดค่าที่สามารถใช้เพื่อช่วยให้องค์กรสามารถข้ามรุ่นหลักของ RHEL ได้

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

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

PS ฉันไม่แน่ใจว่าสิ่งที่สำคัญเกี่ยวกับเอาท์พุท ifconfig ในบริบทนี้ - มันถูกสร้างขึ้นโดยไฟล์การกำหนดค่าและสคริปต์บางอย่าง