הגן על בסיס הנתונים שלך: זמינות גבוהה לנתוני ביקוש רב

על ידי צוות Techopedia, 7 בדצמבר 2016

אסיפה: המארח אריק קוואנה דן בזמינות עם רובין בלור, דז בלנשפילד וברט סקלזו של IDERA.

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

אריק קוואנה: גבירותיי ורבותיי, שלום וברוך שוב שוב. הגיע השעה מזרחית בשעה ארבע ביום רביעי, ובימים אלה יכול להיות משמעות כמעט דבר אחד אם אתה נמצא בעולם הנתונים: הגיע הזמן שוב להוט טכנולוגיות! אכן כן.

שמי אריק קוואנה, אני אהיה המארח שלך לתוכנית. זה נועד להבין מה חם, מה קורה שם בחוץ, מה הדברים המגניבים שמשתמשים בהם בארגון, וכמובן, ממש בבסיס כל מה שאנחנו עושים בכל התחום הזה הוא בסיס הנתונים. אז אנחנו הולכים לדבר על הגנה על בסיס הנתונים שלך. הנושא המדויק הוא, "הגן על בסיס הנתונים שלך: זמינות גבוהה לנתוני ביקוש גבוהים." אז, יש שקופית לגביך באמת. ודי, הרביץ אותי בטוויטר, @eric_kavanagh.

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

אנו הולכים ללמוד מכמה מהטובים כיום בעסק - נשמע מד"ר רובין בלור משלנו, מומחה מסדי נתונים של כשלושה עשורים ברציפות. דז בלנשפילד שעושה זאת כבר זמן רב בערך, אבל הוא התחיל כשהיה ממש צעיר, וברט סקלזו מ- IDERA, שהוא באמת החגורה השחורה של מסד הנתונים. אז אל תתאפקו, אנשים, שאלו שאלות - החלק הגדול באירוע הזה הוא בעל ערך עבורכם הוא כשאתם שואלים שאלות טובות ומקבלים תשובות טובות, אז שלחו אותם דרך חלון הצ’אט או רכיב ה- Q ו- A בקונסולה שלכם.

ועם זה אני הולך למסור אותו לרובין בלור - קח אותו.

ד"ר רובין בלור: אוקיי, תן ​​לי ללחוץ על זה ולראות אם זה זז - זה כן. אני לא מתכוון לדבר במיוחד על בסיס נתונים. חשבתי את זה, אתה יודע, מכיוון שאני עושה את ההקדמה במבוא הראשון, אז אדבר על רמות השירות הצפויות וכמובן הזמינות, שהיא העסקה, שהיא נושא המופע של היום.

והשאלה היא, אתה יודע, "באמת, מהי זמינות? ואיזה חלק זה משחק באופן שאנשים מנהלים מרכזי נתונים בימינו? "דבר אחד שמתי לב אליו - שמתי לב לזה ממש מתישהו בשנות ה -90 - עבדתי באתר אחד והמשתמשים התחילו להתלונן מכיוון שהדוא"ל שלהם הושבת 15 דקות.

וזה היה מעניין מכיוון שלמינהל ה- CTO או מי שהיה אחראי על ה- IT היה למעשה, אחד המקומות הבודדים שבהם בימים ההם הם בעצם קבעו את רמות השירות והדוא"ל שהושקע למשך 15 דקות לא היה מפר את רמת השירות של אף אחד . אני חושב שמותר לצאת לשעתיים, למעשה. לא ניתן היה להשתמש בדואר האלקטרוני, אלא שלא ניתן היה לשלוח ולקבל כי השרת היה בחוץ. והסוג הזה הזעיק אותי כי שמתי לב להתקדם מאז, שהכל פשוט מאיץ וכך גם הציפיות של המשתמשים, וזה מוביל אותך למצב בו אנשים עשויים להיות בעלי שלוש רמות שירות, אך לעיתים קרובות הם יתחיל להתלונן כאשר רמות השירות לא מופרות בפועל.

