เอกสารไวท์เปเปอร์: โซลูชันความพร้อมใช้งานสูงช่วยประหยัดต้นทุนและความยืดหยุ่นสำหรับ Oracle

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

ดาวน์โหลด เอกสารไวท์เปเปอร์: โซลูชันความพร้อมใช้งานสูงช่วยประหยัดต้นทุนและความยืดหยุ่นสำหรับ Oracle

เอกสารไวท์เปเปอร์: การทำความเข้าใจความซับซ้อนของความพร้อมใช้งานสูงสำหรับแอปพลิเคชันที่มีความสำคัญต่อธุรกิจ

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

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

ขอแนะนำชุดโหลดบาลานเซอร์ทั่วไปสำหรับ SIOS LifeKeeper และ Google Cloud

นี้จะหารือเกี่ยวกับ ชุดกู้คืนแอปพลิเคชัน Load-Balancer ทั่วไป (ARK) สำหรับ SIOS Lifekeeper สำหรับ Linux และวิธีกำหนดค่าบน Google Cloud โดยเฉพาะ SIOS ARK เป็นปลั๊กอินสำหรับผลิตภัณฑ์ SIOS LifeKeeper ที่เพิ่มการรับรู้แพลตฟอร์มหรือแอปพลิเคชัน

บล็อกนี้แสดงให้เห็นว่าการใช้คลัสเตอร์ NFS แบบสองโหนดและการเอ็กซ์พอร์ต NFS ที่จัดหาให้ในท้ายที่สุดสามารถเข้าถึงได้ผ่านตัวโหลดบาลานซ์ได้อย่างไร

SIOS ได้สร้าง ARK นี้เพื่ออำนวยความสะดวกในการเปลี่ยนเส้นทางไคลเอ็นต์ใน SIOS LifeKeeper คลัสเตอร์ที่ทำงานใน GCP .

เนื่องจาก GCP ไม่รองรับ ARP ที่ไม่เสียค่าใช้จ่าย ซึ่งเป็นคำขอออกอากาศสำหรับที่อยู่ IP ของเราเตอร์เอง ไคลเอ็นต์จึงไม่สามารถเชื่อมต่อโดยตรงกับที่อยู่ IP เสมือนของคลัสเตอร์แบบเดิมได้ แต่ไคลเอ็นต์ต้องเชื่อมต่อกับตัวโหลดบาลานซ์และตัวโหลดบาลานซ์จะเปลี่ยนเส้นทางการรับส่งข้อมูลไปยังโหนดคลัสเตอร์ที่ใช้งานอยู่ GCP ใช้โซลูชันโหลดบาลานเซอร์แยกต่างหากที่ทำงานบนเลเยอร์ 4 TCP, UDP เลเยอร์ 4 หรือ HTTP/HTTP เลเยอร์ 7 โดยสามารถกำหนดค่าตัวจัดสรรภาระงานให้มี IP ฟรอนต์เอนด์ส่วนตัวหรือสาธารณะ ซึ่งเป็นโพรบสุขภาพที่สามารถกำหนดได้ โหนดทำงานอยู่ ชุดของที่อยู่ IP แบ็กเอนด์ (สำหรับแต่ละโหนดในคลัสเตอร์) และกฎการรับส่งข้อมูลเครือข่ายขาเข้า/ขาออก

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

การติดตั้งและการกำหนดค่าใน GCP นั้นตรงไปตรงมาและมีรายละเอียดด้านล่าง:

ภายในพอร์ทัล GCP ให้เลือกการจัดสรรภาระงาน ในกรณีนี้ เราต้องการ TCP Load Balancing สร้างตัวโหลดบาลานซ์ คุณจะเลือกกลุ่มทรัพยากรที่คุณต้องการปรับใช้สิ่งนี้พร้อมกับชื่อ ฉันชอบใช้ชื่อที่ตรงกับประเภทคลัสเตอร์ที่ฉันเป็น การใช้ตัวโหลดบาลานซ์ เช่น IMA-NFS-LB จะนั่งอยู่หน้าโหนด IMA-NFS ทั้งสอง

