แอปพลิเคชันทั่วไปของ 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
