SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

สี่เหตุผลในการใช้กลยุทธ์การหลีกเลี่ยงในความพร้อมใช้งานสูง

by Leave a Comment

สี่เหตุผลในการใช้กลยุทธ์การหลีกเลี่ยงในความพร้อมใช้งานสูง

สี่กลยุทธ์การหลีกเลี่ยงเพื่อปรับปรุงความยืดหยุ่น ประสิทธิภาพ และผลลัพธ์ของคลัสเตอร์

ขั้นตอนง่าย ๆ สำหรับการปรับใช้ในสภาพแวดล้อมคลัสเตอร์ SIOS Protection Suite

 

หลีกเลี่ยงบางสิ่งบางอย่าง – เราทุกคนเคยทำมาก่อนเปลวไฟเก่าที่เราเห็นในร้านขณะเดินไปกับคู่สมรส พนักงานขายเมื่อเรา “ไม่พร้อมที่จะซื้อ” และแม้แต่เจ้านายในขณะที่เราไปเที่ยว “วันหยุด”ตอนที่ฉันเป็นผู้จัดการทีมพัฒนา ฉันได้เห็นรายงานตรงที่เรียกดูในร้านค้าขณะที่พวกเขาควรจะป่วยอยู่นอกสำนักงานพวกเขาหลบอยู่ระหว่างชั้นวางเสื้อผ้าและรีบวิ่งไปตามทางเดินถัดไปและรีบออกไปเราทุกคนเคยทำมาแล้ว และในบางกรณี สำหรับสุขภาพจิต สุขภาพกาย หรือเหตุผลที่ยังคงเป็นเรื่องส่วนตัวและเป็นส่วนตัว เราทุกคนจำเป็นต้องมีมาตรการหลีกเลี่ยงบางอย่างแม้แต่ใน HAดังนั้นคุณจะเพิ่มการหลีกเลี่ยงให้กับ .ได้อย่างไร ความพร้อมใช้งานสูง สิ่งแวดล้อม และทำไม?

สี่เหตุผลในการใช้กลยุทธ์การหลีกเลี่ยงในความพร้อมใช้งานสูง

  • ประสิทธิภาพที่ดีขึ้น (ลดการโอเวอร์โหลดของเซิร์ฟเวอร์)

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

  • การเพิ่มประสิทธิภาพการทำงาน

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

  • การเพิ่มประสิทธิภาพ HA

HA Optimization เป็นอีกสถานการณ์หนึ่งสำหรับการปรับใช้กลยุทธ์การหลีกเลี่ยง เช่นเดียวกับกลยุทธ์การเพิ่มประสิทธิภาพการทำงาน การเพิ่มประสิทธิภาพ HA ถูกใช้เพื่อให้แน่ใจว่าสภาพแวดล้อมของคุณสามารถอยู่รอดได้ในสถานการณ์ความล้มเหลวส่วนใหญ่ และแอปพลิเคชันของคุณได้รับการปรับให้เหมาะสมเพื่อให้ระดับความพร้อมใช้งานสูงสุด ณ เวลาใดเวลาหนึ่งการเพิ่มประสิทธิภาพ HA เป็นสิ่งสำคัญสำหรับแอปพลิเคชัน เช่น SAP ที่มีกระบวนการเข้าคิวที่จำลองแบบในสภาพแวดล้อม SAP ใดๆ คุณไม่ต้องการให้อินสแตนซ์ ASCS (ABAP SAP Central Service) และ ERS (enqueue replication services) อยู่บนเซิร์ฟเวอร์เดียวกันเป็นเวลานานเนื่องจากความเสี่ยงของการล็อกที่สูญหายและงานที่ถูกยกเลิก เพื่อป้องกันไม่ให้สิ่งนี้เกิดขึ้น คุณสามารถใช้กลยุทธ์การหลีกเลี่ยงที่ทำให้อินสแตนซ์ ERS และ ASCS ทำงานบนโหนดคลัสเตอร์ตรงข้ามเสมอพิจารณากรณีของเซิร์ฟเวอร์สามเครื่องที่ใช้ปริมาณงานจริง เรียกว่าเซิร์ฟเวอร์อัลฟ่า เบต้า แกมมาเซิร์ฟเวอร์อัลฟ่ากำลังเรียกใช้อินสแตนซ์ ASCS ในขณะที่เซิร์ฟเวอร์เบต้ากำลังเรียกใช้อินสแตนซ์ ERSServer Gamma ทำหน้าที่เป็นโหนดที่สามสำหรับการเฟลโอเวอร์ของทั้ง Server Beta (ERS) และ Server Alpha (ASCS)หากเบต้าขัดข้อง คุณจะไม่ต้องการให้ทรัพยากร ERS ทำงานบนโหนดเดียวกันกับอินสแตนซ์ ASCSเพื่อให้แน่ใจว่าการดำเนินการนี้ คุณสามารถปรับใช้กลยุทธ์การหลีกเลี่ยงที่จะตรวจสอบโดยอัตโนมัติก่อน และทำให้แน่ใจว่าทั้งสองแอปพลิเคชันอยู่บนเซิร์ฟเวอร์ที่แยกจากกัน และคงไว้ซึ่งแนวทางปฏิบัติที่ดีที่สุดของ SAP ASCS/ERS สำหรับการล็อกเมื่อเกิดข้อผิดพลาด

  • DR หลีกเลี่ยง

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

