หลายๆ คนคุ้นเคยกับ PostgreSQL DBMS และได้พิสูจน์ตัวเองแล้วในการติดตั้งขนาดเล็ก อย่างไรก็ตาม แนวโน้มของ Open Source มีความชัดเจนมากขึ้น แม้ว่าจะเป็นเรื่องของบริษัทขนาดใหญ่และข้อกำหนดขององค์กรก็ตาม ในบทความนี้ เราจะบอกวิธีรวม Postgres เข้ากับสภาพแวดล้อมขององค์กร และแบ่งปันประสบการณ์ของเราในการสร้างระบบสำรองข้อมูล (BSS) สำหรับฐานข้อมูลนี้โดยใช้ระบบสำรองข้อมูลของ Commvault เป็นตัวอย่าง
PostgreSQL ได้พิสูจน์คุณค่าของมันแล้ว - DBMS ใช้งานได้ดี มีการใช้งานโดยธุรกิจดิจิทัลที่ทันสมัย เช่น Alibaba และ TripAdvisor และการไม่มีค่าธรรมเนียมใบอนุญาตทำให้เป็นทางเลือกที่น่าดึงดูดสำหรับสัตว์ประหลาดอย่าง MS SQL หรือ Oracle DB แต่ทันทีที่เราเริ่มคิดถึง PostgreSQL ในรูปแบบ Enterprise เราก็พบกับข้อกำหนดที่เข้มงวดทันที: “แล้วความทนทานต่อข้อผิดพลาดในการกำหนดค่าล่ะ? ต้านทานภัยพิบัติ? การตรวจสอบที่ครอบคลุมอยู่ที่ไหน? แล้วการสำรองข้อมูลอัตโนมัติล่ะ? แล้วการใช้ไลบรารีเทปทั้งโดยตรงและบนที่จัดเก็บข้อมูลสำรองล่ะ”
ประการหนึ่ง PostgreSQL ไม่มีเครื่องมือสำรองข้อมูลในตัว เช่น DBMS “สำหรับผู้ใหญ่” เช่น RMAN ใน Oracle DB หรือ SAP Database Backup ในทางกลับกัน ซัพพลายเออร์ของระบบสำรองข้อมูลขององค์กร (Veeam, Veritas, Commvault) แม้ว่าพวกเขาจะรองรับ PostgreSQL แต่จริงๆ แล้วพวกเขาจะทำงานกับการกำหนดค่าบางอย่างเท่านั้น (โดยปกติจะเป็นแบบสแตนด์อโลน) และด้วยชุดข้อจำกัดต่างๆ
ระบบสำรองข้อมูลที่ออกแบบมาเป็นพิเศษสำหรับ PostgreSQL เช่น Barman, Wal-g, pg_probackup ได้รับความนิยมอย่างมากในการติดตั้งขนาดเล็กของ PostgreSQL DBMS หรือในกรณีที่ไม่จำเป็นต้องสำรองข้อมูลจำนวนมากขององค์ประกอบอื่นๆ ของภูมิทัศน์ด้าน IT ตัวอย่างเช่น นอกเหนือจาก PostgreSQL แล้ว โครงสร้างพื้นฐานยังอาจรวมถึงเซิร์ฟเวอร์จริงและเสมือน, OpenShift, Oracle, MariaDB, Cassandra เป็นต้น ขอแนะนำให้สำรองข้อมูลทั้งหมดนี้ด้วยเครื่องมือทั่วไป การติดตั้งโซลูชันแยกต่างหากสำหรับ PostgreSQL โดยเฉพาะเป็นความคิดที่ไม่ดี: ข้อมูลจะถูกคัดลอกไปที่ใดที่หนึ่งไปยังดิสก์ จากนั้นจะต้องลบออกไปยังเทป การสำรองข้อมูลสองครั้งนี้จะเพิ่มเวลาการสำรองข้อมูล และเวลาการกู้คืนที่สำคัญยิ่งกว่านั้นด้วย
ในโซลูชันระดับองค์กร การสำรองข้อมูลการติดตั้งจะเกิดขึ้นกับโหนดจำนวนหนึ่งในคลัสเตอร์เฉพาะ ในเวลาเดียวกัน ตัวอย่างเช่น Commvault สามารถทำงานกับคลัสเตอร์แบบสองโหนดเท่านั้น โดยที่โหนดหลักและรองถูกกำหนดให้กับบางโหนดอย่างเคร่งครัด และการสำรองข้อมูลจากระดับรองก็สมเหตุสมผลแล้ว เนื่องจากการสำรองข้อมูลจากระดับรองมีข้อจำกัด เนื่องจากลักษณะเฉพาะของ DBMS ดัมพ์จึงไม่ถูกสร้างขึ้นในระดับรอง ดังนั้นจึงเหลือเพียงความเป็นไปได้ในการสำรองข้อมูลไฟล์เท่านั้น
เพื่อลดความเสี่ยงของการหยุดทำงาน เมื่อสร้างระบบที่ทนทานต่อข้อผิดพลาด จะมีการสร้างการกำหนดค่าคลัสเตอร์ "แบบสด" และตัวหลักสามารถค่อยๆ โยกย้ายระหว่างเซิร์ฟเวอร์ต่างๆ ตัวอย่างเช่น ซอฟต์แวร์ Patroni เองก็เปิดตัว Primary บนโหนดคลัสเตอร์ที่เลือกแบบสุ่ม IBS ไม่มีทางติดตามสิ่งนี้ได้ทันที และหากการกำหนดค่าเปลี่ยนแปลง กระบวนการก็จะเสียหาย นั่นคือการแนะนำการควบคุมภายนอกป้องกันไม่ให้ ISR ทำงานได้อย่างมีประสิทธิภาพ เนื่องจากเซิร์ฟเวอร์ควบคุมไม่เข้าใจว่าจะคัดลอกข้อมูลจากที่ไหนและอะไรบ้าง
ปัญหาอีกประการหนึ่งคือการใช้การสำรองข้อมูลใน Postgres เป็นไปได้ผ่านการดัมพ์ และทำงานบนฐานข้อมูลขนาดเล็ก แต่ในฐานข้อมูลขนาดใหญ่ การดัมพ์ใช้เวลานาน ต้องใช้ทรัพยากรจำนวนมาก และอาจนำไปสู่ความล้มเหลวของอินสแตนซ์ฐานข้อมูลได้
การสำรองข้อมูลไฟล์จะแก้ไขสถานการณ์ แต่ในฐานข้อมูลขนาดใหญ่ การดำเนินการจะช้าเนื่องจากทำงานในโหมดเธรดเดียว นอกจากนี้ ผู้จำหน่ายยังมีข้อจำกัดเพิ่มเติมหลายประการ คุณอาจไม่สามารถใช้ไฟล์และการสำรองข้อมูลดัมพ์พร้อมกันได้ หรือไม่รองรับการขจัดข้อมูลซ้ำซ้อน มีปัญหามากมาย และบ่อยครั้งที่การเลือก DBMS ราคาแพงแต่ผ่านการพิสูจน์แล้วง่ายกว่า Postgres
ไม่มีที่ไหนให้ถอยแล้ว! นักพัฒนามอสโกอยู่ข้างหลัง!
อย่างไรก็ตาม เมื่อเร็วๆ นี้ทีมของเราเผชิญกับความท้าทายที่ยากลำบาก: ในโครงการสร้าง AIS OSAGO 2.0 ซึ่งเราสร้างโครงสร้างพื้นฐานด้านไอที นักพัฒนาเลือก PostgreSQL สำหรับระบบใหม่
นักพัฒนาซอฟต์แวร์รายใหญ่สามารถใช้โซลูชันโอเพ่นซอร์สที่ "ทันสมัย" ได้ง่ายกว่ามาก Facebook มีผู้เชี่ยวชาญเพียงพอที่จะสนับสนุนการทำงานของ DBMS นี้ และในกรณีของ RSA งานทั้งหมดของ "วันที่สอง" ก็ตกอยู่บนบ่าของเรา เราจำเป็นต้องตรวจสอบความทนทานต่อข้อผิดพลาด ประกอบคลัสเตอร์ และแน่นอนว่าต้องตั้งค่าการสำรองข้อมูล ตรรกะของการกระทำมีดังนี้:
- สอน SRK ให้สำรองข้อมูลจากโหนดหลักของคลัสเตอร์ ในการดำเนินการนี้ SRK จะต้องพบสิ่งนี้ ซึ่งหมายความว่าจำเป็นต้องมีการผสานรวมกับโซลูชันการจัดการคลัสเตอร์ PostgreSQL อย่างน้อยหนึ่งโซลูชัน ในกรณีของ RSA มีการใช้ซอฟต์แวร์ Patroni สำหรับสิ่งนี้
- ตัดสินใจเลือกประเภทของการสำรองข้อมูลตามปริมาณข้อมูลและข้อกำหนดในการกู้คืน ตัวอย่างเช่น เมื่อคุณต้องการคืนค่าเพจแบบละเอียด ให้ใช้ดัมพ์ และหากฐานข้อมูลมีขนาดใหญ่และไม่จำเป็นต้องคืนค่าแบบละเอียด ให้ใช้ไฟล์ในระดับไฟล์
- แนบความเป็นไปได้ของการสำรองข้อมูลแบบบล็อกเข้ากับโซลูชันเพื่อสร้างสำเนาสำรองในโหมดมัลติเธรด
ในเวลาเดียวกัน ในตอนแรกเราได้เริ่มสร้างระบบที่มีประสิทธิภาพและเรียบง่ายโดยไม่ต้องใช้ส่วนประกอบเพิ่มเติมมากมาย ยิ่งใช้ไม้ค้ำยันน้อยลง ภาระงานของพนักงานก็น้อยลง และความเสี่ยงต่อความล้มเหลวของ IBS ก็น้อยลงด้วย เรายกเว้นแนวทางที่ใช้ Veeam และ RMAN ทันที เนื่องจากชุดโซลูชันสองชุดได้บ่งบอกถึงความไม่น่าเชื่อถือของระบบแล้ว
เวทมนตร์เล็กๆ น้อยๆ สำหรับองค์กร
ดังนั้นเราจึงจำเป็นต้องรับประกันการสำรองข้อมูลที่เชื่อถือได้สำหรับ 10 คลัสเตอร์ กลุ่มละ 3 โหนด โดยมีโครงสร้างพื้นฐานเดียวกันที่มิเรอร์ในศูนย์ข้อมูลสำรอง ศูนย์ข้อมูลในแง่ของ PostgreSQL ทำงานบนหลักการแบบแอคทีฟ-พาสซีฟ ขนาดฐานข้อมูลทั้งหมดคือ 50 TB ระบบควบคุมระดับองค์กรสามารถรับมือกับสิ่งนี้ได้อย่างง่ายดาย แต่ข้อแม้ก็คือ ในตอนแรก Postgres ไม่มีเบาะแสเกี่ยวกับความเข้ากันได้เต็มรูปแบบและเชิงลึกกับระบบสำรองข้อมูล ดังนั้นเราจึงต้องมองหาโซลูชันที่ในตอนแรกมีฟังก์ชันการทำงานสูงสุดร่วมกับ PostgreSQL และปรับปรุงระบบ
เราจัด “แฮ็กกาธอน” ภายใน 3 ครั้ง - เราดูการพัฒนามากกว่าห้าสิบรายการ ทดสอบแล้ว ทำการเปลี่ยนแปลงที่เกี่ยวข้องกับสมมติฐานของเรา และทดสอบอีกครั้ง หลังจากตรวจสอบตัวเลือกที่มีแล้ว เราก็เลือก Commvault เมื่อแกะกล่อง ผลิตภัณฑ์นี้สามารถทำงานได้กับการติดตั้งคลัสเตอร์ PostgreSQL ที่ง่ายที่สุด และสถาปัตยกรรมแบบเปิดทำให้เกิดความหวัง (ซึ่งสมเหตุสมผล) สำหรับการพัฒนาและการบูรณาการที่ประสบความสำเร็จ Commvault ยังสามารถสำรองข้อมูลบันทึก PostgreSQL ได้อีกด้วย ตัวอย่างเช่น Veritas NetBackup ในแง่ของ PostgreSQL สามารถทำการสำรองข้อมูลทั้งหมดได้เท่านั้น
ข้อมูลเพิ่มเติมเกี่ยวกับสถาปัตยกรรม เซิร์ฟเวอร์การจัดการ Commvault ได้รับการติดตั้งในแต่ละศูนย์ข้อมูลทั้งสองแห่งในการกำหนดค่า CommServ HA ระบบเป็นแบบมิเรอร์ จัดการผ่านคอนโซลเดียว และตรงตามข้อกำหนดขององค์กรทั้งหมดจากมุมมองของ HA
นอกจากนี้เรายังเปิดตัวเซิร์ฟเวอร์สื่อทางกายภาพสองตัวในศูนย์ข้อมูลแต่ละแห่ง ซึ่งเราเชื่อมต่อดิสก์อาร์เรย์และไลบรารีเทปสำหรับการสำรองข้อมูลผ่าน SAN ผ่าน Fibre Channel โดยเฉพาะ ฐานข้อมูลการขจัดข้อมูลซ้ำซ้อนที่ขยายออกไปช่วยให้มั่นใจถึงความทนทานต่อข้อผิดพลาดของเซิร์ฟเวอร์มีเดีย และการเชื่อมต่อแต่ละเซิร์ฟเวอร์กับ CSV แต่ละรายการจะเปิดใช้งานการดำเนินการอย่างต่อเนื่องหากส่วนประกอบใด ๆ ล้มเหลว สถาปัตยกรรมระบบช่วยให้การสำรองข้อมูลดำเนินต่อไปได้แม้ว่าศูนย์ข้อมูลแห่งใดแห่งหนึ่งล่มก็ตาม
Patroni กำหนดโหนดหลักสำหรับแต่ละคลัสเตอร์ อาจเป็นโหนดอิสระใดก็ได้ในศูนย์ข้อมูล - แต่ส่วนใหญ่เท่านั้น ในการสำรองข้อมูล โหนดทั้งหมดจะเป็นโหนดรอง
เพื่อให้ Commvault เข้าใจว่าโหนดคลัสเตอร์ใดเป็นโหนดหลัก เราได้รวมระบบ (ด้วยสถาปัตยกรรมแบบเปิดของโซลูชัน) เข้ากับ Postgres เพื่อจุดประสงค์นี้ สคริปต์จึงถูกสร้างขึ้นเพื่อรายงานตำแหน่งปัจจุบันของโหนดหลักไปยังเซิร์ฟเวอร์การจัดการ Commvault
โดยทั่วไป กระบวนการจะมีลักษณะดังนี้:
Patroni เลือก Primary → Keepalived เลือกคลัสเตอร์ IP และรันสคริปต์ → Commvault agent บนโหนดคลัสเตอร์ที่เลือกจะได้รับการแจ้งเตือนว่านี่คือ Primary → Commvault จะกำหนดค่าการสำรองข้อมูลใหม่โดยอัตโนมัติภายในไคลเอนต์หลอก
ข้อดีของแนวทางนี้คือ โซลูชันจะไม่ส่งผลต่อความสอดคล้อง ความถูกต้องของบันทึก หรือการกู้คืนอินสแตนซ์ Postgres นอกจากนี้ยังสามารถปรับขนาดได้อย่างง่ายดาย เนื่องจากไม่จำเป็นต้องแก้ไขโหนด Commvault Primary และ Secondary อีกต่อไป ก็เพียงพอแล้วที่ระบบจะเข้าใจว่า Primary อยู่ที่ไหน และจำนวนโหนดสามารถเพิ่มได้เกือบทุกค่า
การแก้ปัญหาไม่ได้แกล้งทำเป็นอุดมคติและมีความแตกต่างในตัวเอง Commvault สามารถสำรองข้อมูลอินสแตนซ์ทั้งหมดเท่านั้น และไม่สามารถสำรองข้อมูลแต่ละฐานข้อมูลได้ ดังนั้นจึงมีการสร้างอินสแตนซ์แยกต่างหากสำหรับแต่ละฐานข้อมูล ลูกค้าจริงจะรวมกันเป็นลูกค้าหลอกเสมือน แต่ละไคลเอนต์จำลอง Commvault เป็นคลัสเตอร์ UNIX โหนดคลัสเตอร์ที่ติดตั้ง Commvault agent สำหรับ Postgres ไว้จะถูกเพิ่มเข้าไป ด้วยเหตุนี้ โหนดเสมือนทั้งหมดของไคลเอนต์เทียมจึงได้รับการสำรองข้อมูลเป็นอินสแตนซ์เดียว
ภายในไคลเอนต์หลอกแต่ละอัน โหนดที่ใช้งานอยู่ของคลัสเตอร์จะถูกระบุ นี่คือสิ่งที่โซลูชันบูรณาการของเราสำหรับ Commvault กำหนดไว้ หลักการดำเนินการนั้นค่อนข้างง่าย: หาก IP ของคลัสเตอร์ถูกยกขึ้นบนโหนด สคริปต์จะตั้งค่าพารามิเตอร์ "โหนดที่ใช้งานอยู่" ในไบนารีของเอเจนต์ Commvault - อันที่จริงสคริปต์จะตั้งค่า "1" ในส่วนที่ต้องการของหน่วยความจำ . เอเจนต์จะส่งข้อมูลนี้ไปยัง CommServe และ Commvault จะทำการสำรองข้อมูลจากโหนดที่ต้องการ นอกจากนี้ ความถูกต้องของการกำหนดค่าจะถูกตรวจสอบในระดับสคริปต์ ซึ่งช่วยหลีกเลี่ยงข้อผิดพลาดเมื่อเริ่มการสำรองข้อมูล
ในเวลาเดียวกัน ฐานข้อมูลขนาดใหญ่จะได้รับการสำรองข้อมูลเป็นบล็อกในหลายเธรด ซึ่งเป็นไปตามข้อกำหนด RPO และหน้าต่างการสำรองข้อมูล โหลดบนระบบไม่มีนัยสำคัญ: สำเนาฉบับเต็มไม่ได้เกิดขึ้นบ่อยนัก ในวันที่อื่น ๆ จะมีการเก็บรวบรวมเฉพาะบันทึกเท่านั้น และในช่วงระยะเวลาที่มีโหลดน้อย
อย่างไรก็ตาม เราได้ใช้นโยบายแยกต่างหากสำหรับการสำรองบันทึกไฟล์เก็บถาวร PostgreSQL โดยบันทึกเหล่านี้จะถูกจัดเก็บตามกฎที่ต่างกัน คัดลอกตามกำหนดเวลาอื่น และไม่ได้เปิดใช้งานการขจัดข้อมูลซ้ำซ้อนเนื่องจากบันทึกเหล่านี้มีข้อมูลที่ไม่ซ้ำกัน
เพื่อให้มั่นใจถึงความสอดคล้องกันในโครงสร้างพื้นฐานด้านไอทีทั้งหมด จึงมีการติดตั้งไคลเอนต์ไฟล์ Commvault ที่แยกกันบนโหนดคลัสเตอร์แต่ละโหนด โดยแยกไฟล์ Postgres ออกจากการสำรองข้อมูล และมีไว้สำหรับการสำรองข้อมูลระบบปฏิบัติการและแอปพลิเคชันเท่านั้น ข้อมูลส่วนนี้ยังมีนโยบายและระยะเวลาการจัดเก็บของตัวเองด้วย
ปัจจุบัน IBS ไม่ส่งผลกระทบต่อบริการด้านการผลิต แต่หากสถานการณ์เปลี่ยนแปลง Commvault สามารถเปิดใช้งานการจำกัดการโหลดได้
มันดีเหรอ? ดี!
ดังนั้นเราจึงไม่เพียงแต่ได้รับการสำรองข้อมูลที่ใช้งานได้เท่านั้น แต่ยังได้รับการสำรองข้อมูลอัตโนมัติเต็มรูปแบบสำหรับการติดตั้งคลัสเตอร์ PostgreSQL และตรงตามข้อกำหนดทั้งหมดสำหรับการโทรระดับองค์กร
พารามิเตอร์ RPO และ RTO ของ 1 ชั่วโมงและ 2 ชั่วโมงถูกครอบคลุมด้วยส่วนต่าง ซึ่งหมายความว่าระบบจะปฏิบัติตามพารามิเตอร์เหล่านั้น แม้ว่าปริมาณข้อมูลที่จัดเก็บจะเพิ่มขึ้นอย่างมากก็ตาม ตรงกันข้ามกับข้อสงสัยมากมาย PostgreSQL และสภาพแวดล้อมขององค์กรกลับกลายเป็นว่าเข้ากันได้ดีทีเดียว และตอนนี้เรารู้จากประสบการณ์ของเราเองว่าการสำรองข้อมูลสำหรับ DBMS ดังกล่าวสามารถทำได้ในการกำหนดค่าที่หลากหลาย
แน่นอนว่าตามเส้นทางนี้เราต้องสวมรองเท้าบูทเหล็กเจ็ดคู่ เอาชนะความยากลำบากมากมาย เหยียบคราดหลายอัน และแก้ไขข้อผิดพลาดจำนวนหนึ่ง แต่ตอนนี้แนวทางดังกล่าวได้รับการทดสอบแล้วและสามารถนำมาใช้ในการใช้งาน Open Source แทน DBMS ที่เป็นกรรมสิทธิ์ในสภาวะที่รุนแรงขององค์กร
คุณได้ลองทำงานกับ PostgreSQL ในสภาพแวดล้อมขององค์กรแล้วหรือยัง?
ผู้เขียน:
Oleg Lavrenov วิศวกรออกแบบระบบจัดเก็บข้อมูล Jet Infosystems
Dmitry Erykin วิศวกรออกแบบระบบคอมพิวเตอร์ที่ Jet Infosystems
ที่มา: will.com