ความพร้อมใช้งานสูงและการกู้คืนจากภัยพิบัติในทุกที่: จากแนวคิดทั่วไปสู่การสร้างสรรค์โซลูชัน

บล็อกที่เกี่ยวข้อง / บทความแนะนำเพิ่มเติม

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

• คลัสเตอร์ลินุกซ์/คลัสเตอร์ Windows(ขอขอบคุณคุณโฮกลันด์ รองประธานฝ่ายขายและการตลาดระดับโลกของ SIOS และทีมการตลาดของ SIOS ที่ได้เขียนบทความนี้)
• ความชาญฉลาดของแอปพลิเคชันที่เกี่ยวข้องกับความพร้อมใช้งานสูง(ขอขอบคุณคุณเฮนดริกส์-ซิงค์ วิศวกรระบบอาวุโส ฝ่ายไอที บริษัท SIOS สำหรับบทความนี้)
• การดำเนินการเกี่ยวกับทรัพยากรและข้อมูลเบื้องหลังชุดกู้คืนแอปพลิเคชันทั่วไป(เขียนโดยคุณเบอร์มิงแฮม ผู้เชี่ยวชาญด้านเทคโนโลยีอาวุโส)
• การเลือกใช้ระหว่าง GenApp และ QSP: ปรับแต่งระบบความพร้อมใช้งานสูงสำหรับแอปพลิเคชันที่สำคัญของคุณ(ขอขอบคุณคุณเฮนดริกส์-ซิงค์ วิศวกรระบบอาวุโส ฝ่ายไอที บริษัท SIOS สำหรับบทความนี้)

อย่างไรก็ตาม บล็อกนี้จะสำรวจตัวเลือกต่างๆ ที่มีอยู่เมื่อ QSP ARK ไม่สามารถตอบสนองความต้องการด้านความพร้อมใช้งานสูงและการกู้คืนจากภัยพิบัติสำหรับแอปพลิเคชันหรือกรณีการใช้งานเฉพาะได้

ทบทวนอย่างรวดเร็ว

ส่วนก่อนหน้าของบล็อกนี้ในส่วนนี้ได้กล่าวถึงวิธีการคิดเกี่ยวกับแอปพลิเคชันเพื่อจุดประสงค์ในการสร้างชุดกู้คืนแอปพลิเคชันทั่วไป (Generic Application Recovery Kit) เพื่อปกป้องแอปพลิเคชันนั้นด้วย LifeKeeper ในส่วนนี้ พื้นฐานในการทำความเข้าใจแอปพลิเคชันที่นำเสนอในส่วนแรกจะถูกนำมาปรับใช้ให้เข้ากับกรอบการทำงานของชุดกู้คืนแอปพลิเคชันทั่วไปของ LifeKeeper

เนื่องจากบทความนี้ในชุดบทความนี้ควรพิจารณาควบคู่ไปกับบทความก่อนหน้า ดังนั้นนี่คือการทบทวนสั้นๆ เกี่ยวกับแนวคิดที่นำเสนอในบทความที่ 1

ถามคำถามที่สั้นที่สุดแต่ยังคงให้ข้อมูลที่เป็นประโยชน์และนำไปปฏิบัติได้

ในการกำหนดวิธีการตอบคำถามกว้างๆ นั้น ให้แบ่งคำถามเหล่านั้นออกเป็นคำถามย่อยๆ ที่มีคำตอบง่ายกว่า จากนั้นใช้คำถามย่อยเหล่านั้นเพื่อสร้างคำตอบของคำถาม “กว้างๆ” เดิมขึ้นมาใหม่ทีละขั้นตอน

ใช้ข้อมูลที่ให้มา

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