คุณสามารถกำหนดได้ว่าจะเชื่อมต่อกับอินเทอร์เน็ตหรือภายใน VPC ของคุณ ในกรณีนี้ ฉันกำลังกำหนดค่า Load-Balancer เฉพาะภายในให้กับเซิร์ฟเวอร์ NFS ของฉันเพื่อใช้ภายใน VPC ของฉันเท่านั้น

เมื่อคุณกำหนดชื่อ ภูมิภาค ฯลฯ แล้ว คุณจะถูกขอให้กำหนดการกำหนดค่าแบ็กเอนด์ ซึ่งจะต้องใช้กลุ่มอินสแตนซ์ที่มีโหนด HA ที่คุณจะใช้ส่วนหน้า

เมื่อคุณกำหนดกลุ่มอินสแตนซ์แล้ว คุณจะต้องกำหนดการตรวจสอบสภาพ ซึ่งเป็นพอร์ตที่ตรงกับพอร์ตที่คุณจะใช้ในการกำหนดค่า Lifekeeper Generic Load-balancer ในกรณีนี้ ฉันใช้ 54321 โปรดสังเกตหมายเลขพอร์ตอีกครั้งเนื่องจากจะใช้กับ Lifekeeper

ฉันเพิ่งติดอยู่กับค่าเริ่มต้นสำหรับเกณฑ์ด้านสุขภาพ

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

คุณจะกำหนดค่า IP ของคุณและสิ่งนี้จะตรงกับ IP ของ Lifekeeper ที่คุณกำลังปกป้อง

เมื่อคุณพอใจกับการกำหนดค่าแล้ว คุณสามารถตรวจสอบหรือคลิกสร้างก็ได้

เมื่อเราเลือก "สร้าง" แล้ว GCP จะเริ่มปรับใช้ Load Balancer ซึ่งอาจใช้เวลาหลายนาที และเมื่อเสร็จสิ้นการกำหนดค่าจะย้ายไปที่ SIOS Protection Suite

การกำหนดค่าด้วย SIOS Protection Suite

สำหรับบล็อกนี้ ฉันได้กำหนดค่าการส่งออก NFS สามรายการเพื่อป้องกันโดยใช้ SPS-L การส่งออกทั้งสามรายการได้รับการกำหนดค่าให้ใช้ IP เดียวกันกับ IP ส่วนหน้าของตัวจัดสรรภาระงาน GCP ฉันกำลังใช้ ผู้เก็บข้อมูล เพื่อทำซ้ำข้อมูลที่เก็บไว้ในการส่งออก

ขั้นตอนแรกคือการรับสคริปต์ วิธีที่ง่ายที่สุดคือการใช้ wget แต่คุณยังสามารถดาวน์โหลดแพ็คเกจทั้งหมดและอัปโหลด rpm ไปยังโหนดโดยตรงโดยใช้ winscp หรือเครื่องมือที่คล้ายกัน คุณต้องติดตั้ง Hotfix บนโหนดทั้งหมดในคลัสเตอร์ Lifekeeper

สามารถรับชุดการกู้คืนทั้งหมดได้ที่นี่: http://ftp.us.sios.com/pickup/LifeKeeper_Linux_Core_en_9.5.1/patches/Gen-LB-PL-7172-9.5.1 ชิ้นส่วนต่างๆ สามารถพบได้ที่นี่ด้วย wget: wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm.md5sum wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/Gen-LB-readme.txt เมื่อดาวน์โหลดแล้ว ให้ตรวจสอบผลรวม MD5 กับค่าที่บันทึกไว้ในไซต์ FTP

