SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • Products
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • การทดสอบอาหารสัตว์
  • ข่าวสารและกิจกรรม
  • ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์
  • เรื่องราวความสำเร็จ
  • ติดต่อเรา
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

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

ตุลาคม 30, 2021 by Jason Aw Leave a Comment

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

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

 

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

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

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

Multi-cloud คือการใช้ผู้ให้บริการระบบคลาวด์ตั้งแต่สองรายขึ้นไปเพื่อให้บริการด้านไอทีและโครงสร้างพื้นฐานขององค์กร โดยทั่วไป วิธีการแบบมัลติคลาวด์ประกอบด้วยผู้ให้บริการคลาวด์สาธารณะรายใหญ่ร่วมกัน ได้แก่ Amazon Web Services (AWS), Google Cloud Platform (GCP) และ Microsoft Azure

องค์กรเลือกบริการที่ดีที่สุดจากผู้ให้บริการระบบคลาวด์แต่ละรายโดยพิจารณาจากต้นทุน ข้อกำหนดทางเทคนิค ความพร้อมใช้งานทางภูมิศาสตร์ และปัจจัยอื่นๆ ซึ่งอาจหมายความว่าบริษัทใช้ Google Cloud สำหรับการพัฒนา/ทดสอบ ในขณะที่ใช้ AWS สำหรับการกู้คืนจากความเสียหาย และใช้ Microsoft Azure เพื่อประมวลผลข้อมูลการวิเคราะห์ธุรกิจ

Multi-cloud แตกต่างจากไฮบริดคลาวด์ซึ่งหมายถึงสภาพแวดล้อมการประมวลผลที่ผสมผสานโครงสร้างพื้นฐานในสถานที่ บริการคลาวด์ส่วนตัว และระบบคลาวด์สาธารณะ

ใครใช้หลายเมฆ?

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

จุดปวดการกู้คืนความเสียหายแบบมัลติคลาวด์:

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

เอาชนะความท้าทาย DR แบบมัลติคลาวด์

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

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

รับโซลูชัน DR แบบมัลติคลาวด์ที่เหมาะสม

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

เครื่องมือนี้จะช่วยคุณในการเตรียมสถานการณ์การกู้คืน และที่สำคัญคือ ทดสอบมัน หากเครื่องมือนี้รวมเข้ากับเครื่องมือสำรองข้อมูลของคุณเป็นอย่างดี เครื่องมือนี้ยังช่วยให้คุณใช้ข้อมูลสำรองเป็นแหล่งข้อมูลการกู้คืนได้ แม้ว่าข้อมูลจะถูกจัดเก็บไว้ในที่ต่างๆ เช่น คลาวด์หลายเครื่อง การสัมมนาผ่านเว็บ SIOS ล่าสุดของเรากล่าวถึงประเด็นเดียวกันนี้ นาฬิกา ที่นี่ หากคุณสนใจSIOS Datakeeper ให้คุณเรียกใช้แอปพลิเคชันที่มีความสำคัญต่อธุรกิจของคุณในสภาพแวดล้อมคลาวด์ที่ยืดหยุ่นและปรับขนาดได้ เช่น Amazon Web Services (AWS) , Azure , และ Google Cloud Platform โดยไม่สูญเสียประสิทธิภาพ ความพร้อมใช้งานสูง หรือการป้องกันภัยพิบัติ SIOS DataKeeper มีอยู่ใน AWS Marketplace และซอฟต์แวร์ความพร้อมใช้งานสูงที่ได้รับการรับรองจาก Azure เพียงตัวเดียวสำหรับ WSFC ที่นำเสนอใน ตลาด Azure

 

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

Filed Under: ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์ Tagged With: Google Cloud Platform, หลายเมฆ

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

มกราคม 19, 2019 by Jason Aw Leave a Comment

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

การจัดการการกู้คืนตามเวลาจริงใน 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 บุคคลที่สาม

RT Insights SIOS_Real-timeRecovery สำหรับ Cloud Outage_181119

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

Filed Under: ข่าวสารและกิจกรรม Tagged With: หลายเมฆ, เซิร์ฟเวอร์ล้มเหลว, โลกไซเบอร์, ไฟดับเมฆ, ไมโครซอฟท์สีฟ้า

โพสต์ล่าสุด

  • วิดีโอ: ข้อดีของ SIOS
  • การสาธิต SIOS DataKeeper สำหรับคลัสเตอร์สามโหนดใน AWS
  • การคาดการณ์ปี 2023: การทำให้เป็นประชาธิปไตยของข้อมูลเพื่อขับเคลื่อนความต้องการสำหรับความพร้อมใช้งานสูง
  • ทำความเข้าใจกับความซับซ้อนของความพร้อมใช้งานสูงสำหรับแอปพลิเคชันที่สำคัญต่อธุรกิจ
  • Epicure ปกป้อง SQL Server ที่สำคัญทางธุรกิจด้วยซอฟต์แวร์ Amazon EC2 และ SIOS SANLess Clustering

กระทู้ยอดนิยม

เข้าร่วมรายชื่อผู้รับจดหมายของเรา

Copyright © 2023 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in