เมื่อทบทวนพื้นฐานกันเสร็จแล้ว ก็ถึงเวลาที่จะนำ LifeKeeper เข้ามาเกี่ยวข้อง แม้ว่าระบบที่มีความพร้อมใช้งานสูงและการกู้คืนจากภัยพิบัติมักจะเกี่ยวข้องกับความซับซ้อน แต่ก็มีความพยายามอย่างมากที่จะทำให้เข้าใจแอปพลิเคชันเฉพาะนั้นได้ง่ายขึ้นในกรอบงาน Generic Application Recovery Kit โดยมีพื้นฐานดังกล่าวเป็นแนวทางในการคิดแบบ LifeKeeper

คิดแบบไลฟ์คีปเปอร์

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

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

• กู้คืนการดำเนินการ: เริ่มแอปพลิเคชัน
• ลบการดำเนินการ: หยุดการทำงานของแอปพลิเคชัน
• การดำเนินการ quickCheck: แอปพลิเคชันสอบถามข้อมูล
  • บันทึกการดำเนินการ QuickCheck เป็นทางเลือกสำหรับทรัพยากรแอปพลิเคชันทั่วไป และการตรวจสอบจะไม่เกิดขึ้นหากไม่ได้กำหนดการดำเนินการ QuickCheck ไว้ อย่างไรก็ตาม ขอแนะนำอย่างยิ่งให้ตรวจสอบแอปพลิเคชันเป็นประจำเพื่อให้ได้ผลลัพธ์ที่ดีที่สุดสำหรับการใช้งานระบบความพร้อมใช้งานสูงและการกู้คืนจากภัยพิบัติ!
• การดำเนินการฟื้นฟูในระดับท้องถิ่น: หยุดแอปพลิเคชันและเริ่มแอปพลิเคชัน (ตามลำดับ)
  • บันทึกการดำเนินการกู้คืนภายในเครื่อง (Local Recovery Actions) เป็นตัวเลือกเสริมสำหรับทรัพยากรแอปพลิเคชันทั่วไป (Generic Application Resources) หากไม่ได้กำหนดการดำเนินการกู้คืนภายในเครื่องไว้ ทรัพยากรแอปพลิเคชันทั่วไปจะไม่พยายามเริ่มต้นใหม่เพื่อซ่อมแซมตัวเองบนระบบที่ตรวจพบความล้มเหลว แต่จะหยุดทำงานบนระบบที่ล้มเหลว และลำดับชั้นทั้งหมดของแอปพลิเคชันจะย้ายไปยังระบบสำรอง

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

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

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

บทสรุป

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

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

ผู้เขียน: ฟิลิป เมอร์รี วิศวกรฝ่ายสนับสนุน บริษัท SIOS Technology Corp.

นำมาเผยแพร่ซ้ำโดยได้รับอนุญาตจากSIOS

การกำจัดจุดอ่อนที่สำคัญ

ในโลกของไอทีระดับองค์กร คำว่า “จุดล้มเหลวเพียงจุดเดียว” (Single Point of Failure หรือ SPOF) ก็เพียงพอที่จะทำให้ผู้ดูแลระบบนอนไม่หลับแล้ว SPOF คือส่วนประกอบใดๆ ในโครงสร้างพื้นฐานของคุณ ไม่ว่าจะเป็นเซิร์ฟเวอร์ สวิตช์เครือข่าย หรืออุปกรณ์จัดเก็บข้อมูล ที่หากล้มเหลว จะทำให้ระบบทั้งหมดล่มไปด้วย เนื่องจากธุรกิจต่างๆ มีความต้องการเพิ่มมากขึ้นเรื่อยๆความพร้อมใช้งาน 99.99% (หรือสูงกว่า)การระบุและกำจัดช่องโหว่เหล่านี้จึงไม่ใช่เรื่องที่เลือกได้อีกต่อไป แต่เป็นข้อกำหนดที่สำคัญยิ่ง