ติดตั้ง RPM ดังต่อไปนี้: รอบต่อนาที -ivh steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm ตรวจสอบว่าการติดตั้งสำเร็จโดยการรัน: rpm -qa | grep steeleye-lkHOTFIX-Gen-LB-PL-7172 หากคุณต้องการลบ RPM ด้วยเหตุผลบางประการ สามารถทำได้โดยเรียกใช้: rpm -e steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64 ด้านล่างนี้คือ GUI ที่แสดงการส่งออก NFS สามรายการที่ฉันกำหนดค่าไว้แล้ว: สิ่งที่เราต้องทำภายใน ชุดป้องกัน SIOS กำหนด Load Balancer โดยใช้สคริปต์ Hotfix ที่ SIOS ให้มา

ขั้นแรก เราสร้างลำดับชั้นของทรัพยากรใหม่ เราเลือก Generic Application จากดรอปดาวน์ กำหนดสคริปต์ restore.pl ที่อยู่ใน /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/ กำหนดสคริปต์ remove.pl ที่อยู่ใน /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/ กำหนดสคริปต์ quickCheck ที่อยู่ใน /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/ ไม่มีสคริปต์การกู้คืนในเครื่อง ดังนั้นโปรดล้างอินพุตนี้ เมื่อถามถึง Application Info เราต้องการป้อนหมายเลขพอร์ตเดียวกันกับที่เรากำหนดค่าไว้ในพอร์ต Healthcheck เช่น 54321 เราจะเลือกนำบริการมาให้บริการเมื่อสร้างเสร็จ Resource Tag คือชื่อที่เราจะเห็นแสดงใน SPS-L GUI ผมชอบใช้อะไรที่ทำให้ง่ายต่อการระบุ หากทุกอย่างได้รับการกำหนดค่าอย่างถูกต้อง คุณจะเห็น "END การคืนค่าสำเร็จ" เราสามารถขยายไปยังโหนดอื่นเพื่อให้สามารถโฮสต์ทรัพยากรบนโหนดใดโหนดหนึ่งได้

นี่แสดงการกำหนดค่า Load Balancer ที่เสร็จสมบูรณ์ตามส่วนขยายของโหนดทั้งสอง ขั้นตอนสุดท้ายสำหรับคลัสเตอร์นี้คือการสร้างการพึ่งพาลูกสำหรับการส่งออก NFS สามรายการ ซึ่งหมายความว่าการส่งออก NFS ทั้งหมดที่มีมิเรอร์ Datakeeper และ IP จะใช้โหลดบาลานเซอร์ หากเกิดปัญหาร้ายแรงบนโหนดที่ทำงานอยู่ ทรัพยากรเหล่านี้ทั้งหมดจะล้มเหลวไปยังโหนดที่ทำงานอยู่อื่น

ด้านบน ลำดับชั้นที่สมบูรณ์ใน Lifekeeper GUI ด้านล่างแสดงมุมมอง GUI ที่ขยายซึ่งแสดงการส่งออก NFS, IP, ระบบไฟล์ และ DataKeeper ที่จำลองแบบโวลุ่มเป็นลูกของทรัพยากรตัวจัดสรรภาระงาน

นี่เป็นเพียงตัวอย่างหนึ่งของวิธีที่คุณสามารถใช้ SIOS LifeKeeper ใน GCP เพื่อปกป้องคลัสเตอร์ NFS อย่างง่าย แนวความคิดเดียวกันนี้ใช้กับแอปพลิเคชันที่สำคัญทางธุรกิจใดๆ ที่คุณต้องการปกป้อง คุณเพียงแค่ต้องใช้ Load Balancer ARK ที่จัดทำโดย SIOS เพื่อให้ GCP Load Balancer (อินเทอร์เน็ตหรือภายใน) กำหนดว่าโหนดใดกำลังโฮสต์แอปพลิเคชันอยู่

วิธีลดการหยุดทำงานของ SAP

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

มีส่วนประกอบทั่วไปหลายอย่างในแนว SAP ที่สามารถถือเป็นจุดล้มเหลวเพียงจุดเดียว ASCS (บริการส่วนกลาง), HANA DB, โหนด NFS และเซิร์ฟเวอร์แอปพลิเคชัน SAP ตามหลักการแล้วสิ่งเหล่านี้ควรได้รับการปกป้องโดยใช้เซิร์ฟเวอร์สำรองในการกำหนดค่า High Availability

