สวัสดีผู้อ่าน Habr! ในบทความที่แล้ว เราได้พูดคุยเกี่ยวกับวิธีการกู้คืนความเสียหายแบบง่ายๆ ในระบบจัดเก็บข้อมูล AERODISK ENGINE - การจำลองแบบ ในบทความนี้ เราจะเจาะลึกหัวข้อที่ซับซ้อนและน่าสนใจมากขึ้น - เมโทรคลัสเตอร์ ซึ่งก็คือวิธีการป้องกันภัยพิบัติแบบอัตโนมัติสำหรับศูนย์ข้อมูลสองแห่ง ซึ่งช่วยให้ศูนย์ข้อมูลทำงานในโหมดแอคทีฟ-แอคทีฟได้ เราจะบอกคุณ แสดงให้คุณเห็น ทำลายมัน และแก้ไขมัน
ตามปกติทฤษฎีมาก่อน
คลัสเตอร์ขนาดใหญ่คือคลัสเตอร์ที่กระจายไปตามสถานที่ต่างๆ ภายในเมืองหรือภูมิภาค คำว่า "คลัสเตอร์" บอกเป็นนัยอย่างชัดเจนว่าคอมเพล็กซ์นั้นเป็นแบบอัตโนมัติ นั่นคือการสลับโหนดคลัสเตอร์ในกรณีที่เกิดความล้มเหลวโดยอัตโนมัติ
นี่คือจุดที่ความแตกต่างหลักระหว่างคลัสเตอร์เมโทรคลัสเตอร์และการจำลองแบบปกติอยู่ ระบบอัตโนมัติของการดำเนินงาน กล่าวคือ ในกรณีที่เกิดเหตุการณ์บางอย่าง (ความล้มเหลวของศูนย์ข้อมูล ช่องสัญญาณเสียหาย ฯลฯ) ระบบจัดเก็บข้อมูลจะดำเนินการตามที่จำเป็นอย่างอิสระเพื่อรักษาความพร้อมใช้งานของข้อมูล เมื่อใช้เรพลิกาปกติ ผู้ดูแลระบบจะดำเนินการเหล่านี้ด้วยตนเองทั้งหมดหรือบางส่วน
มันทำอะไร?
เป้าหมายหลักที่ลูกค้าดำเนินการเมื่อใช้การใช้งานเมโทรคลัสเตอร์บางอย่างคือการลด RTO (วัตถุประสงค์ด้านเวลาการกู้คืน) ให้เหลือน้อยที่สุด นั่นคือเพื่อลดเวลาการกู้คืนบริการด้านไอทีให้เหลือน้อยที่สุดหลังจากเกิดความล้มเหลว หากคุณใช้การจำลองแบบปกติ เวลาการกู้คืนจะนานกว่าเวลาการกู้คืนด้วยเมโทรคลัสเตอร์เสมอ ทำไม ง่ายมาก. ผู้ดูแลระบบจะต้องอยู่ที่โต๊ะและสลับการจำลองด้วยตนเอง และเมโทรคลัสเตอร์จะดำเนินการนี้โดยอัตโนมัติ
หากไม่มีผู้ดูแลเฉพาะหน้าที่ ไม่นอน ไม่กิน ไม่สูบบุหรี่ ไม่ป่วย และเฝ้าดูสถานะระบบจัดเก็บข้อมูลตลอด 24 ชั่วโมง ก็ไม่มีทางรับประกันได้ว่าผู้ดูแลระบบจะ สามารถสลับด้วยตนเองได้ในระหว่างเกิดความล้มเหลว
ดังนั้น RTO ในกรณีที่ไม่มีเมโทรคลัสเตอร์หรือผู้ดูแลระบบอมตะระดับ 99 ของการบริการหน้าที่ผู้ดูแลระบบจะเท่ากับผลรวมของเวลาเปลี่ยนของทุกระบบและระยะเวลาสูงสุดหลังจากนั้นผู้ดูแลระบบรับประกันว่าจะเริ่มทำงาน ด้วยระบบจัดเก็บข้อมูลและระบบที่เกี่ยวข้อง
ดังนั้นเราจึงได้ข้อสรุปที่ชัดเจนว่าควรใช้เมโทรคลัสเตอร์หากข้อกำหนดสำหรับ RTO คือนาที ไม่ใช่ชั่วโมงหรือวัน กล่าวคือ ในกรณีที่ศูนย์ข้อมูลล้มเหลวเลวร้ายที่สุด แผนก IT จะต้องจัดเตรียมเวลาให้กับธุรกิจ เพื่อเรียกคืนการเข้าถึงบริการด้านไอทีภายในไม่กี่นาทีหรือไม่กี่วินาที
มันทำงานอย่างไร
ในระดับล่าง เมโทรคลัสเตอร์ใช้กลไกสำหรับการจำลองข้อมูลแบบซิงโครนัส ซึ่งเราได้อธิบายไว้ในบทความก่อนหน้านี้ (ดู ). เนื่องจากการจำลองเป็นแบบซิงโครนัส ข้อกำหนดจึงสอดคล้องกัน หรือค่อนข้าง:
- ใยแก้วนำแสงเป็นฟิสิกส์, 10 กิกะบิตอีเธอร์เน็ต (หรือสูงกว่า);
- ระยะห่างระหว่างศูนย์ข้อมูลไม่เกิน 40 กิโลเมตร
- ความล่าช้าของช่องสัญญาณออปติคัลระหว่างศูนย์ข้อมูล (ระหว่างระบบจัดเก็บข้อมูล) สูงถึง 5 มิลลิวินาที (ดีที่สุด 2)
ข้อกำหนดทั้งหมดเหล่านี้เป็นคำแนะนำโดยธรรมชาติ กล่าวคือ เมโทรคลัสเตอร์จะทำงานแม้ว่าจะไม่ปฏิบัติตามข้อกำหนดเหล่านี้ แต่เราต้องเข้าใจว่าผลที่ตามมาจากการไม่ปฏิบัติตามข้อกำหนดเหล่านี้เท่ากับการชะลอตัวในการทำงานของระบบจัดเก็บข้อมูลทั้งสองใน เมโทรคลัสเตอร์
ดังนั้น แบบจำลองแบบซิงโครนัสจึงถูกใช้เพื่อถ่ายโอนข้อมูลระหว่างระบบจัดเก็บข้อมูล และแบบจำลองจะสลับโดยอัตโนมัติได้อย่างไร และที่สำคัญที่สุดคือ จะหลีกเลี่ยงการแยกสมองได้อย่างไร ในการทำเช่นนี้ในระดับที่สูงกว่าจะใช้เอนทิตีเพิ่มเติม - ผู้ตัดสิน
อนุญาโตตุลาการทำงานอย่างไรและงานของเขาคืออะไร?
ผู้ชี้ขาดคือเครื่องเสมือนขนาดเล็กหรือคลัสเตอร์ฮาร์ดแวร์ที่ต้องเปิดตัวบนไซต์ที่สาม (เช่น ในสำนักงาน) และให้การเข้าถึงระบบจัดเก็บข้อมูลผ่าน ICMP และ SSH หลังจากเปิดตัว ผู้ตัดสินควรตั้งค่า IP จากนั้นจากด้านที่เก็บข้อมูลระบุที่อยู่ รวมถึงที่อยู่ของรีโมทคอนโทรลที่เข้าร่วมในเมโทรคลัสเตอร์ หลังจากนี้กรรมการก็พร้อมทำงาน
ผู้ชี้ขาดจะตรวจสอบระบบจัดเก็บข้อมูลทั้งหมดในเมโทรคลัสเตอร์อย่างต่อเนื่อง และหากระบบจัดเก็บข้อมูลเฉพาะไม่พร้อมใช้งาน หลังจากยืนยันความไม่พร้อมใช้งานจากสมาชิกรายอื่นของคลัสเตอร์ (หนึ่งในระบบจัดเก็บข้อมูล "สด") เขาตัดสินใจเริ่มกระบวนการสำหรับการสลับกฎการจำลอง และการทำแผนที่
จุดที่สำคัญมาก อนุญาโตตุลาการจะต้องอยู่ในตำแหน่งที่แตกต่างจากที่ตั้งของระบบจัดเก็บข้อมูลเสมอ นั่นคือ ทั้งในศูนย์ข้อมูล 1 ที่ติดตั้งระบบจัดเก็บข้อมูล 1 หรือในศูนย์ข้อมูล 2 ที่ติดตั้งระบบจัดเก็บข้อมูล 2
ทำไม เนื่องจากนี่เป็นวิธีเดียวที่อนุญาโตตุลาการสามารถระบุการล่มสลายของไซต์ทั้งสองแห่งที่ติดตั้งระบบจัดเก็บข้อมูลได้อย่างไม่คลุมเครือและแม่นยำด้วยความช่วยเหลือจากระบบจัดเก็บข้อมูลระบบใดระบบหนึ่ง วิธีการอื่นใดในการวางตัวชี้ขาดอาจส่งผลให้สมองแตกแยก
ตอนนี้เรามาดูรายละเอียดของงานของอนุญาโตตุลาการกันดีกว่า
ผู้ชี้ขาดจะเรียกใช้บริการหลายอย่างที่สำรวจตัวควบคุมการจัดเก็บข้อมูลทั้งหมดอย่างต่อเนื่อง หากผลการสำรวจความคิดเห็นแตกต่างจากผลก่อนหน้า (มี/ไม่มี) ก็จะถูกบันทึกไว้ในฐานข้อมูลขนาดเล็ก ซึ่งทำงานกับผู้ตัดสินด้วย
ลองดูตรรกะของงานของอนุญาโตตุลาการโดยละเอียด
ขั้นตอนที่ 1: พิจารณาความไม่พร้อมใช้งาน เหตุการณ์ความล้มเหลวของระบบจัดเก็บข้อมูลคือการไม่มี Ping จากตัวควบคุมทั้งสองของระบบจัดเก็บข้อมูลเดียวกันภายใน 5 วินาที
ขั้นตอนที่ 2 เริ่มขั้นตอนการสลับ หลังจากที่ผู้ชี้ขาดทราบว่าระบบจัดเก็บข้อมูลระบบใดระบบหนึ่งไม่พร้อมใช้งาน เขาก็ส่งคำขอไปยังระบบจัดเก็บข้อมูล "ที่ใช้งานอยู่" เพื่อให้แน่ใจว่าระบบจัดเก็บข้อมูล "ที่ใช้งานไม่ได้" นั้นไม่ทำงานจริงๆ
หลังจากได้รับคำสั่งดังกล่าวจากผู้ตัดสิน ระบบจัดเก็บข้อมูลที่สอง (สด) จะตรวจสอบความพร้อมใช้งานของระบบจัดเก็บข้อมูลแรกที่ล่มสลายเพิ่มเติม และหากไม่มีอยู่ จะส่งคำยืนยันไปยังผู้ตัดสินถึงการเดาของเขา ระบบจัดเก็บข้อมูลไม่พร้อมใช้งานอย่างแน่นอน
หลังจากได้รับการยืนยันดังกล่าว ผู้ชี้ขาดจะเริ่มกระบวนการระยะไกลสำหรับการสลับการจำลองแบบและการแมปบนแบบจำลองเหล่านั้นที่ใช้งานอยู่ (หลัก) บนระบบจัดเก็บข้อมูลที่ล้มเหลว และส่งคำสั่งไปยังระบบจัดเก็บข้อมูลที่สองเพื่อเปลี่ยนแบบจำลองเหล่านี้จากแบบจำลองรองไปเป็นหลักและ ยกการทำแผนที่ ดังนั้นระบบจัดเก็บข้อมูลที่สองจึงดำเนินการตามขั้นตอนเหล่านี้จากนั้นจึงให้การเข้าถึง LUN ที่สูญหายจากตัวมันเอง
เหตุใดจึงต้องมีการตรวจสอบเพิ่มเติม? สำหรับองค์ประชุม นั่นคือ สมาชิกคลัสเตอร์จำนวนคี่ (3) ส่วนใหญ่จะต้องยืนยันการล่มสลายของหนึ่งในโหนดคลัสเตอร์ เมื่อนั้นการตัดสินใจครั้งนี้จะถูกต้องอย่างแน่นอน นี่เป็นสิ่งจำเป็นเพื่อหลีกเลี่ยงการสลับที่ผิดพลาดและส่งผลให้สมองแตกแยก
เวลาขั้นตอนที่ 2 ใช้เวลาประมาณ 5 - 10 วินาที ดังนั้น เมื่อคำนึงถึงเวลาที่ต้องใช้ในการพิจารณาความไม่พร้อมใช้งาน (5 วินาที) ภายใน 10 - 15 วินาทีหลังจากเกิดอุบัติเหตุ LUN จากระบบจัดเก็บข้อมูลที่ล้มจะพร้อมใช้งานโดยอัตโนมัติเพื่อทำงานร่วมกับระบบถ่ายทอดสด ระบบจัดเก็บข้อมูล
เป็นที่ชัดเจนว่าเพื่อหลีกเลี่ยงการสูญเสียการเชื่อมต่อกับโฮสต์ คุณจะต้องดูแลกำหนดค่าการหมดเวลาบนโฮสต์ให้ถูกต้องด้วย การหมดเวลาที่แนะนำคืออย่างน้อย 30 วินาที วิธีนี้จะป้องกันไม่ให้โฮสต์ตัดการเชื่อมต่อกับระบบจัดเก็บข้อมูลในระหว่างการสลับโหลดในกรณีที่เกิดภัยพิบัติ และช่วยให้มั่นใจได้ว่าจะไม่มีการหยุดชะงักของ I/O
รอสักครู่ ปรากฎว่าถ้าทุกอย่างดีกับเมโทรคลัสเตอร์ ทำไมเราจึงต้องมีการจำลองแบบปกติด้วย
ในความเป็นจริงทุกอย่างไม่ง่ายนัก
พิจารณาข้อดีข้อเสียของเมโทรคลัสเตอร์
ดังนั้นเราจึงตระหนักว่าข้อได้เปรียบที่ชัดเจนของคลัสเตอร์เมโทรคลัสเตอร์เมื่อเปรียบเทียบกับการจำลองแบบทั่วไปคือ:
- ระบบอัตโนมัติเต็มรูปแบบ ช่วยให้มั่นใจเวลาในการฟื้นตัวน้อยที่สุดในกรณีเกิดภัยพิบัติ
- นั่นคือทั้งหมด :-)
และตอนนี้ความสนใจข้อเสีย:
- ต้นทุนการแก้ปัญหา แม้ว่าเมโทรคลัสเตอร์ในระบบ Aerodisk จะไม่จำเป็นต้องมีใบอนุญาตเพิ่มเติม (ใช้ใบอนุญาตเดียวกันกับแบบจำลอง) แต่ต้นทุนของโซลูชันจะยังคงสูงกว่าการใช้การจำลองแบบซิงโครนัสเสียอีก คุณจะต้องปฏิบัติตามข้อกำหนดทั้งหมดสำหรับการจำลองแบบซิงโครนัส รวมถึงข้อกำหนดสำหรับเมโทรคลัสเตอร์ที่เกี่ยวข้องกับการสลับเพิ่มเติมและไซต์เพิ่มเติม (ดูการวางแผนเมโทรคลัสเตอร์)
- ความซับซ้อนของการแก้ปัญหา เมโทรคลัสเตอร์มีความซับซ้อนมากกว่าแบบจำลองทั่วไป และต้องการความเอาใจใส่และความพยายามมากขึ้นในการวางแผน การกำหนดค่า และเอกสารประกอบ
ในท้ายที่สุด. Metrocluster เป็นโซลูชันที่ดีทางเทคโนโลยีขั้นสูงอย่างแน่นอน เมื่อคุณต้องการจัดเตรียม RTO จริงๆ ภายในไม่กี่วินาทีหรือนาที แต่ถ้าไม่มีงานดังกล่าวและ RTO ในเวลาไม่กี่ชั่วโมงก็โอเคสำหรับธุรกิจ ก็ไม่มีประโยชน์ที่จะยิงนกกระจอกจากปืนใหญ่ การจำลองแบบคนงาน-ชาวนาตามปกติก็เพียงพอแล้ว เนื่องจากคลัสเตอร์ในเมืองใหญ่จะทำให้เกิดค่าใช้จ่ายเพิ่มเติมและความยุ่งยากในโครงสร้างพื้นฐานด้านไอที
การวางแผนเมโทรคลัสเตอร์
เนื้อหาในส่วนนี้ไม่ได้อ้างว่าเป็นแนวทางที่ครอบคลุมเกี่ยวกับการออกแบบคลัสเตอร์เมโทรคลัสเตอร์ แต่จะแสดงเฉพาะทิศทางหลักที่ควรดำเนินการหากคุณตัดสินใจสร้างระบบดังกล่าว ดังนั้น เมื่อใช้งานเมโทรคลัสเตอร์จริง ต้องแน่ใจว่าได้เกี่ยวข้องกับผู้ผลิตระบบจัดเก็บข้อมูล (ซึ่งก็คือเรา) และระบบอื่น ๆ ที่เกี่ยวข้องเพื่อขอคำปรึกษา
สนามเด็กเล่น
ตามที่ระบุไว้ข้างต้น คลัสเตอร์ขนาดใหญ่ต้องมีไซต์อย่างน้อยสามแห่ง ศูนย์ข้อมูลสองแห่งที่ระบบจัดเก็บข้อมูลและระบบที่เกี่ยวข้องจะทำงาน เช่นเดียวกับไซต์ที่สามที่อนุญาโตตุลาการจะทำงาน
ระยะห่างระหว่างศูนย์ข้อมูลที่แนะนำคือไม่เกิน 40 กิโลเมตร ระยะทางที่มากขึ้นมีแนวโน้มที่จะทำให้เกิดความล่าช้าเพิ่มเติม ซึ่งในกรณีของคลัสเตอร์ขนาดใหญ่นั้นเป็นสิ่งที่ไม่พึงปรารถนาอย่างยิ่ง เราขอเตือนคุณว่าความล่าช้าควรสูงถึง 5 มิลลิวินาที แม้ว่าจะแนะนำให้เก็บไว้ภายใน 2 ก็ตาม
ขอแนะนำให้ตรวจสอบความล่าช้าในระหว่างขั้นตอนการวางแผนด้วย ผู้ให้บริการที่มีความเป็นผู้ใหญ่ไม่มากก็น้อยที่ให้บริการใยแก้วนำแสงระหว่างศูนย์ข้อมูลสามารถจัดการตรวจสอบคุณภาพได้ค่อนข้างรวดเร็ว
สำหรับความล่าช้าต่อหน้าอนุญาโตตุลาการ (นั่นคือระหว่างไซต์ที่สามและสองไซต์แรก) เกณฑ์ความล่าช้าที่แนะนำคือสูงสุด 200 มิลลิวินาทีนั่นคือการเชื่อมต่อ VPN ขององค์กรปกติผ่านอินเทอร์เน็ตมีความเหมาะสม
การสลับและเครือข่าย
แตกต่างจากรูปแบบการจำลองแบบที่การเชื่อมต่อระบบจัดเก็บข้อมูลจากไซต์ต่างๆ เพียงพอ ระบบเมโทรคลัสเตอร์จำเป็นต้องเชื่อมต่อโฮสต์กับระบบจัดเก็บข้อมูลทั้งสองที่ไซต์ต่างกัน เพื่อให้ชัดเจนยิ่งขึ้นว่าอะไรคือความแตกต่าง ทั้งสองแผนจึงแสดงไว้ด้านล่าง
ดังที่เห็นได้จากแผนภาพ โฮสต์ไซต์ 1 ของเราจะพิจารณาทั้งระบบจัดเก็บข้อมูล 1 และระบบจัดเก็บข้อมูล 2 นอกจากนี้ ในทางกลับกัน โฮสต์ไซต์ 2 จะพิจารณาทั้งระบบจัดเก็บข้อมูล 2 และระบบจัดเก็บข้อมูล 1 นั่นคือแต่ละโฮสต์จะเห็นทั้งสองระบบจัดเก็บข้อมูล นี่เป็นข้อกำหนดเบื้องต้นสำหรับการทำงานของเมโทรคลัสเตอร์
แน่นอนว่าไม่จำเป็นต้องเชื่อมต่อแต่ละโฮสต์ด้วยสายออปติคอลกับศูนย์ข้อมูลอื่น ไม่มีพอร์ตหรือสายไฟใดที่เพียงพอ การเชื่อมต่อทั้งหมดเหล่านี้ต้องทำผ่านสวิตช์ Ethernet 10G+ หรือ FibreChannel 8G+ (FC ใช้สำหรับเชื่อมต่อโฮสต์และระบบจัดเก็บข้อมูลสำหรับ IO เท่านั้น ปัจจุบันช่องทางการจำลองพร้อมใช้งานผ่าน IP เท่านั้น (Ethernet 10G+)
ตอนนี้บางคำเกี่ยวกับโทโพโลยีเครือข่าย จุดสำคัญคือการกำหนดค่าเครือข่ายย่อยที่ถูกต้อง จำเป็นต้องกำหนดเครือข่ายย่อยหลายรายการทันทีสำหรับการรับส่งข้อมูลประเภทต่อไปนี้:
- เครือข่ายย่อยการจำลองข้อมูลที่จะซิงโครไนซ์ระหว่างระบบจัดเก็บข้อมูล อาจมีหลายอย่างในกรณีนี้ก็ไม่สำคัญ ทุกอย่างขึ้นอยู่กับโทโพโลยีเครือข่ายปัจจุบัน (ใช้งานแล้ว) หากมีสองตัว จะต้องกำหนดค่าการกำหนดเส้นทางระหว่างกันอย่างชัดเจน
- ซับเน็ตการจัดเก็บข้อมูลที่โฮสต์จะเข้าถึงทรัพยากรการจัดเก็บข้อมูล (หากเป็น iSCSI) ควรมีหนึ่งซับเน็ตดังกล่าวในแต่ละศูนย์ข้อมูล
- ควบคุมเครือข่ายย่อย นั่นคือ เครือข่ายย่อยที่กำหนดเส้นทางได้สามเครือข่ายบนไซต์สามแห่งซึ่งมีการจัดการระบบจัดเก็บข้อมูล และผู้ชี้ขาดก็อยู่ที่นั่นด้วย
เราไม่พิจารณาเครือข่ายย่อยสำหรับการเข้าถึงทรัพยากรโฮสต์ที่นี่ เนื่องจากเครือข่ายย่อยเหล่านี้ขึ้นอยู่กับงานเป็นอย่างมาก
การแยกการรับส่งข้อมูลที่แตกต่างกันออกเป็นเครือข่ายย่อยที่แตกต่างกันเป็นสิ่งสำคัญอย่างยิ่ง (เป็นสิ่งสำคัญอย่างยิ่งที่จะต้องแยกแบบจำลองออกจาก I/O) เพราะหากคุณผสมการรับส่งข้อมูลทั้งหมดเป็นเครือข่ายย่อย "หนา" เดียว การรับส่งข้อมูลนี้จะไม่สามารถจัดการได้ และใน เงื่อนไขของศูนย์ข้อมูลทั้งสองแห่งยังคงอาจทำให้เกิดตัวเลือกการชนกันของเครือข่ายที่แตกต่างกัน เราจะไม่เจาะลึกปัญหานี้ภายในกรอบของบทความนี้ เนื่องจากคุณสามารถอ่านเกี่ยวกับการวางแผนเครือข่ายที่ขยายระหว่างศูนย์ข้อมูลบนทรัพยากรของผู้ผลิตอุปกรณ์เครือข่าย ซึ่งมีการอธิบายไว้อย่างละเอียด
การกำหนดค่าอนุญาโตตุลาการ
ผู้ชี้ขาดจะต้องจัดให้มีการเข้าถึงอินเทอร์เฟซการจัดการทั้งหมดของระบบจัดเก็บข้อมูลผ่านโปรโตคอล ICMP และ SSH คุณควรคิดถึงความล้มเหลวของผู้ตัดสินด้วย มีความแตกต่างที่นี่
การเฟลโอเวอร์ของ Arbiter เป็นที่ต้องการอย่างมาก แต่ก็ไม่จำเป็น จะเกิดอะไรขึ้นหากกรรมการผิดพลาดผิดเวลา?
- การทำงานของเมโทรคลัสเตอร์ในโหมดปกติจะไม่เปลี่ยนแปลงเพราะว่า arbtir ไม่มีผลกระทบใด ๆ ต่อการทำงานของเมโทรคลัสเตอร์ในโหมดปกติ (หน้าที่ของมันคือสลับโหลดระหว่างศูนย์ข้อมูลในเวลาที่เหมาะสม)
- ยิ่งไปกว่านั้น หากผู้ชี้ขาดด้วยเหตุผลใดก็ตามล้มลงและ "หลับไหล" อุบัติเหตุในศูนย์ข้อมูล ก็จะไม่มีการสลับเกิดขึ้น เนื่องจากจะไม่มีใครออกคำสั่งการสลับที่จำเป็นและจัดระเบียบองค์ประชุม ในกรณีนี้ เมโทรคลัสเตอร์จะกลายเป็นรูปแบบปกติพร้อมการจำลอง ซึ่งจะต้องเปลี่ยนด้วยตนเองในระหว่างเกิดภัยพิบัติ ซึ่งจะส่งผลต่อ RTO
ต่อจากนี้จะมีอะไรบ้าง? หากคุณต้องการรับรอง RTO ขั้นต่ำจริงๆ คุณต้องแน่ใจว่าผู้ตัดสินมีความทนทานต่อข้อผิดพลาด มีสองตัวเลือกสำหรับสิ่งนี้:
- เปิดตัวเครื่องเสมือนโดยมีตัวตัดสินบนไฮเปอร์ไวเซอร์ที่ทนทานต่อข้อผิดพลาด โชคดีที่ไฮเปอร์ไวเซอร์ที่เป็นผู้ใหญ่ทุกคนรองรับความทนทานต่อข้อผิดพลาด
- หากที่ไซต์ที่สาม (ในสำนักงานทั่วไป) คุณขี้เกียจเกินกว่าจะติดตั้งคลัสเตอร์ปกติและไม่มีคลัสเตอร์ Hypervozor อยู่ เราก็ได้จัดเตรียมเวอร์ชันฮาร์ดแวร์ของอนุญาโตตุลาการ ซึ่งผลิตในกล่อง 2U ซึ่งมีคลัสเตอร์ธรรมดาสองตัว เซิร์ฟเวอร์ x-86 ใช้งานได้และสามารถทนต่อความล้มเหลวในเครื่องได้
เราขอแนะนำอย่างยิ่งให้ตรวจสอบให้แน่ใจถึงความทนทานต่อข้อบกพร่องของผู้ตัดสิน แม้ว่าเมโทรคลัสเตอร์จะไม่ต้องการมันในโหมดปกติก็ตาม แต่ดังที่ทั้งภาคทฤษฎีและภาคปฏิบัติแสดงให้เห็น หากคุณสร้างโครงสร้างพื้นฐานที่ป้องกันภัยพิบัติที่เชื่อถือได้อย่างแท้จริง ก็ควรดำเนินการอย่างปลอดภัยจะดีกว่า เป็นการดีกว่าที่จะปกป้องตัวเองและธุรกิจของคุณจาก "กฎแห่งความใจร้าย" นั่นคือจากความล้มเหลวของทั้งอนุญาโตตุลาการและหนึ่งในไซต์ที่ระบบจัดเก็บข้อมูลตั้งอยู่
สถาปัตยกรรมโซลูชัน
เมื่อพิจารณาข้อกำหนดข้างต้น เราได้รับสถาปัตยกรรมโซลูชันทั่วไปดังต่อไปนี้
LUN ควรมีการกระจายเท่าๆ กันในสองไซต์เพื่อหลีกเลี่ยงการโอเวอร์โหลดอย่างรุนแรง ในเวลาเดียวกัน เมื่อปรับขนาดในศูนย์ข้อมูลทั้งสองแห่ง คุณไม่ควรรวมเฉพาะปริมาณสองเท่า (ซึ่งจำเป็นในการจัดเก็บข้อมูลพร้อมกันบนระบบจัดเก็บข้อมูลสองระบบ) แต่ยังรวมถึงประสิทธิภาพสองเท่าใน IOPS และ MB/s เพื่อป้องกันการสลายตัวของแอปพลิเคชันใน กรณีเกิดความล้มเหลวของศูนย์ข้อมูลแห่งใดแห่งหนึ่ง
แยกกัน เราทราบว่าด้วยแนวทางที่เหมาะสมในการกำหนดขนาด (นั่นคือ โดยมีเงื่อนไขว่าเราได้จัดเตรียมขีดจำกัดบนที่เหมาะสมของ IOPS และ MB/s ตลอดจนทรัพยากร CPU และ RAM ที่จำเป็น) หากเป็นหนึ่งในระบบจัดเก็บข้อมูลใน คลัสเตอร์เมโทรล้มเหลว ประสิทธิภาพจะไม่ลดลงอย่างรุนแรงภายใต้เงื่อนไข การทำงานชั่วคราวในระบบจัดเก็บข้อมูลเดียว
สิ่งนี้อธิบายได้จากข้อเท็จจริงที่ว่าเมื่อสองไซต์ทำงานพร้อมกัน การจำลองแบบซิงโครนัสจะ "กิน" ครึ่งหนึ่งของประสิทธิภาพการเขียน เนื่องจากแต่ละธุรกรรมจะต้องเขียนลงในระบบจัดเก็บข้อมูลสองระบบ (คล้ายกับ RAID-1/10) ดังนั้น หากระบบจัดเก็บข้อมูลระบบใดระบบหนึ่งล้มเหลว อิทธิพลของการจำลองแบบชั่วคราว (จนกว่าระบบจัดเก็บข้อมูลที่ล้มเหลวในการกู้คืน) จะหายไป และเราได้รับประสิทธิภาพการเขียนเพิ่มขึ้นสองเท่า หลังจากที่ LUN ของระบบจัดเก็บข้อมูลที่ล้มเหลวถูกรีสตาร์ทบนระบบจัดเก็บข้อมูลที่ใช้งานได้ การเพิ่มขึ้นสองเท่านี้จะหายไปเนื่องจากโหลดปรากฏจาก LUN ของระบบจัดเก็บข้อมูลอื่น และเรากลับสู่ระดับประสิทธิภาพเดียวกันกับที่เรามีก่อน “ตก” แต่อยู่ในกรอบของไซต์เดียวเท่านั้น
ด้วยความช่วยเหลือของขนาดที่เหมาะสม คุณสามารถรับประกันเงื่อนไขที่ผู้ใช้จะไม่รู้สึกถึงความล้มเหลวของระบบจัดเก็บข้อมูลทั้งหมดเลย แต่เราขอย้ำอีกครั้งว่าต้องใช้ความระมัดระวังอย่างมาก ซึ่งคุณสามารถติดต่อเราได้ฟรี :-)
การจัดตั้งเมโทรคลัสเตอร์
การตั้งค่าเมโทรคลัสเตอร์นั้นคล้ายคลึงกับการตั้งค่าการจำลองแบบปกติมาก ซึ่งเราได้อธิบายไว้แล้ว . ดังนั้นขอเน้นเฉพาะความแตกต่างเท่านั้น เราจัดโต๊ะในห้องปฏิบัติการตามสถาปัตยกรรมด้านบนในเวอร์ชันขั้นต่ำเท่านั้น ได้แก่ ระบบจัดเก็บข้อมูลสองระบบที่เชื่อมต่อผ่านอีเทอร์เน็ต 10G สวิตช์ 10G สองตัว และโฮสต์หนึ่งตัวที่มองผ่านสวิตช์ที่ระบบจัดเก็บข้อมูลทั้งสองที่มีพอร์ต 10G ผู้ชี้ขาดทำงานบนเครื่องเสมือน
เมื่อกำหนดค่า IP เสมือน (VIP) สำหรับเรพลิกา คุณควรเลือกประเภท VIP - สำหรับเมโทรคลัสเตอร์
เราสร้างลิงก์การจำลองสองลิงก์สำหรับ LUN สองรายการและกระจายไปยังระบบจัดเก็บข้อมูลสองระบบ ได้แก่ LUN TEST Primary บนระบบจัดเก็บข้อมูล 1 (ลิงก์ METRO), LUN TEST2 Primary สำหรับระบบจัดเก็บข้อมูล 2 (ลิงก์ METRO2)
สำหรับพวกเขา เราได้กำหนดค่าสองเป้าหมายที่เหมือนกัน (ในกรณีของเราคือ iSCSI แต่รองรับ FC ด้วย ตรรกะการตั้งค่าก็เหมือนกัน)
ระบบจัดเก็บข้อมูล1:
ระบบจัดเก็บข้อมูล2:
สำหรับการเชื่อมต่อการจำลอง จะมีการแมปบนระบบจัดเก็บข้อมูลแต่ละระบบ
ระบบจัดเก็บข้อมูล1:
ระบบจัดเก็บข้อมูล2:
เราตั้งค่า multipath และนำเสนอต่อโฮสต์
การจัดตั้งอนุญาโตตุลาการ
คุณไม่จำเป็นต้องทำอะไรเป็นพิเศษกับผู้ตัดสิน คุณเพียงแค่ต้องเปิดใช้งานบนไซต์ที่สาม ให้ IP และกำหนดค่าการเข้าถึงผ่าน ICMP และ SSH การตั้งค่านั้นดำเนินการจากระบบจัดเก็บข้อมูลเอง ในกรณีนี้ การกำหนดค่าตัวตัดสินเพียงครั้งเดียวบนตัวควบคุมการจัดเก็บข้อมูลใดๆ ในเมโทรคลัสเตอร์ก็เพียงพอแล้ว การตั้งค่าเหล่านี้จะถูกกระจายไปยังตัวควบคุมทั้งหมดโดยอัตโนมัติ
ในส่วนการจำลองระยะไกล >> Metrocluster (บนคอนโทรลเลอร์ใดๆ) >> ปุ่ม "กำหนดค่า"
เราป้อน IP ของอนุญาโตตุลาการรวมถึงอินเทอร์เฟซการควบคุมของตัวควบคุมที่เก็บข้อมูลระยะไกลสองตัว
หลังจากนี้คุณจะต้องเปิดใช้บริการทั้งหมด (ปุ่ม "รีสตาร์ททุกอย่าง") หากมีการกำหนดค่าใหม่ในอนาคต จะต้องเริ่มบริการใหม่เพื่อให้การตั้งค่ามีผล
เราตรวจสอบว่าบริการทั้งหมดกำลังทำงานอยู่
การตั้งค่าเมโทรคลัสเตอร์จะเสร็จสมบูรณ์
ทดสอบความสนใจ
การทดสอบข้อขัดข้องในกรณีของเราจะค่อนข้างง่ายและรวดเร็ว เนื่องจากฟังก์ชันการจำลองแบบ (การสลับ ความสอดคล้อง ฯลฯ) ได้ถูกกล่าวถึงใน . ดังนั้น เพื่อทดสอบความน่าเชื่อถือของคลัสเตอร์เมโทรคลัสเตอร์ เราก็เพียงพอแล้วที่จะตรวจสอบระบบอัตโนมัติของการตรวจจับความล้มเหลว การสลับ และการไม่มีการสูญเสียในการบันทึก (หยุด I/O)
ในการดำเนินการนี้ เราจำลองความล้มเหลวโดยสิ้นเชิงของระบบจัดเก็บข้อมูลระบบใดระบบหนึ่งโดยการปิดตัวควบคุมทั้งสองตัว โดยเริ่มคัดลอกไฟล์ขนาดใหญ่ไปยัง LUN ก่อน ซึ่งจะต้องเปิดใช้งานบนระบบจัดเก็บข้อมูลอื่น
ปิดการใช้งานระบบจัดเก็บข้อมูลหนึ่งระบบ ในระบบจัดเก็บข้อมูลที่สอง เราเห็นการแจ้งเตือนและข้อความในบันทึกว่าการเชื่อมต่อกับระบบใกล้เคียงขาดหายไป หากมีการกำหนดค่าการแจ้งเตือนผ่านการตรวจสอบ SMTP หรือ SNMP ผู้ดูแลระบบจะได้รับการแจ้งเตือนที่เกี่ยวข้อง
10 วินาทีต่อมา (มองเห็นได้ในภาพหน้าจอทั้งสองภาพ) การเชื่อมต่อการจำลองแบบ METRO (การเชื่อมต่อที่เป็นข้อมูลหลักบนระบบจัดเก็บข้อมูลที่ล้มเหลว) จะกลายเป็นข้อมูลหลักในระบบจัดเก็บข้อมูลที่ใช้งานได้โดยอัตโนมัติ เมื่อใช้การแมปที่มีอยู่ LUN TEST ยังคงใช้งานได้สำหรับโฮสต์ การบันทึกลดลงเล็กน้อย (ภายใน 10 เปอร์เซ็นต์ที่สัญญาไว้) แต่ไม่ถูกขัดจังหวะ
การทดสอบเสร็จสมบูรณ์เรียบร้อยแล้ว
สรุปได้
การใช้งานเมโทรคลัสเตอร์ในปัจจุบันในระบบจัดเก็บข้อมูลซีรีส์ N ของ AERODISK Engine ช่วยให้สามารถแก้ไขปัญหาที่จำเป็นในการกำจัดหรือลดเวลาหยุดทำงานของบริการด้านไอทีได้อย่างเต็มที่ และรับประกันการทำงานตลอด 24 ชั่วโมงทุกวันโดยมีค่าใช้จ่ายด้านแรงงานต่ำที่สุด
แน่นอนว่าเราสามารถพูดได้ว่าทั้งหมดนี้เป็นทฤษฎี สภาพห้องปฏิบัติการในอุดมคติ และอื่นๆ... แต่เรามีโครงการที่ดำเนินการหลายโครงการซึ่งเราได้นำฟังก์ชันการฟื้นตัวจากภัยพิบัติไปใช้ และระบบทำงานได้อย่างสมบูรณ์แบบ หนึ่งในลูกค้าที่มีชื่อเสียงของเราซึ่งใช้ระบบจัดเก็บข้อมูลเพียงสองระบบในการกำหนดค่าป้องกันภัยพิบัติได้ตกลงที่จะเผยแพร่ข้อมูลเกี่ยวกับโครงการแล้ว ดังนั้นในส่วนถัดไปเราจะพูดถึงการดำเนินการรบ
ขอขอบคุณ เราหวังว่าจะได้รับการสนทนาอย่างมีประสิทธิผล
ที่มา: will.com