หากคุณต้องการเสริมความแข็งแกร่งให้กับโครงสร้างพื้นฐานของคุณ การผสานรวมความพร้อมใช้งานสูง (High Availability หรือ HA) เข้ากับ…การจำลองข้อมูลนำเสนอโซลูชันที่แข็งแกร่งระดับองค์กรเพื่อกำจัดจุดล้มเหลวเพียงจุดเดียว (SPOF) และรับประกันการดำเนินงานอย่างต่อเนื่อง

พลังของการจัดกลุ่มเพื่อกำจัดจุดล้มเหลวเพียงจุดเดียว

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

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

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

การกำจัดจุดล้มเหลวเพียงจุดเดียวของ SAN

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

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

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

ช่องทางการสื่อสารหลายช่องทางและโซลูชัน Quorum/Witness

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

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

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

ค้นหาและกำจัดจุดล้มเหลวเพียงจุดเดียว (SPOF) อย่างเป็นระบบด้วย SIOS

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

ผู้เขียน: เทรย์ ไอแซค วิศวกรสนับสนุนผลิตภัณฑ์อาวุโส บริษัท SIOS

นำมาเผยแพร่ซ้ำโดยได้รับอนุญาตจากSIOS

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

เคล็ดลับสู่ความสำเร็จในการปกป้องแอปพลิเคชันที่สำคัญต่อธุรกิจ

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

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

บล็อกที่เกี่ยวข้องและคำแนะนำสำหรับการอ่านเพิ่มเติม

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

• คลัสเตอร์ลินุกซ์/คลัสเตอร์ Windows(ขอขอบคุณคุณโฮกลันด์ รองประธานฝ่ายขายและการตลาดระดับโลกของ SIOS และทีมการตลาดของ SIOS ที่ได้เขียนบทความนี้)

• ความชาญฉลาดของแอปพลิเคชันที่เกี่ยวข้องกับความพร้อมใช้งานสูง(เขียนโดย คุณเฮนดริกส์-ซิงค์ วิศวกรซอฟต์แวร์อาวุโส บริษัท SIOS)
• การดำเนินการเกี่ยวกับทรัพยากรและข้อมูลเบื้องหลังชุดกู้คืนแอปพลิเคชันทั่วไป(เขียนโดยคุณเบอร์มิงแฮม ผู้เชี่ยวชาญด้านเทคโนโลยีอาวุโส)
• การเลือกใช้ระหว่าง GenApp และ QSP: ปรับแต่งระบบความพร้อมใช้งานสูงสำหรับแอปพลิเคชันที่สำคัญของคุณ(ขอขอบคุณคุณเฮนดริกส์-ซิงค์ วิศวกรซอฟต์แวร์อาวุโสของ SIOS สำหรับบทความนี้)

อย่างไรก็ตาม บล็อกนี้จะสำรวจตัวเลือกต่างๆ ที่มีอยู่เมื่อ QSP ARK ไม่สามารถตอบสนองความต้องการด้านความพร้อมใช้งานสูงและการกู้คืนจากภัยพิบัติสำหรับแอปพลิเคชันหรือกรณีการใช้งานเฉพาะได้

การวางแนวคิดเกี่ยวกับแอปพลิเคชันและการกำหนดแนวทาง

การถามคำถามเล็กๆ น้อยๆ เกี่ยวกับสถานะของแอปพลิเคชัน

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

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

“กระบวนการทำงานของแอปพลิเคชันกำลังทำงานอยู่หรือไม่ และแอปพลิเคชันกำลังตอบสนองต่อคำถามอยู่หรือไม่?”

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

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

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

คำถามกว้างๆ ที่ถูกแบ่งย่อยออกเป็นคำถามเล็กๆ ที่เฉพาะเจาะจงและมุ่งเป้าไปที่องค์ประกอบแต่ละส่วน คือพื้นฐานในการสร้างชุดเครื่องมือการกู้คืนแอปพลิเคชันทั่วไป (Generic Application Recovery Kits) แต่ละ “คำถามใหญ่” สามารถตอบได้ด้วยการรวบรวมคำตอบที่ให้ไว้สำหรับแต่ละองค์ประกอบที่เกี่ยวข้อง

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

