เว็บสัมมนา: การรับประกันความพร้อมใช้งานสูงในสภาพแวดล้อมมัลติคลาวด์: บทเรียนจากการหยุดให้บริการของ CrowdStrike

ลงทะเบียนเข้าร่วมสัมมนาออนไลน์แบบ On-Demand

ธุรกิจต่าง ๆ หันมาใช้ผู้ให้บริการระบบคลาวด์หลายรายมากขึ้นเพื่อรักษาความยืดหยุ่นและความสามารถในการปรับขนาด อย่างไรก็ตาม เหตุการณ์ล่าสุด เช่น การหยุดให้บริการของ CrowdStrike แสดงให้เห็นว่าแม้แต่ระบบชั้นนำก็อาจประสบปัญหาได้ โดยเฉพาะอย่างยิ่งกับการอัปเดตและแพตช์ความปลอดภัย เว็บสัมมนาครั้งนี้จะกล่าวถึงแนวทางปฏิบัติที่ดีที่สุดในการนำโซลูชันความพร้อมใช้งานสูง (HA) แบบมัลติคลาวด์มาใช้เพื่อให้แอปพลิเคชันที่สำคัญต่อภารกิจของคุณทำงานได้แม้ในกรณีที่เกิดการหยุดชะงักโดยไม่คาดคิด นอกจากนี้ ยังครอบคลุมถึงกลยุทธ์ต่าง ๆ เพื่อป้องกันไม่ให้ระบบหยุดทำงานเนื่องจากการกำหนดค่าระบบผิดพลาดหรือแพตช์ที่มีปัญหา เพื่อให้แน่ใจว่าคุณสามารถจัดการโครงสร้างพื้นฐานระบบคลาวด์ของคุณได้อย่างมีประสิทธิภาพ

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

พิมพ์ซ้ำโดยได้รับอนุญาตจากSIOS

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

การประมวลผลแบบคลาวด์แพร่หลายไปทั่วในช่วงทศวรรษที่ผ่านมา โดย 99% ขององค์กรใช้ระบบคลาวด์สาธารณะหรือส่วนตัวอย่างน้อยหนึ่งระบบตามรายงาน Flexera 2021 State of the Cloud ในขณะที่ AWS, Microsoft Azure และ GCP เป็นผู้ให้บริการคลาวด์สาธารณะสามอันดับแรกในปัจจุบัน หลายๆ องค์กร—ไม่ว่าจะโดยการออกแบบหรือโดยบังเอิญ—ได้นำกลยุทธ์มัลติคลาวด์มาใช้ ซึ่งช่วยให้พวกเขาสามารถเลือกบริการคลาวด์ใดที่น่าสนใจและเหมาะสมที่สุด ตามความต้องการทางธุรกิจเฉพาะของพวกเขา ตามรายงานของ Flexera 92% ขององค์กรในปัจจุบันมีกลยุทธ์มัลติคลาวด์และใช้คลาวด์สาธารณะเฉลี่ย 2.6 และ 2.7 ไพรเวทคลาวด์ ซึ่งรวมถึง Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) และข้อเสนอ Infrastructure-as-a-Service (IaaS)

---

มัลติคลาวด์คืออะไร?

มัลติคลาวด์เป็นเพียงสภาพแวดล้อมที่ประกอบด้วยคลาวด์สาธารณะและ/หรือไพรเวทคลาวด์ตั้งแต่ 2 ก้อนขึ้นไป (รวมถึง SaaS, PaaS และ IaaS) บริการที่แตกต่างกันในสภาพแวดล้อมแบบมัลติคลาวด์อาจทำงานร่วมกัน (ในกรณีนี้อาจเป็นคลาวด์แบบไฮบริด) หรืออาจไม่จำเป็นต้องทำงานร่วมกัน (โดยพื้นฐานแล้วทำงานเป็นไซโลคลาวด์แยกต่างหาก) โปรดจำไว้ว่า แม้ว่าไฮบริดคลาวด์ทั้งหมดจะเป็นมัลติคลาวด์ แต่มัลติคลาวด์ไม่ใช่ทั้งหมดที่เป็นไฮบริดคลาวด์

