วิธีการตั้งค่า DataKeeper Cluster Edition (คลัสเตอร์ DKCE)

วิธีการตั้งค่า DataKeeper Cluster Edition (คลัสเตอร์ DKCE)

คลัสเตอร์ DKCE คืออะไร

DKCE เป็นตัวย่อสำหรับรุ่นคลัสเตอร์ DataKeeper. DKCE เป็นซอฟต์แวร์ SIOS ที่รวมการใช้ DataKeeper เข้ากับคุณสมบัติของการทำคลัสเตอร์ Windows Failoverเพื่อให้ความพร้อมใช้งานสูงผ่านการจำลองข้อมูลตามการย้ายข้อมูล

ขั้นตอนในการสร้างคลัสเตอร์ DKCE

สำหรับตัวอย่างนี้ ฉันจะตั้งค่าคลัสเตอร์แบบสามโหนดโดยมีโหนดที่สามที่ดูแลโหนดส่วนใหญ่

ขั้นตอนที่ 1:คุณต้องติดตั้ง DataKeeper บน 2/3 ของระบบเพื่อตั้งค่าคลัสเตอร์ DKCE คลิกลิงก์ต่อไปนี้เพื่อปฏิบัติตามคู่มือเริ่มต้นใช้งานฉบับย่อของเราเพื่อทำการติดตั้งให้เสร็จสิ้น:https://docs.us.sios.com/dkce/8.10.0/en/topic/datakeeper-cluster-edition-quick-start-guide

ขั้นตอนที่ 2:เพิ่มเซิร์ฟเวอร์ที่คุณวางแผนจะจัดการในตัวจัดการเซิร์ฟเวอร์ สิ่งนี้จะต้องดำเนินการบนเซิร์ฟเวอร์ทั้งหมดที่คุณวางแผนจะเพิ่มลงในคลัสเตอร์

บนเซิร์ฟเวอร์ของคุณไปที่ Server Manager

คลิก “เพิ่มเซิร์ฟเวอร์อื่นเพื่อจัดการ”

ฉันเพิ่มเซิร์ฟเวอร์ตามชื่อของพวกเขาที่นี่ ในการดำเนินการนี้ คุณจะต้องยืนยันชื่อระบบและรายการ IP ของคุณในไฟล์โฮสต์ ซึ่งอยู่ที่นี่: C:\Windows\System32\drivers\etc\hosts

หลังจากเพิ่มเซิร์ฟเวอร์ทั้งหมดแล้ว คุณสามารถตรวจสอบได้โดยไปที่ “เซิร์ฟเวอร์ทั้งหมด” ในตัวจัดการเซิร์ฟเวอร์

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

ตั้งค่ารายการ WSMan:\localhost\Client\TrustedHosts -ค่า ‘<ชื่อของเซิร์ฟเวอร์ 1>,<ชื่อของเซิร์ฟเวอร์ 2>’

ขั้นตอนที่ 4:ติดตั้งคลัสเตอร์ล้มเหลว

ติดตามขั้นตอนเหล่านี้เพื่อติดตั้งการทำคลัสเตอร์ล้มเหลว.

ขั้นตอนที่ 5:นำทางไปยังตัวจัดการคลัสเตอร์ล้มเหลว

ขั้นตอนที่ 6:คลิก “สร้างคลัสเตอร์”

ขั้นตอนที่ 7:จากนั้นเพิ่มเซิร์ฟเวอร์ที่ควรอยู่ในคลัสเตอร์แล้วคลิก “เพิ่ม” หลังจากแต่ละรายการ

ขั้นตอนที่ 8:รายการควรจะคล้ายกับรายการในภาพต่อไปนี้

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

ขั้นตอนที่ 10:เมื่อการทดสอบเสร็จสิ้นให้คลิก “เสร็จสิ้น”

ขั้นตอนที่ 11:ตั้งชื่อคลัสเตอร์ของคุณ ฉันตั้งชื่อคลัสเตอร์นี้ว่า “Cluster1” แล้วคลิก “ถัดไป”

ขั้นตอนที่ 12:ตรวจสอบว่าได้เลือก “เพิ่มพื้นที่เก็บข้อมูลที่มีสิทธิ์ทั้งหมดลงในคลัสเตอร์” แล้วคลิก “ถัดไป”

ขั้นตอนที่ 13:เมื่อขั้นตอนที่ 12 เสร็จสิ้น คลิก “เสร็จสิ้น”

ขั้นตอนที่ 14:ใน Failover Cluster Manager คลัสเตอร์จะเริ่มต้นออฟไลน์ ฉันจะกำหนด IP ที่ไม่ได้ใช้เพื่อนำมาออนไลน์ ใน “ทรัพยากรหลักของคลัสเตอร์” ให้คลิกขวาที่ทรัพยากรที่อยู่ IP และเลือกคุณสมบัติ

ในแผงคุณสมบัติ ซับเน็ตมาสก์ของฉันคือ /28 ดังนั้นฉันจะเลือก IP ที่ใช้งานได้ภายในช่วง 12.0.0.14 คลิก “สมัคร”

ใน “ทรัพยากรหลักของคลัสเตอร์” ให้คลิกขวาที่คลัสเตอร์แล้วเลือก “นำออนไลน์”

ทรัพยากรควรออนไลน์แล้ว

ขั้นตอนที่ 15:นำทางไปยัง DataKeeper

ขั้นตอนที่ 16:คลิกขวาที่งานแล้วคลิก “สร้างงาน” เพื่อเริ่มสร้างมิเรอร์แรกของเรา

ตั้งชื่องาน ฉันตั้งชื่องานของฉันว่า “job1” แล้วคลิก “สร้างงาน”

เลือกแหล่งที่มาและปริมาณที่จะจำลองข้อมูล ฉันเลือก Box1 เป็นแหล่งของฉัน และเล่ม D คลิก “ถัดไป”

จากนั้นเลือกเซิร์ฟเวอร์และโวลุ่มที่จะเป็นเป้าหมาย ฉันเลือก Box2 และเล่ม D

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

