6 צווארי בקבוק נסתרים בהעברת נתוני ענן

סת 'נובל הוא מייסד ונשיא Data Expedition.

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

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

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

צוואר בקבוק של העברת ענן מספר 1: אחסון נתונים

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

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

כל היתרונות הללו הופכים אחסון מבוסס קבצים לאפשרות היקרה ביותר, אך לאחסון קבצים בענן יש כמה חסרונות אחרים. כדי להשיג ביצועים גבוהים, ניתן לגשת לרוב מערכות הקבצים מבוססות הענן (כמו אמזון EBS) רק על ידי מכונה וירטואלית מבוססת ענן אחת בכל פעם, מה שאומר שכל היישומים הזקוקים לנתונים חייבים לפעול ב- VM ענן אחד. כדי לשרת מספר מחשבים וירטואליים (כמו Azure Files) נדרשת חזית אחסון עם פרוטוקול NAS (אחסון צמוד לרשת) כמו SMB, שיכול להגביל מאוד את הביצועים. מערכות קבצים מהירות, גמישות ותואמות מדור קודם, אך הן יקרות, שימושיות רק ליישומים הפועלים בענן ואינן משתנות היטב.

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

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

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

צוואר בקבוק של הגירת ענן מספר 2: הכנת נתונים

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

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

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

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

צוואר בקבוק של הגירת ענן מס '3: אימות מידע

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

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

צוואר בקבוק של נדידת ענן מס '4: העברת מרשל

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

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

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

צוואר בקבוק של העברת ענן מספר 5: העברת נתונים

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

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

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

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

צוואר בקבוק של הגירת ענן מס '6: קנה מידה בענן

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

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