คู่มือการประเมิน SIOS Protection Suite สำหรับ Linux สำหรับสภาพแวดล้อม AWS Cloud

เริ่มต้นการประเมิน SIOS Protection Suite สำหรับ Linux ใน AWS

ใช้คำแนะนำทีละขั้นตอนนี้เพื่อกำหนดค่าและทดสอบคลัสเตอร์สองโหนดใน AWS เพื่อปกป้องทรัพยากร เช่น Oracle, SQL Server, PostgreSQL, NFS, SAP และ SAP HANA

ก่อนที่คุณจะเริ่มการประเมินของคุณ

ตรวจสอบลิงก์เหล่านี้เพื่อทำความเข้าใจแนวคิดหลักที่คุณต้องการก่อนเริ่มโครงการคลัสเตอร์เมื่อเกิดข้อผิดพลาดใน AWS

• ความพร้อมใช้งานสูง RTO , และ RPO – ได้รับความเข้าใจที่ชัดเจนเกี่ยวกับแนวคิดพื้นฐานของ HA

• SIOS Protection Suite สำหรับ Linux – ส่วนประกอบแบบบูรณาการ – ทำความเข้าใจส่วนประกอบที่รวมอยู่ใน SIOS Protection Suite: SIOS LifeKeeper, DataKeeper และชุดการกู้คืนแอปพลิเคชัน/

• ประโยชน์ของ SIOS ชุดป้องกันสำหรับ Linux – เรียนรู้ว่า SIOS Protection Suite สำหรับ Linux ให้การปกป้องข้อมูลที่เหนือกว่าอย่างไร

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

• แพลตฟอร์มคลาวด์สาธารณะและความแตกต่างของโครงสร้างเครือข่าย – ผู้ให้บริการคลาวด์สาธารณะมีโครงสร้างเครือข่ายของตนเอง เรียนรู้พื้นฐานว่าโครงสร้างเหล่านี้ส่งผลต่อการกำหนดค่าคลัสเตอร์ของคุณอย่างไร

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

• การจำลองข้อมูลระหว่างโหนดทำงานอย่างไร– การตรวจสอบความซ้ำซ้อนของการจัดเก็บเป็นสิ่งสำคัญ เรียนรู้วิธีที่ SIOS DataKeeper จำลองข้อมูลระหว่างโหนดอย่างมีประสิทธิภาพ

• “Split Brain” คืออะไรและจะหลีกเลี่ยงได้อย่างไร เรียนรู้วิธีดูแลให้คุณรักษาโหนดที่ใช้งานอยู่หนึ่งโหนดและโหนดสแตนด์บายอย่างน้อยหนึ่งโหนด แม้ว่าการเชื่อมต่อเครือข่ายจะล้มเหลว

การกำหนดค่าส่วนประกอบเครือข่าย

ส่วนนี้สรุปทรัพยากรการคำนวณที่จำเป็นสำหรับแต่ละโหนด โครงสร้างเครือข่าย และกระบวนการที่จำเป็นในการกำหนดค่าส่วนประกอบเหล่านี้

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

การสร้างอินสแตนซ์บน AWS EC2 จาก Scratch

• การสร้างอินสแตนซ์บน AWS จาก Scratch
• สลับไปมาระหว่าง AWS บริการ
• กำลังตัดสินใจ AWS ภูมิภาค
• การสร้าง VPC
• การสร้างซับเน็ต
• การสร้างอินเทอร์เน็ตเกตเวย์และกำหนดให้กับ VPC
• การสร้างตารางเส้นทาง
• การสร้างกลุ่มความปลอดภัย
• การสร้างอินสแตนซ์ EC2 แรก
• การสร้างอินสแตนซ์ที่สองและสาม

กำหนดค่า Linux Nodes เพื่อเรียกใช้ SIOS Protection Suite สำหรับ Linux

• กำหนดค่า Linux Nodes เพื่อเรียกใช้ SIOS Protection Suite สำหรับ Linux

ติดตั้ง SIOS Protection Suite สำหรับ Linux