เป้าหมาย HA/DR สำหรับ SAP

เป้าหมายหลักในการออกแบบส่วนประกอบของ High Availability/Disaster Recovery สำหรับ SAP ควรเป็น:

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

การใช้ ความพร้อมใช้งานสูง โซลูชันเช่น SIOS Protection Suite นำเสนอความพร้อมใช้งานสูงอัจฉริยะควบคู่ไปกับการจำลองดิสก์ในเครื่องเพื่อให้แน่ใจว่าแอปพลิเคชันและบริการ SAP ของคุณได้รับการตรวจสอบ ป้องกัน และมีความสามารถในการเปลี่ยนไปใช้ฮาร์ดแวร์สำรองโดยอัตโนมัติเมื่อตรวจพบความล้มเหลว

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

ตอนนี้ ลองจินตนาการว่าสภาพแวดล้อมการประมวลผลการขายนี้ (ภาพด้านบน) ได้รับการกำหนดค่าในระบบคลาวด์โดยไม่มี HA เนื่องจากสถาปนิกคิดว่าฮาร์ดแวร์ที่ซ้ำซ้อนอย่างมากในสภาพแวดล้อมคลาวด์นั้นดีพอที่จะป้องกันจากความล้มเหลวได้หากฐานข้อมูล HANA นั้นประสบปัญหาและปิดตัวลง ให้ดูขั้นตอนที่จำเป็นโดยทั่วไปในการทำให้ฐานข้อมูลสำรองและทำงาน: ● แม้ว่า HANA จะได้รับการกำหนดค่าด้วย HANA System Replication แต่การเฟลโอเวอร์ไปยังระบบ HANA DB สำรองจะไม่ทำงานโดยอัตโนมัติ การดำเนินการนี้จะต้องใช้ผู้ที่รู้จัก HANA เพื่อแก้ไข หลังจากตรวจพบความล้มเหลวและได้รับแจ้งการหยุดทำงาน
● ธุรกรรมแบบเรียลไทม์จากเว็บเซิร์ฟเวอร์จะถูกระงับจนกว่าปัญหาจะได้รับการแก้ไข หากผู้ค้าปลีกเสื้อผ้ารายย่อยรายนี้ทำธุรกรรมจากการขายทางเว็บประมาณ 10 ล้านดอลลาร์ต่อปี ซึ่งเท่ากับยอดขายประมาณ 1150 ดอลลาร์ต่อชั่วโมงต่อปี เวลาสูงสุดจะเสียค่าใช้จ่ายมากขึ้นต่อชั่วโมง

รายงานนี้จาก IBM แสดงให้เห็นว่าต้นทุนการหยุดทำงานเฉลี่ยต่อชั่วโมงอยู่ที่ $10,000 รูปที่ 2: SAP Landscape ด้วย HA/DR หากมีการใช้ซอฟต์แวร์ HA (รูปที่ 2) ความล้มเหลวของ HANA DB จะเป็นไปโดยอัตโนมัติ และการหยุดชะงักของเว็บเซิร์ฟเวอร์จะอยู่ภายในระยะหมดเวลาที่กำหนด และจะไม่มีการขายใดๆ หายไปโดยเด็ดขาด การแจ้งเตือนจะถูกสร้างขึ้นและสามารถดูสาเหตุและวินิจฉัยได้แบบสบาย ๆ มากกว่าสถานการณ์ที่ระบบล่ม

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

อื่น รายงานของไอบีเอ็ม แสดงให้เห็นว่า 44% ของผู้ตอบแบบสอบถามมีปัญหาการหยุดทำงานโดยไม่ได้วางแผนทุกๆ 2 เดือน และอีก 35% มีการหยุดทำงานโดยไม่ได้วางแผนเป็นรายเดือน

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

ดูข้อมูลเพิ่มเติมเกี่ยวกับ ความพร้อมใช้งานสูงสำหรับ SAP และ S/4HANA .