אז ההגדרה של רמות השירות, רק כדי לתת - ובכן, זה יכול להיות תלוי בדיוק במה שאתה מדבר מבחינת רמות השירות. דיברנו על מערכת IT או על יישום IT. בדרך כלל הגדירו מבחינת ביצועים, זמינות ומדד - במילים אחרות, אינכם יכולים באמת להגדיר רמת שירות אלא אם כן תוכלו למדוד אותה, כך שבדרך כלל ישנה איזושהי מדידה ומדובר בדרך כלל בזמני תגובה, עסקאות מסוימות ו זמינות המערכות בפרק זמן מסוים, ולפני 1994-1995 בערך, היה נדיר מאוד שמערכות כלשהן נדרשות להיות זמינות יותר משעות עבודה רגילות. אז בואו נגיד שמונה בבוקר עד שש בערב, בכדי לתת טווח תקין - ואנשים בנו מערכות וככה וזה אומר - לדעתי, במיוחד עם בסיס הנתונים - תוכלו להגדיר את בסיס הנתונים בצורה מסוימת וכ חלון האצווה התחיל להתכווץ, הצורך לחשוב שוב התחיל להתעורר במערכות מסוימות ואז מערכות אחרות, ואז קיבלנו את הופעת השירות או הארכיטקטורה, שהתחילו ליצור תלות בין מערכות שלא היו תלויות בהן בעבר אחד את השני, מחמיר את הכל. קיבלנו את הסחיטה מבחינת הזמינות של המערכות.

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

רמות שירותי IT הן בדרך כלל חברות בת לרמות שירות של תהליכים עסקיים, אך ממש כפי שהיה באמת נדיר לפני 15 שנה שלארגון כלשהו היו רמות שירות מוגדרות היטב, עדיין נדיר לארגונים רמות שירות מוגדרות היטב לתהליכים עסקיים. . זה משהו שקורה עכשיו; זה לא משהו שקורה הרבה זמן.

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

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

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

כך שתוכלו לראות שמסגרות זמן מסוימות ויום, שבוע וחודשים לדברים שבהם התנהגות אצווה הגיונית ולכן אינכם נמצאים בעולם מעבד אירועים, ולכן הזמינות עשויה להיות שונה לגמרי מבחינת מה שאתם צריכים להיות מסוגל לספק. אך ברגע שאתה נמצא בעולם האירועים, אתה נמצא בזמינות של 24/7 ושינוי הטכנולוגיה הוא גורם שכן הטכנולוגיה עוברת מהר יותר ויותר, ייתכן שהזמינות לא תגדל; זה פשוט נשאר כמו שהוא.

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

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

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

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

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

אולי הנקודה האחרונה שאני רוצה להעלות היא שניהול רמות השירות היא פעילות מתמשכת; זה לא משהו שאתה יודע שיש לך פרויקט, אתה עושה את זה וזה נגמר. זה לא, כי הדברים פשוט ממשיכים להשתנות. לאחר שאמרתי את זה, אני אעביר את הכדור לדצ.

דז בלנשפילד: תודה לך רובין. אני אוהב את שקופית הפתיחה שלך. בדיוק עשינו את השידור החוזר של הסרט, אני חושב שזה "למצוא את נמו 2", הסרט. הייתה לך נמו שמחפש זמינות בצורה של תשעה, שלדעתי די חמודה. תמיד מעשה קשה לעקוב אחריו. כשאני חושב על זמן וזמינות וביצועים גבוהים, הדימוי הראשון שעולה לי בראש, מכיוון שגדלתי באיי שלמה ליד הרי געש והקו המשווה, הוא הר געש שמתפרץ במרכז הנתונים שלי; תמיד יש לי את הדימוי הזה שבמחשבה שלי שזה מה שעלול לקרות אם משהו ישתבש. זו תמונה של הר החמוד. אטנה, שהיא הפינה הצפונית-מזרחית של סיציליה, שנמצאת ממש בסמוך לקטניה.

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

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

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

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

