Azure Outage Post Mortem ส่วนที่ 2

เกิดอะไรขึ้น? นี่คือบทความ Azure Outage Post Mortem ส่วนที่ 2 ของเรา

โพสต์บล็อกก่อนหน้าของฉันกล่าวว่า Cloud-to-Cloud หรือ Hybrid-Cloud จะทำให้คุณได้รับความเหงามากที่สุดจากปัญหาใด ๆ ที่ CSP สามารถพบได้ อย่างไรก็ตามการหยุดทำงานส่วนใหญ่ที่เกิดจากภัยพิบัติทางธรรมชาตินี้อาจถูกหลีกเลี่ยงได้หากโซนจำหน่ายมีให้บริการในภาคกลางภาคใต้ Microsoft ได้เผยแพร่ RCA เบื้องต้นของวันที่ 4 กันยายน South Central Outage ส่วนที่สำคัญที่สุดของสรุปทั้งหมดนั้นมีดังต่อไปนี้ …

“ลดความซ้ำซ้อนในที่ทำงานมีเหตุการณ์ที่ทำให้เกิดความเย็นที่เกิดขึ้นกับตัวทำละลาย DATACENTER สามารถส่งผลกระทบต่อการทำงานของลูกค้าในเอกสารสำคัญที่ได้รับผลกระทบ”

คุณหมายถึงอะไร?

หากแอ็พพลิเคชันของคุณทำงานในดาต้าเซ็นเตอร์เดียวกันคุณจะเสี่ยงต่อการหยุดทำงานประเภทเดียวกันในอนาคต ในการป้องกันของ Microsoft สิ่งนี้ไม่ควรเป็นข่าวแก่คุณ นี่เป็นจริงเสมอไม่ว่าคุณจะทำงานใน Azure, AWS, Google หรือแม้แต่ดาต้าเซ็นเตอร์ของคุณเอง ความล้มเหลวในการวางแผนล่วงหน้าเกี่ยวกับการจำลองข้อมูลไปยังดาต้าเซ็นเตอร์อื่นและแผนในการกู้คืนแอปพลิเคชันของคุณได้อย่างรวดเร็วก็คือการขาดการวางแผนในส่วนของคุณ Microsoft ไม่ได้เผยแพร่ตำแหน่งที่ตั้งของ Availability Zone ที่แน่นอน หากคุณเชื่อว่าแผนที่นี้เผยแพร่ที่นี่คุณสามารถคาดเดาได้ว่าอาจอยู่ห่างจากที่อื่น ๆ ประมาณ 2-10 ไมล์ ในกรณีทั้งหมด แต่ส่วนใหญ่การจำลองข้อมูลในเขตการให้บริการควรเพียงพอสำหรับการป้องกันข้อมูล แอ็พพลิเคชันบางอย่างเช่น SQL Server ได้สร้างขึ้นในเทคโนโลยีการจำลองแบบ อย่างไรก็ตามสำหรับแอพพลิเคชันระบบปฏิบัติการและชนิดข้อมูลจำนวนมากจะตรวจสอบการจำลองแบบระดับบล็อก SANless cluster solutions โซลูชันคลัสเตอร์ SANless ได้รับการใช้แบบดั้งเดิมสำหรับกลุ่ม multisite แต่เทคโนโลยีเดียวกันนี้ยังสามารถนำมาใช้ในระบบคลาวด์ในโซนการให้บริการภูมิภาคหรือไฮบริดคลาวด์สำหรับความพร้อมใช้งานและการกู้คืนระบบที่มีประสิทธิภาพสูง การใช้คลัสเตอร์ SANless ที่ครอบคลุมเขตการให้บริการไม่ว่าจะเป็น Azure, AWS หรือ Google เป็นกระบวนการที่ค่อนข้างง่ายที่ได้รับเครื่องมือที่เหมาะสม ในฐานะที่เป็นส่วนหนึ่งของการหยุดชันสูตรพลิกศพที่กรุงปักกิ่งที่นี่มีแหล่งข้อมูลไม่กี่อย่างที่จะช่วยให้คุณเริ่มต้น ขั้นตอนทีละขั้นตอน: การกำหนดคอนฟิกคลัสเตอร์เซิร์ฟเวอร์ไฟล์ใน Azure ซึ่งครอบคลุมเขตพื้นที่ให้บริการวิธีสร้างอินสแตนซ์ของคลัสเตอร์ล้มเหลวของ SQL Server แบบ SANless ใน Google Cloud Platform MS SQL Server v.Next บน Linux พร้อมการจำลองแบบและความพร้อมใช้งานสูง #Azure #Cloud #Linux การปรับใช้คลัสเตอร์ล้มเหลวของ Microsoft SQL Server 2014 ใน #Azure Resource Manager (ARM) คลัสเตอร์เซิร์ฟเวอร์ SQL แบบไม่ใช้ SAN ใน AWS คลัสเตอร์ Linux แบบไม่มีการแจ้งเตือนใน AWS Quick Start