---

วิวัฒนาการ (และการยอมรับในวงกว้าง) ของมัลติคลาวด์เป็นกลยุทธ์

สภาพแวดล้อมแบบมัลติคลาวด์ประกอบด้วยการรวมกันของข้อเสนอคลาวด์สาธารณะหรือส่วนตัวอย่างน้อยสองรายการ รวมถึง SaaS, PaaS และ IaaS ดังนั้น กลยุทธ์มัลติคลาวด์ขององค์กรอาจประกอบด้วยปริมาณงานขององค์กรที่ทำงานบน Amazon Elastic Cloud Compute (EC2) และการใช้ Microsoft 365 สำหรับแอปพลิเคชันอีเมลและแบ็คออฟฟิศ หรือองค์กรอาจเชื่อมต่อฐานข้อมูลแบบกำหนดเองที่โฮสต์ในระบบคลาวด์ส่วนตัวกับ Salesforce ซึ่งเป็นข้อเสนอ SaaS บนคลาวด์สาธารณะ

สภาพแวดล้อมคลาวด์แบบไฮบริดประกอบด้วยการผสมผสานระหว่างสภาพแวดล้อมแบบ on-premises, private cloud และ public cloud ตามรายงานของ Flexera องค์กร 80% มีกลยุทธ์ไฮบริดคลาวด์ (ดูรูปที่ 4) สภาพแวดล้อมแบบมัลติคลาวด์มักพัฒนาขึ้นจากระบบไอทีเงา ซึ่งแผนกต่างๆ จัดหาบริการคลาวด์เพื่อตอบสนองความต้องการส่วนบุคคลโดยไม่จำเป็นต้องปรึกษาแผนกไอทีส่วนกลาง ตัวอย่างเช่น ทีมการตลาดของคุณอาจเริ่มใช้ Salesforce นานก่อนที่ฝ่าย IT จะปรับใช้ปริมาณงานแรกใน AWS ในขณะที่แผนกทรัพยากรบุคคลและการเงินของคุณยุ่งอยู่กับการเพิ่ม Workday และ Concur ให้กับแอปพลิเคชัน SaaS ที่องค์กรของคุณพึ่งพาอยู่ในขณะนี้ หรือบางทีคุณอาจมีทีมพัฒนาแอปพลิเคชันที่ทำงานในโครงการต่างๆ ทั่วโลก ทีมพัฒนาทีมหนึ่งอาจชอบ Azure DevOps ในขณะที่อีกทีมอาจชอบเครื่องมือโอเพ่นซอร์สใน AWS ดังนั้น กลยุทธ์มัลติคลาวด์ของคุณอาจพัฒนาขึ้นโดยบังเอิญเท่านั้น ซึ่งไม่จำเป็นต้องเป็นเรื่องเลวร้ายเสมอไป

แผนกต่างๆ ของคุณมีอำนาจในการเลือกโซลูชันที่ดีที่สุดเพื่อตอบสนองความต้องการของพวกเขา ในขณะที่ทีมพัฒนาแอปของคุณสามารถเพิ่มประสิทธิภาพการทำงานสูงสุดและลดเวลาในการทำงานสู่ตลาดในสภาพแวดล้อมการพัฒนาที่พวกเขาต้องการ

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

ภาษาข้อบังคับอาจคลุมเครือและสับสน ตัวอย่างเช่น ระเบียบข้อบังคับของ Financial Conduct Authority (FCA) เกี่ยวกับการว่าจ้างไอทีจากภายนอกระบุว่าบริษัทต้องสามารถ "รู้ว่าพวกเขาจะเปลี่ยนไปใช้ผู้ให้บริการทางเลือกและรักษาความต่อเนื่องทางธุรกิจได้อย่างไร" ข้อความนี้บอกเป็นนัยว่าบริษัทที่ได้รับการควบคุมอย่างน้อยต้องวางแผนสำหรับสภาพแวดล้อมคลาวด์สำรองเป็นอย่างน้อย จากลักษณะที่ไม่ชอบความเสี่ยงของบริษัทที่มีการกำกับดูแลอย่างเข้มงวด ปัญหาประเภทนี้ทำให้หลายบริษัทหันมาใช้กลยุทธ์มัลติคลาวด์

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

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