למעשה, עד כדי כך, כשחושבים על ההפרעות הגדולות בנתונים של מאוחר, בפרט, הילידים הדיגיטליים או ילידי הענן, חלק מהחברות שהגיעו כמו Uber ו- Airbnb וכדומה, ו- PayPals הישנים מעט ו- eBays של העולם - היקף וגודל אותם ארגונים אפשרי רק בגלל טכנולוגיית מסדי נתונים מודרנית ותשתית ענן מודרנית. בלי זה, ללא היכולת המסופקת, הם בוודאי לא היו קיימים. תאר לעצמך תרחיש שבו היית יכול להגיע רק ל- eBay בין השעות 9:05 ל- 9:25 מכיוון שהוא לא היה זמין להמשך היום בגלל שהוא מנסה לעשות iCloud או גיבוי או משהו כזה, זה פשוט לא היה צריך עבד.

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

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

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

ויש גם משפט נוסף שאני אשאיר אותך איתו, וזה השעה תשע איפה שהוא, כל הזמן. זהו עולם 24/7/365 שאנו חיים בו. כדור הארץ מסתובב ללא הרף סביב השמש ובשלב מסוים, וזמן, בכל שעה משעות היום השעה תשע. וזה אומר שאנשים קמים מהמיטה ומנסים לעשות דברים, לקנות דברים, להתקין דברים וכו '.

אז למה אנו מתכוונים כשמדברים על זמינות גבוהה? ובכן זה נשמע ממש ברור עד שמתחילים לצלול לפרטים הקטנים. אז אתה יודע כשאנחנו חושבים על "בסדר, מה המשמעות של זמינות גבוהה?" ובכן, המציאות היא שאין כדור כסף. זהו מושג מורכב למדי, כפי שרובין התייחס לכמה מהנושאים שהזכיר כמו מדידת זמינות והסכמי רמת שירות. אנחנו ממפים אותו לדברים כמו שיש לי את השאלות האלה, האם זה זמן פעולה? האם אנו מודאגים מדברים כמו מה שאנו מכנים חמש תשע, שאכנס אליהם בעוד רגע. האם אנו מחשיבים את עצמנו עם מה שמופיע בהסכמים ברמת השירות שלנו? לדוגמה, בהסכמים ברמת שירות, אני מתכוון שיש עיכובים, ראשי התיבות של שלוש אותיות להסכמים ברמת שירות הפכו להיות יותר ויותר קריטיים בימינו.

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

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

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

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

כל הדברים הבסיסיים האלה, עכשיו הם נשמעים כמו מושגים פשוטים, אבל כשאתה נכנס לכל אחד מהדברים האלה הם דברים מאוד מאוד מפורטים. כשאנחנו מדברים על זמינות, אנחנו בסופו של דבר מדברים על תשעה. ולמה אנחנו מתכוונים עם תשע? כולנו שמענו על אלה, אבל בואו נחשוב מה המשמעות שלהם לרגע ומדוע הם חשובים.

אז אנחנו מדברים על תשע אחד, שזה רק 90 אחוז מהזמינות שלנו. אני יודע שזה נשמע מאוד גבוה. לכן, כשאנחנו מדברים 24 על 7 על ידי 365, אם רק מסתכלים על שנה אחת למשל, כשאנחנו מדברים על תשע אחד שזה 90 אחוז מהזמן, זה מאפשר שלושים ושש ימים וחצי של השבתה בשנה. בואו ונעגל את זה ליותר מחודש.

