กลยุทธ์การกู้คืนข้อมูลสำหรับโลกที่เสี่ยงต่อภัยพิบัติ

กลยุทธ์การกู้คืนข้อมูลสำหรับโลกที่เสี่ยงต่อภัยพิบัติ

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

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

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

การกู้คืนจากภัยพิบัติคืออะไรและเกี่ยวข้องกับอะไรบ้าง?

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

การกู้คืนจากภัยพิบัติแตกต่างจากวิธีการดั้งเดิมในการรับมือกับเหตุขัดข้องอย่างไร

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

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

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

องค์กรต่างๆ มักทำผิดพลาดบ่อยที่สุดอะไรบ้างเมื่อออกแบบกลยุทธ์การกู้คืนระบบจากภัยพิบัติที่มีความพร้อมใช้งานสูง (HADR) และพวกเขาจะหลีกเลี่ยงข้อผิดพลาดเหล่านั้นได้อย่างไร

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

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

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

ความสำคัญของการขจัดจุดล้มเหลวเดี่ยวๆ คืออะไร?

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

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

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

คุณแนะนำให้องค์กรต่างๆ สมดุลระหว่างความซับซ้อนและต้นทุนของการนำกลยุทธ์ HA/DR ที่แข็งแกร่งมาใช้กับความต้องการความคล่องตัวทางธุรกิจอย่างไร

มีสมมติฐานทั่วไปว่าโซลูชัน HA/DR นั้นซับซ้อนหรือมีราคาแพงหรือทั้งสองอย่าง เมื่อเกิดสมมติฐานนี้ขึ้น จำเป็นอย่างยิ่งที่จะต้องมองภาพรวมที่ชัดเจนเกี่ยวกับความเสี่ยงที่เกิดขึ้น ระบบต่างๆ จะทำงานเพื่อวัตถุประสงค์ทางธุรกิจบางประการ และสิ่งนี้จะส่งผลให้เกิดรายได้ เมื่อระบบหยุดทำงานเนื่องจากเหตุขัดข้อง จะมีค่าใช้จ่ายมากกว่าแค่การสูญเสียรายได้ หากไม่มีกลยุทธ์ HA/DR พนักงานจะต้องแก้ไขปัญหาอย่างจริงจังเมื่อเกิดเหตุขัดข้อง ส่งผลให้ต้องเสียค่าใช้จ่ายเป็นชั่วโมงการทำงานของพนักงานเพื่อนำมาคำนวณเป็นค่าใช้จ่ายสำหรับเวลาหยุดทำงาน ซึ่งอาจรวมถึงเวลาที่พนักงานพักผ่อนไม่เพียงพอและไม่ได้เตรียมพร้อมที่จะทำงานให้ดีที่สุด นอกจากนี้ ยังมีค่าใช้จ่ายเพิ่มเติมที่ค้างอยู่ เช่น การหยุดชะงักของหน้าที่ประจำและความล่าช้า/ความล่าช้าเมื่อพนักงานต้องเปลี่ยนงานเพื่อแก้ไขปัญหาการผลิต จากนั้นจึงเปลี่ยนกลับไปทำหน้าที่ปกติ นอกจากนี้ ยังมีค่าใช้จ่ายด้านชื่อเสียงที่อาจทำให้ไม่สามารถรับรู้โอกาสในการสร้างรายได้ ตัวอย่างเช่น หากคุณนึกถึง“การประท้วงของฝูงชน”? แม้ว่าสิ่งนี้จะไม่นำมาซึ่งผลลัพธ์ทันทีปัญหาและข่าวร้ายที่เกี่ยวข้องซึ่ง CrowdStrike ประสบในเดือนกรกฎาคม 2024 ณ เวลาที่เขียนบทความนี้ (25 มีนาคม 2025) ราคาหุ้นของพวกเขาเพิ่งจะกลับสู่ระดับเดิมก่อนจะออกหุ้นในวันที่ 19 กรกฎาคม 2024 เมื่อพิจารณาถึงต้นทุนโอกาสของการกำหนดค่าโซลูชัน HA/DR ปัจจัยที่กล่าวถึงข้างต้นสามารถเปลี่ยนการวิเคราะห์ได้อย่างมาก โดยทั่วไป ลูกค้าของ SIOS พบว่าการนำโซลูชัน HA/DR มาใช้ช่วยประหยัดเงินในระยะยาว นอกจากนี้ ด้วยการปรับปรุงและทำซ้ำหลายทศวรรษสำหรับข้อเสนอ HA/DR จาก SIOS Technology ความซับซ้อนของการกำหนดค่าโซลูชันดังกล่าวจึงเข้าถึงได้ง่ายขึ้นและซับซ้อนน้อยลงกว่าที่เคย หากมีปัจจัยบางอย่างที่ยังคงทำให้เกิดความกังวลเกี่ยวกับความซับซ้อนในการนำโซลูชัน HA/DR มาใช้ในสภาพแวดล้อมการผลิต SIOS Technology ก็มีข้อเสนอบริการระดับมืออาชีพที่สามารถช่วยฝึกอบรมทีม ดำเนินการติดตั้งและกำหนดค่า หรือเพียงแค่ตรวจสอบการกำหนดค่าที่มีอยู่ ด้วยโอกาสเหล่านี้นำความพร้อมใช้งานสูงมาสู่สถาปัตยกรรมระบบไม่เพียงแต่มีความซับซ้อนน้อยลงกว่าที่เคยเป็นมาเท่านั้น แต่ยังสามารถใช้งานได้เร็วกว่าที่เคยอีกด้วย สุดท้ายนี้ สำหรับองค์กรที่กังวลเกี่ยวกับความซับซ้อนอันเนื่องมาจากการกำหนดค่าที่ไม่ซ้ำใครหรือพยายามที่จะเข้าถึงยูทิลิตี้สูงสุดอย่างแท้จริงของโซลูชัน HA/DR ทีมสนับสนุนระดับโลกของเราพร้อมให้ความช่วยเหลือในการทำให้การใช้งานใดๆ ก็ตามมีศักยภาพสูงสุด

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