องค์กรจำนวนมากขึ้นเรื่อยๆ (34% ตามรายงานของ Flexera) ได้ดำเนินการเพิ่มขั้นตอนในการปรับใช้ภาระงานที่มีความสำคัญต่อภารกิจในผู้ให้บริการคลาวด์สาธารณะหลายราย ซึ่งสามารถทำได้ง่ายกว่ามากสำหรับเวิร์กโหลดแบบคงที่ เช่น เว็บไซต์และแอปพลิเคชันที่สามารถทำงานแยกจากกัน สำหรับระบบแบบกระจาย เช่น ฐานข้อมูลและบริการไดเร็กทอรี (เช่น Active Directory) การกู้คืนจากภัยพิบัติแบบมัลติคลาวด์อาจเป็นเรื่องที่ท้าทายกว่ามาก

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

สภาพแวดล้อมแบบมัลติคลาวด์นั้นซับซ้อนกว่าและมีความท้าทายในการจัดการมากกว่าการปรับใช้คลาวด์เดียว ความท้าทายที่ไม่เหมือนใครในสภาพแวดล้อมแบบมัลติคลาวด์ ได้แก่: • การมองเห็นแบบ end-to-end: การตรวจสอบการมองเห็นที่สมบูรณ์เป็นสิ่งที่ท้าทายในสภาพแวดล้อมด้านไอทีใดๆ และมีความซับซ้อนและท้าทายมากขึ้นเป็นทวีคูณในสภาพแวดล้อมแบบมัลติคลาวด์ที่มีไดนามิกสูง อย่างไรก็ตาม การมองเห็นแบบ end-to-end มีความสำคัญอย่างยิ่งต่อการแก้ไขปัญหาด้านประสิทธิภาพและปัญหาคอขวด การรักษาความปลอดภัยรอยเท้าดิจิทัลของคุณ และการระบุจุดที่ล้มเหลวเพียงจุดเดียวในระบบและแอปพลิเคชันที่มีความสำคัญต่อภารกิจ

• การจัดการความปลอดภัยและข้อมูลประจำตัว: แรนซัมแวร์และภัยคุกคามความปลอดภัยทางไซเบอร์อื่นๆ เป็นสิ่งที่ผู้นำด้านไอทีทุกคนนึกถึงในปัจจุบัน ในขณะที่การย้ายไปยังแพลตฟอร์มคลาวด์สาธารณะโดยทั่วไปจะช่วยปรับปรุงท่าทางการรักษาความปลอดภัยขององค์กรโดยการเปลี่ยนความรับผิดชอบด้านความปลอดภัยบางอย่าง (เช่น ศูนย์ข้อมูลและความปลอดภัยทางกายภาพ) ไปยังผู้ให้บริการคลาวด์สาธารณะและให้การเข้าถึงบริการตามต้องการ เช่น การเข้ารหัสและการแบ่งส่วนเครือข่าย มันสามารถ ยังทำให้ง่ายต่อการทำผิดพลาดที่มีราคาแพง ตัวอย่างเช่น การกำหนดค่าเครือข่ายผิดพลาดอาจเป็นเรื่องปกติ—การละเมิดข้อมูลหลายพันรายการเกิดจากบัคเก็ตพื้นที่จัดเก็บ AWS S3 ที่กำหนดค่าไม่ถูกต้อง การจัดการข้อมูลประจำตัวเป็นอีกหนึ่งความท้าทาย ตัวอย่างเช่น Azure Active Directory อาจค่อนข้างคุ้นเคยสำหรับองค์กรที่เคยใช้ Active Directory ในสภาพแวดล้อมภายในองค์กร แต่ขยายการจัดการข้อมูลประจำตัวนอกเหนือจาก Azure ไปยังข้อเสนอ AWS, GCP และ SaaS (เช่น Salesforce, ServiceNow, Workday และอื่นๆ ) สามารถนำเสนอความท้าทายใหม่ๆ

