รับประกันความพร้อมใช้งานสูงสำหรับแอปพลิเคชันธนาคารบนคลาวด์

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

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

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

สร้างความมั่นใจในการเข้าถึงระบบคลาวด์

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

เริ่มต้นด้วยการบอกว่าการมี VM แบบคลัสเตอร์กระจายอยู่ใน AZ หลายๆ แห่งนั้นมีความสำคัญต่อการรับรองความพร้อมใช้งานสูง (HA) ของแอปพลิเคชันและข้อมูลหลักของคุณ สิ่งที่คุณต้องการเพิ่มเติมคือกลยุทธ์เพื่อให้แน่ใจว่า VM แต่ละเครื่องสามารถเข้าถึงแอปพลิเคชันและข้อมูลที่สำคัญที่คุณต้องการให้ทำงานต่อไป นั่นคือสิ่งที่แนวทางดั้งเดิมของ HA แตกต่างออกไปเมื่อพูดถึงระบบคลาวด์

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

การกำหนดค่าสำหรับคลาวด์

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

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

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

โซลูชันการจำลองข้อมูล

คุณมีตัวเลือกมากมายเมื่อพูดถึงโซลูชันการจำลองข้อมูล

หากคลัสเตอร์ของคุณใช้ Windows และคุณกำลังใช้ Microsoft SQL Server คุณสามารถใช้คุณลักษณะ Availability Groups (AGs) ในตัวของ SQL Server ซึ่งจะจำลองฐานข้อมูล SQL ที่มีชื่อผู้ใช้ไปยังแต่ละโหนดในคลัสเตอร์ของคุณโดยอัตโนมัติ ข้อเสียของแนวทางนี้คือทำซ้ำเฉพาะฐานข้อมูล SQL แทนที่จะเป็นบล็อกข้อมูลทุกบล็อกในที่จัดเก็บ การจำลองฐานข้อมูล SQL Server หลายฐานข้อมูลไปยัง VM ที่สแตนด์บายหลายเครื่องอาจมีราคาแพงมาก เนื่องจากคุณจะต้องใช้ SQL Server Enterprise Edition เพื่อจำลองฐานข้อมูลมากกว่าหนึ่งฐานข้อมูล หรือจำลองฐานข้อมูลไปยัง VM หลายเครื่อง แม้ว่าแอปพลิเคชันของคุณจะทำงานได้ดีอย่างสมบูรณ์โดยใช้ SQL Server Standard Edition .

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

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

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

Todd Doane เป็นสถาปนิกโซลูชันที่ SIOS Technology เขาใช้เวลามากกว่า 20 ปี โดยเฉพาะอย่างยิ่งในโลกบริการทางการเงิน สร้างสถาปัตยกรรมอ้างอิงที่มีความพร้อมใช้งานสูง รูปแบบและหลักการออกแบบเฉพาะแอปพลิเคชัน

• เนื้อหาที่ขับเคลื่อนด้วย SEO และการเผยแพร่ประชาสัมพันธ์ รับการขยายวันนี้
• เพลโตบล็อคเชน Web3 Metaverse ข่าวกรอง ขยายความรู้. เข้าถึงได้ที่นี่.
• ที่มา: https://bankautomationnews.com/allposts/core-cloud/ensuring-high-availability-for-cloud-based-banking-applications/