โซลูชั่นของ SIOS Technologyสามารถตอบสนองทุกประเด็นที่กล่าวมาข้างต้นได้ โดยจะเล่าให้ฟังบางส่วนดังนี้:

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

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

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

ในที่สุด ผลิตภัณฑ์ SIOS Protection Suite ก็ได้รับประโยชน์จากการใช้งานจริงมาหลายทศวรรษ โดยได้ผ่านการทดสอบในสถานการณ์และการกำหนดค่าการใช้งานที่หลากหลาย และได้รับประโยชน์จากการปรับปรุงความสะดวกในการใช้งานมาหลายปี ด้วยเหตุนี้ จึงเป็นโซลูชันที่มีความยืดหยุ่น นำไปใช้ได้ง่าย และเหมาะสมกับสภาพแวดล้อมการผลิตได้อย่างลงตัว ความซับซ้อนในการออกแบบและกำหนดค่าโซลูชัน HA/DR จะหลีกเลี่ยงได้ด้วยการนำ SIOS Protection Suite มาใช้ และเพลิดเพลินไปกับข้อดีของประวัติการพัฒนาอันยาวนานพร้อมการปรับปรุงนับไม่ถ้วน ควบคู่ไปกับทีมสนับสนุนระดับโลกที่พร้อมให้ความช่วยเหลือในกรณีที่มีคำถามหรือข้อกังวลใดๆ ที่อาจเกิดขึ้น นอกจากนี้ ยังมีโอกาสในการติดตั้งร่วมกันหรือขั้นตอนการตรวจสอบสำหรับข้อเสนอ SIOS Protection Suite เพื่อให้แน่ใจว่าสภาพแวดล้อมของคุณพร้อมสำหรับทุกสิ่งที่โลกจะมอบให้ ในที่สุด ทีมงานที่ต้องการพนักงานที่มีประสบการณ์สูงและต้องการเพิ่มประสิทธิภาพการใช้ SIOS Protection Suite และส่วนประกอบต่างๆ ให้สูงสุด SIOS เสนอการฝึกอบรมแบบมีส่วนร่วมซึ่งทีมงานสามารถทำงานร่วมกับพนักงานเพื่อทำความเข้าใจส่วนประกอบต่างๆ ที่เกี่ยวข้อง และมีการอภิปรายอย่างจริงจังเพื่อสร้างความเข้าใจอย่างลึกซึ้ง ซึ่งรับรองว่าพนักงานจะสามารถทำงานได้ทันทีด้วยข้อมูลทั้งหมดที่จำเป็นในการนำโซลูชันไปใช้อย่างเต็มศักยภาพ

ปกป้องธุรกิจของคุณจากเวลาหยุดทำงานและการสูญเสียข้อมูล—ขอสาธิตหรือเริ่มทดลองใช้งานฟรีเพื่อดูการทำงานของ SIOS

ผู้เขียน: Philip Merry, CX – วิศวกรซอฟต์แวร์ที่ SIOS Technology Corp.