עכשיו חשוב על כל עסק שאנחנו מתמודדים איתו מדי יום - בין אם זה בנקאות מקוונת, eBay, PayPal או מדיה חברתית כמו פלטפורמות לינקדאין, טוויטר או סתם קמעונאית כללית - בואו נגיד שרציתי להזמין טיסה כדי להגיע לארה"ב מארץ שמש אוסטרליה, הייתי שמח אם הייתי רוצה לבוא לאמריקה בעוד שבועות, אם חברת התעופה האהובה עליי הייתה מושבתת במשך שלושים ושש וחצי ימים כי ספק השירות שלהם אמר, "תראה, אנחנו עומדים על 90 אחוז מהזמן "? ברור שלא.

כשאתה עולה על הדגם הזה, שני תשעים: 99 אחוזים. ובכן זה הופך ל -3.65 יום, בערך שלושה שעות וחצי השבתה בשנה. זה עניין גדול? ובכן, אם אתה מנהל את יום שישי השחור, ואתה מנהל מבצע מיוחד ואנשים יכולים לקנות רק במהלך הימים ההם.

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

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

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

זמינות גבוהה, במובן אחר באנגלית פשוטה, היא העיצוב בו אתה מיישם או משיג סוג כלשהו של תוצאה וזמינות של נתונים בפרט כאשר כמעט כל הזמן - 24/7/365 ימים בשנה - שהזמינות מגיעה לחלק מאותם תשעה. באופן בלתי הפיך זה לא אומר 100 אחוז. מאה אחוז טכני אינו אפשרי בעולם אמיתי בסביבה אחת. קשה מאוד לשרת אחד במערכת הפעלה עם מסד נתונים עליו, עם פלטפורמה פועלת ועל יישום כזה תוכלו לספק אותו ולצפות שהוא יפעל במאה אחוז. אז אנחנו מתחילים לחשוב על עיצובים. האם יש לנו פיטורים, האם יש לנו שקופיות מרובות לשכפול? ואז כשאתה מנסח את זה באנגלית רגילה, מעניין עד כמה הנושא של זמינות לעומת זמינות גבוהה הופך להיות שונה.

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

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

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

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

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

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

כפי שציינתי קודם, שם יכולתי לומר, "הזמינות שלי היא לא הזמינות שלך." אז כשמדובר בסביבות בסיסי נתונים ותמיכה בתשתיות, הפעלת בסיס הנתונים שלך והגנה על זה והבטחת זמינות גבוהה, אין באמת חנות אחת להפסיק . לכל אחד יש את הצרכים והרצונות שלו. אז עליכם לשאול את עצמכם את השאלות היסודיות האלה שאשאיר אתכם איתן, וזה: מה יכול הארגון שלכם להרשות לעצמו? אני לא מדבר רק על דולרים וסנטים. אני מדבר, כארגון, על מה אתה יכול משאבים, זמן ומאמץ וכדומה להרשות לעצמך ככל שרמת הזמינות יכולה לספק? כמו כן, במה העסק שלך יכול לתמוך? אז, היכולות הנוכחיות, המיומנויות הנוכחיות, התשתית הנוכחית, המימון הנוכחי שתוכלו לגייס. כך שהג'אגלינג בין מה שאתה יכול להרשות לעצמך לעומת מה שאתה יכול לתמוך בו הוא איזון מעניין.

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

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

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

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

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

ד"ר רובין בלור: בסדר. ברט, פשוט נתתי לך את המפתחות, קח אותו משם.

ברט סקלזו: תודה! תודה, דז ורובין. אני אמשיך להמשיך בנושא הזמינות הגבוהה לנתונים שלך. ואני בעצם הולך למנף הרבה ממה שדז דיבר רק על זה. אז, הבחירות, התשעים, הסחרים, הרווחיות. אני מתכוון לנסות ולנסות זאת יותר למנהל מסד הנתונים או למישהו קרוב יותר לתעלות, איך הם היו מסתכלים על זה? איך הם היו מארגנים את זה? ומה משמעות הבחירות האלה.

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

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