ใน DataKeeper คุณจะเห็นว่าโวลุ่มกำลังมิเรอร์อยู่

ขั้นตอนที่ 17:ใน Failover Cluster Manager ให้ไปที่ Storage จากนั้นเลือก Disks คุณจะเห็นวอลุ่มที่คุณลงทะเบียนอัตโนมัติคือ WSFC

ขั้นตอนที่ 18:มาตรวจสอบเจ้าของที่ควรตรวจสอบกัน คลิกขวาที่โวลุ่มแล้วคลิก “คุณสมบัติ”

เนื่องจากฉันต้องการหนึ่งในสามเพื่อเป็นพยานและรักษาส่วนใหญ่ของโหนด Box3 จะต้องไม่ถูกเลือก / คงไม่ถูกเลือก

ขั้นตอนที่ 19:ตอนนี้เราสามารถทดสอบการย้ายข้อมูลผ่าน Failover Cluster Manager ได้ ไปที่ File Explorer และสร้างไฟล์ข้อความใหม่ในโวลุ่มที่กำลังทำมิเรอร์อยู่ ทำสิ่งนี้กับแหล่งที่มาของคุณ

ไปที่ Failover Cluster Manager คลิก “DataKeeper Volume D” และเลือก “ย้ายที่เก็บข้อมูลที่มีอยู่” จากบานหน้าต่างการดำเนินการ

คลิกขวาที่ “โหนดที่ดีที่สุดที่เป็นไปได้” สิ่งนี้ควรย้ายไปยังเป้าหมายของคุณโดยอัตโนมัติ

ใน Failover Cluster Manager ให้ตรวจสอบว่าเจ้าของ “DataKeeper Volume D” เป็นโหนดเป้าหมายแล้ว

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

การตั้งค่าคลัสเตอร์ DKCE สำเร็จ

คุณตั้งค่าคลัสเตอร์ DKCE เสร็จแล้ว

SIOS จัดให้ทรัพยากรและการฝึกอบรมสำหรับผลิตภัณฑ์ทั้งหมดของเรา

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

รับรองการเข้าถึงแอปพลิเคชันทางการศึกษาที่สำคัญ

รับรองการเข้าถึงแอปพลิเคชันทางการศึกษาที่สำคัญ

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

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

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

ทางเลือกเพื่อให้ได้ความพร้อมใช้งานสูง

เมื่อคุณเลือกแอปพลิเคชันที่คุณต้องการปกป้องแล้ว ตัวเลือกในการบรรลุ HA จะชัดเจนยิ่งขึ้น พวกเขาทำงานบน Windows หรือ Linux หรือไม่? ระบบจัดการฐานข้อมูล (DBMS) ของคุณรองรับการกำหนดค่า HA ในตัวหรือไม่ หากเป็นเช่นนั้น มีข้อจำกัดอะไรบ้าง? หากแอปพลิเคชันที่สำคัญของคุณทำงานบน Windows และ SQL Server คุณสามารถเปิดใช้งาน HA ได้โดยใช้คุณสมบัติ Availability Group (AG) ของ SQL Server เอง หรือคุณสามารถกำหนดค่า HA โดยใช้เครื่องมือการทำคลัสเตอร์ SANless ของบริษัทอื่น ซึ่งเสนอตัวเลือกที่บริการ AG ใน SQL Server ไม่มี หากคุณกำลังพยายามปกป้องเซิร์ฟเวอร์ฐานข้อมูลจากผู้ขายหลายราย หรือหากแอปพลิเคชันที่สำคัญบางแอปพลิเคชันของคุณทำงานบน Windows ในขณะที่แอปพลิเคชันอื่นๆ ทำงานบน Linux ความสามารถในการจัดการ HA ของคุณจะได้รับการอำนวยความสะดวกโดยการใช้โซลูชัน HA ที่รองรับ DBMS และ OS หลายตัว แพลตฟอร์ม การเลือกใช้โซลูชันคลัสเตอร์ที่รองรับแพลตฟอร์ม DBMS และ OS ที่หลากหลายทำให้การจัดการง่ายขึ้น ตรงกันข้ามกับความซับซ้อนและความยุ่งยากที่อาจเกิดขึ้นในการจัดการบริการ HA ที่ใช้ฐานข้อมูลหลายรายการพร้อมกัน

รับประกันความพร้อมใช้งานสูงผ่านโซลูชัน HA แบบเนทีฟฐานข้อมูล

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

เครื่องมือ HA ที่ใช้ฐานข้อมูลจำนวนมากทำงานในลักษณะเดียวกัน อย่างไรก็ตาม เมื่อพิจารณาถึงแนวทางแบบเนทีฟของฐานข้อมูล มีข้อควรพิจารณาบางประการ: หากบริการ HA รวมเข้ากับ DBMS เอง บริการเหล่านั้นอาจจำลองเฉพาะข้อมูลที่เกี่ยวข้องกับ DBMS นั้นเท่านั้น หากมีข้อมูลสำคัญอื่นๆ อยู่บนเซิร์ฟเวอร์หลักของคุณ ข้อมูลนั้นจะไม่ถูกจำลองไปยังเซิร์ฟเวอร์รองในสถานการณ์ HA ดั้งเดิมของฐานข้อมูล อาจมีข้อจำกัดอื่นๆ เกี่ยวกับสิ่งที่บริการดั้งเดิมของฐานข้อมูลจะทำซ้ำเช่นกัน ถ้าคุณใช้ฟังก์ชัน Basic AG ที่รวมอยู่ใน SQL Server Standard Edition ตัวอย่างเช่น แต่ละ AG สามารถจำลองแบบฐานข้อมูล SQL เดียวเท่านั้นไปยังตำแหน่งรองเดียวได้ คุณสามารถสร้าง AG พื้นฐานได้หลายรายการหากแอปพลิเคชันของคุณเกี่ยวข้องกับฐานข้อมูล SQL หลายฐานข้อมูล แต่คุณไม่สามารถควบคุมได้ว่า AG แต่ละอันจะล้มเหลวพร้อมกันในสถานการณ์เฟลโอเวอร์หรือไม่ และปัญหาอาจเกิดขึ้นได้หากไม่เป็นเช่นนั้น วิธีหนึ่งในการหลีกเลี่ยงข้อจำกัดนี้คือการใช้ฟังก์ชัน Always On AG ที่รวมอยู่ใน SQL Server Enterprise Edition ซึ่งช่วยให้สามารถจำลองฐานข้อมูล SQL หลายฐานข้อมูลไปยังเซิร์ฟเวอร์รองหลายเครื่องได้ แต่อาจมีราคาแพงมากจากมุมมองของสิทธิ์การใช้งานหากแอปพลิเคชันของคุณไม่ มิฉะนั้นให้ใช้คุณสมบัติใด ๆ ของ SQL Server Enterprise Edition

