הבטחת זמינות גבוהה עבור יישומי בנקאות מבוססי ענן

הבטחת זמינות גבוהה עבור יישומי בנקאות מבוססי ענן

מפתה לחשוב שספק שירותי ענן יבטיח את הזמינות הגבוהה של יישומי הבנקאות הקריטיים שלך מבוססי ענן. הבעיה היא שהם ממש לא.

הבטחת זמינות גבוהה עבור יישומי בנקאות מבוססי ענן PlatoBlockchain Data Intelligence. חיפוש אנכי. איי.הבטחת זמינות גבוהה עבור יישומי בנקאות מבוססי ענן PlatoBlockchain Data Intelligence. חיפוש אנכי. איי.
טוד דואן, אדריכל פתרונות, SIOS Technology

ייתכן שספק הענן שלך עזר לך להגדיר אשכול של מכונות וירטואליות (VMs) שנגמר ממספר מרכזי נתונים או אזורי זמינות (AZ). ייתכן שהיא הטמיעה מערכת כשל אוטומטית כדי להבטיח ש-VM במצב המתנה בתצורה יכול להשתלט מיד אם ה-VM הראשי עובר לפתע במצב לא מקוון. הכל נשמע כאילו זה אמור לספק זמינות גבוהה, נכון?

אבל תסתכל מקרוב על הסכם רמת השירות (SLA) המתאר זמינות גבוהה: ה-SLA מבטיח שלפחות אחד מה-VMs במערכת שלך יהיה נגיש לפחות 99.9% או אפילו 99.99% מהזמן. אבל זו לא ערובה לזמינות יישום או נתונים. אם ה-VM שנותר אינו יכול לגשת לתשתית האחסון שבה נמצאים יישומי הבנקים והנתונים שלך, היישומים הקריטיים שלך אינם מקוונים ביעילות.

הבטחת נגישות בענן

איך אתה יכול להבטיח שהאפליקציות והנתונים הבנקאיים הקריטיים שלך יישארו נגישים מאוד בענן או בתצורה היברידית מקומית/ענן, אם קביעת התצורה של הטכנולוגיה הבסיסית למעבר כשל אוטומטי במספר AZs אינה מספקת?

נתחיל בכך שפיזור של מחשבי VM מקובצים בין מספר AZ הוא קריטי להבטחת הזמינות הגבוהה (HA) של האפליקציות והנתונים העיקריים שלך. עם זאת, מה שאתה צריך בנוסף הוא אסטרטגיה כדי להבטיח שלכל אחד מאותם VMs יש גישה ליישומים ולנתונים הקריטיים שאתה רוצה להמשיך לפעול. זה המקום שבו הגישות המסורתיות ל-HA מתפצלות בכל הנוגע לענן.

בתצורת HA מסורתית - כלומר מקומית - תוכל ליצור אשכול כשל המורכב ממספר שרתים או VMs ורשת שטח אחסון (SAN), שבה נמצאים היישומים והנתונים שלך. כל שרת או VM באשכול יכול לקיים אינטראקציה עם היישומים והנתונים ב-SAN, כך שאם ה-VM המריץ יישום מפתח באופן פתאומי יצא לא מקוון, האשכול ייכשל אוטומטית ל-VM אחר שיכול לקיים אינטראקציה עם ה-SAN ולהתחיל להפעיל את יישום ועדכון אותו מסד נתונים שהמכונה הקודמת השתמשה בו.

הגדרת תצורה עבור הענן

בענן, לעומת זאת, אין אפשרות אמיתית ליצור SAN משותף. יש כמה אפשרויות אחסון משותף, אבל הן לא בנויות כדי לספק את הביצועים או הרמות של HA שהאפליקציות הבנקאיות הקריטיות שלך דורשות. במקום זאת, תצורות HA מבוססות ענן תלויות באחסון עם ביצועים גבוהים המחוברים לכל אחד מה-VMs באשכול. כאשר VM נתון מריץ יישום, הוא מקיים אינטראקציה עם נתונים המאוחסנים במסד נתונים השוכן באחסון המצורף לאותו VM.