คุณจะปรับใช้กลยุทธ์การหลีกเลี่ยงอย่างไร

ผู้ให้บริการหลายรายมีกฎความสัมพันธ์ที่สามารถกำหนดค่าได้ ในขณะที่ผู้ให้บริการรายอื่นๆ ใช้ลำดับความสำคัญของเซิร์ฟเวอร์ร่วมกันหรือขั้นตอนที่ต้องทำด้วยตัวเองในกรณีของ SIOS Protection Suite สำหรับ Linux คุณสามารถใช้วิธีการในตัวได้หลายวิธี ได้แก่:

  • การจัดลำดับความสำคัญของทรัพยากร

ในกรณีที่เกิดความล้มเหลว ทรัพยากรจะล้มเหลวไปยังเซิร์ฟเวอร์ที่มีลำดับความสำคัญที่เหลืออยู่ต่ำสุดและต่อไปยังเซิร์ฟเวอร์เพิ่มเติม (อัลฟ่า เบต้า และแกมมา)Server Alpha เป็นเซิร์ฟเวอร์หลักสำหรับ Resource.HR, Server Beta เป็นเซิร์ฟเวอร์หลักสำหรับ Resource.MFG และ Server Gamma เป็นเซิร์ฟเวอร์สำรองสำหรับทรัพยากร/เซิร์ฟเวอร์ทั้งหมดการใช้การจัดลำดับความสำคัญของทรัพยากร Resource.HR จะมีลำดับความสำคัญหนึ่ง (1) ใน Server Alpha และลำดับความสำคัญสอง (2) บน Server Gammaในขณะที่ Resource.MFG สามารถมีลำดับความสำคัญหนึ่ง (1) บนเซิร์ฟเวอร์เบต้าและลำดับความสำคัญสอง (2) บนเซิร์ฟเวอร์ Gammaหากลูกค้าต้องการปรับการใช้สภาพแวดล้อมให้เหมาะสม Resource.HR สามารถมีลำดับความสำคัญสาม (3) บนเซิร์ฟเวอร์เบต้าและทรัพยากร MFG สามารถมีลำดับความสำคัญสาม (3) บนเซิร์ฟเวอร์อัลฟ่าในกรณีที่เซิร์ฟเวอร์อัลฟ่าล้มเหลว ทรัพยากร Resource.HR จะล้มเหลวในเซิร์ฟเวอร์แกมมาก่อนที่จะพยายามเข้ามาใช้บริการ (ถูกกู้คืน) บนเซิร์ฟเวอร์อัลฟ่า

SIOS Protection Suite สำหรับ Linux (UI และ CLI) อนุญาตให้ผู้ใช้ระบุลำดับความสำคัญสำหรับแต่ละเซิร์ฟเวอร์และการรวมทรัพยากร

  • นโยบายหรือกฎความสัมพันธ์

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

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

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

  • แหล่งข้อมูลการหลีกเลี่ยงเฉพาะ

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