โซลูชัน HA แบบเนทีฟฐานข้อมูลอื่นๆ อาจมีข้อจำกัดที่คล้ายกัน ดังนั้น โปรดทำความเข้าใจก่อนตัดสินใจลงทุนในแนวทางดังกล่าว

รับประกันความพร้อมใช้งานสูงผ่านการทำคลัสเตอร์แบบไร้ SAN

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

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

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

การสัมมนาผ่านเว็บ: การกู้คืนความเสียหายบนคลาวด์: การทำความเข้าใจความท้าทายและกลยุทธ์สำหรับ SQL Server

การสัมมนาผ่านเว็บ: การกู้คืนความเสียหายบนคลาวด์: การทำความเข้าใจความท้าทายและกลยุทธ์สำหรับ SQL Server

ลงทะเบียนเข้าร่วมสัมมนาออนไลน์ตามความต้องการ

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

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

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

สร้างความพร้อมใช้งานสูงด้วยคลัสเตอร์ HSR 3 โหนด HANA ใน AWS โดยใช้ SIOS LifeKeeper

สร้างความพร้อมใช้งานสูงด้วยคลัสเตอร์ HSR 3 โหนด HANA ใน AWS โดยใช้ SIOS LifeKeeper

บทนำ: วิธีตรวจสอบ HA และ DR ในฐานข้อมูลของคุณ

การสร้างสภาพแวดล้อม SAP HANA ที่พร้อมใช้งานสูงใน AWS ถือเป็นงานที่สำคัญสำหรับธุรกิจจำนวนมาก คู่มือนี้ให้คำแนะนำโดยละเอียดสำหรับการตั้งค่าคลัสเตอร์ HANA System Replication (HSR) แบบ 3 โหนดโดยใช้SIOS ไลฟ์คีปเปอร์ใน AWS สร้างความมั่นใจในฐานข้อมูลความยืดหยุ่นและความพร้อมใช้งานสูง.

ข้อกำหนดเบื้องต้น

• บัญชี AWS พร้อมความสามารถในการปรับใช้อินสแตนซ์ EC2
• ซอฟต์แวร์ SIOS LifeKeeper
• การประเมิน SIOS LifeKeeper หรือใบอนุญาตถาวร
• ซอฟต์แวร์ SAP HANA
• ความคุ้นเคยกับบริการของ AWS และ SAP HANA

ขั้นตอนที่ 1: เตรียมสภาพแวดล้อม AWS ของคุณ

การปรับใช้อินสแตนซ์ EC2

ปรับใช้ EC2 instance สามรายการใน AWS อินสแตนซ์เหล่านี้จะทำหน้าที่เป็นโหนดหลัก รอง และตติยภูมิของคลัสเตอร์ HANA ตรวจสอบให้แน่ใจว่ามีคุณสมบัติตรงตามข้อกำหนดด้านฮาร์ดแวร์และซอฟต์แวร์สำหรับ SAP HANA และ SIOS LifeKeeper ตรวจสอบให้แน่ใจว่าคุณปฏิบัติตามแนวทางการกำหนดขนาด SAP HANA เมื่อสร้างอินสแตนซ์ของคุณ

การกำหนดค่าเครือข่าย

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

เมื่อกำหนดค่าโหนด HANA ในภูมิภาคต่างๆ คุณสามารถปกป้องชื่อ DNS ได้โดยใช้ SIOS LifeKeeper สำหรับ Linux Route53 Application Recovery Kit หรือ ARK ต่อไปนี้เป็นสถาปัตยกรรมสำหรับฐานข้อมูล HANA 3 โหนดใน AWS:

เมื่อตั้งค่าพื้นที่จัดเก็บข้อมูล ให้ใช้วอลุ่ม EBS แยกต่างหากสำหรับ /usr/sap, /hana/data, /hana/log และ /hana/shared

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

ในที่สุด เราจำเป็นต้องสร้างโซนโฮสต์ที่มีทั้ง VPC และเพิ่มบันทึกสำหรับโดเมนและชื่อโฮสต์ที่เราจะใช้เพื่อสื่อสารกับโหนด HANA ที่ใช้งานอยู่

ขั้นตอนที่ 2: การติดตั้งและกำหนดค่า SAP HANA

การติดตั้งในแต่ละโหนด

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

เริ่มต้นด้วยการกำหนดการตั้งค่าการติดตั้งของคุณ สำหรับฉันฉันใช้สิ่งต่อไปนี้:

ซิด: D11

• HANA หมายเลขอินสแตนซ์: 11
• HANA db fqdn ใน Route53: saphana.sapdemo
• ชื่อโฮสต์ Node1: sapdemohana1
• ชื่อโฮสต์ Node2:sapdemohana2
• ชื่อโฮสต์ Node3:sapdemohana3
• ประเภทอินสแตนซ์: r5.4xlarge

พื้นที่จัดเก็บอินสแตนซ์ในเครื่อง:

• 30GB / (โวลุ่มรูท)
• 15GB /usr/sap
• 60GB /hana/แชร์*
• 200GB /ฮานะ/ดาต้า
• 200GB /hana/log

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