המפתח ל-HA עבור יישומי בנקאות מבוססי ענן, אם כן, הוא להבטיח שלכל VM באשכול שלך יהיו תמיד אותם יישומים ואותם נתונים. בדרך זו, אם ה-VM הראשי באשכול נהיה חשוך לפתע, האשכול יכול להיכשל אוטומטית ל-VM המתנה, שכל אחד מהם יכול להתחיל להפעיל את היישום ולקיים אינטראקציה עם הנתונים באופן מיידי מכיוון שעתק של היישום והנתונים נמצאים ב אחסון צמוד משלו.

ספק הענן שלך יכול להגדיר בקלות את ה-VMs שיספקו את רמות הביצועים והזמינות שהאפליקציות הקריטיות שלך דורשות. זה יכול גם לצרף מערכות אחסון עם ביצועים גבוהים לאותם מכשירי VM, והוא יכול להגדיר את האשכול שלך למעבר אוטומטי לכשל בכמה AZs. לאחר מכן, עליך לפרוס מנגנון שממכן את השכפול הסינכרוני של נתונים בין כל מערכות האחסון המחוברות ל-VMs באשכול ה-failover שלך.

פתרונות שכפול נתונים

יש לך מספר אפשרויות כשמדובר בפתרונות שכפול נתונים.

אם האשכול שלך מבוסס על Windows ואתה משתמש ב-Microsoft SQL Server, אתה יכול להשתמש בתכונה המובנית של קבוצות זמינות (AGs) של SQL Server, שתשכפל אוטומטית מסדי נתונים של SQL עם שם משתמש לכל אחד מהצמתים באשכול שלך. החיסרון של גישה זו הוא שהיא משכפלת רק מסדי נתונים של SQL, ולא כל בלוק נתונים באחסון. שכפול מסדי נתונים מרובים של SQL Server ל-VMs מרובים במצב המתנה עשוי להיות יקר מאוד מכיוון שתצטרך להשתמש ב-SQL Server Enterprise Edition כדי לשכפל יותר מבסיס נתונים אחד או לשכפל מסדי נתונים ל-VMs מרובים, גם אם היישומים שלך פועלים בצורה מושלמת באמצעות SQL Server Standard Edition .

לחלופין, תוכל להשתמש בפתרון אשכולות ללא SAN, המספק שכפול אוטומטי ברמת הבלוק של נתונים מה-VM הראשי הפעיל לכל אחד מה-VM המשניים באשכול. היתרון בשימוש בפתרון Clustering ללא SAN הוא היותו אגנוסטטי של יישומים ומסד נתונים; הוא פשוט משכפל בלוקים של נתונים ממערכת אחסון אחת לאחרת, ומבטיח שכל הנתונים במערכת האחסון הראשית שלך משוכפלים לכל אחד ממכשירי ה-VM האחרים. החיסרון בגישת אשכולות ללא SAN הוא שיש עוד פיסת תוכנה לצוות ה-IT שלך לרישיון וללמוד, דבר שעלול להרגיש מכביד אם תוכל להשתמש בפונקציונליות AG של SQL Server ללא עלות נוספת.

שכפול נתונים הוא המפתח להבטחת HA עבור מערכות בנקאיות מבוססות ענן, בין אם אתה משתמש בפונקציונליות המובנית בפתרון כמו SQL Server, או בפונקציונליות המסופקת על ידי פתרון אשכולות עצמאי ללא SAN.

ספק הענן שלך יכול לספק את התשתית בעלת הביצועים הגבוהים שהיישומים שלך דורשים, אך עליך לוודא שהנתונים והיישומים הזמינים לכל אחד מה-VMs באותו אשכול יהיו מעודכנים אם פתרון ה-HA שלך יפעל כמצופה כאשר אתה צריך זה לעשות זאת.

טוד דואן הוא אדריכל פתרונות ב-SIOS Technology. הוא בילה יותר מ-20 שנה, בעיקר בעולם השירותים הפיננסיים, ביצירת ארכיטקטורות התייחסות בזמינות גבוהה ודפוסי עיצוב ועקרונות ספציפיים ליישום.

בול זמן:

עוד מ בנקינובציה