สำหรับตัวอย่างเพิ่มเติมของกลยุทธ์การหลีกเลี่ยงและทรัพยากร ให้พิจารณา SIOS Protection Suite สำหรับ Linux เอกสาร .หากลูกค้ามีสองแอปพลิเคชัน ได้แก่ app1 และ app2 ซึ่งพวกเขาต้องการให้ทำงานบนโหนดต่างๆ ทุกครั้งที่ทำได้ ลูกค้าสามารถสร้างทรัพยากรโหนดปลายสุดของเทอร์มินัลการหลีกเลี่ยงได้ 2 รายการโดยใช้ SIOS Protection Suite สำหรับทรัพยากร Linux gen/app และ ‘/opt/LifeKeeper /lkadm/bin/avoid_restore’ สคริปต์

สืบพันธุ์จาก SIOS

 

ข้อมูลเบื้องต้นเกี่ยวกับคลัสเตอร์ – ตอนที่ 2

by Leave a Comment

ข้อมูลเบื้องต้นเกี่ยวกับคลัสเตอร์ - ตอนที่ 2

ข้อมูลเบื้องต้นเกี่ยวกับคลัสเตอร์ – ตอนที่ 2

มีคลัสเตอร์ประเภทใดบ้างและทำงานอย่างไร

ภาพรวมของ HA Clusters และ Load Balancing Clusters

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

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

HA Clustering คืออะไร?

การทำคลัสเตอร์ High Availability หรือที่เรียกว่าการทำคลัสเตอร์ HA มีประสิทธิภาพสำหรับแอปพลิเคชันทางธุรกิจที่สำคัญต่อภารกิจ ระบบ ERP และฐานข้อมูล เช่น SQL Server SAP และ Oracle ที่ต้องการความพร้อมใช้งานเกือบต่อเนื่อง

การจัดกลุ่ม HA สามารถแบ่งออกเป็นสองประเภท ได้แก่ การกำหนดค่า "Active-Active" และการกำหนดค่า Active-Passive

มาดูความแตกต่างระหว่างการทำคลัสเตอร์ HA ทั้งสองประเภทนี้

HA Clustering Type 1: Active-Active Configuration

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

อย่างไรก็ตาม หากแต่ละโหนดทำงานที่เกือบ 100% และโหนดหนึ่งหยุดทำงาน โหนดอื่นจะรับภาระการประมวลผลเพิ่มเติมได้ยาก ดังนั้น การวางแผนกำลังการผลิตที่มีมาร์จิ้นจึงมีความสำคัญสำหรับการทำคลัสเตอร์ HA

HA Clustering Type 2: Active-Standby Configuration

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

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

สององค์ประกอบของการจัดกลุ่ม HA: การใช้งานและการจัดเก็บ

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

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

การรับรู้แอปพลิเคชันเป็นสิ่งสำคัญ

ในทำนองเดียวกัน ERP และแอปพลิเคชันฐานข้อมูลที่ซับซ้อนมีส่วนประกอบหลายส่วนที่ต้องจัดเก็บไว้ในเซิร์ฟเวอร์หรืออินสแตนซ์ที่ถูกต้อง เริ่มทำงานในลำดับที่ถูกต้อง และดำเนินการตามแนวทางปฏิบัติที่ดีที่สุดที่ซับซ้อน เลือกซอฟต์แวร์คลัสเตอร์ที่มีซอฟต์แวร์เฉพาะที่เรียกว่า Application Recovery Kit ที่ออกแบบมาโดยเฉพาะเพื่อรักษาแนวปฏิบัติที่ดีที่สุดสำหรับข้อกำหนดเฉพาะของแอปพลิเคชัน/ฐานข้อมูล

มีหลายวิธีในการกำหนดค่าคลัสเตอร์ HA:

คลัสเตอร์สองโหนดแบบดั้งเดิมพร้อมพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน

 

สองเซิร์ฟเวอร์ถูกคลัสเตอร์ด้วยที่เก็บข้อมูลแบบแบ่งใช้

