การแนะนำ

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

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

ขณะนี้ฝ่ายบริหารได้อนุญาตแล้ว เปิดโครงการสู่ชุมชนโอเพ่นซอร์สภายใต้ใบอนุญาต MIT. README จะได้รับการแปลเป็นภาษาอังกฤษเร็วๆ นี้ (เนื่องจากคาดว่าผู้บริโภคหลักจะเป็นนักพัฒนา Pacemaker และ PostgreSQL) และฉันตัดสินใจนำเสนอ README เวอร์ชันรัสเซียเก่า (บางส่วน) ในรูปแบบของบทความนี้

คลัสเตอร์ถูกปรับใช้บนเครื่องเสมือน VirtualBox. เครื่องเสมือนทั้งหมด 12 เครื่อง (รวมทั้งหมด 36GiB) จะถูกใช้งาน ซึ่งสร้างคลัสเตอร์ที่ทนทานต่อข้อผิดพลาด 4 กลุ่ม (ตัวเลือกที่แตกต่างกัน) สองคลัสเตอร์แรกประกอบด้วยเซิร์ฟเวอร์ PostgreSQL สองเซิร์ฟเวอร์ ซึ่งตั้งอยู่ในศูนย์ข้อมูลที่แตกต่างกัน และเซิร์ฟเวอร์ทั่วไปหนึ่งตัว พยาน c อุปกรณ์องค์ประชุม (โฮสต์บนเครื่องเสมือนราคาถูกในศูนย์ข้อมูลแห่งที่สาม) ซึ่งแก้ไขความไม่แน่นอน 50% / 50%โดยการลงคะแนนเสียงให้กับฝ่ายใดฝ่ายหนึ่ง คลัสเตอร์ที่สามในศูนย์ข้อมูลสามแห่ง: หนึ่งหลัก สองทาส ไม่ใช่ อุปกรณ์องค์ประชุม. คลัสเตอร์ที่สี่ประกอบด้วยเซิร์ฟเวอร์ PostgreSQL สี่เซิร์ฟเวอร์ โดยสองเซิร์ฟเวอร์ต่อศูนย์ข้อมูล: หนึ่งเซิร์ฟเวอร์หลัก ส่วนที่เหลือจำลอง และยังใช้ พยาน c อุปกรณ์องค์ประชุม. ตัวที่สี่สามารถทนต่อความล้มเหลวของเซิร์ฟเวอร์สองตัวหรือศูนย์ข้อมูลหนึ่งแห่งได้ โซลูชันนี้สามารถปรับขนาดเป็นแบบจำลองจำนวนมากขึ้นได้หากจำเป็น

บริการเวลาที่แม่นยำ เอ็นทีพีดี ได้รับการกำหนดค่าใหม่สำหรับความทนทานต่อข้อผิดพลาด แต่จะใช้วิธีการนั้นเอง ntpd (โหมดเด็กกำพร้า). เซิร์ฟเวอร์ที่ใช้ร่วมกัน พยาน ทำหน้าที่เป็นเซิร์ฟเวอร์ NTP ส่วนกลาง โดยกระจายเวลาไปยังคลัสเตอร์ทั้งหมด จึงประสานเซิร์ฟเวอร์ทั้งหมดเข้าด้วยกัน ถ้า พยาน ล้มเหลวหรือถูกแยกออกจากกัน จากนั้นเซิร์ฟเวอร์คลัสเตอร์ตัวใดตัวหนึ่ง (ภายในคลัสเตอร์) จะเริ่มกระจายเวลา แคชเสริม พร็อกซี HTTP ยกให้เป็นเช่นกัน พยานด้วยความช่วยเหลือดังกล่าว เครื่องเสมือนอื่นๆ จึงสามารถเข้าถึงพื้นที่เก็บข้อมูลของ Yum ได้ ในความเป็นจริง บริการต่างๆ เช่น เวลาที่แม่นยำและพรอกซี มักจะโฮสต์บนเซิร์ฟเวอร์เฉพาะ แต่ในบูธ บริการเหล่านั้นจะโฮสต์บน พยาน เพียงเพื่อประหยัดจำนวนเครื่องเสมือนและพื้นที่

รุ่น

v0. ทำงานร่วมกับ CentOS 7 และ PostgreSQL 11 บน VirtualBox 6.1

โครงสร้างคลัสเตอร์