• แอพพลิเคชั่นและการพกพาข้อมูล: ความสามารถในการย้ายแอปพลิเคชันและข้อมูลแบบไดนามิกข้ามแพลตฟอร์มคลาวด์สาธารณะต่างๆ ในสภาพแวดล้อมแบบไฮบริด (มัลติคลาวด์) เป็นกุญแจสำคัญในกลยุทธ์มัลติคลาวด์จำนวนมาก แม้ว่าผู้ให้บริการคลาวด์สาธารณะไม่จำเป็นต้องสร้างบริการของตนเพื่อจำกัดความสามารถในการพกพาแอปพลิเคชันและข้อมูล แต่ก็ไม่จำเป็นต้องทำงานร่วมกันเพื่ออำนวยความสะดวกในความสามารถนี้ และอาจมีค่าใช้จ่ายที่เกี่ยวข้อง ผู้ให้บริการระบบคลาวด์ที่แตกต่างกันยังใช้เทคโนโลยีที่แตกต่างกันสำหรับข้อเสนอบริการต่างๆ

• ไซโลมัลติคลาวด์: หากองค์กรไม่วางแผนและออกแบบการปรับใช้มัลติคลาวด์สำหรับแอปพลิเคชันและความสามารถในการพกพาข้อมูล พวกเขาอาจลงเอยด้วยแอปพลิเคชันและพื้นที่เก็บข้อมูลแบบแยก ซึ่งโดยพื้นฐานแล้วจะสร้างปัญหาทั่วไปขึ้นใหม่ในสภาพแวดล้อมศูนย์ข้อมูลแบบดั้งเดิมในองค์กรบนแพลตฟอร์มคลาวด์ที่หลากหลาย อย่างน้อยที่สุด องค์กรต่างๆ จำเป็นต้องมีเครื่องมือรักษาความปลอดภัยและการจัดการแบบมัลติคลาวด์ที่ช่วยให้สามารถจัดการความเสี่ยงและการใช้งาน/ค่าใช้จ่ายบนแพลตฟอร์มคลาวด์ต่างๆ ได้อย่างมีประสิทธิภาพ

ตามรายงาน Flexera 2021 State of the Cloud 81% ขององค์กรระบุว่าการรักษาความปลอดภัยเป็นความท้าทายสูงสุดในการปรับใช้ระบบคลาวด์ ตามมาด้วยการจัดการค่าใช้จ่ายระบบคลาวด์ (79%) มีองค์กรเพียง 42% เท่านั้นที่ใช้เครื่องมือการจัดการต้นทุนแบบมัลติคลาวด์ และเพียง 38% เท่านั้นที่ใช้เครื่องมือรักษาความปลอดภัยแบบมัลติคลาวด์

จัดการกับความพร้อมใช้งานสูงและการกู้คืนความเสียหายในสภาพแวดล้อมแบบมัลติคลาวด์

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

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

ฉันควรทำอย่างไร?

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

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

ทำซ้ำโดยได้รับอนุญาตจาก SIOS

การจัดการการกู้คืนตามเวลาจริงใน Cloud Outage ที่สำคัญ