ติดตั้งซอฟต์แวร์เซิร์ฟเวอร์ HANA บนแต่ละโหนดแยกกันราวกับว่าเป็นระบบสแตนด์อโลน ตรวจสอบให้แน่ใจว่าติดตั้งไลบรารีที่จำเป็นทั้งหมดแล้ว สำหรับ RHEL 8 นั้นจะอยู่ใน SAP note 2772999 คุณจะต้องตรวจสอบให้แน่ใจว่าคุณสร้างลิงก์สัญลักษณ์หลังจากติดตั้ง compact-sap-c++-9-9.1.1-2.3.el7_6.x86_64.rpm โดยการรัน: ln -s /opt/rh/SAP/lib64/compat-sap-++-10.so /usr/sap/lib/libstdc++.so.6

• yum ติดตั้ง xorg-x11-server-Xorg xorg-x11-xauth -y #สำหรับ LifeKeeper GUI
• ยำติดตั้ง nfs-utils

สร้างพาร์ติชั่น ฟอร์แมตที่เก็บข้อมูล และแนบมัน สร้างไฟล์สลับของคุณ

ฉันสร้างคีย์ RSA บนโฮสต์ทั้งหมดของฉัน จากนั้นอนุญาตให้รูทเข้าสู่ระบบ ssh ระหว่างโหนด hana โดยการเพิ่มคีย์สาธารณะลงในไฟล์ .ssh/authorized_keys ซึ่งจะทำให้การติดตั้งง่ายขึ้นมาก

เมานต์วอลลุ่มสื่อการติดตั้ง HANA ของคุณ

• ยำ localinstall compat-sap-c++-10-10.2.1-11.el7_9.x86_64.rpm
• ยำ localinstall compat-sap-c++-9-9.1.1-2.3.el7_6.x86_64.rpm
• mkdir /usr/sap/lib
• ln -s /opt/rh/SAP/lib64/compat-sap-++-10.so /usr/sap/lib/libstdc++.so.6
• yum ติดตั้ง compat-sap-c++-10 libatomic -y

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

การตั้งค่าการจำลองแบบระบบ

คุณจะต้องสำรองข้อมูลก่อนเปิดใช้งาน HSR:

• su – <SID>adm [เช่น. su -d11adm]
• hdbsql -i <หมายเลขอินสแตนซ์>adm -u ระบบ -p <รหัสผ่าน> [เช่น hdbsql -i 11 -u ระบบ -p “รหัสผ่าน123”]
• สำรองข้อมูลโดยใช้ FILE(‘/usr/sap/<SID>/HDB<instance number>’) [เช่น. สำรองข้อมูลโดยใช้ไฟล์ (‘/usr/sap/D11/HDB11’)

ทำซ้ำขั้นตอนการสำรองข้อมูลด้านบนในทุกโหนด

กำหนดค่าการจำลองระบบ HANA บนแต่ละโหนด:

เริ่มต้นอินสแตนซ์ HDB บนระบบ HANA หลัก หากไม่ได้ทำงานอยู่: sapcontrol -nr <instance number> -function StartSystem HDB [เช่น: sapcontrol -nr 11 -function StartSystem HDB]

เริ่มต้น HSR ที่ไซต์หลัก: hdbnsutil -sr_enable –name=<primary site name> [เช่น. hdbnsutil -sr_enable –name=sapdemohana1

หยุดอินสแตนซ์ HDB บนระบบ HANA รอง: sapcontrol -nr <หมายเลขอินสแตนซ์> -function StopSystem HDB [เช่น sapcontrol -nr 11 – ฟังก์ชั่น StopSystem HDB]

ในระบบ HANA เพิ่มเติม ให้สำรองไฟล์ KEY และ DAT และคัดลอกไฟล์ KEY และ DAT หลักไปยังตำแหน่งที่ต้องการ:

• mv /usr/sap/<SID>/SYS/global/security/rsecssfs/data/SSFS_<SID>.DAT /usr/sap/<SID>/SYS/global/security/rsecssfs/data/SSFS_<SID>. DAT.BAK [เช่น mv /usr/sap/D11/SYS/global/security/rsecssfs/data/SSFS_D11.DAT /usr/sap/D11/SYS/global/security/rsecssfs/data/SSFS_D11.DAT.BAK]

• mv /usr/sap/<SID>/SYS/global/security/rsecssfs/key/SSFS_<SID>.KEY /usr/sap/<SID>/SYS/global/security/rsecssfs/key/SSFS_<SID> KEY.BAK [เช่น mv /usr/sap/D11/SYS/global/security/rsecssfs/key/SSFS_D11.KEY /usr/sap/D11/SYS/global/security/rsecssfs/key/SSFS_D11.KEY.BAK]

• scp root@<โหนดหลัก>:/usr/sap/<SID>/SYS/global/security/rsecssfs/data/SSFS_<SID>.DAT /usr/sap/<SID>/SYS/global/security/rsecssfs/ ข้อมูล/SSFS_<SID>.DAT [เช่น scp root@sapdemohana1:/usr/sap/D11/SYS/global/security/rsecssfs/data/SSFS_D11.DAT /usr/sap/D11/SYS/global/security/rsecssfs/data/SSFS_D11.DAT]

• scp root@<โหนดหลัก>:/usr/sap/<SID>/SYS/global/security/rsecssfs/key/SSFS_<SID>.KEY /usr/sap/<SID>/SYS/global/security/rsecssfs/ คีย์/SSFS_<SID>.KEY [เช่น scp root@sapdemohana1:/usr/sap/D11/SYS/global/security/rsecssfs/key/SSFS_D11.KEY /usr/sap/D11/SYS/global/security/rsecssfs/key/SSFS_D11.KEY]

ตรวจสอบให้แน่ใจว่าเจ้าของไฟล์คีย์และ dat เป็น <SID>adm sapsys:

• [root@sapdemohana2 ~]# ls -l /usr/sap/D11/SYS/global/security/rsecssfs/data/
• รวม 12
• -rw-r–r– 1 d11adm sapsys 2960 3 ม.ค. 22:19 SSFS_D11.DAT
• -rw-r–r– 1 d11adm sapsys 2960 3 ม.ค. 22:15 SSFS_D11.DAT.BAK

ลงทะเบียนระบบ HANA เพิ่มเติมกับระบบ HANA หลัก – ต้องทำในฐานะผู้ใช้ที่เป็นผู้ดูแลระบบ:

• hdbnsutil -sr_register –name=<ชื่อของ HSR รอง> –remoteHost=<ชื่อโฮสต์หลักของระบบ SAP HANA> –remoteInstance=<หมายเลขอินสแตนซ์ระยะไกล> –operationMode=<delta_datashipping | ล็อกเล่นซ้ำ | logreplay_readaccess> –replicationMode=<sync | ซิงค์ | อะซิงโครนัส>

[เช่น. hdbnsutil -sr_register –name=sapdemohana2 –remoteHost=sapdemohana1 –remoteInstance=11 –operationMode=logreplay –replicationMode=sync]

ตรวจสอบสถานะ HSR บนทุกระบบ รันคำสั่งต่อไปนี้ในฐานะผู้ใช้ผู้ดูแลระบบ: d11adm@sapdemohana4:/usr/sap/D11/HDB11>hdbnsutil -sr_state

เมื่อระบบทั้งหมดออนไลน์แล้ว คุณสามารถไปยังขั้นตอนถัดไปได้

ขั้นตอนที่ 3: การติดตั้ง SIOS LifeKeeper

การติดตั้ง AWS CLI

ติดตั้ง AWS CLI และกำหนดค่าด้วยคีย์ที่มีสิทธิ์ต่อไปนี้:

การกำหนดค่าตารางเส้นทาง (แบ็กเอนด์):

• ec2:DescribeRouteTables
• ec2:แทนที่เส้นทาง
• ec2:DescribeNetworkInterfaceAttribute
• ec2:ModifyNetworkInterfaceAttribute
• การกำหนดค่า Elastic IP (ส่วนหน้า):
• ec2: อธิบายที่อยู่
• ec2:ที่อยู่ผู้ร่วมงาน
• ec2: ยกเลิกการเชื่อมโยงที่อยู่

การติดตั้งไลฟ์คีปเปอร์

ติดตั้ง SIOS LifeKeeper บนแต่ละโหนด ซึ่งเกี่ยวข้องกับการเรียกใช้สคริปต์การติดตั้งและปฏิบัติตามวิซาร์ดการตั้งค่า ซึ่งจะแนะนำคุณตลอดขั้นตอนที่จำเป็น สำหรับการติดตั้งนี้ ฉันใช้เครือข่าย, Route53 ARK และฐานข้อมูล, SAP HANA ARK พร้อมกับฟังก์ชันพยาน

แก้ไขไฟล์ /etc/selinux/config และปิดการใช้งาน selinux:

ฉันยังเปลี่ยนชื่อโฮสต์และแก้ไขไฟล์ /etc/hosts ด้วย ในที่สุดก็แก้ไขไฟล์ /etc/default/LifeKeeper และเพิ่ม /usr/local/bin ใน PATH:

เปลี่ยน NOBCASTPING=1:

ฉันยังเปลี่ยน QUORUM_LOSS_ACTION เป็น osu ด้วย:

ตรวจสอบให้แน่ใจว่าคุณใช้งาน Xwindows ได้ ฉันลบนามแฝง cp ออกจาก .bashrc และเพิ่ม /opt/LifeKeeper/bin และ /usr/local/bin ไปยัง .bash_profile ของฉัน พร้อมกับคัดลอกไฟล์ ec2-users .Xauthority ไปยังรูทและโฮมไดเร็กทอรี <SID>adm เพื่อให้ Xwindows จะทำงาน:

ฉันเปลี่ยนรหัสผ่านรูทและรีบูต ก่อนที่จะเปิดตัว LifeKeeper GUI ตรวจสอบให้แน่ใจว่า HSR ออนไลน์อยู่บนทุกโหนดและลงทะเบียนโหนดทั้งหมดแล้ว:

การกำหนดค่า

เปิด LifeKeeper GUI: lkGUIapp และเข้าสู่ระบบด้วยผู้ใช้รูทและรหัสผ่าน:

คลิกที่ปุ่มเชื่อมต่อเพื่อเข้าสู่โหนดเพิ่มเติมในคลัสเตอร์:

เมื่อเข้าสู่โหนดทั้งหมดแล้วให้คลิกที่ปุ่มสร้างเส้นทางการสื่อสาร:

กดถัดไปเมื่อถามถึง Local Server จากนั้นกด shift ค้างไว้และเลือกโหนดทั้งหมด:

กดยอมรับค่าเริ่มต้นและกดเสร็จสิ้นเมื่อเสร็จสิ้น คลิกที่ปุ่มสร้างเส้นทางการสื่อสารอีกครั้ง และคราวนี้เปลี่ยนเป็นโหนดที่สอง:

กดถัดไปและเลือกโหนดที่ 3:

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

เลือกชุด IP และกดถัดไป:

กดถัดไปจนกว่าคุณจะไปที่หน้าทรัพยากร IP ที่นี่ป้อน 0.0.0.0 และกดถัดไป:

กดถัดไปจนกว่าคุณจะไปที่ปุ่มสร้าง กดปุ่มสร้าง:

เมื่อเสร็จสิ้นแล้วให้กดถัดไป: กดยอมรับค่าเริ่มต้นโดยเซิร์ฟเวอร์เป้าหมายจะแสดงโหนดที่สอง:

เมื่อกดเสร็จแล้วเซิร์ฟเวอร์ถัดไป:

กดยอมรับค่าเริ่มต้นโดยแสดงโหนดที่ 3 และเมื่อกดเสร็จสิ้น:

ตีเสร็จแล้ว:

ตอนนี้เรามีทรัพยากร IP แล้ว เราสามารถเพิ่มทรัพยากร Route53 ของเราได้ ซึ่งจะเปลี่ยนรายการ DNS เพื่อแก้ไข fqdn เป็นที่อยู่ IP ของโหนดที่ใช้งานอยู่ ในกรณีนี้ saphana.sapdemo จะแก้ไขเป็นที่อยู่ IP ของ sapdemohana1 (172.31.0.25) กดปุ่มสร้างลำดับชั้นทรัพยากรเพื่อเริ่มกระบวนการ:

เลือก Route53 และกดถัดไป:

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

ป้อนชื่อโฮสต์ที่ทุกอย่างจะใช้เชื่อมต่อกับฐานข้อมูล HANA และกดถัดไป:

กดถัดไปจนกว่าคุณจะไปถึงปุ่มสร้างแล้วคลิกปุ่มสร้าง เมื่อเสร็จแล้วให้กด ถัดไป:

ที่ Pre-Extend Wizard ให้กดยอมรับค่าเริ่มต้น:

เมื่อเสร็จแล้วให้กด Next Server:

เซิร์ฟเวอร์เป้าหมายจะแสดงโหนดที่ 3 กดยอมรับค่าเริ่มต้น:

กด Finish เมื่อเสร็จแล้ว จากนั้นกดเสร็จสิ้น จากนั้นคุณสามารถขยายต้นไม้ได้ เปิดเซสชันเทอร์มินัลไปยังโหนดที่ 2 และ ping fqdn สำหรับฐานข้อมูล HANA [เช่น ปิง -c3 saphana.sapdemo]

คลิกขวาที่สแตนด์บายด้านบนใต้ sapdemohana3 และเลือก In Service:

Hit In Service ในหน้าจอถัดไปจากนั้นกด Done เมื่อเสร็จสิ้น:

ไปที่หน้าต่างเทอร์มินัลแล้วทำการทดสอบ ping ซ้ำ:

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

ขั้นตอนที่ 4: การรวม SAP HANA เข้ากับ SIOS LifeKeeper

การสร้างลำดับชั้นทรัพยากร

ใช้ LifeKeeper GUI สร้างลำดับชั้นทรัพยากรสำหรับ SAP HANA บนแต่ละโหนด การตั้งค่านี้มีความสำคัญอย่างยิ่งต่อการจัดการกระบวนการเฟลโอเวอร์และการกู้คืน ตรวจสอบให้แน่ใจว่า HSR ทำงานบนโหนด 1 และมีการลงทะเบียนโหนดเพิ่มเติม:

คลิกที่ปุ่มสร้างทรัพยากร:

เลือกชุดการกู้คืน SAP HANA และกดถัดไปจนกว่าคุณจะไปที่หน้าจอที่อยู่ IP:

เลือกไม่มีแล้วกดถัดไป:

กดถัดไปจนกว่าคุณจะไปที่หน้าจอสร้างแล้วกดสร้าง:

หลังจากสร้างแล้วให้กด Next จากนั้นยอมรับค่าเริ่มต้นสำหรับ node2:

อีกครั้งเมื่อ node2 เสร็จสิ้นให้กด Next Server และยอมรับค่าเริ่มต้น:

เมื่อกดเสร็จแล้วให้กด Finish จากนั้นกด Done:

คลิกขวาที่ลำดับชั้นของ Hana และเลือกสร้างการพึ่งพา:

สำหรับแท็กทรัพยากรย่อย ให้เลือกทรัพยากร Route53 จากเมนูแบบเลื่อนลงแล้วกดถัดไป:

คลิกที่สร้างการพึ่งพา:

คลิกที่เสร็จสิ้น จากนั้นเลือกดูขยายต้นไม้:

หากทุกอย่างเป็นสีเขียว เราก็พร้อมที่จะทดสอบ

ขั้นตอนที่ 5: การทดสอบและการตรวจสอบความถูกต้อง

การทดสอบการเฟลโอเวอร์/สวิตช์โอเวอร์

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

การทดสอบแรกที่เราจะดำเนินการคือการเปลี่ยนไปใช้กิจกรรมการบำรุงรักษาหรือหากคุณมีกำหนดการหยุดทำงาน คลิกขวาที่โหนดที่ 2 แล้วเลือก In Service – Takeover with Handshake…

กดดำเนินการเทคโอเวอร์:

การทดสอบนี้จะสลับไปยังโหนดที่ 2 โดยที่ผู้ใช้มีเวลาหยุดทำงานน้อยที่สุด เมื่อโหนดที่ 2 เริ่มทำงานและทำงานเสร็จสิ้น:

หลังจากผ่านไประยะหนึ่ง node1 จะกลับมาเข้าสู่โหมดสแตนด์บาย – กำลังซิงค์

ตอนนี้เราสามารถทำการทดสอบการเฟลโอเวอร์ได้แล้ว เปิดเทอร์มินัลไปยังโหนด 2 และพิมพ์ echo c > /proc/sysrq-trigger เพื่อจำลองระบบล่ม คุณจะเห็นโหนด 1 เข้ายึดครองเนื่องจากมีลำดับความสำคัญสูงสุดที่ 1:

ในที่สุดทุกอย่างก็จะกลับมาเป็นปกติ:

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

การตรวจสอบการซิงโครไนซ์ข้อมูล

ตรวจสอบว่ามีการจำลองข้อมูลอย่างถูกต้องในทุกโหนด ข้อมูลที่สอดคล้องกันระหว่างโหนดมีความสำคัญอย่างยิ่งต่อความสมบูรณ์ของการตั้งค่า HSR

การตรวจสอบประสิทธิภาพ

ตรวจสอบประสิทธิภาพของอินสแตนซ์ SAP HANA และการตั้งค่า LifeKeeper เป็นประจำ ตรวจสอบความผิดปกติหรือปัญหาที่อาจบ่งบอกถึงปัญหาที่อาจเกิดขึ้น ตรวจสอบไฟล์ /var/log/lifekeeper.log เพื่อให้แน่ใจว่าทุกอย่างทำงานได้ตามที่คาดไว้ คุณอาจต้องปรับตัวจับเวลา Heartbeat และจำนวนการเต้นของหัวใจที่พลาดไป ขึ้นอยู่กับประสิทธิภาพของเครือข่าย สิ่งเหล่านี้สามารถกำหนดค่าได้ในไฟล์ /etc/default/LifeKeeper ความสามารถในการปรับได้คือ LCMHBEATTIME และ LCMNUMHBEATS คุณสามารถตรวจสอบสถานะของ Lifekeeper ได้จากบรรทัดคำสั่งด้วยคำสั่ง lcdstatus -q

บทสรุป

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

SIOS จัดให้ทรัพยากรและการฝึกอบรมสำหรับผลิตภัณฑ์ทั้งหมดของเรา

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

เขตเมืองหลวงแห่งชาติของสหรัฐอเมริกาปกป้องบริการจัดส่งเหตุฉุกเฉินที่สำคัญด้วย SIOS DataKeeper

เขตเมืองหลวงแห่งชาติของสหรัฐอเมริกาปกป้องบริการจัดส่งเหตุฉุกเฉินที่สำคัญด้วย SIOS DataKeeper

SIOS DataKeeper ปกป้องซอฟต์แวร์ CAD-EX CAD2CAD ที่สำคัญบน SQL Server ใน Azure

จนกระทั่งเมื่อไม่นานมานี้ ผู้มอบหมายงานใช้ระบบการจัดส่งโดยใช้คอมพิวเตอร์ช่วย (CAD) ซึ่งสันนิษฐานว่าน่าจะอยู่ที่ไหนและความพร้อมของหน่วยในเขตอำนาจศาลใกล้เคียง แต่ในการขอจัดส่ง พวกเขาต้องโทรหาหน่วยงานใกล้เคียงเหล่านั้นด้วยสายโทรศัพท์เฉพาะเพื่อตรวจสอบตำแหน่งของหน่วยจริงและความพร้อม . กระบวนการนี้ทำให้เวลาตอบสนองช้าลง และไม่ได้ให้ผู้เผชิญเหตุคนแรกเข้าถึงรายละเอียดเหตุการณ์สำคัญที่อาจได้รับจากหน่วยงานจัดส่ง

เพื่อปรับปรุงประสิทธิภาพ ผู้นำหน่วยงาน NCR และ Emerging Digital Concepts (EDC) ร่วมมือกันสร้าง Data Exchange Hub (DEH) ซึ่งเป็นแพลตฟอร์มการแลกเปลี่ยนข้อมูลและการทำงานร่วมกันที่ออกแบบมาเพื่อให้หน่วยงานบริการฉุกเฉิน NCR ของสมาชิกสามารถเข้าถึงข้อมูลและแอปพลิเคชันได้อย่างปลอดภัย พวกเขาใช้ National Information Exchange Model (NIEM) เพื่อรับรองการทำงานร่วมกันของระบบ การสื่อสาร และขั้นตอนต่างๆ

DEH ได้กลายเป็นต้นแบบระดับชาติของความร่วมมือระดับภูมิภาคที่มีประสิทธิภาพในการตอบสนองต่อเหตุฉุกเฉิน รับประกันบริการจัดส่งฉุกเฉินที่มีประสิทธิภาพสำหรับเขตเมืองหลวงแห่งชาติ SIOS DataKeeper ปกป้องซอฟต์แวร์ CAD-EX CAD2CAD ที่สำคัญบน SQL Server ใน Azure

การแลกเปลี่ยนข้อมูล DEH หลักคือการแลกเปลี่ยน CAD-to-CAD (C2C) ซึ่งช่วยให้ผู้มอบหมายงานในหน่วยงาน NCR DEH ทั้งหมดสามารถเข้าใจตำแหน่งของทรัพยากรแนวหน้า ความพร้อมของทรัพยากร และแบ่งปันข้อมูลล่าสุดเกี่ยวกับเหตุการณ์ที่เกี่ยวข้องในทันที C2C Exchange ทั้งหมดเชื่อมต่อกับระบบ CAD ในเขตอำนาจศาลของสมาชิก

NCR DEH C2C Exchange ใช้ฐานข้อมูล Microsoft SQL Server ที่ทำงานบน Windows Servers และปรับใช้ใน Azure Commercial Cloud เมื่อพิจารณาถึงลักษณะที่สำคัญของระบบเหล่านี้ DEH จึงต้องการการปกป้องข้อมูลที่มีความพร้อมใช้งานสูงสำหรับการทำคลัสเตอร์ล้มเหลวของแพลตฟอร์ม C2C Exchange โดยไม่มีการเพิ่มความซับซ้อน ในสภาพแวดล้อมความพร้อมใช้งานสูงของ Windows (HA) แบบดั้งเดิมที่เกี่ยวข้องกับฐานข้อมูล มีการกำหนดค่าโหนดอินสแตนซ์ฐานข้อมูลตั้งแต่สองรายการขึ้นไป คลัสเตอร์ล้มเหลวของ Windows Server พร้อมที่เก็บข้อมูลที่ใช้ร่วมกัน (โดยทั่วไปคือ SAN)

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

ในช่วงแรกของโครงการ ทีมไอทีของ NCR ได้ปรับใช้แพลตฟอร์ม C2C Exchange ในสภาพแวดล้อมต่างๆ ซึ่งรวมถึงศูนย์ข้อมูลในองค์กร Fairfax County และต่อมาในสภาพแวดล้อมของผู้ให้บริการโฮสติ้งบุคคลที่สาม ระดับชาติ และระดับท้องถิ่นหลายแห่ง ในสภาพแวดล้อมเหล่านี้ สถาปัตยกรรมการปรับใช้ฐานข้อมูล C2C Exchange ใช้ Microsoft SQL Server Enterprise Edition และ Always On Availability Groups

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

Azure Cloud ยังอนุญาตให้ NCR ปรับใช้โซลูชันการทำคลัสเตอร์ฐานข้อมูลที่มีความคุ้มค่าและมีความพร้อมใช้งานสูงเพื่อส่งมอบข้อมูลแอปพลิเคชัน C2C Exchange อย่างมั่นใจ ในขณะเดียวกันก็ลดต้นทุนลิขสิทธิ์ที่สูงขึ้นที่เกี่ยวข้องกับ SQL Server Enterprise Edition

การแก้ไขปัญหา

NCR DEH C2C Exchange เริ่มใช้ซอฟต์แวร์ SIOS DataKeeper Cluster Edition เพื่อสร้างคลัสเตอร์ SANless เพื่อปกป้องความพร้อมใช้งานของข้อมูล C2C Exchange ใน Azure Commercial Cloud ซอฟต์แวร์ทำงานบนการกำหนดค่าคลัสเตอร์ Windows Server Failover แบบแอคทีฟ-พาสซีฟแบบสองโหนดโดยใช้ SQL Server Standard Edition พร้อม Always On Failover Clustering

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

ผลลัพธ์

NCR DEH C2C Exchange ใช้ซอฟต์แวร์ SIOS DataKeeper Cluster Edition ใน Azure Commercial Cloud มานานกว่าสองปี การมีส่วนร่วมในโครงการการทำงานร่วมกันได้เติบโตขึ้น นอกเหนือจากสมาชิกเริ่มแรกแล้ว โครงการนี้ยังรวมถึง Metro Washington Airports Authority (MWAA), เทศมณฑลเวอร์จิเนียแห่ง Loudoun และ Prince William และเทศมณฑลแมริแลนด์แห่งมอนต์กอเมอรีและปรินซ์จอร์จ C2C Exchange จัดการหน่วยที่ใช้ร่วมกันสองสามพันหน่วยและแบ่งปันข้อมูลเกี่ยวกับเหตุการณ์นับแสนต่อปีระหว่างผู้เข้าร่วมเหล่านี้

การสร้างคลัสเตอร์ฐานข้อมูลที่มีความพร้อมใช้งานสูงในระบบคลาวด์ทำได้อย่างรวดเร็วและตรงไปตรงมาโดยใช้ SIOS DataKeeper Cluster Edition “เราเพิ่งติดตั้ง SIOS DataKeeper ลงในโหนด Windows Server Failover Cluster ของเรา กำหนดค่าพื้นที่จัดเก็บโหนดในเครื่องเป็นที่จัดเก็บข้อมูลที่จัดการโดย SIOS สำหรับการจำลอง และทำงานได้อย่างราบรื่น” Greg Crider ประธานเจ้าหน้าที่ฝ่ายเทคนิคและผู้ร่วมก่อตั้ง EDC กล่าว “ประโยชน์เพิ่มเติมของซอฟต์แวร์การทำคลัสเตอร์ SIOS DataKeeper คือช่วยให้เราสามารถดำเนินการบำรุงรักษาซอฟต์แวร์อย่างต่อเนื่องบนฐานข้อมูลโดยการเปลี่ยนโหนดคลัสเตอร์ตามความต้องการ โดยไม่จำเป็นต้องหยุดทำงานตามแผนหรือการหยุดชะงักของบริการ”

นับตั้งแต่ใช้งาน SIOS DataKeeper ใน NCR C2C Exchange ก็ไม่มีปัญหาการหยุดทำงานที่เกี่ยวข้องกับฐานข้อมูลหรือการสูญหายของข้อมูลระหว่างโหนด Chris Wiseman ประธาน ซีอีโอ และผู้ร่วมก่อตั้ง EDC กล่าวเสริมว่า “มีปัญหาด้านเครือข่ายที่ไม่คาดคิดและควบคุมไม่ได้อยู่บ้าง อย่างไรก็ตาม ฐานข้อมูลล้มเหลวอย่างรวดเร็วและการดำเนินการของ C2C Exchange ยังคงดำเนินต่อไปโดยที่ผู้ใช้ไม่ได้รับผลกระทบจากการลดการให้บริการเป็นเวลานาน ซอฟต์แวร์ SIOS DataKeeper ช่วยให้เราสามารถมอบการปกป้องข้อมูลและการส่งมอบในระดับที่สูงขึ้นโดยไม่จำเป็นต้องได้รับสิทธิ์การใช้งาน SQL Server Enterprise Edition ที่มีราคาแพงกว่า ซึ่งช่วยประหยัดเงินได้อย่างมีนัยสำคัญและต่อเนื่องทุกปีสำหรับผู้มีส่วนได้ส่วนเสียของเรา”

NCR C2C Exchange พร้อมการป้องกัน SIOS DataKeeper มีคุณลักษณะโดย DHS/SAFECOM ในลิงก์วิดีโอ) เมื่อเร็วๆ นี้ เกิดเหตุเพลิงไหม้ครั้งใหญ่ 3 ครั้งเกิดขึ้นพร้อมกันที่ธนาคาร อพาร์ทเมนต์ และบ้านพักคนชรา การทำงานร่วมกันระหว่างระบบ CAD มีบทบาทสำคัญในการรับประกันการตอบสนองต่อเหตุการณ์เหล่านี้อย่างรวดเร็วและมีประสิทธิภาพ

EDC กำลังขยายการนำ C2C Exchange ไปใช้ทั่วสหรัฐอเมริกาในตลาดอื่นๆ ด้วยผลิตภัณฑ์ NG-CAD-X C2C Exchange ที่มีจำหน่ายในท้องตลาด ข้อเสนอ C2C ขั้นสูงที่มีฟังก์ชันการทำงานนี้กำลังดำเนินการโดยเมือง Denver North Central All-Hazards Region และโดย Greater Southeast Florida NG-CAD-X เป็นข้อความที่เข้ากันได้กับ NCR C2C Exchange ซึ่งใช้งานใน Azure Government Cloud สำหรับการปฏิบัติตาม CJIS และการบังคับใช้กฎหมาย นอกเหนือจาก fire และ EMS ESF และยังใช้ SIOS DataKeeper Cluster Edition ในสถาปัตยกรรมฐานข้อมูลสำหรับทั้งหมด เหตุผลในการดำเนินงานและความคุ้มทุนที่เน้นไว้ข้างต้น “ความร่วมมือเชิงกลยุทธ์มีบทบาทสำคัญในการให้บริการลูกค้าของเราด้วยโซลูชั่นเทคโนโลยีที่ดีที่สุดในตลาด SIOS DataKeeper เป็นส่วนสำคัญของระบบของเราและเป็นพันธมิตร EDC ที่มีคุณค่า” Kevin Konczal รองประธาน EDC กล่าว

ดาวน์โหลดไฟล์ PDF

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