คลัสเตอร์ทั้งหมดได้รับการออกแบบให้ตั้งอยู่ในศูนย์ข้อมูลหลายแห่ง รวมกันเป็นเครือข่ายเดี่ยว และต้องทนต่อความล้มเหลวหรือการแยกเครือข่ายของศูนย์ข้อมูลเดียว นั่นเป็นเหตุผล เป็นไปไม่ได้ ใช้สำหรับป้องกัน แบ่งสมอง เทคโนโลยีเครื่องกระตุ้นหัวใจมาตรฐานที่เรียกว่า สโตนิธ (ยิงโหนดอื่นในหัว) หรือ รั้ว. สาระสำคัญ: หากโหนดในคลัสเตอร์เริ่มสงสัยว่ามีบางอย่างผิดปกติกับบางโหนด โหนดนั้นไม่ตอบสนองหรือทำงานไม่ถูกต้อง จากนั้นพวกเขาจะบังคับให้ปิดมันผ่านอุปกรณ์ "ภายนอก" เช่น การ์ดควบคุม IPMI หรือ UPS . แต่จะใช้ได้เฉพาะในกรณีที่เกิดความล้มเหลวเพียงครั้งเดียว เซิร์ฟเวอร์ IPMI หรือ UPS ยังคงทำงานต่อไป ที่นี่เราวางแผนที่จะป้องกันความล้มเหลวที่ร้ายแรงยิ่งขึ้น เมื่อศูนย์ข้อมูลทั้งหมดล้มเหลว (เช่น สูญเสียพลังงาน) และด้วยการปฏิเสธทุกอย่าง หินแข็ง- อุปกรณ์ (IPMI, UPS ฯลฯ ) จะไม่ทำงานเช่นกัน

แต่ระบบจะยึดตามแนวคิดเรื่ององค์ประชุมแทน โหนดทั้งหมดมีเสียง และมีเพียงโหนดที่มองเห็นมากกว่าครึ่งหนึ่งของโหนดทั้งหมดเท่านั้นที่สามารถทำงานได้ ปริมาณของ “ครึ่ง + 1” นี้เรียกว่า องค์ประชุม. หากไม่ถึงองค์ประชุม โหนดจะตัดสินใจว่าอยู่ในการแยกเครือข่ายและต้องปิดทรัพยากร เช่น นี่คือสิ่งที่มันเป็น การป้องกันสมองแยก. หากซอฟต์แวร์ที่รับผิดชอบพฤติกรรมนี้ใช้งานไม่ได้ เช่น หน่วยงานเฝ้าระวังซึ่งใช้ IPMI จะต้องทำงาน

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

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

Tuchanka1 (วงจรที่มีการบดอัด)

โครงสร้าง

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

ศูนย์ข้อมูลแต่ละแห่งมีเซิร์ฟเวอร์เดียว แต่ละเซิร์ฟเวอร์มีอินสแตนซ์ PostgreSQL สองอินสแตนซ์ (ในคำศัพท์ของ PostgreSQL เรียกว่าคลัสเตอร์ แต่เพื่อหลีกเลี่ยงความสับสน ฉันจะเรียกอินสแตนซ์เหล่านั้นว่าอินสแตนซ์ (โดยการเปรียบเทียบกับฐานข้อมูลอื่น) และฉันจะเรียกเฉพาะคลัสเตอร์ Pacemaker เท่านั้น) อินสแตนซ์หนึ่งทำงานในโหมดหลัก และให้บริการเท่านั้น (เฉพาะ IP ลอยเท่านั้นที่นำไปสู่อินสแตนซ์) อินสแตนซ์ที่สองทำงานเป็นทาสสำหรับศูนย์ข้อมูลที่สอง และจะให้บริการเฉพาะในกรณีที่ต้นแบบล้มเหลว เนื่องจากโดยส่วนใหญ่แล้วมีเพียงอินสแตนซ์เดียวจากสองอินสแตนซ์เท่านั้นที่จะให้บริการ (ดำเนินการตามคำขอ) ทรัพยากรเซิร์ฟเวอร์ทั้งหมดจึงได้รับการปรับให้เหมาะสมสำหรับต้นแบบ (หน่วยความจำได้รับการจัดสรรสำหรับแคช shared_buffers เป็นต้น) แต่เพื่อให้อินสแตนซ์ที่สอง ยังมีทรัพยากรเพียงพอ ( แม้ว่าการดำเนินการจะไม่เหมาะสมผ่านแคชของระบบไฟล์) ในกรณีที่ศูนย์ข้อมูลแห่งใดแห่งหนึ่งล้มเหลว สเลฟไม่ได้ให้บริการ (ไม่ดำเนินการร้องขอแบบอ่านอย่างเดียว) ในระหว่างการดำเนินการปกติของคลัสเตอร์ ดังนั้นจึงไม่มีสงครามแย่งชิงทรัพยากรกับต้นแบบบนเครื่องเดียวกัน

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

