บทนำ

ดังนั้น คุณจึงได้สร้างอินสแตนซ์คลัสเตอร์ล้มเหลวของเซิร์ฟเวอร์ SQL (FCI) หรืออาจเป็นคลัสเตอร์ SAP ASCS/ERS ใน Azure แต่ละโหนดของคลัสเตอร์อยู่ใน Availability Zone (AZ) ที่แตกต่างกัน หรือบางทีคุณอาจมีข้อกำหนดด้านเวลาแฝงที่เข้มงวด และกำลังใช้ Placement Proximity Groups (PPG) และโหนดของคุณทั้งหมดอยู่ใน Availability Set เดียวกัน ไม่ว่าสถานการณ์จะเป็นอย่างไร ตอนนี้คุณมีความพร้อมใช้งานสำหรับแอปพลิเคชันที่สำคัญทางธุรกิจของคุณในระดับที่สูงกว่าการเรียกใช้อินสแตนซ์เพียงตัวเดียว

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

Azure Site Recovery (ASR) เป็นบริการกู้คืนข้อมูลหลังภัยพิบัติ (DRaaS) ของ Microsoft ที่ให้คุณจำลอง VM ทั้งหมดจากภูมิภาคหนึ่งไปยังอีกภูมิภาคหนึ่งได้ นอกจากนี้ยังสามารถจำลองเครื่องเสมือนและเซิร์ฟเวอร์จริงจากภายในองค์กรไปยัง Azure ได้อีกด้วย แต่สำหรับวัตถุประสงค์ของโพสต์ในบล็อกนี้ เราจะเน้นที่ความสามารถของ Azure ภูมิภาคต่อภูมิภาค

การตั้งค่าการกู้คืนไซต์ Azure

เราจะถือว่าคุณได้สร้างคลัสเตอร์ของคุณแล้วโดยใช้ SIOS DataKeeper . ถ้าไม่ ต่อไปนี้คือคำแนะนำบางประการที่จะช่วยให้คุณเริ่มต้นได้

อินสแตนซ์คลัสเตอร์ล้มเหลวด้วย SQL Server บน Azure VMs SIOS DataKeeper Cluster Edition สำหรับดิสก์แชร์คลัสเตอร์ SAP ASCS/SCS เราจะถือว่าคุณคุ้นเคยกับ Azure Site Recovery เป็นอย่างดี แทนที่จะเป็นคำแนะนำอื่นในการตั้งค่า ASR ฉันแนะนำให้คุณอ่านล่าสุด เอกสาร จากไมโครซอฟต์ บทความนี้จะเน้นที่บางสิ่งที่คุณอาจไม่ได้พิจารณาและขั้นตอนเฉพาะที่จำเป็นในการแก้ไขคลัสเตอร์ของคุณหลังจากเฟลโอเวอร์ไปยังซับเน็ตอื่น

ภูมิภาคที่จับคู่

ก่อนที่คุณจะเริ่มต้นเส้นทาง DR คุณควรตระหนักถึงแนวคิดของ Azure Paired Regions ทุกภูมิภาคใน Azure มีภูมิภาค DR ที่ต้องการ หากคุณต้องการเรียนรู้เพิ่มเติมเกี่ยวกับภูมิภาคที่จับคู่ เอกสาร ให้พื้นหลังที่ยอดเยี่ยม มีบางอย่างที่ดีจริงๆ ประโยชน์ ของการใช้ภูมิภาคที่จับคู่ของคุณ แต่จริงๆ แล้วขึ้นอยู่กับคุณที่จะตัดสินใจว่าคุณต้องการใช้ภูมิภาคใดเพื่อโฮสต์ไซต์ DR ของคุณ

ตำแหน่งพยานบนคลาวด์

เมื่อคุณสร้างคลัสเตอร์ในตอนแรก คุณต้องเลือกประเภทพยานสำหรับองค์ประชุมของคุณ คุณอาจเลือก File Share Witness หรือ Cloud Witness โดยปกติพยานประเภทใดประเภทหนึ่งเหล่านี้ควรอยู่ใน AZ ที่แยกจากโหนดคลัสเตอร์ของคุณ

