เฮ้ ฮับ!
หลังจากวันหยุดปีใหม่ เราได้เปิดตัวระบบคลาวด์ป้องกันภัยพิบัติอีกครั้งโดยอิงจากสองไซต์ วันนี้เราจะบอกคุณว่ามันทำงานอย่างไรและแสดงสิ่งที่เกิดขึ้นกับเครื่องเสมือนของไคลเอนต์เมื่อแต่ละองค์ประกอบของคลัสเตอร์ล้มเหลวและไซต์ทั้งหมดล่ม (สปอยล์ - ทุกอย่างเรียบร้อยดี)
ระบบจัดเก็บข้อมูลบนคลาวด์ที่ทนต่อภัยพิบัติบนไซต์ OST
มีอะไรอยู่ข้างใน
ภายใต้ฝากระโปรง คลัสเตอร์มีเซิร์ฟเวอร์ Cisco UCS พร้อมด้วยไฮเปอร์ไวเซอร์ VMware ESXi, ระบบจัดเก็บข้อมูล INFINIDAT InfiniBox F2240 สองระบบ, อุปกรณ์เครือข่าย Cisco Nexus รวมถึงสวิตช์ Brocade SAN คลัสเตอร์แบ่งออกเป็นสองไซต์ - OST และ NORD กล่าวคือ ศูนย์ข้อมูลแต่ละแห่งมีชุดอุปกรณ์ที่เหมือนกัน ที่จริงแล้วนี่คือสิ่งที่ทำให้ทนทานต่อภัยพิบัติ
ภายในไซต์เดียว องค์ประกอบหลักก็จะถูกทำซ้ำเช่นกัน (โฮสต์ สวิตช์ SAN ระบบเครือข่าย)
ทั้งสองไซต์เชื่อมต่อกันด้วยเส้นทางไฟเบอร์ออปติกโดยเฉพาะซึ่งสงวนไว้เช่นกัน
คำไม่กี่คำเกี่ยวกับระบบจัดเก็บข้อมูล เราสร้างคลาวด์ป้องกันภัยพิบัติเวอร์ชันแรกบน NetApp ที่นี่เราเลือก INFINIDAT และนี่คือเหตุผล:
- ตัวเลือกการจำลองแบบ Active-Active ช่วยให้เครื่องเสมือนยังคงทำงานได้แม้ว่าระบบจัดเก็บข้อมูลระบบใดระบบหนึ่งจะล้มเหลวโดยสิ้นเชิงก็ตาม ฉันจะบอกคุณเพิ่มเติมเกี่ยวกับการจำลองแบบในภายหลัง
- ตัวควบคุมดิสก์สามตัวเพื่อเพิ่มความทนทานต่อข้อผิดพลาดของระบบ โดยปกติแล้วจะมีสองคน
- โซลูชั่นพร้อม เราได้รับชั้นวางแบบประกอบไว้ล่วงหน้าซึ่งเพียงต้องเชื่อมต่อกับเครือข่ายและกำหนดค่า
- การสนับสนุนด้านเทคนิคที่เอาใจใส่ วิศวกรของ INFINIDAT วิเคราะห์บันทึกและเหตุการณ์ของระบบจัดเก็บข้อมูล ติดตั้งเฟิร์มแวร์เวอร์ชันใหม่ และช่วยเหลือในการกำหนดค่าอย่างต่อเนื่อง
นี่คือรูปถ่ายบางส่วนจากการแกะกล่อง:
วิธีการทำงาน
คลาวด์มีความทนทานต่อข้อผิดพลาดภายในตัวมันเองอยู่แล้ว ช่วยปกป้องไคลเอนต์จากความล้มเหลวของฮาร์ดแวร์และซอฟต์แวร์ตัวเดียว การต้านทานภัยพิบัติจะช่วยป้องกันความล้มเหลวครั้งใหญ่ภายในไซต์เดียว: ตัวอย่างเช่น ความล้มเหลวของระบบจัดเก็บข้อมูล (หรือคลัสเตอร์ SDS ซึ่งเกิดขึ้นค่อนข้างบ่อย 🙂) ข้อผิดพลาดขนาดใหญ่ในเครือข่ายการจัดเก็บข้อมูล เป็นต้น และที่สำคัญที่สุด: คลาวด์ดังกล่าวจะช่วยประหยัดเวลาเมื่อทั้งไซต์ไม่สามารถเข้าถึงได้เนื่องจากไฟไหม้ ไฟดับ การยึดครองของผู้บุกรุก หรือการลงจอดของเอเลี่ยน
ในกรณีทั้งหมดเหล่านี้ เครื่องเสมือนของไคลเอนต์ยังคงทำงานต่อไป และนี่คือเหตุผล
การออกแบบคลัสเตอร์ได้รับการออกแบบเพื่อให้โฮสต์ ESXi ที่มีเครื่องเสมือนไคลเอ็นต์สามารถเข้าถึงระบบจัดเก็บข้อมูลใดก็ได้จากทั้งสองระบบ หากระบบจัดเก็บข้อมูลบนไซต์ OST ล้มเหลว เครื่องเสมือนจะทำงานต่อไป: โฮสต์ที่เครื่องทำงานอยู่จะเข้าถึงระบบจัดเก็บข้อมูลบน NORD เพื่อหาข้อมูล
นี่คือลักษณะของแผนภาพการเชื่อมต่อในคลัสเตอร์
สิ่งนี้เป็นไปได้เนื่องจากมีการกำหนดค่า Inter-Switch Link ระหว่างแฟบริค SAN ของทั้งสองไซต์: สวิตช์ Fabric A OST SAN เชื่อมต่อกับสวิตช์ Fabric A NORD SAN และในทำนองเดียวกันสำหรับสวิตช์ Fabric B SAN
เพื่อให้ความซับซ้อนทั้งหมดของโรงงาน SAN สมเหตุสมผล การจำลองแบบ Active-Active จึงได้รับการกำหนดค่าระหว่างระบบจัดเก็บข้อมูลทั้งสอง: ข้อมูลจะถูกเขียนไปยังระบบจัดเก็บข้อมูลภายในและระบบจัดเก็บข้อมูลระยะไกลเกือบจะพร้อมกัน RPO = 0 ปรากฎว่าข้อมูลต้นฉบับถูกจัดเก็บไว้ในระบบจัดเก็บข้อมูลระบบหนึ่ง และแบบจำลองของข้อมูลนั้นถูกจัดเก็บไว้ในอีกระบบหนึ่ง ข้อมูลจะถูกจำลองในระดับโวลุ่มการจัดเก็บข้อมูล และข้อมูล VM (ดิสก์ ไฟล์การกำหนดค่า ไฟล์สลับ ฯลฯ) จะถูกจัดเก็บไว้ในข้อมูลเหล่านั้น
โฮสต์ ESXi มองเห็นวอลุ่มหลักและเรพลิกาเป็นอุปกรณ์ดิสก์เดียว (อุปกรณ์จัดเก็บข้อมูล) มี 24 เส้นทางจากโฮสต์ ESXi ไปยังอุปกรณ์ดิสก์แต่ละตัว:
12 เส้นทางเชื่อมต่อกับระบบจัดเก็บข้อมูลในตัวเครื่อง (เส้นทางที่เหมาะสมที่สุด) และอีก 12 เส้นทางเชื่อมต่อกับระบบจัดเก็บข้อมูลระยะไกล (เส้นทางที่ไม่เหมาะสม) ในสถานการณ์ปกติ ESXi เข้าถึงข้อมูลบนระบบจัดเก็บข้อมูลภายในเครื่องโดยใช้เส้นทาง "ที่เหมาะสมที่สุด" เมื่อระบบจัดเก็บข้อมูลนี้ล้มเหลว ESXi จะสูญเสียเส้นทางที่เหมาะสมที่สุดและเปลี่ยนไปใช้เส้นทางที่ "ไม่เหมาะสม" นี่คือลักษณะที่ปรากฏบนแผนภาพ
โครงการคลัสเตอร์ป้องกันภัยพิบัติ
เครือข่ายไคลเอนต์ทั้งหมดเชื่อมต่อกับทั้งสองไซต์ผ่านโครงสร้างเครือข่ายทั่วไป แต่ละไซต์ใช้งาน Provider Edge (PE) ซึ่งเครือข่ายของลูกค้าจะถูกยกเลิก PE จะรวมกันเป็นคลัสเตอร์ทั่วไป หาก PE ล้มเหลวที่ไซต์หนึ่ง การรับส่งข้อมูลทั้งหมดจะถูกเปลี่ยนเส้นทางไปยังไซต์ที่สอง ด้วยเหตุนี้ เครื่องเสมือนจากไซต์ที่เหลือโดยไม่มี PE จึงยังคงสามารถเข้าถึงไคลเอ็นต์ผ่านเครือข่ายได้
ตอนนี้เรามาดูกันว่าจะเกิดอะไรขึ้นกับเครื่องเสมือนไคลเอนต์ในระหว่างความล้มเหลวต่างๆ เริ่มจากตัวเลือกที่เบาที่สุดและจบด้วยความล้มเหลวที่ร้ายแรงที่สุดของทั้งไซต์ ในตัวอย่าง แพลตฟอร์มหลักจะเป็น OST และแพลตฟอร์มสำรองที่มีการจำลองข้อมูลจะเป็น NORD
จะเกิดอะไรขึ้นกับเครื่องเสมือนไคลเอนต์หาก...
ลิงก์การจำลองแบบล้มเหลว การจำลองแบบระหว่างระบบจัดเก็บข้อมูลของทั้งสองไซต์หยุดลง
ESXi จะใช้งานได้กับอุปกรณ์ดิสก์ในเครื่องเท่านั้น (ผ่านเส้นทางที่เหมาะสมที่สุด)
เครื่องเสมือนยังคงทำงานต่อไป
ISL (Inter-Switch Link) พัง คดีนี้ไม่น่าเป็นไปได้ เว้นแต่ว่าจะมีรถขุดบ้าๆ สักคันขุดเส้นทางออพติคัลหลายเส้นทางพร้อมกัน ซึ่งวิ่งบนเส้นทางอิสระและถูกนำไปยังไซต์งานผ่านอินพุตที่แตกต่างกัน แต่อย่างไรก็ตาม. ในกรณีนี้ โฮสต์ ESXi จะสูญเสียเส้นทางครึ่งหนึ่งและสามารถเข้าถึงระบบจัดเก็บข้อมูลในเครื่องเท่านั้น มีการรวบรวมแบบจำลอง แต่โฮสต์จะไม่สามารถเข้าถึงได้
เครื่องเสมือนทำงานได้ตามปกติ
สวิตช์ SAN ล้มเหลวบนไซต์ใดไซต์หนึ่ง โฮสต์ ESXi สูญเสียเส้นทางบางส่วนไปยังระบบจัดเก็บข้อมูล ในกรณีนี้ โฮสต์ที่ไซต์ที่สวิตช์ล้มเหลวจะทำงานผ่าน HBA อันใดอันหนึ่งเท่านั้น
เครื่องเสมือนยังคงทำงานตามปกติ
สวิตช์ SAN ทั้งหมดบนไซต์ใดไซต์หนึ่งล้มเหลว สมมติว่าเกิดภัยพิบัติดังกล่าวบนไซต์ OST ในกรณีนี้ โฮสต์ ESXi บนไซต์นี้จะสูญเสียเส้นทางทั้งหมดไปยังอุปกรณ์ดิสก์ของตน กลไกมาตรฐานของ VMware vSphere HA เข้ามามีบทบาท: โดยจะรีสตาร์ทเครื่องเสมือนทั้งหมดของไซต์ OST ใน NORD ในเวลาสูงสุด 140 วินาที
เครื่องเสมือนที่ทำงานบนโฮสต์ของไซต์ NORD ทำงานได้ตามปกติ
โฮสต์ ESXi ล้มเหลวในไซต์เดียว ที่นี่กลไก vSphere HA ทำงานได้อีกครั้ง: เครื่องเสมือนจากโฮสต์ที่ล้มเหลวจะถูกรีสตาร์ทบนโฮสต์อื่น - บนไซต์เดียวกันหรือระยะไกล เวลารีสตาร์ทเครื่องเสมือนนานถึง 1 นาที
หากโฮสต์ ESXi ทั้งหมดบนไซต์ OST ล้มเหลว จะไม่มีตัวเลือก: VM จะรีสตาร์ทบนโฮสต์อื่น เวลารีสตาร์ทก็เหมือนเดิม
ระบบจัดเก็บข้อมูลล้มเหลวที่ไซต์เดียว สมมติว่าระบบจัดเก็บข้อมูลล้มเหลวที่ไซต์ OST จากนั้นโฮสต์ ESXi ของไซต์ OST จะสลับไปทำงานกับแบบจำลองพื้นที่จัดเก็บข้อมูลใน NORD หลังจากที่ระบบจัดเก็บข้อมูลที่ล้มเหลวกลับมาให้บริการอีกครั้ง การจำลองแบบบังคับจะเกิดขึ้นและโฮสต์ ESXi OST จะเริ่มเข้าถึงระบบที่จัดเก็บข้อมูลในตัวเครื่องอีกครั้ง
เครื่องเสมือนทำงานได้ตามปกติตลอดเวลานี้
หนึ่งในไซต์ล้มเหลว ในกรณีนี้ เครื่องเสมือนทั้งหมดจะถูกรีสตาร์ทบนไซต์สำรองผ่านกลไก vSphere HA เวลารีสตาร์ท VM คือ 140 วินาที ในกรณีนี้ การตั้งค่าเครือข่ายทั้งหมดของเครื่องเสมือนจะถูกบันทึกไว้ และไคลเอนต์ยังคงสามารถเข้าถึงได้ผ่านเครือข่าย
เพื่อให้แน่ใจว่าการรีสตาร์ทเครื่องที่ไซต์สำรองข้อมูลเป็นไปอย่างราบรื่น แต่ละไซต์จะเต็มเพียงครึ่งเดียวเท่านั้น ครึ่งหลังเป็นส่วนสำรองในกรณีที่เครื่องเสมือนทั้งหมดย้ายจากไซต์ที่สองที่เสียหาย
ระบบคลาวด์ที่ทนต่อภัยพิบัติซึ่งใช้ศูนย์ข้อมูล XNUMX แห่งจะช่วยป้องกันความล้มเหลวดังกล่าว
ความสุขนี้ไม่ถูกเนื่องจากนอกเหนือจากทรัพยากรหลักแล้วยังจำเป็นต้องมีการสำรองในเว็บไซต์ที่สองอีกด้วย ดังนั้น บริการที่มีความสำคัญต่อธุรกิจจึงถูกวางไว้บนคลาวด์ดังกล่าว ซึ่งการหยุดทำงานในระยะยาวทำให้เกิดการสูญเสียทางการเงินและชื่อเสียงจำนวนมาก หรือหากระบบข้อมูลอยู่ภายใต้ข้อกำหนดด้านความสามารถในการฟื้นตัวจากภัยพิบัติจากหน่วยงานกำกับดูแลหรือกฎระเบียบภายในของบริษัท
แหล่งที่มา:
ที่มา: will.com