ความล้มเหลวในการเป็นพยาน

ความล้มเหลวในการเป็นพยาน (อุปกรณ์องค์ประชุม) ฉันจะพิจารณาเฉพาะกลุ่ม Tuchanka1 เท่านั้น ส่วนกลุ่มอื่นๆ ทั้งหมดจะเป็นเรื่องเดียวกัน หากพยานล้มเหลว จะไม่มีอะไรเปลี่ยนแปลงในโครงสร้างคลัสเตอร์ ทุกอย่างจะยังคงทำงานเหมือนเดิม แต่องค์ประชุมจะกลายเป็น 2 ใน 3 ดังนั้นความล้มเหลวใดๆ ที่ตามมาจะส่งผลร้ายแรงต่อคลัสเตอร์ ยังคงต้องได้รับการแก้ไขอย่างเร่งด่วน

Tuchanka1 ปฏิเสธ

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

Tuchanka2 (คลาสสิค)

โครงสร้าง

รูปแบบคลาสสิกของสองโหนด นายทำงานที่หนึ่ง ทาสทำงานที่สอง ทั้งสองสามารถดำเนินการตามคำขอได้ (ทาสเป็นแบบอ่านอย่างเดียว) ดังนั้นทั้งสองจึงถูกชี้ไปที่ IP ลอยตัว: krogan2 คือมาสเตอร์, krogan2s1 คือทาส ทั้งนายและทาสจะมีความอดทนต่อความผิด

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

Tuchanka2 ปฏิเสธ

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

Tuchanka4 (ทาสมากมาย)

โครงสร้าง

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

คุณลักษณะอีกประการหนึ่งของโครงร่างนี้คือสามารถจัดระเบียบการจำลองแบบซิงโครนัสหนึ่งรายการได้แล้ว หากเป็นไปได้ มีการกำหนดค่าให้จำลองข้อมูลไปยังศูนย์ข้อมูลอื่น แทนที่จะจำลองในศูนย์ข้อมูลเดียวกันกับศูนย์ข้อมูลหลัก มาสเตอร์และทาสแต่ละคนจะถูกชี้ไปโดย IP แบบลอย โชคดีที่ระหว่างทาสนั้นจำเป็นต้องสร้างสมดุลระหว่างคำขอ พร็อกซี sqlตัวอย่างเช่น ในฝั่งไคลเอ็นต์ ลูกค้าประเภทต่างๆ อาจต้องการประเภทที่แตกต่างกัน พร็อกซี sqlและมีเพียงนักพัฒนาลูกค้าเท่านั้นที่รู้ว่าใครต้องการสิ่งใด ฟังก์ชันนี้สามารถใช้งานได้โดย daemon ภายนอกหรือโดยไลบรารีไคลเอ็นต์ (พูลการเชื่อมต่อ) ฯลฯ ทั้งหมดนี้นอกเหนือไปจากหัวข้อคลัสเตอร์ฐานข้อมูลเมื่อเกิดข้อผิดพลาด (failover พร็อกซี SQL สามารถนำไปใช้ได้อย่างอิสระ ร่วมกับการยอมรับข้อผิดพลาดของลูกค้า)

Tuchanka4 ปฏิเสธ

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

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

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

Tuchanka3 (ศูนย์ข้อมูล 3 แห่ง)

โครงสร้าง