אז שוב, אני אנסה להישאר די אגנוסטיים בבסיסי נתונים. עכשיו, רוב הדברים עליהם אני מדבר, אני יודע שהם קיימים ב- Oracle, SQL Server, MySQL, PostgreSQL. ישנם גם כמה ספקי צד ג ', שמייצרים כלים שגם יעניקו לך אדריכלות נוספת שתוכל לשקול. וכפי שדז אמר בדיוק, אף אחד מהפתרונות אינו הטוב ביותר; הכל תלוי. אבל ישנה עובדה אוניברסלית אחת בה אנו הולכים להסתכל, האם יהיו חלקים נעים יותר, כך שהיא תהיה מורכבת יותר ולכן יקרה יותר.

אז, כולנו יודעים כי נתונים הם נכס חשוב. וכולם יודעים שגישה מהירה לנתונים היא תמיד נחמדה. עם זאת, גישה אמינה לנתונים היא קריטית. וכפי שהוא מדבר על התשע דוגמאות שלו, האם אתה באמת יכול להרשות לעצמך 36½ ימי השבתה? זה קריטי כי נתונים זמינים כל הזמן. וכך, זמן השבתה יכול לעלות הון, הן מבחינת הכנסות שאבדו, אך חשוב עוד יותר, בלקוחות שאבדו, או באובדן המוניטין של הלקוחות. אני אתן לך דוגמא טובה; אם אתר מסוים בו אני מבצע רכישות איטי, אני יכול לנסות למצוא אתר חדש שמוכר פריטים דומים במחיר דומה שאין להם אתרים איטיים. וכך, זה לא רק אובדן הלקוח, אלא הרצון הטוב שיש ללקוח כלפיך.

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

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

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

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

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

אז בואו נתחיל עם הפיתרון הבסיסי ביותר בזמינות גבוהה. זו ממש לא זמינות גבוהה, אבל אני רוצה להתחיל עם זה, מכיוון שזה גורם לאנשים לחשוב בדרך הנכונה. אם יש לי שרת ומערך אחסון, בדרך כלל אני שם מספר NICs, כרטיסי ממשק רשת, בשרת הזה, ואגד אותם כך שאם NIC אחד נכשל, אני עדיין במצב. ואני אעשה את אותו הדבר עם מתאמי האוטובוס המארח שלי, אני אעבור בדרך כזו דרך מתגים שונים, כך שיש לי דרכים רבות להגיע לאחסון שלי. ויש לי ספק כוח אוניברסלי, ויש לי בקרים חוזרים ונשנים בתוך מערך האחסון שלי, ואולי עשיתי משהו כמו RAID 10 עם הדיסקים שלי. במילים אחרות, בתמונה זו מנעתי כישלון של רכיב יחיד ברמות מרובות. אז אני לא מחויב ל- NIC, או ל- HBA, או לבקר או למתג.

אך אם שמתם לב, השרת בצבע אדום ומערך האחסון בצבע אדום. יש לי עדיין שני אזורים שבהם אם הם נכשלים, אם השרת שלי הולך, אני מת, אם ארון מערך האחסון שלי הולך, אני מת. לכן, בעוד שזו לא זמינות גבוהה באמת, זה מתחיל לראות ולהתבונן בתמונה ולומר "אני רוצה תמונה שאין בה אדום." וזו באמת המטרה של התמונות האלה, לגרום לנו להיות מכוונים לכיוון הנכון.

לכן, הדבר הראשון שקורה הוא, כ- DBA, אני תמיד רוצה לשים את הפיתרון לזמינות גבוהה כיישום בסיס נתונים, אבל יכול להיות שזה זמין שאפשר לעשות זאת כפתרון אחסון, או שזה יכול להיות שזה יכול להיות שכפול ברמת האחסון. במקרה של השמאל, יש לי וירטואליזציה לאחסון. מה שקורה הוא שיש לי RAID 0 בשני ארונות אחסון שונים לדיסקים שלי, אבל יש לי RAID 1 על פני שני ארונות האחסון השונים. במילים אחרות, למעשה אני יכול להיכשל בארון האחסון ואני לא מת. אז זה עדיף מהתמונה הקודמת, מכיוון שבתמונה הקודמת - זכרו שהיה לנו שני אדום בשרת ואדום במערך האחסון - ועכשיו ביצענו שיפור קטן, עכשיו אין לנו עוד אדום ברמת האחסון, אנחנו השתמשנו - וירטואליזציה לאחסון פתרה את הבעיה.

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

