ตัวเลือกสำหรับเมื่อระดับบริการคลาวด์สาธารณะลดลง

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

Caveat Emptor ในก้อนเมฆ

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

ข้อ จำกัด ที่สำคัญ

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

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

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

มีบริการระดับคลาวด์สาธารณะอะไรบ้าง

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

สามตัวเลือกสำหรับการปรับปรุงความพร้อมใช้งานระดับแอปพลิเคชัน

HA / DR

ตัวเลือก HA / DR ที่อาจดูเหมือนว่าง่ายที่สุดในการนำไปใช้นั้นเป็นตัวเลือกที่ออกแบบมาเฉพาะสำหรับแต่ละแอปพลิเคชัน ตัวอย่างที่ดีคือฐานข้อมูล SQL Server ของ Microsoft พร้อมคุณสมบัติ Always On Availability Group ของผู้ให้บริการ อย่างไรก็ตามมีข้อเสียสองประการสำหรับวิธีการนี้ ค่าธรรมเนียมใบอนุญาตที่สูงขึ้นในกรณีนี้สำหรับ Enterprise Edition สามารถทำให้มีราคาแพงสำหรับความต้องการมากมาย และข้อเสียยิ่งกว่านั้นคือความต้องการบทบัญญัติ HA / DR ที่แตกต่างกันสำหรับการใช้งานที่แตกต่างกันซึ่งทำให้การจัดการอย่างต่อเนื่องเป็นการต่อสู้ที่ต่อเนื่อง (และมีค่าใช้จ่าย)

คุณสมบัติที่เกี่ยวข้องกับสถานะการออนไลน์รวมอยู่ในระบบปฏิบัติการ

ตัวเลือกที่สองเพื่อปรับปรุงระดับบริการคลาวด์สาธารณะเกี่ยวข้องกับการใช้คุณสมบัติที่เกี่ยวข้องกับช่วงเวลาที่รวมเข้ากับระบบปฏิบัติการ ยกตัวอย่างเช่นการทำคลัสเตอร์ Windows Server Failover เป็นคุณลักษณะที่ทรงพลังและได้รับการพิสูจน์แล้วซึ่งสร้างไว้ในระบบปฏิบัติการ แต่ด้วยตัวของมันเอง WSFC อาจไม่มีโซลูชัน HA / DR ที่สมบูรณ์เนื่องจากไม่มีคุณสมบัติการจำลองข้อมูล ในระบบคลาวด์ส่วนตัวการจำลองข้อมูลสามารถให้บริการโดยใช้รูปแบบของการจัดเก็บข้อมูลที่ใช้ร่วมกันบางอย่างเช่นเครือข่ายพื้นที่จัดเก็บ แต่เนื่องจากที่เก็บข้อมูลที่ใช้ร่วมกันไม่สามารถใช้ได้ในระบบคลาวด์สาธารณะการใช้การจำลองแบบข้อมูลที่มีประสิทธิภาพจึงต้องใช้ซอฟต์แวร์เชิงพาณิชย์หรือซอฟต์แวร์ที่พัฒนาขึ้นเอง สำหรับ Linux ซึ่งขาดคุณสมบัติเช่น WSFC ความต้องการบทบัญญัติ HA / DR เพิ่มเติมและ / หรือการพัฒนาแบบกำหนดเองนั้นยิ่งใหญ่กว่ามาก การใช้ซอฟต์แวร์โอเพนซอร์สเช่น Pacemaker และ Corosync ต้องมีการสร้าง (และทดสอบ) สคริปต์ที่กำหนดเองสำหรับแต่ละแอปพลิเคชัน สคริปต์เหล่านี้มักจะต้องได้รับการปรับปรุงและทดสอบซ้ำหลังจากมีการเปลี่ยนแปลงเล็กน้อยกับซอฟต์แวร์หรือฮาร์ดแวร์ที่ใช้ แต่เนื่องจากการทำให้ HA สแต็คเต็มรูปแบบทำงานได้ดีสำหรับทุกแอปพลิเคชันอาจเป็นเรื่องยากเป็นพิเศษองค์กรขนาดใหญ่เท่านั้นจึงมีความจำเป็นที่จะต้องพิจารณาความพยายามด้วยซ้ำ

คลัสเตอร์ Failover ที่สร้างขึ้นตามวัตถุประสงค์

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

ประโยชน์ของการแก้ปัญหาเหล่านี้