พิมพ์ซ้ำโดยได้รับอนุญาตจากSIOS

DataKeeper และเบสบอล: กลยุทธ์ในการกู้คืนจากภัยพิบัติ

DataKeeper และเบสบอล: กลยุทธ์ในการกู้คืนจากภัยพิบัติ

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

การสร้างแผนเกมที่ชนะสำหรับการปกป้องข้อมูล

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

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

ความแตกต่างระหว่าง Baseball และ DataKeeper: เดิมพันใน IT สูงกว่า

มีความแตกต่างบางประการที่มองข้ามไม่ได้ ในขณะที่การแพ้เกมเบสบอล โดยเฉพาะอย่างยิ่งหากเป็นเวิลด์ซีรีส์ เกมที่ 7 อินนิ่งสุดท้าย 2 เอาท์ 3 ลูก – 2 สไตรค์ อาจเป็นเรื่องน่าผิดหวัง แต่ความเสี่ยงนั้นสูงกว่ามากเมื่อใช้ DataKeeper การสูญเสียข้อมูลอาจส่งผลร้ายแรงต่อธุรกิจ ในขณะที่ผู้เล่นเบสบอลต้องการทักษะด้านกีฬาเฉพาะตัว DataKeeper เป็นโซลูชันที่ต้องมีความรู้เกี่ยวกับระบบองค์กรและกระบวนการที่เกี่ยวข้อง

โดยสรุป แม้ว่าเบสบอลและ DataKeeper อาจดูแตกต่างกันโดยสิ้นเชิง แต่ก็มีบางส่วนที่คล้ายคลึงกันซึ่งเราสามารถสรุปได้ ทั้งสองอย่างนี้ต้องการ:

• กลยุทธ์
• การทำงานเป็นทีม
• . . . และความเชี่ยวชาญ

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

แผนการปกป้องข้อมูลของคุณคืออะไร?

ตรวจสอบแผนเกม/โซลูชันที่นำเสนอที่us.sios.com/โซลูชั่น/

เล่นบอล . . .

ผู้เขียน: Gregory A. Tucker วิศวกรสนับสนุนผลิตภัณฑ์อาวุโสที่ SIOS

พิมพ์ซ้ำโดยได้รับอนุญาตจากSIOS

การจัดทำงบประมาณสำหรับความเสี่ยงจากการหยุดทำงานของ SQL Server

การจัดทำงบประมาณสำหรับความเสี่ยงจากการหยุดทำงานของ SQL Server

ในนี้บทความ TechRadar Pro เรื่อง “Budgeting for SQL Server Downtime Risk” Dave Bermingham จาก SIOS เน้นย้ำถึงความสำคัญของการจัดแผนความต่อเนื่องทางธุรกิจให้สอดคล้องกับงบประมาณที่สมเหตุสมผลเพื่อลดการหยุดชะงักในการใช้งาน SQL Server ที่สำคัญต่อภารกิจ เขาแนะนำให้องค์กรต่างๆ ประเมินความสำคัญของอินสแตนซ์ SQL Server แต่ละตัว ทำความเข้าใจถึงผลกระทบที่อาจเกิดขึ้นจากเวลาหยุดทำงาน รวมถึงรายได้ที่สูญเสียไป ประสิทธิภาพการทำงานที่ลดลง ข้อมูลเสียหาย และโทษทางกฎหมาย และจัดสรรทรัพยากรที่เหมาะสม ไม่ว่าจะเป็นแบบภายในองค์กร คลาวด์ หรือไฮบริด เพื่อให้แน่ใจว่าสามารถเตรียมพร้อมรับมือกับภัยพิบัติได้

สร้างซ้ำจากSIOS

การย้ายจาก SIOS DataKeeper สำหรับ Linux ไปยัง DRBD

การย้ายจาก SIOS DataKeeper สำหรับ Linux ไปยัง DRBD

SIOS แนะนำชุดการกู้คืนอุปกรณ์บล็อกแบบกระจายแบบจำลอง (DRBD)SIOS LifeKeeper สำหรับ Linux เวอร์ชัน 9.9.0. การย้ายจากSIOS ดาต้าคีปเปอร์สำหรับ Linux เพื่อ DRBD เป็นกระบวนการง่ายๆ สำหรับผู้ที่ต้องการทดลองใช้ฟีเจอร์ DRBD ภายในไลฟ์คีปเปอร์รวมถึงผู้ที่เคยคุ้นเคยกับ DRBD มาก่อนแล้ว

ทำความเข้าใจ DRBD และประโยชน์ของมันใน LifeKeeper