นี่คือคลัสเตอร์สำหรับสถานการณ์ที่มีศูนย์ข้อมูลที่ทำงานได้เต็มรูปแบบสามแห่ง โดยแต่ละศูนย์มีเซิร์ฟเวอร์ฐานข้อมูลที่ทำงานเต็มรูปแบบ ในกรณีนี้ อุปกรณ์องค์ประชุม ไม่ต้องการ. ศูนย์ข้อมูลแห่งหนึ่งมีเจ้าหน้าที่ประจำการ ส่วนอีก 1 แห่งมีเจ้าหน้าที่ประจำการ การจำลองแบบเป็นแบบซิงโครนัส พิมพ์ ANY (slave2, Slave4) นั่นคือ ไคลเอ็นต์จะได้รับการยืนยันการคอมมิต เมื่อทาสใด ๆ เป็นคนแรกที่ตอบกลับว่าเขายอมรับการคอมมิต ทรัพยากรจะถูกระบุโดยหนึ่ง IP ลอยสำหรับหลักและสองสำหรับทาส ต่างจาก TuchankaXNUMX ตรงที่ IP ทั้งสามแบบลอยนั้นทนทานต่อข้อผิดพลาด หากต้องการปรับสมดุลการสืบค้น SQL แบบอ่านอย่างเดียวที่คุณสามารถใช้ได้ พร็อกซี sql (โดยมีความทนทานต่อข้อผิดพลาดแยกต่างหาก) หรือกำหนด IP ทาสฟลอยด์หนึ่งตัวให้กับไคลเอ็นต์ครึ่งหนึ่ง และอีกครึ่งหนึ่งให้กับ IP ที่สอง

Tuchanka3 ปฏิเสธ

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

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

ระบบทดสอบอัตโนมัติ

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

test/failure 2 3

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

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

1. สถิติการทดสอบจะแสดงที่นี่ คอลัมน์:
   • ความล้มเหลว — ชื่อของการทดสอบ (ฟังก์ชันในสคริปต์) ที่จำลองข้อบกพร่อง
   • ปฏิกิริยา — เวลาเฉลี่ยทางคณิตศาสตร์เป็นวินาทีในระหว่างที่คลัสเตอร์กู้คืนฟังก์ชันการทำงาน โดยจะวัดตั้งแต่เริ่มต้นสคริปต์ที่จำลองข้อผิดพลาดจนถึงช่วงเวลาที่คลัสเตอร์กู้คืนฟังก์ชันการทำงานและสามารถให้บริการต่อไปได้ หากเวลาสั้นมาก เช่น หกวินาที (สิ่งนี้เกิดขึ้นในกลุ่มที่มีทาสหลายตัว (Tuchanka3 และ Tuchanka4)) หมายความว่าข้อผิดพลาดนั้นเกิดขึ้นที่ทาสแบบอะซิงโครนัสและไม่ส่งผลกระทบต่อประสิทธิภาพ แต่อย่างใด ไม่มี สวิตช์สถานะคลัสเตอร์
   • การเบี่ยงเบน — แสดงสเปรด (ความแม่นยำ) ของมูลค่า ปฏิกิริยา โดยใช้วิธีส่วนเบี่ยงเบนมาตรฐาน
   • นับ - ทำการทดสอบนี้กี่ครั้ง
2. บันทึกแบบสั้นช่วยให้คุณประเมินสิ่งที่คลัสเตอร์กำลังทำอยู่ในปัจจุบันได้ หมายเลขการวนซ้ำ (ทดสอบ) การประทับเวลา และชื่อของการดำเนินการจะปรากฏขึ้น การวิ่งนานเกินไป (> 5 นาที) บ่งชี้ถึงปัญหา
3. หัวใจ (หัวใจ) - เวลาปัจจุบัน สำหรับการประเมินประสิทธิภาพด้วยภาพ ปรมาจารย์ เวลาปัจจุบันจะถูกเขียนลงในตารางอย่างต่อเนื่องโดยใช้ float IP master หากสำเร็จ ผลลัพธ์จะแสดงในแผงนี้
4. ชนะ (พัลส์) - "เวลาปัจจุบัน" ซึ่งสคริปต์บันทึกไว้ก่อนหน้านี้ หัวใจ ถึงผู้เชี่ยวชาญตอนนี้อ่านจาก ทาส ผ่าน IP ลอยตัว ช่วยให้คุณประเมินประสิทธิภาพของทาสและการจำลองแบบด้วยสายตา ใน Tuchanka1 ไม่มีทาสที่มี IP แบบลอย (ไม่มีทาสที่ให้บริการ) แต่มีสองอินสแตนซ์ (DB) ดังนั้นจึงจะไม่แสดงที่นี่ ชนะและ หัวใจ ตัวอย่างที่สอง
5. การตรวจสอบความสมบูรณ์ของคลัสเตอร์โดยใช้ยูทิลิตี้ pcs mon. แสดงโครงสร้าง การกระจายทรัพยากรข้ามโหนด และข้อมูลที่เป็นประโยชน์อื่นๆ
6. การตรวจสอบระบบจากเครื่องเสมือนแต่ละเครื่องในคลัสเตอร์จะแสดงที่นี่ อาจมีแผงดังกล่าวมากกว่านี้ ขึ้นอยู่กับจำนวนเครื่องเสมือนที่คลัสเตอร์มี สองกราฟ ซีพียูโหลด (เครื่องเสมือนมีโปรเซสเซอร์สองตัว) ชื่อเครื่องเสมือน โหลดระบบ (ชื่อ Load Average เนื่องจากมีค่าเฉลี่ยมากกว่า 5, 10 และ 15 นาที) ประมวลผลข้อมูลและการจัดสรรหน่วยความจำ
7. ร่องรอยของสคริปต์ที่ทำการทดสอบ ในกรณีที่เกิดความผิดปกติ - การหยุดชะงักของการทำงานกะทันหันหรือรอบการรอคอยที่ไม่มีที่สิ้นสุด - คุณสามารถดูสาเหตุของพฤติกรรมนี้ได้ที่นี่

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

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