อย่างไรก็ตาม เมื่อคุณพิจารณาว่า ในกรณีที่เกิดภัยพิบัติ คลัสเตอร์ทั้งหมดของคุณจะทำงานในภูมิภาค DR ของคุณ ก็มีตัวเลือกที่ดีกว่า คุณควรใช้พยานบนคลาวด์ และวางไว้ในภูมิภาค DR ของคุณ การให้พยานบนคลาวด์ในภูมิภาค DR ของคุณไม่เพียงแต่ให้ความยืดหยุ่นสำหรับความล้มเหลวของ AZ ในพื้นที่เท่านั้น แต่ยังช่วยปกป้องคุณหากภูมิภาคทั้งหมดล้มเหลว และคุณต้องใช้ ASR เพื่อกู้คืนคลัสเตอร์ของคุณในภูมิภาค DR ด้วยความมหัศจรรย์ของ Dynamic Quorum และ Dynamic Witness คุณสามารถมั่นใจได้ว่าแม้ว่าภูมิภาค DR ของคุณจะออฟไลน์ชั่วคราว จะไม่ส่งผลกระทบต่อคลัสเตอร์การผลิตของคุณ

ความสอดคล้องหลาย VM

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

คะแนนการกู้คืนที่สม่ำเสมอของความผิดพลาด

ไม่รองรับจุดกู้คืนที่สอดคล้องกันของแอปพลิเคชันในคลัสเตอร์ที่จำลองแบบ เมื่อกำหนดค่าตัวเลือกการจำลองแบบ ASR อย่าเปิดใช้งานจุดกู้คืนที่สอดคล้องกันของแอปพลิเคชัน

เก็บที่อยู่ IP ไว้หลังจาก Failover?

เมื่อใช้ ASR เพื่อทำซ้ำไปยังไซต์ DR ของคุณ มีวิธีรักษาที่อยู่ IP ของ VM ไว้เหมือนเดิม Microsoft อธิบายไว้ในบทความเรื่อง รักษาที่อยู่ IP ไว้ระหว่างเกิดข้อผิดพลาด . หากคุณสามารถเก็บที่อยู่ IP ไว้เหมือนเดิมหลังจากเกิดข้อผิดพลาด กระบวนการกู้คืนจะง่ายขึ้น เนื่องจากคุณไม่จำเป็นต้องแก้ไขที่อยู่ IP ของคลัสเตอร์หรือจุดสิ้นสุดมิเรอร์ DataKeeper ซึ่งอิงตามที่อยู่ IP

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

ความพยายามล้มเหลวครั้งแรกของคุณ

แผนฟื้นฟู

เนื่องจากคุณใช้ Multi-VM Consistency คุณต้องเฟลโอเวอร์ VM ของคุณโดยใช้แผนการกู้คืน ดิ เอกสาร ให้คำแนะนำที่ค่อนข้างตรงไปตรงมาเกี่ยวกับวิธีการทำเช่นนั้น แผนการกู้คืนจะจัดกลุ่ม VM ที่คุณต้องการกู้คืนไว้ด้วยกัน เพื่อให้แน่ใจว่าทั้งหมดจะล้มเหลวพร้อมกัน คุณยังสามารถเพิ่ม VM หลายกลุ่มในแผนการกู้คืนเดียวกันได้ เพื่อให้แน่ใจว่าโครงสร้างพื้นฐานทั้งหมดของคุณล้มเหลวอย่างเป็นระเบียบ

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

ที่อยู่ IP แบบคงที่

ในกระบวนการกู้คืน คุณต้องแน่ใจว่า VM ใหม่มีที่อยู่ IP แบบคงที่ คุณจะต้องปรับคุณสมบัติของอินเทอร์เฟซในพอร์ทัล Azure เพื่อให้ VM ใช้ที่อยู่เดียวกันเสมอ หากคุณต้องการเพิ่มที่อยู่ IP สาธารณะให้กับอินเทอร์เฟซ คุณควรดำเนินการในตอนนี้เช่นกัน

การกำหนดค่าเครือข่าย

หลังจากกู้คืน VM ที่จำลองแบบสำเร็จในไซต์ DR แล้ว สิ่งแรกที่คุณต้องทำคือตรวจสอบการเชื่อมต่อพื้นฐาน การกำหนดค่า IP ถูกต้องหรือไม่ อินสแตนซ์ใช้เซิร์ฟเวอร์ DNS ที่ถูกต้องหรือไม่ การแก้ไขชื่อทำงานถูกต้องหรือไม่ คุณสามารถ ping เซิร์ฟเวอร์ระยะไกลได้หรือไม่?