DRBD คือโซลูชันการจัดเก็บข้อมูลที่จำลองแบบบนซอฟต์แวร์ที่ไม่มีการแชร์และไม่มีการแชร์ใดๆ โดยจะสะท้อนเนื้อหาของอุปกรณ์บล็อก (ฮาร์ดดิสก์ พาร์ติชั่น วอลุ่มลอจิคัล ฯลฯ) ระหว่างโฮสต์ LifeKeeper สำหรับ Linux DRBD Recovery Kit ช่วยให้สามารถกำหนดค่าและควบคุมทรัพยากร DRBD เพื่อให้มีความพร้อมใช้งานสูง

การเปรียบเทียบ SIOS DataKeeper สำหรับ Linux และ DRBD

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

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

วิธีการย้ายฐานข้อมูล PostgreSQL ของคุณไปยัง DRBD

1. หยุดแอปพลิเคชัน PostgreSQL ผ่านทาง LifeKeeper UI

การลบทรัพยากร lkcli –tag pgsql-demo

1. สร้างการสำรองข้อมูลสำหรับฐานข้อมูล PostgreSQL และไฟล์บันทึก

cp -pra /pgsql-demo* /สำรองข้อมูล/

1. สร้างทรัพยากร DRBD ใหม่โดยมีตำแหน่งระบบไฟล์ชั่วคราว

ทรัพยากร lkcli สร้าง drbd –tag drbd-pgsql-demo –device /dev/mapper/singledrbd-lk1 –fstype ext3 –mount_point /tmp/pgsql-demo

อย่าลืมเลือก fstype เดียวกันกับทรัพยากร DataKeeper สำหรับ Linux ก่อนหน้า อุปกรณ์ที่เลือกควรเพียงพอสำหรับปริมาณข้อมูลและบันทึกสำหรับชุดข้อมูลฐานข้อมูล PostgreSQL

1. ขยายทรัพยากร DRBD ไปยังเซิร์ฟเวอร์เป้าหมาย

ทรัพยากร lkcli ขยาย drbd –tag drbd-pgsql-demo –dest node-a –device /dev/xvdc3 –mode synchronous –laddr 10.15.29.165 –raddr 10.15.27.49

1. นำทรัพยากรระบบไฟล์สำหรับฐานข้อมูล PostgreSQL ออกจากการใช้งาน

การลบทรัพยากร lkcli –tag /pgsql-demo

1. เปลี่ยนเจ้าของและกลุ่มสำหรับไดเร็กทอรี /tmp/pgsql/demo

chown postgres: postgres /tmp/pgsql/demo คำสั่ง

1. คัดลอกข้อมูลไปยังระบบไฟล์มิเรอร์ DRBD

cp -pra / สำรองข้อมูล / * /tmp/pgsql-demo

1. นำทรัพยากรระบบไฟล์ DRBD ที่เพิ่งสร้างใหม่ออกจากการใช้งาน

การลบทรัพยากร lkcli –tag /tmp/pgsql-demo

1. ทำลายความสัมพันธ์ระหว่างระบบไฟล์ก่อนหน้าและทรัพยากร DataKeeper สำหรับ Linux

การพึ่งพา lkcli ลบ – parent /pgsql-demo –child datarep-pgsql-demo

ทำลายความสัมพันธ์ระหว่างระบบไฟล์และทรัพยากร DRBD

การลบการอ้างอิง lkcli –parent /tmp/pgsql-demo –child drbd-pgsql-demo

1. สร้างความสัมพันธ์ระหว่างระบบไฟล์ /pgsql-demo ที่มีอยู่และทรัพยากร drbd ขึ้นใหม่

lkcli การอ้างอิงสร้าง –parent /pgsql-demo –child drbd-pgsql-demo

1. เริ่มต้นทรัพยากร pgsql-demo

การกู้คืนทรัพยากร lkcli –แท็ก pgsql-demo

เริ่มการคืนค่า “pgsql-demo” บนเซิร์ฟเวอร์ “node-b”

กำลังรอเซิฟเวอร์เริ่มทำงาน….เสร็จเรียบร้อย

เซิฟเวอร์เริ่มแล้ว

สิ้นสุดการคืนค่า “pgsql-demo” บนเซิร์ฟเวอร์ “node-b” สำเร็จแล้ว

1. เชื่อมต่อกับฐานข้อมูลและตรวจสอบการเชื่อมต่อฐานข้อมูล

ตัวอย่างเช่น:

psql -p 3308 -h /pgsql-demo/socket -U psql