ภัยพิบัติเกิดขึ้นทำให้ความเป็นจริงหยุดทำงานกะทันหัน แต่มีหลายสิ่งที่ลูกค้าทุกคนสามารถทำได้เพื่อความอยู่รอดของระบบคลาวด์ สิ่งที่เกิดขึ้น ความล้มเหลว – ทั้งเล็กและใหญ่ – หลีกเลี่ยงไม่ได้ สิ่งที่หลีกเลี่ยงไม่ได้คือการขยายเวลาหยุดทำงาน พิจารณาวันที่ภาคกลางของสหรัฐอเมริกาทางใต้ของ Azure cloud ของ Microsoft ประสบความล้มเหลวอย่างรุนแรง พายุฝนฟ้าคะนองรุนแรงนำไปสู่การเรียงลำดับของปัญหาที่ในที่สุดก็ทำให้ศูนย์ข้อมูลทั้งหมดล้มเหลว ในสิ่งที่บางคนเรียกว่า "The Day the Azure Cloud Fell from the Sky" ลูกค้าส่วนใหญ่ออฟไลน์ไม่ใช่เพียงแค่ไม่กี่วินาทีหรือนาที แต่สำหรับทั้งวัน บางคนออฟไลน์นานกว่าสองวัน ในขณะที่ไมโครซอฟท์ได้กล่าวถึงปัญหาต่าง ๆ ที่นำไปสู่การหยุดทำงาน แต่ผู้เชี่ยวชาญด้านไอทีจะจดจำเหตุการณ์นี้ได้นาน นั่นเป็นข่าวร้าย ข่าวดีก็คือ: มีทุกสิ่งที่ลูกค้า Azure ทุกคนสามารถทำได้เพื่อให้สามารถอยู่รอดได้ในทุกสถานการณ์ อาจมาจากเซิร์ฟเวอร์เดียวที่ล้มเหลวไปจนถึงศูนย์ข้อมูลทั้งหมดที่ออฟไลน์ ในความเป็นจริงลูกค้า Azure ที่ใช้ข้อกำหนดด้านความพร้อมใช้งานสูงและ / หรือการกู้คืนความเสียหายที่สมบูรณ์พร้อมด้วยการจำลองข้อมูลตามเวลาจริงและการล้มเหลวอัตโนมัติที่รวดเร็วสามารถคาดหวังว่าจะไม่มีการสูญหายของข้อมูล ดูเพิ่มเติมที่: Nutanix มองเห็นคลาวด์ขององค์กรที่ชนะการแข่งขันคลาวด์

การจัดการ The Cloud Outage

บทความนี้ตรวจสอบสี่ตัวเลือกสำหรับการให้การกู้คืนความเสียหาย (DR) และความพร้อมใช้งานสูง (HA) ในการกำหนดค่าระบบคลาวด์แบบไฮบริดและ Azure ล้วนๆ ตัวเลือกสองตัวเลือกเฉพาะสำหรับฐานข้อมูล Microsoft SQL Server ซึ่งเป็นแอปพลิเคชั่นยอดนิยมในระบบคลาวด์ Azure อีกสองตัวเลือกคือโปรแกรมไม่เชื่อเรื่องพระเจ้า ตัวเลือกสี่ตัวเลือกซึ่งสามารถใช้ในชุดค่าผสมต่าง ๆ เปรียบเทียบในตารางและรวมถึง:

• บริการ Azure Site Recovery (ASR)
• SQL Server Failover Cluster อินสแตนซ์ที่มีพื้นที่เก็บข้อมูลโดยตรง
• SQL Server บนกลุ่มความพร้อมใช้งานเสมอ
• ซอฟต์แวร์การทำคลัสเตอร์ Failover บุคคลที่สาม

RTO และ RPO 101