หากมีปัญหาใดๆ กับการสื่อสารเครือข่าย ขั้นตอนที่เหลือที่อธิบายไว้ด้านล่างจะล้มเหลว อย่าข้ามขั้นตอนนี้!

โหลดบาลานเซอร์

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

กลุ่มความปลอดภัยเครือข่าย

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

แก้ไขที่อยู่ IP คลัสเตอร์

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

ทุกคลัสเตอร์มีที่อยู่ IP ของคลัสเตอร์หลัก สิ่งที่คุณจะเห็นหากคุณเปิดใช้ WSFC UI หลังจากเกิดข้อผิดพลาดก็คือคลัสเตอร์จะไม่สามารถเชื่อมต่อได้ เนื่องจากที่อยู่ IP ที่ใช้โดยคลัสเตอร์ไม่ถูกต้องในซับเน็ตใหม่

หากคุณเปิดคุณสมบัติของทรัพยากรที่อยู่ IP นั้น คุณสามารถเปลี่ยนที่อยู่ IP เป็นสิ่งที่ทำงานในเครือข่ายย่อยใหม่ได้ อย่าลืมอัปเดต Network และ Subnet Mask ด้วย

เมื่อคุณแก้ไขที่อยู่ IP นั้นแล้ว คุณจะต้องทำสิ่งเดียวกันกับที่อยู่คลัสเตอร์อื่นๆ ที่คุณใช้ในทรัพยากรคลัสเตอร์ของคุณ

แก้ไขที่อยู่มิเรอร์ของ DataKeeper

มิเรอร์ SIOS DataKeeper ใช้ที่อยู่ IP เป็นจุดสิ้นสุดมิเรอร์ สิ่งเหล่านี้ถูกเก็บไว้ในมิเรอร์และงานมิเรอร์ หากคุณกู้คืนคลัสเตอร์ที่ใช้ DataKeeper ในซับเน็ตอื่น คุณจะเห็นว่ามิเรอร์ปรากฏขึ้นในสถานะรอการซิงค์ใหม่ คุณจะสังเกตเห็นด้วยว่า IP ต้นทางและ IP เป้าหมายสะท้อนถึงซับเน็ตดั้งเดิม ไม่ใช่ซับเน็ตของไซต์ DR

การแก้ไขปัญหานี้เกี่ยวข้องกับการเรียกใช้คำสั่งจาก SIOS ที่เรียกว่า เปลี่ยนจุดสะท้อน . การใช้งาน CHANGEMIRRORENDPOINTS มีดังนี้

emcmd <NEW source IP> CHANGEMIRRORENDPOINTS <volume letter> <ORIGINAL target IP> <NEW source IP> <NEW target IP> ในตัวอย่างของเรา คำสั่งและเอาต์พุตมีลักษณะดังนี้

หลังจากรันคำสั่ง DataKeeper GUI จะได้รับการอัปเดตเพื่อแสดงที่อยู่ IP ใหม่ดังที่แสดงด้านล่าง มิเรอร์ก็จะเข้าสู่สถานะมิเรอร์เช่นกัน

บทสรุป

ตอนนี้คุณได้กำหนดค่าและทดสอบการกู้คืนจากความเสียหายของแอปพลิเคชันที่สำคัญสำหรับธุรกิจของคุณเรียบร้อยแล้วโดยใช้ SIOS DataKeeper ที่ให้ความพร้อมใช้งานสูงและ Azure Site Recovery สำหรับการกู้คืนจากภัยพิบัติ หากคุณมีคำถามหรือต้องการปรึกษากับ SIOS เพื่อช่วยคุณออกแบบและปรับใช้ความพร้อมใช้งานสูงและการกู้คืนจากความเสียหายสำหรับแอปพลิเคชันที่สำคัญทางธุรกิจของคุณ เช่น SQL Server, SAP ASCS และ ERS, SAP HANA, Oracle หรือแอปพลิเคชันที่สำคัญทางธุรกิจอื่นๆ โปรดติดต่อเรา .