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

מהו Azure Site Recovery?

זהו שירות ענן מנוהל של Microsoft Azure המאפשר התאוששות מאסון (Disaster Recover) עבור ארכיטקטורות ענן או ארכיטקטורות היברידיות. השירות מאפשר לשכפל בקלות כל מכונה ווירטואלית, כולל מערכות פיזיות On-prem בענן (בדרך כלל ב-Region אחר). בעת אסון או השבתה מתוכננת או לא מתוכננת, המערכת מבצעת Failover תוך שחזור מהיר של כל הנתונים בתהליך מובנה, מוכח ומסודר שמבטיח המשכיות עסקית רציפה.

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

  • Hyper-V to Azure – המשכיות עסקית לסביבת Hyper-V המקומית בAzure.
  • Hyper-V to Hyper-V – המשכיות עסקית מסביבת Hyper-V מקומית וסביבת Hyper-V משנית.
  • VMware/Physical to Azure – המשכיות עסקית לסביבת VMware או שרתים פיזיים.
  • VMware/Physical to VMware – המשכיות עסקית מסביבת VMware לסביבת VMware משנית.
  • Azure to Azure – המשכיות עסקית לשרתי IaaS ב-Azure מ-Region אחד ל-Region אחר.

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

ההגדרה והניהול של ההמשכיות העסקית מבוצעים במסגרת ה- Azure Management Portal. אין צורך בניהול של patchים או של תחזוקת שרתים, הכל מנוהל במסגרת השירות. באמצעות השימוש בשירות ASR ניתן להנות מRTO (Recovery Time Objective) וRPO (Recovery Point Objective) נמוכים במיוחד.

כיצד מקימים פרוייקט המשכיות עסקית?

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

  • שלב התכנון – זהו שלב קריטי המשלב הביטים טכניים ועסקיים גם יחד. כך למשל, בשלב זה בוחנים את הצרכים מבחינת RPO ו- RTO, נפחי האחסון הנדרשים, רוחבי הפס של הרשת וכו'.
  • הקמת הסביבות והגדרתן – לאחר שלב התכנון מגיע שלב ההטמעה. במסגרת זו מגדירים את הסביבות ואת תהליך הרפליקציה. תהליך זה כולל הגדרת סביבת הDR בענן, הגדרת הרשת, האחסון ומדיניות הרפליקציה.
  • רפליקציה ראשונית – תהליך הרפליקציה הראשוני לוקח זמן ממשוך מכיוון שהוא כולל את כל (או רוב) המידע ולא רק את הדלתא\השינויים. זהו תהליך רגיש, לכן יש לתכננו באופן מוקפד ומבעוד מועד כך שלא יפריע למהלך התקין של הארגון.
  • בדיקת ההתאוששות (Failover) – בשלב זה ניתן לבדוק את תהליך ההתאוששות מאסון. ASR מאפשר לבצע בדיקה שכזאת על ידי כך שמדמים מצב שבו צריך לבצע Failover וכך לבחון את מוכנות הסביבות והמערכות.
  • ניטור הרפליקציה ופתרון בעיות – כחלק מתהליך ה-DR מאוד חשוב לנטר את הרפליקציות ולבדוק שיעדי ה- RPO נשמרים. מעבר לאספקת התראות על Jobים שונים, ASR גם כולל Event Log Source משלו המשמש לבצע תהליך פתרון בעיות עבור בעיות שונות ברפליקציה.
  • ביצוע מיגרציה – באמצעות יכולת המיגרציה של ASR ניתן לבצע מיגרציה והמערכת באופן אוטומטי דואגת לכך שה- workload יעבור מיגרציה במלואו, תהליך הרפליקציה יפסק, והחיוב עבור המכונה שממנה בוצעה המיגרציה יפסק.

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

 

 

 

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

מה מתוחזק באופן אוטומטי?

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

אז למה צריך DBA?

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

שלב ההקמה