คลัสเตอร์ไร้ SAN สองโหนด

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

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

คลัสเตอร์บน SAN ที่มีโหนดที่สาม

โหนดที่สามสำหรับการป้องกันภัยพิบัติ

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

คลัสเตอร์โหลดบาลานซ์คืออะไร?

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

การทำคลัสเตอร์ HPC คืออะไร?

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

คุณพร้อมที่จะค้นหาโซลูชันการทำคลัสเตอร์ HA ที่เหมาะสมสำหรับธุรกิจของคุณแล้วหรือยัง?

เรียนรู้เพิ่มเติมเกี่ยวกับการทำคลัสเตอร์ SIOS High Availability ที่นี่ .

 

ข้อมูลเบื้องต้นเกี่ยวกับคลัสเตอร์ – ตอนที่ 1

by Leave a Comment

ข้อมูลเบื้องต้นเกี่ยวกับคลัสเตอร์ – ตอนที่ 1

ข้อมูลเบื้องต้นเกี่ยวกับคลัสเตอร์ – ตอนที่ 1

การจัดกลุ่มในตอนแรกคืออะไร?

เทคโนโลยีการจัดกลุ่มเป็นเทคโนโลยีที่ช่วยให้คุณสามารถเชื่อมต่อเซิร์ฟเวอร์หลายเครื่องเพื่อทำหน้าที่เป็นหน่วยการทำงานเดียว

ประเภทของการจัดกลุ่ม

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

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

ข้อมูลเบื้องต้นเกี่ยวกับคลัสเตอร์
ในคลัสเตอร์เฟลโอเวอร์หน่วยเก็บข้อมูลที่ใช้ร่วมกันแบบดั้งเดิม โหนดหลักและโหนดรองหรือโหนดระยะไกลจะใช้ที่เก็บข้อมูลเดียวกัน

HA คลัสเตอร์

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

ความพร้อมใช้งานสูง

ความพร้อมใช้งานสูงของแอปพลิเคชันคือการวัดระยะเวลาที่แอปพลิเคชันพร้อมใช้งานและใช้งานได้ในปีที่กำหนด โดยทั่วไปแล้ว HA คลัสเตอร์ ให้ความพร้อมใช้งาน 99.99% (สี่เก้า) หรือเวลาหยุดทำงานมากกว่า 52 นาทีเล็กน้อยตลอดทั้งปีที่กำหนด

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

ข้อมูลเบื้องต้นเกี่ยวกับคลัสเตอร์
คลัสเตอร์ SANless ซิงโครไนซ์ที่เก็บข้อมูลในเครื่องโดยใช้การจำลองระดับบล็อกตามโฮสต์

SANless Clusters

อย่างไรก็ตาม หลายบริษัทต้องการใช้คลัสเตอร์ SANless ด้วยเหตุผลหลายประการ ประการแรก พื้นที่เก็บข้อมูลที่ใช้ร่วมกันแสดงถึงจุดล้มเหลวจุดเดียวที่สำคัญ ประการที่สอง พื้นที่จัดเก็บข้อมูลที่ใช้ร่วมกันมักไม่ใช่ตัวเลือกในสภาพแวดล้อมคลาวด์สาธารณะ ประการที่สาม SAN อาจขัดขวางประสิทธิภาพของแอปพลิเคชันฐานข้อมูล เช่น SQL Server, Oracle และ SAP

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

สืบพันธุ์จาก SIOS

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

by Leave a Comment

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

ซอฟต์แวร์คลัสเตอร์

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

ซอฟต์แวร์คลัสเตอร์คืออะไร?

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

ประเภทของซอฟต์แวร์การจัดการคลัสเตอร์

มีโซลูชันซอฟต์แวร์การจัดการคลัสเตอร์ที่หลากหลายสำหรับการกระจาย Windows และ Linux ตัวอย่าง ได้แก่

  • Windows Server Failover Clustering (WSFC),
  • SUSE Linux Enterprise ส่วนขยายความพร้อมใช้งานสูง
  • เรดแฮทคลัสเตอร์สวีท
  • Oracle Real Application Clusters (RAC) และ
  • ซอฟต์แวร์ SIOS