โซลูชั่นเหล่านี้มีการรวมกันของการจำลองข้อมูลตามเวลาจริงการตรวจสอบแอปพลิเคชันอย่างต่อเนื่องและนโยบายการกู้คืนความล้มเหลว / ล้มเหลวที่กำหนดค่าได้ บางอันที่แข็งแกร่งกว่านั้นมีความสามารถขั้นสูงเพิ่มเติมเช่นตัวเลือกการซิงโครนัสระดับบล็อกหรือแบบอะซิงโครนัสการสนับสนุน Failover Cluster Instances (FCIs) ใน SQL Server Standard Edition ที่ราคาไม่แพงการเพิ่มประสิทธิภาพ WAN การใช้ประโยชน์และการสลับการทำงานด้วยตนเองของการกำหนดเซิร์ฟเวอร์หลักและรองเพื่ออำนวยความสะดวกในการบำรุงรักษาตามแผน แม้ว่าโซลูชันที่ใช้งานทั่วไปเหล่านี้โดยทั่วไปเป็นผู้ไม่เชื่อเรื่องการจัดเก็บ แต่ช่วยให้พวกเขาสามารถทำงานกับเครือข่ายพื้นที่จัดเก็บได้โดยทั่วไปคลัสเตอร์ SAN ล้มเหลวแบบไม่มีอะไรที่ใช้ร่วมกันจะเป็นที่ต้องการโดยขึ้นอยู่กับความสามารถของพวกเขา

การกำหนดค่าการทำคลัสเตอร์แบบล้มเหลวทั่วไปสองแบบ

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

คลัสเตอร์ล้มเหลว SANless สามโหนดนี้มีหนึ่งอินสแตนซ์ของเซิร์ฟเวอร์ที่ใช้งานอยู่และสองอินสแตนซ์ สามารถจัดการกับสองความล้มเหลวพร้อมกันโดยมีเวลาหยุดทำงานน้อยที่สุดและไม่มีการสูญเสียข้อมูล [/ caption] รูปแสดงคลัสเตอร์ล้มเหลว SANless สามโหนดที่ได้รับการปรับปรุงซึ่งให้ความพร้อมใช้งานสูงทั้งห้าและ 9 เช่นเดียวกับคลัสเตอร์สองโหนดการกำหนดค่านี้จะทำงานในสภาพแวดล้อมคลาวด์ส่วนตัวสาธารณะหรือไฮบริด ในตัวอย่างนี้เซิร์ฟเวอร์ # 1 และ # 2 ตั้งอยู่ในดาต้าเซ็นเตอร์องค์กรพร้อมเซิร์ฟเวอร์ # 3 ในคลาวด์สาธารณะ ภายในดาต้าเซ็นเตอร์การจำลองแบบข้าม LAN สามารถซิงโครนัสอย่างเต็มที่เพื่อลดเวลาที่ใช้ในการทำ failover ให้เสร็จสมบูรณ์ ดังนั้นเพิ่มความพร้อมใช้งานสูงสุด เมื่อกำหนดค่าอย่างเหมาะสมคลัสเตอร์ล้มเหลวสามโหนด SANless จะจ่าย HA และ DR ระดับผู้ให้บริการอย่างแท้จริง การดำเนินการขั้นพื้นฐานนั้นไม่เชื่อเรื่องแอปพลิเคชันและทำงานเหมือนกันสำหรับ Windows หรือ Linux เซิร์ฟเวอร์ # 1 เป็นอินสแตนซ์หลักหรืออินสแตนซ์ที่ใช้งานอยู่ซึ่งทำซ้ำข้อมูลอย่างต่อเนื่องไปยังเซิร์ฟเวอร์ # 2 และ # 3 หากพบความล้มเหลวแอปพลิเคชันจะล้มเหลวโดยอัตโนมัติไปยังเซิร์ฟเวอร์ # 2 ซึ่งจะกลายเป็นข้อมูลการเรพลิเคทหลักไปยังเซิร์ฟเวอร์ # 3 โดยอัตโนมัติ

การฟื้นตัว