ก่อนที่จะอธิบายถึงสี่ตัวเลือกจำเป็นต้องมีความเข้าใจพื้นฐานของตัวชี้วัดสองตัวที่ใช้ในการประเมินประสิทธิภาพของบทบัญญัติ DR และ HA: เวลาในการกู้คืนวัตถุประสงค์และวัตถุประสงค์ของจุดกู้คืน ผู้ที่คุ้นเคยกับ RTO และ RPO สามารถข้ามส่วนนี้ได้ RTO เป็นระยะเวลาที่ยอมรับได้สูงสุดของการหยุดทำงาน โดยทั่วไปแอปพลิเคชันการประมวลผลธุรกรรมออนไลน์มี RTO ที่ต่ำที่สุดและแอปพลิเคชันที่สำคัญต่อภารกิจมักมี RTO เพียงไม่กี่วินาที RPO เป็นช่วงเวลาสูงสุดในระหว่างที่สามารถทนต่อการสูญเสียข้อมูล หากไม่มีการสูญเสียข้อมูลที่ยอมรับได้ RPO จะเป็นศูนย์ ปกติแล้ว RTO จะกำหนดประเภทของการป้องกัน HA และ / หรือ DR ที่จำเป็น เวลาในการกู้คืนที่ต่ำมักจะต้องการบทบัญญัติ HA ที่แข็งแกร่งซึ่งป้องกันระบบปกติและความล้มเหลวของซอฟต์แวร์ในขณะที่ RTOs อีกต่อไปสามารถพึงพอใจกับบทบัญญัติ DR พื้นฐานที่ออกแบบมาเพื่อป้องกันการแพร่กระจายที่แพร่หลายมากขึ้น การจำลองข้อมูลที่ใช้กับบทบัญญัติ HA และ DR สามารถสร้างความต้องการการแลกเปลี่ยนที่เป็นไปได้ระหว่าง RTO และ RPO ในสภาพแวดล้อม LAN ที่มีความหน่วงต่ำซึ่งการจำลองข้อมูลสามารถซิงโครไนซ์ชุดข้อมูลหลักและชุดรองสามารถอัปเดตพร้อมกันได้ สิ่งนี้ช่วยให้การกู้คืนเต็มรูปแบบเกิดขึ้นโดยอัตโนมัติและในเวลาจริงทำให้สามารถตอบสนองเวลาการกู้คืนและวัตถุประสงค์ของจุดกู้คืนที่ต้องการได้มากที่สุด (ไม่กี่วินาทีและศูนย์ตามลำดับ) โดยไม่จำเป็นต้องแลกเปลี่ยน ในทางตรงกันข้ามการบังคับให้หลักรอให้รองเพื่อยืนยันความสมบูรณ์ของการอัปเดตสำหรับทุกธุรกรรมจะส่งผลเสียต่อประสิทธิภาพการทำงาน ด้วยเหตุนี้การจำลองข้อมูลใน WAN จึงมักจะไม่ตรงกัน สิ่งนี้สามารถสร้างการแลกเปลี่ยนระหว่างการรองรับ RTO และ RPO ซึ่งโดยปกติแล้วจะส่งผลให้เวลาการกู้คืนเพิ่มขึ้น นี่คือเหตุผล: เพื่อให้เป็นไปตาม RPO ศูนย์ต้องดำเนินการด้วยตนเองเพื่อให้แน่ใจว่าข้อมูลทั้งหมด (เช่นจากบันทึกธุรกรรม) ได้รับการทำซ้ำอย่างสมบูรณ์ในลำดับที่สองก่อนที่จะเกิดความล้มเหลวเกิดขึ้นความพยายามพิเศษนี้ มักใช้สำหรับ DR ไม่ใช่ HA

บริการ Azure Site Recovery (ASR)

ASR เป็นการนำเสนอ DR-as-a-service (DRaaS) ของ Azure ASR จำลองทั้งเครื่องจริงและเสมือนไปยังไซต์ Azure อื่น ๆ ที่อาจเกิดขึ้นในภูมิภาคอื่น ๆ หรือจากอินสแตนซ์ในสถานที่ไปยังคลาวด์ Azure บริการนี้ให้การกู้คืนที่รวดเร็วพอสมควรจากระบบและสถานที่เกิดเหตุขัดข้องและยังอำนวยความสะดวกในการบำรุงรักษาตามแผนโดยไม่ต้องหยุดทำงานในระหว่างการอัพเกรดซอฟต์แวร์ เช่นเดียวกับข้อเสนอ DRaaS ทั้งหมด ASR มีข้อ จำกัด บางประการการที่ร้ายแรงที่สุดคือการไม่สามารถตรวจจับและล้มเหลวจากความล้มเหลวจำนวนมากที่ทำให้แอปพลิเคชันหยุดทำงานโดยอัตโนมัติ แน่นอนนี่คือเหตุผลที่บริการนี้มีลักษณะเป็น DR และไม่ใช่สำหรับ HA ด้วย ASR เวลาในการกู้คืนจะอยู่ที่ประมาณ 3-4 นาทีซึ่งแน่นอนว่าผู้ดูแลระบบสามารถตรวจจับและตอบสนองต่อปัญหาได้อย่างรวดเร็วด้วยตนเองอย่างไร ตามที่อธิบายไว้ข้างต้นความจำเป็นในการจำลองข้อมูลแบบอะซิงโครนัสข้าม WAN สามารถเพิ่มเวลาการกู้คืนสำหรับแอปพลิเคชันที่มี RPO เป็นศูนย์ต่อไป