• ติดตั้ง SIOS Protection Suite สำหรับ Linux

เข้าสู่ระบบและการกำหนดค่าพื้นฐาน

• เข้าสู่ระบบและการกำหนดค่าพื้นฐาน

การปกป้องทรัพยากรที่สำคัญ

• การสร้างทรัพยากร IP ในan สภาพแวดล้อมภายในองค์กร
• การสลับระหว่างโหนดใน a สภาพแวดล้อมคลาวด์

เมื่อทรัพยากร IP ได้รับการป้องกันแล้ว ให้เริ่มต้นสวิตช์ (โดยที่โหนด "สแตนด์บาย" จะกลายเป็นโหนด "ใช้งานอยู่") เพื่อทดสอบการทำงาน

• วิธีเปลี่ยนไปใช้โหนดสแตนด์บายเพื่อยืนยันว่าการสลับทำงานอยู่
• การปกป้องทรัพยากร Oracle
• ปกป้อง MSSQL การใช้การป้องกันบริการด่วน
• การปกป้องทรัพยากร PostgreSQL
• ปกป้องและ NFS ทรัพยากร
• ปกป้อง SAP ทรัพยากร
• ปกป้อง SAP ฮานะ ทรัพยากร

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

ประสิทธิภาพของ Azure Shared Disk พร้อม Zone Redundant Storage (ZRS)

เมื่อวันที่ 9 กันยายน 2564 Microsoft ประกาศ ความพร้อมใช้งานทั่วไปของ Zone-Redundant Storage (ZRS) สำหรับ Azure Disk Storage รวมถึง Azure Shared Disk

สิ่งที่ทำให้สิ่งนี้น่าสนใจคือตอนนี้คุณสามารถสร้างอินสแตนซ์คลัสเตอร์ล้มเหลวที่จัดเก็บข้อมูลที่ใช้ร่วมกันซึ่งครอบคลุม Availability Zone (AZ)ด้วยโหนดคลัสเตอร์ที่อยู่ใน AZ ต่างๆ ผู้ใช้จึงมีสิทธิ์ได้รับ SLA ความพร้อมใช้งาน 99.99% ก่อนที่จะรองรับ Zone Redundant Storage นั้น Azure Shared Disks รองรับ Locally Redundant Storage (LRS) เท่านั้น ซึ่งจำกัดการปรับใช้คลัสเตอร์เป็น AZ เดียว ทำให้ผู้ใช้เสี่ยงต่อไฟดับหาก AZ ออฟไลน์

อย่างไรก็ตาม มีข้อจำกัดบางประการที่ต้องระวังเมื่อปรับใช้ Azure Shared Disk กับ ZRS

• รองรับเฉพาะไดรฟ์โซลิดสเทตระดับพรีเมียม (SSD) และ SSD มาตรฐานเท่านั้น ไม่รองรับดิสก์ Azure Ultra
• ปัจจุบัน Azure Shared Disk ที่มี ZRS พร้อมให้บริการในภูมิภาค West US 2, West Europe, North Europe และ France Central เท่านั้น
• Disk Caching ทั้งอ่านและเขียนไม่รองรับ Premium SSD Azure Shared Disks
• การระเบิดดิสก์ไม่พร้อมใช้งานสำหรับ SSD ระดับพรีเมียม
• การสนับสนุน Azure Site Recovery ยังไม่พร้อมใช้งาน
• Azure Backup พร้อมใช้งานผ่าน Azure Disk Backup เท่านั้น
• รองรับการเข้ารหัสฝั่งเซิร์ฟเวอร์เท่านั้น ในขณะนี้ไม่รองรับการเข้ารหัสดิสก์ Azure

ฉันยังพบบันทึกที่น่าสนใจใน เอกสาร .

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