ทันทีหลังจากความล้มเหลวในเซิร์ฟเวอร์ # 1 เจ้าหน้าที่ IT จะเริ่มวินิจฉัยและซ่อมแซมสิ่งที่ทำให้เกิดปัญหา เมื่อแก้ไขแล้วเซิร์ฟเวอร์ # 1 สามารถเรียกคืนเป็นอุปกรณ์หลักที่มีความล้มเหลวด้วยตนเองหรือเซิร์ฟเวอร์ # 2 สามารถทำงานต่อได้ในฐานะข้อมูลจำลองหลักไปยังเซิร์ฟเวอร์ # 1 และ # 3 หากเซิร์ฟเวอร์ # 2 ล้มเหลวก่อนที่เซิร์ฟเวอร์ # 1 จะกลับสู่การดำเนินการตามที่แสดงเซิร์ฟเวอร์ # 3 จะกลายเป็นเซิร์ฟเวอร์หลัก เนื่องจากเซิร์ฟเวอร์ # 3 อยู่ฝั่ง WAN ในคลาวด์สาธารณะการเรพลิเคทข้อมูลแบบอะซิงโครนัสและการเฟลโอเวอร์เป็นคู่มือเพื่อป้องกัน "การจำลองแบบล่าช้า" จากการสูญเสียข้อมูลใด ๆ ซอฟต์แวร์การทำคลัสเตอร์ failover SANless สามารถตรวจสอบความล้มเหลวที่เป็นไปได้ทั้งหมดในระดับแอปพลิเคชัน สามารถเอาชนะข้อ จำกัด และการยกเว้น CSP ที่กล่าวถึงข้างต้นได้อย่างง่ายดาย ดังนั้นจึงเป็นไปได้ที่การกำหนดค่าสามโหนดนี้จะถูกปรับใช้ทั้งหมดภายในคลาวด์สาธารณะ เพื่อให้มีความพร้อมใช้งานสูง 5-9 ของเดียวกันโดยพิจารณาจากความล้มเหลวทันทีและอัตโนมัติเซิร์ฟเวอร์ # 1 และ # 2 จะต้องอยู่ภายในโซนเดียวหรือภูมิภาคที่ LAN รองรับการจำลองแบบซิงโครนัส สำหรับการป้องกัน DR ที่เหมาะสมเซิร์ฟเวอร์ # 3 ควรอยู่ในดาต้าเซ็นเตอร์หรือภูมิภาคอื่นซึ่งจำเป็นต้องใช้การจำลองแบบอะซิงโครนัสและการเฟลโอเวอร์ / ความล้มเหลวด้วยตนเองซึ่งจำเป็นสำหรับแอปพลิเคชันที่ต้องการปริมาณงานสูง คลัสเตอร์สามโหนดยังสามารถอำนวยความสะดวกในการบำรุงรักษาฮาร์ดแวร์และซอฟต์แวร์ที่วางแผนไว้สำหรับเซิร์ฟเวอร์ทั้งสามเครื่อง ในขณะเดียวกันก็ให้การป้องกัน DR อย่างต่อเนื่องสำหรับแอปพลิเคชันและข้อมูลของมัน ด้วยการนำเสนอดาต้าเซ็นเตอร์ที่กระจายตัวอยู่ในพื้นที่หลายแห่งทำให้ระบบคลาวด์สาธารณะสามารถสร้างโอกาสมากมายในการปรับปรุงความพร้อมใช้งาน ซอฟต์แวร์การทำคลัสเตอร์ล้มเหลวของ SANless ทำให้การใช้ทรัพยากรการคำนวณการจัดเก็บและเครือข่ายทั้งหมดมีประสิทธิภาพและประสิทธิผล มันยังง่ายต่อการติดตั้งและใช้งาน โซลูชั่นที่สร้างขึ้นตามวัตถุประสงค์เหล่านี้จะลดค่าใช้จ่ายด้านทุนและการดำเนินงานทั้งหมด ในที่สุดส่งผลให้มีความพร้อมใช้งานสูงมีประสิทธิภาพมากขึ้นและราคาไม่แพงมากขึ้นกว่าเดิม # # #

เกี่ยวกับผู้แต่ง

Cassius Rhue เป็นผู้อำนวยการฝ่ายวิศวกรรมของ SIOS Technology  เขาเป็นผู้นำการพัฒนาผลิตภัณฑ์ซอฟต์แวร์และทีมวิศวกรรมในเล็กซิงตัน Cassius มีประสบการณ์ด้านวิศวกรรมการพัฒนาและการทดสอบมากกว่า 17 ปี นอกจากนี้เขายังสำเร็จการศึกษาระดับปริญญาตรีสาขาวิศวกรรมคอมพิวเตอร์จากมหาวิทยาลัยเซาท์แคโรไลนา