ผลิตภัณฑ์เหล่านี้รองรับระบบปฏิบัติการเดียวหรือต้องใช้ฮาร์ดแวร์ SAN ราคาแพง ยกเว้น SIOS ซึ่งจำกัดความยืดหยุ่นและตัวเลือกการปรับใช้ นอกจากนี้ ส่วนขยาย HA แบบโอเพ่นซอร์สของ Linux ยังต้องการทักษะทางเทคนิคระดับสูง ซึ่งสร้างปัญหาด้านความซับซ้อนและความน่าเชื่อถือที่ท้าทายผู้ปฏิบัติงานส่วนใหญ่

ผลิตภัณฑ์ SIOS ปกป้องแอปพลิเคชันที่ใช้ Windows หรือ Linux ที่ทำงานในสภาพแวดล้อมจริง เสมือน คลาวด์หรือไฮบริด และในสถานการณ์การกู้คืนไซต์หรือการกู้คืนจากภัยพิบัติ แอปพลิเคชันต่างๆ เช่น SAP และฐานข้อมูล รวมถึง Oracle, SQL Server, DB2, SAP HANA และอื่นๆ อีกมากมาย ได้รับประโยชน์จากซอฟต์แวร์ SIOS ความเรียบง่าย "ที่พร้อมใช้งานทันที" ความยืดหยุ่นในการกำหนดค่า ความน่าเชื่อถือ ประสิทธิภาพ และความคุ้มค่าของผลิตภัณฑ์ SIOS ทำให้พวกเขาแตกต่างจากซอฟต์แวร์การทำคลัสเตอร์อื่นๆ

ซอฟต์แวร์คลัสเตอร์ SIOS ให้ความพร้อมใช้งานสูงสำหรับคลัสเตอร์ Windows และ Linux อย่างไร

หากคุณกำลังใช้งานแอปพลิเคชันที่สำคัญในสภาพแวดล้อม Windows หรือ Linux คุณอาจต้องการพิจารณาผลิตภัณฑ์คลัสเตอร์ซอฟต์แวร์ที่มีความพร้อมใช้งานสูงของ SIOS Technology Corporation

ในสภาพแวดล้อมของ Windows SIOS DataKeeper Cluster Edition ผสานรวมกับและขยาย Windows Server Failover Clustering (WSFC) ได้อย่างราบรื่นโดยให้การเพิ่มประสิทธิภาพตามโฮสต์ การจำลองข้อมูล กลไก. ในขณะที่ WSFC จัดการคลัสเตอร์ซอฟต์แวร์ SIOS จะดำเนินการจำลองแบบเพื่อเปิดใช้งานการป้องกันจากภัยพิบัติและรับรองว่าข้อมูลจะสูญหายเป็นศูนย์ในกรณีที่คลัสเตอร์การจัดเก็บข้อมูลที่ใช้ร่วมกันเป็นไปไม่ได้หรือทำไม่ได้ เช่น ในสภาพแวดล้อมการจัดเก็บข้อมูลบนคลาวด์ เสมือน และประสิทธิภาพสูง

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

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

นี่เป็นกรณีศึกษาหนึ่งที่กล่าวถึงวิธีที่ผู้ให้บริการระบบข้อมูลโรงพยาบาล (HIS) ชั้นนำปรับใช้ SIOS DataKeeper Cluster Edition เพื่อปรับปรุงความพร้อมใช้งานสูงและแบนด์วิดท์เครือข่ายในสภาพแวดล้อมคลัสเตอร์ Windows

ผู้ให้บริการ HIS หนึ่งรายปรับปรุง RPO และ RTO ด้วยซอฟต์แวร์คลัสเตอร์ DataKeeper ของ SIOS