ตามคำแนะนำในเอกสาร ฉันใช้ DiskSpd เพื่อวัดเวลาแฝงในการเขียนเพิ่มเติมที่คุณอาจพบ แน่นอนว่าผลลัพธ์จะแตกต่างกันไปตามปริมาณงาน ประเภทดิสก์ ขนาดอินสแตนซ์ ฯลฯ แต่นี่คือผลลัพธ์ของฉัน

	พื้นที่จัดเก็บซ้ำซ้อนในเครื่อง (LRS)	พื้นที่จัดเก็บซ้ำซ้อน (ZRS)
เขียน IOPS	5099.82	4994.63
เวลาในการตอบสนองเฉลี่ย	7.830	7.998

การทดสอบ DiskSpd ที่ฉันเรียกใช้ใช้พารามิเตอร์ต่อไปนี้

diskspd -c200G -w100 -b8K -F8 -r -o5 -W30 -d10 -Sh -L testfile.dat ฉันเขียนไปยังดิสก์ P30 ที่มี ZRS และ P30 พร้อม LRS ที่ต่อกับ Standard DS3 v2 (4 vcpus, หน่วยความจำ 14 GiB ) ประเภทอินสแตนซ์ นอกจากนี้ ZRS P30 ที่แชร์ยังแนบกับอินสแตนซ์ที่เหมือนกันใน AZ อื่น และเพิ่มเป็นที่จัดเก็บข้อมูลที่ใช้ร่วมกันในแอปพลิเคชันคลัสเตอร์ที่ว่างเปล่า

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

นี่คือผลลัพธ์

	พื้นที่จัดเก็บซ้ำซ้อนในเครื่อง (LRS)	พื้นที่จัดเก็บซ้ำซ้อน (ZRS)	ZRS เมื่อเขียนจาก AZ . ระยะไกล
เขียน IOPS	5099.82	4994.63	4079.72
เวลาในการตอบสนองเฉลี่ย	7.830	7.998	9.800

ในสถานการณ์นั้น ฉันวัดเวลาแฝงในการเขียนที่เพิ่มขึ้น 25% หากคุณพบความล้มเหลวโดยสมบูรณ์ของ AZ ทั้งพื้นที่จัดเก็บและอินสแตนซ์จะเฟลโอเวอร์ไปยัง AZ สำรอง และคุณไม่ควรพบกับเวลาแฝงที่เพิ่มขึ้นนี้เลย อย่างไรก็ตาม สถานการณ์ความล้มเหลวอื่นๆ ที่ไม่ได้ครอบคลุม AZ อาจทำให้แอปพลิเคชันแบบคลัสเตอร์ของคุณทำงานใน AZ เดียวโดยมี Azure Shared Disk ทำงานใน AZ อื่น ในสถานการณ์เหล่านี้ คุณจะต้องย้ายเวิร์กโหลดแบบคลัสเตอร์ของคุณกลับไปยังโหนดที่อยู่ใน AZ เดียวกันกับที่เก็บข้อมูลของคุณโดยเร็วที่สุดเพื่อหลีกเลี่ยงโอเวอร์เฮดเพิ่มเติม

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

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

ฉันหวังว่าในอนาคต Microsoft จะอนุญาตให้ผู้ใช้เริ่มต้นการเฟลโอเวอร์ด้วยตนเองของดิสก์ ZRS เช่นเดียวกับที่ทำกับ GRS เหตุผลที่พวกเขาเพิ่มคุณลักษณะนี้ให้กับ GRS ก็คือการให้อำนาจแก่ผู้ใช้ในกรณีที่เกิดข้อผิดพลาดโดยอัตโนมัติไม่เกิดขึ้นตามที่คาดไว้ ในกรณีของ Zone Redundant Storage ฉันเห็นว่าผู้คนต้องการลองเชื่อมโยงพื้นที่จัดเก็บและแอปพลิเคชันเข้าด้วยกัน เพื่อให้มั่นใจว่าพวกเขาจะทำงานใน AZ เดียวกันเสมอ คล้ายกับวิธีที่โซลูชันการจำลองแบบอิงโฮสต์ เช่น SIOS DataKeeper ทำ