וכך, זוהי תמונה אחרת שעשויה להיות זמינה או לא. ומי שמנהל את זה יכול להיות מנהל האחסון שלך, ולא מנהל המערכת שלך. אני אוהב להעלות את זה, כי לפעמים אנשים חושבים על "אה! זמינות גבוהה, זו בטח ה- DBA שמטפל בבעיה זו." זה לא תמיד נכון; במקרה זה יכול להיות מנהל האחסון.

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

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

עכשיו, במקרה זה, שוב, זה יכול להיות מנהל האחסון ומנהל הווירטואליזציה שבונים את הפיתרון הזה ועכשיו נראה: יש לי תמונה שאין בה אדום. יש לי זמינות גבוהה מכיוון שאני יכול להעביר את המכונה הווירטואלית או את היישום הפועל או מסד נתונים משרת אחד למשנהו ויש לי וירטואליזציה במערך האחסון שלי על ידי כך שהוא מבצע RAID 1 בשני מערכי אחסון נפרדים. ביצעתי מספר רב של מתגים עם מתגי ה- HBA שלי.

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

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

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

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

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

עכשיו, הרשה לשקופית הבאה מכיוון שהיא כמעט זהה והיא שכפול הגיוני והדבר היחיד שמשתנה בתמונה הוא שבאמצע, במקום לשלוח את ה- I / O לחסימה, אנו שולחים למעשה את היומן קבצים עם פקודות SQL בתוכה. כלומר, במילים אחרות, מה שאנחנו משכפלים הוא לא ה- I / O הפיזי, אלא הפקודות הגורמות ל- I / O הפיזי.

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

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

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

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

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

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

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

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

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

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

ועם זה, זה מביא אותי לסוף החומר שלי ולזמן לפתוח את זה לשאלות.

אריק קוואנה: בסדר, דז, אולי אתה קודם ואז רובין?

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

ואני מעוניין להעלות את מחשבותיך על הג'אג'ל, במיוחד עכשיו כשאנחנו עוברים לדגמי ענן, שבהם אתה יכול להשיג או / או. אתה יכול ללכת ל- AWS או Azure ול- Rackspace שלך, לא משנה מה, ולקנות כשירות שמספק פלטפורמת מסד הנתונים שלך, או שתוכל לעשות זאת באמצעות קוד קוד פתוח. ועל מה דיברנו זה עתה, מה הג'אגלינג בין קנייני לקוד פתוח ואיך דפוסי העיצוב שאתה מדבר עליהם נכנסים לתוקף ומה המחשבות הכלליות שלך בנושא זה כשאנחנו מתקדמים, במיוחד סביב אספקת זמינות?

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

ואני אתן לך דוגמה טובה למקרה אחד שהיה לי. הייתה לי חברה מבוססת אינטרנט שמשתמשת ב- MySQL כמסד הנתונים שלהם והם היו בגירסה ישנה של MySQL, כמו גרסה 4.0, והשכפול בין הצמתים שלהם היה הגורם המגביל עד כמה גדולים הם יכולים להגדיל את מסדי הנתונים שלהם. והם בדקו לקנות פיתרון של צד שלישי, ואז הסתכלו, "טוב, אולי נוכל להשתמש באחד הפתרונות של קוד פתוח." ומה שבאמת התחשק זה היה כל מה שהם צריכים לעשות היה לשדרג את ה- MySQL לגירסה שלהם, אני חושב שזה היה 5.5 שאליו הלכנו, מכיוון שההבדל בין שתי גרסאות בסיס הנתונים היה בגירסת 4.0 של שכפול MySQL לא היה הברגה בגרסה 5.0 זה היה, וזה היה למעשה הדרך הטובה ביותר עבורם.

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