כשמקימים את בסיס הנתונים קיים הבדל משמעותי בין on-prem לבין PaaS בכך שבהתקנה המקומית ה- DBA חייב לדאוג לאחסון (למשל באיזה דיסקים ישב כל DB) ואילו ב- Azure PaaS לא צריך לדאוג לאחסון באופן שכזה. כל שאר הפעולות נשארות כפי שהיו טיוב שאילתות, אינדקסים, פיתוח דוחות, הגדרת הרשאות פנימיות לבסיס הנתונים, וכו'.

שלב התחזוקה

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

ניטור ופתרון בעיות ביצועים

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

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

שדרוגי גרסה

שדרוגי גרסה של המערכת\אפליקציה שעושה שימוש בבסיס הנתונים לרוב מצריכה שינויים בסכמה של ה-DB, טבלאות נוספות, פרוצדורות, שאילתות וכו'. לפני שהשדרוג מבוצע, מומלץ ש-DBA יבצע Code Review על מנת לוודא שהקוד נכתב בצורה יעילה שתואמת את ה- best practices. כשהכל מוכן, יש לקחת baseline חדש כדי למדוד שינויים בביצועים ומומלץ מאוד לבצע בדיקות ביצועים (stress tests) המדמות עומסים צפויים.

לסיכום

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

כותב: תומר לב,  ארכיטקט DATA, מנכ"ל ובעלים DATASITE 

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

מה זה NoSQL וכיצד הוא שונה מבסיסי נתונים רלציוניים?

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

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

הבדל חשוב נוסף הינו העובדה שבסיסי הנתנים הרלציוניים תומכים ב- vertical scaling בלבד. כלומר כדי לגדול יש להוסיף יכולות לאותה מכונה. ואילו NoSQL תומך ב- horizontal scaling, המאפשר גדילה רוחבית על פני מספר בלתי מוגבל של מכונות.

בסיסי נתונים NoSQL מתחלקים לכמה משפחות עיקריות, כאשר כל אחת מאופיינת במטרות וביצועים שונים:

  • Document Databases – בסיס נתונים בו המסמך הוא המפתח והתוכן של המסמך, באשר הוא, הוא הערך. דוגמה לבסיס נתונים זה הינו MongoDB.
  • Graph Stores – בנויים על סכימה שמכילה קשרים בין נתוים ובין אובייקטים במטרה להציג את הנתונים ואת הניתוח באמצעות גרפים חזותיים. סוג זה של בסיס נתונים משמש לרשתות חברתיות ולמערכות למניעת הונאה. דוגמה לבסיסי נתונים זה הינו Neo4J.
  • Key Value Store – מאחסנות זוגות של ערכי מפתח ומספקות פונקציונליות בסיסית לאחזור הערך המשויך למפתח ידוע. הפשטות בשמירת נתונים באופן הזה הופכת את מערכות אלה למותאמות היטב ל embedded databases, כאשר הנתונים המאוחסנים אינם מורכבים במיוחד ומהירותם היא בעלת חשיבות עליונה. דוגמה לבסיס נתונים זה הינו Redis.
  • Wide-Column Stores – בסיס נתונים מבוססי עמודות (במקום שורות), בו משמשים בעיקר לשאילתות על מערכי מידע גדולים במיוחד. דוגמה לבסיס נתונים זה הינו Cassandra.

איזה סוג DB מתאים לפרוייקט שלך?