1. เรียกใช้ฟังก์ชันที่จำลองข้อผิดพลาด
2. พร้อม? — กำลังรอให้คลัสเตอร์ได้รับการกู้คืน (เมื่อมีการให้บริการทั้งหมด)
3. แสดงการหมดเวลาการกู้คืนคลัสเตอร์ (ปฏิกิริยา).
4. แก้ไขปัญหา — คลัสเตอร์กำลัง "ซ่อมแซม" หลังจากนั้นควรกลับสู่สถานะการทำงานเต็มรูปแบบและเตรียมพร้อมสำหรับการทำงานผิดพลาดครั้งต่อไป

นี่คือรายการการทดสอบพร้อมคำอธิบายสิ่งที่พวกเขาทำ:

• ฟอร์คบอมบ์: สร้าง "หน่วยความจำไม่เพียงพอ" โดยใช้ระเบิดส้อม
• นอกอวกาศ: ฮาร์ดไดรฟ์เต็ม แต่การทดสอบค่อนข้างเป็นเชิงสัญลักษณ์ ด้วยโหลดที่ไม่มีนัยสำคัญซึ่งสร้างขึ้นระหว่างการทดสอบ PostgreSQL มักจะไม่ล้มเหลวเมื่อฮาร์ดไดรฟ์เต็ม
• Postgres-ฆ่า: ฆ่า PostgreSQL ด้วยคำสั่ง killall -KILL postgres.
• Postgres-หยุด: แฮงค์คำสั่ง PostgreSQL killall -STOP postgres.
• หมดแรง: “ยกเลิกการรวมพลัง” เครื่องเสมือนด้วยคำสั่ง VBoxManage controlvm "виртуалка" poweroff.
• รีเซ็ต: โอเวอร์โหลดเครื่องเสมือนด้วยคำสั่ง VBoxManage controlvm "виртуалка" reset.
• SBD-หยุด: ระงับปีศาจ SBD ด้วยคำสั่ง killall -STOP sbd.
• ปิดตัวลง: ส่งคำสั่งไปยังเครื่องเสมือนผ่าน SSH systemctl poweroff,ระบบปิดตัวลงอย่างสวยงาม
• ยกเลิกการเชื่อมโยง: การแยกเครือข่าย, คำสั่ง VBoxManage controlvm "виртуалка" setlinkstate1 off.

เสร็จสิ้นการทดสอบโดยใช้คำสั่ง tmux มาตรฐาน "kill-window" Ctrl-b &หรือคำสั่ง "detach-client" Ctrl-b d: ณ จุดนี้การทดสอบสิ้นสุดลง, tmux ปิด, เครื่องเสมือนถูกปิด

ปัญหาที่พบในระหว่างการทดสอบ