דז בלנשפילד: כן, זה משקף את החשיבה שלי, למען האמת. רק לצורך גילוי מלא, ולא אכנס למותגים, אבל הגעתי מרקע קנייני העובד עבור יצרני יצרני ציוד מקומי וספקי תוכנה ו- IOC באופן כללי, וזה בהחלט היה הניסיון שלי ובו בזמן אני מאוד מקצוען -open-source ואני תורם קוד לחבורה של פרויקטים שלא נקרא בשמותיהם, אבל אני מסכים איתך בכך שאם אתה ארגון גדול - נניח שאתה בנק, או כל מה שאתה יכול להיות - תמיד לא תרצו להיות חנות IT. אתה יודע, למשל, אם אתה מפרסם עיתונים או שאתה קמעונאי, אתה לא רוצה להיות חנות IT שמפרסם עיתונים, אתה רוצה להיות חנות עיתונים שממש ממנפת את ה- IT.

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

כנראה השאלה האחרונה שלי לפני שאני מוסר לד"ר רובין בלור, מכיוון שאני יודע שיש לנו זמן קצר. לאן אתה רואה את זה הולך מבחינת מגמה? אז אתה שם בחוץ כל הזמן, אתה על הקצה המדמם של החומר, אתה רואה שאנשים התיישבו והתייחסו והתעוררו מהצורך להפוך את זה לחלק מסחרי מהיום יום שלהם- שיחת יום בחזרה לחדר הלוח? או שאתה עדיין רואה את זה שמדובר בחוות החנונים, הטכנאים והקפוצ'ונים חושבים על זמינות כי זה גורם להם להתעורר בארבע בבוקר כשמשהו לא מקוון?

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

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

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

ואפילו ראיתי בסביבות בהן, אתה יודע, אנשי IT משלהם יבואו ויגידו, "אה, אתה לא יכול לקבל את מה שאתה רוצה. זה יקר מדי. "והם יביאו חברת ייעוץ צד ג 'שתגיד אז" לא, זה לא נכון. כך תוכל לעשות זאת. הנה מה שזה יעלה לך. "אז, אני חושב שיש לנו עדיין קצת זמן בין רמות התקשורת בין שני הצדדים לפני שזה הופך להיות אוטומטי עדיין.

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

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

הייתה לי הודעה פרטית בה אני פשוט אגע במהירות עכשיו. מישהו שאל שאלה "האם זה מציאותי שתוכל להשיג 100 אחוז זמינות?" ואולי תוכל לתקן אותי כאן, אבל אני הולך לומר כן. בניתי פלטפורמה להעברת כספים אלקטרונית, שער EFTPOS בין פלטפורמות בנקאיות מהירות למסופי ה- EFTPOS. בניתי זאת בראשית שנות האלפיים. זה למעשה היה מקוון 100 אחוז מהזמן במשך 17 שנים. למעשה, הוא נבנה לפני שנות האלפיים, אך הוא יצר רק 2000/2001 בערך.

אז 17 השנים היו קיימות מהפיתוח לבדיקה ואז הייצור. ב- 17 שנים, מחשבים נמוכים מאוד מהמדף במחשבים נמוכים, המפעילים מערכת הפעלה בקוד פתוח, אך בסיס נתונים קנייני, מבצעים החלפה פעילה / פסיבית כל 90 יום, עם הפעלת פטנטים עיצוביים שונים, עם שכפול של דיסקים בכל שרת, שכפול נתונים בין שרתי מודלים, שכפול של מרכזי נתונים מרובים, והדפדף ממרכז הנתונים A עושה ייצור למשך 90 יום ואז מעביר למרכז נתונים B ועושה ייצור.

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

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