ผู้ให้บริการ HIS ชั้นนำรายนี้มีองค์กรด้านการดูแลสุขภาพ (HCO) ในสหรัฐอเมริกามากกว่า 10,000 แห่ง โดยใช้แอปพลิเคชันที่หลากหลาย รวมถึงการจัดการการดูแลผู้ป่วย การบริการตนเองของผู้ป่วย และการจัดการรายได้ เพื่อสนับสนุนลูกค้าเหล่านี้ องค์กรมีคลัสเตอร์ SQL Server มากกว่า 20 คลัสเตอร์ ซึ่งตั้งอยู่ในศูนย์ข้อมูลสองแห่งที่กระจายอยู่ตามภูมิศาสตร์ เช่นเดียวกับเซิร์ฟเวอร์ขนาดเล็กสองสามตัวและการจัดส่งบันทึกของ SQL Server สำหรับ การกู้คืนระบบ (DR).

องค์กรมีฐานลูกค้าขนาดใหญ่และโครงสร้างพื้นฐานด้านไอทีที่กว้างขวาง และต้องการโซลูชันที่สามารถรองรับการรับส่งข้อมูลเครือข่ายจำนวนมาก และขจัดปัญหาแบนด์วิดท์ของเครือข่ายเมื่อจำลองข้อมูลไปยังไซต์ DR องค์กรยังต้องปรับปรุง Recovery Point Objective (RPO) และ Recovery Time Objective (RTO) เพื่อลดปริมาณข้อมูลที่มีความเสี่ยง และช่วยให้ฝ่ายไอทีกลับมาทำงานได้รวดเร็วขึ้นหลังภัยพิบัติหรือระบบล้มเหลว RPO คือจำนวนสูงสุดของการสูญเสียข้อมูลที่สามารถยอมรับได้เมื่อเซิร์ฟเวอร์ล้มเหลว หรือเกิดภัยพิบัติขึ้น RTO คือระยะเวลาสูงสุดที่ยอมรับได้ของการหยุดทำงาน

เพื่อจัดการกับความท้าทายเหล่านี้ องค์กรนี้เลือก SIOS DataKeeper Cluster Edition ซึ่งให้การผสานรวมกับ WSFC ได้อย่างราบรื่น ทำให้สามารถสร้างคลัสเตอร์ SANless ได้

เมื่อ SIOS DataKeeper Cluster Edition ผ่านการทดสอบ POC ที่เข้มงวดขององค์กรแล้ว ทีมไอทีได้ปรับใช้โซลูชันนี้ในสภาพแวดล้อมการผลิตของบริษัท ทีมงานได้ปรับใช้ SIOS ในคลัสเตอร์สามโหนดที่ประกอบด้วยโหนดบน SAN สองโหนดในศูนย์ข้อมูลหลักในองค์กรขององค์กร และโหนด SANless หนึ่งโหนดในไซต์ DR ระยะไกล

โซลูชัน SIOS จะซิงโครไนซ์การจำลองแบบข้ามสามโหนดในคลัสเตอร์และขจัดปัญหาแบนด์วิดท์ที่ไซต์ DR ปรับปรุงทั้ง RPO และ RTO และลดต้นทุนของแบนด์วิดท์ วันนี้ องค์กรใช้ SIOS DataKeeper Cluster Edition เพื่อปกป้องสภาพแวดล้อม SQL Server ของตนในโหนดคลัสเตอร์มากกว่า 18 โหนด

ดูกรณีศึกษาฉบับเต็มเพื่อเรียนรู้เพิ่มเติม .

ซอฟต์แวร์คลัสเตอร์ SIOS ทำงานอย่างไร

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

หากคุณต้องการการจำลองที่รวดเร็ว มีประสิทธิภาพ เพื่อถ่ายโอนข้อมูลผ่านเครือข่ายท้องถิ่นหรือบริเวณกว้างที่มีแบนด์วิดท์ต่ำ SIOS DataKeeper จะปกป้องสภาพแวดล้อม Windows ที่มีความสำคัญทางธุรกิจ รวมถึง Microsoft SQL Server, Oracle, SharePoint, Lync, Dynamics และ Hyper-V จากการหยุดทำงานและ การสูญเสียข้อมูลในสภาพแวดล้อมทางกายภาพ เสมือน หรือระบบคลาวด์

SIOS Protection Suite สำหรับ Linux รองรับการกระจาย Linux หลักทั้งหมด รวมถึง Red Hat Enterprise Linux, SUSE Linux Enterprise Server, CentOS และ Oracle Linux และรองรับสถาปัตยกรรมการจัดเก็บข้อมูลที่หลากหลาย