ความพร้อมใช้งาน SLA: FT ความพร้อมใช้งานสูงและการกู้คืนจากภัยพิบัติ – จะเริ่มต้นที่ไหน

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

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

แนวคิดเกี่ยวกับความพร้อมใช้งานด้านไอทีจำนวนมากถูกกล่าวถึงเช่น ความทนทานต่อความผิดพลาด (FT) , ความพร้อมใช้งานสูง (ฮา) และ การกู้คืนระบบ (DR) .แต่สิ่งนี้สามารถทำให้เกิดคำถามเพิ่มเติมอะไรคือความแตกต่างระหว่างแนวคิดเกี่ยวกับความพร้อมใช้งานเหล่านี้?ข้อใดจะเหมาะกับโครงสร้างพื้นฐานของฉันสามารถรวมกันหรือเปลี่ยนได้หรือไม่? ขั้นตอนแรกและสำคัญที่สุดสำหรับความคิดริเริ่มด้านความพร้อมใช้งานใดๆ คือการสร้างข้อตกลงระดับบริการความพร้อมใช้งานของแอปพลิเคชัน/ฐานข้อมูล (SLA) ที่ชัดเจนสิ่งนี้จะกำหนดแนวทางความพร้อมใช้งานที่เหมาะสมที่สุด

SLA คืออะไร?

ในระดับหนึ่ง เราทุกคนรู้ดีว่า SLA คืออะไร แต่สำหรับการสนทนานี้ ให้ตรวจสอบให้แน่ใจว่าเราอยู่ในความยาวคลื่นเดียวกัน SLA ความพร้อมใช้งานคือสัญญาระหว่างผู้ให้บริการและผู้ใช้ปลายทางซึ่งกำหนดระดับที่คาดหวังของเวลาทำงานของแอปพลิเคชัน/ฐานข้อมูลและความสามารถในการเข้าถึงที่ผู้ขายจะต้องรับรองและร่างบทลงโทษที่เกี่ยวข้อง (โดยปกติคือด้านการเงิน) หากระดับบริการที่ตกลงกันไว้ไม่ พบกันในโลกไอทีนั้น SLA ถูกสร้างขึ้นจากมาตรการสำคัญสองประการต่อธุรกิจ – Recovery Time Objectives (RTO) และ Recovery Point Objectives (RPO)พูดง่ายๆ ก็คือ RTO กำหนดว่าเราต้องการการกู้คืนการดำเนินการของแอปพลิเคชันอย่างรวดเร็วเพียงใดในกรณีที่เกิดความล้มเหลว RPO กำหนดว่าข้อมูลของเราจะเป็นปัจจุบันอย่างไรในกรณีที่เกิดสถานการณ์การกู้คืน เมื่อคุณระบุเมตริกเหล่านี้สำหรับแอปพลิเคชันและฐานข้อมูลได้แล้ว การดำเนินการนี้จะกำหนด SLA ของคุณSLA จะวัดเป็นเปอร์เซ็นต์ ตัวอย่างเช่น คุณอาจพบเงื่อนไขต่างๆ เช่น 99.9% หรือ 99.99% ที่พร้อมใช้งานสิ่งเหล่านี้คือการวัดจำนวนนาทีของเวลาทำงานและความพร้อมใช้งานที่ฝ่ายไอทีจะรับประกันสำหรับแอปพลิเคชันในปีที่กำหนด โดยทั่วไป การปกป้องที่มากขึ้นหมายถึงต้นทุนที่มากขึ้น ดังนั้นจึงเป็นเรื่องสำคัญที่จะต้องประเมินค่าใช้จ่ายของการหยุดทำงานหนึ่งชั่วโมงสำหรับแอปพลิเคชันหรือฐานข้อมูล และใช้ SLA นี้เป็นเครื่องมือในการเลือกโซลูชันที่เหมาะสมกับธุรกิจ

เมื่อเรามี SLA แล้ว เราสามารถตัดสินใจทางธุรกิจเกี่ยวกับประเภทของโซลูชัน – FT, HA, DR หรือการผสมผสานของโซลูชันนั้น – เป็นแนวทางที่เหมาะสมที่สุดสำหรับความต้องการด้านความพร้อมใช้งานของเรา