การทำงานร่วมกับ Application API และ LifeKeeper API

บ่อยครั้งที่แอปพลิเคชันมีส่วนติดต่อผู้ใช้แบบกราฟิก (GUI) เพื่อแสดงข้อมูลหรือแสดงการเปลี่ยนแปลงที่เกิดขึ้นกับแอปพลิเคชัน แม้ว่าจะเป็นเรื่องยอดเยี่ยมสำหรับการใช้งานโดยมนุษย์ แต่ก็มีประโยชน์น้อยลงเมื่อการจัดการทำโดยแอปพลิเคชัน GUI มีไว้สำหรับให้คนใช้งาน และแอปพลิเคชัน (โดยไม่ต้องใช้ความพยายามในการเขียนโปรแกรมจำนวนมากและความซับซ้อนที่ไม่จำเป็น) ไม่ได้ถูกออกแบบมาให้เชื่อมต่อกับ GUI ของแอปพลิเคชันอื่นเหมือนที่มนุษย์ทำ สำหรับวัตถุประสงค์ของ LifeKeeper และ Generic Application Resource การแลกเปลี่ยนข้อมูลระหว่างสคริปต์การทำงานของ Generic Application Recovery Kit และแอปพลิเคชันที่ได้รับการปกป้องจะต้องทำผ่าน Application Programming Interface หรือ “API”