SQL Server Failover Cluster Instance พร้อมที่เก็บ Spaces โดยตรง

SQL Server มีตัวเลือก HA / DR ของตัวเองสองตัวเลือก: Failover Cluster Instances (ที่กล่าวถึงที่นี่) และ Always On Groups Availability (ที่กล่าวถึงถัดไป) FCIs มีข้อดีสองประการ: คุณสมบัตินี้มีอยู่ใน Standard Edition ที่ราคาถูกกว่าของ SQL Server และไม่ได้ขึ้นอยู่กับการมีพื้นที่เก็บข้อมูลที่ใช้ร่วมกันเหมือนคลัสเตอร์ HA ดั้งเดิม ข้อได้เปรียบหลังนี้มีความสำคัญเนื่องจากพื้นที่เก็บข้อมูลที่ใช้ร่วมกันนั้นไม่มีอยู่ในระบบคลาวด์ – จาก Microsoft หรือผู้ให้บริการคลาวด์อื่น ๆ ทางเลือกที่ได้รับความนิยมสำหรับการจัดเก็บใน Azure cloud คือ Storage Spaces Direct (S2D) ซึ่งรองรับแอพพลิเคชั่นหลากหลายและการสนับสนุนสำหรับ SQL Server จะปกป้องอินสแตนซ์ทั้งหมด ข้อเสียที่สำคัญของ S2D คือเซิร์ฟเวอร์จะต้องอยู่ในดาต้าเซ็นเตอร์เดียวทำให้ตัวเลือกนี้เหมาะสำหรับความต้องการ HA บางอย่าง แต่ไม่ใช่สำหรับ DR สำหรับการปกป้อง HA และ DR แบบหลายไซต์การจำลองข้อมูลที่จำเป็นจะต้องได้รับจากการจัดส่งบันทึกหรือโซลูชันการทำคลัสเตอร์ล้มเหลวของบุคคลที่สาม

SQL Server บนกลุ่มความพร้อมใช้งานเสมอ

ในขณะที่กลุ่มความพร้อมใช้งานตลอดเวลาเป็นข้อเสนอที่มีความสามารถมากที่สุดของ SQL Server สำหรับทั้ง HA และ DR แต่ต้องมีการออกใบอนุญาต Enterprise Edition ที่มีราคาแพงกว่า ตัวเลือกนี้สามารถส่งมอบเวลาการกู้คืน 5-10 วินาทีและจุดการกู้คืนของวินาทีหรือน้อยกว่า นอกจากนี้ยังมีคุณสมบัติที่สองที่สามารถอ่านได้สำหรับการสืบค้นฐานข้อมูล (ด้วยสิทธิ์ใช้งานที่เหมาะสม) และไม่มีข้อ จำกัด เกี่ยวกับขนาดของฐานข้อมูลหรือจำนวนอินสแตนซ์รอง การกำหนดค่ากลุ่มความพร้อมใช้ตลอดเวลาที่ให้การปกป้องทั้ง HA และ DR ประกอบด้วยการจัดเรียงสามโหนดที่มีสองโหนดในชุดความพร้อมใช้งานหรือโซนเดียวและที่สามในภูมิภาค Azure ที่แยกต่างหาก ข้อ จำกัด หนึ่งที่น่าสังเกตคือมีเพียงฐานข้อมูลเท่านั้นที่ถูกจำลองและไม่ใช่อินสแตนซ์ SQL ทั้งหมดซึ่งต้องได้รับการปกป้องด้วยวิธีการอื่น นอกเหนือจากการเป็นฐานข้อมูลที่ต้องห้ามสำหรับแอพพลิเคชั่นฐานข้อมูลบางตัวแล้วแนวทางนี้ก็มีข้อเสียอีกประการหนึ่ง การใช้งานเฉพาะแอพพลิเคชั่นนั้นต้องใช้แผนกไอทีในการบังคับใช้ข้อกำหนด HA และ DR อื่น ๆ สำหรับแอปพลิเคชันอื่นทั้งหมด การใช้โซลูชัน HA / DR หลายตัวสามารถเพิ่มความซับซ้อนและค่าใช้จ่ายได้อย่างมาก (สำหรับการออกใบอนุญาตการฝึกอบรมการติดตั้งและการใช้งานอย่างต่อเนื่อง) จึงเป็นอีกสาเหตุหนึ่งที่ทำให้องค์กรต้องการใช้โซลูชันของบุคคลที่สาม