אלה המאפיינים שעבורם בסיס נתונים רלציוני (SQL) הינו אידאלי:

  • מידע מובנה (structured) – אם המידע שבפרוייקט הינו מובנה, כלומר מבנה הנתונים צפוי מראש (שדות, טבלאות, וכו') עם הרבה מאוד קשרים בין מערכים של דאטה, אז ככל הנראה אתם זקוקים לבסיס נתונים רלציוני.
  • שלמות המידע (ACID) – ACID הינו ראשי תיבות של Atomicity, Consistency, Isolation, Durability. המשמעות הינה מנגנונים השומרים על שלמות ונכונות הנתונים תוך הגדרה מדויקת של תהליכים טרנזקציניים. לכן אם שלמות ונכונות המידע חיוניים עבור הפרוייקט שלכם סוג זה של יכולות יכול להתאים יותר.
  • שימוש ב- Joinים – אם אתם זקוקים לאחזר סטים שונים של מידע השמורים בטבלאות שונות, תוכלו לעשות זאת בקלות בבסיס הנתונים הרלציוני. לעומת זאת ב- document databases אין אפשרות לבצע זאת כך ותאלצו לבצע מספר שאילתות כדי לאחזר סטים שונים של מידע.

אלה המאפיינים שעבורם בסיס נתונים לא-רלציונלי (NoSQL) הינו אידאלי:

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

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

 

איך אומרים? "לכל דבר טוב יש סוף…" וכפי שהתבשרנו זה מכבר גם התמיכה המורחבת ב- SQL Server 2008 ו- 2008R2. מסתיימת בימים אלו. או ליתר דיוק, הסתיימה כבר ב-9 ליולי 2019. "אז מה עושים?" זו השאלה שחוזרת על עצמה בקרב לקוחותינו המחזיקים עדיין במערכות העושות שימוש בגירסה זו של SQL Server. באופן כללי התשובה לשאלה זו קשורה לא מעט במערכות שעושות שימוש בבסיס הנתונים הזה. במקרים מסוימים מערכות אלו לא יתמכו במעבר לבסיס נתונים מסוג אחר או במעבר פשוט מ-on-prem לענן אלא ידרשו בחינה מעמיקה יותר  ובמאמר זה לא נתייחס לאפשרויות האלה אלא לתהליך העבודה של שדרוג. 

לאיזו גירסה של SQL Server כדאי לשדרג? 

שוב הכל מאוד תלוי במערכת העושה שימוש בבסיס הנתונים. אך אפשר להניח שבשלב הזה מרבית המערכות יתמכו במעבר לגירסת SQL Server 2017, שנחשבת כבר כיציבה ופופולרית. המאמר הזה מסכם את כל מה שהתחדש ב- SQL 2017 מאז גירסת 2008. 

תאימות בין סביבת המקור לסביבת היעד

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

  • גודל אחסון – יש לוודא שגודל האחסון בדיסק של סביבת היעד מספיקה. אם זה לא מספיק יש להרחיב את גודל האחסון.   
  • מיקום הלוגים והדאטה – יש לוודא שמיקום הלוגים והדאטה בסביבת היעד תואמת את מיקום הסביבה במקור. אני בדרך כלל ממליץ לשמר את אותם מאפיינים של האחסון כלומר אם יש דיסק "D" לקובץ הדאטה ודיסק L לקבצי הלוגים, אז לשמר את אותו סדר גם בשרת היעד.
  • מאפייני בסיס הנתונים – יש לאסוף את המאפיינים של בסיס הנתונים ולוודא תאימות. מאפיינים אלו כוללים Auto Stats, DB Owner, Recovery Model, Compatibility level, Trustworthy option, ועוד. בזמן ההתקנה של בסיס הנתונים החדש יש לבחור את אותו path עבור ה- MDF, LDF, וה- backup. 
  • בדיקת ה- Collation – יש לבדוק מה ה- Collation שהוגדר בבסיס הנתונים המקורי ולוודא שהוא מוגדר גם ביעד. מאמר זה מסביר על ההגדרות ומשמעות השימוש ב- Collation. 
  • יישומים ושירותים תלוים – יש לאסוף נתונים על כל היישומים התלויים בבסיס הנתונים לרבות כל השירותים שהם מריצים.
  • שירותים של בסיס הנתונים – יש לוודא שהשירותים של בסיס הנתונים הישן כמו SSIS, SSRS, ו- SSAS מוגדרים גם בבסיס הנתונים החדש. לא כל השירותים האלה מוגדרים בכל בסיס נתונים לכן יש לבחון אם הם היו קיימים בבסיס הנתונים במקור.  
  • הרשאות – יש לאסוף נתונים על כל ההרשאות של בסיס הנתונים, לרבות משתמשים, לוגאינים, הרשאות וכו'. יש לבדוק אם ישנם משתמשים "יתומים" – מאמר זה מסביר כיצד למצוא משתמשים כאלה וכיצד לפעול בנושא. במקרים רבים ההרשאות מנוהלות באמצעות Active Directory ולכן אני ממליץ לשמור על אותו שם שרת ברשת עבור השרת היעד. זה ימנע את הצורך בהגדרות חדשות לכל המשתמשים. זה ימנע גם הגדרה מחודשת של ה- connection strings.  
  • אובייקטים מקושרים – יש לבדוק אם ישנם אובייקטים מקושרים כמו SQL Agent Jobs או שרתים מקושרים כמו Link Server.  
  • תוכנית תחזוקה וDR – יש לבדוק אם השרת נכלל בתוכנית תחזוקה כלשהי והאם הוא נכלל בתוך תוכנית Disaster Recovery, למשל אם יש לו Log shipping, mirroring או availability groups וכו'. יש לרשום את כל אלה ולבצע את אותן הגדרות גם בסביבת היעד.  

המעבר עצמו

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

  • ניתוק השרת הישן – לפי אופציה זו מנתקים את השרת הישן, מעבירים את הקבצים לשרת החדש על ידי dettach. כמובן שכל זאת תוך שמירת על אותו path בשני השרתים. לאחר מכן ניתן להרים את השרת החדש. שיטה זו אינה כה נפוצצה כי זה אומר שיהיה downtime, אשר בדרך כלל אינו רצוי.
  • שיטה של Backup ו- Restore – אומרים לכל העובדים להפסיק את עבודתם. לוקחים backup ואז עושים restore בשרת החדש. שיטה זו גם מצריכה הפסקת עבודה לזמן ממושך ואינה מומלצת בדרך כלל. אם בסיס הנתונים מאוד קטן אין בעיה לעשות זאת כי זה לא יקח זמן ממושך. 
  • שיטת ה- Log Shipping – עושים גיבוי מלא של המקור ו- restore ביעד ואז מתחילים "לגלגל" לוגים אל עבר היעד. כך למעשה משחזרים את כל הפעולות שנעשו בבסיס הנתונים מאז הגיבוי. בזמן הזה ניתן לעבוד כרגיל בבסיס הנתונים המקורי. כשרואים השכל עובד כראוי עושים את ה- restore  של הלוג האחרון. כלומר עושים restore רק עבור הדלתא של השינויים האחרונים. בזמן הקצר הזה מפסיקים לעבוד, עושים את ה-restore לשרת החדש, מכבים את השרת הישן, משנים למכונה ביעד את שם המכונה ומעלים אותה. ואז כל ה- connection strings יכנסו כבר למכונה החדשה. כלומר ה-downtime במקרה הזה הינו ממש מינימלי למשל רבע שעה. 

 

מקווים שעזרנו במעט להתמודד עם ה- end of life של SQL Server 2008. לכל שאלה או בקשה צוות המומחים שלנו ישמח לעמוד לרשותכם: info@datasite.co.il 

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

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

לביצוע אנליזה ותחקור של ניקיון ה – DATA אפשר לגשת באמצעות טכניקות שונות כגון: סוגי המידע  (DATA TYPES), תכונות קבועות (Constant features), שורות כפולות (Duplicated rows),

תכונות כפולות (Duplicated features), ערכים מחוץ לטווח (Values out of range) וע"י כך להגיע לרוב הפערים במידע הארגוני בצורה יסודית ושיטתית. חלק מהעבודה עם רשומות המידע ניתן לתחקר באמצעות כלים מסורתיים לניתוח, לדוגמה, R או Python. הפערים שזוהו בתהליך עשויים להיגרם בעיקרם על ידי טעויות כניסה של משתמשים, על ידי שחיתות באחסון או בהעברת המידע.

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

מיגרציה של מסדי נתונים ל Azure

תהליך מיגרציה לענן מובנה בשני תהליכים עיקריים – הראשון הוא אומדן התאמת הסביבה הקיימת
(Migration Assessment) לענן והשני הוא ביצוע המיגרציה עצמה.

השלב הראשון בא לענות לנו בצורה חד משמעית – עד כמה הסביבה שלי מותאמת למעבר לענן והאם אני צריך לבצע שינויים כלשהם?

Database Migration Assistant

כאשר מסתכלים על התפתחות השירותים למעבר לענן, ניתן לראות כי Azure שמה דגש רב על כלים לאומדן ההתאמה לענן מלבד הכלים המשמשים למיגרציה עצמה. מלבד הכלי הכללי לאומדן התאמה לענן, Azure פיתח כלי ייעודי עבור אומדן התאמה של מסדי נתונים הנקרא (Database Migration Assistant (DMA.

כלי ה DMA מסייע לנו לבצע אומדן התאמה של שרתי ה on-prem SQL ל Azure SQL Instances, בין אם Microsoft SQL Server in an Azure virtual machine או Azure SQL database.

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

השלב השני בתהליך המיגרציה הוא ביצוע המיגרציה עצמה, כאשר קיימת חשיבות עליונה בהשמת דגש על מיגרציה תקינה של מסדי נתונים. עבור כך Azure פיתח את Azure Database Migration Services. ה – DMS הינו שירות PaaS המשלב את היתרונות הקיימים בכלי ה (SQL Server Migration Assistant (SSMA בשילוב כלי ה – DMA.

Azure Database Migration

ה – DMS הוא שירות מיגרציה ייעודי למסדי נתונים המאפשר מיגרציה חלקה ופשוטה של מסדי נתונים ממספר מקורות כגון SQL, Oracle ו MySQL אל אחד מ Azure SQL Instances, זאת עם זמן השבתה (downtime) מינימלי. בנוסף למיגרציה של מסדי הנתונים, ה – DMS מאפשר לבצע מיגרציה של uncontained SQL objects.

חשוב לציין כי ביצירת פרויקט מיגרציה ניתן לבחור בין מצב מיגרצית online למצב מיגרצית offline, כאשר ההבדל ביניהם הוא באופי ההעתקה – מיגרציות offline מבצעות תהליך של גיבוי ושחזור של ה data עצמו (ללא ה schema), לעומת מיגרציות online המעתיקות גם את ה schema.

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

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

Azure מספק סל פתרונות מקיף לקבלת תובנות משמעותיות מהמידע. השירותים העיקריים הינם  –

  • Azure Analysis services – שירות המאפשר שימוש במודלים תמציתיים עליהם מכילים את המידע, בצורה כזו שהם מאפשרים ביצוע של שאילתות פשוטות. כל המשתמשים שנחשפים למידע דרך המודלים  נחשפים לגרסה בודדת ומאומתת (single version of truth).
  • Data Lake Analytics – שירות ליצירת עבודות אנליזה לפי דרישה, המאפשרות ביצוע טרנפורמציה של הנתונים. שירות זה יעיל כלכלית מכיוון שעבודות האנליזה מחויבות רק כאשר הן רצות.
  • Azure Data explorer – שירות חקירה של מידע המגיע בצורת logs וטלמטריה המתקבל ממגוון מקורות, כגון אתרים, אפליקציות, מכשירי IoT ועוד.

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

ביג-דאטה הפך לנושא פופולרי הולך וגדל במהלך השנים האחרונות, ועוסק בעיבוד כמויות גדולות של נתונים במגוון פורמטים אשר לוקח בחשבון זרימת נתונים "חיה" ושימוש בנתונים היסטוריים. טכנולוגיות בסיסי נתונים מסורתיות (SQL) לא מתאימות להתמודד עם נתוני ביג-דאטה הכוללים זרימת נתונים מאסיבית ולכן היה צורך בארכיטקטורה גמישה שתוכל להתמודד עם כמות הנתונים הגדולה. ארכיטקטורת למבדה היא ארכיטקטורה כזו, המסוגלת להתמודד עם קליטה, עיבוד ואנליזה של נתוני ביג-דאטה.
כל הנתונים החדשים שמתקבלים מועברים במקביל לשתי שכבות:
o שכבת עיבוד אשכול (batch) – השכבה האחראית לאחסון כל הנתונים בצורתם "הגסה" (raw data) ואחראית גם על עיבוד הנתונים החדשים וההיסטוריים. שכבה זו מספקת הסתכלות מקיפה ומדויקת על הנתונים, על חשבון הזמן בו לוקח לקבלם. תוצאות העיבוד נשמרות בשכבת ההגשה (serving) בתור תצוגות אשכול (batch views).
o שכבת עיבוד בזמן אמת (או "שכבת מהירות") לעיבוד "חי" של זרמי נתונים. תוצאות העיבוד נשמרות בשכבה בתור תצוגות "חיות" (Real-time views). שכבה זו מספקת זמן קבלת תוצאות מהירה, על חשבון הדיוק.
ארכיטקטורת למבדה מיועדת לאנליזה, והשאילתות עבור קבלת מבט על הנתונים נעשות ישירות על שתי צורות התצוגות, בהתאם לצורך העסקי.

ארכיטקטורת למבדה (lambda)

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

יתרונות בשימוש במנוי CSP בענן AZURE 

 

מודל ה – (CSP ( Cloud Solution Provider הינו מודל רישוי המותאם לעולם הענן. הוא מתבסס על תשלום חודשי לפי שימוש, עם גמישות ושקיפות מקסימליים.
מקבלי החלטות רבים לא נעזרים ביתרונות בשימוש במנוי CSP המותאם לעולם הענן וזאת בשל חוסר הידיעה על השירות, על יתרונותיו ועל איך הוא יכול לשפר את תהליכי ה IT היומיומיים שלהם, וכל זאת ללא תוספת תשלום מצדם.

חלק מיתרונות ה CSP כוללים:
1. תמיכה מקומית ומקצועית עם מסלול ישיר למיקרוסופט. רישוי ה CSP מספק לנו הסכם תמיכה מתקדם המאפשר תיעדוף גבוה וזמני תגובה קצרים יותר – אנו עומדים בתווך בינך לבין מיקרוסופט
2. במנוי CSP אתה משלם רק עבור מה שאתה משתמש, בניגוד ל Enterprise Agreement (EA) בו התשלום הוא שנתי וקבוע מראש.
3. מחיר תחרותי יחסית למנוי Pay As You Go ) PAYG) ו EA – אותה סביבה, רק יותר זולה.
דטה סייט הינה שותף CSP של מיקרוסופט ומתוקף כך היא רשאית למכור את שירותי הענן של מיקרוסופט במסלול ה CSP על כלל יתרונותיו ( 365, AZURE ועוד..). תכנית ה CSP מאפשרת לנו לקיים קשר משמעותי עם הלקוחות שלנו, באמצעותו אנו מציעים שירותים בעלי ערך בתחומי הביליניג, הניהול והתמיכה.
גם אם יש לכם מנוי בענן (EA או PAYG) זו לא בעיה. המומחים של דטה סייט מחכים ומצפים לסייע לכם להעביר אותו למנוי CSP ולהתחיל ליהנות משלל יתרונותיו.

היתרונות בשימוש במיקרושירותים באפליקציות מבוססות ביגדאטה

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

איך שימוש בארכיטקטורת Microservices ישפיע על מורכבות בסיס הנתונים שלכם ומתי כדאי לכם להשתמש בה? איך שימוש בארכיטקטורת Microservices ישפיע על מורכבות בסיס הנתונים שלכם ומתי כדאי לכם להשתמש בה?

 

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

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

שינוי קנה מידה של אפליקציה

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

המשכיות ואיכות המידע

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