ประสิทธิภาพของ 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

แพลตฟอร์มสื่อชั้นนำปกป้อง SAP S/4 HANA ที่สำคัญใน AWS EC2 Cloud

เลือก SIOS ตามการรับรองและการตรวจสอบสำหรับ SAP, Amazon Web Services และ Red Hat Linux

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

สิ่งแวดล้อม

บริษัทใช้ an แอปพลิเคชัน SAP S/4 HANA และ ฐานข้อมูล HANA เพื่อขับเคลื่อนการดำเนินงานทั่วทั้งองค์กร การรวมการดำเนินงานในหลายแผนก พวกเขากำลังเรียกใช้แอปพลิเคชันและฐานข้อมูลที่สำคัญเหล่านี้ในสภาพแวดล้อม Red Hat Linux ในศูนย์ข้อมูลภายในองค์กร การปกป้องระบบที่จำเป็นเหล่านี้จากการหยุดทำงานและภัยพิบัติเป็นสิ่งสำคัญที่สุดสำหรับทีมไอทีขององค์กรนี้

ความท้าทาย

ทีมไอทีขององค์กรสื่อตระหนักดีว่าสามารถประหยัดต้นทุนได้อย่างมากด้วยการย้ายแอปพลิเคชัน SAP และฐานข้อมูล HANA ไปยังคลาวด์ AWS EC2 อย่างไรก็ตาม เพื่อให้การย้ายข้อมูลประสบความสำเร็จ พวกเขาต้องการโซลูชันที่มีความพร้อมใช้งานสูง (HA) และการกู้คืนความเสียหาย (DR) ที่จะ "ยกระดับและเปลี่ยน" ด้วยภูมิทัศน์ SAP ที่มีอยู่ไปยัง AWS โดยไม่หยุดชะงัก

การประเมินผล

ทีมไอทีของบริษัทต้องการโซลูชัน HA/ DR ที่พวกเขาวางใจได้เพื่อให้เป็นไปตาม SLA ความพร้อมใช้งาน 99.99% ในระบบคลาวด์ โซลูชันจำเป็นต้องได้รับการรับรองจากทั้ง SAP และ AWS และรองรับระบบปฏิบัติการ Red Hat Linux สุดท้ายนี้ เพื่อให้แน่ใจว่าพวกเขาสามารถส่งมอบการป้องกัน DR เต็มรูปแบบสำหรับปริมาณงานที่สำคัญเหล่านี้ พวกเขาต้องการโซลูชันการทำคลัสเตอร์ที่จะเฟลโอเวอร์ข้ามโซนความพร้อมใช้งานของ AWS (AZ) หลายโซน สถาปนิกโซลูชันของ AWS แนะนำให้องค์กรใช้ซอฟต์แวร์การทำคลัสเตอร์ SIOS LifeKeeper สำหรับ Linux ทีมไอทีของบริษัทมีระยะเวลาสั้นๆ ในการดำเนินการโครงการให้เสร็จสิ้น และจำเป็นต้องเลือกผู้ขาย HA ที่สามารถตอบสนองความต้องการได้โดยไม่ขัดขวางความก้าวหน้า

การแก้ไขปัญหา

พวกเขาเลือก SIOS LifeKeeper เพราะไม่เพียงตรงตามเกณฑ์ทั้งหมดของเรา แต่ยังเป็นเพราะทีม SIOS ได้รับการจัดระเบียบอย่างรวดเร็ว ทำให้พวกเขาสามารถรักษาโครงการย้ายข้อมูลบนระบบคลาวด์ได้ตามกำหนดเวลา SIOS Lifekeeper ได้รับการรับรองจากทั้ง AWS และ SAP สำหรับความพร้อมใช้งานสูงบนสภาพแวดล้อมระบบคลาวด์ของ Red Hat และ AWS EC2 โซลูชัน SIOS ยังตรงตามเกณฑ์สำคัญอีกประการหนึ่ง เนื่องจากสามารถทำซ้ำและให้ความซ้ำซ้อนในโซนความพร้อมใช้งานของ AWS ทีมไอทีขององค์กรรู้สึกประทับใจกับทีมสนับสนุนในพื้นที่เฉพาะของ SIOS ที่พร้อมตอบคำถามและให้การสนับสนุนตลอด 24 ชั่วโมง 7 วัน สัปดาห์. ปัจจุบันองค์กรมีคลัสเตอร์ล้มเหลวห้าคู่ที่ใช้ SIOS LifeKeeper สำหรับ Linux เพื่อปกป้องแอปพลิเคชัน S/4 HANA และ SAP HANA ที่ทำงานข้ามโซนความพร้อมใช้งานหลายโซนใน AWS EC2

ผลลัพธ์

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

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

ปกป้องระบบจากการหยุดทำงาน

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

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

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

SIOS มีโซลูชันที่ให้ความพร้อมใช้งานสูงและการกู้คืนจากความเสียหายสำหรับแอปพลิเคชันที่สำคัญ โซลูชันเหล่านี้ได้รับการพัฒนาจากประสบการณ์จริงของเรา ในอุตสาหกรรมและกรณีการใช้งานต่างๆ สินค้าของเราได้แก่ SIOS DataKeeper Cluster Edition สำหรับ Windows และ SIOS LifeKeeper สำหรับ Linux หรือวินโดวส์ แอปพลิเคชันอันทรงพลังเหล่านี้ให้การป้องกันเมื่อเกิดข้อผิดพลาด Application Recovery Kits ที่มาพร้อมกับ LifeKeeper ช่วยเร่งเวลาการกำหนดค่าแอปพลิเคชันด้วยการกำหนดค่าอัตโนมัติและตรวจสอบอินพุต

การปกป้องระบบภายในองค์กร ในระบบคลาวด์หรือในสภาพแวดล้อมแบบไฮบริด

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

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