LifeKeeper มี API ของตัวเองสำหรับการโต้ตอบกับ LifeKeeper, ลำดับชั้น และทรัพยากรภายในลำดับชั้นนั้น ในกรณีของ API ของ LifeKeeper นั้น ยูทิลิตี้บรรทัดคำสั่งที่มีอยู่ในผลิตภัณฑ์นั้นใช้งานง่ายที่สุดในแอปพลิเคชันทั่วไป โดยทั่วไปแล้ว ขอแนะนำให้ใช้เฉพาะยูทิลิตี้บรรทัดคำสั่งที่ระบุไว้ในเอกสารประกอบผลิตภัณฑ์ LifeKeeper เท่านั้น (เอกสารคำสั่ง Linux/เอกสารคำสั่งของ Windowsควรใช้คำสั่งดังกล่าว แม้จะมีคำแนะนำนี้ แต่ก็ควรใช้คำสั่งเหล่านี้ด้วยความระมัดระวังและใส่ใจในรายละเอียด เพื่อให้แน่ใจว่าจะไม่มีการกระทำที่ไม่พึงประสงค์เกิดขึ้น

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

การใช้รหัสส่งคืนและสตรีมเอาต์พุตในสคริปต์การกู้คืน

ไม่ว่าจะเป็น API สำหรับ LifeKeeper หรือแอปพลิเคชันที่ได้รับการปกป้อง ข้อมูลจะถูกแสดงผลออกมาในสองรูปแบบหลัก ๆ ดังนี้:

• รหัสส่งคืน
• ช่องสัญญาณเอาต์พุต (บางครั้งเรียกว่า “เอาต์พุต STDOUT/STDERR” หรือ “เอาต์พุตเทอร์มินัล”)

รหัสส่งคืนช่วยในการตัดสินว่าการดำเนินการสำเร็จหรือล้มเหลวอย่างไร

โดยทั่วไปแล้ว รหัสส่งคืน (Return code) เป็นวิธีที่ใช้ตรวจสอบได้อย่างรวดเร็วว่าโปรแกรมทำงานสำเร็จหรือล้มเหลว โดยปกติ (ในบริบทของสภาพแวดล้อมเชลล์) รหัสส่งคืนเป็น 0 หมายถึงสำเร็จ ในขณะที่รหัสส่งคืนที่ไม่ใช่ศูนย์หมายถึงล้มเหลว

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

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

สตรีมเอาต์พุตให้ข้อมูลแอปพลิเคชันที่ละเอียดมากขึ้นได้อย่างไร

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

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

การสร้างรากฐานสำหรับการปกป้องแอปพลิเคชันทั่วไป

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

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

ผู้เขียน: ฟิลิป เมอร์รี, วิศวกรฝ่ายสนับสนุนระดับ L3 บริษัท SIOS Technology Corp.

นำมาเผยแพร่ซ้ำโดยได้รับอนุญาตจากSIOS

คู่มือการสนับสนุน SIOS Enterprise: แผนของคุณครอบคลุมอะไรบ้าง

แพ็คเกจการสนับสนุน SIOS Enterprise ของคุณประกอบด้วยอะไรบ้าง?

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

ให้การสนับสนุนตลอด 24 ชั่วโมง 7 วันต่อสัปดาห์ สำหรับกรณีที่ระบบหยุดทำงานในสถานการณ์วิกฤติ

สถานการณ์ที่ 1: ระบบล่มหลังเวลาทำการ

ทีมของโจแอน: เวลา 19.00 น. ตามเวลา EST ของวันอาทิตย์ การสลับการทำงานระหว่างโหนดคลัสเตอร์ SIOS LifeKeeper ควรจะเป็นเรื่องง่าย แต่เกิดเหตุการณ์ไม่คาดฝันขึ้น ทำให้การสลับการทำงานล้มเหลว แม้ทีมจะพยายามแก้ไขปัญหาอย่างเต็มที่แล้ว แต่คลัสเตอร์ก็ยังคงใช้งานไม่ได้ โจแอนต้องการความช่วยเหลือ แต่เธอไม่แน่ใจว่าแผนการสนับสนุนทางเทคนิคของ SIOS ครอบคลุมวันหยุดสุดสัปดาห์หรือไม่ หรือต้องใช้เวลานานแค่ไหนกว่าจะได้คุยกับเจ้าหน้าที่ฝ่ายสนับสนุนทางโทรศัพท์

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

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

การสนับสนุนการติดตั้งและการกำหนดค่า

สถานการณ์ที่ 2: ต้องการความช่วยเหลือในการติดตั้ง

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

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

การวิเคราะห์สาเหตุหลัก (RCA) หลังการสลับระบบไปยังเครื่องสำรอง

สถานการณ์ที่ 3: การสนับสนุนการวิเคราะห์สาเหตุหลักหลังการสลับระบบ (Post-Failover RCA Support)

ทีมของอามอล: เวลา 2 นาฬิกา EST ของวันอังคาร มีการแจ้งเตือนส่งไปยังทีมพัฒนาแอปพลิเคชันทั้งหมดของบริษัท AjaxBjax Corp. คลัสเตอร์ที่ปกป้องระบบแอปพลิเคชันที่สำคัญที่สุดของบริษัทกำลังทำการสลับระบบ (failover) อามอลตรวจสอบแดชบอร์ดแอปพลิเคชันและพบว่าการสลับระบบสำเร็จและแอปพลิเคชันทั้งหมดทำงานได้ อย่างไรก็ตาม อามอลรู้ว่าฝ่ายบริหารต้องการคำอธิบายและคำรับรอง อามอลต้องการให้แน่ใจว่าบริการแอปพลิเคชันทั้งหมดทำงานได้ แต่เขาไม่แน่ใจว่าแผนการสนับสนุนของพวกเขาครอบคลุมเรื่องนี้หรือไม่

ทีมของ Amol กำลังมองหา RCA (Receiver Analyst) และความมั่นใจว่าระบบของพวกเขาจะยังคงใช้งานได้ต่อไป ข้อมูลของ Amol สามารถเข้าถึงได้ และแอปพลิเคชันของเขาก็ทำงานได้อย่างสมบูรณ์ ระบบของเขาไม่ใช่เซิร์ฟเวอร์ที่ใช้งานไม่ได้อย่างร้ายแรง หรือปัญหา P1 (Priority Level 1) อย่างไรก็ตาม หาก AjaxBjax Corp มีการสนับสนุนระดับองค์กรที่ถูกต้องสำหรับคลัสเตอร์ของพวกเขา พวกเขาจะสามารถติดต่อทีมสนับสนุนของ SIOS เพื่อขอคำแนะนำได้ตลอด 24 ชั่วโมง (เวลาฝั่งตะวันออกของสหรัฐอเมริกา) วันจันทร์ถึงวันศุกร์ สำหรับปัญหา RCA การโทรของ Amol ในเวลาตี 2 จะถูกส่งต่อไปยังศูนย์สนับสนุนของ SIOS ที่มีความรู้ความเชี่ยวชาญแห่งใดแห่งหนึ่ง ซึ่งทีมงานจะเริ่มทำงานร่วมกับ Amol

คำถามเพิ่มเติมเกี่ยวกับการติดต่อฝ่ายสนับสนุนของ SIOS

อามอลและโจนสามารถติดต่อฝ่ายสนับสนุนได้ผ่านทางสายด่วนฝ่ายสนับสนุน (สหรัฐอเมริกา: 877.457.5113; ต่างประเทศ: +1.803.808.4270) โดยได้รับความคุ้มครองจากแพ็คเกจการสนับสนุนระดับองค์กร ส่วนสก็อตต์ได้รับความช่วยเหลือที่ต้องการ ไม่ใช่จากทีมสนับสนุน แต่จากการซื้อบริการเพิ่มเติมเพื่อช่วยในการกำหนดค่าและการติดตั้ง แต่ในกรณีอื่นๆ สก็อตต์ อามอล โจน และคนอื่นๆ จะหาข้อมูลเพิ่มเติมเกี่ยวกับระดับการสนับสนุนและรายละเอียดการสนับสนุนได้จากที่ไหน หรือว่าผลิตภัณฑ์ของพวกเขาอยู่ในช่วงการบำรุงรักษาหรือการสนับสนุนเพิ่มเติมแล้วหรือไม่?

หากคุณต้องการข้อมูลเพิ่มเติมเกี่ยวกับข้อตกลงการสนับสนุน คุณสามารถดูข้อตกลงการสนับสนุนทางเทคนิคของ SIOS (TSA) ซึ่งรวมอยู่ในทุกคำสั่งซื้อ นอกจากนี้ คุณยังสามารถดู TSA ได้อย่างสะดวกบนเว็บไซต์ของเราเว็บไซต์ดาวน์โหลดและสามารถขอรับได้โดยส่งอีเมลไปยังทีมสนับสนุน SIOS ที่support@us.sios.comนอกจากนี้ คุณยังสามารถดูตารางกำหนดการผลิตและข้อมูลระดับการสนับสนุนได้ทางออนไลน์ที่ [ลิงก์เว็บไซต์]วงจรชีวิตของผลิตภัณฑ์หน้าหนังสือ.

ลูกค้าที่ทราบรายละเอียดความคุ้มครองภายใต้แผนประกันของตนอยู่แล้ว แต่ต้องการความช่วยเหลือเกี่ยวกับปัญหา คำตอบสำหรับคำถามทั่วไป การวิเคราะห์สาเหตุที่แท้จริง ซอฟต์แวร์เวอร์ชั่นล่าสุด หรือคำแนะนำเพิ่มเติม สามารถเปิดเคสใหม่ได้ผ่านทาง…พอร์ทัลสนับสนุนเยี่ยมชมเว็บไซต์หรือส่งอีเมลไปยังกล่องข้อความฝ่ายสนับสนุนที่support@us.sios.comเมื่อสร้างเคสของคุณแล้ว ทีมงานจะดำเนินการตอบกลับและแก้ไขปัญหาอย่างทันท่วงที

ผู้เขียน: คาสเซียส รู รองประธานฝ่ายประสบการณ์ลูกค้า

นำมาเผยแพร่ซ้ำโดยได้รับอนุญาตจากSIOS