วิธีการตั้งค่า 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

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

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

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

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

 

สร้างความพร้อมใช้งานสูงด้วยคลัสเตอร์ 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