หากต้องการดูว่าซอฟต์แวร์คลัสเตอร์ SIOS ทำงานอย่างไรเพื่อปกป้องสภาพแวดล้อม Windows และ Linux ขอตัวอย่าง หรือรับ ทดลองฟรี .

เรียนรู้เพิ่มเติมเกี่ยวกับ: การทำคลัสเตอร์ SAP การทำคลัสเตอร์เซิร์ฟเวอร์ SQL Oracle คลัสเตอร์ การทำคลัสเตอร์ Linux ตรวจสอบบล็อกโพสต์ล่าสุดเกี่ยวกับผลิตภัณฑ์การจัดกลุ่มของเรา

อ้างอิง

[1]SIOS ร่วมกับ ActualTech Research, (2018) รายงานการสำรวจความพร้อมใช้งานสูงของ State of Application ทำซ้ำจาก SIOS

พื้นฐานการกู้คืนจากภัยพิบัติ

by Leave a Comment

พื้นฐานการกู้คืนจากภัยพิบัติ

พื้นฐานการกู้คืนจากภัยพิบัติ

ภาพรวมการกู้คืนจากภัยพิบัติ

 

 

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

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

ผลกระทบที่แท้จริงของความล้มเหลวของระบบ

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

ความสำคัญของการฟื้นฟูจากภัยพิบัติ

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

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

ความท้าทายในการกู้คืนจากภัยพิบัติ

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

ความท้าทายที่ 2: ข้อกำหนดแบนด์วิดท์เครือข่าย การจำลองข้อมูลไปยังตำแหน่งภายนอกสำหรับการกู้คืนจากความเสียหายอาจหมายถึงความต้องการแบนด์วิดท์ของเครือข่ายที่เพิ่มขึ้นและปัญหาเวลาแฝง

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

ความท้าทายที่ 4: ขั้นตอนการกู้คืนในขณะที่การกู้คืน หากระบบล่มเนื่องจากภัยพิบัติ จำเป็นต้องกู้คืนบริการ บ่อยครั้ง บริษัทต่างๆ พบว่าข้อมูลของพวกเขากระจัดกระจายอยู่ในหลายที่ และไม่มีขั้นตอนที่เป็นมาตรฐานสำหรับและการกู้คืน ส่งผลให้เสียเวลาและค่าใช้จ่ายมหาศาล การพัฒนาขั้นตอนการบูรณะที่ชัดเจนและได้มาตรฐานจะช่วยขจัดอาการปวดหัวนี้ และช่วยให้ดำเนินการได้อย่างรวดเร็วในยามที่สำคัญที่สุด

การสำรองข้อมูลเทียบกับการป้องกันความพร้อมใช้งาน

ตามธรรมเนียมแล้ว การสำรองข้อมูล – โดยพื้นฐานแล้วเป็นกระบวนการในการทำสำเนาข้อมูลและแอปพลิเคชันและย้ายไปยังตำแหน่งภายนอก – ได้ดำเนินการเพื่อวัตถุประสงค์ในการปกป้องข้อมูลในกรณีที่อุปกรณ์ไอทีขัดข้อง/ล้มเหลว และเพื่อการเก็บบันทึก/การเก็บถาวรตามระเบียบข้อบังคับ ข้อกำหนดเช่น HIPAA (Healthcare Information Portability Accountability Act) ในการกู้คืนการทำงาน เซิร์ฟเวอร์ พื้นที่เก็บข้อมูล และฮาร์ดแวร์อื่นๆ รวมถึงเครือข่ายที่ได้รับผลกระทบจากเหตุการณ์นั้นจำเป็นต้องเปลี่ยนหรือซ่อมแซม เซิร์ฟเวอร์ต้องได้รับการกำหนดค่าและต้องกู้คืนแอปพลิเคชัน นำกลับมาออนไลน์ และเชื่อมต่อกับข้อมูลที่กู้คืน ขั้นตอนเหล่านี้สามารถเป็นเดือน

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