ซอฟต์แวร์การทำคลัสเตอร์ Failover บุคคลที่สาม

ด้วยการออกแบบแอพพลิเคชั่นที่ไม่เชื่อเรื่องพระเจ้าและแพลตฟอร์มที่ไม่เชื่อเรื่องพระเจ้าซอฟต์แวร์การทำคลัสเตอร์ล้มเหลวสามารถให้บริการโซลูชั่น HA และ DR ที่สมบูรณ์แบบสำหรับการใช้งานแทบทุกประเภทในสภาพแวดล้อมคลาวด์ส่วนตัวสาธารณะและไฮบริด ซึ่งรวมถึงทั้ง Windows และ Linux การเป็นผู้ไม่เชื่อเรื่องการประยุกต์ใช้ทำให้ไม่จำเป็นต้องมีบทบัญญัติ HA / DR ที่แตกต่างกันสำหรับการใช้งานที่แตกต่างกัน การเป็นผู้ไม่เชื่อเรื่องพระเจ้าบนแพลตฟอร์มทำให้สามารถใช้ประโยชน์จากความสามารถและบริการต่าง ๆ ในระบบคลาวด์ Azure รวมถึง Fault Domains, ชุดความพร้อมใช้งานและเขตพื้นที่, คู่ของภูมิภาคและ Azure Site Recovery ในฐานะที่เป็นโซลูชันที่สมบูรณ์ซอฟต์แวร์จะรวมการจำลองข้อมูลอย่างน้อยตามเวลาจริงการตรวจสอบอย่างต่อเนื่องสามารถตรวจจับความล้มเหลวในระดับแอปพลิเคชันและนโยบายที่กำหนดค่าได้สำหรับการเข้าแทนที่และความล้มเหลว โซลูชันส่วนใหญ่ยังมีความสามารถที่เพิ่มมูลค่าหลากหลายที่ช่วยให้คลัสเตอร์ล้มเหลวสามารถส่งมอบการกู้คืนได้ต่ำกว่า 20 วินาทีโดยมีการสูญเสียข้อมูลน้อยที่สุดหรือไม่มีเลยเพื่อตอบสนองความต้องการ HA / DR ทั้งหมด

ทำให้เป็นจริง

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

เกี่ยวกับ Jonathan Meltzer

Jonathan Meltzer เป็นผู้อำนวยการฝ่ายจัดการผลิตภัณฑ์ของ SIOS Technology เขามีประสบการณ์กว่า 20 ปีในการจัดการผลิตภัณฑ์และการตลาดสำหรับซอฟต์แวร์และผลิตภัณฑ์ SaaS ที่ช่วยให้ลูกค้าสามารถจัดการเปลี่ยนแปลงและเพิ่มประสิทธิภาพทุนมนุษย์และทรัพยากรไอทีของพวกเขา ทำซ้ำจาก RTinsights