Date: มกราคม 18, 2018
ฉันถูกถามคำถามนี้มากกว่าสองครั้งดังนั้นฉันคิดว่าฉันจะตอบคำถามนี้ในโพสต์บล็อกฉบับแรกของฉัน คำตอบพื้นฐานคือใช่คุณสามารถสูญเสียข้อมูลในความล้มเหลวที่ไม่คาดคิดเมื่อใช้การจำลองแบบอะซิงโครนัสในคลัสเตอร์แบบ multi-site ในโลกที่เหมาะทุก บริษัท จะมีการเชื่อมต่อกับเครือข่ายไฟเบอร์ออฟติคัลไปยังไซต์ DR ของตนและใช้การจำลองแบบซิงโครนัสกับกลุ่มไซต์หลายแห่งเพื่อลดความเป็นไปได้ที่ข้อมูลจะสูญหาย อย่างไรก็ตามในความเป็นจริงในหลาย ๆ กรณีการเชื่อมต่อ WAN ไปยังไซต์ DR มีความแฝงมากเกินไปเพื่อสนับสนุนการจำลองแบบซิงโครนัส ในกรณีเช่นนี้การจำลองแบบอะซิงโครนัสเป็นทางเลือกที่ดี
มีอยู่มากกว่าสองสามตัวเลือกเมื่อเลือกโซลูชันการจำลองแบบอะซิงโครนัสเพื่อใช้กับคลัสเตอร์ multi-site WSFC ของคุณซึ่งรวมถึงโซลูชันที่ใช้อาร์เรย์จาก บริษัท ต่างๆเช่น EMC IBM HP เป็นต้น และโซลูชันจากโฮสต์เช่นเดียวกับที่ใกล้และเป็นที่รักของฉัน "SteelEye DataKeeper Cluster Edition" ตั้งแต่ฉันรู้ดีที่สุด DataKeeper ฉันจะอธิบายวิธีการทั้งหมดนี้ทำงานจาก DataKeeper ในอนาคต
เมื่อใช้ SteelEye DataKeeper และการจำลองแบบอะซิงโครนัสเราอนุญาตให้มีการเขียนจำนวนหนึ่งที่จะเก็บไว้ในคิว async จำนวนการเขียนที่สามารถจัดคิวได้จะถูกกำหนดโดย "เครื่องหมายน้ำสูง" ซึ่งเป็นค่าที่ปรับได้โดยใช้ DataKeeper เพื่อกำหนดจำนวนข้อมูลที่สามารถอยู่ในคิวก่อนที่สถานะมิเรอร์จะเปลี่ยนจาก "มิเรอร์" เป็น "หยุดชั่วคราว" . สถานะ "หยุดชั่วคราว" จะถูกป้อนด้วยทุกครั้งที่มีข้อผิดพลาดในการสื่อสารระหว่างเซิร์ฟเวอร์รองและเซิร์ฟเวอร์หลัก ในขณะที่อยู่ในสถานะหยุดชั่วคราวการทำงานแบบอัตโนมัติในหลายไซต์จะถูกปิดใช้งานโดย จำกัด จำนวนข้อมูลที่อาจสูญหายไปในความล้มเหลวที่ไม่คาดคิด หากชุดข้อมูลเดิมถือว่า "สูญหายไปตลอด" ข้อมูลที่เหลืออยู่บนเซิร์ฟเวอร์เป้าหมายสามารถปลดล็อกด้วยตนเองและโหนดคลัสเตอร์จะสามารถนำมาใช้งานได้
ขณะที่อยู่ในสถานะ "หยุดชั่วคราว" DataKeeper ช่วยให้คิว async ระบายออกไปจนกว่าเราจะมาถึง "เครื่องหมายน้ำต่ำ" เมื่อถึงจุดนี้กระจกจะเข้าสู่สถานะ "resync" จนกว่าข้อมูลทั้งหมดจะซิงค์กัน เมื่อถึงจุดนั้นกระจกจะอยู่ในสถานะ "mirroring" อีกครั้งและระบบ failover อัตโนมัติจะเปิดใช้งานอีกครั้ง
ตราบเท่าที่ลิงก์ WAN ของคุณไม่อิ่มตัวหรือเสียคุณไม่ควรเห็นมากกว่าเขียนไม่กี่ที่เวลาใดก็ตามในคิว async นี้ ในความล้มเหลวที่ไม่คาดคิด (คิดดึงสายไฟ) คุณจะสูญเสียการเขียนใด ๆ ที่อยู่ในคิว async นี่คือการค้าที่คุณทำเมื่อคุณต้องการเป้าหมายการกู้คืนที่น่าประทับใจ (RPO) และวัตถุประสงค์การกู้เวลา (RTO) ที่คุณได้รับจากกลุ่มไซต์หลายแห่ง แต่ลิงก์ WAN ของคุณมีความล่าช้ามากเกินไปในการสนับสนุนการจำลองแบบซิงโครนัสอย่างมีประสิทธิภาพ
ถ้าคุณใช้เวลาในการตรวจสอบคิว Async DataKeeper ผ่านทางบันทึกผลการปฏิบัติงานของ Windows และการแจ้งเตือนฉันคิดว่าคุณจะต้องประหลาดใจมากที่พบว่าเวลาส่วนใหญ่คิว async ว่างเปล่าเนื่องจากประสิทธิภาพของเครื่องมือจำลองข้อมูลของ DataKeeper แม้ในช่วงที่มีการเขียนอย่างหนักแถว async จะโตขึ้นมากและมักระบายเกือบจะในทันทีดังนั้นจำนวนข้อมูลที่มีความเสี่ยงในเวลาใดก็ตามจึงน้อยที่สุด เมื่อคุณพิจารณาทางเลือกในภัยพิบัติอาจจะเรียกคืนจากการสำรองข้อมูลคืนที่ผ่านมาจำนวนการเขียนที่คุณอาจสูญเสียในความล้มเหลวที่ไม่คาดคิดโดยใช้การจำลองแบบอะซิงโครนัสมีน้อย!
แน่นอนว่ามีบางกรณีที่สูญเสียการเขียนเพียงครั้งเดียวไม่สามารถยอมรับได้ ในกรณีดังกล่าวขอแนะนำให้ใช้ตัวเลือกการจำลองแบบซิงโครไนซ์ของ SteelEye DataKeeper ผ่าน LAN ความเร็วต่ำหรือการเชื่อมต่อ WAN ต่ำ
ทำซ้ำโดยได้รับอนุญาตจาก https://clusteringformeremortals.com/2009/07/