ต่อไปนี้คือสาเหตุทั่วไปบางประการที่แผนการกู้คืนข้อมูลหลังภัยพิบัติที่มีประสิทธิภาพมีความสำคัญ:

ตัวชี้วัดการกู้คืนจากภัยพิบัติ

ตัวชี้วัดหลักสำหรับการกู้คืนจากความเสียหายคือ “RPO” และ “RTO”

RPO (วัตถุประสงค์จุดกู้คืน) RPO ระบุจุดจากเวลาที่เกิดภัยพิบัติจนถึงเวลาที่ผ่านมาที่รับประกันการกู้คืนข้อมูล

ถ้า “RPO = < 5 นาที เมื่อมุ่งหมายสำหรับ “RPO = 0 (ข้อมูลสูญหายเป็นศูนย์)” จำเป็นต้องมีกลไกการป้องกันความพร้อมใช้งาน เช่น การทำคลัสเตอร์เมื่อเกิดข้อผิดพลาด

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

การเลือกวิธีการกู้คืนจากภัยพิบัติ

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

  • ความสำคัญของกระบวนการทางธุรกิจและความอดทนต่อผลกระทบ
  • ชนิดข้อมูลและความจุที่คุณต้องการปกป้อง
  • ข้อกำหนดการกู้คืน – RPO และ RTO . ของคุณ
  • งบประมาณ

มุ่งเน้นไปที่ผลกระทบทางธุรกิจ

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

ชนิดข้อมูลที่ได้รับการป้องกัน (ความสมบูรณ์ของข้อมูล)

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

ในทางกลับกัน ระบบ ERP และฐานข้อมูล เช่น SQL Server, Oracle และ SAP มีบริการและชิ้นส่วนที่หลากหลายซึ่งจำเป็นต้องระบุตำแหน่งบนเซิร์ฟเวอร์เฉพาะ เริ่มทำงานในคำสั่งซื้อเฉพาะ และจัดการตามแนวทางปฏิบัติที่ดีที่สุดเฉพาะแอปพลิเคชันที่หลากหลาย . โดยทั่วไปต้องมีการป้องกันความพร้อมใช้งานสูงและโซลูชันคลัสเตอร์ที่รับรู้แอปพลิเคชันเพื่อจัดการการเฟลโอเวอร์

———————————————————————————————————————

เงื่อนไขการกู้คืนจากภัยพิบัติที่สำคัญ

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

มิเรอร์ที่เก็บข้อมูลแบบซิงโครนัส การรักษาสำเนาการจัดเก็บข้อมูลในเครื่องและระยะไกลให้ตรงกันสำหรับการป้องกัน DR ในวิธีนี้ ข้อมูลจะถูกเขียนไปยังที่จัดเก็บในตัวเครื่องและจำลองแบบทันทีไปยังที่เก็บข้อมูลระยะไกล ที่เก็บข้อมูลในเครื่องจะไม่ “ผูกมัด” จนกว่ากระบวนการเขียนข้อมูลไปยังตำแหน่งระยะไกลจะเสร็จสิ้น กระบวนการนี้ทำให้ทั้งสองสถานที่เหมือนกัน ขจัดความคลาดเคลื่อนที่อาจส่งผลให้หาก data-in-transit ในเวลาที่เกิดเหตุการณ์ไม่สามารถเขียนบนตำแหน่งระยะไกลได้ รับประกันความสมบูรณ์ของข้อมูลระหว่างไซต์หลักและไซต์สำรอง

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

“สแตนด์บายเย็น” และ “สแตนด์บายร้อน”

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

ร้อนสแตนด์บาย นี่เป็นกระบวนการที่ทำให้ระบบรองทำงานและเปลี่ยนไปใช้ระบบสำรองในกรณีที่ระบบหลักหยุดทำงาน

การเปรียบเทียบต้นทุนวิธีการกู้คืนจากภัยพิบัติ

RPO และ RTO ที่เล็กลง เวลาหยุดทำงานสั้นลง แต่ต้นทุนจะเพิ่มขึ้นตามไปด้วย

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

หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับความพร้อมใช้งานสูงและโซลูชันการกู้คืนระบบที่ SIOS คลิก ที่นี่ .