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

ความพร้อมใช้งาน 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

วิธีหลีกเลี่ยงปัญหาคอขวด 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

แพลตฟอร์มสื่อชั้นนำปกป้อง 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

วิธีบรรลุความพร้อมใช้งานสูงในระบบคลาวด์โดยใช้ WSFC

วิธีบรรลุความพร้อมใช้งานสูงในระบบคลาวด์โดยใช้ WSFC

Microsoft Windows Server มีซอฟต์แวร์ Windows Server Failover Clustering (WSFC) เพื่อให้แน่ใจว่ามีแอปพลิเคชันที่สำคัญพร้อมใช้งาน ในสภาพแวดล้อมภายในองค์กร โหนดหลักและโหนดสแตนด์บายในคลัสเตอร์จะเชื่อมต่อกับที่เก็บข้อมูลที่ใช้ร่วมกันเดียวกัน อย่างไรก็ตาม โครงสร้างพื้นฐานนี้ไม่สามารถนำไปใช้กับระบบคลาวด์ได้โดยตรง พื้นที่เก็บข้อมูลที่ใช้ร่วมกันซึ่งครอบคลุมทั้งระบบหลักและระบบสแตนด์บายเป็นสิ่งจำเป็นใน WSFC แต่ที่เก็บข้อมูลที่ใช้ร่วมกันไม่สามารถใช้กับบริการคลาวด์สาธารณะเช่น IaaS (โครงสร้างพื้นฐานเป็นบริการ) ใน AWS, Azure หรือ Google Cloud

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

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

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

ในสภาพแวดล้อม WSFC เซิร์ฟเวอร์หลักและเซิร์ฟเวอร์สแตนด์บายจะเชื่อมต่อกับที่เก็บข้อมูลที่ใช้ร่วมกัน – โดยทั่วไปแล้วที่เก็บข้อมูลเรียกว่า SAN (Storage Area Network) หรือที่เก็บข้อมูล iSCSI-SAN

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

ดูเนื้อหาที่เกี่ยวข้อง: พื้นฐานการกู้คืนจากภัยพิบัติ .

อย่างไรก็ตาม เมื่อย้าย WSFC ไปยังระบบคลาวด์ จะไม่มี SAN ให้ใช้งาน ตัวอย่างเช่น คุณไม่สามารถเชื่อมโยง Amazon Web Services (AWS) และ Microsoft Azure กับหลายโหนด (เซิร์ฟเวอร์) เพื่อใช้เป็นที่เก็บข้อมูลที่ใช้ร่วมกันได้ เช่นเดียวกับ IaaS สำหรับบริการคลาวด์อื่นๆ

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

ซอฟต์แวร์การจำลองข้อมูลช่วยแก้ปัญหา

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

ด้วย DataKeeper โหนดที่ซิงโครไนซ์จะปรากฏเป็น SAN ในหน้าจอการจัดการ WSFC (การจัดการคลัสเตอร์ล้มเหลว) หากผู้จัดการฝ่ายปฏิบัติการของคุณใช้ WSFC พวกเขาจะไม่ต้องการการฝึกอบรมเพียงเล็กน้อยหรือไม่มีเลยกับแนวทางนี้

ความพร้อมใช้งานสูงในระบบคลาวด์เหนือกว่าในองค์กร HA ด้วย SIOS DataKeeper และ WSFC

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

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

บูรณาการอย่างราบรื่นกับ WSFC

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

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