มกราคม 19, 2024 |
การสัมมนาผ่านเว็บ: การกู้คืนความเสียหายบนคลาวด์: การทำความเข้าใจความท้าทายและกลยุทธ์สำหรับ SQL Serverการสัมมนาผ่านเว็บ: การกู้คืนความเสียหายบนคลาวด์: การทำความเข้าใจความท้าทายและกลยุทธ์สำหรับ SQL Serverลงทะเบียนเข้าร่วมสัมมนาออนไลน์ตามความต้องการการรับรองความพร้อมใช้งานสูง (HA) และการกู้คืนความเสียหาย (DR) ในระบบคลาวด์อาจเป็นเรื่องท้าทายสำหรับหลายองค์กร ความท้าทายที่เกี่ยวข้องกับ HA/DR ในระบบคลาวด์ ได้แก่ ความซับซ้อนของการใช้เครื่องมือต่างๆ จากผู้จำหน่ายระบบคลาวด์ที่แตกต่างกัน ข้อพิจารณาเกี่ยวกับอธิปไตยของข้อมูล ความท้าทายในการปฏิบัติตามข้อกำหนด และการจัดการต้นทุนอย่างต่อเนื่อง การสัมมนาผ่านเว็บนี้จะหารือเกี่ยวกับวิธีจัดการกับความท้าทายเหล่านั้น โดยเน้นความสำคัญของความซ้ำซ้อนและการเฟลโอเวอร์สำหรับบริการและการปกป้องข้อมูลที่ไม่หยุดชะงัก และสำรวจความเข้าใจผิดที่พบบ่อยเกี่ยวกับความยืดหยุ่นของระบบคลาวด์และความจำเป็นในการสำรองข้อมูลที่แข็งแกร่งและกลยุทธ์ DR ทำซ้ำโดยได้รับอนุญาตจากSIOS
|
มกราคม 14, 2024 |
สร้างความพร้อมใช้งานสูงด้วยคลัสเตอร์ HSR 3 โหนด HANA ใน AWS โดยใช้ SIOS LifeKeeperสร้างความพร้อมใช้งานสูงด้วยคลัสเตอร์ HSR 3 โหนด HANA ใน AWS โดยใช้ SIOS LifeKeeperบทนำ: วิธีตรวจสอบ HA และ DR ในฐานข้อมูลของคุณการสร้างสภาพแวดล้อม SAP HANA ที่พร้อมใช้งานสูงใน AWS ถือเป็นงานที่สำคัญสำหรับธุรกิจจำนวนมาก คู่มือนี้ให้คำแนะนำโดยละเอียดสำหรับการตั้งค่าคลัสเตอร์ HANA System Replication (HSR) แบบ 3 โหนดโดยใช้SIOS ไลฟ์คีปเปอร์ใน AWS สร้างความมั่นใจในฐานข้อมูลความยืดหยุ่นและความพร้อมใช้งานสูง. ข้อกำหนดเบื้องต้น
ขั้นตอนที่ 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 เหล่านี้ หากคุณพยายามใช้ที่เก็บข้อมูลที่ใช้ร่วมกัน คุณจะไม่สามารถสร้างเซิร์ฟเวอร์ที่เหมือนกันได้ เนื่องจาก 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
สร้างพาร์ติชั่น ฟอร์แมตที่เก็บข้อมูล และแนบมัน สร้างไฟล์สลับของคุณ ฉันสร้างคีย์ RSA บนโฮสต์ทั้งหมดของฉัน จากนั้นอนุญาตให้รูทเข้าสู่ระบบ ssh ระหว่างโหนด hana โดยการเพิ่มคีย์สาธารณะลงในไฟล์ .ssh/authorized_keys ซึ่งจะทำให้การติดตั้งง่ายขึ้นมาก เมานต์วอลลุ่มสื่อการติดตั้ง HANA ของคุณ
รัน hdblcm จากไดเร็กทอรีสื่อการติดตั้ง hana ที่ถูกต้อง เมื่อคุณติดตั้ง HANA บนโหนดทั้งหมดเรียบร้อยแล้ว คุณก็พร้อมสำหรับขั้นตอนต่อไป การตั้งค่าการจำลองแบบระบบ คุณจะต้องสำรองข้อมูลก่อนเปิดใช้งาน HSR:
ทำซ้ำขั้นตอนการสำรองข้อมูลด้านบนในทุกโหนด กำหนดค่าการจำลองระบบ 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 หลักไปยังตำแหน่งที่ต้องการ:
ตรวจสอบให้แน่ใจว่าเจ้าของไฟล์คีย์และ dat เป็น <SID>adm sapsys:
ลงทะเบียนระบบ HANA เพิ่มเติมกับระบบ HANA หลัก – ต้องทำในฐานะผู้ใช้ที่เป็นผู้ดูแลระบบ:
[เช่น. 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 และกำหนดค่าด้วยคีย์ที่มีสิทธิ์ต่อไปนี้: การกำหนดค่าตารางเส้นทาง (แบ็กเอนด์):
การติดตั้งไลฟ์คีปเปอร์ ติดตั้ง 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
|
มกราคม 9, 2024 |
เขตเมืองหลวงแห่งชาติของสหรัฐอเมริกาปกป้องบริการจัดส่งเหตุฉุกเฉินที่สำคัญด้วย SIOS DataKeeperเขตเมืองหลวงแห่งชาติของสหรัฐอเมริกาปกป้องบริการจัดส่งเหตุฉุกเฉินที่สำคัญด้วย SIOS DataKeeperSIOS 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 กล่าว ทำซ้ำโดยได้รับอนุญาตจากSIOS |
มกราคม 4, 2024 |
การสัมมนาออนไลน์: รักษาความปลอดภัย SAP และ SAP S/4HANA ของคุณบน Azure: แนวทางปฏิบัติที่ดีที่สุดในการกู้คืนความเสียหายการสัมมนาออนไลน์: รักษาความปลอดภัย SAP และ SAP S/4HANA ของคุณบน Azure: แนวทางปฏิบัติที่ดีที่สุดในการกู้คืนความเสียหายในโลกดิจิทัลในปัจจุบัน การรักษาความปลอดภัยแอปพลิเคชันทางธุรกิจที่สำคัญ เช่น SAP และ SAP S/4HANA เป็นสิ่งสำคัญอย่างยิ่งในการป้องกันภัยพิบัติที่อาจเกิดขึ้นซึ่งอาจส่งผลกระทบต่อความต่อเนื่องทางธุรกิจ ด้วยการใช้ประโยชน์จากพลังของการประมวลผลแบบคลาวด์ Azure นำเสนอโซลูชันการกู้คืนความเสียหายที่มีประสิทธิภาพสำหรับสภาพแวดล้อม SAP และ SAP S/4HANA เซสชั่นการประชุมสัมมนาตามความต้องการนี้จะกล่าวถึงแนวทางปฏิบัติที่ดีที่สุดในการรักษาความปลอดภัยระบบ SAP และ SAP S/4HANA บน Azure รวมถึงกลยุทธ์สำหรับการจำลองข้อมูลสำรองและกู้คืน ความพร้อมใช้งานสูง และเฟลโอเวอร์ Harikrishna Madathala วิศวกรลูกค้าอาวุโสของ Microsoft ฝ่าย Fast Track ที่ SAP บนคลาวด์ Azure แบ่งปันข้อมูลเชิงลึก เคล็ดลับที่ใช้งานได้จริง และตัวอย่างในโลกแห่งความเป็นจริงเพื่อช่วยนำแนวทางปฏิบัติที่ดีที่สุดในการกู้คืนความเสียหายไปใช้เพื่อปกป้องการปรับใช้ SAP และ SAP S/4HANA บน Azure เพื่อให้มั่นใจถึงระดับสูงสุด ด้านความปลอดภัย ความยืดหยุ่น และความพร้อมใช้งานสำหรับแอปพลิเคชันทางธุรกิจที่สำคัญ ทำซ้ำโดยได้รับอนุญาตจากSIOS |
ธันวาคม 30, 2023 |
การสัมมนาผ่านเว็บ: ความยืดหยุ่นสำหรับ SAP บน AWS: แนวทางปฏิบัติที่ดีที่สุดเพื่อให้บรรลุความพร้อมใช้งานสูงและความต่อเนื่องทางธุรกิจการสัมมนาผ่านเว็บ: ความยืดหยุ่นสำหรับ SAP บน AWS: แนวทางปฏิบัติที่ดีที่สุดเพื่อให้บรรลุความพร้อมใช้งานสูงและความต่อเนื่องทางธุรกิจลงทะเบียนเข้าร่วมสัมมนาออนไลน์ตามความต้องการเซสชั่นการประชุมสัมมนาตามความต้องการนี้มุ่งเน้นไปที่แนวทางปฏิบัติที่ดีที่สุดเพื่อให้บรรลุผลความพร้อมใช้งานสูงและความต่อเนื่องทางธุรกิจสำหรับแอปพลิเคชัน SAP และ SAP S/4HANA บน AWS ด้วยการพึ่งพาโครงสร้างพื้นฐานคลาวด์ที่เพิ่มขึ้น จึงจำเป็นอย่างยิ่งที่ธุรกิจจะต้องมีระบบ SAP ที่ยืดหยุ่นและเชื่อถือได้เพื่อปกป้องข้อมูลและแอปพลิเคชันที่สำคัญจากการหยุดชะงักที่อาจเกิดขึ้น AWS ให้ภาพรวมที่ครอบคลุมขององค์ประกอบหลักของความพร้อมใช้งานสูงและการกู้คืนความเสียหายสำหรับ SAP และ SAP S/4HANA บน AWS รวมถึงการสำรองและการกู้คืน การจำลอง และการเปลี่ยนระบบเมื่อเกิดข้อผิดพลาด และสำรวจกลยุทธ์และเครื่องมือต่างๆ ที่มีอยู่บน AWS รับข้อมูลเชิงลึกเกี่ยวกับวิธีสร้าง SAP และ SAP S/4HANA บน AWS ที่ยืดหยุ่นและเชื่อถือได้ ทำซ้ำโดยได้รับอนุญาตจากSIOS
|