• ณ ตอนนี้ สุนัขเฝ้าบ้านปีศาจ sbd ทำงานในการหยุด daemons ที่สังเกตได้ แต่จะไม่แช่แข็งพวกมัน และเป็นผลให้เกิดข้อผิดพลาดที่นำไปสู่การแช่แข็งเท่านั้น โคโรซิงค์ и ม้านำแต่ไม่ได้แขวน SBD. สำหรับเช็ค โคโรซิงค์ มีอยู่แล้ว ประชาสัมพันธ์#83 (บน GitHub ที่ SBD), ยอมรับในเธรด เจ้านาย. พวกเขาสัญญา (ใน PR#83) ว่าจะมีบางสิ่งที่คล้ายกันสำหรับ Pacemaker ฉันหวังว่าภายในนั้น RedHat8 จะทำ. แต่ “ความผิดปกติ” ดังกล่าวเป็นการคาดเดาและสามารถจำลองแบบเทียมได้อย่างง่ายดายโดยใช้ ตัวอย่างเช่น killall -STOP corosyncแต่ไม่เคยเจอในชีวิตจริง

• У ม้านำ ในเวอร์ชั่นสำหรับ 7 CentOS ตั้งค่าไม่ถูกต้อง sync_timeout у อุปกรณ์องค์ประชุม, ผลที่ตามมา หากโหนดหนึ่งล้มเหลว อาจมีความเป็นไปได้บางประการที่โหนดที่สองจะรีบูตด้วยซึ่งนายควรจะย้ายไป หายขาดโดยการขยาย sync_timeout у อุปกรณ์องค์ประชุม ระหว่างการใช้งาน (ใน script setup/setup1). การแก้ไขนี้ไม่ได้รับการยอมรับจากนักพัฒนา ม้านำแต่พวกเขาสัญญาว่าจะออกแบบโครงสร้างพื้นฐานใหม่ในลักษณะ (ในอนาคตที่ไม่ระบุรายละเอียด) ที่จะคำนวณการหมดเวลานี้โดยอัตโนมัติ

• หากการกำหนดค่าฐานข้อมูลระบุไว้ว่า LC_MESSAGES (ข้อความ) สามารถใช้ Unicode ได้ เช่น ru_RU.UTF-8จากนั้นเมื่อเริ่มต้น postgres ในสภาพแวดล้อมที่โลแคลไม่ใช่ UTF-8 ให้พูดในสภาพแวดล้อมที่ว่างเปล่า (ที่นี่ ม้านำ+pgsqlms(paf) วิ่ง postgres) แล้ว บันทึกจะมีเครื่องหมายคำถามแทนตัวอักษร UTF-8. นักพัฒนา PostgreSQL ยังไม่ตกลงว่าควรทำอย่างไรในกรณีนี้ มีค่าใช้จ่ายคุณต้องติดตั้ง LC_MESSAGES=en_US.UTF-8 เมื่อกำหนดค่า (สร้าง) อินสแตนซ์ฐานข้อมูล

• หากตั้งค่า wal_receiver_timeout (โดยค่าเริ่มต้นคือ 60 วินาที) ดังนั้นในระหว่างการทดสอบ PostgreSQL-STOP บนต้นแบบในคลัสเตอร์ tuchanka3 และ tuchanka4 การจำลองแบบไม่ได้เชื่อมต่อกับต้นแบบใหม่อีกครั้ง. การจำลองแบบมีการซิงโครนัส ดังนั้นไม่เพียงแต่ทาสหยุดเท่านั้น แต่ยังรวมถึงต้นแบบใหม่ด้วย แก้ไขได้โดยการตั้งค่า wal_receiver_timeout=0 เมื่อกำหนดค่า PostgreSQL

• ในบางครั้ง ฉันสังเกตเห็นว่าการจำลองแบบค้างใน PostgreSQL ในการทดสอบ ForkBomb (หน่วยความจำล้น) หลังจาก ForkBomb บางครั้งทาสอาจไม่เชื่อมต่อกับมาสเตอร์ใหม่อีกครั้ง. ฉันพบสิ่งนี้เฉพาะในคลัสเตอร์ tuchanka3 และ tuchanka4 เท่านั้น ซึ่งต้นแบบหยุดทำงานเนื่องจากการจำลองแบบซิงโครนัส ปัญหาหายไปเองหลังจากเวลาผ่านไปนาน (ประมาณสองชั่วโมง) จำเป็นต้องมีการวิจัยเพิ่มเติมเพื่อแก้ไขปัญหานี้ อาการจะคล้ายกับจุดบกพร่องครั้งก่อน ซึ่งมีสาเหตุมาจากสาเหตุอื่น แต่ให้ผลลัพธ์ที่ตามมาเช่นเดียวกัน

ภาพโครแกนนำมาจาก ศิลปะเบี่ยงเบน โดยได้รับอนุญาตจากผู้เขียน:

ที่มา: will.com