ทำไม SIOS HANA Multitarget Automation ถึงเป็นเรื่องใหญ่กว่าที่คิด
Larry (ไม่ใช่ชื่อจริงของเขา) เป็นลูกค้า SIOS ที่เคยปรับใช้โซลูชันการจำลองแบบสำหรับความพร้อมใช้งานสูงและการกู้คืนระบบ (HA/DR) ในอดีต เมื่อเขาเปิดตัว PoC เพื่อทดสอบโซลูชันการจำลองแบบสองโหนดสำหรับ Linux โดยใช้SIOS LifeKeeperและการจำลองแบบ DataKeeper สิ่งสำคัญสูงสุดของเขาคือการปกป้องความสมบูรณ์ของข้อมูล รายการทดสอบ PoC ของ Larry รวมรายการมาตรฐาน ได้แก่: การเริ่ม/หยุดฐานข้อมูล การโอนย้ายฐานข้อมูลไปยังโหนดสำรอง กิจกรรมการบำรุงรักษา และเซิร์ฟเวอร์ล้มเหลว เป็นต้น Larry ยืนกรานว่าโซลูชันนี้สามารถทำได้ทั้งการสลับเซิร์ฟเวอร์ที่รวดเร็ว (เช่น การโยกย้ายที่สง่างาม) และรวดเร็วล้มเหลว(กล่าวคือการย้ายอย่างกะทันหันและถูกบังคับ) ของแอปพลิเคชัน ฐานข้อมูล ที่เก็บข้อมูลและบริการจากเซิร์ฟเวอร์หนึ่งไปยังอีกเซิร์ฟเวอร์หนึ่ง แต่เขามีความมุ่งมั่นและกระตือรือร้นมากขึ้นว่ากิจกรรมดังกล่าวไม่ควรทำให้ข้อมูลสูญหาย
ปกป้องความสมบูรณ์ของข้อมูลโดยหลีกเลี่ยงการแยกสมอง
นอกเหนือจากการทดสอบมาตรฐานเหล่านี้แล้ว Larry ได้เพิ่มการทดสอบเฉพาะเพื่อพยายามบังคับ “สมองแตก” สถานการณ์ สมองแตกเป็นภาวะที่เกิดขึ้นเมื่อสมาชิกของคลัสเตอร์ไม่สามารถสื่อสารกันได้ แต่อยู่ในสถานะที่ทำงานอยู่และใช้งานได้ และต่อมาก็เข้าครอบครองทรัพยากรร่วมกันพร้อมกัน จริงอยู่ คุณมีคนขับรถบัสสองคนต่อสู้กันเพื่อแย่งชิงพวงมาลัย เนื่องจากลักษณะการทำลายล้าง สมองแตก อาจทำให้ข้อมูลสูญหายหรือข้อมูลเสียหายได้ และควรหลีกเลี่ยงโดยใช้กลไกเพื่อพิจารณาว่าโหนดใดควรยังคงทำงานอยู่ (ขับรถบัส) และโหนดใดควรหยุดเขียนลงดิสก์
แม้ว่าสถานการณ์แยกสมองจะค่อนข้างพบได้บ่อยในคลัสเตอร์ที่ปรับใช้ความสามารถองค์ประชุมและองค์ประชุมบวกกับความสามารถของพยาน ความยากของการแก้ปัญหาสมองแยกจะเพิ่มขึ้นอย่างทวีคูณเมื่อเพิ่มโหนดทุกโหนดในการกำหนดค่าคลัสเตอร์ ในการกำหนดค่าแบบหลายเป้าหมายที่มีโหนดตั้งแต่สามโหนดขึ้นไป ซอฟต์แวร์การทำคลัสเตอร์ไม่เพียงแต่ต้องจัดการการเฟลโอเวอร์ไปยังโหนดที่ถูกต้องเท่านั้น แต่ยังต้องสลับการจำลองแบบอัตโนมัติจากโหนดหลักใหม่ไปยังโหนดตติยภูมิเพื่อรักษาการป้องกัน DR ในขณะเดียวกันก็ต้องแน่ใจว่าได้ตัดสินอย่างเหมาะสมระหว่าง โหนด ในโซลูชันการทำคลัสเตอร์อื่นๆ การดำเนินการที่ซับซ้อนเหล่านี้ต้องได้รับการเขียนสคริปต์ด้วยตนเองและอัปเดตด้วยตนเองในกรณีที่เกิดข้อผิดพลาดและอีกครั้งเพื่อกู้คืนการทำงานปกติ และจะยิ่งยากขึ้นเมื่อเกิดการแตกของสมอง
เนื่องจากคุณสมบัติและการปรับปรุงใน SIOS LifeKeeper และชุดการกู้คืนแอปพลิเคชัน SAP HANA(ARK) แลร์รี่มีปัญหาในการแนะนำสถานการณ์สมองแตก อย่างไรก็ตาม เมื่อเขาสามารถประดิษฐ์ได้ในที่สุด เขาก็ได้รับประโยชน์อย่างมากจากการเข้าใจตรรกะที่ผลิตภัณฑ์ SIOS ใช้เพื่อปกป้องข้อมูลของเขา Larry ตระหนักถึงความซับซ้อนระดับสูงที่ได้รับการออกแบบในการปกป้องข้อมูลที่จัดทำโดยซอฟต์แวร์การทำคลัสเตอร์ SIOS เขาเลือก SIOS LifeKeeper
ความแตกต่างของ SIOS HANA Multitarget Automation
สถานการณ์เช่น Larry’s เป็นเพียงหนึ่งในเก้าเหตุผลที่ระบบอัตโนมัติหลายเป้าหมาย HANA ของ SIOS เป็นเรื่องใหญ่กว่าที่คุณคิด นี่คือทั้งหมดเก้า:
- การป้องกันขั้นสูง
โซลูชันของ SIOS ช่วยลดความยุ่งยากในการปกป้องทรัพยากรฐานข้อมูล HANA ในสถานการณ์หลายเป้าหมาย ตัวเลือกที่ใช้วิซาร์ดจะตรวจจับการกำหนดค่าปัจจุบันได้อย่างรวดเร็ว และเพิ่มข้อมูลลงในการกำหนดค่า LifeKeeper อย่างแม่นยำ การตรวจจับข้อผิดพลาดมีทั้งความกระชับและให้ข้อมูลเพื่อช่วยให้ผู้ใช้แก้ไขปัญหาต่างๆ และประหยัดเวลาในภายหลัง - การบริหารที่คล่องตัว
Natalie (ไม่ใช่ชื่อจริงของเธอ) รับผิดชอบการกำหนดค่ามัลติโหนด HANA เมื่อเซิร์ฟเวอร์ล้มเหลวหรือจำเป็นต้องบำรุงรักษา Natalie ใช้ประโยชน์จากสคริปต์และเครื่องมือต่างๆ เพื่อดำเนินการที่จำเป็น อย่างไรก็ตามสิ่งนี้ไม่สามารถปรับขนาดได้ หลังจากย้ายไปที่ SIOS LifeKeeper นาตาลีและทีมมี UI ที่เรียบง่ายเพื่อทำงานหลักทั้งหมด เช่น การหยุดและรีสตาร์ท HANA และการจำลองระบบ HANA นอกจากนี้ หากเกิดภัยพิบัติ ทีมงานสามารถใช้ SIOS UI เดียวที่เรียบง่ายแทนการค้นหา runbook ล่าสุด ค้นหาสำเนาของสคริปต์ที่ถูกต้อง หรือโทรหานาตาลีตอนตี 2 . - การตรวจสอบที่ง่ายขึ้น
รายงานสถานะที่ใช้งานง่ายของ SIOS ใน UI ทำให้ทีมมีวิธีที่รวดเร็วในการพิจารณาการจำลองแบบสถานะ. การใช้เครื่องมือชิ้นเดียว เมื่อเทียบกับชุดของบอร์ดตรวจสอบและสคริปต์ที่ทำขึ้นเอง ทำให้การดูแลระบบง่ายขึ้นและประหยัดเวลา - การกู้คืนอัตโนมัติ
โซลูชัน HANA HSR บางตัวสามารถดำเนินการเฟลโอเวอร์ของการจำลองแบบ HANA ระหว่างสองโหนดเหล่านั้นได้ อย่างไรก็ตาม ผู้ดูแลระบบมักจะต้องลงทะเบียนการจำลองอีกครั้งหลังจากระบบล้มเหลว ในกรณีที่มีโหนดสามโหนดขึ้นไป ผู้ดูแลระบบจะเข้าใจวิธีการอัปเดตการลงทะเบียนในโหนดที่สามหรือโหนดที่สี่หรือไม่ พวกเขาจะจดจำการใช้ sync และ async อย่างเหมาะสมหรือไม่ โซลูชัน SIOS ที่สามารถจัดการโหนดสามหรือสี่โหนดสำหรับการจำลองแบบหลายเป้าหมาย จะทำให้การลงทะเบียนโหนดเป้าหมายเป็นไปอย่างอัตโนมัติหลังจากเกิดความล้มเหลว - ความยืดหยุ่นและความสามารถในการปรับขนาด
ความสามารถในการปกป้องคลัสเตอร์ HANA ในชุดค่าผสมสอง สาม หรือสี่โหนด หมายความว่าลูกค้ามีความยืดหยุ่นในการเรียกเลขหมายระดับความพร้อมใช้งานและการกู้คืนความเสียหาย ลูกค้าสองโหนดที่มีองค์ประชุมสามารถให้การป้องกันความพร้อมใช้งานจากภัยพิบัติและจัดการกิจกรรมการบำรุงรักษาโดยแทบไม่ต้องหยุดทำงานโดยใช้ประโยชน์จากการครอบครอง HANA ด้วยคุณสมบัติการจับมือกัน ลูกค้าที่ใช้งานโหนดสามโหนดสามารถเรียกใช้ฟังก์ชันการกู้คืนความเสียหายเพิ่มเติมได้โดยการปรับใช้โหนดที่สามด้วยการจำลองแบบ async ในศูนย์ข้อมูลหรือภูมิภาคอื่น เพื่อประโยชน์เพิ่มเติม ลูกค้าสามโหนดสามารถปรับใช้โหนดที่สี่พร้อมโควรัมพื้นที่เก็บข้อมูลเพื่อเปิดใช้งานความพร้อมใช้งานสูงและการกู้คืนระบบในกรณีที่ศูนย์ข้อมูลทั้งหมดสูญหาย - การป้องกันข้อมูล
กลับไปที่ปัญหาของ Larry เขาใช้งาน HANA บนโหนดหลัก A โดยมีการจำลองแบบหลายเป้าหมายไปยังโหนด B และ C จะเกิดอะไรขึ้นเมื่อความพยายามด้วยตนเองของคุณจบลงด้วยหายนะ โหนดใดเป็นโหนดหลัก สิ่งต่าง ๆ ซิงค์กันหรือไม่เมื่อโหนด A ขัดข้อง ฉันจะหลีกเลี่ยงการเรียกโหนดที่ไม่ถูกต้องได้อย่างไร นอกเหนือจากการเพิ่มการรองรับสำหรับสามโหนดขึ้นไปในการกำหนดค่า HSR หลายเป้าหมายแล้ว HANA ARK ใหม่ยังมีเครื่องมือการดูแลระบบเพิ่มเติมเพื่อช่วยในกรณีที่เกิดภัยพิบัติหรือเหตุการณ์สมองแตกที่โชคร้ายแฟล็ก HANA_DATA_OUT_OF_SYNC_<tag> ป้องกันไม่ให้ผู้ใช้กู้คืนฐานข้อมูลในระบบที่ไม่ถูกต้องโดยไม่ตั้งใจ แฟล็ก HANA_LAST_OWNER_<tag> ช่วยให้ผู้ดูแลระบบทราบเมื่อมีการดำเนินการกับระบบหลักในขณะที่โหนดสแตนด์บายไม่ซิงค์กัน แฟล็กนี้บอกผู้ดูแลระบบว่าโหนดนี้เป็นเจ้าของคนสุดท้ายและควรเป็นที่ที่การจำลองแบบกลับมาทำงานต่อ HANA_DATA_CONSISTENCY_UNKNOWN_<tag> ช่วยให้ SIOS แก้ไขและกู้คืนการจำลองโดยอัตโนมัติเมื่อการสื่อสารทั้งหมดระหว่างโหมดสแตนด์บายขาดหายไปชั่วคราว จากนั้นจึงกู้คืน เมื่อใช้ร่วมกับแนวทางปฏิบัติที่ดีที่สุด การปรับใช้โควรัม และการปรับแต่งที่เหมาะสม เครื่องมือเหล่านี้จะช่วยให้ผู้ดูแลระบบอย่าง Larry หลีกเลี่ยงอาการสมองแตกและฟื้นตัวได้อย่างปลอดภัยหากเกิดขึ้น
- การรายงาน ประสิทธิภาพ และการกู้คืนความเสียหาย
แน่นอนว่าประโยชน์ที่แท้จริงสำหรับหลายเป้าหมายอยู่ที่โหนดพิเศษและฟังก์ชันการทำงานที่โหนดเหล่านี้ปลดล็อก การใช้สามโหนดในศูนย์ข้อมูลเดียวกันสามารถปลดล็อกศักยภาพในการรายงานเพิ่มเติมผ่านพารามิเตอร์ logreplay_readaccess ในขณะที่ยังคงรักษาโหนดไว้ที่ไซต์ DR นอกจากนี้ การสนับสนุน SIOS สำหรับโหมดการจำลองแบบต่างๆ ช่วยให้ผู้ใช้มีตัวเลือกในการมีโหนดซิงค์และโหนด async เพื่อประสิทธิภาพที่ดีขึ้นทั่วทั้งศูนย์ข้อมูล (หรือภูมิภาค) - การทดสอบอย่างต่อเนื่อง
ทีมของคุณทดสอบสคริปต์แบบโฮมเมดบ่อยแค่ไหน? runbook ของคุณได้รับการตรวจสอบเกี่ยวกับการกำหนดค่า การดูแลระบบ และสถานการณ์ 2:00 น. บ่อยเพียงใด โซลูชันหลายเป้าหมายของ HANA ไม่เพียงแต่ได้รับการทดสอบอย่างต่อเนื่องโดยวิศวกร SIOS, QA และผู้เชี่ยวชาญด้านประสบการณ์ลูกค้าเท่านั้น แต่โซลูชันดังกล่าวยังได้รับการทดสอบและตรวจสอบความถูกต้องสำหรับกระบวนการเฟลโอเวอร์และการกู้คืนของ HANA ในแต่ละรุ่นและการอัปเดตอีกด้วย - เอกสารประกอบมากมาย
ก่อนหน้านี้ ทีมของเราได้ทำงานร่วมกับลูกค้ารายหนึ่งเพื่อดูแลระบบคลัสเตอร์ แม้ว่าบรรพบุรุษของเขาจะมีความรู้เป็นอย่างดีเกี่ยวกับสภาพแวดล้อมของพวกเขา แต่การเลื่อนตำแหน่งพนักงานและการปรับโครงสร้างองค์กรทำให้เจ้าหน้าที่ไอทีจำนวนมากต้องรับผิดชอบระบบที่พวกเขารู้เพียงเล็กน้อย เมื่อถามเกี่ยวกับ runbooks และเอกสารเกี่ยวกับการกำหนดค่า ลูกค้าไม่สามารถค้นหารายละเอียดจากทีมก่อนหน้าหรือผู้ดูแลระบบคนก่อนหน้าได้ นอกเหนือจากระบบอัตโนมัติที่แข็งแกร่ง การดูแลระบบ การตรวจสอบ การกู้คืน และการปกป้องข้อมูลแล้ว โซลูชันหลายเป้าหมายของ SIOS ยังรวมถึงเอกสารที่มีรายละเอียดและง่ายต่อการใช้งานเกี่ยวกับการปรับใช้ การดำเนินการ และการจัดการระบบหลายเป้าหมาย HANA ที่ควบคุมโดย LifeKeeper
การใช้ประโยชน์จากโซลูชันทั้งหมดของ SIOS หมายความว่าลูกค้าจะได้รับประโยชน์จากการตรวจสอบและตรวจจับที่สม่ำเสมอและทันท่วงที การกู้คืนที่รวดเร็ว เชื่อถือได้และมีประสิทธิภาพ และโซลูชันอัตโนมัติเต็มรูปแบบที่รับประกันความพร้อมใช้งานสูงและการป้องกันการกู้คืนจากภัยพิบัติติดต่อเราสำหรับข้อมูลเพิ่มเติมเกี่ยวกับระบบอัตโนมัติหลายเป้าหมาย SAP HANA
– โดย Cassius Rhue รองประธานฝ่ายประสบการณ์ลูกค้า
ทำซ้ำโดยได้รับอนุญาตจากSIOS