บทเรียนจาก Azure Outage Post Mortem

ถ้าคุณอยู่ใน Azure คุณอาจต้องการพิจารณาการกู้คืนไซต์ Azure (ASR) ASR ช่วยให้คุณทำซ้ำ VM ทั้งหมดจากพื้นที่ Azure หนึ่งไปยังพื้นที่อื่น ASR จะทำซ้ำ VMs ของคุณในแบบเรียลไทม์และอนุญาตให้คุณทำแบบทดสอบ DR ที่ไม่ก่อกวนเมื่อใดก็ตามที่คุณต้องการ รองรับเวอร์ชันล่าสุดของ Windows และ Linux และติดตั้งได้ง่ายมาก นอกจากนี้คุณยังสามารถสร้างงานจำลองแบบที่มี “Multi-VM Consistency” ซึ่งหมายความว่าเซิร์ฟเวอร์ต้องได้รับการกู้คืนจากจุดเดียวกันในเวลาที่สามารถรวบรวมไว้ในกลุ่มความสอดคล้องนี้ได้และจะมีจุดการกู้คืนเหมือนกัน ถ้าคุณสร้างคลัสเตอร์ SANless ด้วย DataKeeper ในภูมิภาคเดียวเพื่อความพร้อมใช้งานที่สูงคุณมีสองทางเลือกสำหรับ DR หนึ่งคือคุณสามารถขยาย SANless คลัสเตอร์ของคุณไปยังโหนดในพื้นที่อื่นหรือคุณสามารถใช้ ASR เพื่อทำซ้ำโหนดทั้งสองในกลุ่มที่มีความสอดคล้อง

ความแตกต่างคืออะไร?

การค้าขายกับ ASR ก็คือ RPO และ RTO ไม่ดีเท่าที่คุณจะได้รับจาก SANless multi-site cluster แม้ว่าจะสามารถกำหนดค่าและใช้งานได้ง่ายเพียงใดก็ตาม เพียงระมัดระวัง ถ้าแอพพลิเคชันของคุณเกินกว่า 10 MBps ในการเขียนดิสก์เป็นประจำ ASR จะไม่สามารถติดตามได้ นอกจากนี้กลุ่มที่ใช้พื้นที่เก็บข้อมูล Spaces Direct ไม่สามารถทำซ้ำกับ ASR และโดยทั่วไปไม่มีกลยุทธ์ DR ที่ดีเมื่อใช้ใน Azure ในขณะที่หลังจากดิสก์ที่ได้รับการจัดการได้รับการปล่อยตัว ASR ไม่สนับสนุนพวกเขาทั้งหมดจนกระทั่งประมาณหนึ่งปีต่อมา การสนับสนุนดิสก์ไดรฟ์ที่มีการสนับสนุนอย่างเต็มที่คืออุปสรรคใหญ่สำหรับคนจำนวนมากที่ต้องการใช้ ASR โชคดีตั้งแต่ประมาณเดือนกุมภาพันธ์ปี 2018 ASR สนับสนุนดิสก์ที่มีการจัดการอย่างเต็มที่ อย่างไรก็ตามมีปัญหาอื่น ๆ ที่เพิ่งเปิดตัว ด้วยการเปิดตัวโซนการให้บริการ ASR ถูกจับอีกครั้งหลังเวลา ปัจจุบันพวกเขาไม่สนับสนุน VM ที่ได้รับการติดตั้งในเขตพื้นที่ให้บริการ

ฉันไปข้างหน้าและพยายามมันต่อไป ดูเหมือนว่าจะสามารถกำหนดค่าการจำลองแบบและฉันสามารถทดสอบ failover ได้

ฉันใช้ ASR เพื่อทำซ้ำ SQL1 และ SQL3 จาก Central ไปตะวันออก US 2 และได้ทดสอบ failover. นอกเหนือจากการไม่วาง VMs ใน AZs ใน US US 2 ดูเหมือนว่าจะใช้ได้ผล [/ caption] ฉันหวังจะหาข้อมูลเพิ่มเติมเกี่ยวกับข้อ จำกัด นี้ในการประชุม Ignite ถึงแม้ว่าข้อ จำกัด นี้จะไม่สำคัญเท่ากับ Managed Disk’s เนื่องจากเขตปลอดอากรไม่สามารถใช้ได้อย่างกว้างขวาง ดังนั้นหวังว่า ASR จะรับการสนับสนุนพื้นที่ให้บริการในขณะที่ภูมิภาคอื่น ๆ สว่างขึ้นโซนการให้บริการและมีการใช้กันอย่างแพร่หลายมากขึ้น

อ่านข้อมูลเพิ่มเติมเกี่ยวกับการวิเคราะห์ Azure Outage Post Mortem ที่ได้รับอนุญาตจาก Clusteringformeremortals.com