ד"ר רובין בלור: טוב, בסדר, אני אאסוף את זה. אחד הדברים שרתקו אותי במצגת שלך היה מספר האפשרויות הזמינות כעת שלא היו זמינות כשהייתי צריך להיאבק עם הדברים האלה. אני די מעוניין במי עומד לעצב את התצורות האלה, או מי מעצב בימינו את התצורות האלה? מה שקרה בעבר, או, העולם שאני רגיל אליו, זה שתהיה מערכת טרנסאקציות כבדה למדי ותהיה מעוניין בזמני זמן רב וזמינות גבוהה. מכיוון, אתם יודעים, מערכת העסקאות, זה יהיה יקר אם היא תיפול בכל דרך שהיא. ולא יהיו לך את כל האפשרויות שהצגת לי זה עתה, אך בדרך זו או אחרת, תוכל למצוא דרך, באמצעות שכפול בעיקר, ליצור המתנה חמה שלא תלחץ עליה באופן בלתי מורגש, אבל זה ייתן לך שירות מושפל עד שתחזור.

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

ברט סקלזו: בחברות הגדולות, היעילות והיעילות מאוד בכל פעולותיהן, כולל ה- IT שלהם, לרוב תהיה להם קבוצת אדריכלות ריכוזית, או שיהיה להם שם כלשהו, ​​שמעתי את זה שנקרא " קבוצת אדריכלות "הרבה פעמים. ויהיה באחריותם לדעת את כל התמונות השונות הללו ומה היתרונות והחסרונות ומה העלויות. ומה שיקרה הוא, כאשר אפליקציה מסוימת מסתכלת ואומרת, "היי, אני חייבת לעמוד בדרישות העסקיות X, Y ו- Z. היי, צוות אדריכלות, מהן הבחירות שלי?"

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

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

ד"ר רובין בלור: זה באמת די מעניין. בימי, לעולם לא היינו חושבים על זמינות גבוהה פרט למערכות העסקאות. ובכן, בימינו, כמובן שיש לכם מערכות סטרימינג שכפופות ככל הנראה לדרישות גדולות עוד יותר מבחינת הזמינות. אבל, במאגר מבוסס-השאילתה, האחורית, אנליטיקה, מחסן נתונים, סוג של סביבה, האם אתה רואה אי פעם דרישות לזמינות גבוהה?

ברט סקלזו: כן, ואני שמח ששאלת את השאלה הזו. ביצעתי עבודות עבור חברת קמעונאית וההחלטות האסטרטגיות שלהן עבור העסק התבססו בחלק ניכר מהניתוח שהן יעשו ממחסן הנתונים. ולמעשה, הם התראיינו למגזין פורבס והמנכ"ל של החברה אמר, "היי, מחיר המניות שלנו צמח 250 אחוז בחמש השנים האחרונות וסיבה גדולה מאוד שזה נכון היא מכיוון שאנחנו יודעים למנף את הנתונים שלנו ביעילות. במחסן הנתונים שלנו. "הם היו כל כך טובים בקבלת החלטות עסקיות, שמבחינתם, מחסן הנתונים והיכולת לבצע את הניתוחים האלה, היכולת לקבל החלטות על בסיס יומיומי מול הנתונים התפעוליים שלהם, הייתה למעשה עבורם, מערכת ייצור.

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

ד"ר רובין בלור: אני מניח שבוודאי יש דברים כאלה. יש לנו די זמן, אני חושב שעלי למסור לאריק למקרה שיש לו כמה שאלות מהקהל. אריק?

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

ובכן, חברים, אנו מבצעים ארכיון של כל שידורי האינטרנט הללו לצפייה מאוחרת יותר. אז קפוץ מקוון ל- Techopedia.com כדי לחפש את קטע השידורים ברשת. כל אותם Hot Techs יופיעו שם. תודה גדולה לחברנו ברט על המומחיות שלו. וכמובן, לדז ורובין. ועם זה אנו ניפרד מכם, חברים. שמור על עצמך. נדבר איתך בפעם הבאה. ביי ביי.