Fault Tolerance (FT) คืออะไร?

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

ฟังดูยอดเยี่ยม!ฟังดูยอดเยี่ยม!ทำไมเราถึงต้องการอะไรอีก?แต่เดี๋ยวก่อน…มันยอดเยี่ยมเหมือน FT ฟังบนกระดาษ มีข้อแม้บางประการที่ต้องพิจารณา

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

ช่องโหว่ข้อผิดพลาดของซอฟต์แวร์

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

ความพร้อมใช้งานสูง (HA) คืออะไร?

สำหรับ SLA ส่วนใหญ่ FT นั้นแพงเกินไปที่จะซื้อและจัดการสำหรับกรณีการใช้งานทั่วไปในกรณีส่วนใหญ่ โซลูชัน HA เป็นตัวเลือกที่ดีกว่า พวกเขาให้การป้องกันในระดับเกือบเท่ากันโดยมีค่าใช้จ่ายเพียงเล็กน้อยโซลูชัน HA มี SLA 99.99% ซึ่งเท่ากับเวลาหยุดทำงานประมาณ 52 นาทีในหนึ่งปี โดยปรับใช้ในลักษณะ Active-Standbyมีการแนะนำ SLA ที่ลดลง เนื่องจากมีช่วงการหยุดทำงานเล็กน้อยซึ่งเซิร์ฟเวอร์ที่ใช้งานอยู่ต้องสลับไปยังเซิร์ฟเวอร์สแตนด์บายก่อนที่การดำเนินการจะกลับมาทำงานต่อตกลง นี่ไม่ได้น่าประทับใจเท่ากับโซลูชัน FT แต่สำหรับข้อกำหนดด้านไอทีส่วนใหญ่ HA ตรงตาม SLA แม้กระทั่งสำหรับแอปพลิเคชันที่มีความสำคัญยิ่งยวด เช่น ระบบ CRM และ ERP

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

Disaster Recovery (DR) เข้ากับรูปภาพได้อย่างไร?

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

มันไม่สิ่งที่ทุกคนหมายถึงอะไร?

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

วิธีการเลือก: FT, HA และ DR?

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

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

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

วิธีหลีกเลี่ยงปัญหาคอขวด IO: คำแนะนำการจัดตำแหน่งบันทึกเจตนาของ DataKeeper สำหรับการปรับใช้ Windows Cloud

เพื่อให้มั่นใจถึงประสิทธิภาพของแอปพลิเคชันที่เหมาะสมที่สุด เมื่อปรับใช้ SIOS DataKeeper มันเป็นสิ่งสำคัญที่จะวาง บันทึกเจตนา (ไฟล์บิตแมป) บนดิสก์เวลาแฝงต่ำสุดที่มีอยู่ หลีกเลี่ยงปัญหาคอขวด IO ใน AWS, GCP และ Azure ดิสก์เวลาแฝงต่ำสุดที่มีคือไดรฟ์ชั่วคราว อย่างไรก็ตาม ใน Azure ความแตกต่างระหว่างการใช้ไดรฟ์ชั่วคราวกับ Premium SSD นั้นน้อยมาก ดังนั้นจึงไม่จำเป็นต้องใช้ไดรฟ์ชั่วคราวเมื่อเรียกใช้ DataKeeper ใน Azure อย่างไรก็ตาม ใน AWS และ GCP จำเป็นต้องย้าย Intent Log ไปยังไดรฟ์ชั่วคราว มิฉะนั้น ปริมาณงานการเขียนจะได้รับผลกระทบอย่างมาก

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

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

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

ข้อมูลเกี่ยวกับวิธีการย้ายบันทึกความตั้งใจสามารถพบได้ใน เอกสาร DataKeeper . ข้อมูลเพิ่มเติมเกี่ยวกับวิธีการใช้บันทึกความตั้งใจสามารถดูได้ใน เอกสาร DataKeeper .

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