psql -p <พอร์ต> -h <ไดเร็กทอรีซ็อกเก็ต> -U <ผู้ใช้ฐานข้อมูล>

1. ลบทรัพยากรระบบไฟล์ DRBD ชั่วคราว

ลบทรัพยากร lkcli /tmp/pgsql-demo

1. ลบ datarep และทรัพยากรระบบไฟล์ชั่วคราวสำหรับ DataKeeper สำหรับ Linux

ลบทรัพยากร lkcli –tag datarep-pgsql-demo

15. ตรวจสอบสวิตช์โอเวอร์และการเชื่อมต่อ

เหตุใดจึงต้องย้ายจาก SIOS DataKeeper สำหรับ Linux มาเป็น DRBD?

การย้ายจาก SIOS DataKeeper สำหรับ Linux ไปยัง DRBD เป็นกระบวนการง่ายๆ สำหรับผู้ที่ต้องการทดลองใช้ฟีเจอร์ DRBD ใน LifeKeeper เช่นเดียวกับผู้ที่เคยคุ้นเคยกับ DRBD มาแล้วก่อนหน้านี้ หรือต้องการใช้ประโยชน์จากความเร็วในการจำลองแบบอะซิงค์ที่เร็วขึ้นของ DRBD และอาร์เรย์รองรับเคอร์เนลที่หลากหลายยิ่งขึ้น

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

ผู้เขียน: Cassius Rhue รองประธานฝ่ายประสบการณ์ลูกค้าที่ SIOS Technology Corp.

พิมพ์ซ้ำโดยได้รับอนุญาตจากSIOS

เหตุใด Storageless/Nodeless Quorum จึงเป็นอันตรายต่อความพร้อมใช้งานของคลัสเตอร์?

เหตุใด Storageless/Nodeless Quorum จึงเป็นอันตรายต่อความพร้อมใช้งานของคลัสเตอร์?

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

ใน LifeKeeper Quorum จะบังคับใช้ฉันทามติที่ใช้สถานะของโหนดในคลัสเตอร์เพื่อดำเนินการขั้นตอนถัดไปในการจัดการความล้มเหลวของโหนดภายในคลัสเตอร์ LifeKeeperโควตาสามารถดำเนินการได้ 3 โหมดที่เก็บข้อมูล ส่วนใหญ่ และ TCP Remote (TCP Remote มีเฉพาะใน LifeKeeper สำหรับ Linux เท่านั้น)

• Storage Quorum จะใช้อุปกรณ์จัดเก็บข้อมูลที่ใช้ร่วมกันเพื่อติดตามการอัปเดตที่จัดทำโดยระบบอื่นๆ ในคลัสเตอร์ หากระบบไม่จัดเตรียมการอัปเดต Quorum จะทำเครื่องหมายคลัสเตอร์นั้นว่าล้มเหลว
• องค์ประชุมเสียงข้างมากอาศัยโครงสร้างของคลัสเตอร์จำนวนคี่โดยที่โหนดหนึ่งทำหน้าที่เป็นพยานเพื่อพิจารณาว่าโหนดหนึ่งหรือทั้งหมดในคลัสเตอร์ไม่สามารถสื่อสารกันได้หรือไม่
• การเชื่อมต่อระยะไกลของ TCP ผ่านบริการ TCP/IP บนพอร์ตที่ระบุเพื่อตรวจสอบว่าโหนดในคลัสเตอร์สามารถสื่อสารกันได้หรือไม่

ทำความเข้าใจความสำคัญของโควรัมในคลัสเตอร์

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

ความเสี่ยงของการดำเนินการโดยไม่มีโควรัมในคลัสเตอร์ของคุณ

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

สถานการณ์ที่ 1: ลดระยะเวลาหยุดทำงาน

การหยุดทำงานโดยไม่ได้ตั้งใจสามารถเกิดขึ้นได้เมื่อระบบหนึ่งระบบหรือมากกว่านั้นไม่สามารถใช้งานได้เนื่องจากการกระทำที่หลีกเลี่ยงไม่ได้ เช่น ระบบหยุดทำงานหรือการสื่อสารเครือข่ายล้มเหลวชั่วคราว

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

สถานการณ์ที่ 2: สมองแยกส่วน

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

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

เหตุใดการกำหนดค่าโควรัมที่เหมาะสมจึงมีความสำคัญ

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

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

ผู้เขียน: Alexus Gore วิศวกรซอฟต์แวร์ประสบการณ์ลูกค้าที่ SIOS Technology Corp.

พิมพ์ซ้ำโดยได้รับอนุญาตจากSIOS